ソフトウェア開発に「銀の弾丸など無い」とはどういう意味か『人月の神話』を読んでみた

ソフトウェア開発者であれば、様々な文脈で「銀の弾丸など無い」という言葉に触れたことがあると思う。

これは元をたどれば、1986年のIFIP(情報処理学会国際連合)という学会で発表された論文にたどり着く。

ロバート・L・パトリックが著した「銀の弾などない」という論文は1987年にIEEE(電気電子学会)の「コンピュータ」誌に再掲載されて大いに反響を呼んだ。

「銀の弾丸など無い」という言葉の意味は、

「ソフトウェアの生産性において、格段の向上をひとりでにもたらすようなプログラミング技法は今後10年間は登場しない」

という意味である。

注意すべきは、当時はプログラミングの生産性を上げるようなフレームワークも統合開発環境も存在していなかったという点だ。

Ruby on Railsも無い1986年の頃の話である。

僕が生まれたか生まれない時代の話で、日本にバブルが来る前のことだ。古き良き時代の話だ。

『人月の神話』という本がある

この16章「銀の弾などない -ソフトウェア・エンジニアリングの本質と偶有的事項」という項目で、銀の弾丸について述べられている。

表紙の文言がこの章で述べていることを集約している。

「技術においても管理手法においても、それだけで十年間に生産性や信頼性と容易性での飛躍的な改善を一つでも約束できるような開発は一つとしてない」

「銀の弾丸」とは何のメタファー(比喩)なのか?

銀の弾丸とは、「狼人間を魔法のように鎮めることができる」というものである。

では、狼人間は何を示しているのか?

狼人間は、「慣れ親しんでいるものを恐怖に変えてしまうもの」のメタファーだ。

本ではこう書かれている。

慣れ親しんだプロジェクトにもこうした性質があり、ふだんは無害でまともなのだが、スケジュールの遅延、膨れ上がった予算、そして欠陥製品といった怪物にもなり得る。

そして私たちは銀の弾、すなわちコンピュータハードウェアのコストと同じようにソフトウェアのコストも急激に小さくしてくれる特効薬を求める必死の叫び声を聞くのである。

このような記述から、冒頭に記したような結論につながる。

すなわち、「特効薬などない」という結論だ。

なぜ、特効薬は無いのか?

ソフトウェアは本質的に複雑なもの

まず、「ソフトウェアの複雑性は本質的な性質であって、偶有的なものではない」という点。

簡単に言うと、ソフトウェアは本質的に複雑なもので、たまたま複雑だったり単純だったりするわけではないよってこと。
ソフトウェアは複雑なものなので、単純なものさしでは測れない。

ソフトウェア構築で難しいのは、処理を書くことよりも、インターフェース(仕様)を作ったりデザイン(設計)する部分なので、単純に「ステップ数は1000」みたいな古臭いSIerの謎基準で難易度は測れない。

間違ったものさしでソフトウェアを測ろうとするから、目算を見誤る。
目算を見誤った上に「どうして予定通りに進んでないんだ!」とガントチャートを見るしか仕事がないジジイが文句をつけ、さらにプロジェクトが炎上する!

「ええい!人を投入せい!」

いやいやいや、人数が増えたらそれに比例して「コミュニケーションコスト」が増えていくんだって。
つまり、全体の生産性は落ちていくの。

どうしてそんなことがわからないのか…。

なぜ日本の会社は労働生産性が低いのか?効率よりも捨てる意識が大事

同調性

「同調性」について。

一回作ったものはなかなか変えられない。

機能追加をするときは「既に動いている仕様」につねに引きずられてしまう。

『人月の神話』には

「多くの場合、ソフトウェアは最後に登場したという理由で他に従わなければならない」

と書かれている。

まさにその通りで、それこそが複雑性が発生する原因であるという。

早く会社に入っただけで偉そうにするおっさんのように、後から追加されるソフトウェアは前例に従わざるをえない。
しかし、早く会社に入っていたり、早く生まれていたからといって人間が優秀だとは限らないように、既に動いているソフトウェアが素晴らしいともいえない。

先に生まれただけで偉そうにすんなよ。

可変性

可変性について。

ソフトウェアは常に変更という圧力にさらされているという。

システム中のソフトウェアはその機能を具現化したものである。
少し言い換えると、ソフトウェアこそがユーザーが求めている機能を実現するものである。

人が変更の必要性を感じるのは、当然ながら「求めている機能」である。

例えば、カーナビがあったとする。

みなさんの中に、

「カーナビの形を変えてくれ!」

という人はいるだろうか?

どちらかというと、

「距離を見やすく表示してくれ」

「旅行スポットの口コミを表示してくれ」

「いっそGoogleMapsを表示してくれ」

とソフトの部分を変えてほしいと願うものではないだろうか。

このようにソフトウェアはハードよりも変更の圧力にさらされる部分が多い。

それゆえにゴールがなく、工数も膨らみがちとなる。

不可視性

最後に、不可視性について。

ソフトウェアの構造は本質的に視覚化できないままになっている。
そのため、強力な概念上のツールを作る意欲を阻害している、と。

概念上のツールが作成できないから、思考を阻害し、コミュニケーションを妨げている、というのが『人月の神話』の主張だ。

頭の中でもやっと考えてソフトウェアを作るのではなく、概念を視覚化しようぜ、ということだ。

ちなみにUMLが登場したのが1996年。ちょうど『人月の神話』の論文が発表されてから10年後のことだ。

ここまで述べてきたようなソフトウェアの本質から、生産性を劇的に向上させる魔法なんてないよ、というのが論文の論旨である。

1986年に『銀の弾丸はない』と嘆きにも近い論文が書かれた。

その間、たしかにソフトウェアは大きく進歩したかもしれないが、銀の弾丸は無かった。

しかし現代を見たらどうだろう?

XCodeを使い、GUIでユーザーインターフェースを作っていける。
統合開発環境が丁寧にコードの予測をしてくれる。
バグを教えてくれる。

テストは自動化され、環境の構築も自動化され、便利なサービスがAWSで提供された。

生産性を劇的に向上させる「銀の弾丸」は存在しなかったのかもしれないが、ソフトウェア開発者の絶え間ない努力と新たなサービスを生み出す意欲が、かつての人々から見ると魔法のような開発環境を作った。

ソフトウェアは本質的に複雑で、現代のソフトウェア開発でも炎上はつきものだろう。
それでも、かつての開発者と比べると、銀の弾丸で撃ち抜かれたような世界で開発ができているに違いない。

ただここで覚えておかなければならないことは、「銀の弾丸」の恩恵は全ての人間にもたらされるわけではない、ということだ。

努力を惜しまず、新しい技術を取り入れ、現場の意識を変えたエンジニアだけが、銀の弾丸の恩恵を受けることができる。

Excelでソースコードの自動生成したり、くだらない会議で時間を無駄にする世界に生きている人間には、銀の弾丸は見えない。

¥3,520 (2020/03/31 02:06:13時点 Amazon調べ-詳細)

1 Comment

現在コメントは受け付けておりません。