カスタムソフトウェアプロジェクトの価格交渉において、甲乙双方が最もよく合意する単位は「人日」です：何人のエンジニアが何日間作業し、単価はいくらか。このモデルは、要件が安定していて納品範囲が明確な場合にこそ機能します。しかし、現場のルールが頻繁に変更されたり、AIツールによってコーディング効率が大幅に向上したりしても、依然として甲方が「人数を積み上げる」方式で検収を行うと、矛盾が噴出します――乙方は要件の拡大を、甲方は「人数は増やしていないのに成果物が増えない」と感じます。
政策シグナル：人頭売りから成果売りへ
2026年9月、工業情報化部は『「人工知能＋ソフトウェア」特別行動実施方案』を発表しました。同方案では、ソフトウェア生産モデルの変革を推進し、「モデル即サービス」「エージェント即サービス」を発展させることを繰り返し述べており、2028年までに重点業界でエージェント型ソフトウェアのモデルアプリケーションを構築することを明確にしています。文書はカスタム開発を否定していませんが、一つの明確な方向性を示しています：ソフトウェアの価値を評価する際には、投入した人日の数だけではなく、実際の成果を重視するようになってきています。
ERP、MES、CRM、業界向け管理システムを導入している企業にとって、これは契約書に依然として「XX人×XX日」としか記載されていない場合、稼働後に「コードは完成したのに業務で使えない」というもめ事に陥りやすいことを意味します。より持続可能な書き方は、納品内容を検証可能な業務成果に分解することです。
業務ロジック：マイルストーンは人日よりも具体的にすべきです
プロジェクトを「段階払い」から「マイルストーン払い」へとアップグレードし、各マイルストーンは同時に四つの条件を満たさなければなりません：
- 業務シーン：誰が使用し、どのような操作を解決するのか（例えば「倉庫係がバーコードで入庫する」であって、「入庫モジュールを完成させる」ではない）。
- データ口径：どのマスターデータ、ステータスフィールド、権限範囲が関与し、サンプリングルールはどうか。
- 検証スクリプト：与えられたテストデータに基づき、どのプロセスを通過し、どのような伝票やレポートを生成するか。
- 例外処理：失敗時にシステムがどのように通知し、誰が修正権を持ち、履歴が残されるか。
マイルストーンは通常、2～4週間に設定するのが適切です；長すぎると再び「ブラックボックス開発」に戻ってしまいます。典型的な分割例としては、マスターデータと権限→コア伝票のクローズドループ→レポートと照合→インターフェースと本番切り替えがあります。
設計ロジック：範囲、変更、そして「スマート補助」を契約書に明記する
AIによるコーディング支援、テストケースの自動生成、文書のスマート補完などは、同じ機能でも人日の消費量を変える可能性がありますが、業務の複雑さを自動的に変えることはありません。契約書および要件仕様書には、次のように別途記載することを推奨します：
- 範囲ベースライン（Baseline）：機能リスト＋範囲外リスト（Out of Scope）、変更は必ず変更申請書を通じて行う必要があります。
- 変更の計価ルール：新たなマイルストーンは「シナリオ＋検証スクリプト」に基づいて見積もられ、臨時の人日追加ではありません。
- スマート補助の境界：どの工程でAIによる効率化が可能で（コード生成、文書下書き）、どの部分は必ず人手による署名が必要か（安全、コンプライアンス、対外的約束）。
- 知識蓄積の帰属：プロセス文書、設定、スクリプトは誰が保有するのか、納品後の運用継続における断絶を防ぐためです。
開発の実装：検証の自動化と可観測性
「成果志向」を実行可能にするため、技術側は三つのことに協力する必要があります：
- 検証用ケースの登録：各マイルストーンに対応する一組の自動化または半自動化されたテストケースを用意し、リグレッションテストを繰り返し実施できるようにします。
- 環境とデータの分離：UAT環境のデータはリセット可能で、「デモ環境でのみ合格する」という事態を防ぎます。
- 可観測ログ：重要な操作には監査ログを設け、紛争時には誰が何を変更したのかを追跡できます。
プロジェクトにエージェントやルールエンジンが含まれる場合、検証には抜き打ち検査メカニズムを追加する必要があります：境界ケースをランダムに入力し、拒否回答、人手への昇格、権限遮断などが設計通りかどうかを確認し、単に「会話ができる」かどうかだけを見るのではありません。
三種類のよくある紛争とその予防
紛争その一：「機能はすべて実装したのに、なぜ業務で使えないのか？」――予防策：マイルストーンに担当業務と研修出席記録を紐付け、検証時には現場で巡回チェックを行い、PPTのデモンストレーションだけに留まらないようにします。
紛争その二：「ちょっとした要望を追加するのに、なぜ追加料金が必要なのか？」――予防策：変更申請書に影響を受けるマイルストーン、スクリプト、工期を明確に記載し、双方が署名した後で開発を進めます。
紛争その三：「AIで効率が上がったのに、人日を削減できるのか？」――予防策：契約書で「実現コスト」と「業務の複雑さ」を区別し、効率化による利益は総額や期間に反映されるものの、検証基準は下げない。
パイロット提案：まずは一つのクローズドループモジュールから始める
全システムの契約書の書き換えを待つ必要はありません。2～3週間でクローズドループが可能なモジュール（入出庫、作業指示の報告、経費承認など）を選定し、新しいテンプレートで補足契約を結びます：シナリオ、スクリプト、例外、支払時期を列挙します。一度成功すれば、全プロジェクトへと展開できます。成功の目安は、変更申請書によるもめ事の時間短縮が見られるか、UATの一回通過率が上昇しているか、乙方が人日をどれほど過少申告したかではなく、全体的な成果を評価することです。パイロットモジュールの選定がうまくいけば、全プロジェクトで契約書を改訂する説得力が生まれます。
人日は一夜にして消えるものではありませんが、「唯一の価格決定単位」から「コスト見積もりの参考」へと変わりつつあります。マイルストーンと検証スクリプトを契約書に明記することが、人工知能＋ソフトウェアの時代においてもカスタムソフトウェアが信頼できる成果を提供し続けるための基本なのです。
固定総額契約やアジャイル反復との連携
マイルストーンによる検証はアジャイルを排除するものではありません：各Sprintでは引き続きデモ可能なインクリメントを納品できますが、支払いと正式な検証はより大きなマイルストーンに紐付けられます。特に固定総額契約では、「範囲凍結点」を明確に記載する必要があります――どのレビュー以降に追加要望が出ても変更申請書を通じて対応し、口頭での機能追加を防ぐのです。エージェントを含むモジュールについては、全体の本番稼働と一括して結び付けるのではなく、個別のマイルストーンで「ルールバージョン＋抜き打ち検査通過率」を検証することを推奨します。
業界データによれば、ソフトウェアプロジェクトの失敗の約3分の1は、要件と検証基準の曖昧さに起因しており、技術的実装そのものではありません。まず「何が完了したのか」を契約書に明記しておくことが、AIがプログラマーを何人置き換えたかを議論するよりも有意義です。次回のプロジェクト審査時には、まずこう問いかけてみてください：もし明日乙方全員が休暇になったら、スクリプトだけで現在のマイルストーンが基準を満たしているかどうか判断できるでしょうか――答えられないなら、検証基準がまだ十分に明確になっていない証拠です。マイルストーンを契約書に記載するのは、乙方を困らせるためではなく、双方が同じページで「終わったのかどうか」を話し合うためです。AIによる効率化が顕著になるプロジェクトほど、この点を早めに明確にしておくことが重要です。