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

見積もりの知識と技法を駆使した「デスマーチ・プロジェクト」への対処法を検討する。今回は、発注側と開発側の双方が満足できるソフトウェア開発の手順を紹介。この手順に従えば、デスマーチ・プロジェクトに対処できるはずだ！

[山浦恒央 東海大学 大学院 組込み技術研究科 准教授（工学博士），＠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：最短開発期間の算出）

　そして、前回お届けした「見積もりの進化と客の入らないレストラン」では、以下に示す「見積もりプロセスの進化の過程」を解説しました。

• 第1段階：見積もり精度の向上　
  見積もり精度の向上を目指そうという意識はあるが、組織として共通の見積もりプロセスがない（ソフトウェア開発組織全体の90％以上がこの段階？）
• 第2段階：見積もり値の適用法の改善　
  見積もり値の適用法を改善しようと考え、現実のプロジェクトを見積もり値に合わせるよう制御する（見積もりの“黒帯”レベルだが自分のプロジェクトのことしか考えてない）
• 第3段階：プロジェクト成功のための見積もり　
  プロジェクトを成功させるために、見積もり値を使う（発注側と開発側の両方が満足できる・成功するプロジェクト制御を目指す）

　今回は、見積もりプロセスの進化の過程のうち、最終段階（第3段階：プロジェクト成功のための見積もり）をさらに掘り下げていきます。

第3段階の見積もりとは（第1、2段階のおさらい）

　「デスマーチ・プロジェクト」を一言でいうと、“常識的な開発期間の半分以下でソフトウェアを作れ”と強制されたプロジェクトです。要求通りのスケジュールをそのまま受け入れたのでは、確実にプロジェクトは失敗してしまいます。第3段階の見積もりが、第1、2段階と決定的に違うのは、「発注側と開発側の両方が満足できる（成功する）プロジェクト制御」を目指していることです。

　見積もりレベルが第1段階にしか達していないプロジェクトでは、発注側の無理なスケジュールをそのままのみ、長時間の残業や休日出勤を重ねて、何とか間に合わせようとします。しかし、「力まかせの正面攻撃」で成功したソフトウェア開発プロジェクトは有史以来1つも存在しません。どのプロジェクトでも「当たって砕けろ」的に頑張るのですが、皆、本当に当たって砕けてしまいます……。

　ムチャな要求をした発注側は、新しくビジネスを展開する予定（だったとします）でソフトウェアを発注しましたが、リリースが何カ月も遅れたことにより（あるいは、途中で打ち切りになったことで）、新規事業の展開が思うように進まず、結果的に大損害を被ることになります。一方の開発側は、何とかスケジュール通りに納品しようとして、無理な超過勤務を重ね、人員を増強したため、大赤字になります――。そうです、“誰のためにもならないプログラム開発”。これが、世界中のデスマーチ・プロジェクトに共通した現状です。

　第2段階になると、少し状況は良くなります。この段階における開発側は、発注側が要求する機能と、割り当てられたスケジュールおよびコストを詳細に分析し、“提示された条件（コストと期間）で本当に要求された全機能を開発することができるのか”を検討します。もしも「発注側の条件をそのままのむと『必ず失敗する』」という結論になれば、「確実な危険」を回避するため、開発を辞退します。この進化の段階では、“共倒れ”という最悪の事態は避けられますが、ある意味、ビジネスチャンスを逃してしまっている残念な状態ともいえます。

　今回紹介する第3段階では、「発注側と開発側の両方が満足できるプロジェクト制御（＝ソフトウェア開発）」を目指します。これが、デスマーチ・プロジェクト対策の究極の対処法です。

発注側と開発側の両方が満足できる・成功するソフトウェア開発とは

　図1に、発注側と開発側の両方が満足できる（成功する）ソフトウェアを開発する手順を示します。この手順に従えば、プロジェクト管理者が1人で頑張るだけで、デスマーチ・プロジェクトに対処できます。

図1　プロジェクト管理者が1人で可能なデスマーチへの対処法

　この手順では、これまで本コラムで解説してきた「FP試算法」「SLIM」「トリアージュ」だけを適用しています（実は、本コラムでこれらを取り上げてきたのは、このデスマーチ対処法を解説するためだったのです）。

　それでは、次ページで図1に示した各ステップを解説します。