固定スコープ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つあるか

業務責任者の参加がない場合、ソフトウェアはできても、投資判断に使える証拠にならないことがあります。判断のないデモは単なる報告会、デモのない判断は単なる希望です。週次デモは、固定スコープスプリントがどちらにも陥らない方法です。