銀の弾などない

『銀の弾などない— ソフトウェアエンジニアリングの本質と偶有的事項』（ぎんのたまなどないソフトウェアエンジニアリングのほんしつとぐうゆうてきじこう、英: No Silver Bullet - essence and accidents of software engineering）とは、フレデリック・ブルックスが1986年に著した、ソフトウェア工学の広く知られた論文である。

この記事には参考文献や外部リンクの一覧が含まれていますが、脚注によって参照されておらず、情報源が不明瞭です。

論文概要

原論文は英語である。日本語では『銀の弾丸はない』と、翻訳されることもある。ブルックスは、「銀の弾丸」（Silver Bullet）として、魔法のように、すぐに役に立ちプログラマの生産性を倍増させるような技術や実践 (特効薬) は、今後10年間（論文が著された1986年の時点から10年の間）は現れないだろう、と記載した。

銀の弾丸とは銀で作られた弾丸であり、西洋における銀は霊力を有するとの俗信と結びつける形で1941年米国のユニバーサル映画のヒット作『狼男』で不死身の狼男を倒せる武器として用いられたことから、今日では広く一般にフィクション作品等で狼男や魔物を撃退する際に用いられるものとのイメージで捉えられている。

ブルックスの警句は、非常に多く引用されており、生産性、品質、制御に適用されている。ブルックスは、自身の警句で述べているプログラマの生産性の限界は「本質的な複雑性」（essential complexity）についてのみ当てはまると述べているのであり、「偶有的な複雑性」（accidental complexity）に対する挑戦については支持している。ブルックスは、偶有的な複雑性については著しい改善（おそらく今後10年間で10倍以上）がみられるだろうと述べている。

ブルックスは、この論文で本質的な複雑性に対処するために、次のことを提案している（詳細は#提案を参照）

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

（ブルックス、滝沢、牧野、宮澤、2002年、第16章、P.166）

『銀の弾などない』は、1986年のIFIPでの論文である。1987年に IEEE Computer Society の「コンピュータ」誌に再録された。また、この論文とこの論文に対するブルックス自身の省察『「銀の弾などない」再発射』（No Silver Bullet - Refired）の2つの論文は、ブルックスの著書『人月の神話』（The Mythical Man-Month）の20周年記念増訂版に収められている。

『銀の弾などない』が収録された「コンピュータ」誌の表紙と、『人月の神話』の20周年記念増訂版の第16章「銀の弾などない」の扉には、狼人間を描いた絵が掲載されている。

問題の所在—銀の弾とソフトウェアプロジェクト

この論文が対象とする問題の所在を説明するために、論文の序の文章を引用する。

民話の中の悪夢に登場する怪物のうちでも、狼人間ほど恐ろしいものはない。というものも、狼人間は慣れ親しんでいるものを不意に恐怖に変えてしまうからだ。だから、私たちは、この狼人間を魔法のように鎮めることができる銀の弾を探し求める。
　慣れ親しんだソフトウェアプロジェクトにもこうした性質が若干あり（少なくとも非技術担当マネージャーの目から見ると）、ふだんは無害でまともなのだが、スケジュールの遅延、膨れ上がった予算、そして欠陥製品といった怪物にもなり得る。そして私たちは銀の弾、すなわちコンピュータハードウェアのコストと同じようにソフトウェアのコストも急激に小さくしてくれる特効薬を求める必死の叫び声を聞くのである。
　しかし、これから十年間という範囲で眺めると、銀の弾などはどこにも見えない。技術においても、管理手法においても、それだけで十年間に生産性や信頼性と容易性での飛躍的な改善を一つでも約束できるような開発は一つとしてない。本章では、ソフトウェア問題の本質と、提案されているそれぞれの銀の弾の特性の両方を検証することによって、それがなぜ特効薬になりえないのかについて見ていくことにする。
　とはいっても、懐疑主義は悲観主義とは違う。輝かしい進展は見えないが、実際のところそう決めてかかることはソフトウェアの本質からは離れている。多くの頼もしい新機軸 (革新) が着々と進められている。それらを開発、普及、利用するという苦しいが一貫した努力こそ、飛躍的な改善をもたらすはずだ。王道はない。しかし、道はある。
　病気治療の第一ステップは、悪魔信仰を細菌説によって生理学的理論に置き換えることだった。そのステップこそ希望の始まりであり、すべての魔法のような解決の夢を打ち砕いた。医療従事者は、進歩は段階を追いながら多大な労力を払って遂げるもので、健康回復には持続的で根気強い看護がなされなければならないと教え込まれた。今日のソフトウェアエンジニアリングにおいても、それは変わらない。
— ブルックス、滝沢、牧野、宮澤、2002年、第16章、pp.166-167

