実装スプリント4〜フィードバックの反映

• 日程: Day 15 / セッション 02
• 時間: [9:40-12:20]（160分、途中休憩 11:00-11:10 を含む）
• 形式: 実習（ハンズオン、AIペアプログラミング）
• ゴール: 中間発表で決めた対応タスクを実装し、動作確認まで完了できる

  • 行動: 採用タスクを実装し、変更前後で動作確認する
  • 条件: 1タスクごとにデグレード確認を実施し、AIに差分レビューを依頼する
  • 基準: 採用タスクのうち優先度上位2〜3件を完了し、既存機能が壊れていない
• 学習形式: ハンズオン実習（AIペアプログラミング）

実装スプリント4の主役は「デグレード確認」です。

フィードバック反映の難しさは、新規実装と違って「既に動いているもの」に手を入れる点にあります。新しく作るときは「動けばOK」。でも、既存に手を入れるときは「変えたところが動く」かつ「変えていないところも壊れていない」、両方が必要です。

「直したつもりが壊した」を防ぐ最強の武器は、チェックリストと小さい変更です。一度に大きく変えず、1タスクごとにコミット→動作確認→次のタスク、を回します。

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

1タスクごとに次のサイクルを回します。

「変更前に動作確認する」がポイントです。元々動いていなかったものを変えて「壊れた」と騒ぐのは時間の無駄。最初に元の状態を握ります。

「エラー文言修正」タスクの例（変更前後）

// 変更前
function validateEmail(email) {
  if (!email.includes("@")) {
    return "エラー";
  }
  return null;
}

// 変更後（フィードバック: エラー文言が不親切）
function validateEmail(email) {
  if (!email.includes("@")) {
    return "メールアドレスの形式が正しくありません。例: user@example.com";
  }
  return null;
}

このとき確認すべきこと：

1. 不正なメール入力でメッセージが新しい文言になる（変更箇所の動作）
2. 正常なメール入力ではエラーが出ない（既存動作の保持）
3. 他のフォーム（パスワードなど）のエラー文言が変わっていない（影響範囲外の確認）

3番目の「影響範囲外の確認」を忘れがちです。「メール関連だけ触ったから他は関係ない」と思い込むと、共通化された関数の修正で全画面に影響、というパターンに気づけません。

ソフトウェア工学では「リグレッションテスト」（回帰テスト）という言葉があります。1970年代から使われている言葉で、「変更によって過去のバグが再発していないか」を確認するテストです。プロのエンジニアは新機能を作るたびにリグレッションテストを書きます。今回の研修では自動テストまでは作りませんが、「変更前のチェックリスト」を作っておくのが入門編のリグレッションテストです。

変更前に「ここは動くはず」というチェックリストを作っておきます。

# デグレード確認チェックリスト（予約一覧キャッシュ導入時）

## 変更前に動作することを確認した項目
- [x] 予約一覧画面が3秒以内に表示される（変更後の目標）
- [x] 予約登録→一覧に即反映される
- [x] 予約キャンセル→一覧から消える
- [x] 検索フィルタが動作する
- [x] 並べ替えが動作する

## 変更後に再確認する項目（同上）
- [ ] 予約一覧画面が1秒以内に表示される（改善目標）
- [ ] 予約登録→一覧に即反映される（キャッシュで遅延しないか）
- [ ] 予約キャンセル→一覧から消える（キャッシュで残らないか）
- [ ] 検索フィルタが動作する
- [ ] 並べ替えが動作する

チェックリストは「項目を増やす」よりも「変えたところの周辺3〜5項目を漏らさない」のが重要。完璧主義を捨てて、影響範囲をカバーする最小セットを作ります。

「自分の変更がどこに影響するか」は、コードベースが大きくなるほど見えにくくなります。AIに事前予測を頼みましょう。

プロンプト例:
「以下のコードを変更します。
 [変更前コード]
 ↓
 [変更後コード]

 このコードは以下のファイルで呼び出されています:
 - userForm.js
 - registerPage.js
 - profilePage.js

 影響範囲と、デグレードの可能性がある箇所を5つ挙げて。」

AIは静的解析的に「呼び出し元」「関連処理」「副作用」を列挙してくれます。すべてが当たるわけではありませんが、人間が見落としがちな範囲をカバーできます。

実装が設計書から離れたら、設計書を直す。これはDay11から繰り返し言っているルールです。フィードバック反映では特に重要。

「画面仕様書ではエラー文言が『エラー』だったが、新しい文言に変えた」→ 画面仕様書を更新する。

更新を怠ると、Day20のリハーサルや、Day22の振り返りで「設計と実装が違う」とハマります。実装したらすぐ設計書を直す。これを徹底します。

設計書の更新はチームで分担する。「実装した本人が直す」が原則。3行コミットしたら設計書も3行直す。重くしない。

実装中、こんな質問が効きます。

• 「以下の変更でデグレードしそうな箇所を5つ予測して：（変更内容貼り付け）」
• 「以下のコードを変更します。テスト観点を10個挙げて：（コード貼り付け）」
• 「以下のチェックリストに漏れがないか確認して：（チェックリスト貼り付け）」
• 「このエラーログの原因と対策を：（ログ貼り付け）」

エラーが出たら全文貼って相談。これがAIペアプログラミングの基本です。

160分（途中休憩込み）で以下を完了させてください。

1. 採用タスク（優先度上位2〜3件）を実装
2. 各タスクで変更前後のデグレード確認を実施
3. AIに最低1回、影響範囲予測を依頼
4. 変更に対応する設計書（画面仕様書・機能設計書）を更新
5. 各タスク完了ごとにコミット（小さく頻繁に）

• フィードバック反映済みの実装
• デグレード確認チェックリスト（タスクごと）
• 更新済み設計書
• コミット履歴（タスク単位）
• 更新済みかんばん

• 大きいタスクは分割する（例：「スマホ対応」→「ヘッダー」「フォーム」「一覧」）
• エラーで詰まったら15分悩んだらAIに全文貼って相談
• 1人で抱えず、チームメンバーに「ペアで見て」と頼む

フィードバック反映は「小さく変えて小さく確認」。デグレード確認は変更前と変更後で同じチェックリストを通す。AIには「コードを書かせる」より「影響範囲を予測させる」。設計書もその場で更新。これでDay16以降にハマらない。

• 採用タスクを2〜3件完了できましたか？
• 各タスクでデグレード確認を実施しましたか？
• 設計書は実装に追従していますか？

• 参考: リグレッションテスト、テスト駆動開発（TDD）の入門、「壊れた窓理論」
• 発展課題: チェックリストをGoogleスプレッドシートで共有して、Day16のテスト計画の土台にする