フレッド・ブルックス氏が今週亡くなりました。年齢にもよりますが、彼はコンピューター科学の分野の巨匠、もしくはコンピューターサイエンスの教科書に載っている名言の著者として知られているでしょう。しかし実際には、彼はその両方でした。

ブルックスはIBMのSystem/360とOS/360の開発を主導しました。これらはコンピューティングにおける革命的なマイルストーンであり、ほぼすべての現代システムの先駆けとなりました。これらのメガプロジェクトを通して、ブルックスはソフトウェアプロジェクトの組織化に関する多くの貴重な洞察を獲得し、それらについて出版や講演を行いました。

「遅れているソフトウェアプロジェクトに人員を追加しても、プロジェクトは遅れるだけだ」（ブルックスの法則）という有名な格言は、コンピュータサイエンス分野の人なら誰でも少なくとも一度は耳にしたことがあるであろう、彼の著書『人月の神話』に由来しています。この本の中心的な主張は、多くのプロジェクトでは人員を追加してもメリットがないというものです。

土嚢の壁を作る場合、袋に砂を詰めて積み上げる作業員が増えることがボトルネックになります。そのため、砂と袋の供給が不足しない限り、人員を増やすことでプロジェクトは加速します。しかし、ソフトウェアプロジェクトはそうではありません。月末までにコードをリリースしようとしている場合、突然100人ものエンジニアをプロジェクトに投入すると、状況は悪化します。

多くのマネージャーや日常業務が IT ではない人にとっては直感に反しますが、よく考えてみると、理由は納得できます。

立ち上げ期間：使用されているツールやライブラリ、それらのツールやライブラリを習得し、コードのレイアウト方法を理解し、資格情報を取得し、グループの規範（コーディングスタイルからコミットの期待値まで）を理解するまで、コードベースに貢献することはできません。これらはすべて時間がかかり、特に既存のエンジニアの時間を要します。既存のエンジニアがデータの取得方法や使用するデータベースクライアントライブラリを私に示している間、そのエンジニアはコードを書いていません。

組み合わせ爆発：仕事が軌道に乗ると、他のエンジニア全員とやり取りしなければなりません。プロジェクトに4人しかいない時は大した問題ではありません。しかし、20人、200人になると、全員に情報を提供し、コミュニケーションをとるだけで時間がどんどん奪われてしまいます。目が回るようなほど多様なコミュニケーションツールが使えるので、これはもっと簡単になるはずです。実際、それは簡単です。タイプライターで書いたメモの代わりに、メールやSlackを使えばいいのです。しかし、そうすると他の人がそれを読むのに時間を割かなければなりません！

すべてのタスクが分割可能とは限らない：一部のタスクでは、専門的でドメイン固有のスキルを持つ1人または数人の担当者が集中して取り組む必要があります。ブルックス氏が言うように、「9人の女性が1ヶ月で赤ちゃんを産むことはできない」のです。人員を増やすことは、非常に複雑な分野で長期間にわたって人材を育成するのと同等です。これは、大学や一般的なコンピュータサイエンスで学べるようなものではなく、既に構築されている非常に複雑なシステムや、アプリケーションに関するドメイン固有の知識がすべてチーム内で共有されているケースに当てはまります。

『人月の神話』にはさらに多くの洞察が詰まっており、ソフトウェアエンジニアリングの様々なトピックを網羅しています。ユーモアあふれる名言の数々で知られるブルックス氏はかつて、この本をソフトウェアエンジニアリングのバイブルと評しました。「誰もが引用し、読む人もいれば、それに従う人もいる」からです。

ブルックスはチューリング賞を受賞し、91歳まで生きた。