銀の弾などない

2014年12月13日2023年7月19日

「銀の弾などない」や、「ブルックスの法則：遅れているソフトウェアプロジェクトへの要員追加は、さらに遅らせるだけである」、あるいは「人月の神話：人と月とが相互に交換可能だという誤った認識」は、大抵のプログラマーやＳＥが一度は聞いたことのあるＩＴ業界（ソフトウェア開発）の箴言（警句）である。この箴言は、フレデリック・Ｐ・ブルックス，Ｊｒ著「人月の神話ー狼人間を撃つ銀の弾などない」に登場する。 あまりにも有名な箴言であるが、恥ずかしながら今までこの本をまともに読んだことはなかった。先日、古本が手に入り本書を読む機会を得た。 本書に登場する警句や法則は、主に、著者がＩＢＭのOS360（システム360のOS）を開発した時の経験（体験）に基づいている。 システム360はIBMが社運をかけて開発したメインフレームであり、著者のフレデリック・Ｐ・ブルックス，ＪｒはOS360のプロジェクトリーダーである。（システム360の後継機が1970年代に登場したシステム370である。国産メインフレーマーがその互換機を開発したことでも知られている。） 本書が最初に出版されたのは1975年で、その20年後に「1995年版：20周年記念増訂版」が出版されている。すなわち、最初の出版は今から約40年も昔で、増訂が施された1995年版からでも既に20年近くが経過している。変化の激しいIT業界にあって、そのような大昔の箴言や知見、法則が今でも通用するのか？ 誰しもそう思うに違いない。確かに現在では当てはまらない（と思われる）古い内容もあるが、現在でも充分に当てはまる部分が多々ある。 なぜ、今でも当てはまる警句が多くあるのか？　著者は次のように分析している。 先ずソフトウェア開発が今もって労働集約的なままであるという点があげられる。従って、本書の内容の多くは「人」と「チーム」について書かれているからそう簡単には時代遅れにならない。（組織やリーダーシップに関する書籍が昔から多数出版され続けていることと同じ理屈であろう） そして、プロジェクトが成功するためには、プロジェクトに携わる人々の質、およびその組織形態と管理こそが、使用するツールや採用する技術的アプローチよりもはるかに重要な要因である。 デマルコとリスターの著作「ピープルウェア」にも共通する、その根底にある理論は、「我々の作業にまつわる主要な問題は、本質的には技術的というより社会学的なもの」なのである。 本書の内容で少々意外に感じたのは「ウォーターフォールモデルは間違いだ」と言明している点である。意外に感じた訳は、OSの開発はユーザー向けのアプリケーション開発とは異なり、最初にきっちりと仕様やインタフェースを固めて、その後下流工程につなげていくウォーターフォールモデルが最も適しているのではないかと思ったからである。これがユーザ向けアプリケーション開発の場合であれば、運用テスト段階で要件が変わったり追加要件が出るようなことはよくある話で、我々もしばしば経験するところである。 著者がウォーターフォールモデルを否定している理由は、一般的にウォーターフォールモデルの欠点と言われていることと同じである。 すなわち、「実務の利用者のニーズとニーズに対する認識の両方が、プログラムが作成され、テストされ、使用される中で『変化』していく」、「ソフトウェア製品は、加工しやすくしかも目に見えないために、（特に）製作者はたえず変化する要求にさらされる」、 「目的（および開発戦略）に対する正当な若干の変更は避けられない。変更はないなどと想定するよりも、あると思って準備した方が良い」 といったことである。 著者はウォーターフォールモデルには誤解があるという。「ウォーターフォールモデルの基本的な誤解は、プロジェクトでは各工程が『1回』だけで、アーキテクチャが見事で使いやすく、インプリメンテーションデザインが適切で、テストの進捗に合わせて実現段階での修正が可能だと仮定していることである」 そして、ウォーターフォールモデルが確固たる地位を確保した背景を次のように語っている。 「ウォーターフォールモデルは、1975年にたいていの人が抱いていたソフトウェアプロジェクトについての考え方だった。だから、不幸にもDOD-STD-2167というすべての軍事ソフトウェアに関する国防総省の仕様書に記述され祭り上げられてしまった。そのために、思慮深い専門家のほとんどが不適切さに気づき捨て去ってからも生き延びた。」 著者が提唱しているのは漸増的構築モデルである。 「下流工程から来る経験とアイデアは、時には一段階以上流れに逆らって飛び越えて上がり、上流の作業に影響を与えるようでなければならない」、「ごく初期からユーザーテストに着手する」 早い段階でユーザー（利用部門）にシステムを使用してもらって、そこで出された改善要望や追加要望を上流工程に反映させる方法論であろう。この方法論を採用するときは当然ながら、スコープ（開発範囲と開発期間、開発コスト）をコントロールする仕組みも組み込む必要があるだろう。 著者は漸増的成長の1つの例として、マイクロソフトの「毎晩構築」アプローチをあげている。これは、今日でいう継続的インテグレーション（CI：Continuous Integration）と同義だと思われる。冒頭で紹介したブルックスの法則、遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけである、の根拠は「ソフトウェアプロジェクトに要員を追加することは、以下の3点において、必要となる全体の労力を増大させる。すなわち、再配分作業とそのための中断、新しい要員の訓練、それから新たに必要となる相互コミュニケーション」である。

ブログ記事「人工知能は人間を超える？」で人工知能の可能性について記載したところであるが、人工知能が銀の弾になりうるかについて、著者は次のように語っている。 「多くの人々は、人工知能（AI)の進歩がソフトウェアの生産性と品質に飛躍的な収穫をもたらす革新的な進展を与えてくれると期待しているが、私は期待しない」 本書改訂増補版出版から約20年が経過した今日、この見通しは果たして変わったであろうか？