高コストなAIプロジェクトが失敗する原因は、エンジニアリングの問題ではなく、初日に行われなかったスコープの意思決定にある。
モデルの欠如でも、データセットの欠如でもない。境界の欠如だ。
チームが構築を始めると、スコープはデフォルトで拡大する。すべてのステークホルダーがユースケースを追加する。すべてのデモが新たなエッジケースを浮き彫りにする。6週間後、システムは1つのことを確実にこなす代わりに、12のことを中途半端にこなすようになる。この結果は予測可能であり、防止できる。
まず正確なワークフローの境界を定義する
AIシステムのスコープドキュメントには2つの側面がある。システムが扱うものと、明示的に扱わないものだ。
両側面は同等に重要だ。ほとんどのチームは最初の側面を書く。2番目を書くチームはほとんどいない。
有用な境界ステートメントは次のようになる：
- スコープ内： システムはインバウンドのリードレコードを読み取り、定義されたICPに対してスコアリングし、構造化されたサマリーを共有キューに書き込む。
- スコープ外： システムはメールの送信、CRMフィールドの更新、ルーティングの意思決定を行わない。
2番目のリストは制限ではない。設計上の決定だ。すべてのエンジニア、すべてのレビュアー、すべての将来のステークホルダーに対して、システムがどこで止まるかを正確に伝える。ローンチ前夜の午後11時に誰かが議論する前に。
DK1.AIでは、すべてのプロダクトがこの種の明示的な境界から始まる。AI Brand Presenceはその明確な例だ。企業がAI駆動の検索・ディスカバリーサーフェス全体でどのように表示されるかを扱う。有料メディア、ソーシャルスケジューリング、従来の意味でのSEOは管理しない。その境界は最初から明示されており、最初の請求書の後に発見されるものではない。
キックオフ前に拒否リストを作成する
拒否リストとは、最初のスプリントの前に除外するすべての機能だ。
直感に反するように聞こえる。何も構築する前に、構築しないものを定義している。しかし、拒否リストの各項目は、3ヶ月目に発生しない1週間の手戻りだ。
アウトバウンドAIシステムの実用的な拒否リストには次のものが含まれるかもしれない：
- 通話中のリアルタイムエンリッチメントなし
- パイロットフェーズ中は本番CRMへの直接書き込みアクセスなし
- 英語のワークフローが安定するまで多言語サポートなし
- 自動送信なし — すべてのアウトバウンドはオペレーターの承認が必要
各拒否は失敗モードを除去する。通話中のリアルタイムエンリッチメントは、コアの仕事とは無関係なレイテンシとエラー処理の複雑さをもたらす。パイロット中の直接CRM書き込みは、AIのバグがデータクリーンアッププロジェクトを生み出すことを意味する。ベースワークフローが安定する前の多言語サポートは、2つの問題を同時にデバッグすることを意味する。
拒否リストは永続的なものではない。出発点だ。しかし、スコープが受動的に蓄積されるのではなく、スコープを追加するための明示的な決定をチームに強制する。
拒否リストセッションの進め方
キックオフ前に、システムを構築する人々と使用する人々を集める。全員に10分間、含まれていると思う機能を書き出させる。リストを収集する。次に項目ごとに確認し、「システムがコアバリューを提供するためにv1に含まれる必要があるか？」と問う。
その問いを生き残れないものはすべて拒否リストに入れる。理由を文書化する。その文書化は重要だ。4週目にステークホルダーがその機能を求めたとき、拒否ではなく延期された理由の書面記録がある。
生きた契約としてのスコープ
要件は変化する。それは計画の失敗ではなく、通常のことだ。問題は、スコープの変更が意図的に行われるか、ドリフトによって行われるかだ。
ドリフトはこのように見える。ステークホルダーが小さな追加を求める。チームはそれが些細に見えるのでYesと言う。3つの小さな追加の後、システムはスコープされたものとは実質的に異なることをしており、元のパフォーマンスベンチマークはもはや適用されない。
生きたスコープ契約は、システムを硬直させることなくドリフトを防ぐ。仕組みは次のとおりだ：
- 提案されたスコープ変更は、追加されるものと置き換えまたは延期されるものを説明する1文の正式な修正として書き留める。
- チームは元の境界ステートメントに対して修正をレビューする。これはシステムのコアジョブを変えるか？新たな失敗モードをもたらすか？
- 修正が承認された場合、拒否リストを更新する。以前に拒否された機能がスコープ内になった場合、元の拒否の理由を明示的に再検討する。
これは官僚主義ではない。2人チームの場合、プロセス全体に20分かかる。防ぐのは、システムを脆くしデバッグを遅くする複雑さの静かな蓄積だ。
DK1.AIでは、スコープレビューは定義されたチェックポイントで行われる。継続的でもなく、行われないわけでもない。目標は、本番環境で静かに動作するシステムであり、永続的に作業が面白いシステムではない。
実際の結果
スコープが適切に定義されたシステムは、構築が速く、テストが容易で、維持コストが低い。境界ドキュメントは受け入れ基準になる。拒否リストはスコープクリープの回帰テストになる。修正プロセスは変更ログになる。
これには大きなチームも正式なプロセスフレームワークも必要ない。最初のスプリントが始まる前の1時間の規律ある会話が必要だ。
地味さが勝つ。18ヶ月間1つのことを確実にこなすシステムは、6週間8つのことを印象的にこなすシステムよりも価値がある。