　第4回のコラム「30年前の本がいまでも売れている理由」で“ブルックスの法則”を取り上げた際、最も有名なブルックスの法則として、「その2：遅延プロジェクトに人員を投入すると、さらに遅れる」を紹介しました。この法則は、ソフトウェア開発の遅れを取り戻すために人員を追加すると、遅延がさらに拡大するというもので、一見すると常識に反するように思える法則ですが、組み込み系ソフトウェア開発だけでなく、あらゆるプログラム開発で誰もが経験していることだと思います。

　このたった1発の場外ホームラン的な法則により、ブルックスの法則全体が世界的に有名になり、誰もが記憶すべき古典として「ソフトウェア工学の殿堂」入りを果たしました。

　スケジュールの遅延を回復する方法として、50年前から行われているのが開発エンジニアの増員ですが、人員投入による遅れを最小にし、また「助っ人」の効果を最大にするにはどうすればいいでしょうか？

　今回は、この法則の細部を検討しつつ、人員投入時のコツを解説します。

遅れを取り戻す4つの方法

　遅れているプロジェクトを正常状態に戻すには、一般的に以下の4つの方策が取られます（2つ以上を同時に導入する場合もあります）。

（1）スケジュールの延長
（2）トリアージュ
（3）人員投入
（4）ダイハード方式

　（2）「トリアージュ」とは、限りある資源（ソフトウェア開発の場合、時間と工数）を優先順位の高い作業から順番に割り当てる「野戦病院方式」のソフトウェア開発法です。この方式の詳細は別の機会に解説します。（4）「ダイハード方式」は、「本物のプログラマは寝ずに働く」的な思想をベースにしたものです。マッチョで前近代的な遅延回復方法であり、ひたすら効率の悪い長時間労働を頼りにして、力で中央を突破する作戦です。

　この4つは、遅延回復の効果が高く、プロジェクトの負担や混乱が少ない順番に並べてあります。上に行くほど正統的で望ましい対策なのですが、現実には、下位の対策、すなわち、（3）「人員投入」か（4）「ダイハード方式」を採用するプロジェクトが大部分でしょう。（4）「ダイハード方式」は自滅的な方法であり、プロジェクトは必ず大失敗します。さすがにいまでは少なくなりましたが、かつての王道的な遅延対策法でした。現代の遅延回復の主流は（3）「人員投入」でしょう。

　この人員投入の正面に、ヒマラヤ山脈より高く立ちはだかるのが、ブルックスの法則です。

遅れのメカニズム

　助っ人を投入すると遅延が拡大する原因として、ブルックスは「作業の再配分」「新規要員の教育」「コミュニケーション・パスの急激な増加」の3つを挙げています。特に、新しく入った助っ人プログラマを教育するために、オリジナルのメンバーのかなりの工数を割かざるを得ず、プロジェクト全体の生産性が大きく下がって、スケジュールの遅れがさらに拡大するのです。この様子を図1に示します（この図本体、および、図中で使用している用語は筆者が勝手に考案したものであり、ブルックスの書籍には載っていません）。

図1　人員投入による遅延の移り変わり

　図1の「遅延期」では、遅れつつも、プロジェクト員の全工数をソフトウェア開発に割り当てていました。遅れを回復するため、プロジェクトの外部から人員を集めて追加した瞬間、プロジェクトは「混乱期」に突入し、チーム全体の生産性は大きく下がります。最悪の場合、図1に示したようにゼロ以下になることもあります。この原因として、以下が考えられます。

　1）オリジナルのプログラマが、助っ人の「教育係」となり、対象ソフトウェアの機能、処理方式、アルゴリズム、モジュール構造などを教えなければならないため、開発の実動パワーが大幅に急激に減少します。

　2）「教育係」の担当作業を別のメンバーに割り当てた場合、別メンバーは慣れない「守備範囲外」の作業をするため、不必要なバグを作り込んでしまいます。このバグ修正に余分な工数が掛かり、「何もしない方がましだった」との結果になりかねません。

　3）作業全体をオリジナル・メンバーと助っ人に割り当て直すため、プロジェクト全体が大混乱します。これは、例えば、1人で書いていた長編小説を10人で分担するようなもので、分割執筆のためのいろいろな準備、手配、相互の意思疎通は、想像するよりはるかに複雑怪奇で大変です。

　この混乱が治まり、徐々に助っ人の効果が表れ、「回復期」に入るのです。

混乱期から脱出する方法

