ソフトウェア開発における法則「ブルックスの法則」

ソフトウェア開発は、案件や現場によってルールも内容も違っているが、奇妙なことに、因縁関係のような法則が存在する。 今回は「ブルックスの法則」を少し掘り下げてみることにする。

解説

Wikipedia

「遅れているソフトウェアプロジェクトへの要員追加はさらに遅らせるだけだ」 「9人の妊婦を集めても、1ヶ月で赤ちゃんを出産することはできない」

wikipediaで説明されている通り、フレデリック・ブルックスという人が提唱した法則だが、皮肉っている内容であることは間違いない。 妊婦の説明はソフトウェア開発には関係ないが、質よりも量で解決できない事の比喩のようである。

身近に考えてみる

仕事をしていると忙しい人は大体において、とりかかっている案件のボリュームを作業員の少なさに例える。 現実に、そのような時に望むだけの人員を投入できたとしたら、その人は忙しく無くなるかというと、実は誰でも分かっているが そうならないことの方が多い。 おそらくは、新しく来た人に作業の説明を行う必要があるし、新しく来た人が行なった仕事の確認を行い、新しく来た人の上に立たないといけないはずだ。 手数を分散させるために人出を増やしたはずなのに、教育したり、確認したりする作業は少人数で行なっていた今までは必要なかったのに、想定外の仕事が増えて、再度「忙しい」というセリフを別の作業によって発してしまうことだろう。 猫の手も借りたいと言うのは、猫の手を借りても意味が無いことの例えであることも忘れないようにしよう。

プロジェクト進行は人数が少ないほどバグが少ない

ソフトウェア開発における不具合の発生率は、開発を行う人数に依存する事を研究している人がいた事をご存知だろうか？ マイクロソフト社のトーマス・ジマーマン氏が研究成果を発表しているが、色々な開発環境におけるバグの発生率を調査したらしい。 「少人数のチームの方がソフトウェアの品質は高い」実証的ソフトウェア工学の研究会が開催 ここではブルックスの法則を

「組織の構造がプロダクトの品質に大きな影響を与える。」

と現しているが、チームを組織として考え、ポイント制で統計を取っていったという事だ。 少人数の方が発生したバグが少ないというよりも、人数が増えるほどバグが多くなるという結果で、小さなコミュニケーションの食い違いがソフトウェア障害に繋がるという典型的な結果となった。

同じ単語の意味の違い

非常に分かりやすいのは、他人との話の中で同じ単語でも捉え方が違うケースがないだろうか？ 開発初期に、「AとBを比較して同じであればCを表示、違っていればDを表示」という要件に対し、「同じであれば・・・」という言葉に対して、開発員の一人は、「同じ値であれば」と考えた、もう一人は「同じジャンルであれば」と考えたが、もちろんこの二人が作る開発物の結果が食い違う事は誰でも用意に理解できる。 でも、彼らは判定は「同じ」という事で勧められているので打ち合わせを行なっても疑うことすら無く、結合試験までは、このバグは判明されない事となる。 はじめから、「何が同じ」というレベルで話していればこうした不都合は発生しないかと言うと、ツーカーの仲でも、双子でも、こういった不都合は発生するのである。 だって、１つの脳みそではないからね。 という事で些細な食い違いを無くす努力をしているチームや組織が、バグが少なく、その手直し作業を考えると、バグが少ない事イコール作業の効率がいいという事に繋がる。

コミュニケーションは距離に比例する

先ほどのトーマス氏のレポートにもある、同じチームでも、別のフロア、別の建物、別の国、などのように実際の距離が離れるほどコミュニケーションの共有感が薄れるという事も実験結果で現れている。 昨今であれば、FaceTimeなどを使って常時テレビ電話として作業もできるのだが、物理的な距離は潜在的に存在するようだ。 しかし、これらの実験結果も、法則も、あくまでただの理論であるという事も一方で認識しよう。 多くの人出回しているプロジェクトでも不具合が皆無なモノも存在するし、一人で開発していてもバグだらけのモノもたくさんある。 スピードや効率も、人数で左右されない要因もたくさんあるので、占いなどと同じように、フルックスの法則も、業界アルアル話程度に理解して、そういった失敗や、法則に乗っ取らない持論を持つことが重要と理解しよう。 人が増えた時の為に、マニュアルを作ればいいだけの話なのである。