書面の受入条件：固定スコープ開発を安全にするもの

「固定スコープ」は安全に聞こえます。決まった成果物、決まった価格、決まった期日。しかし散文だけで書かれたスコープ（「動くダッシュボード」「サポート用のAIアシスタント」）は、まったく固定されていません。双方が別のものを思い描き、その差は最悪のタイミングで表面化します：納品時です。

スコープを本当に固定するのは、短い受入条件のリストです。着手前に「完了」の意味を定義する、書面のテスト可能な文です。

良い受入条件の形

有用な受入条件は、エンジニアでなくても動くシステムを見て検証できるものです。比べてみましょう。

曖昧： 「システムは受信したサポートメールを分類する。」

テスト可能： 「クライアントが提供する50通のサンプルメールに対し、システムは45通以上にカテゴリーと返信案を割り当て、すべての分類が確信度スコア付きでレビューキューに表示される。」

後者は一度に三つの仕事をします。エンジニアには何を作るかを正確に伝え、貴社にはデモで何を確認するかを正確に伝え、最終の検収会話を意見交換からチェックリストに変えます。

紛争の大半を防ぐ最小セット

条件が何十個も必要なわけではありません。2〜6週間の構築なら、1ページのリストでほぼ足ります。

1. 機能条件。 上の例のような文を3〜8個。それぞれ事前に合意したサンプルデータか具体的なシナリオに紐づけます。
2. 除外項目。 このプロジェクトが意図的に含まないもの。除外は悲観ではなく、予算の誠実な境界線です。私が見てきた紛争はすべて、書かれていない空白から始まりました。
3. 品質ゲート。 システムがどこで動くか（貴社のクラウドアカウント）、何と一緒に納品されるか（ドキュメント、再現可能なセットアップ、引き継ぎノート）、コードがどうなるか（貴社のリポジトリ、書面での譲渡）。
4. デモの周期。 動くソフトウェアの週次デモと、貴社の承認記録。毎週チェックされる条件は、大きくはズレられません。

変更は問題ない。無言の変更が問題。

固定スコープは凍結スコープではありません。実プロジェクトには学びがあります。守りになるのは正式な変更管理です。新しい情報で計画が変わるときは、条件リストを書面で更新し、時間と価格への影響を作業の前に明示します。絶対に起きてはいけないのは、どちらの方向であれ無言のスコープ変化です。ベンダーがこっそり手を抜くことも、クライアントが毎週「小さなお願い」を足すことも。

最初のドラフトは誰が書くべきか

ベンダーです。テスト可能な条件を書くには、何が技術的に検証可能かを知っている必要があります。そして、条件を書面にすることを渋るベンダーは、納品がどう進むかについて重要なことを教えてくれています。貴社の仕事はドラフトをレビューし、都合のよい技術的アウトプットではなく、貴社のビジネス課題を記述しているか確かめることです。

Urbano DXでは、受入条件と除外項目を着手前にSOWで確定し、毎週のデモをその条件に照らして実施し、条件を満たさないマイルストーンは納品扱いにする前に修正します。この最後の一文が安全装置のすべてです。条件は、満たさないことに結果が伴って初めて貴社を守ります。

貴社のプロジェクトで「条件ファースト」のスコープがどう見えるか知りたい場合は、有償監査がまさにその文書を作ります。