主張

要約

視点

ブルックスが本書で主張していることを述べる。

本質的な複雑性と偶有的な複雑性を区別する

ブルックスの主張で重要なことは、ソフトウェア開発の複雑性について、「本質的な複雑性」 (essential complexity) と「偶有的な複雑性」 (accidental complexity) を区別していることである。なお、これは、アリストテレスの分類にヒントを得たものである。

偶有的な複雑性は、ソフトウェア開発者自身が発生させている解決可能な問題に関連する。例えば、アセンブリ言語のプログラムコードの記述、最適化、バッチ処理などによってもたらされる遅延は、偶有的な複雑性に由来する。
本質的な複雑性は、解決すべき問題によってもたらされるものであり、これを取り除くことはできない。もし利用者が30の異なることを行う1つのプログラムを望む場合、この30のことは本質的であり、開発するべきプログラムはこの30の異なることを実行しなければならない。

ブルックスによると、ソフトウェア開発者はこれまで偶有的な複雑性の多くを退治してきたが、その一方で、現在 (1986年) のプログラマは自分の時間の大部分を本質的な複雑性に取り組むことに費している。

偶有的な複雑性におけるブレークスルー

過去に行われてきたソフトウェア技術の発展は、ソフトウェア開発における偶有的な複雑性を攻略した。ただし、これはあくまでも偶有的な複雑性を攻略しただけであって、本質的な複雑性を攻略したわけではない。

高水準プログラミング言語

偶有的な複雑性の領域における大きなブレークスルーの一つは、FORTRANのような高水準プログラミング言語である。高水準プログラミング言語は、データ型やデータ構造、操作などのような高水準な概念でプログラミングできる環境を提供し、プログラマは低水準な複雑性を考える必要がなくなった。

タイムシェアリングシステム

タイムシェアリングシステムより古いバッチ処理の環境では、ターンアラウンドが遅いため、プログラマは思考を中断させられてしまい、また時間コストがかかってしまっていた。しかし、タイムシェアリングシステムの登場により、プログラマは、早いレスポンスの環境で作業ができるようになった。

統一されたプログラミング環境

UNIXとInterlispによる統一されたプログラミング環境が広く普及し、次のような特長により、プログラマの生産性は大きく向上した。

銀の弾の候補

次に、銀の弾になる可能性のあるとされている技術について述べる。

Adaとその他の高水準プログラミング言語の進歩

Adaなどの現在のプログラミング言語が出現したことは、進歩であるといえる。
ただし、Adaなど現在のプログラミング言語の出現は、高水準プログラミング言語が初めて出現したことよりも、影響は小さい。
また、Adaは、モジュール化、抽象データ型、階層構造化を促進している。これらは、有用な進歩であるといえる。
しかし、Adaもまた高水準プログラミング言語の一つに過ぎない。
そのため、Adaなどの現在のプログラミング言語が出現したことによる影響は、あくまで偶有的な複雑性を低減することにとどまる。

オブジェクト指向プログラミング

オブジェクト指向プログラミングでは、クラスの概念を導入し、カプセル化と継承を活用することができる。

多くのソフトウェア工学分野の研究者が、オブジェクト指向プログラミングの有効性に大きな期待を寄せている (グラディ・ブーチ) 。
そして、ブルックス自身も、オブジェクト指向プログラミングに非常に期待している。
ただし、オブジェクト指向プログラミングも、ソフトウェア開発の過程における偶有的な複雑性の一つを除去するにとどまる。
したがって、オブジェクト指向プログラミングが発展しても、本質的な複雑性が低減されるわけではない。

人工知能

音声認識や画像認識に象徴される人工知能技術からは、あまり収穫は得られない。
ソフトウェア開発についての困難は何を表現するかを決定することであり、表現することそれ自体ではない。
エキスパートシステム技術については、次の節で述べる。

エキスパートシステム