　人員投入作戦を成功させるには、2つの方法しかありません。1つは、図1の混乱期における生産性の落ち込み幅を最小限にすること、もう1つは、混乱期の期間を最短化することです。これに効果が期待できることを以下に記します。どれも非常に重要なことです。

（1）プロジェクト管理者の心構え

　混乱期を短く早く乗り切るための最も重要なことは、プロジェクト管理者が「人員を投入すると遅延は拡大する」ことを十分に認識していることです。図1のような「生産性低下曲線」を頭に入れ、混乱期を早く乗り切る算段を立てなければなりません。助っ人を大量に投入したのだから、遅れはすぐに回復できると無邪気に信じる上位管理者はたくさんいます。ソフトウェア開発の初心者も同様です。そんな上司や初級プログラマに、ブルックスの法則をしっかり理解してもらう必要があります。

（2）助っ人選択の人事権

　遅延しているプロジェクトが、会社の将来を左右するほど重要なものであるなら、プロジェクト管理者は、助っ人を選ぶ「人事権」を持つべきです。

　前回「ソフトウェア開発で1本10万円のワインを造る方法」で書きましたが、プログラマの能力の差は、10倍（28倍と分析する人もいます）以上もあるのが常識です。また、助っ人の人数が増えると、「教育係」の負担が増えたり、コミュニケーションのパス数が爆発的に増加したりするなど、百害あって一利なしです。助っ人として、高い能力のプログラマに参画してもらい（実際には、上層部に働き掛けて、無理やり引き抜くことになります）、プロジェクトの人数をなるべく少なくすべきです。

　最悪は、平均以下のプログラマが大量に投入された場合でしょう。助っ人を出してくれるように外部のプロジェクトに頼むと、頭数さえそろえばいいんだろうと「お荷物プログラマ」を出す（厄介払い？）場合があります。そんな人は、助けにならないどころか、マイナスの生産性要因です。断固、断りましょう。その意味でも、プロジェクト管理者が「助っ人選択の人事権」を持つことは非常に重要です。

「ボランティア」の勘違い

　大きな地震で壊滅状態になった被災地では、復旧に向けての緊急対策室を市役所などに設置し、負傷者の対策やライフラインの復旧などに全力を注ぎます。

　ここで、ある震災地の対策室の担当者から聞いた話を紹介します。

　「対策室には、『私は医者ですが、そちらにボランティアとして参画したい』という電話がひっきりなしに入るんですよ。そんな人の大部分は、『貧しい民に施しを与える正義の味方』として市長や市民から大歓迎され、特別待遇を受けられると期待しているんです。言葉の端々から、『美談のヒーロー扱い』への大きな期待がうかがえます。しかし、緊急対策室にはそんな余裕はまったくありません。ボランティアの大原則は、『被災地側に負担を掛けない』です。食事、水、交通手段、寝袋などすべて自腹で用意・確保したうえで、被災地へ来て、病人やけが人の治療をする。そんな人でないと来ていただきたくありませんし、役に立ちません。そうお話しすると、言葉に詰まる人も多くいますよ。困った人を助けるには、被災者とともに厳しい現実に向かう覚悟と救援物資が必要なのです」。

　遅延プロジェクトに投入された助っ人は、まさに、被災地のボランティアです。「困っている村人を助ける七人の侍」的なユルい気持ちで参加されては、大きな迷惑です。参加してくれる助っ人に感謝しつつも、「一緒に泥水をすする覚悟で遅れを取り戻してほしい」と最初にキチンと宣言しましょう。プロジェクトに参加した以上、助っ人ではなく、当事者なのです。「誰か（他人）のプログラム開発が遅れている」のではなく、「自分のソフトウェアが遅延している」のです。

　さて、次回も引き続き「混乱期から脱出する方法」を紹介したいと思います。お楽しみに！（次回に続く）

【筆者紹介】

山浦恒央（やまうらつねお）
東海大学大学院組込み技術研究科助教授（工学博士）

1977年、日立ソフトウェアエンジニアリングに入社、2006年より、東海大学情報理工学部ソフトウェア開発工学科助教授、2007年より、同大学大学院組込み技術研究科助教授、現在に至る。

主な著書・訳書は、「Advances in Computers」（Academic Press社、共著）、「ピープルウエア第2版」「ソフトウェアテスト技法」「実践的プログラムテスト入門」「デスマーチ第2版」「ソフトウエア開発プロフェッショナル」（以上、日経BP社、共訳）、「ソフトウエア開発 55の真実と10のウソ」「初めて学ぶソフトウエアメトリクス」（以上、日経BP社、翻訳）。