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

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

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

前回までの振り返り

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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