銀の弾などない

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内検索

銀の弾などない— ソフトウェアエンジニアリングの本質と偶有的事項』(ぎんのたまなどない ソフトウェアエンジニアリングのほんしつとぐうゆうてきじこう、: No Silver Bullet - essence and accidents of software engineering)は、フレデリック・ブルックス1986年に著したソフトウェア工学の広く知られた論文である。原論文は英語である。日本語では『銀の弾丸はない』と訳されることもある。ブルックスは、「銀の弾丸」(Silver Bullet)として魔法のようにすぐに役に立ちプログラマの生産性を倍増させるような技術や実践 (特効薬) は、今後10年間 (論文が著された1986年の時点から10年の間) は現れないだろうと主張した。

銀の弾とは、で作られた弾丸であり、西洋の信仰において狼人間、悪魔を撃退する際に用いるものとされていた。

ブルックスの警句は、非常に多く引用されており、生産性、品質、制御に対してあてはめられている。ブルックスは、自身の警句で述べているプログラマの生産性の限界は「本質的な複雑性」(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のような高水準プログラミング言語である。 高水準プログラミング言語は、データ型データ構造、操作などのような高水準な概念でプログラミングできる環境を提供し、プログラマは低水準な複雑性を考えずにすむようになった。

タイムシェアリングシステム[編集]

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

統一されたプログラミング環境[編集]

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

銀の弾の候補[編集]

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

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

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

オブジェクト指向プログラミング[編集]

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

人工知能[編集]

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

エキスパートシステム[編集]

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

「自動」プログラミング[編集]

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

ビジュアルプログラミング[編集]

ビジュアルプログラミングの技法を使うことによる生産性の向上を達成することは難しい。

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

プログラム検証[編集]

プログラム検証の技法は、労力がかかるため開発の対象となる全てのプログラムで行うことはできず、重要な少数のプログラムに適用できるのみである。 プログラム検証を行った場合でも、それは仕様書を正しく実装していることが証明されるということであり、仕様書のバグ (誤り・欠陥) には対処できない。 プログラム開発の本質の多くの部分は仕様書のデバッグ (誤り・欠陥の修正) である。 完全で一貫した仕様書に到達することは非常に難しい作業である。

環境とツール[編集]

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

ワークステーション[編集]

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

提案[編集]

以下のことを提案する。

ソフトウェア製品の大市場の利用[編集]

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

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

ソフトウェア要件の確立に際し、開発循環計画の一部として、迅速なプロトタイピングを使用すること。

  • 洗練された手法で丁寧に要件定義を行うことと、また顧客自身が要件を明確に認識していないことが多いため迅速なプロトタイピングを行うことが、有用である。

漸増的開発[編集]

実行と使用とテストが行われるにつれて、より多くの機能をシステムに追加しながら、ソフトウェアを有機的 (系統的) に成長させること。

  • 漸増的開発をとおして有機的に「育成されていく」ソフトウェアを支持する。
  • まず最初にメインプログラムを実装して、その後にサブプログラムを順次に実装してゆくことを、勧める。
  • このような漸増的開発を採用することにより、開発の全ての段階において動作するシステムがもたらされ、それゆえプログラマのやる気を促す。
  • 漸増的開発を採用することによる恩恵は、大規模プロジェクトにおいても得られる (ベーム) 。

偉大なデザイナー[編集]

若い世代の素晴らしいコンセプトデザイナー (設計者) を発掘し、育てること。

  • 良いデザイナーと「偉大な」デザイナーとの間に違いが存在する。
  • プログラミングは創造的な過程であるため、設計能力が非常に高い偉大なデザイナーと設計能力が平均的なデザイナー (良いデザイナー) とがいる、と仮定する。
  • 良いデザイナーは、技術者を優れた練習法でデザイン (ソフトウェア設計) を教えることにより育成することができる。こうした技術者の教育はまったく理にかなったことであり、賛成する。
  • しかし偉大なデザインは、偉大なデザイナーから生まれる。良いデザイナーは、偉大なデザインを生み出すことはできない。
  • ソフトウェア企業にとっては、偉大なデザイナーを発見し育成することに大きな労力を費すことが、重要である。
  • 偉大なデザイナーを偉大なマネージャと同等に処遇することを勧める。
  • 偉大なデザイナーと偉大なマネージャとに、同等の給与を与えるだけでなく、高い地位に伴う全ての給付を与えることを、提言する (広いオフィス、スタッフ支援、出張旅費など) 。

その他[編集]

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

「銀の弾などない」再発射[編集]

ブルックスは、1986年に論文『銀の弾などない』を発表してから9年目にあたる1995年に、同論文を省察する『「銀の弾などない」再発射』という論文を発表した。

『「銀の弾などない」再発射』の内容を抜粋・補足して説明する。

『銀の弾などない』で述べた、「銀の弾丸」として魔法のようにすぐに役に立ちプログラマの生産性を倍増させるような技術や実践 (特効薬) は、今後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. Addison-Wesley. 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. 
  • フレデリック・P・ブルックス Jr.・滝沢徹 (訳) 、牧野祐子 (訳) 、宮澤昇 (訳) 『人月の神話 狼人間を撃つ銀の弾はない (20周年記念増訂版、新装版)』 ピアソン・エデュケーション、2002年ISBN 978-4-89471-665-0
      • 第16章 銀の弾などない——ソフトウェアエンジニアリングの本質と偶有的事項
      • 第17章 「銀の弾などない」再発射

外部リンク[編集]