第2回：銀の弾は無いけど、”銃”はあるよね｜本気で読み解く”人月の神話”（第16章）

すっごい武器はないが、まぁまぁ効く武器は結構ありそう。

人月の神話【20周年増訂 新装版】

だれにも読まれていない（あるいは、読んでも実践されていない）ソフトウェア開発者のバイブル「人月の神話」を読み解くこのシリーズですが、僕が最も思い入れのある章から、ガチ読み解きを始めていきたいと思います。「第16章：銀の弾などない　－ソフトウェアエンジニアリングの本質と偶有的事項」です。

連載記事一覧は、コチラの最下段から

銀の弾とは何か

「銀の弾などない」という章タイトルの意図するところは、この一文を読んでいただけると良くわかると思います。引用します。

民話の中の悪夢に登場する怪物のうちでも狼人間ほど恐ろしいものはない。というのも、狼人間は慣れ親しんでいるものを不意に恐怖に変えてしまうからだ。だから、私たちはこの狼人間を魔法のように鎮めることができる銀の弾を探し求める。

この一説は、本書のメインテーマである「システム開発」の話として、以下のように続けられます。

慣れ親しんだソフトウェアプロジェクトにもこうした性質が若干あり（中略）ふだんは無害でまともなのだが、スケジュールの遅延、膨れ上がった予算、そして欠陥製品と知った怪物にもなりえる。そして私たちは銀の弾、すなわちコンピュータハードウェアのコストと同じようにソフトウェアのコストも急激に小さくしてくれる特効薬を求める必死の叫び声を聞くのである。

しかし、これから10年間という水平線を見渡すと、銀の弾などはどこにも見当たらない。

では、どうするべきなのか？＝まずは「むずかしさ」を理解しよう

それでは、いったい、どうしたら良いのでしょうか？そのために、著者は「むずかしさ」を理解することから始めるべきだと提言します。

ソフトウェア開発のむずかしさ

ソフトウェア開発における「むずかしさ」は、本質的なものと偶有的なものに分けられる、とブルックス氏は述べます。

本質的なむずかしさとは、ソフトウェア開発に固有のものです。具体的には「複雑性（ややこしい）」「同調性（他と合わせる必要がある）」「可変性（常に変化することが求められる）」「不可視性（リアルなものとして捉えられない）」の４つが挙げられます。

一方、偶有的なむずかしさとは、事象としては実際に難しいものの、別にソフトウェア開発だから難しいってわけではない、というような事象です。これは、ソフトウェア開発の歴史の中で、少しずつ解決されてきました。（もちろん、この”偶有的むずかしさ”さえも、まだ完全に解決していないが故に「銀の弾がない」という結論に至っているわけですが）

その解決の歴史として「高水準言語（機械語からの脱却による”概念”の世界でのプログラミングの実現）」「タイムシェアリング（リアルタイム処理による”思考を妨げない”）」「統一されたプログラミング環境（統合ライブラリ等によって”概念構造体”としてプログラムを捉えることができるようになった）」という3つについて述べられます。

しかし、高水準言語は”言語に対する習熟”が必要になることがボトルネックであり、また、タイムシェアリングも”応答速度が人の知覚可能な領域を超えた”後には更なる改善機会としては存在し得なくなったと指摘されます。

最後の砦「統一されたプログラミング環境」が銀の弾の可能性を秘めている（かもしれない）わけです。というわけで、後半は、統合プログラミング環境についてのお話となります・・・となるのが筋が良いストーリーだと思うのですが、実際には、この後「上記全部をひっくるめた、現在（といっても、1980年代半ば）時点で研究が進んでいる『銀の弾の”種”』」についての議論になります。（なんでやねん。）

プログラミング環境の変化に伴う「改善」

（当時の）技術動向については、9つのトピックが取り上げられます。

最初に取り上げられるのは、Adaを含む高水準言語についてです。Adaは「エイダ」と読みます。僕は使ったことが無いのですが、少なくとも1980年代には重要な役割を持っていたプログラミング言語です。しかし、これも先述した「偶有的困難」の一部を解決することしかできませんので、銀の弾とは言えません。

続いては、オブジェクト指向プログラミングです。モジュール化によって再利用性が高まるなどの強みはありますが、これも「偶有的困難」の排除に留まると断じられます。

3つ目は人工知能です。人工知能は「人間の知能によってのみ解決できる問題を解決する」ものと「推論エンジン・ルールベース」を持つものに分けられる、と定義した上で、まずは、その前者の話をしています。これには非常に大きな可能性はあるものの「個別の問題特有の機能」になってしまうので、普遍的に活用することが困難だと結論づけられます。

4つ目は、先ほどの人工知能の区分のうち、後者すなわち推論エンジン・ルールベースのもの＝エキスパートシステムです。これは、非常に有効だとしつつも、その設計・構築に際して「推論」「ルール」をしっかりと定義できる人材（その業務領域の専門家）が必要になることが課題とされます。（要は、誰にでも作れるものではない）

5つ目は、自動プログラミングです。プログラムの自動生成によって、いろんな困難は回避できるが、「シンプルな機能群」ならば実現できても、「複雑な機能群」は自動では作れないだろうと著者は述べます。

6つ目は、ビジュアルプログラミングです。これについては、「そもそも見えない（不可視）プログラムを、ビジュアルで表現するのには無理がある」ということで、割りとあっさりと可能性を否定します。

