Day 12 - 本日のサマリー: 設計書とコードを毎日揃える日

• 日程: Day 12
• 本日のゴール: 外部設計書・内部設計書と実装を突き合わせ、差分を解消しながら機能を追加できる
• 対応する到達目標: No.7
• 本日の成果物: 追加実装された機能、更新された設計書（変更履歴付き）、更新済みかんばん

昨日「最初の1つ」が動きました。今日からは機能を増やしていきます。ここで一番起きやすい失敗はバグではなく「設計書と実装の食い違い」です。実装してみて初めて気づく設計の不備は必ず出てきます。そのときの正解は「勝手にコードだけ直す」ではなく「チームに報告 → 合意 → 設計書を更新 → コードを直す」。これはDay1で全員で決めた「合意した内容に変更が生じる場合には事前に報告して調整する」の実践です。今日からは新機能を追加するたびに「昨日動いた機能が今日も動くか」（デグレード確認）も毎日のルーチンに入ります。

今日から実装期間の本格的なリズム（朝会10分→実装2時間40分→終会20分）が始まります。朝会は立ったまま、議論はせず共有のみ、で短く回します。

「設計書と整合した追加機能が1〜2つ動いている状態」が目標。たとえば「会員登録画面の入力チェックが完成 → 設計書§3.2にパスワード確認欄を追加した変更履歴がある → 昨日の会員一覧も今日も動く」のような形。設計書を更新した変更履歴（日付・変更者・変更箇所・理由）が残っていれば理想的です。終会では「設計変更を全員で共有 → かんばん更新 → 遅れがあれば対策1つ合意」まで持っていきます。

• 設計書の更新を後回しにする → 必ずコード変更の「前」に設計書を直す。順序を逆にすると忘れる
• デグレードに気づくのが翌日 → 機能追加のたびに既存機能を1回操作するルーチンを作る
• AIに差分を聞くと毎回違う指摘が来る → 同じ観点リスト（入力・出力・エラー）を毎回指定する
• 朝会で深い議論が始まる → 司会が「それは朝会後に」と打ち切る。打ち切りは悪ではない
• 終会で原因分析が個人攻撃になる → 主語を「人」ではなく「タスク・順序・環境」にする

安心材料として、設計書の更新は「該当箇所の1〜2行」で済むことがほとんど。完璧な書き直しを目指す必要はありません。

「まず自分で書く → 詰まったところだけ聞く」を維持しつつ、今日からはAIを「差分の検出器」としても使います。

• 「画面仕様書とコードを並べます。仕様書: [貼る]。コード: [貼る]。入力項目・ボタン動作・エラー文言の3観点で差分を洗い出してください。勝手に直さず、差分だけ列挙してください」
• 「今、機能A（○○）を追加しました。変更ファイル: [一覧]。既存機能Bや共通処理に影響が出ていないか、確認すべき項目を5つ挙げてください」

差分の指摘を全部反映する必要はありません。「設計書を直すべきもの」「コードを直すべきもの」の振り分けはチームで判断します。