多くのソフトウェア科学者が、エキスパートシステム技術をソフトウェア開発環境に適用しようと努力している (デイビッド・パーナス) 。
もしエキスパートシステム技術をエキスパートアドバイザーとして活用することができれば、ソフトウェア開発者の役に立つだろう。
エキスパートシステム技術では、知識ベースを構築することが困難であり、そのことが障害となっている。
知識ベースを構築するためには、専門家 (エキスパート) を確保する必要がある。しかし、これは簡単なことではない。
また、たとえ専門家を確保できたとしても、彼らの豊富な知識を知識ベースに登録するための効率的な方法を開発しなければならない。

「自動」プログラミング

自動プログラミングとして言及されてきた技法は、つまるところ高水準プログラミング言語を使ったプログラミングの婉曲的表現である (デイビッド・パーナス) 。

ビジュアルプログラミング

ビジュアルプログラミングを使って生産性を向上させることは難しい。

フローチャートは、ソフトウェアの構造を抽象的に表現するものとしては貧弱である。そのため、プログラマは、実際にはフローチャートを描いてからプログラミングをするのではなく、プログラミングしてからフローチャートを描いている。
重要なソフトウェア構成図の詳細を表示するには、現在のディスプレイは範囲と解像度の点で力不足である。そのため、ハードウェア技術のさらなる進歩が必要である。
ソフトウェアは、基本的に複雑であり視覚化することが難しい。そのため、ソフトウェアの視覚化を試みても、特定の一つの視点による一面的な認識しか得られない。

プログラム検証

プログラム検証には労力がかかる。そのため、全ての開発対象を検証することはできず、一部の重要なプログラムを検証することしかできない。また、たとえプログラムを検証したとしても、それは、プログラムが仕様書通りに実装されていることを証明するだけであり、仕様書にバグがないことを証明するわけではない。

プログラム開発の本質の多くの部分は、仕様書のデバッグである。
完全で一貫した仕様書に到達することは、非常に難しい作業である。

環境とツール

プログラミング環境とツールの整備については、既に大きな成果が出ており、今後のさらなる成果はあまり期待できない。

ワークステーション

ワークステーション (プログラム開発のための作業用コンピュータ) の性能は、飛躍的に向上した。
プログラムや文書の作成には、現在のワークステーションの性能で既に十分であり、ワークステーションの性能が現在以上に向上しても生産性に寄与する余地はない。
プログラムのコンパイルは、特にワークステーションの性能を必要とする作業だが、現在のワークステーションの性能でも、既にほとんど生産性の阻害要因とならない水準になっている。

提案

以下のことを提案する。

ソフトウェア製品の大市場の利用

購入できるものをあえて構築しないようにするために、市場を活用するべきである。

要件の洗練と迅速プロトタイピング

ソフトウェア要件を確立するときには、開発循環計画の一部として、迅速なプロトタイピングを使用する。
洗練された手法で丁寧に要件定義をしたり、顧客自身が要件を明確に認識していなかったりすることが多いため、迅速にプロトタイピングを行うことが有用である。

漸増的開発

実行と使用とテストが実施されるにつれて、ソフトウェアは、機能を増やしながら、有機的 (系統的) に成長する。
漸増的開発を通して有機的に「育成されていく」ソフトウェアを支持する。
まずメインプログラムを実装して、その後にサブプログラムを実装してゆくことを推奨する。
このような漸増的開発を採用することによって、開発のどの段階でもシステムが動作するので、プログラマのやる気が出る。
漸増的開発を採用することによる恩恵は、大規模プロジェクトにおいても得られる (ベーム) 。

偉大なデザイナー

若い世代の素晴らしいコンセプトデザイナー (設計者) を発掘し、育てる。
プログラミングは、創造的な過程である。そのため、設計能力が非常に高い「偉大なデザイナー」と設計能力が平均的な「よいデザイナー」が存在する。
よいデザイナーは、優れた練習法でソフトウェア設計を学ぶ。こうした教育は、まったく理にかなったことである。
しかし、偉大なデザインは、偉大なデザイナーからしか生まれない。よいデザイナーは、偉大なデザインを生み出すことはできないのである。
ソフトウェア企業にとっては、偉大なデザイナーを発見し育成することに大きな労力を費すべきである。
偉大なデザイナーを偉大なマネージャと同等に処遇する。
偉大なデザイナーと偉大なマネージャに対して、給与だけでなく、高い地位に伴う全ての給付を同様に与える（広いオフィス、スタッフ支援、出張旅費など）。

その他

多くの企業にとっては、知的労働者 (プログラマではなくエンドユーザ) に、パーソナルコンピュータとワープロソフト、表計算ソフトなどを与え、自由に使わせることが、強力な戦略である。