目次
大量生産は、生産プロセスの画一化が重要
本日は、第12章：切れ味のいい道具 をご紹介します。
連載記事一覧は、コチラの最下段から
プログラミングの門外漢にはつまらない章
この章は、開発の現場において、どのような「ツール」が必要か、というお話です。したがって、本章は、プログラミングの現場にいないと、何を話してるんだかさっぱりわからない（あるいは、興味を持てない）内容になっています。さらに悪いことに、ターゲット機械、媒体機械というような表現も理解を困難にしています。（ちなみに、ここでの「機械」は、「ハードウェア」ということになります。ターゲット機械は本番環境で、媒体機械は開発環境とでも理解すべきでしょうかね。）
いずれにしても、本章の内容についてクドクド語るのは、当連載の立ち位置（すなわち、ビジネスサイドの人も含めて、しっかりと”人月の神話”を理解する）としては、少々お門違いな感じがしますので、今回は、本章の「タイトル（＝切れ味のいい道具）」に注目し、もう少し一般的な事柄として読み解きを進めていきたいと思います。
切れ味のいい”個人的な”道具は「考える場面」では有効
タイトルである「切れ味のいい道具」に関しては、本章の冒頭から引用します。
熟練した機械工はそれぞれ、長年にわたって収集し、大切にしまって守ってきた、見れば力量までわかるような自分専用の七つ道具を持っている。全く同じように、プログラマはちょっとした編集プログラムやソートプログラム、2進数表示ダンプ、ディスクスペースユーティリティなどを揃えて、自分のファイルにそっとしまっておく。
これは普遍的な話です。例えば、コンサルタントも、”あんちょこ”というか、”虎の巻”というか、まぁ、そういう類のものを独自で持っているものです。市販されている書籍の場合もあれば、過去に携わったプロジェクトの”考え方”に相当する部分の資料（大抵はクライアント名などのプロジェクトの特定される情報を消した資料＝サニタイズされたものです）であったり、討議した際の手書きのメモ書き・ノートであったりすると思います。これらを集積しておけば、生産性は何倍にもなります。あるいは、エクセルなども、過去資産を参考にすることがあります。（まぁ、これも、エクセルそのものというよりは、それを作る際の”考え方・設計思想”ですが。）
しかし、このやり方はプログラム開発の現場においては、馬鹿げている、とブルックス氏は一蹴します。
しかし、そういうやり方は、プログラム開発プロジェクトから見ると、馬鹿げている。第一に、本質的問題はコミュニケーションであり、個人的なツールはコミュニケーションの助けというよりも、妨げになるものだ。第二に、機械や使用言語が変われば、技法は変わるものだから、ツールの寿命は短い。最後に、汎用的なプログラミングツールを共同で開発・メンテナンスする方が、どう見てもはるかに効率的だ。
これはこれで、真理です。なぜなら、システム開発は「モノづくり」の領域だからです。
一方、コンサルティング（特に、戦略コンサルティング）の領域は、「理論と概念」の世界です。ここにおける「個人的なツール」は、コミュニケーションの妨げになりません。その個人的なツールによって思考の幅を広げる事は非常に良いことです。ただし、その思考の結果を、みんなに分かりやすく伝える（コミュニケーションする）ことにはしっかりと留意する必要があります。これは、プログラム開発と何ら変わりません。
そう考えてみると、アーキテクトの領域においては、切れ味のいい道具の”個人的な”蒐集は推奨されるべきでしょうね。
本章で語られるのはあくまでもモノづくり＝インプリメンテーションの領域の話です。
大規模システム開発の現場は、大量生産品をつくる工場と同じ
さらにいえば、本章で取り上げられている大規模システム開発は、伝統工芸でもなければ家内制手工業でもありません。そこで必要となるのは「画一的に生産する体制」です。
これを意識せずにシステム開発に取り組むと、痛い目にあいます。多くの企業が、システム開発において失敗するのは、どの部分が伝統工芸・家内制手工業で、どの部分が大量生産なのかを見極められていないことが原因です。「考える部分」は伝統工芸・家内制手工業で、「作る部分」は大量生産です。
自社製品をつくる際に、生産量を急に5倍に増やそう、とした場合にどうなるかを考えてみると良いでしょう。
いまこの瞬間が減産期で、工場の生産ラインに大きな余裕がある状況ならば「明日から5倍に増やす」ということも可能かもしれません。しかし、普通の状況ではそんなに急激な増産は不可能です。生産ラインはそんなに簡単に増やせませんよね。また、仮に生産ラインに余裕があったとしても、その操作をできる人材を一定数確保できないといけません。それには、最低限の”熟練”が必要です。これも、急激に増やすのは簡単ではありません。（余剰に囲っている、なら可能です）
あるいは、ライン式生産方式ではなく、セル生産方式だったとしても、熟練工の確保は課題です。道を歩いているお兄さんたちをスカウトして、労働者を5倍の人数に増やしたとしても、いきなり5倍になることは無いでしょう。（生産プロセスを画一的に設計できていれば、短時間で、5倍に引き上げていくことは可能だとは思います）
画一的な生産体制をつくろう
つまり、大規模システム開発が、大量生産を行うことだと理解すれば、皆が「画一的に」動くことが求められるわけです。そうすると、そこに「個人的に蒐集したツール」が歓迎されないのは自明です。
ですので、本章の中では「切れ味のいい”共通的な”道具」を用意しよう、という話になっていきます。
実のところ、汎用的なツールだけでは、十分とは言えない。特殊なニーズや個人的な好みから、特化したツールも求められる。だからプログラミングチーム内で話し合い、私はチームごとにツール責任者を要求した。その製作者は共通のツールすべてに熟達していて、顧客の立場にある上司に使用に関して教育することができる。また、上司が必要とする限定したツールを作ることもできるのだ。
プロジェクトマネージャーは、共通のツール製作に関する方針を立て、そのためのリソースを確保しなければならない。と同時に、特化したツールの必要性も認識して、そのツール製作のために要員を自分の作業チームから出し惜しみしてはならない。
ということで、チームという単位での共通ツールと、プロジェクト全体における共通ツールの2階層できることは許容するが、”個人レベル”での便利ツールは使わせないようにして、生産性の向上と生産プロセスの画一化を両立させよう、というわけですね。
システム開発は”積み上げ”の作業です
第8章の解説でも述べましたが、システム開発とは積み上げの作業です。トップダウンでテーマを決めたとしても、建築のように、徐々に作り上げられていくものです。
土台として何があり、どの部分にどの素材を使い、どの順番で作って行くのかを、チーム全員が理解している必要があります。ピラミッドを3日で作るのは無理ですよね。秀吉の一夜城も所詮は伝説で、事前準備なども勘案すれば工期はそれなりにかかっています。現代のプレハブ住宅も、現地の組み立ての前に工場での作業も発生しているわけですし、そもそも土台づくりが必要ですので、順番論は大切なのです。同様に、システムも、いきなり完成させることはできません。そんな「魔法」はないのです。
これは、漸増的開発（インクリメンタルな開発）をしたとしても同じです。最終的に納品できる商品・製品をつくり上げるためには、開発の順序やクリティカルパスなどの”制約”からは逃れられません。
開発体制（＝生産体制）を確保し、開発プロセス（生産プロセス）を画一化し、適切なコンポーネント（素材）を配置し、適切な順序で開発（組立て）を行っていくというモノづくりの世界において、たんなる思い付きや、気分の変化が仕様に影響を与えることは、あってはならない事態です。システム開発とは、クライアントとベンダーが、相互に信頼しあって初めて達成できる「プロジェクト」だということを、もっともっと理解する人が（開発側にも、クライアント側にも）増えるとよいなと思う次第です。
連載記事一覧は、コチラの最下段から
