『銀の弾などない— ソフトウェアエンジニアリングの本質と偶有的事項 』（ぎんのたまなどない ソフトウェアエンジニアリングのほんしつとぐうゆうてきじこう、英 : 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などの現在のプログラミング言語が出現したことによる影響は、あくまで偶有的な複雑性を低減することにとどまる。
オブジェクト指向プログラミング では、クラス の概念を導入し、カプセル化 と継承 を活用することができる。
多くのソフトウェア工学分野の研究者が、オブジェクト指向プログラミングの有効性に大きな期待を寄せている (グラディ・ブーチ ) 。
そして、ブルックス自身も、オブジェクト指向プログラミングに非常に期待している。
ただし、オブジェクト指向プログラミングも、ソフトウェア開発 の過程における偶有的な複雑性の一つを除去するにとどまる。
したがって、オブジェクト指向プログラミングが発展しても、本質的な複雑性が低減されるわけではない。
音声認識や画像認識に象徴される人工知能 技術からは、あまり収穫は得られない。
ソフトウェア開発についての困難は何を表現するかを決定することであり、表現することそれ自体ではない。
エキスパートシステム技術については、次の節で述べる。
多くのソフトウェア科学者が、エキスパートシステム 技術をソフトウェア開発環境に適用しようと努力している (デイビッド・パーナス ) 。
もしエキスパートシステム技術をエキスパートアドバイザーとして活用することができれば、ソフトウェア開発者の役に立つだろう。
エキスパートシステム技術では、知識ベース を構築することが困難であり、そのことが障害となっている。
知識ベースを構築するためには、専門家 (エキスパート) を確保する必要がある。しかし、これは簡単なことではない。
また、たとえ専門家を確保できたとしても、彼らの豊富な知識を知識ベースに登録するための効率的な方法を開発しなければならない。
自動プログラミング として言及されてきた技法は、つまるところ高水準プログラミング言語 を使ったプログラミング の婉曲的表現である (デイビッド・パーナス) 。
ビジュアルプログラミング を使って生産性を向上させることは難しい。
フローチャート は、ソフトウェアの構造を抽象的に表現するものとしては貧弱である。そのため、プログラマは、実際にはフローチャートを描いてからプログラミングをするのではなく、プログラミングしてからフローチャートを描いている。重要なソフトウェア構成図の詳細を表示するには、現在のディスプレイは範囲と解像度の点で力不足である。そのため、ハードウェア技術のさらなる進歩が必要である。
ソフトウェアは、基本的に複雑であり視覚化することが難しい。そのため、ソフトウェアの視覚化を試みても、特定の一つの視点による一面的な認識しか得られない。
プログラム検証 には労力がかかる。そのため、全ての開発対象を検証することはできず、一部の重要なプログラムを検証することしかできない。
また、たとえプログラムを検証したとしても、それは、プログラムが仕様書通りに実装されていることを証明するだけであり、仕様書にバグ がないことを証明するわけではない。
プログラム開発の本質の多くの部分は、仕様書のデバッグ である。
完全で一貫した仕様書に到達することは、非常に難しい作業である。
プログラミング環境とツール の整備については、既に大きな成果が出ており、今後のさらなる成果はあまり期待できない。
ワークステーション (プログラム開発のための作業用コンピュータ) の性能は、飛躍的に向上した。プログラムや文書の作成には、現在のワークステーションの性能で既に十分であり、ワークステーションの性能が現在以上に向上しても生産性に寄与する余地はない。
プログラムのコンパイル は、特にワークステーションの性能を必要とする作業だが、現在のワークステーションの性能でも、既にほとんど生産性の阻害要因とならない水準になっている。
以下のことを提案する。
購入できるものをあえて構築しないようにするために、市場を活用するべきである。
ソフトウェア 要件を確立するときには、開発循環計画の一部として、迅速なプロトタイピング を使用する。洗練された手法で丁寧に要件定義をしたり、顧客自身が要件を明確に認識していなかったりすることが多いため、迅速にプロトタイピングを行うことが有用である。
実行と使用とテスト が実施されるにつれて、ソフトウェアは、機能を増やしながら、有機的 (系統的) に成長する。
漸増的開発 を通して有機的に「育成されていく」ソフトウェアを支持する。まずメインプログラムを実装して、その後にサブプログラムを実装してゆくことを推奨する。
このような漸増的開発を採用することによって、開発のどの段階でもシステムが動作するので、プログラマ のやる気が出る。
漸増的開発を採用することによる恩恵は、大規模プロジェクトにおいても得られる (ベーム) 。
若い世代の素晴らしいコンセプトデザイナー (設計者) を発掘し、育てる。
プログラミング は、創造的な過程である。そのため、設計能力が非常に高い「偉大なデザイナー」と設計能力が平均的な「よいデザイナー」が存在する。よいデザイナーは、優れた練習法でソフトウェア設計 を学ぶ。こうした教育は、まったく理にかなったことである。
しかし、偉大なデザインは、偉大なデザイナーからしか生まれない。よいデザイナーは、偉大なデザインを生み出すことはできないのである。
ソフトウェア企業にとっては、偉大なデザイナーを発見し育成することに大きな労力を費すべきである。
偉大なデザイナーを偉大なマネージャと同等に処遇する。
偉大なデザイナーと偉大なマネージャに対して、給与だけでなく、高い地位に伴う全ての給付を同様に与える（広いオフィス、スタッフ支援、出張旅費など）。
ブルックス は、1986年に論文『銀の弾などない』を発表してから9年目にあたる1995年に、同論文を省察する『「銀の弾などない」再発射 ("No silver bullet" reloaded)』という論文を発表した。
『「銀の弾などない」再発射』の内容を抜粋・補足して説明する。
『銀の弾などない』で述べた、「銀の弾丸 」として魔法のようにすぐに役に立ちプログラマ の生産性を倍増させるような技術や実践 (特効薬) は、今後10年間 (論文が著された1986年の時点から10年の間) は現れないとの予測は、悲観的過ぎるとの指摘が多くブルックスのもとに寄せられた。
しかし1995年現在の時点で考えてみると、むしろこの予測は楽観的過ぎたようである。
プログラマの生産性向上は予測を下回っているようである。 なお、デービッド・ハレルは、1992年に論文『銀の弾丸をかみしめて』を発表して、『銀の弾などない』について慎重に分析を行った。
オブジェクト指向プログラミング の手法は成長が遅かった。
この理由には次のようなものが考えられる。
オブジェクト指向 のプログラマは、C++ で連結リスト やセット (集合 ) のような比較的低水準な抽象化 によるクラス を作る傾向があり、高水準な抽象化を行ってクラスを作ることは行ってこなかった。 (ジェームズ・コギンズの雑誌記事より)オブジェクト指向についてプログラマを教育するとき、オブジェクト指向を特定のツール/言語を使うことだと教えてしまうことが多かった。本来はオブジェクト指向は設計 (ソフトウェア設計 ) の一つの種類 (オブジェクト指向設計 ) だと教育し、設計の原則を与えるべきであった。プログラマは設計の原則を学ばずに単にオブジェクト指向言語を使うだけであったため、恩恵は少なかった。恩恵が少ないのでは普及しないのは当然である。 (デイビッド・パーナス からブルックスに宛てられた手紙の内容より)
オブジェクト指向 の技法は厳しい状況にある。
プログラマにまったく新しい思考法 (オブジェクト指向の考え方) で考えるよう再教育しなければならないなど、事前に多額の投資が必要であり、さらに効果が目に見える形で現れるまで時間がかかる。
「オブジェクト指向テクニックは、最初や二度目のプロジェクト開発を速めるのではない。そのファミリーで五度目にあたるものなら、猛烈に速く進むことだろう」(ジェームズ・コギンズ)
とはいえ、多くの組織でC++ をC の代わりに採用する動きがあり、ゆっくりとではあるが着実に情況は前に向けて進んでいるようである。
再利用可能なプログラムコード の開発には、1回限りのプログラムコードの開発と比べて、2倍、3倍の労力がかかる。再利用可能なプログラムコードの開発には、優れた設計と優秀な文書 の両方が必要である (デイビッド・パーナス) 。
再利用可能なプログラムコードを利用するためには、そのプログラムコードについて学習する必要がある。
プログラムコードの再利用 は、企業内では特に大規模な企業において精力的に行われている傾向がある (ケーパーズ・ジョーンズ) 。市場では再利用可能なプログラムコードがいくつか流通している (ケーパーズ・ジョーンズ) 。
見解は変わらない。
銀の弾などない。
魔法 のようにすぐに役に立つ解決策（特効薬）は、身近にはない。ソフトウェア開発 の専門家にとっては、革命的改善をただ待ったり、期待するのではなく、発展的改善を検証する時が来た。(フレデリック・ブルックス、デイビッド・パーナス、R・L・グラス)
Brooks, Fred P. (1986). “No Silver Bullet — Essence and Accident in Software Engineering”. Proceedings of the IFIP Tenth World Computing Conference : 1069–1076. Brooks, Fred P. (April 1987). “No Silver Bullet — Essence and Accidents of Software Engineering”. IEEE Computer 20 (4): 10–19. Brooks, Fred P. (1975). The Mythical Man-Month ISBN 0-201-00650-2 Brooks, Fred P. (1995). “Chap. 16”. "No Silver Bullet — Essence and Accident" (Anniversary Edition with four new chapters ed.). Addison-Wesley. ISBN 0-201-83595-9 Brooks, Fred P. (1995). “Chap. 17”. "'No Silver Bullet' Refired" (Anniversary Edition with four new chapters ed.). Addison-Wesley. ISBN 0-201-83595-9 『人月の神話 狼人間を撃つ銀の弾はない (20周年記念増訂版、新装版)』ピアソン・エデュケーション、2002年。ISBN 978-4-89471-665-0 。 第16章 銀の弾 などない——ソフトウェアエンジニアリングの本質と偶有的事項
第17章 「銀の弾などない」再発射
