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

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

昨日、最初の機能が動きました。今日は機能を増やしながら、もう1つの仕事をします。「設計書との突き合わせ」です。

ここで考えてみてください。昨日の実装で、設計書に書いていない判断を1つもしなかった人はいますか？

おそらく全員が、何かしら小さな判断をしています。「ボタンの文言を変えた」「項目を1つ後回しにした」。それ自体は自然なことです。危険なのは、その差分が記録されず、設計書とコードが別々の真実を語り始めることです。

今日のテーマは2つです。

1. 設計書と実装の差分を見つけて解消する
2. 差分の解消は「勝手に変えず、報告して設計書を更新する」

突き合わせとは、設計書と動いている実装を並べて、1項目ずつ照合する作業です。健康診断のようなもので、自覚症状（気づいている差分）だけでなく、無自覚の差分を見つけるのが目的です。

照合する組み合わせは次の通りです。

• 画面仕様書 ↔ 実際の画面（項目・ボタン・文言は一致しているか）
• 画面遷移図 ↔ 実際の遷移（ボタンを押すと設計通りの画面に行くか）
• テーブル定義書 ↔ 実際のデータ構造（カラム名・型・制約は一致しているか）
• 機能設計書 ↔ 実際の動作（入力チェック・ボタンの動作・初期設定は実装されているか）

差分を見つけたときの正しい順番は「報告 → 合意 → 設計書更新 → コード修正」です。「とりあえずコードを直しておいた」は良い行動に見えて、悪い例です。なぜなら、他のメンバーは古い設計書を信じて作業を続けるからです。逆に、差分をその場でチームに伝えて設計書を直すのは、一見遠回りでも、チーム全体では最短ルートになります。

• 設計書はそのまま動作確認のチェックリストになる（Day 16のテストでも同じ使い方をする）
• 差分は「見つけたら勝ち」。隠れた差分が中間発表当日に見つかるのが最悪のシナリオ
• 設計書の更新は変更箇所が分かるように残す（変更日・理由をメモする）

建築の世界には「竣工図」という言葉があります。最初の設計図に対し、工事中の変更をすべて反映した「完成時点の真実の図面」のことです。これがない建物は、配管がどこを通っているか壁を壊さないと分からず、改修費用が跳ね上がります。ソフトウェアも同じで、保守を引き継いだエンジニアが最初に探すのは「現状と一致した設計書」です。皆さんが今日やる突き合わせは、未来の誰か（数日後の自分を含む）への最高の贈り物です。

突き合わせと機能追加の両方で、AIが活躍します。相談例を場面別に示します。自チームの技術に置き換えてください。

設計書とコードの差分チェックを手伝ってもらう

設計書とコードの差分を確認したいです。
設計書（画面仕様書）の該当部分:
[仕様を貼る]
実装したコード:
[コードを貼る]
設計書にあるのに実装されていない項目、
実装にあるのに設計書にない振る舞いを、それぞれ列挙してください。

差分が見つかったとき、どちらに合わせるか整理する

設計書には「メールアドレスは重複不可」とありますが、
実装では重複チェックを入れていませんでした。
このチェックを後回しにした場合のリスクと、
今実装する場合の作業量の見積もりを整理してください。
チームで相談する材料にします。

昨日のコードを土台に機能を追加する

昨日作った「一覧表示」のコードを土台に、「新規登録」を追加します。
既存のコード: [貼る]
機能設計書の該当部分: [貼る]
既存コードを壊さずに追加する手順を、小さいステップに分けてください。
各ステップの動作確認方法もお願いします。

昨日の自分のコードが読めないとき

昨日自分で書いたコードですが、一部思い出せません。
[コードを貼る]
このコードが何をしているか、処理の流れに沿って説明してください。
そのあと、私が自分の言葉で説明するのでチェックしてください。

エラーが出たときの鉄則は昨日と同じです。エラーメッセージは全文を貼る。直前にやったことを添える。

