実装スプリント2〜設計書との突き合わせ

• 日程: Day 12 / セッション 2
• 時間: [9:40-12:20]（途中休憩11:00-11:10を含む）
• 形式: 実習
• ゴール: 外部設計書・内部設計書と実装を突き合わせ、差分を解消しながら機能を追加できる
• 学習形式: ハンズオン実習（AIペアプログラミング）

実装2日目です。昨日「最初の1つ」が動きました。今日からは機能を増やしていきます。

ここで一番起きやすい失敗は何だと思いますか。バグでしょうか。実は違います。「設計書と実装の食い違い」です。

実装を進めると、設計書に書いていない細部や、書いてあるが実装しにくい部分が必ず出てきます。そのとき「コードだけ直して進む」を選ぶと、設計書はどんどん嘘になり、最後には誰も信用しない紙くずになります。

今日のテーマはこれです。

実装中に設計の不備に気づいたら、勝手に変えずチームに報告して設計書を更新する。

これはDay 1で全員で決めたルール「合意した内容に変更が生じる場合には事前に報告して調整する」の実践です。

実装中、定期的に設計書とコードの差分を確認します。AIに頼むと効率的です。

AIへの突き合わせ依頼。

画面仕様書と、私が実装した画面のコードを並べます。
仕様書: [画面仕様書の該当部分を貼る]
コード: [実装コードを貼る]
仕様書とコードで以下の観点で差分を洗い出してください。
- 入力項目の過不足
- ボタンの動作の違い
- エラーメッセージの文言
洗い出すだけでOK、勝手に直さないでください。

差分が見つかったら、それぞれを「どっちが正しいか」チームで判断します。
コードが正しい場合: 設計書を更新する。
設計書が正しい場合: コードを直す。
どちらも違う場合: 設計書を改善してからコードも直す。

• 突き合わせは1日1回、お昼前か終会前に必ず実施
• 差分は「正誤判定」ではなく「どちらに合わせるか」の判断
• 判断は個人ではなくチームで合意

ある現場の格言に「設計書は鏡、コードは顔」というものがあります。鏡（設計書）が割れたまま顔（コード）を映すと、顔まで歪んで見えます。鏡を磨くのは時間の無駄ではなく、正しい顔を見るために必要な仕事、という意味です。設計書の更新は実装の邪魔ではなく、実装の前提を整える仕事です。

設計の不備に気づいた瞬間、手を止めるのが正解です。流れはこうです。

報告のテンプレート。

【設計変更の相談】
- 場所: 会員登録画面、機能設計書 §3.2
- 気づき: パスワード確認入力欄が無いが、ユーザーが入力ミスに気づけない
- 提案: 確認入力欄を追加し、不一致なら登録ボタンを押せないようにする
- 影響範囲: 会員登録画面のみ。テーブルへの影響なし
- 所要見込み: 設計書更新10分、実装30分
- 判断したいこと: 追加してよいか、Yes/No

5分以内に判断できる粒度で出します。判断が遅れそうなら、その日はその機能を保留し、別タスクに切り替えます。

• 「勝手に変えない」が鉄則
• 報告は5分で判断できる粒度・情報量で
• 変更後は必ず設計書を先に直してからコードを直す

NASAでは飛行士が宇宙船を改造したいと思っても、地上の管制に必ず申請します。判断が現場任せだと、見えていない他の系統に影響が出るからです。ソフトウェアも同じで、コードの一箇所の変更が他のテーブル・他の画面に波及することは日常茶飯事です。「勝手にやらない」は技術ではなく文化の話です。

機能を追加すると、既存機能が壊れることがあります。これを「デグレード」と呼びます。

追加実装したあと、必ず昨日動いた機能も触ります。

今日追加した機能の確認手順:
1. 新機能(会員登録)を1回操作 → 期待通り
2. 昨日動いた機能(会員一覧)を1回操作 → 期待通り
3. 昨日動いた機能から新機能への遷移 → 期待通り
全部OKならDoneにする。1つでもNGなら原因調査。

AIにも確認手順を聞けます。

今、機能A(○○)を追加しました。
変更したファイル: [一覧]
追加・変更した処理: [概要]
既存機能Bや共通処理に影響が出ていないか、
確認すべき項目を5つ挙げてください。

• 「新機能が動いた」だけで満足しない
• 昨日動いていたものが今日も動くかを必ず確認
• 確認項目はAIに洗い出してもらう

回帰テスト（regression test）という言葉があります。新しいコードが「昔は動いていた機能」を退化（regress）させていないか確認するテストです。手動で全部確認するのが大変なので、自動テストに育てていくのが王道ですが、研修期間中は「手で1回触る」だけでも十分価値があります。

実装中の判断に迷ったら、AIに聞いてみましょう。

• 「設計書とコードを突き合わせる効率的な方法を教えて」
• 「設計変更の影響範囲を洗い出すチェックリストを作って」
• 「デグレードを防ぐためにレビューで見るべき観点を5つ挙げて」

設計書と実装を突き合わせながら、機能を追加してください。

1. 開始時に設計書とコードの突き合わせ（15分）

   • 昨日動いた機能のコードと設計書をAIに見せて差分を洗い出す
   • 差分があればチームに報告して合意
2. 設計書の更新（必要な場合・15分）

   • 合意した変更内容を設計書に反映
   • 更新者と日付を残す
3. 今日のタスクを実装（〜90分）

   • かんばんのDoingに移して着手
   • エラーは全文をAIに貼る
4. デグレード確認（10分）

   • 新機能が動いたら、昨日の機能も操作して動作確認
5. かんばん整理（10分）

   • 終会の準備として実態をかんばんに反映

• 追加実装された機能（動作確認済み）
• 更新された設計書（変更履歴付き）
• 実態に合ったかんばん

• 設計とコードを並べて見るのが面倒 → AIに「ペーストする設計書とコードの差分を表で出して」と頼む
• 設計書の更新が大ごとに見える → 該当箇所の1〜2行で済むことが多い。完璧な書き直しを目指さない
• チームに相談するのが申し訳ない → 報告は早いほど傷が浅い。後で発覚するほうが何倍も大ごと
• デグレードが起きてしまった → 昨日のコミットまで戻して原因箇所を特定する。AIに「この変更で壊れる可能性のある箇所を挙げて」と聞く

今回学んだことを一言でまとめると「設計とコードを毎日揃える。ずれたら設計を直してからコードを直す」です。

• 設計書とコードの突き合わせを日課にする
• 設計変更は勝手にやらない。報告 → 合意 → 設計書更新 → コード変更
• デグレードを防ぐため、昨日動いた機能も毎日触る

次のセッションは終会。今日の設計変更と進捗を共有します。

• 実装中に設計の不備に気づいたら、最初にやることは?
• 設計変更フローの5つのステップは?
• デグレードを防ぐためにやることは?

• 参考リンク: 自チームの外部設計書・内部設計書、かんばん
• 発展課題: 設計書の変更履歴フォーマット（日付・変更者・変更箇所・理由）を作ってチーム共有

このセクションは、受講者が理解を深めることをサポートする参考情報です。