【番外編】見積もりミスによるリスクを契約条件で回避する方法（その2）：山浦恒央の“くみこみ”な話（46）
前回に引き続き、“契約条件”の面から実践できる見積もりミス対策を検討する。客観性のある見積もり技法を2つ以上学び、その技法の具体的な適用方法を習得し、さらに、契約面からも見積もりミスに対処できるようになれば、あなたは立派な「見積もりの“黒帯”」だ！
「見積もり」は、ソフトウェア開発における大きなテーマであり、ソフトウェア工学における最重要課題の1つでもあります。
今回お届けしている“見積もり・シリーズ”では、「見積もりの目的（正確に見積もるだけでは不十分）」「見積もりの具体的な方法（精度を上げるため、少なくとも、2つ以上の方法で見積もる必要がある）」「見積もりの応用（見積もり値に合わせる制御と再見積もり）」「見積もりの調整（状況に応じて開発量とスケジュールを再見積もりしなければならない）」について、具体的に解説していきます。
“見積もり・シリーズ”の振り返り
本シリーズでは、見積もり技法の基本として、過去の類似プロジェクトから予測する方法（類推法の一種）、LOC（Lines of Code）やFP（Function Point）を計測する方法（積み上げ法の一種）、SLIM（Software Life Cycle Management）による見積もり法（パラメトリックス法の一種）の3つを具体的に解説してきました。また、FP試算法、トリアージュ、SLIMの3つの技法を駆使してデスマーチ・プロジェクトに正面から立ち向かう方法も取り上げました。
今回は、前回に引き続き、少し視点を替えて契約条件の面から見積もり問題に対処する方法を紹介します。客観性のある見積もり技法を2つ以上学び、その技法の具体的な適用方法を習得し、さらに、契約面からも見積もりミスに対処できるようになれば、立派な「見積もりの“黒帯”」といえます。
契約面での見積もりミス対応は、意外に大きな“保険”としての効果が期待できますので、ぜひ応用してみてください。
1．一括請負契約とプログラマー残酷物語
ソフトウェア開発の一括請負契約で最も多い形態は、事前に総開発金額を決め、実際の費用がそれを超えようが、下回ろうが、発注側が支払う金額は“不変”という「定額請負契約」です。前回のコラムでも説明した通り、この契約形態での発注側のリスクは非常に少なく、受注側、つまり、開発側が一方的に大きなリスクを背負うことになります。
――ソフトウェア関係の技術展示会や国内外の学会など、いろいろな企業のソフトウェア開発エンジニアが集まる場では、午前と午後のセミナーで最新の技術論や開発方法論を話し合い、熱の入った討論をしますが、夕食後の懇親会では、アルコールが口を軽くするためか、三々五々、会場のあちらこちらで生々しい本音トークが始まります。
例えば……、
3年前、ウチの会社が請け負った『プログラムの変換』プロジェクトだけど、プロジェクト・マネジャーが、『自動変換できるんで、検証も含めて6人で6カ月もあれば楽勝で開発できる』と思って、6人×6月＝36人月分の金額に、利益を乗せて4000万円で契約したんだよ。でもね、実際にやってみたら、完全な見込み違いで、全て手で変換しなきゃならず、20人で26カ月も掛かったんだ。結局、4000万円もらうのに、5億2千万円も掛かってしまったんだよね。会社の信用に関わるんで、大損しても最後までやり通したけれど……。きっと、アメリカの開発会社だったら、違約金を支払って、途中放棄するんだろうな〜。
などという「実話、プロジェクト残酷物語」が披露され、周囲でそれを聞いているエンジニアたち（主に、プロジェクトマネジャー）は、ビールの入ったグラスを片手に、溜息をつきながら大きくうなずき、
それは大変だったねぇ。でも、ウチはもっとひどいよ。去年のことだけどね……。
と、さらなる残酷物語を語り始めます。
こうした残酷物語で最も多いのは、“見積もりミス”に関する話題です。ソフトウェア開発が、趣味からビジネスへと遷移してから半世紀もの時が経過しました。しかし、過去50年間、開発側のプロジェクトマネジャーは、少しでも見積もりミスのリスクを軽減するため、開発規模を50％水増しして発注側に提示し、そんなことは先刻承知の発注側は、いきなり半額に値切るなど、技術力ではなく政治力やハッタリを駆使し、死力を尽くした駆け引きを展開してきました……（最後には、お金を払う発注側に強く押し切られ、不利な条件での開発を強いられます）。
2．実費償還契約
見積もりミスのリスクが高い定額請負契約の逆が、「実費償還契約」です。これは、実際に掛かったコストに利益を上乗せし、その金額を発注側が開発側に支払う方式です。この契約方式ですと、開発側は絶対に赤字になりません。定額請負契約とは逆に、発注側のリスクが非常に高くなります。
「ビジネスでは、お金を出す側が圧倒的に威張っているのに、わざわざこんな不利な契約をすることがあるのか？」と感じる人も多いと思いますが、答えは「イエス」です。例えば、化学プラント建設、地下鉄工事のように、何年にもわたる大規模な建設では、建築資材などの材料価格が数年後にどのように変化するかが予測できないため、実費償還契約を採用するところが多いようです。
大規模プラント建設のような場合、将来の材料費の価格動向が読めないため、実費償還契約もやむを得ないでしょうが、ソフトウェア開発のコスト計算では、「開発原価＝人件費」と考えることが多く（人件費を1人1カ月100万円とすると、PCの購入コストは無視できるほど小さくなります）、材料費をゼロと見なすため、実費償還契約は、まず、あり得ません（今まで、実施例を聞いたことがありません）。そのため、ソフトウェア開発における見積もりミスは（特に、1年未満の短期プロジェクトの場合）、純粋に開発側の見積もり能力や経験不足が原因だといえます。
3．定額請負契約と実費償還契約の折衷案
ソフトウェア開発における定額請負契約では、開発側の負担が非常に大きくなります。このリスクを少しでも軽減する手段として、定額請負契約と実費償還契約の折衷案、あるいは、「範囲付きの実費償還契約」があります。
これは、全部のコストを発注側が無限に負担するのではなく、「事前に開発コストを決め、実際の開発費用が合意した金額を超過した場合、超過分の一部を発注側（顧客）に負担してもらい、逆に安く開発できた場合は、浮いた差額分を発注側と開発側で折半する」というものです。
図1で具体的に説明します。
1億円で請け負って、実際には9600万円で完成した場合、浮いた400万円（図1の左の水色の部分）を双方で分配します。しかし、こんなにラッキーなお話は、現実の世界では、宝くじを10枚買って10枚とも当たりくじを引くくらいあり得ません。
よくあるのが、超過して、1億2000万円も掛かってしまったというケースです。請負額の1億円の中の利益幅が2000万円とすると、この場合の利益はゼロです。小さな開発会社なら翌日に倒産しそうです。万一、実際に倒産して担当エンジニアたちが散り散りに去ってしまうと……、完成したソフトウェアの保守や将来のバージョンアップ対応がスムーズに受けられない可能性も出てきます。このように長い目で見てみると、発注側も大きな不利益を被ることになります。こうした双方のリスクを軽減する手段が、範囲付きの実費償還契約です。例えば、「コストの超過額が定額の20％以内ならば、お互いに超過分を半分ずつ支払いましょう」というように取り決めます。ただし、無制限に超過分を負担するのでは、発注側もたまりませんので、併せて「20％を越えた分は、開発側が全額を負担すること」と取り決めるとよいでしょう。
定額請負契約と範囲付きの実費償還契約は、パーティーの開始時間に似ています。パーティーの案内状に、「19時開始」と書いてあれば、きっかり19時（あるいは、19時プラスマイナス30秒）に会場へ到着しなければなりません。ピッタリの時間に会場の最寄り駅に到着する電車がない場合、早めに行き、どこかで時間をつぶすことになります。正直、時間がもったいないですし、結構、面倒です。今年の夏のような猛暑日は夜間でも熱気がこもるため、ネクタイとジャケット着用の暑苦しい格好をしていると、時間つぶしも楽ではありません。こうした「時間が決まっているパーティー」は定額請負方式に似ています。
一方、範囲付きの実費償還契約は、「開場19時、開宴19時30分」というようなパーティーに相当します。「何時きっかりに開始」という形式とは異なり、開場から開宴まで30分の幅があるため、参加者は自分の都合で会場へ向かうことができます。ムダに時間をつぶす必要はありません。参加者に優しい方式ですね。
4．範囲付きの実費償還契約
範囲付きの実費償還契約は、開発側には非常にありがたい方式ですが、以下のような理由から、発注側はなかなか「ウン」と言ってくれません。
ケース（1）：
ウチは、定額契約が基本なので、後で値引きや支払いを要求されても困るんだよ！
＞＞ケース（1）の対策：
利益金の分配やコスト超過分の半額負担は、そのバージョンの期間内に支払ったり、受領したりするのではなく、次バージョンでの開発費用を値引きしたり、上乗せしたりすることで反映させます。
ケース（2）：
「浮いた金額を償還する」と言いながら、実際には必ず超過するんじゃないの？
＞＞ケース（2）の対策：
開発側が提示した見積もり値に“客観性”がないと、必ずこのように言われます。見積もり値（特に、総ステップ数などの規模見積もり）の前提条件や見積もり技法、算出手順に客観性があり、開発の進ちょく状況もガラス張りになっていないと、発注側の信頼を得られません。ここで威力を発揮するのが、この見積もりシリーズで解説したFPによる見積もり技法です。FP法の客観性と算出手順の明快さには、大きな説得力があります。
今回は、前回に引き続き、契約条件から見積もりを検討しました。見積もりミスを少しでも減らすには、（1）見積もり技法をブラッシュアップする、（2）複数の見積もり技法を導入する、（3）経験を積む、に加え、“契約の条件”もきちんと考慮すべきです。
たった1つの特別な技法や方式（いわゆる、「銀の弾丸」）だけで見積もりミスを完全になくすことはできません。航空機の設計では、重量を減らすために、いろいろな部品を少しずつ軽量化することで、全体としての目標となる重量削減を達成します。ソフトウェアの見積もりもこれと同様、いろいろな方法や技法を駆使して、少しずつ、リスクを下げることが必要です。
ソフトウェア開発での最大の問題、見積もりミスが少しでも改善され、デスマーチ・プロジェクトが1つでも少なくなることを祈っています。（次回に続く）
東海大学 大学院 組込み技術研究科 准教授（工学博士）
関連キーワード
デスマーチ | 組み込み開発 | 組み込み開発プロセス改善 | 組み込み開発の混沌から抜け出そう | 現場の声からプロセス改善を深掘りする | 山浦恒央の“くみこみ”な話 | バグ | 開発プロセス | ソフトウェアテスト | システム開発
Copyright © ITmedia, Inc. All Rights Reserved.
デスマーチ・プロジェクトでの正しい手の抜き方