エンジニア向けにだけ書かれたスコープドキュメントは、内容を理解していないバイヤーにサインされる。そのサインが、後から発生するすべての変更指示の争いの原因になる。
解決策は長いドキュメントではない。意図的な構造を持つドキュメントだ――エンジニアが必要とする精度と、バイヤーが承認・判断するために必要な明確さを、同時に提供する構造。
2つの読者、1つのドキュメント
すべてのAIプロジェクトのスコープドキュメントには、異なる成功条件を持つ2種類の読者がいる。
エンジニアチームは、何を作るのか、何を作らないのか、完了が測定可能な形でどう見えるかを正確に知る必要がある。ここでの曖昧さは手戻りを生む。
バイヤーは、何に対して支払うのか、スコープ外は何か、想定外のことが起きたときどうなるかを知る必要がある。ここでの曖昧さは紛争を生む。
ほとんどのスコープドキュメントは一方の読者にはよく機能し、もう一方を無視している。エンジニアはシステム用語で書く――エンドポイント、レイテンシバジェット、モデルバージョン。バイヤーは成果の言葉で読む――獲得リード数、削減工数、アクションあたりのコスト。どちらの表現も間違いではない。両方が同じドキュメントに存在する必要がある。
以下の構造がその翻訳を強制する。
スコープドキュメントに必要な4つのセクション
1. バウンダリ（境界）
システムが何をするかを正確に記述する。1段落。平易な言葉で。
例：このシステムは週最大5,000件の企業レコードを取り込み、2つのソースからファーモグラフィックデータで各レコードをエンリッチし、定義済みICPに対して各レコードをスコアリングし、毎週月曜日午前6時までにランク付けされた出力ファイルを指定のS3バケットに配信する。
この文はエンジニアにもバイヤーにも機能する。エンジニアはデータ量、ソース、出力フォーマット、配信ウィンドウを読み取る。バイヤーは何をいつ受け取るかを読み取る。
1段落でバウンダリを書けないなら、スコープはまだ定義されていない。
2. 除外事項
このセクションは最も省略されやすく、省略コストが最も高い。
除外事項は、システムが何をしないかを記述する。将来できるかもしれないことではない。予算外のことでもない。このエンゲージメントで明示的にスコープ外となるものだ。
上記システムの除外事項の例：
- CRMへの書き戻しは含まない。出力はファイル形式での配信のみ。
- システムは入力レコードの検証やクリーニングを行わない。不正なレコードはスキップしてログに記録する。
- リアルタイムエンリッチメントはスコープ外。処理は週次バッチスケジュールで実行する。
- スコアリング済みレコードの人によるレビューは含まない。
このセクションがないと、バイヤーはバウンダリに隣接するすべてが含まれると思い込む。エンジニアはバイヤーがそうでないことを知っていると思い込む。そのギャップは実際のコストになる――典型的には、プロジェクト中盤で双方が正しく双方が不満を持つ会話という形で。
最初のスプリントが始まる前に除外事項リストを書く。バイヤーと明示的にレビューする。書面で確認を取る。
3. 測定可能な単位での成功基準
成功基準は数値でなければならない。形容詞ではない。
悪い例：システムは良好に動作し、正確な結果を提供すること。
良い例：
- 有効な入力レコードに対するエンリッチメントマッチ率 ≥ 85%
- 週次バッチが予定実行の ≥ 95% で午前6時のウィンドウ内に出力ファイルを完了・配信する
- レコードあたりのスコアリングレイテンシが99パーセンタイルで ≤ 200ms
- 200件のホールドアウトセットで測定したICPスコアリングの偽陽性率 ≤ 12%
これらの数値は2つのことをする。エンジニアに構築目標を与える。バイヤーにコードを読まずに検証できる完了の定義を与える。
バイヤーがエンジニアの助けなしに成功基準を評価できないなら、その基準はまだバイヤーが読める状態ではない。
4. エスカレーションパス
スコープドキュメントはほぼ常にこれを省略する。最もコストの高い会話を防ぐセクションだ。
エスカレーションパスが答える問いは：プロジェクト中にバウンダリ外のことが浮上したとき、何が起きるか？
以下を明記する必要がある：
- スコープ外の項目を誰が特定するか（エンジニア、PM、またはバイヤー）
- どのように文書化するか（Slackメッセージではなく、書面による変更依頼）
- 誰がスコープ変更を承認し、どのタイムフレームで行うか
- 変更がタイムライン、コスト、またはその両方に影響するかどうか、およびその伝達方法
1段落のエスカレーションパスで、次の状況を防げる：エンジニアが役立つと思ってスコープに隣接するものを構築し、バイヤーがそれを見てメンテナンスされると期待し、次のエンゲージメントが何を約束したかの不一致から始まる状況。
除外事項を省略すると実際にかかるコスト
現実的な例：チームがリードエンリッチメントパイプラインをスコープする。除外事項セクションは空白。バイヤーはCRM同期が含まれると思い込む――デモ環境にはあったから。エンジニアは一度も議論されなかったと思い込む。3週間後、バイヤーがCRM同期はいつ稼働するか尋ねる。エンジニアはスコープに含まれていなかったと言う。バイヤーが契約書を引っ張り出す。契約書には記載がない。
解決の選択肢：無償で構築する、請求してリレーションシップを損なう、または部分的に交渉する。3つの選択肢すべて、1週目に除外事項セクションを書くよりコストが高い。
手戻りコストはエンジニアリング工数だけではない。信頼コスト、遅延コスト、並行して走る他のすべてのプロジェクトへの集中力コストがある。
AIシステムへの具体的な適用
AIシステムには特有のスコープ失敗パターンがある：バイヤーは、システムがトレーニングも設計もされていないエッジケースを処理すると思い込む。バウンダリと除外事項を正確に定義したドキュメントは、その思い込みのギャップがサポートチケットになる前に解消する。
DK1.AIでは、スコープの明確さはすべてのエンゲージメントの構造に組み込まれている。AI Brand Presenceはその一例だ――バウンダリ、除外事項、成功基準は本番作業が始まる前に定義され、双方が何を作り何を作らないかを正確に把握している。
その規律はわれわれが運用するすべてのシステムに適用される。