「ブルックスの呪い」から逃れるために：山浦恒央の“くみこみ”な話（8）
プロジェクトの遅延回復策として行われる人員投入。しかし、単に人員投入をしただけではさらなる遅延を招いてしまう……。その打開策とは？
遅れているプロジェクト（銀河系のすべてのソフトウェア開発プロジェクトの120％が該当します）の遅延回復対策として、優れているものから順番に「スケジュールの延長」「トリアージュ（野戦病院方式）」「人員投入」「ダイハード方式」の4つがあると前回のコラム「震災地ボランティアと遅延プロジェクトの回復」で述べました。
「寝ないでコーディングしろ！」「土日も出社してデバッグだぁ!!」という長時間労働のみに頼るダイハード方式は論外にしても（しかし、現実には確実に失敗するこの方法を強制されることが少なくありません。特に、時間的な制約が非常に厳しい組み込み系のソフトウェア開発では顕著です）、遅延回復対策として“助っ人”を投入するプロジェクトは多いでしょう。
そこで今回は、『人員投入』を成功させるための具体策について検討していきます。
人員投入の最大の敵は、“遅延プロジェクトに人員を投入するとさらに遅れる”という、いわゆる「ブルックスの法則」です（発生メカニズムは前回解説しました）。このブルックスの法則による“呪（のろ）い（ここでは「ブルックスの呪い」とします）”にシッカリと対応しないと、ダイハード方式と同様、絵に描いたように見事に失敗してしまいます……。
ソフトウェア開発は一般的に、「要求仕様定義フェイズ」「設計フェイズ」「コーディングフェイズ」「デバッグフェイズ」「テストフェイズ」というプロセスを順番にたどります。仕様書や設計書、ソースコードは、それらしいものをでっち上げれば何とでもチェックの目をごまかせます。しかし、こうした怠慢、さぼり、いいかげんさに直面し、ツケを払わなければならなくなる場面が訪れます。それが“デバッグ工程”です。
また、プロジェクトの遅れが顕著になるのもデバッグ工程です。コーディング工程まで遅れなしで快調に進み、毎日17時に退社していたのに、デバッグ工程に入った瞬間、プログラムが“1ミリも動かない”なんてことも珍しくありません。きちんとした開発プロセスを踏んでこなかったプロジェクトは、デバッグ工程で必ず大混乱を起こします。
プロジェクトが大混乱すると、プログラマの机の上は、ラインマーカーで7色に染まったバグ・レポートが山積み状態。散乱したコンビニ弁当の空箱の上には仕様変更書が重なり、ホッチキスや穴開け器を重し代わりに、さらには開きっ放しの仕様書や設計書のすき間にコーヒーの紙コップが5、6段重なる……。そこへ追い討ちをかけるように、メールが100通届き、QA（Quality Assurance）部から怒りの電話が入る……といった状況になるでしょう。これは、世界中で見かける遅延プロジェクトの「よくある光景」ですが、こんな状況下に助っ人が投入されるのです。
こんな大混乱状態のプロジェクトに人員を追加すると、必ず遅れが拡大します。その原因として、ブルックスは「（1）コミュニケーション・パスの急激な増加」「（2）助っ人の教育」「（3）作業の再配分」の3つを挙げています。人員投入で遅延回復を図る場合、この3つの遅延要因と正面から向き合わなければなりません。それでは、遅延要因に対してどのように対処すればいいのか、具体策を見ていきましょう。
| 関連リンク： | |
|---|---|
| ⇒ | 人月の神話 狼人間を撃つ銀の弾はない |
（1）コミュニケーション・パスの急激な増加
大混乱しているプロジェクトに人員を投入した場合、最も怖いのが“コミュニケーション不良”です。間違った情報がエンジニアに伝わる可能性は、それほど多くはありませんが、「知るべき人に情報が伝達されない」ミスは頻発します。特に、オフィスが分散している場合は、「必ず発生する」といっても過言ではありません（分散オフィスでの対処法は後述します）。
助っ人を入れると、なぜ、コミュニケーション・ミスが発生するのでしょうか？ 最大の原因は“コミュニケーションのパス数が爆発的に増えること”にあります。5人のエンジニアがいれば、コミュニケーションのパス数は5角形の対角線の数ですから、
となります。ここに新たに5人の助っ人を追加投入して10人のプロジェクトを作ると、人数が2倍になっただけなのに、パス数は「45」となり、5人のときの4倍以上になります。
コミュニケーション・パスの爆発的増加、および、そこから発生する混乱へ対応する方法として、
- 助っ人の数を最小限にする
- 「人間仕様書」を設置する
- 分散オフィスの場合、「リエゾン（連絡将校）」を置く
の3つがあります。
以降で、各対策について説明していきます。
1．助っ人の数を最小限にする
ブルックスも書いていますが、「ソフトウェア開発の最良の形態は、少数精鋭のグループで開発すること」です。エンジニア間のインターフェイスを最小にできると、すなわち、開発エンジニアの人数を少なくするほど、生産効率が良くなり品質の高いソフトウェアを開発できる可能性が高くなります。究極は1人のプロジェクト、例えるなら『ゴルゴ13』のような「ワンマン・アーミー」です。
人員投入による遅延回復の“超”基本は、「助っ人の数を最小限にする」にあります。投入人員を少なくすると、コミュニケーション・パスの爆発的増加を最小限に食い止めることができます。助っ人の人数を可能な限り少なくするには、ほかのプロジェクトから、能力の高いエース級の技術者を派遣してもらうことが必須ですが、これは簡単なことではありません。しかし、遅延プロジェクトの成否が、会社の存亡にかかわるほど重要である場合、以前のコラムでも書きましたが、プロジェクト・マネージャは誰でも任意の助っ人を引き抜ける「人事権」を持つべきです。特に、組み込み系のソフトウェア開発のように、狭いけれども非常に深い知識が必要な分野では、スーパー・プログラマの参画は必須です（能力の高い技術者を出してもらえなかった場合の回復策については、次回以降で紹介します）。
2．「人間仕様書」を設置する
プロジェクトが混乱する最大の理由の1つが、「仕様変更が全員に伝わっていない」というコミュニケーション・ミスです。プロジェクトの規模が大きくなると、仕様全体を押さえている人がおらず、仕様変更の伝達ミスは大きくなり、「自信タップリに、間違った仕様を伝えるミス」が増えます。そんなときに有効なのが「人間仕様書」です。この人の役割は、「すべての仕様に通暁（ぎょう）し、変更もすべて承知し、仕様の管理“だけ”をする」ことにあります。人間仕様書に聞けば、仕様を即答してくれるのです。50KLOC程度の小規模プログラムであれば、人間仕様書は必要ありませんが、10MLOCを超えることも多い組み込み系の巨大ソフトウェアでは、人間仕様書の効果は絶大です。人間仕様書は非常に重労働なので、ほかの作業との兼任はできません。贅沢な人員の割り振りですが、その価値は十分にあります。
3．分散オフィスの場合、「リエゾン（連絡将校）」を置く
理想の開発形態は、「エンジニアが全員同じオフィス、同じ部屋で作業すること」です。しかし、海外発注が盛んに行われている昨今、日本と中国、日本とインドのように、分散開発は当たり前どころか、不可避になってきました。特に、組み込み系のソフトウェア開発は手離れがよいことから、国内国外を問わず、分散開発が多く見られます。
分散オフィスの問題は、コミュニケーション不良が発生しやすいことです。分散開発でのコミュニケーション・ミスは、特に、エンド・ゲームとなるデバッグ工程やテスト工程では致命的で、伝達不良のために、一挙に2、3カ月前の状態に簡単に戻ってしまうこともよくあります。分散開発でのコミュニケーション・ミスを防ぐには、専任の「リエゾン（連絡将校）」を置くことが重要です。リエゾン担当者は、設計能力よりも伝達能力、完遂力が重要で、設計者としてそれほど高い能力を必要としません。そのため、人選にはさほど苦労しないと思います。
以上が、遅延プロジェクトに人員投入する場合の「（1）コミュニケーション・パスの急激な増加」に対する留意事項です。
次回は残りの2つ、「（2）助っ人の教育」「（3）作業の再配分」への対応策を検討していきます。ご期待ください！（次回に続く）
東海大学 大学院 組込み技術研究科 助教授（工学博士）
Copyright © ITmedia, Inc. All Rights Reserved.