Day 15 - 本日のサマリー: 小さく変えて、小さく確認する日

• 日程: Day 15
• 本日のゴール: 中間発表で決めた対応タスクを実装し、動作確認まで完了できる
• 対応する到達目標: No.7
• 本日の成果物: フィードバック反映済みの機能、デグレード確認チェックリスト、更新済み設計書、更新済みかんばん

中間発表でもらったフィードバックを反映する日です。新規実装と違って今日は「既に動いているもの」に手を入れます。難しいのは「変えたところが動く」かつ「変えていないところも壊れていない」を両立すること（デグレード防止）。武器は2つ、チェックリストと小さい変更です。一度に大きく変えず「1タスク → コミット → 動作確認 → デグレード確認 → 次のタスク」のサイクルを回します。実装期間はあと3日（今日・Day16テスト・Day17仕上げ）。今日の終会では残タスクを冷静に見て「削る判断」も視野に入ります。

朝会10分・実装2時間40分・終会20分のリズム。Day16・Day17も同じリズムで進むので、ここでリズムを作り直します。

「採用タスク上位2〜3件が動作確認まで完了」「各タスクで変更前後のデグレード確認チェックリストが残っている」「変更に対応する設計書（画面仕様書・機能設計書）が更新されている」「タスク単位で小さくコミットされている」の4点が揃っていれば理想的。たとえば「予約一覧キャッシュ導入（チケット#1）Done、エラー文言修正（チケット#3）Done、スマホ対応はMVP範囲を再合意」のような形です。Done判定は「コード変更・動作確認・デグレード確認・設計書更新」の4点すべてが揃ったものだけ、を徹底します。

• 一度に大きく変えてしまう → 1コミット=1論理変更。10ファイル同時編集は危険信号
• 動作確認を変更後だけする → 変更前の動作も確認しないと「元から壊れていた」を見逃す
• 設計書の更新を後回し → 後回しは確実に忘れる。コミット前に必ず直す運用に
• 全員が同じタスクをやろうとする → かんばんで担当を明示、1タスク1担当を原則に
• Done基準が甘い（「ほぼDone」「コードはDone」） → 4点すべて揃わない限りDoneにしない
• 削る判断を先送り → 先送りすると最終日に強制カット。今日判断して明日に集中する

安心材料として、デグレード確認チェックリストは「変えた周辺の3〜5項目」を漏らさない最小セットで十分です。完璧主義は捨ててOK。

今日のAIの使い方は「コードを書かせる」より「変更の影響範囲を予測させる」のが効きます。

• 「以下のコードを変更します: [変更前] ↓ [変更後]。このコードは以下のファイルで呼び出されています: [一覧]。影響範囲と、デグレードの可能性がある箇所を5つ挙げてください」
• 「以下のチェックリストに漏れがないか確認してください: [チェックリスト貼り付け]」「以下の変更でデグレードしそうな箇所を5つ予測してください」

エラーが出たら全文を貼って相談、はDay11からの基本ルールのまま。AIの予測がすべて当たるわけではありませんが、人間が見落としがちな範囲をカバーできます。