現代の銀行システムを支える巨人 第5話：ブルックスの法則
作者のかつをです。
第四章の第5話です。
ソフトウェア開発に携わったことがある人なら、誰もが一度は聞いたことがあるであろう「ブルックスの法則」。
その法則が、いかにして生まれたのか。今回は、その壮絶な背景を描きました。
※この物語は史実を基にしたフィクションです。登場する人物、団体、事件などの描写は、物語を構成するための創作であり、事実と異なる場合があります。
ハードウェアの開発が、アーキテクチャという名の羅針盤を得て、順調に進む一方で。
フレッド・ブルックスが率いるソフトウェア開発チームは、泥沼の中でもがいていた。
彼らが作っていたのは、System/360の魂となる、OS/360という、史上最も複雑なオペレーティングシステム。
ハードウェアの性能を最大限に引き出し、複数のプログラムを同時に動かす、魔法のじゅうたんのようなソフトウェアだ。
しかし、開発は、絶望的なまでに、遅れていた。
「ブルックス、どうなっているんだ。スケジュールから、もう半年も遅れているぞ」
役員会議で、ワトソン・ジュニアの厳しい声が飛ぶ。
ブルックスは、汗を滲ませながら、答えるしかなかった。
「申し訳ありません。ですが、人員を増強して、必ずや、巻き返してみせます」
それが、当時の常識だった。
プロジェクトが遅れたら、人手を増やせばいい。
単純な理屈だ。
ブルックスは、その言葉通り、何百人というプログラマーを、次々とプロジェクトに投入した。
しかし、事態は、好転しなかった。
それどころか、さらに悪化の一途をたどったのだ。
新しく加わったプログラマーたちは、この複雑なOSの全体像を、すぐには理解できない。
彼らを教育するために、元からいた優秀なプログラマーたちが、時間を奪われる。
人が増えれば、それだけ、コミュニケーションの経路も、爆発的に増えていく。
Aさんが書いたプログラムが、Bさんが書いた別のプログラムと、予期せぬ悪影響を及ぼし合う。
バグが、モグラ叩きのように、次から次へと発生した。
プロジェクトは、まるで、底なしのタールの沼にはまったようだった。
もがけばもがくほど、深く、沈んでいく。
この地獄のような経験の中で、ブルックスは、一つの痛烈な教訓を得た。
「ソフトウェア開発は、ビルの建設とは、根本的に違う」
レンガを積む作業なら、人手を二倍にすれば、速さも二倍になるかもしれない。
しかし、思考の産物であるソフトウェアは、そうはいかない。
彼は、後に、この経験を元に、ソフトウェア工学における、最も有名な警句を書き残す。
「遅れているソフトウェアプロジェクトに人員を追加すると、さらに遅れる」
――“ブルックスの法則”の、誕生である。
それは、会社の存亡を賭けた巨大プロジェクトの、夥しい犠牲と、苦悩の中から生まれた、血の滲むような法則だった。
最後までお読みいただき、ありがとうございます！
フレッド・ブルックスは、この時の経験を『人月の神話』という名著にまとめました。この本は、ソフトウェア開発の難しさと本質を突いた古典として、今なお、世界中のエンジニアに読まれ続けています。
さて、泥沼にはまってしまったOS開発。
出口の見えないトンネルを、彼らはどうやって突き進んだのか。
次回、「デスマーチの果てに」。
エンジニアたちの、不屈の戦いが描かれます。
物語の続きが気になったら、ぜひブックマークをお願いします！
ーーーーーーーーーーーーーー
もし、この物語の「もっと深い話」に興味が湧いたら、ぜひnoteに遊びに来てください。IT、音楽、漫画、アニメ…全シリーズの創作秘話や、開発中の歴史散策アプリの話などを綴っています。
▼作者「かつを」の創作の舞台裏
https://note.com/katsuo_story
