【番外編】見積もりミスによるリスクを契約条件で回避する方法（その1）：山浦恒央の“くみこみ”な話（45）（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人でできるデスマーチ・プロジェクトの対処法（その1）
⇒	プロジェクト管理者が1人でできるデスマーチ・プロジェクトの対処法（その2）

　ここまでの内容で、正確に見積もる方法、見積もり値の使い方、そして、FP試算法、トリアージュ、SLIMの3つの技法を駆使したデスマーチ・プロジェクトの対処法を理解いただけたでしょうか。これらは、いずれも見積もりミス対策の“正攻法”といえます。

　今回は少し視点を変えて、契約条件の面から、実践できる見積もりミス対策を検討していきます。意外に効果がありますので、皆さんのプロジェクトでも適用してみてください。

1．一括請負契約と業務派遣契約

　ソフトウェア開発は、発注側と受注側（開発側）に分かれて、契約を結ぶのが一般的です。契約条件にはさまざまなものがありますが、やはり、お金を出す発注側が有利になっていることがほとんどです。こうしたソフトウェア開発に関わる契約条件を工夫すれば、見積もりミスによるリスクを軽減できる場合が少なくありません。

　一般的に、ソフトウェア開発の契約は、「一括請負契約」と「業務支援契約」に大別できます。

（1）一括請負契約　開発側のプロジェクトの成果物が、支払いの対象となる契約です。一言でいうと「（例）このソフトウェアを1億3千万円で開発します」という契約で、現在のソフトウェア開発における契約の主流がこれです。見積もりに誤差があった場合（見積もり誤差とは、もちろん、過小見積もりのことです）、そのリスクは開発側の負担になることがほとんどです。一括請負契約では、“開発側のリスク軽減”が大きなカギになります。

（2）業務支援契約　開発側が派遣した人員の労働に対し、発注側が対価を支払う契約です。いわゆる、“人員派遣”であり、派遣された人員は、発注側の人員として働きます。つまり、人員を使う責任や進捗（しんちょく）管理のリスクは発注側にあります。この契約形態の場合、派遣側（開発側）は、基本的に見積もりミスによるリスクを負うことはありません。

　前述の通り、現在のソフトウェア開発における契約の主流は、一括請負契約です。本稿では、一括請負契約のリスク軽減対策について解説します。

2．一括請負契約でのコスト

　開発側が発注側に提示する請負金額（一括請負契約での見積もりの内訳）のイメージを図1に示します。

図1　一括請負契約での見積もりの内訳（イメージ）

　見積もり額の提示では、実際にコストを見積もり（これは、正直に見積もった値であり、いわゆる裏帳簿に相当します）、そこへ、リスクに対する保険分を上乗せし、さらに利益を積み上げるのが普通です。この請負金額の算出プロセスは、会社ごとに決まったものがあるかと思います。

　最初に見積もったコストの範囲内で開発が完了した場合、利益は「想定利益＋リスク分」となりますが、こんな例は、“白いカラス”や“野心のない政治家”を探すより難しいでしょう。通常はスケジュールが徐々に遅れ、以下のステップをたどることになります。

1. 遅延や機能拡張分は、リスクとして上乗せした金額から支出する
2. それでも完了できない場合は、利益分を取り崩す
3. 最悪の場合（でも、最も多い）、コストを取り崩す

　コストを取り崩して開発費を捻出するようなプロジェクトは、もちろん、大混乱します。ある意味、デスマーチ・プロジェクトの「約束された道のり」と言えます。

　発注側は、「契約で支払額を決めたのだから、こちらは1円も余分に払わないよ」とマイナス30℃の冷たい態度を取ることもできるのですが、この状態になると、開発側が実装機能を削減したり、品質を犠牲にしたりする可能性が非常に大きくなるので、決して傍観はできません。こんなソフトウェアを納入されても、使いものにはなりません。もちろん、スケジュールが大幅に遅延しますので、発注側のビジネス計画も大きな打撃を受けます。そして、デスマーチ・プロジェクトの典型的な末路である「共倒れ」に至ります……。

3．虚々実々の駆け引き

　先ほどの図1では、開発側は大きめに規模を見積もり、さらに、リスクを上乗せして、予期せぬ規模拡張（実は、毎回、発注側に無理難題をのまされ、規模が大きくなるのですが……）に備えようとします。一方の発注側は、そんなことは十分に承知しており、上乗せ分を圧縮しようと躍起になります。

　このあたりの虚々実々の駆け引きは、技術論に基づいたソフトウェアエンジニア同士の話し合いではなく、“バナナのたたき売り”や“ネットオークション”のような雰囲気になります。相手の心理状態の推理合戦や腹の探り合いの様相を呈し、押しが強くて、声の大きい方が有利になります。

　発注側と開発側が見積もり値を擦り合わせ、コストとスケジュールに合意してから作業に取り掛かるのが「正しいソフトウェア開発」なのですが、この通りに進まないことも少なくありません。なかなか条件が折り合わず、双方の営業担当がにらみ合った状態で数カ月もムダに時間が過ぎてしまう……。時間が何よりも貴重なソフトウェア開発では、そんな状態を回避するため、契約が未締結なのにもかかわらず、開発側と発注側の双方の開発担当部署で、“先に開発を進める”ケースが（非常に多く）見受けられます。

納入日はどうしてもズラせない。まぁ、そのうち契約条件は決まるだろうから、時間を有効に使うためにも、先に始めちゃおう！

というわけです。

　この“ソフトウェア開発版の見切り発車”は、開発側のリスクが非常に大きいため、絶対に避けるべきです。しかし、付き合いの長い会社同士では、恒常的に、慣例的に、こうした見切り発車が行われています……。