請負契約と準委任契約、つまり固定価格で請けるか、かかった時間で精算するかという選択は、たいていリスクをめぐる選択として説明されます。その説明そのものは正しいのですが、直後に扱いを誤ります。発注側も受注側も、リスクは移動するだけであることを忘れ、どちらかを選べばリスクが消えると思い込んでしまうからです。

リスクは消えません。請負契約では、見積もりが外れるリスクをベンダーが背負い、そのリスク分を提示する金額の中に織り込みます。準委任契約では、同じリスクを発注者が背負います。問われているのは、どちらの契約形態が不確実性を消してくれるかではありません。どちらの当事者がその不確実性を扱いやすい立場にいるのか、そして移転の対価を払う価値があるのか、この二点です。

どちらが機能するかを言い当てる判定基準： 「完了」が何を意味するのかを、二人の人間が到達の可否で一致できる程度の細かさで書き出せますか。書き出せるなら、請負契約という選択肢は使えますし、たいていは妥当です。書き出せないなら、請負契約は曖昧さを取り除いてくれません。将来のあらゆる意見の相違を、技術的な会話ではなく商談へ変えてしまうだけです。

請負契約が実際に買っているもの

買えているのは請求額についての確実性だけで、それ以外は何も買えていません。とくに、出来上がるものの中身、納期、品質についての確実性は買えていません。発注側はこの三つも一括で付いてくると考えがちですが、付いてきません。

そして、この確実性には値段が付いています。請負で金額を出すベンダーは、超過分を自分で飲み込む以上、必ずリスク引当を上乗せします。その上乗せ幅は、仕様が曖昧であるほど大きくなります。範囲がきちんと定まった仕事なら、上乗せはささやかで済みます。輪郭のぼやけた仕事なら、作業そのものの費用に迫ることさえあり、しかもリスクが現実になったかどうかに関係なく、あなたはその分を支払います。

二つ目の費用は、金額ではなく行動に現れます。金額が固定された瞬間から、あらゆる曖昧さは作業が少なくなる方向で解釈されるようになります。そこにベンダーの利益があるからです。これは不誠実さではなく、契約そのものが作り出した誘因です。実装の途中でより良いやり方に気づいたベンダーには、それを持ち出す動機がありません。要件が間違っていたと気づいた発注者の前に現れるのは、会話ではなく変更依頼です。

請負が力を発揮するのは、本当に境界を引ける仕事です。移行元と移行先がわかっている移行、ドキュメントの整ったAPIとの連携、合意済みのデザインに沿って作る決まった画面群などがこれにあたります。逆に、探索的な要素を含む仕事にはまるで向きません。

準委任契約のほうが安く済む場面

直感に反しますが、安く済む場面はよくあります。リスク引当を払わずに済み、変更依頼のやり取りにかかる費用も払わずに済むからです。

向いているのは、スコープが正当な理由で変わっていく仕事です。利用者の行動次第で方向が決まる最初のバージョン、誰もドキュメントを書いていないシステムとの連携、中を見るまで状態のわからないコードベースの立て直しなどがこれにあたります。こうした案件で請負の金額を出すことは、要するに推測に対して固定価格を付けることにほかなりません。

準委任が発注者に求めるのは、関与です。関与のない準委任は、終わりの見えない請求書に変わります。典型的な失敗の形は、先週何が出来上がったのかを誰も尋ねないまま、数か月にわたって走り続けるプロジェクトです。ここでの統制は契約条項ではなく運用で効かせます。見える形のバックログ、一定間隔でのデモ、そして優先順位を変える権限を持つ発注側の担当者、この三つが要になります。

その関与を担える人が自社側にいないのであれば、正直にそう伝えてください。準委任はうまく機能しませんし、どんな条項を足しても直りません。

多くの案件が選ぶべき第三の形

上限付き、あるいは段階分割の取り決めです。ここまでの二つのどちらでもなく、実際にはどちらよりも多くの開発案件に合います。

上限付きの準委任契約。 作業は時間で精算しつつ、合意した上限額を設けます。発注者は方向を変える自由を保ち、ベンダーは上限を超えた部分のリスクを負います。両者に効率化の利益が残るという点で、純粋な請負にも純粋な準委任にもない性質を持ちます。

段階分割の請負。 短く有償の要件定義フェーズで仕様を作り、そのうえで初めて、実在する対象に対して構築フェーズの請負金額を出します。これは請負の誠実な形です。見積もりが、未知を減らしたあとに作られるからです。その仕様に何を書くべきかは、ソフトウェアのRFP作成ガイドで扱っています。