7つ目は、プログラム検証ということで「システムデザインの段階で、バグをつぶしこむ」という技法について語られます。ただ、この技法の最大の弱点は「プログラムと仕様書が整合している」ということしか検証できないために、「仕様書そのものが間違っている」というリスクを潰しこめないことです。

8つ目は、環境とツールです。これについては、「生産性と信頼性の両方においてきっと成果をもたらすだろう。しかし本来の性質から言って、今後の見返りはあまり期待できないはずだ」とバッサリ切り捨てます。（僕の理解としては、「情報の”最新状態”が常に共有されるということは”画期的”ではあるが、”本質的な解決”にはなりえない」ということだと思います。）

最後＝9つ目は、ワークステーションです。ワークステーションのスペックは飛躍的に向上し続けています。これによって生産性は間違いなく上がります。しかし、1980年代当時でさえも、既に「人間の思考」を妨げないレベルに到達してしまっていましたので、そこから先に「スペックが高くなったから、プログラミングの生産性が上がった」ということにはならないだろうというのが、著者の見解です。

つまり、現在進行形（我々からすると、過去進行形ですが・・・）の技術を見ても、改善にはつながるだろうが、銀の弾として魔法のような効果はもたらし得ない、ということです。

では、どうしろっていうのよ！？

じゃぁ、どうすれば良いのさ？というお話になりますよね。著者の答えはシンプルです。

「本質的な課題に向き合おうぜ。以上。」

・・・お、おぅよ。って感じですね。（笑）ちょっと分かりにくい日本語なのですが、引用します。

仮に作業の中でコンセプト部分そのものに現在一番時間がかかっているのならば、単にコンセプトを表現するだけの部分にいくら労力を割いても生産性を大きく向上させることはできない。

直訳感がありますよね。（笑）これは、「私は、作業工程の中で”コンセプト策定”に一番時間がかかっていると思っている。そうだとすると、既に策定されたコンセプトを”表現する＝プログラムという成果物にする”ところをどうこうしても、全体としての生産性は上がらないよね」ということだと僕は理解しています。

もっと平たく言えば「コンセプトを策定するところ（正確には、概念構造体を定式的に定義するところ）を改善しようぜ」ということです。

”コンセプトの本質”への攻略

それを、「コンセプトの本質への攻略」と呼んで、4つのアプローチを提唱します。

それは、

• 自分で作らないで、できてるものを買えばいいんじゃないか？
• 要件を定義するのがメチャメチャ難しい上に、メチャメチャ重要なんだから、仕様を決めきって作るんじゃなくて、プロトタイプ作成と仕様作成を往復しながら進めるべきなんじゃないの？
• システムを「構築する」のをやめて「育成する」ことにしたらどう？とりあえず動くものを作ってから、ちょっとずつ機能拡張していこうよ。
• デザイナーを育てませんか？結局、画期的なソフトウェアって、少人数の天才がつくるもんだから、そういう”天才的な人”を育てるしかないよ。

という4つです。（下図に、もう少し詳しく本書の記述内容をまとめておきました。）

ちょっと余談ですが・・・

本筋からは少し外れますが、少し余談を。下記の一説をご一読ください。

ソフトウェア制作者が顧客のために行う最も重要な仕事は、製品の要件を繰り返し抽出し、洗練していくことだ。実際のところ、顧客自身何を希望しているのか分かっていないものだ。彼らは通常、どんな質問に答えなくてはならないかを理解しておらず、指定しなければならない問題の詳細さについて考えたことなどほとんどない。「これまでの人がやっていた情報処理作業と同じように動く新しいソフトウェアシステムを作ってくれ」という単純な答えでは、実際まさしく単純すぎる。顧客は、正確にそれを望んでいるのではない。

この一文は、多くのソフトウェア制作者が感じていることでしょう。しかし、結局のところ、皆、文句を言うばかりで、それを自ら解決しようとはしないわけです。つまり「要件を決めるのは誰か」というところに関して、大きな誤解があるのです。「要件を出す」のは顧客、「要件を出し切らせて整理する」のは製作者、「整理された要件を承認する」のは顧客、であるべきです。

このあたりに、そもそもの「ソフトウェア開発に潜む深遠なる闇」の一端が見え隠れすると思うんですよね。いや、ほんとに。

そして、提言へ

さて、ここまでの一連の流れを踏まえたうえで、本章の冒頭に述べられる「提言」（すなわち、上述した「”本質へのアプローチ”の要約に相当するわけですが）を読むと、非常に含蓄深く感じられるはずです。

• 購入できるものを敢えて構築しないようにするためのマスマーケット（市販製品）の利用
• ソフトウェア要件の確率に際し、開発反復計画の一部として、ラピッド（迅速な）プロトタイピングを使用すること
• 実行と使用とテストが行われるにつれて、より多くの機能をシステムに追加しながら、ソフトウェアを有機的（系統的）に成長させること
• 若い世代の素晴らしいコンセプトデザイナーを発掘し、育てること

深いなぁ、、、。ただ、冒頭に、これだけを読んでも、ピンとこないと思うんですよ。一方、この流れの中で理解を進めると、なるほどなと肚落ちしませんかね？というわけで、非常にしっくりきたところ（え、僕だけ？）で、第16章の読み込みは終了です。

次回は、【第17章「銀の弾などない」再発射】を読み解きます。

連載記事一覧は、コチラの最下段から