固定スコープDXで週次デモが重要な理由
DXプロジェクトは、進捗が見えないと勢いを失います。週次デモは、前提が固まる前に成果を具体化するための仕組みです。
固定スコープのAI自動化スプリントでは、デモは儀式ではありません。進行を制御する仕組みです。ステータスメール、チケットボード、バーンダウンチャート—これらはすべて下流のアウトプットです。反応すべき「動くデモ」がなければ、他のプロジェクト成果物は計測ではなく意見にすぎません。
良いデモで見せるもの
有効なデモでは、粗い状態でも業務の流れを端から端まで見せます。
どのデータが入ったか
AIが何を抽出、分類、要約したか
人の確認がどこに入るか
どの出力が作られるか
どの例外がまだ失敗するか
この見える化により、業務責任者が早い段階で方向修正できます。
30分で有用なフィードバックを安定して引き出せるデモ構成:
1. 振り返り(2分)。 先週合意したこと、変わったこと、本日のデモの目的。
2. エンドツーエンドの歩み(10分)。 実データ・実環境、スライドなし。トリガーから出力まで業務を追う。AIが判断する場所で止め、根拠と信頼度を見せる。
3. エッジケース(5分)。 故意に難しい例を2〜3件。失敗を含めて現状の挙動を見せる。
4. 必要な判断(5分)。 1判断1スライド/付箋の短いリスト:「Xを提案、代替はYまたはZ、業務責任者は金曜までに決定」。
5. 来週の計画(5分)。 1週間後のデモで何が違っているか。具体的で検証可能な項目。
6. オープンQ&A(3分)。 タイムボックス。
デモは常に最新のデプロイ済みビルドで動かします。開発者のラップトップではなく。業務責任者が開けるURLから再現できなければ、信頼できません。
スコープを守る理由
週次デモは、追加要望のトレードオフを見える化します。新しい要望が出たとき、合意済みの成果、受入条件、期間と比較できます。
デモ中のスコープ会話で効くパターン:
単一の生きた文書(「スコープ台帳」)を維持する。合意成果、含む項目、除外項目、これまでの変更指示を一覧化。
新規要望は出た瞬間に「候補変更」セクションへ書き出す。
各候補はストーリーポイントではなくカレンダー日数で見積もり、次回デモで2択を提示:現スコープ維持して延期、または既存項目と入れ替え。
業務責任者がその会議内で書面で決定。両選択肢が見える状態で。
これにより、固定スコープが公平に保たれます。クライアントは進捗を確認でき、開発側は静かなスコープ拡大を避けられます。最も高くつくスコープクリープは、当時誰も名前を付けなかったものです。週次デモと書面台帳は、それを防ぐ最も安い方法です。
参加すべき人
最も重要なのはプロダクト責任者または業務責任者です。その人が、実際にユーザーの役に立つかを判断できます。その人の会議での役割は、機能を個別に承認することではなく、デモごとに1つの問いに答えることです:「業務が使える判断に向けて、まだ軌道上にあるか」。
開発側のデモ前チェックリスト:
最新ビルドがデプロイされ、開発ネットワーク外から到達可能か
実データ(または代表データ)を使った例が少なくとも1つあるか
質問込みで15分以内に通せるか
未決事項が事前に文書化されているか
通話後に業務責任者が経営層へ共有できる画面/録画/URLが1つあるか
業務責任者の参加がない場合、ソフトウェアはできても、投資判断に使える証拠にならないことがあります。判断のないデモは単なる報告会、デモのない判断は単なる希望です。週次デモは、固定スコープスプリントがどちらにも陥らない方法です。