増分ごとの請負。 各フェーズを別々に見積もり、別々に合意します。予算の見通しを小分けで得られるうえに、途中でやめる権利が残ります。これは発注者が持つ最も価値のある権利であり、長期の請負契約が取り上げてしまうものでもあります。

共通しているのは、いくらか作業を進めたあとでは見積もりの精度が桁違いに上がるという事実です。その事実を活かせる形に商流を組み立てることは、どんな契約条項よりも価値があります。

請負案件が実際に破綻する場所

金額ではありません。スコープと変更の境界です。

請負案件は必ず変更依頼を生みます。仕様が、誰かがその成果物を使ってみる前に書かれるからです。取り決めが健全かどうかは、その変更依頼をどう扱うかで決まり、そしてそれは、開始時点でスコープをどれだけ厳密に定義したかで決まります。当事者の善意で決まるのではありません。

摩擦を減らす手立ては二つあります。まず、変更が起きたときの扱いを書面で合意しておくこと。誰が評価するのか、何を根拠に金額を出すのか、どれくらいの期間で回すのか、この三点です。次に、発注側にも予備費を持っておくこと。発注側に変更用の予算がない請負は、新しい発見のたびに口論を生みます。

もう一つよくある破綻は検収です。完了をどう証明するのかを契約が定めていなければ、最終支払いは意見のぶつけ合いになります。検収基準はスコープと並べて明記し、誰かが判断しなければならない基準よりも、誰かがテストできる基準を優先してください。

実務としての選び方

まず、本当に未知なのは何かを問うてください。答えがごくわずかであれば請負は妥当であり、その確実性の対価としてリスク引当を払う覚悟をしておくべきです。未知が大量にあるなら、請負は技術的な不確実性を商業上の摩擦に置き換えるだけです。

次に、自分たちが何を見ていられるかを問うてください。準委任は関与に報い、その不在を罰します。請負は毎週の負担こそ軽いものの、最初の段階、つまり仕様の段階で多くを求めます。そこでの誤りは費用こそ安いのですが、気づくのは難しくなります。

そして、確実性がいくらの価値を持つかを問うてください。取締役会がひとつの数字を必要とする場面は実際にありますし、そのときリスク引当は妥当な対価です。これは請負を選ぶ正当な理由であり、請負ならリスクが消えると信じるよりはるかに良い理由です。

Mecanikはソフトウェア開発サービスの一環として三つの形すべてで仕事をしており、最も多く勧めているのは段階分割の形です。二週間の要件定義を経て出した見積もりは、その前に出した見積もりより、双方にとって価値があります。

よくある質問

請負契約は準委任契約より安全ですか。 予測しやすいのは確かですが、それは安全と同じではありません。請負は見積もりのリスクをベンダーへ移し、ベンダーはそれをリスク引当として金額に含めるため、リスクが現実になってもならなくても、あなたはその分を支払います。買えるのは請求額の確実性であって、出来上がるものや納期や品質の確実性ではありません。

準委任契約のほうが安く済むのはどんなときですか。 スコープが正当な理由で変わる場面です。利用者の行動次第で方向が決まる最初のバージョン、ドキュメントのないシステムとの連携、中を見るまで状態のわからないコードベースへの着手などが該当します。こうした場面ではリスク引当と変更依頼の処理費用の両方を避けられます。そこでの請負は、要するに推測に対して固定価格を付ける行為だからです。

上限付きの準委任契約とは何ですか。 作業を時間で精算しつつ、合意した上限額を設ける形です。発注者は方向を変える自由を保ち、ベンダーは上限を超えた分のリスクを負います。両者に効率化の利益が残る点が特徴で、純粋な請負にも純粋な準委任にもこの性質はありません。

請負のシステム開発案件はなぜ失敗するのですか。 ほぼ常に、金額ではなくスコープと変更の境界で失敗します。仕様は誰かがそのソフトウェアを使う前に書かれるため、変更依頼は避けられません。健全さは、誰が変更を評価しどう金額を出すのかを事前に合意しているか、そして発注側が自前の予備費を持っているかにかかっています。

検収基準は契約に書くべきですか。 書くべきです。スコープと並べて明記してください。完了を示す方法が定義されていないと、最終支払いは意見のぶつけ合いになります。誰かが判断しなければならない基準よりも、誰かがテストできる基準を選んでください。テストできる基準は争いを終わらせ、判断に頼る基準は争いを長引かせます。