『Mythical Man-Month（人月の神話）』で、著者Fred Brooks氏が『No Silver Bullet: Essence and Accidents of Software Engineering(PDF)（銀の弾などない: ソフトウェアエンジニアリングの本質と偶有的事項）』という論文を発表してから20年以上が経ちました。原論文で、Fred Brooks氏は、ソフトウェア開発において生産性を10倍向上させるような革新（銀の弾のような特効薬）は、今後10年間は現れないだろうと主張しました。Brooks氏は、ソフトウェア開発の複雑性を、本質的な複雑性と偶有的な複雑性の2つに区別しています。ソフトウェア開発の本質的な複雑性は、仕様、設計（ソフトウェアへの仕様のマッピング）、テスト（設計がビジネスニーズを適切に満たしているか）に関連します。偶有的な複雑性は、実装（言語、ランタイム、ツール、プログラミング手法）にかかわる困難さに関係します。論文で、Brooks氏は、（当時の）偶有的な複雑性への対処を試みたさまざまな革新がどうして銀の弾（特効薬）になりえないのかを説明し、10倍近くの生産性の向上をもたらすかもしれない唯一のものは、要件の取りまとめの改善、迅速なプロトタイピング、優れた設計技能の育成などの、本質的な複雑性に対処するものであると結論を出しました。
昨年（2007）のOOPSLAカンファレンス(リンク)において、銀の弾などない（No Silver Bullet）に関する回顧的パネルディスカッション(リンク)が行われました。これには、Fred Brooks氏(リンク)自身のほか、Martin Fowler氏（後で狼人間として現れて聴衆を驚かせた）、Ricardo Lopez氏、Aki Namioka氏、Linda Northrop氏(リンク)、David Lorge Parnas氏(リンク)、Dave Thomas氏、そしてパネル指揮者としてSteven Fraser氏が参加しました。このパネルディスカッションでは、ソフトウェア開発における銀の弾（特効薬）は存在しないというBrooks氏の前提を振り返って検討しました。InfoQは、パネルディスカッションに出席し、以来、この重要な議論をコミュニティに持ち込むように大いに働きかけました。以下は、パネルディスカッションからの重要な抜粋を含め、許可を得て公開した編集済みの要約です。
Steven Fraser氏は、論文が20年前に最初に公開されたときにそれを読んだかどうか主席者に尋ねることでパネルディスカッションを開始しました。出席者の四分の三が挙手しました。Steven氏は次のように聴衆に言いました。「この論文は、私の博士論文発表日に公開されたのを覚えています。私の論文指導担当者は、Fred氏の考えと異なることを言わなくてよかった、と言いました。」その後Steven氏は、各パネリストを紹介し、当時カリフォルニアを襲った恐るべき山火事から避難していたRicardo氏とその家族にお見舞いの言葉を述べました。次にSteven氏は、ここ20年間における銀の弾（特効薬）に関する意見について話す時間を各パネリストに与えました。Fred Brooks氏は当初の考えを概括することから始めました。
私は、ソフトウェア開発の困難さを、アリストテレスに従って、本質と偶有的事項に分けることができると主張します。本質は、実現は別とした、ソフトウェア自体の概念構造です。偶有的事項は（アリストテレスの言葉を使って、incidences（出現）と表現しても構いませんが）、概念構造で引き起こされないが、概念構造を実行可能な形式で実現するプロセスの一面または別の側面によって引き起こされる困難さです
そして私は、数学的命題は、挑戦することが非常に困難なものであると主張します。つまり、1986年に9/10未満の問題が偶有的事項である場合、すべての偶有的事項をゼロに減らしても10倍の向上は達成されないでしょう。したがって、銀の弾が存在するならば?この銀の弾とは、狼人間を倒す際に用いるものですが、私がこの言葉を選んだ理由は、多くのプロジェクトが一見無害かつ単純にスタートするが、闇夜にモンスターに変身するからです（そして皆様はそのようなプロジェクトを行っている可能性があり、私もあります）。したがって、生産性を10倍向上させるものが存在するならば、それは固有の概念的な複雑性に対処するものであるはずであり、違う次元で概念に対処することを意味するかもしれません。
そこで、反対論が存在します。現在、反対論はいくつかの見地から問題にできます。まず、事態を概念構造やその他のものにきちんと分割できるという仮定に異議を唱えることです。つぎに、「残りの問題の9/10以上が偶有的事項であると信じている」と言うことですが、私は今までに誰かにそう断言させたことは一度もありません。しかし、私はその意見がかなり問題であると断言しました。そして最後は、数学が間違っていると言うことです。私はこれが実にばかげたことだと断言します。数学は間違っていませんし、お気付きでしょうが皆様はいくつかの形でそれを目にしています。
論文の残り部分で、狼人間を仕留めるための銀の弾の候補となっているさまざまな技術を取り上げ、それらがなぜ本質ではなく偶有的事項に対処しているように思えるのか説明することを約束します。
さらに私は大胆な発言もしています。それは、生産性を10倍に向上させるような技術やその他の特効薬は、今後10年間（1986年から1996年の間）は現れないだろう、ということです。
大量の論文が公表され、「そうです、銀の弾があります。これです、これは私のものです!」と発表されました。96年になって私は『The Mythical Man-Month（人月の神話）』の新版を執筆し、その中の章で、ソフトウェア工学における10倍の生産性の向上はまだ達成されていないと記しました。私は、以降1つでも行った手法があったかどうかと疑います。あるとすれば、私は、実際のところ、それがオブジェクト指向プログラミングであると推測します。
次のパネリストはDave Parnas氏でした。彼は、「情報隠蔽（hiding information）」条件に基づいてモジュールでシステムを設計することに関する処女作を執筆しました。また、ソフトウェア工学を工学専門分野（土木工学、機械工学など）として扱う（および認可する）ことの強力な支持者であり続けています。
Dave氏はソフトウェアの銀の弾などないことをすぐに宣言し、この問題が20年経過してもなお話題になる理由を説明しました。Dave氏は3つの理由を挙げました。
- 人々には「難しい質問に対する簡単な答えを探そうとするごく自然な傾向があり、ソフトウェアの設計は困難なことで、今後もずっと困難であり続けるでしょう。」
- 新しい技術はたいてい過剰宣伝されます: 「そうしないと人々が聞く耳を持たないため、その技術を銀の弾（特効薬）であるかのように仕立て上げる必要があります。」
- 人々が「実際に仕事を覚えること」よりも優れたツールを求める欲望。Dave氏は比喩を用いて次のように言いました: 「‘下手な職人は道具のせいにする（the poor workman blames his tools）’という古いことわざがあります - 人々が下手な職人であり、私はほとんどのプログラマが下手な職人であると思います。」 さらにDave氏は、人々は仕事を覚えることを避けるために銀の弾（特効薬）を探しているのだと言いました。
Dave氏は、我々の進歩の大半はハードウェアによるものではなく、ソフトウェア工学において多くの進展が見られたという考えに異議を唱えました。Dave Parnas氏は次のように結論を出しました: 「私が鉛弾と呼んでいる、規律があって勤勉な昔からの一般的な弾に相当するものがいくつかあります。それらを使用するためには多くのトレーニングが必要ですが、それをしていません。私の本当の疑問は、なぜ鉛弾を使用しないかということです。」
Linda Northrop氏は、Fred氏の論文を称賛し、学んだ重要なポイントについて次のように話しました: 「ソフトウェア工学はプログラミング以外も関係しています…ソフトウェア開発で最も困難なことは、どのように言うかではなく、何を言うかを理解することです。」Linda氏は、銀の弾などないということに同意し、自身のチームが本質的な複雑性に重点的に取り組んだとき、「結果は息をのむようなものであった」と賛同しました。
Linda氏は、Simula（最初のOO言語）はモデリングに関するものであったと言い、Kristen Nygaard氏(リンク)（オブジェクト指向のオリエンテーションの共同創始者）の言葉を引用しました。2001年にNygaard氏は（Linda氏の解釈で）「我々は本質を見失っていた、我々はモデリングについて考えていなかった、我々は皆、言語やつまらない飾り物や余分なものに胸を躍らせていた」と言いました。「彼の考えでは、それがオブジェクト指向の本質とは何も関係がなかった」と、Linda氏は言い足しました。
Linda氏は次のように結論を出しました。
開発者と我々が抱えているもの（ユーザーと呼ぶのは不適切だと重います）の間の境界、および偶然の革新は、ほとんど役に立ちません。これからの狼人間と闘うためには、優れた設計者が必要ですが、まだあまりにも少なすぎるので、今後も勤勉の雰囲気を高めるだけでなく、コーディングの世界から居心地悪く我々を連れ出す学際的展望を培う必要があります。我々の世界は、今朝の基調講演からフレーズを借りるならば、「技術推進（technology push）」です。技術推進を行う理由は、対処しようとしている相手のニーズを理解するためにきつい仕事をしないからだと思います。
次は、Cisco systemsのAki Namioka氏でした。Namioka氏は、ますます多くの人々がプログラマにならずに便利なアプリケーション（Webサイトなど）を作成できるようになっているため、この数年で大きな進展が見られたと示唆しました。「我々は実際、高度な技術を持つエンジニアだけでなく多くの人が作り出したものをプログラミングしたツールを作成しました…」。
IBM Visual Age for SmalltalkおよびEclipse IDEの影の重要人物であるDave Thomas氏は、Brooks氏の論文を、しきりに生産性に対処しようとする我々にとっての課題であると表現しました。しかしながら、Dave氏は、今日のソフトウェア開発（特にミドルウェア）の状態を、未熟なソフトウェアがもたらされるだけでなく、平均的なソフトウェアチームが遅れをとらずについていくことを困難にするような、APIとフレームワークのあまりにも急速な変化による、いわれのない災難であると言いました。Dave氏は、今日の企業システムの大半が基本的にただのCRUDアプリケーションであると主張しました: 「結局こうした人々は、極めて単純なことを行おうとしています。もし4GL（第4世代言語）を使用してメインフレームに取り組んでいたら、実際に問題を片付けていたでしょう。」
Dave Thomas氏は、能力よりも証明書を気に掛けている今日の大学について、「我々は無能力さを証明している」と、自身の気持ちを表現したがりました。Dave氏は、新卒者が幅広いコンピュータの多様性について教わっていないことを嘆き、「… そのため新たな言語が生み出されると、知識の乏しい人間は、こうしたことを理解できる共通概念の基本セットがないために、くどくど言い続ける」と述べました。
Dave Thomas氏は、工学と製造からの教訓は、アジャイルプラクティスよりもはるかに、大規模プロジェクトに役立つものであると主張しました。しかし、Dave氏は、テストの実施が重要であるという今日の開発者の考えを「飛躍的進歩」であると言いました。
Dave Thomas氏は、航空会社の予約とヘッジファンドにおける非常に特殊な領域特化型の特殊な言語アプリケーションを挙げて、特定分野で「真の成功」を目にしたと締めくくりました。しかしながら、Dave氏は、必要とされる開発者スキルは「極めて高く」、「大衆に広めることは不可能である」と警告しました。
次に出番となったRicardo Lopez氏は、人類の歴史における2つの定数、「恐怖」と「最適化して改善する必要性」を位置付けて、スピリチュアルな論述を行いました。Ricardo氏は、このコンテキストにおいて恐怖を狼人間への恐怖として位置付けました。狼人間は、ソフトウェア障害の擬人化です。Ricardo氏は、銀の弾があり、それは次の2箇所からもたらされる可能性があると主張しました。
- 「取り囲む複雑性から逃げるのではなく、踏み込んでみましょう。なぜなら、私の経験では、障害への恐怖のため複雑性を回避しようとする試みが、実際は、障害を保証する偶有的な複雑性を増加させているからです。
- 「あなたが、自身の中の素晴らしさを追究し、自らのもの、かつプロになるために努力しようとするときはいつでも、それを同僚と共有した場合、あなたが銀の弾なのです。あなたは、自身が行うどんなことにおいても大きな改善を得るために必要なものです。」
Ricardo氏は自信に満ちたメッセージを続けました。
あなたは自分自身を向上させ、自分の周りの人を気に掛けたり個人およびプロとしての成長を気に掛けたりすることで彼らを躍進させようと考えたときに、チームの生産力の向上は見られていないのではないですか? 全体のコラボレーション術は、あなたが直面していることの共有経験を具現化することです。これは本当に10倍の向上をもたらします。
Ricardo氏は、「あなたが探している銀の弾は自分の中に存在する」と締めくくりました。Ricardo氏は、自らの例を示して、パネルディスカッション時に起こっていたカリフォルニアの山火事で失われなかった人命の数について100年前と比べ、それが次のことを証明していると指摘しました: 「文明として、我々はなし得ることにおいて数桁の向上を実現してきました。なぜなら、我々自身が銀の弾だからです。」
Martin Fowler氏は、パネリストの列の最後にいました。Martin氏は、自身の人生でBrooks氏の論文がいかに重要で大きな影響を及ぼしたかを話すことから始めました。突然、Martin氏は自分の首をつかみながらこらえ切れない様子で金切り声を出し始め、テーブル裏の見えないところに倒れこみました。私は、ラップトップを横に投げて急いで立ち上がり、助けに行こうとすると突然、Martin氏はとても恐ろしい狼人間のマスクを被って再登場したのです。狼人間はソフトウェアプロジェクトにおける障害の擬人化であり、Brooks氏が論文の始めにそう説明していたからでした。次の抜粋は、十分理解できるよう抜粋できないため、下記は、Martin氏の完全な導入部のスピーチです。
私は、なぜ効果的に生き残ったかについていくつかの意見を述べたいと思います。オブジェクト指向が非常に危険で邪悪なアイデアであるという点でBrooks氏に同意しますが、私はそれを大した困難もなく克服できました。確かに、オブジェクト指向には多くの良いアイデアがありますが、素晴らしい点は、誰もそれを実行していないということです。
OOPSLAで、確かに、オブジェクトの話は多くありますが、あなた方は外界に出ています。誰も実際にそれを行っていません! 言語は使用していますが、アイデアについてまったく分かっていません。オブジェクトで成功したと思っているかもしれませんが、その前に私を倒しに行くための長い道のりがあります。
そして私は他の武器を自由に使えます! 私は、マルチコアの同時システムが大好きです。あなた方はスレッド問題と競合条件にとても苦しむことになり、私は今後数年間大いに楽しむでしょう。
これらはもちろん偶有的事項の一部であり、私にとってそれほど危険ではありません。実際の問題は本質を攻撃するものであり、それでも私は生き残ることができました。
最も危険なことの1つは間違いなく、構築することよりも購入すること、つまりあらかじめ構築されたコンポーネントと構造を使用することです。これは優れた理論ですが、重大な弱点が1つあります。ライブラリがいくらか役に立つ場合にしか助けにならないことです。そして私は、人々に非常に粗末なライブラリを構築させることが非常に得意です。
概念的な本質に対する別の重要な攻撃は、優れた設計者を育てることです。私は、これが最も有力な攻撃の1つであるという点で昔の友人に同意します。困ったことに、ここにいる多くの方がそれを理解しています。しかし、幸い、ここの外部の人は誰もそれを理解していません。
人々は、ソフトウェアが実行しやすいことを望み、ソフトウェアが些細であることを望み、そして、これを奨励する準備ができている多くの人々がいます。その結果、彼らはソフトウェア開発を真剣に受け止めず、ソフトウェア開発の不可視性がさらにそれを手助けしています。ソフトウェア開発が実際はいかに困難であるかを人々が理解していないからであり、その判断の誤りが意味することは、人々が優れた設計者を十分に評価しないということです。
課題は、優れた設計者が必要だと自分に言いきかせることではありません。なぜなら、あなた方はすでにそれを知っているからです。課題は、より広範な人々に対してその可視性を高めることであり、今までのところ、そのことについてあなた方は完全に哀れな状態です。
次に、最後のポイントは、概念的な本質に対するFred Brooks氏の攻撃の残り2つの部分についてですが、私はある程度一緒に組み合わせます。それはすべて、人々がソフトウェアの構築に取り組む方法に関係があります: プロセスおよび迅速なプロトタイピングと追加開発に対する奨励です。
ここ30年間で私にとって大変驚きであったことの1つは、私がウォーターフォールを崇拝するようになったことです。顕著なことに、あなた方人間は、プロジェクトの開始時にほとんど情報を持たずに、何が起こるかを正確に計画し、コストを特定し、非現実的なあらゆる計画に献身できると考えているようです。そして、あなた方は、なぜ私がいつも姿を現すことができるのだろうと思っていることでしょう。コントロールしているという錯覚、データに基づかずにこうした壮大な予測をさせることができるという考え、その愚の骨頂が私の最大の強みの1つです。これはもちろん、鉛弾でも結局私を傷つけることができない理由です。
私を助ける最大のことの1つは、銀の弾に対する強い願望です。人々は、銀の弾を作ろうと多大な時間を費やし、さらに、銀の弾を売ろうと多大な時間を費やして、自ら一層仕事を増やしています。銀の弾の提供者は、私の大きな味方です。ありがとうございます。
Amir Kirsh氏による画像(リンク)
パネル指揮者のSteven Fraser氏は、聴衆からの質問を受け付けました。
聴衆から最初に口火を切ったのは、Bertrand Meyer氏でした。Bertrand氏は、自身の経験によると、多くの人（特にマネージャー）はOOPなどの80年代と90年代の新しいアイデアを受け入れず、実際彼らは古い人間であり、受け入れない理由は、提案された新技術を信じておらず開発に重大な影響を与えると思っているからであり、その根拠として「銀の弾などない」の論文を利用しているという事実を言及しました。
Fred氏はそれに対し、偶有的な困難さに対処するどんな技術進歩も、2～3倍の生産力の向上をもたらしたとしても、実際の問題を解決していないということを再び断言することで答えました。
Linda氏は、銀の弾を売りたがっているマーケターが、我々の実際のニーズに対するソリューションを提供しない限り、彼らには興味ないと言いました。そして、彼女はRicardo氏が前に発言したことに異議を唱えました。
彼は銀の弾の理由について話したとき、我々が銀の弾を持っていることについて、すべて崇高な理由を挙げたように思えました。我々には複雑性への恐怖があること、そして我々は生産性を向上させたいと願っていて、複雑性の非常に恐ろしい本質が我々に恐怖心を抱かせているということです。私の考えでは、銀の弾を吹聴する卑しい理由が存在すると思い、それは強欲だと思います。
John Roberts氏（Qualcomm）は、あらゆる組織から最も優れた開発者を集めて作ったチームは銀の弾もしくは災害のためのレシピになり得るかどうかを尋ねました。
Ricardo氏は、銀の弾が手に入ることを約束せずに、チームを優れた人間で構成するというアイデアを支持しました。
共にベストを得ることが非常に重要です。なぜなら、彼らはあなたを前進させ、より本質的な複雑性に取り組み、その恐怖にとらわれないために言わば偶有的に非本質的な複雑性をもたらしている唯一の人間ではないからです。また、あなたは他の人に学習の機会を与えており、それが、我々が互いを活用するきっかけであり、文明が今日あなたと私が知っているものになるきっかけです。
同じトピックについて、Dave Thomas氏が言い足しました。
あなたがお若くて、良くなる方法を見つけたいなら、自分が働くことができる、真に実力のある人々を探してください。それには、あなたが共に働くことができるエグゼクティブ（幹部社員）も含まれます。あなたは、より優れた人から学ぶことができます。
Dave Parnas氏は、前の質問のテーマについて、2～3日間のトレーニングコースをあなたに販売したがっている人は、実際は銀の弾を販売していて、それに興味を持っている買い手を見つける必要があると、彼が興味を持っていなかったと推論して言いました。実際、鉛弾は教育であり、それには多くの学習とトレーニング時間がかかります。
狼人間は自分を抑えることはできませんでしたが、にやりと笑いました。
はい、優れた人々がチームで一緒に協働できないこの考えは、私にとって非常に有益です。彼らは十分でないため、あなた方は決して優れた人々と協力できない、と言うことによって私は疑念を植え付けることができます。当然これは、優れた人々と協力するのを妨げます。優れた人々と協力しようとしないなら、あなたは決して成功しないでしょう。したがって、それが私にとって簡単に進めるルートです。
次に、優れた人々を実際に協働させることの難しさについて話します。その難しさは、人々が協力して働けるように十分に努力しないため、功を奏しています。彼らは、我々人間が、互いに仲良くすることがどれほど必要なことで、協働するチームを実際に持つことがいかに効果的かを理解していません。ここでも人々は簡単で単純なものを望んでおり、もちろん、私は常に重いプロセスを利用できます。これは非常に良い手法で、再び新しいことに関する疑問に結びつきます。
例としてアジャイルコミュニティを挙げると、非常にかわいいことに、彼らは重いプロセスを排除する方法についてあれこれと話し、グループ全体がアジャイルとは何かをあまり理解していないということを忘れています。彼らは意味論ではなく構文に焦点を合わせており、アジャイルコミュニティが行っているすべてのことを全面的に弱体化しています。私にとって、それは非常に満足できます。
The RefactoryからのOOPSLAパネル議長であるJoe Yoder氏は、優れた人々、優れた設計、コラボレーション、進行する要件がすべて一緒になっても、望ましい銀の弾にならないかもしれないが、狼人間を撃退する助けとなり、そのうちソフトウェアが実現する可能性がある、と言い足しました。
Dave Thomas氏は、人と手法の適切な組み合わせを持つということについてJoe氏に賛同しましたが、自身の経験を基に、優れた組み合わせには偶然遭遇しており、それを必要なときに必要なところで作り出すことができるように繰り返し行う方法について分かっていない、と付け加えました。
Fred氏は、リーダーシップと偉大なチームを育てることを興味がある人向けに『Peopleware and The Carolina Way』という本を読むことを勧めました。
Linda氏は管理と指導の違いに関して話しました。また、キャラクタとリーダーシップを基に、コーチが行うように指導することを強く要求しました。
狼人間は聴衆をどっと笑わせました。
人間（peopleware）は世の中で最も危険な本の1つです。幸い、チームを管理することと、人々の相互関係に焦点を合わせることはハードな仕事です。手持ちぶさたでMicrosoftプロジェクトを楽しむほうがはるかに楽です。誰かがPERTチャートやガントチャートを作成するたびに、私は追加の子猫を手に入れて食べます。
パネリストは、10倍の向上が実現したかどうかを確認するために、どのように生産性を測定できるかと尋ねられました。狼人間はすぐにあざ笑いました。
これは言うまでもなく私の思いのままである最大のことの1つです。あなた方は生産物を測定できませんし、生産性も測定できません。ある手法が別の手法よりも優れているかどうかを特定する賢明な実験を行う方法もありません。…時に私には簡単過ぎることもあります。
Ricardo氏は狼人間に賛同し、生産性の測定に利用した方法をいくつか扱ったが、その実行は非常に困難であったと締めくくりました。
Dave Parnas氏も、生産性の測定について同じ意見を支持し、次の例を挙げました: 「同じ問題を2人の人に与えて、その1人が2日間で2000コード行を生成する仕事を行い、もう1人が3日間で500コード行を生成する仕事を行う場合、特にそのコードを維持しなければならない場合は、あなたはどちらを望みますか?」
我々は、開発者が偶有的事項ではなく本質に焦点を合わせることができるような適切な開発環境をいつ期待することができるのか、と聴衆の誰かが尋ねました。
狼人間は、それを食い止めるために自分がすることを分かっていました。
ソフトウェア開発における最大の困難さは、ソフトウェアを記述する側の人とソフトウェアを記述される側の人の間のコミュニケーションです。概念的な攻撃、本質の問題は、そのコミュニケーションの向上を図ることにかなり焦点を合わせることです。それを行う手間が、そのコミュニケーションの流れを悪くしていることです。ビジネスの人間の中には、ソフトウェアの人間と話したがらない者がいて、幸いなことに、ソフトウェアの人間は社会的交流のこととなると絶望的になり、ビジネスの人間と話すことができません。
プロジェクトで行う重要なことは、ビジネスの人間と開発者の間にできるだけ多くの障壁を作ることです: コミュニケーションを阻止するようにして、彼らに文書で話し合うようにさせて、異なる部門に配属してください。その後起こることは（この兆候の1つが私にとって非常に都合の良いことだと思います）、ソフトウェアの人間はフラストレーションを感じて、まずビジネスの問題について興味を失い、その場合、私が本当に勝ったということです。そして、彼らはビジネスの問題に焦点を当てることができないと感じるため事態をいっそう悪くし、自分たちが知っていること、つまりインフラストラクチャ系に焦点を合わせ始めます。そして、彼らは、他に実行することを考えることができないため、精巧なインフラストラクチャを構築します。
Brian Foote氏（Industrial Logic）は、世界が「悪いコード」に捕らわれていると断言し、なぜ悪いコードの記述に対してより効果的になろうとせず、悪いコードをより良くしようとしないのかと問いました。
Ricardo氏は、いつもの口調で、人類は何かを完全に成し遂げたことは一度もなく、短所を受け入れることを学び、それと同じことがソフトウェアにも言えると言及しました。我々は、激変的なコードを排除し、かなり受け入れられている悪いコードの記述を回避しようとする必要があります。
Dave Parnas氏はその問題に対して異なるアプローチをとりました。
開発者にとって良いことは、恐らく世界にとっては良くありません。私は、誰も修正できないくらい複雑なものを記述することによって自社や部署で天才だと評判になっている実に多くの人を知っています。我々はそこから逃れなくてはならないと思います。それによって、ソフトウェア業界においていくらかの失業が生じる可能性があることを私は承知しており、それを歓迎するでしょう。
聴衆の別のリスナーは、OOP革命を終えるために我々にできることがあるかどうかと尋ねました。
Dave Parnas氏は、後ほど行うプレゼンテーションでそのような具体的な質問に対処するつもりである、とすぐに返答しましたが、「あなたはその答えが気に入らないと思いますよ。」と言い足しました。
Fred氏は、「多くのアプリケーションに役立つシステムを作る最良の方法は、本当に役立つシステムを作ってからそれを一般化することです。」と言いました。
Dave Thomas氏はソフトウェアのフレームワークを攻撃しました。
ソフトウェアコンポーネントを手に入れる最良の方法は、人々がソフトウェアのフレームワークの構築を止めることです。そこで彼らはフレームワークの複雑性とあらゆるカプセル化違反によって原料を漏出しています。我々が犯した大きな間違いの1つは、フレームワークを構築して出荷することを人々に奨励していることだと思います。フレームワークは未完成で専門的に磨かれていないものを出荷する最良の方法です。
セッションが終わりに近づき、Steven氏は先程と逆の順序でパネリストに締めくくりの言葉を要請したため、最初に狼人間が話を始めました。
ソフトウェア開発がここ20年間ですばらしい発展をしたのは事実ですが、正直なところ、あなた方が成し遂げた大きな進歩によって私は被害を受けていません。なぜなら私の本質が予想外の外見にあるからです。… 人間はソフトウェアのこととなると素晴らしく楽観的であるため、それがいつも簡単になると思っています。生産性が向上したとしても、自分たちの能力を過大評価しており、それが私の強みになります。あなた方は実世界を見ることができず、それは私の最大の強みです。
Ricardo氏は、複雑性に取り組む能力について楽観的でした。
我々は、何世代にもわたって、時代と共に増加する複雑性を受け入れてきました。今後も引き続きそうするでしょう。狼人間は、より大きくより醜くなるでしょうが、いずれ死ぬでしょう。
Dave Thomas氏は、結論づけられた「大課題」を提供したFred氏に感謝し、次のように締めくくりました: 「目標を持つことは重要であり、ビジョンを持つことは重要です。旅をしているなら、達成していないことはそれほど問題ではありません。」
Aki氏は、銀の弾の探求が、毎日人々が使用しているソフトウェアシステムの作成に我々を導いたと指摘しました。
Linda氏は、Brooks博士とParnas博士と共に同じパネルディスカッションに参加できたことについて感謝の意を表し、自身が人生から学んだ1つの重要な教訓を共有しました: 「偶有的事項ではなく本質に焦点を合わせること。」です。
Dave Parnas氏は、ウォータフォールのソフトウェア開発プロセスが不当に避難されていると明確な態度で擁護しました。また、Dave氏は、よりシンプルなシステムを支持して、複雑なものが我々の問題の最良のソリューションではないということを暗に伝えました。最後に、我々は難しい質問に対する簡単な答えを探すべきではないと言いました。
Fred氏は、次のように意見を述べました: 「私は、人々が互いの仕事についてほとんど研究せず、先例についてほとんど研究せず、伝統的なモデルについてほとんど研究しない工学の分野を知りません。それは非常に危険なことだと思います。」
Steven Fraser氏は次のように宣言してセッションを終了しました: 「銀の弾など存在しません!」
OOPSLAについて
OOPSLA(リンク)は、もともとオブジェクト指向プログラミングをテーマとした会議でしたが、その範囲は、プログラマの生産性、セキュリティと信頼性、超大規模なシステムや進化するハードウェアプラットフォームなど、現在のソフトウェア課題に対処するプログラミング、プラクティス、パラダイムにまで広がっています。OOPSLAでは、研究と業界から最新情報を得たり、ワークショップに参加したり、実践のチュートリアルでスキルを磨いたり、その他セッションに参加することができ、創造的かつ面白い方法で知性を養います。
原文はこちらです：http://www.infoq.com/articles/No-Silver-Bullet-Summary
（このArticleは2008年10月21日に原文が掲載されました）