プロジェクト ミューズ：バイリンガルプロジェクトは辛いよ　～その8～　固定金額契約と単金契約

主な契約形体として、固定金額契約（Fixed Price Contract)と単金契約（Time & Material-base contract)があります。現在のプロジェクトミューズは、単金契約になっています。

単金契約は、どれだけの作業量になるか事前の見積りができない場合、委託業務内容を定義せずいろいろな業務を委託した場合、納期までに成果物を仕上げるという結果重視では無く、作業過程に着目するタイプの業務に適しています。

一方、アプリケーション開発のように、納期があり、実装してほしい機能が明確な場合には固定金額契約にしたほうが発注側のリスク管理負担が減ります。

なぜプロジェクトミューズは単金契約なのか。

プロジェクトがスタートした昨年10月の時点では、業務委託内容が今一つ明確になっていませんでした。開発を任せるということがはっきりしていなかったのです。元々パッケージソフトを一部改修するカスタマイズ案件だったので、このパッケージソフトに関する問い合わせに回答してもらうというのが当初の委託業務内容でした。ところがプロジェクトが進むにつれて、カスタマイズ案件を全面的に委託しなければならない状況になってきました。それには製品に関する知識の不足、特殊な開発言語という要素があるのですが、それはさておいて、、、、。

プロジェクトはいつの間にか「カスタマイズ＝開発案件」にその性格を変えていましたが、途中で固定金額契約に切り替えることができなかったのです。その理由は：

固定金額契約にするためには、業務依頼内容を明確にし、それに基づく作業量の見積りをしなければ、金額が提案できません。この場合の業務依頼内容とは、どの顧客要件は製品標準機能で対応可能で、どの顧客要件はカスタマイズ（開発）が必要かを見極めるということです。
プロジェクトミューズにおいて、発注側は製品知識不足のためにどの顧客要件がカスタマイズを必要としているのかが判断できなかったのです。顧客要件を開発要件に落とし込む部分ができない発注者。一方カスタマイズを専門とするこの請負業者はカスタマイズ要件を明確に提示してもらわないと開発範囲（スコープ）が決まらないため、固定金額契約はできないと主張しました。そしてそのまま単金ベースで進めざるを得ない状況が続いています。

単金ベースだと、ずるずると工期が延びても請負側にはまったくリスクがありません。歪曲した言い方をするとわざと機能を実装せず、工期を長引かせることによって自分達の収入を高めるということすら出来てしまうのです。
「製品に関する質問に回答してもらう」というコンサルティングが委託業務だった時期は単金ベースでも理にかなっていました。
ところが、いざ納期、実装内容、品質を問わなければならない開発にプロジェクトが様変わりした時点で固定金額契約に切り替えるべきだったのです。

両者の違いについて、次回、あらためて比較してみましょう。