プロジェクト管理者が1人でできるデスマーチ・プロジェクトの対処法（その2）：山浦恒央の“くみこみ”な話（44）（2/2 ページ）

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授（工学博士），＠IT MONOist]

4．SLIMを基に、要求日程での開発は不可能であることを示す

　ここは、前述の1、2、3のステップで得られたデータ、計算方式、結果を発注側に提示して、オリジナルの開発計画が非現実的（というより、不可能）であることを理解してもらうステップです。ある意味、これが“最難関”といえます。発注側を説得する材料には以下のものがあります。

（1）SLIMにより、不可能であることは明らか　
　最も説得力のあるのがSLIMを使ったデータでしょう。SLIMで計算した最短開発期間より短い日程で開発が成功したプロジェクトは、世界の6300プロジェクトの中で“ゼロ”であることを説明し、要求日程が不可能であることを理解してもらいましょう。　

（2）ソフトウェア開発には順序性がある　
　家を建てる場合、基礎工事が終わって柱を立て、屋根を作るように、ソフトウェア開発でも、仕様決定→設計→コーディング→デバッグ→テストという厳然たる順序性があります。1つのフェーズが終わらないと次へは行けません。従って、分業は簡単ではなく、増員しても劇的な効果は期待できません。　

（3）テストには時間がかかる　
　世界のトッププロが完璧なテスト項目を設計したとしても、完全なテストは不可能ですし、品質を上げるには一定の時間がかります。特に、組み合わせテスト（例えば、携帯電話で画像データをダウンロードしている最中に、メールを受信し、直後に音声通話を着信した場合）、長時間耐久テスト（48時間の連続運転など）、過負荷テスト（実装メモリが最少なのに、最大構成で稼働させる）を実施するのは簡単ではありません。大勢のユーザーに長時間使ってもらわないと、バグをたたき出せません。　

（4）ソフトウェア開発では、「魔法」と「奇跡」はない　
　ソフトウェアは目に見えないので、複雑性や規模を感覚的に把握するのは非常に困難です。当然、魔法のような技術があって、呪文を唱えれば、たちどころにプログラムが完成するなどということはあり得ませんが、中には「ソフトウェアであれば何でもできてしまうのでは？」と考える人も少なくありません。また、最初に設計・コーディングしたプログラムを一度も手直しすることなく、全て正常に機能するというソフトウェア版「奇跡のホールインワン」も、これまでの経験や実績を考えると非現実的です。しかしながら、苦しいプロジェクトほど、なぜか魅入られたように「奇跡」や「幸運」に期待してしまい、最後は、奇跡を織り込んだ日程を立ててしまうこともあります。正気の沙汰ではありませんが、デスマーチ・プロジェクトは正気ではやっていけません。

5．発注側に出荷日と機能のどちらの優先度が高いかを問い合わせる

　ここまでくれば、「国家元首同士の合意」は取れている状態なので、次は、両国外務省の役人による「事務方レベルの協議」に移ります。

　日程を最優先にするならば、一部の機能を削減する必要があります。必須、必要、希望の3つに分けた機能のうち、どれを第2バージョン以降に回すかを発注側と協議し、FP試算法を使って、機能削減版の規模を再見積もりします。

　フルスペックを実装することに意味があるのならば、上記「1．FP試算法により、開発規模を見積もる」の（1）で見積もったFPをベースに、SLIMで日程を計算します。現実には、「フルスペック死守」というケースはほとんどありませんが、発注側がソフトウェア開発に不慣れな場合は、「何が何でも、全機能を作ってほしい」と要求してきます。製品戦略にもよるのでしょうが、日本の電気電子機器は圧倒的にスペック過多です。例えば、家庭用FAXのマニュアルを読んでいると、一生使わないような複雑怪奇な機能まで搭載してあり、唯一できないのは「ご飯を炊くことだけか……」と思ってしまいます。ソフトウェアにおいても、余計なスペックを削ぎ落とし、流線型化を考えるべきです。

6．新しい開発規模、人月、日程をFP試算法とSLIMから計算

　「事務方レベル折衝」の最終段階がこのステップです。日程優先、機能優先により、機能削減や日程延長した案を幾つか出し、SLIMの計算式に代入して、開発規模、人月（コスト）、日程を算出します。この中から、最適の案を発注側に選んでもらいます。

　以上が、要求仕様定義フェーズにおける「デスマーチ・プロジェクトへの対処法」です。以降、設計フェーズに入ると、プロジェクト管理者は周期的に（最低、週に1回）見積もりを繰り返し、新しいスケジュールとコスト（人月）の通りにプロジェクトが進行するようにコントロールします。

---

　今回は、デスマーチ・プロジェクトへの具体的な対処法として、FP試算法、トリアージュ、SLIMを適用した見積もりのステップを解説しました。通常のデスマーチ・プロジェクトでは、発注側と開発側の双方が確実に共倒れしますが、ここに挙げた対処法により、両方が満足し、成功するソフトウェア開発が可能になります。今回紹介した1〜6のステップは、プロジェクト管理者が1人でできることです。これを活用して頂き、デスマーチ・プロジェクトが1つでも少なくなれば幸いです。（次回に続く）

【 筆者紹介 】

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

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

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