人月×単価は「時間が価値に比例する」前提の上に成り立ってきました

受託開発の金額は、長いあいだ人月×単価で組み立てられてきました。何人が何か月働くかを積み上げ、そこに単価を掛ける。発注側がこの計算を疑わずに済んだのは、かけた時間と生まれる価値がおおむね比例していたからです。実装に時間がかかる案件は、それだけ多くの機能を積み上げている。時間は、価値のわかりやすい代理指標でした。

生成AIは、この比例を壊します。同じ機能を作るのに必要な時間が、AIをどれだけ開発プロセスに組み込んでいるかで大きく変わるようになりました。従来なら数週間かかった実装が数日で終わることもあれば、AIの出力を検証するために従来とは違う時間の使い方が要ることもあります。かけた時間が価値を代理しなくなったとき、人月×単価は「この金額は何に対する対価か」に答えられなくなります。

この変化が受託の構造をどう動かしているかは、受託開発に起きている変化で整理しました。本稿はその一歩先、契約そのものをどう設計し直すかに踏み込みます。

速くなった分の便益は、放っておくと配分が歪みます

工数課金のまま開発だけが速くなると、何が起きるでしょうか。

見積もり工数を据え置けば、実際の作業が早く終わった分は受託側の利幅になります。発注側は従来と同じ金額を払い、速くなった恩恵をほとんど受け取れません。しかも、この差分は請求書からは見えません。工数の内訳が同じなら、金額も同じだからです。

逆に、短くなった工数を見積もりへ正直に反映すれば、発注側は安く買えます。ただしこのとき受託側は、AIに投資して生産性を上げるほど売上が減る構造に置かれます。ツールや教育に費用をかけた結果が値引きにしかならないなら、受託側には速くなる動機がありません。生産性の向上そのものが止まります。

つまり工数課金の下では、速くなった便益はどちらか一方に偏るか、改善が止まって便益自体が生まれなくなるか、そのどちらかへ向かいます。これは受託側の善意や交渉の巧拙の問題ではなく、時間に対して払うという構造の帰結です。双方が便益を分け合うには、値引き交渉ではなく、何に対して払うかの定義を変える必要があります。それが、成果への対価という選択肢です。

成果対価は「何を成果と呼ぶか」を決める作業から始まります

成果対価、アウトカムベースという言葉はひとつの契約形態のように聞こえますが、実際には「成果」の置き方に階層があります。どの階層に指標を置くかで、契約の性格は大きく変わります。

成果の階層 指標の例 測定 受託側の制御
成果物の完成 機能のリリース、検収済みの成果物 明確 高い
稼働と品質 稼働率、応答時間、不具合の収束 比較的明確 高い
業務の効果 処理時間の短縮、問い合わせ対応の削減 測定設計が必要 業務側の要因が混ざる
事業の効果 売上、解約率への寄与 切り分けが難しい 低い

下の階層ほど発注側の事業価値に直結しますが、受託側が制御できない要因が増えます。制御できないものに対価を連動させれば、受託側はその不確実性の分を金額に上乗せせざるを得ません。逆に上の階層は測りやすい一方、「成果物は納品されたが業務は変わらなかった」を防げません。

だから実務では、稼働と品質から業務の効果までの帯に主たる指標を置き、事業の効果は参照値にとどめる設計が現実的です。良い成果指標の条件は、契約の両側から見て同じ数字が出ること、受託側の働きがその数字を動かせること、発注側がその数字の改善にお金を払う理由を説明できることです。この3つがそろわない指標は、契約に載せても運用できません。

リスクの置き場所と検収の手続きが、契約の本体です

成果対価への移行は、リスクの移転を伴います。工数課金では、成果が出ないリスクの大半を発注側が負っていました。時間に対して払う以上、期待した効果が出なくても支払いは発生するからです。成果対価では、その一部を受託側が引き受けます。リスクを引き受ける側は、当然その分の上乗せを求めます。成果対価にすれば安くなる、という話ではありません。速くなった便益とリスクを、双方でどう分け合うかを決め直す交渉です。

