Day 16 - 本日のサマリー: 設計書を片手に「意地悪な操作」をする品質の日

• 日程: Day 16
• 本日のゴール: テストとレビューで製品の品質を高め、発見した不具合・未完了タスクを一覧化して明日の優先順位を決められる
• 対応する到達目標: No.7
• 本日の成果物: テスト済みの機能（チェックリストにOK/NG記録）、不具合リスト、なりきり操作の記録、更新済みかんばん

昨日まではフィードバックを反映して機能を「足す」日が続きました。今日は重心を「確かめる」に移します。Day 5〜8で作った設計書はそのままテストのチェックリストになる——これが今日の核です。明日は実装最終日で、新機能の追加は禁止になります。今日たくさん不具合を見つけられるほど、明日と発表当日が安全になります。

朝会で時間割を分けて、本編で「設計書 vs 実物」を突き合わせ、終会で「核となる体験」を守る作戦を立てる流れです。

完成イメージ: 設計書から作ったチェックリストにOK/NGが全項目記入され、見つかった不具合は再現手順つきで1か所に集約されている。なりきり操作で「迷い・不安・専門用語」の記録もあり、明日の優先順位（直す／隠す／やらない）が明確になっている状態。

例: 「機能Xのチェックリスト24項目中22項目OK、NG2件（A画面の連打・B画面の空入力）。なりきり操作で迷い3件、不安1件。修正5件＋デグレード確認済み。明日は連打の修正を最優先、空入力は『隠す』判断」

• 自作機能を自分でテストする分担にしてしまう: 作った人は無意識に「動く操作」を選ぶ。必ず作成者と交差させる
• テストを「余った時間でやるもの」と扱う: 時間割に「確かめる時間」を先に予約する。作る作業は膨張する性質がある
• 異常系で見つけた不具合を黙って直してしまう: 不具合リストに載せてから直す。チームの状況把握が崩れる
• 重大度ではなく「直しやすさ」で優先順位をつけてしまう: 基準は常に「核となる体験」。簡単でもデモ導線外なら後回し

安心材料: 不具合は見つかるのが正常です。たくさん見つかったチームほど今日は良い仕事をしています。チェックリストは設計書から機械的に作れるので、ゼロから考える必要はありません。

まず自分（チーム）で書く → 詰まったところだけ聞く、を守ります。

• 「メンバー3人で機能が6つある。作成者と交差するテスト分担表を作って」
• 「機能設計書の入力チェック欄を貼る。確認すべき操作を表形式で列挙して」
• 「会員登録フォームの項目一覧を貼る。各項目に対する異常系テスト観点（境界値含む）を表で出して」

意地悪な操作の案出しはAIが得意ですが、実際に操作して「迷い・不安」を感じ取るのは人間（ペルソナの目）の仕事です。