• 機能追加の前に、既存機能がまだ動くことを確認する（壊してから気づくと原因探しが大変）
• 追加して動いたら、既存機能をもう一度動かす。これがデグレード（先祖返り）の最初の検知法
• AIに差分チェックを頼むときは、設計書とコードの「両方」を貼る。片方では照合できない

「昨日の自分は他人」という格言がプログラマの間にあります。ある調査では、エンジニアが「これは誰が書いたひどいコードだ？」と履歴を調べたら自分だった、という経験はほぼ全員にあるそうです。だからこそプロは、未来の自分という他人のためにコードにコメントを書き、設計書を更新します。今日のあなたの突き合わせ作業は、3日後のあなたへの親切です。3日後のあなたは、確実に今日の詳細を忘れています。

作業を始める前に、疑問があればAIに聞いてみましょう。たとえば：

• 「デグレードって何？　なぜ起きるの？　防ぐ習慣を初心者向けに教えて」
• 「設計書と実装の突き合わせを効率よくやる順番は？」
• 「実装中に設計の不備に気づいたとき、報告の仕方の例文を作って」

設計書との突き合わせと機能追加を並行して進めてください。

1. 既存機能の突き合わせ（最初の20分）

   • 昨日動かした機能を、画面仕様書・機能設計書と1項目ずつ照合する
   • 見つけた差分をメモに列挙する（この時点ではまだ直さない）
2. 差分の扱いをチームで決める（10分）

   • 差分ごとに「設計書を直す／コードを直す／後回しにしてTodoへ」を合意する
   • 設計書を直す場合は、その場で更新して変更理由をメモする
3. 機能追加の実装（〜90分）

   • かんばんの次のタスクに着手する（朝会で決めた分担に従う）
   • AIと方針を固めてから小さく書き、すぐ動かす
   • 追加後は既存機能がまだ動くことを必ず確認する
4. 終了10分前に動作確認とかんばん整理（10分）

   • 今日動いた機能をチームで操作し、終会に備える

• 追加実装された機能
• 実装と一致するよう更新された設計書（変更理由のメモつき）
• 実態に合ったかんばん

• 差分が多すぎて直しきれない → 全部直さなくてよい。「発表で見せる主要機能」に関わる差分を優先し、残りはTodoカードにする
• 設計書を直すべきかコードを直すべきか迷う → 「ペルソナにとってどちらが良いか」で判断する。迷ったらチームに聞く
• エラーが出たら → 「[エラー全文]というエラーが出た。直前に○○を変更した」とAIに伝えると解決策を教えてもらえます
• 機能追加で既存機能が壊れた → 慌てず「最後に動いていた状態から何を変えたか」をAIに伝えて切り分ける
• 突き合わせが面倒に感じる → 1機能あたり5分で終わる小さな作業。中間発表前日にまとめてやる方が何倍も大変

今回学んだことを一言でまとめると「設計書と実装を毎日一致させ続けるチームは、迷子にならない」です。

• 設計書はチェックリスト。1項目ずつ照合して差分を見つける
• 差分の解消は「報告 → 合意 → 設計書更新 → コード修正」の順
• 機能追加のあとは既存機能の動作確認（デグレード検知）

次のセッションは終会です。明日（Day 13）はチームコードレビュー、明後日（Day 14）は中間発表。残りの作業を見渡しておきましょう。

以下の問いに答えられるか確認してみましょう：

• 設計書と実装の差分を見つけたとき、最初にやることは何ですか？
• 突き合わせで照合する設計書と実装の組み合わせを2つ挙げられますか？
• デグレードを検知する一番簡単な習慣は何ですか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

• 参考リンク: 自チームの外部設計書・内部設計書・かんばん、Day 11 Session 1「実装の進め方」
• 発展課題: AIに「変更履歴を設計書に残すときの簡単な書式」を提案してもらい、チームの設計書に取り入れる

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