ブルックスの法則とはなにか
ソフトウェア開発におけるブルックスの法則とは何か。
遅れているソフトウェアプロジェクトへの要員追加は、プロジェクトをさらに遅らせる
ブルックスはIBM System/360用オペレーティングシステムOS/360の開発総責任者だった人で、その経験をもとに人月の神話【新装版】
人月の神話は、ソフトウェア開発を志す人なら必ず一度は読まなければいけない良書だ。読んでいない人は、悪いことは言わないから、ともかく読むことをおすすめする。
初版が出版されたのが1975年（日本語訳は1977年）で、20周年記念版が1995年に出た。ブルックスの発見した法則があきらかになって約40年たつ。
40年もたつのに、未だにソフトウェア開発は遅れるし、品質はおそまつで、開発コストも予算をオーバーするのはなぜか。
一つはブルックスの法則も理解しない素人がソフトウェア開発に関わっているからではないか。
素人のプロジェクトマネージャーは、スケジュールの遅延を発見できないし、仮にスケジュールが遅れていることを発見したとしても、それはもう手遅れのタイミングだったりするのではないか。そして素人は、出火しているのを見て、パニックになりやってはいけないこと、すなわち、人員を無駄に投下する。それは火に油を注ぐようなものである。
ではどうすればいいのか。ソフトウェア開発における変数とは何か。それは１）開発のスコープ（何を開発するか）、２）スケジュール、３）開発人員として考える。
ブルックスの法則によれば、遅れているプロジェクトに人員を追加すること（３）は事態を悪化させる。従って、次善の策としては、開発スコープを変える（通常は減らす）、スケジュールを延ばすのどちらかになる。
そして、混乱しているプロジェクトの中でスケジュールを延ばすというのは、通常は単に混乱を引き延ばすだけなので、事態は収拾しない。結果、開発スコープを減らすというのが現実的な解になる。
とはいうものの、受託開発などの場合、契約書で何を開発するかなどが記されていたりして、それを変更することが困難だったりするので、大抵はデッドエンドである。
ソフトウェア製品を何度も何度も作っていると、組織として、ソフトウェア開発の困難性を学ぶので、見積もりの精度があがったり、スケジュールの遅延に繋がるような兆候を早期に発見したりする仕組みを持っていたりする。従って、スケジュールが遅延して、どうしようもないというプロジェクトが発生する確率は低くなる。
それがソフトウェアテストの自動化だったり、アジャイルソフトウェア開発手法だったりする。
特効薬はない。当たり前のことを当たり前にやるだけの話である。
開発スコープを小さくすることのメリットは、小さい機能単位なので、相対的にすばやく開発でき、実際に動くものが出来るので、ユーザーに直接利用してもらえて、その機能が必要なものかどうかを確認できる。正しく動いているかという確認ではなく、ユーザーが必要としたものかどうか、正しいものを作ったかどうかを確認できるというのが最大のメリットになる。
ウォーターフォールモデルの場合、要求仕様定義のフェーズで記されたものがユーザーによって確認されるのは、実際に出荷した後で、無駄なものをせっせと作ってしまう可能性が常にある。その機能を極限までに小さくして、さっさと作ってさっさとデプロイしてさっさと確認するという方法だと、無駄なものを作る可能性が減り、結果として生産性があがる。
ブルックスの法則とは何か。炎上しているプロジェクトのメンバーは一度本書を読んでよく理解してみよう。そして、どうすれば、プロジェクトが遅延しないのか、炎上しないか、よく考えてみよう。
プロジェクトマネージャーが人が足りないと言っていたら、それはよくない兆候である。
