週次デモの確認シート

1. このシートの使い方

週に一度、30分程度の打ち合わせを固定で設けます。開発側が動くものを画面共有し、発注側がこのシートに沿って確認していく形です。毎回同じ項目を見るところに意味があります。項目が固定されていれば、先週との差分が自然に浮かび上がり、「なんとなく順調」という曖昧な状態が続きにくくなります。技術的な判断を発注側が下す必要はありません。見るべきは、事業として意図した方向に進んでいるかどうかです。埋めた用紙はそのまま記録になるので、日付を入れて保管してください。

• ✓日付・参加者・対象スプリント（期間）を先に記入する
• ✓画面共有で実際に操作してもらう（スクリーンショットや資料だけで済ませない）
• ✓気づいたことはその場で書く。後でまとめようとすると抜ける
• ✓終了時に「次の一週間で見るもの」を一文で合意する

2. 先週決めたことが入っているかを見る

最初に確認するのは、前回の打ち合わせで「次はこれを作る」と合意した内容が、実際に動く形で入っているかです。入っていない場合、理由が技術的な事情なのか、優先順位の変更なのか、単に手が回らなかったのかで、取るべき対応が変わります。技術的な事情なら見積りの前提を見直す必要があり、優先順位の変更なら誰の判断だったかを確認する必要があります。理由を責めるためではなく、次週の計画を現実的にするために聞くという姿勢を、最初に伝えておくと話が早く進みます。

• ✓前回合意した項目のうち、今週見られたものはどれか
• ✓見られなかったものについて、理由と、いつ見られる見込みか
• ✓合意していなかったものが増えている場合、それは誰の判断で入ったか

3. 実際に自分で操作してみる

説明を聞くだけでなく、可能であれば発注側が自分で触れる環境を用意してもらいます。開発者が操作するとき、手順は自然と最短経路になります。事情を知らない人が触ると、どこで迷うか、どの表示が読み取れないかが見えます。この差は、説明を聞いているだけでは決して現れません。打ち合わせの場で触る時間がなければ、翌日までに触れるURLとテスト用アカウントをもらい、週の途中で操作して気づいた点を次回に持ち込む形でも構いません。

• ✓発注側が触れる環境（URL・テスト用アカウント）があるか
• ✓説明なしで目的の操作までたどり着けるか
• ✓途中で手が止まった箇所はどこか（そこが利用者もつまずく箇所です）
• ✓スマートフォンなど、想定利用者の環境でも確認したか

4. 「見えているだけ」と「動いている」を区別する

画面ができていることと、機能が動いていることは別です。デモでは、データが固定で埋め込まれているだけの画面が、完成したものに見えることがあります。悪意があるわけではなく、開発の途中段階としてはごく自然な状態です。ただし、発注側がその区別をつけずに進捗を判断すると、残っている作業を実際より小さく見積もってしまいます。判断に迷ったら、自分で値を入力し、画面を再読み込みしてもその内容が残っているかを確かめてください。これだけで多くの場合は見分けがつきます。

5. 事業の言葉で確認する

技術的な実装方法について発注側が判断する必要はありません。確認すべきは、その画面や機能が、事業として意図した行動を生むかどうかです。「この画面を見た利用者は、次に何をすると想定していますか」と聞いてみてください。返ってくる答えが自社の意図と違えば、そこに認識のずれがあります。ずれは時間が経つほど修正の費用が上がるため、まだ作り込む前のこの段階で見つけて直すのが、結果として最も安く済みます。

• ✓この機能は、誰のどんな行動を助けるためのものか説明できるか
• ✓利用者がこの画面で迷ったとき、次にどこへ行くか決まっているか
• ✓運営側の手間（承認、問い合わせ対応、集計）は増えていないか
• ✓検証したい仮説の観測に必要なデータは記録されているか

6. 今週出てきた「宿題」を持ち帰る

デモの場では、開発側から発注側への確認事項が必ず出ます。仕様の判断、文言、素材、外部サービスの契約やアカウント発行などです。これらが放置されると、翌週の開発がそこで止まります。開発が遅れる原因が発注側にあるという状況は、実際には珍しくありません。その場で担当者と期限を決め、誰が見ても分かる形で書き残してください。口頭の「では確認しておきます」で終わらせず、翌週のデモの冒頭でその宿題の状況から確認する流れにすると、滞留しにくくなります。

• ✓発注側が決めること（仕様の判断、文言、優先順位）と期限
• ✓発注側が渡すもの（ロゴ、写真、原稿、アカウント情報）と期限
• ✓開発側が調べて回答すること（技術的な可否、工数の見込み）と期限

7. 残りの範囲と期日を毎週更新する

毎週の確認で最も見落とされやすいのが、全体の残量です。今週の成果だけを見ていると、毎週何かが進んでいるため順調に見えたまま期日に近づきます。合意した範囲のうち、完了・進行中・未着手がそれぞれどれだけあるかを、毎週同じ形式で更新してもらってください。項目が増えていれば、何かを後ろに回すか、期日を動かすか、どちらかの判断が必要になります。この判断を先送りにした分だけ、最後の局面が苦しくなります。

• ✓当初合意した範囲のうち、完了した項目の数と残りの数
• ✓今週、新しく範囲に追加された項目はあるか。誰の判断か
• ✓現在の進み方で期日に間に合う見込みか。間に合わない場合の選択肢は何か
• ✓後回しに分類していた機能を、今も後回しのままでよいか

8. 気になる兆候を記録する

問題は、ある週に突然表れるより、小さな兆候が数週続いた後に表面化することが多いものです。一度なら偶然ということもありますが、同じ兆候が三週続くようであれば、進め方のどこかに構造的な原因があると考えたほうが自然です。責めるための記録ではなく、手遅れになる前に進め方そのものを話し合うための材料として残します。気づいた週に日付とともに書いておけば、後から「いつからこうなっていたか」を落ち着いて振り返ることができます。

• ✓同じ機能が数週にわたって「あと少し」のまま進んでいない
• ✓デモで見せられるものが資料やスクリーンショットに置き換わっている
• ✓質問への回答が抽象的で、具体的な日付や範囲が出てこない
• ✓発注側の宿題が滞留し、それが遅れの理由として繰り返し挙がっている

9. 次の一週間の合意を一文で書く

最後に、次回のデモで何を見るかを一文にして、双方で読み上げます。「認証まわりを進める」ではなく、「新規登録してログインし、自分のプロフィールを編集して保存できるところまで見る」のように、当日そのまま操作できる形で書きます。抽象的な言い方のままにしておくと、翌週になって双方の想定が食い違い、判断できないまま一週間を失います。ここで書いた一文が、そのまま次回の第2章の確認項目になります。

• ✓次回見るものを、操作の順番で書けているか
• ✓その一文に、発注側の宿題が前提として含まれていないか（含まれるなら期限を前倒しする）
• ✓次回の日時を、その場で確定させたか