だからこそ、全額を成果に連動させる必要はありません。体制の維持や要件整理に対応する固定部分と、指標の達成に連動する変動部分を組み合わせる形が、リスクの偏りを抑えます。

日本の契約実務でも、この設計は特殊なものではありません。受託契約の基本形は、仕事の完成に報酬を払う請負と、業務の遂行に報酬を払う準委任です。2020年4月に施行された改正民法では、準委任でも成果の引渡しに対して報酬を支払う類型、いわゆる成果完成型が明文化されました（民法648条の2）。成果対価は、既存の法的な枠組みの上で設計できます。

そのうえで、契約の実質を決めるのは検収の設計です。工数課金の検収は、成果物が仕様どおりかを確かめれば足りました。成果対価では、成果が出たかどうかを、いつ、どのデータで、誰が判定するかという手続きそのものを契約に書き込みます。締結前に、少なくとも次の項目を双方で合意しておく必要があります。

ここを曖昧にしたまま「成果連動」とだけ書いた契約は、検収のたびに解釈の争いを生みます。

弊社がAIネイティブ開発の受託で成果連動の要素を入れるときは、この項目を契約前に発注側と一緒に文書へ落とすところから始めます。日本側のPMが要件整理の段階で「この開発は、何の数字が動けば成功か」を発注側の業務担当と詰め、ベトナムの開発チームは実装、レビュー、運用改善をその指標に向けて回します。検収は納品を確認する儀式ではなく、合意した指標を双方で確かめる場になります。指標を先に決める過程で要件の曖昧さも早く表に出るため、この進め方は手戻りを減らす効果も持ちます。

すべてを成果対価にする必要はありません

課金モデルの選択は、工数課金か成果対価かの二択ではありません。開発には、成果を先に定義できる工程と、できない工程があります。

要件がまだ揺れている探索の段階で成果を固定すると、かえって歪みが出ます。作る途中で「これは作るべきではなかった」と分かっても、指標の達成に向けて作りきる方向へ力が働くからです。この段階は、時間に対して払う準委任のほうが、方向転換の自由を保てます。一方、対象業務が定まり、指標のベースラインが取れる運用改善の段階は、成果連動を載せやすい工程です。

だから現実的な移行は、契約全体の一斉切り替えではなく、工程ごとの使い分けになります。探索は時間で、構築は成果物の完成で、運用改善は業務指標で払う。ひとつの取引の中に複数の原理が混ざって構いません。重要なのは、どの工程がどの原理で課金されているかを、発注側が理解して選んでいることです。

なお、本稿で扱ってきたのは払い方の構造であって、金額の水準ではありません。提示された見積もりが水準として適正かを見極める観点は、適正価格の見方で別に整理しています。構造と水準は別の問いなので、両方を確かめてください。

弊社の関わり方

弊社は、AIネイティブ開発を前提にした受託を、日本側PMとベトナム開発チームの体制で回しています。要件整理から実装、レビュー、運用改善までを一続きで担っているため、どの工程なら成果を約束できて、どの工程はまだ約束できないかを、自分たちの実務として答えられます。成果指標と検収の設計は、提案書の飾りではなく契約の条文に落ちるところまで、発注側と一緒に詰めます。

契約の見直しは、発注側から判断の力を奪うものではありません。何が成功かを指標として言語化する作業は、発注側の中に残る資産になります。AI開発の伴走支援は、その力を発注側に残し、内製化を止めないことを前提にした関わり方です。

開発が速くなった実感はあるのに、請求書の中身が変わらない。いまの契約にそのずれを感じているなら、次の契約更新が構造を見直す機会です。どの工程から成果対価を試すか、指標をどこに置くかの検討も含めて、お問い合わせからご相談ください。