「ご要望いただいた機能はすべて納品し、契約どおりの人月をご請求しました。」
この二つの文がどちらも正しいまま、プロジェクトが事業として失敗しているということが起こり得ます。 これが人月契約の構造的な問題です。 人月契約は、投入された工数と引き渡された機能に対して支払う契約であり、事業側が実際に手にする成果に対して支払う契約ではありません。
その影響は、三つの方向に積み上がります。
インセンティブが逆を向きます。 時間単価または人月での請求のもとでは、速く仕上げたベンダーほど売上が減ります。 機能を複雑に設計したベンダーほど売上が増えます。 効率化——AIツールによって現在では日常的になったものも含めて——は、それを実現した当事者にとって減収になります。 効率を罰するために契約を設計する方はいらっしゃいませんが、この契約形態は結果としてそう機能します。
納品リスクを発注側がすべて負います。 ベンダーが合意された仕様を100%納品しても、誰も使わないソフトウェアが残るということが起こります。 人月契約では、いずれの場合でも請求は有効です。
エージェンシー・SIerはコモディティ化します。 販売しているものが開発者の時間である以上、発注側が握るレバーは単価だけになり、交渉は一方向にしか進みません。
代替案は「もっと信頼してください」ではありません。 測定可能な成果を契約書そのものに書き込むことです。 これは見た目より難しく、多くの試みが同じ理由で失敗します。 本記事では、まず失敗の理由を整理し、次に当社が日本のお客様との間で用いている4階層モデル、そして成果条項が実務で機能するために必要な4つの要素をご説明します。
なぜ多くの成果条項は機能しないのか
先に失敗パターンを整理します。 判定できない成果条項は、条項がない状態よりも悪い結果を招きます。 プロジェクトではなく紛争を生むためです。
- 基準値がない。 「処理時間を50%削減する」は、プロジェクト開始前に処理時間を誰も測定していなければ何も意味しません。 基準値は開発着手前に測定し、双方で確認する必要があります。 後から記憶に基づいて再構成するものではありません。
- 測定する主体が定まっていない。 指標がお客様側の分析基盤にあり、ベンダーに参照権限がなければ、ベンダーは自らが負う約束を管理できません。 ベンダーの自己申告であれば、お客様はその数値を信頼できません。 誰がいつ計器を読むのかを、双方で合意する必要があります。
- 帰責の境界がない。 コンバージョン率は、競合が値下げしたために下がることも、お客様が価格ページを変更したために下がることも、ソフトウェアが遅いために下がることもあります。 ベンダーが制御できる範囲とできない範囲を切り分けない条項は、執行できません。
- 結果が紐づいていない。 検収、支払段階、是正義務——いずれとも結びついていない指標は、文書上のKPIであって契約条項ではありません。
4階層の成果モデル
各階層は、ベンダーがほぼ完全に制御できるものから、影響は及ぼすものの事業側と制御を分け合うものへと並んでいます。 この勾配が重要です。 各階層をどこまで金銭と固く結びつけてよいかを決めるためです。
- 第1階層 — デリバリー速度。 デプロイ頻度、合意された要件からお客様が触れる環境で動作するソフトウェアまでのリードタイム。 ベンダーが最も直接的に制御できる階層であり、確定的なコミットメントとして書きやすい階層です。 VAONでは、要件から動くものまでの時間を40%短縮することを実務目標としています。 これはAIツール——Anthropic社のClaude Codeを含みます——をコーディング工程だけでなく「仕様→デモ」のループの内側に置くことで実現しています。 ここでの事業価値は、コードが安くなることではありません。 誤った前提が、4か月目のUATではなく2週目のデモで表面化することです。
- 第2階層 — システム性能と信頼性。 定義された負荷条件下でのAPI応答時間のパーセンタイル、重大度区分ごとの障害流出率、重要モジュールにおける自動テストカバレッジ。 これらは、指定した検証環境と指定した負荷条件に紐づけて記載しなければ意味を持ちません。 同時接続数を明記しないp95レイテンシの数値は、コミットメントではありません。
- 第3階層 — 定着と使いやすさ。 実際の運用担当者による作業完了時間、想定利用者数に対するアクティブ率、重要な工程における離脱率。 この階層では、ベンダーが納品後も関与し続けることが前提になります。 計測は実利用が始まって初めて信号を出すためです。 同時に、お客様側がその計測基盤への参照権限を付与してくださることも前提になります。
- 第4階層 — 事業インパクト。 コンバージョン率、問い合わせ件数、特定業務から削減された時間、総所有コスト。 契約に入れたいと最も望まれる階層であり、同時に最も紛争になりやすい階層でもあります。 ベンダーは、価格政策・マーケティング・人員配置・市場そのものと制御を分け合っているためです。
第4階層について、当社は意図的に保守的な立場をとります。 ベンダーがループ全体を実際に制御している場合を除き、支払ペナルティではなく、検収基準および要件定義フェーズの設計に紐づけることをお勧めします。 仕組みが完全にスコープ内にある場合——たとえば定義済みの問い合わせ類型を自動化する、特定業務から測定可能な時間を削減する——第4階層は実質的な商業的重みを持ち得ます。 そうでない場合、無理に契約へ組み込むことは、双方が完遂するプロジェクトではなく、双方が争う条項を生みます。
成果条項に必要な4要素
契約に書き込む指標ごとに、次の4点を併記してください。 1つでも欠けると条項は成立しません。
- 基準値。 測定済みの開始時点の数値、測定日、測定方法、および双方の確認。 仕様確定フェーズの中で取得します。
- 測定方法と実施主体。 計測ツール、クエリまたはイベントの定義、対象環境、そして実施する当事者の指定。 お客様側のツールを用いる場合は、契約においてベンダーに参照権限を付与します。
- 測定期間。 いつ、どの期間について数値を取るか。 「Go-Liveの2週間後を起点とする本番利用30日間」は条項です。 「リリース後」は条項ではありません。
- 結果と適用除外。 達成時および未達時に何が起こるか——検収、支払段階、範囲を定めた是正義務——および条項の適用を停止する事象の明記。 たとえばお客様側の業務プロセス変更、第三者によるAPI仕様変更などです。
コミットメントが本当に置かれるべき場所
成果指標は、受託開発における最大の損失要因を解消するものではありません。 その要因はコーディングの遅さではなく、誤ったまたは不足した仕様が、遅れて発見されることです。 失敗プロジェクトのおよそ半数がここに帰着します。
そのため当社の契約上のコミットメントは、各階層の下流だけでなく、その上流に置かれています。 VAONは仕様確定フェーズを固定価格でお引き受けします。 要件定義・画面設計・DB設計・アーキテクチャ、および開発フェーズの固定見積までを、期間を定め、価格を事前に提示した上で実施します。 その後の開発フェーズで手戻りが発生し、その根本原因が当社が作成した仕様書の誤りまたは記載漏れに帰着する場合、その費用は当社が負担いたします。
境界は明示的に契約へ記載します。 境界のないコミットメントはコミットメントではなく、値付けされていない債務だからです。 当社仕様の誤り・漏れは当社の負担です。 確定後の仕様変更、第三者APIや法令改正といった前提条件の変化、そして記録された照会の場でお尋ねしたにもかかわらず開示されなかった業務ルールについては、お客様のご負担となります。 手戻りのチケットはこの4分類に照らして記録とともに判定し、範囲外のご依頼はすべて書面の変更管理を通します。 見積と工期影響を書面でご提示し、書面でご承認をいただいた上で着手いたします。 ご承認いただいていない作業の請求書をお送りすることは、決してありません。
これは4つの階層が依拠しているものと同じ規律です。 指標が判定可能であるためには、指標が参照する仕様が曖昧でないこと、そしてすべての意思決定に記録が残っていることが必要です。
セキュリティとデータの取り扱い
成果に関するお約束は、システムが継続的に利用可能であり、データが所定の場所に保持されることを前提とします。 データレジデンシーが条件となる場合、東京を含め、お客様がご指定になるリージョンへ構築いたします。 当社の自社プロダクト「OneBot」——LINE連携を備え本番稼働しているRAG構成のアシスタント——は、APPIを考慮したデータ取り扱いをアーキテクチャ上の制約として設計しています。 方針文書の上だけでなく、自社プロダクトで実際に解いてきた課題です。 重大度区分と応答に関するお約束（重大障害については1時間以内の初動応答を目標としています）は、善意に委ねるのではなく契約に定めます。
「人月」を買う契約から、「成果」を買う契約へ
ソフトウェア開発の目的は、予算を消化することでも、仕様書のチェック欄を埋めることでもありません。 業務上のボトルネックを取り除き、測定可能な事業上の変化を生むことです。
次の契約を成果指標に基づいて設計されるのであれば、見積の前に、階層ごとの指標設計をご一緒いたします。
🤝 成果ベース契約・OEMパートナーシップのご相談 — 貴社案件の指標設計、総合お見積り、またはエージェンシー・SIer向けB2B OEM／技術パートナーシッププログラムについては、VAONまでお問い合わせください。