　大混乱プロジェクトに人員を追加すると、「ブルックスの呪い」のため、必ず遅れが拡大します。ブルックスの呪いの正体は、「コミュニケーション・パスの急激な増加」「助っ人の教育」「作業の再配分」の3つです。前回「『ブルックスの呪い』から逃れるために」では、この中で「コミュニケーション・パスの急激な増加」に対する対処法を述べました。

　今回は、最も厄介な「助っ人の教育」に正面から切り込んでいきたいと思います。

「助っ人受け入れ」の実際

　大混乱しているプロジェクトに人員を投入した瞬間、どんなことが起きるのでしょうか？おそらく、日本中で次のような会話が交わされているに違いありません。

熊谷（プロジェクト・マネージャ）　「先週の全社工程会議で最低20人欲しいといったら、専務があちこちの開発部署に声を掛けてくれて（※1）、家電ソフトウェア第1開発部から5、6人出してくれるらしい。1時半にその連中が来るからそろそろだな……。阿波君、その人たちの面倒を見てやってよ。オレ、いまから事業部工程会議（※2）に行かなきゃならないんで」（といいながらノートをつかんで席を立つ）。

阿波（サブ・マネージャ）　「あっ、熊谷さん。どんなレベルの人が来るんですかね？それと、足りないエンジニアはどうするんですか？」。

熊谷　「レベル？うーん、よく分からん。足りない分は、ボチボチ出してもらえるはずだよ（※3）。まあ、よろしく頼むわ」（と飛んでいく）。

――やがて1時半になり、5人のエンジニアが到着。

中野（家電ソフトウェア第1開発部のエンジニア）　「あの、『家ソ1』の中野ですけど、ここへ1時半に来いといわれまして……。熊谷さんいらっしゃいますか？」。

阿波　「熊谷さんは事業部工程会議に行きました。今度、お手伝いいただく『家ソ1』の方ですね。よろしくお願いします。熊谷さんからお話は聞いています」（といいながら、使えそうなヤツかどうか5人を値踏みし、『こいつらハズレだろうなぁ。イイやつは出してくれないものね』とガッカリするも、『でも、何かの役には立つだろう』と気を取り直す）。「ところで、これまでFAX機器のソフトウェア開発を担当された人はいますか？」。

中野　「この蜷川（にながわ）君は、メール・サーバの開発経験がありますが、あとの4人は通信系ははじめてですね」。

阿波　「（“やっぱりね”とガッカリしながら（※4））分かりました。では、このプロジェクトの概要を説明しますんで、会議室へ移動してください」。

――ゾロゾロとプロジェクトの真ん中を突っ切って5人は会議室に向かう。3日は帰宅していないようなエンジニア連中が必死にソースコードとにらめっこしている様子を見て、“来週はオレたちもああなるんだなぁ”と5人は暗い気分になる……。会議室で、1時間にわたり、阿波がプロジェクトの状況や開発しているFAX機器の機能の概要を説明する。

阿波　「……というわけなんですが、5人ともFAX機器の開発経験がないということなんで、まずは、仕様書を読んで、大ざっぱな機能を理解してください（※5）。分からないところがたくさんあると思いますが、何でも質問してもらって構いません（※6）。いまから仕様書をコピーしてきます。それと、5人分の机がないので、大至急用意しますが（※7）、それまで申し訳ないんですが、ここで作業をしてください」（といい残して、会議室を出ていく）。

高橋　「パソコンがすぐにはもらえないのか。ちょっと不便だね。オレ、メールをチェックしなきゃいけないんで、『家ソ1』に戻るわ」。

蜷川　「じゃあ、オレも」。

――かくして、1週間が無駄に過ぎるのであった……。

※1：どの開発部署もエンジニアを出したがらないので、担当役員が無理やり、人を引きはがして、問題プロジェクトに投入するのが基本。

※2：遅延プロジェクトの管理者は、プロジェクトに張り付いていなければならないのに、1日中、工程会議、品質会議、進ちょく会議など、会議にまみれている場合がほとんど。会議は、大勢の時間を浪費させる最も確実な方法。

※3：追加人員は、まとめて投入されず、五月雨式にポツポツ入ってくるのが普通。

※4：要求にピッタリの人員が投入されることはまずあり得ない。プロジェクトで使っているプログラミング言語を知っているだけでももうけもの。

