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

見積もりの知識と技法を駆使した「デスマーチ・プロジェクト」への対処法を検討する。今回は、プロジェクト管理者が1人で実施できる6つのステップについて順を追って詳しく紹介する。

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

　「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。

　今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。

“見積もり・シリーズ”の振り返り

　これまで、見積もり技法の基本として、過去の類似プロジェクトから予測する方法（類推法の一種）、LOC（Lines of Code）やFP（Function Point）を計測する方法（積み上げ法の一種）、SLIM（Software Life Cycle Management）による見積もり法（パラメトリックス法の一種）の3つを具体的に解説してきました。

　特にSLIMの解説では、簡単に「工数（コスト）」「開発期間（月）」「機能総数（規模）」「（プロセス）生産性」の4つの相互関係を分析できるよう、マイクロソフトの表計算ソフト「Excel」の計算式を使った算出方法を紹介しました。SLIMには「開発エンジニアを何千人・何万人投入したとしても、『この期間（最短開発期間）』よりも絶対に短く開発することはできない」という考え方がありますが、これについてもExcelを使った算出方法を紹介しました。

	関連記事：
⇒	ついに登場！ 究極の見積もり技法（その1：解説編）
⇒	ついに登場！ 究極の見積もり技法（その2：実践編）
⇒	ついに登場！ 究極の見積もり技法（その3：最短開発期間）
⇒	ついに登場！ 究極の見積もり技法（その4：最短開発期間の算出）

　デスマーチ・プロジェクト対策の“鍵”となるのが、これまで紹介してきたFP試算法、トリアージュ、SLIMの3つの技法を駆使して、「発注側が要求する日程では実現不可能であることの証明と代替案」を提示することです。

　前回のコラムでは、以下のステップを挙げました。今回は、これら6つのステップの詳細を説明します。全てのステップは、プロジェクト管理者が1人で実施可能であり、デスマーチ・プロジェクトに1人で立ち向かうことができる方法となります。

1. FP試算法により、開発規模を見積もる
2. 算出したFPをLOCに変換する
3. 開発規模（LOC）をSLIMの計算式に代入して最短開発期間を計算する。提示された日程の方が長い場合は、開発を続行。提示された日程の方が短い場合は、次の4．を実施
4. SLIMを基に、提示されたスケジュールとコストでは要求通りのソフトウェアは開発できないと発注側に示す
5. 発注側に対し、出荷日と機能のどちらの優先度が高いかを問い合わせる
6. 機能を削減して出荷日を厳守する、あるいは出荷日を後ろにずらして全機能を確保するなどの代替案を提示する。この場合、SLIMの計算式から開発規模、人月、日程を求める

1．FP試算法により、開発規模を見積もる

　この段階では、大まかな機能が分かっており、かつ、各機能に対して、トリアージュ（詳細は、第10回「サボりのモジュール化・サボる部分の独立化」を参照のこと）を適用し、要求される実装機能に「必須」「必要」「希望」の3段階の優先順位が付けられているはずです。これをベースに、以下の3つをFP試算法で見積もります。

（1）必須＋必要＋希望機能（フルスペック）を開発する場合のFP　
（2）必須＋必要機能だけを開発する場合のFP　
（3）必須機能だけを開発する場合のFP

　可能であれば、過去の類似プロジェクトのデータを参考にした類推法でも見積もり値を算出し、見積もり精度を上げたいところです。

　この規模見積もりにおいて、「うちは今まで、FPで見積もった経験がないので、LOC（ソースコード行数）で見積もればいいや」と考えてはなりません。必ず、FPで見積もる必要があります。それはなぜか？ 以下の2つの理由によります。

• 理由（1）：LOC見積もりは客観性に欠ける　
  発注側を説得する際、極めて重要なのが、客観性のあるデータに対して客観性のある見積もり技法を適用することです。開発側に規模を水増しする余地がなく、また、発注側が見積もっても同じ値になることが必須なのです。この目的で使えるのが、FP試算法とSLIMです。FP試算法による見積もりは、客観的な前提条件を発注側にきちんと提示できるため、発注側は文句をつけられません
• 理由（2）：LOC見積もりは精度が低い　
  LOC見積もりは、FPに比べると、精度で圧倒的に劣ります。特に、大ざっぱな機能しか決まっていない開発の初期段階では、LOCで見積もった規模が現実と数倍違うことも珍しくありません

2．算出したFPをLOCに変換する

　FPは、機能の規模（正確には、ファイルやデータに注目して、開発規模を計測した値）であり、実際に開発で使うプログラミング言語のLOCに変換しないとその規模を実感できません。

　変換の目安として、1FPは、COBOLで記述すると100行、C++では50行、Visual Basicでは70行、Javaでは35行といわれています。各プロジェクトにはクセや傾向がありますので、過去の統計データにより、変換係数を補正してください。

3．開発規模（LOC）をSLIMの計算式に代入して最短開発期間を計算する

　次のステップでは、LOCに変換した開発規模をSLIMの計算式に代入し、その規模を開発する場合に要する最も短い時間（最短開発期間）を計算します。

　Excelに埋め込んだSLIMの計算式（詳細は、第41回「ついに登場！ 究極の見積もり技法（その4：最短開発期間の算出）」を参照のこと）に変換したLOCを入れて、「必須＋必要＋希望（フルスペック）」機能、「必須＋必要」機能、「必須」機能だけの3通りについて、最短開発期間を計算します。その結果、最短開発期間は、以下のようになるはずです。

（1）フルスペックの最短開発期間 < 発注側提案の日程　
　これは、必須＋必要＋希望の全ての機能を開発できる時間的余裕のある理想的なプロジェクトです。こんなにすばらしい開発に参画できることを神に感謝し、粛々と設計作業に取り掛かりましょう。……と言いながら、現実にはこんな開発日程は30年前に死に絶えています。50歳以上のソフトウェア開発技術者に聞くと、当時の状況をソフトウェア版「古事記」として語ってくれるでしょう。　

（2）必須機能の最短開発期間 ≦ 発注側提案の日程 ≦ フルスペックの最短開発期間　
　現代のソフトウェア開発の75％がここに入ると思います。最短開発期間とは、“品質はボロボロだけれど、最低限の機能を実装できる期間”であり、ある程度の品質を確保するためには、数十パーセント増しの時間が必要です。つまり、品質と日程を確保するなら、大幅な機能削減をせねばなりませんし、日程と機能を確保するなら、品質が犠牲になります。機能と品質の両方を確保するなら、日程を大幅にずらす必要があります。どの戦略を採用するか、また、どの機能を削減するか、日程はどう変わるかなどの詳細は、次の4、5、6のステップで分析します。　

（3）発注側提案の日程 < 必須機能の最短開発期間　
　開発プロジェクトが立ち上がった30分後に大失敗が確定するのがこれです。現代のソフトウェア開発の25％がこれでしょう。エリート技術者を1万人投入したとしても、必要最低限の機能を開発する時間がないプロジェクトであり、発注側と開発側の両方が確実に共倒れします。プロジェクト管理者としては、この状況は絶対に避けねばなりません。救済策は、次の4、5、6のステップしかありません。