目次
20年たっても結論は変わらない
前回までに、18章（1-15章の総まとめ）→16章（銀の弾などないのだ！という主張）→17章（銀の弾はやっぱりないのだ！という主張）を読み解いてきました。今回は、19章「『人月の神話』から20年を経て」です。
連載記事一覧は、コチラの最下段から
ブルックス氏、自己反省をする の巻
前回（第4回）の末尾でも述べた通り、この章は「人月の神話」を書いてから20年を経て、「人月の神話の、何が正しくて何が正しくなかったのかを明確にしよう」という、ブルックス氏の自己反省です。
すさまじくザックリと要旨をまとめると、下図のようになります。
正しかったのは、
- コンセプトの完全性が成功の鍵であること
- その、コンセプトをしっかりと構築するために、アーキテクトを任命し、アーキテクチャとインプリメンテーションを分離すること
- セカンドシステム症候群、すなわち、「後継システムの開発」には、大きなリスクがあること
- そして、もっとも重要な命題である「人月の神話」は、やはり神話であったこと
が挙げられます。
一方、自己反省として、正しくなかったこととして挙げられるのは
- 一つは捨石にする、という発想（前提としていたウォーターフォール型開発そのものに限界があったため）
- 情報公開・共有こそ是である、という考え方（カプセル化は非常に有効だと分かったため）
です。
また、20年間で大きく状況を変化させたのは、以下の2つの出来事だと述べられます。
- マイクロコンピュータ（いわゆる、パソコン）が普及して、”偶有的困難”を大幅に減らした
- パッケージソフトが普及して、極力「自分で作らない」ことが可能となった
そりゃそうですよね。って感じです。
人月の神話は、やはり”神話”だった
このうち、コンセプトの完全性等については、1章~15章の解説の中で触れていきますが、本書まるまる一冊の大命題であり、大前提である「人月の神話」については、ここで詳細にみておきましょう。
バリー・ベームの研究
ブルックス氏は、バリー・ベームの研究を引用し、以下のような発見を取り上げます。
ベームの結果は、要員と月数の間のトレードオフは線形どころではなく、人月は生産性の尺度としては実に神話的だとする『人月の神話』の主張を、強固に立証している。中でも、彼が発見した次のことは注目に値する。
- 最初の出荷までのコスト最適スケジュール時間 T を、T＝2.5×（人月）1/3、とした。つまり、月数で表した最適時間は、予想された人月労力の立方根に比例する。この数字は彼のモデルにおけるサイズ見積もりやその他の要因から引き出された。最適要員配置の曲線はこれの系として得られる。
- コスト曲線は、計画されたスケジュールが最適のものより長くなるにつれ上昇する。人は時間に余裕があると、ますます時間をかけるものだ。
- コスト曲線は、計画されたスケジュールが最適のものより短くなると急上昇する。
- 投入された要因の人数には関係なく、計算された最適スケジュールの4分の3より短い時間内で成功したプロジェクトはほとんどない！上位管理者が不可能なスケジュールの約束を要求してきた場合、ソフトウェアマネージャーにとって、引用価値のあるこの結果は強固な防衛手段となる。
さらに、新たな要員を追加すると、キャッチアップに数週間の時間を要することから、「要員を追加しても、納期短縮にはつながらない」と述べます。もちろん、「遅延しているプロジェクトにさらに要員を追加することは、つねにコストがより高くつくことにはなるが、完了をつねに遅らせるわけではない」という話は持ち出すものの、そのためには「プロジェクトの初期段階で要員を追加するべき」と述べています。
結局のところ、人と月は交換可能ではない、というブルックスの説は、20年たっても何ら色あせることがない真理だということです。
カプセル化は、正解だ
ブルックス氏の自己反省における、「漸増的（インクリメンタル）な開発が理想だ」という話は、16章「銀の弾などない」や、17章「銀の弾などない 再発射」で熱く語られていますので一旦良しとして、ここでは、「情報隠匿は罪だ」と考えていたことへの反省の話をしたいと思います。
まずは、その「間違っていた、と自己反省した箇所」を第7章より引用します。
カーネギー・メロン大学のD・L・パルナス（中略）の主張では、プログラマは自分の担当以外のシステム部分の開発に関する詳細にさらされるより遮断されている方が効率的だと言う。ここでは、すべてのインターフェースが完全かつ正確に定義されていることを前提にしている。そういうデザインはまさしく理論的だが、完璧な完成品に依存する点で、失敗のレシピだと言える。優れた情報システムは、インターフェースエラーをさらけ出して、その修正を促すものなのだ。
（第7章：バベルの塔は、なぜ失敗に終わったのか より）
これですね。「失敗のレシピだと言える」と言い切ってしまったのだけど、ごめんなさい・・・というわけです。素直ですね、ブルックスさん。その上で「モジュールに関する情報隠匿の定義＝オブジェクト指向の考え方」は、以下の3段階を経て発展してきたと解説します。
- モジュールを、独自のデータモデルおよび演算一式を備えたソフトウェア実体（エンティティ）と定義し、データは適切な操作を介してのみアクセスできる＝パルナスの提唱した”情報の隠匿”
- 当該モジュールを「抽象データ型」に格上げし、この抽象データ型からたくさんのオブジェクトを派生させた
- 「継承」による、クラスの階層化を実現
このうち、オブジェクト指向は「第一段階」すなわち、パルナスが提唱したことである、として、自らの過ちを認めています。
要は、16章・17章での主題が「オブジェクト指向」だったことを踏まえて、オブジェクト指向の”知的先祖”とも言うべきパルナスの思想は素晴らしい、と評価したのでしょうね。
2つの大きな変化
20年間で起こった大きな変化としてあげられた「PCの普及」「パッケージソフトの普及」ですが、前者については、既に人間の知覚を超えるレベルまで進化した事を踏まえると、今後の影響は（まぁ、小さくはないでしょうが、相対的に）大きくないと理解し、割愛します。一方、後者は、まさに「本質的困難」を打破する非常に意味のある一手であり、また、ひとつの”思想”として強く認識すべきものですので、少し読み解きをしていきたいと思います。
パッケージソフトの意義
パッケージソフトは、すでにテストされており、詳細なドキュメントが添付された上に、完全に「情報隠匿」もなされています。再利用性という意味で「完璧」です。「つくらなくていいものは、つくらない」「すでにあるものは、そのままつかう」という基本思想に基づけば、パッケージソフトこそ、生産性向上の鍵です。
もちろん、パッケージソフトを買ってきて、それですべて解決、ということにはなりません。その場合・・・
特に見込みのある方向は、マスマーケットパッケージをプラットフォームとして使用して、もっと機能豊富でよりカスタム化された製品を構築することだ。
ということになります。これは、実際に、弊社（株式会社ギックス）が提供する、データビジュアライズサービス”graffe/グラーフ”の構築に際して用いた考え方です。既存のプラットフォームを環境として使い、それを活用して「自社のサービス（あるいは、ソリューションと言うべきかもしれませんが）」を組み立てるわけです。
この「パッケージを使って構築する」ということは、非常に有効です。引用します。
現在、パッケージを使って構築するという現象が平均的な情報システム管理制御プログラマに大きな影響を及ぼしていないため、ソフトウェアエンジニアリング分野ではまだあまり目立っていない。そうはいっても、これは概念構造体を作り上げることの本質を攻略するものだから、急速に成長していくことだろう。パッケージソフトは緻密だが厳密なインターフェースを持った関数の大きなモジュールを提供するので、その内部の概念構造体をデザインする必要が無い。（中略）よって次のレベルのアプリケーションを構築する人は、豊富な機能やテスト済みコンポーネント、優れた文書が手に入り、短い期間で開発ができ、コストは極端に抑えられる。
当時（1995年）の時点では、まだパッケージ活用が十分ではなかったのかもしれませんが、現在は、かなりのパッケージソフト、および、パッケージ化されたプラットフォームが提供されています。さらに、それらの多くは、クラウド環境で提供されており、容易に活用できます。（例えば、最近、テレビCMとかでやっているIBM Blueｍixなんかは、バッチリそんな感じですよね。） →関連記事：IBM Bluemix 経由で Watsonを使ってみる
尚、このパッケージソフトウェアの利用者は、４つのレベルに分けられるとブルックス氏は主張します。要約します。
- そのままの利用者：アプリケーションの提供する機能・インターフェースをそのまま使う人
- メタプログラマ：提供されたインターフェースを利用しつつ、エンドユーザーの利便性向上のために関数などを作る人
- 外部機能作成者：アプリケーションに、手作りで機能を追加する高度な技術を持つ人
- メタプログラマその２：複数のアプリをシステムコンポーネントとして活用する人
上の3つは分かりやすいですが、最後の1つはなかなか複雑です。ブルックス氏は、この最後の利用者のニーズは殆ど満たされていないとした上で、以下のように述べます。
最後に挙げた利用者にとって、パッケージアプリケーションには補足的な文書作成が為されているインターフェース、すなわちメタプログラミングインターフェース（MPI）が必要である。このインターフェースにはいくつかの能力を必要とする。まず、メタプログラムはアプリケーション群全体をコントロールする必要があるのに対し、通常のアプリケーションではそれぞれが自分でコントロールするものと想定されている。
このあたりに解決策が提示されてくると、より一層「パッケージソフトの活用」が進み、生産性が向上していくというわけですね。僕は、最近の動向に詳しくないので、この辺りは弊社の別メンバーに解説記事を書いてもらいたいと思います。
ソフトウェアエンジニアリングの将来
20年を経てもなお、ソフトウェアエンジニアリングの置かれた状況は（ほとんど）変わらないとブルックス氏は締めくくります。
結局のところ、ソフトウェアエンジニアリングは、化学工学と同様に、産業規模の工程に規模拡大させるという非線形問題に関心があり、また、経営工学同様に、人間の行動の複雑性によって永久的に混乱させられるものなのである。
ソフトウェアエンジニアリングに特有な問題は、現在でもまさしく（田中注：20年前に）第1章（田中注：「タールの沼」のこと）で述べたことである。再び述べておこう。
- システムに向けてプログラムセットをデザイン、実現する方法
- プログラムまたはシステムを、安定した、テスト済みで、文書完備のサポート付き製品になるようにデザイン、実現する方法
- 大量の複雑性に対して知的制御を維持する方法
ソフトウェアエンジニアリングというタールの沼は、これから当分の間厄介なままだろう。人類が、手の届く範囲の、あるいはぎりぎりで届かないところにあるシステムを、ずっと試していくことは容易に想像がつく。おそらくソフトウェアシステムは、人間の作り出したもののうちで最も複雑なものだろう。この複雑な作品は私たちに多くのことを要求している。この分野を引き続き展開させていくこと、より大きな単位に組み立てることを学ぶこと、新しいツールを最大限使用すること、正当性が立証されたエンジニアリング管理方法に最大限順応すること、常識から自由になること、それに誤りを犯しがちな点と限界を気づかせてくれる神の与えた謙遜の心を。
この結びの一文を読むと、ソフトウェア開発とは決して、スキルだけで解決するものではなく、”正しい思想”によってのみ解決されるのかもしれないなと感じます。
もはや、完全に「哲学」の領域に突入しているなぁとは思いつつ、これこそが「ソフトウェア開発のむずかしさの”真理”」を言い表していることにも気づかされます。まぁ、20年も一つの事象（ソフトウェア開発）を研究し続けていれば、そりゃぁ哲学的にもなりますよね。本書を理解するということは、ブルックス氏の”精神世界”を理解することなのかもしれません。
これまでの連載（第0回から第5回）は「人月の神話」の概略および、その後の情報更新に関しての読み解きでした。ここまで読んでいただけば、本書の7割は理解したと言っていただいて大丈夫だと思います。さらに、書籍を購入して18章をしっかりと読んでいただけば「本書の90%を理解した」と胸を張って言って良いと思います。
当初は、この後、第1章に立ち戻って、第15章まで順に読み解きを進めていこうと思っていたのですが、先ほど述べた”精神世界”をより理解するために、すこし回り道をしたいと思います。それは「エピローグ：50年間の不思議、興奮、それに喜び（2ページ）」および「訳語について（2ページ）」「訳者あとがき（7ページ）」の読み解きです。特に、訳語および訳者あとがきは、正直言って、読みやすいとは言い難い本書の翻訳にあたり、どういう苦労があったのかを窺い知ることができますので、そこにスポットライトを当てたうえで、本編（1章~15章）の解説へと進みたいと思っています。お付き合いのほど、よろしくお願いします。
連載記事一覧は、コチラの最下段から