※5：助っ人を受け入れる態勢ができていない混乱プロジェクトでは、「まずは、仕様書を読め」が超基本。

※6：血走った眼でソースコードを追い掛けているサブ・マネージャの阿波に、「留守電メッセージ再生中に、再送ボタンを押すとどうなるんですか？」なんてとても聞けない。

※7：混乱プロジェクトでは、追加人員は窓のない会議室で作業させられることが多い。追加人員の作業場所と開発環境（特に、メールを送受信できる環境）をすぐに提供できないと、助っ人の効果はなくなり、混乱ばかりが増大する。

助っ人の教育と早期戦力化

　経験したことのないソフトウェアを開発する場合、「仕様書を読めば機能が分かる」ことはあり得ません。まして、ソースコードを渡して、「ロジックを追い掛けて」とお願いしてもそんなことは不可能です。

　上記のケースのように、助っ人の受け入れ態勢がまったく整っていない状況では、投入人員が戦力になるには数カ月かかるでしょう。助っ人の教育に取られる工数を最小限にし、かつ、投入人員の効果を早急に出す最善の方法が「デバッグの支援」です。

　前回のコラム「『ブルックスの呪い』から逃れるために」でも書きましたが、プロジェクトが混乱するのはデバッグ工程以降です。デバッグ工程は、テスト項目がきちんと設計されていれば、追加されたエンジニアを最も効率よく使える工程です。

　以下に、テスト項目をまじめに作っているプロジェクトで、追加人員の教育と、早期戦力化を同時に実施する最良の方法を示します。

各助っ人の担当する機能を決める。
各助っ人に、担当機能のデバッグを実行してもらう。
→テスト項目は、入力条件と期待する出力を具体的に定義してあるので、助っ人がはじめて担当する未知の機能でも、デバッグは可能である。また、バグがあっても、再現できる。
→バグを検出したら、バグ・レポートを書く。
→マシンの実行によるデバッグの実作業を助っ人に任せることにより、元の設計者は、助っ人の教育に時間を取られることもなく、最重要作業である「バグ修正」に専念できる。
助っ人は、デバッグの実作業により、開発対象ソフトウェアの操作や機能を自習し、体で覚えられる。
機能や操作を一通り理解したら（1、2週間？）、設計書を読み、モジュールの構造や、各モジュールで実装している機能を理解する。
担当する機能のバグを修正する（ソースコードを読む）。

テスト項目設計の重要性

　上記のステップが成功するかどうかは、質の良いテスト仕様書、テスト項目をきちんと作っているかどうかに掛かっています。高品質のテスト・ドキュメントができているようなプロ集団のまじめなプロジェクトは、当たり前ですが大混乱はしません。まともなテスト項目を設計していないからこそ、プロジェクトの遅れが後工程にならないと分からず、どうしようもなくなって、爆発してしまうのです……。

　テスト項目をきちんと設計していないプロジェクトは、デバッグがどこまで完了したのか、定量的に把握できていないはずです。テスト項目の総数が分からず、何パーセント終わったか測定できません。そんな混沌プロジェクトでは、人員投入をする前に、すべての作業をやめて以下を実施する必要があります。

各エンジニアが担当している機能のテスト項目を作成し、ドキュメント化する。
作成したテスト項目の妥当性を第三者がチェックする。
テスト項目の総数をカウントする。デバッグ工程の進ちょくは、正しく実行できたテスト項目数で管理する。
回帰テストとして、開発するソフトウェア全体をチェックするテスト項目を作成する。この回帰テストは、バグ修正のたびに必ず実行させるので、自動化しておくこと。

　テスト項目の設計は、対象ソフトウェアの「操作説明書」をベースにして、助っ人に作成してもらうことも可能ですが、テスト項目をキチンと設計していないプロジェクトにまともな「操作説明書」があるとは思えません。

　世の中の工業製品で、唯一、品質基準や安全基準が存在しないのがソフトウェアです。実際のソフトウェアの品質制御では、テスト項目の設計が非常に重要ですが、品質管理だけでなく、リスク管理や遅延回復でも、テスト項目をちゃんと設計しているかどうかが非常に重要な鍵になるのです。（次回に続く）

【筆者紹介】

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

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

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