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

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

昨日の中間発表で、他チームや講評からフィードバックをもらいました。終会ではそれをかんばんのタスクに変換しましたね。今日はそのタスクを実装に反映する日です。

ここで1つ考えてみてください。
「フィードバックを反映する作業」で、いちばん怖いことは何でしょうか？

直したつもりの変更が、これまで動いていた別の機能を壊してしまうことです。これをデグレード（degrade、リグレッションとも呼びます）といいます。

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

• フィードバックを価値の高い順に実装する
• 変更のたびに「壊していないか」を確かめる

「直す」と「確かめる」を必ずペアで回しましょう。

昨日の終会で「すべてのフィードバックに対応しない勇気」を学びました。今日はその続きで、対応すると決めたタスクをどの順で実装するかです。

これは引っ越し後の荷ほどきに例えられます。段ボールは全部で50箱。最初に開けるのは「今夜の布団と歯ブラシ」が入った箱ですよね。「思い出のアルバム」の箱は後回しでも生活は回ります。

実装も同じです。

• 「デモで毎回通る画面の分かりにくい文言を直す」は該当します。低コストで、見せ場の価値が確実に上がるからです
• 「使うかどうか分からない管理者向け統計画面を新設する」は該当しません。高コストなのに、核となる体験に効かないからです

ここで自分のかんばんを見てください。
いちばん上にあるタスクは「核となる体験」に効くものになっていますか？

並べ替えの考え方を図にすると次の通りです。

かんばんのタスクカードの書き方の例です（ツールは何でも構いません）。

[FB-01] 登録完了後にメッセージが出ず不安、という指摘への対応
  完了条件: 登録成功時に完了メッセージが表示される
  見積もり: 30分 / 担当: Aさん / 優先度: 高（デモ導線上）

[FB-02] 検索結果が多いと見づらい、という指摘への対応
  完了条件: 検索結果を10件ずつ表示できる
  見積もり: 90分 / 担当: Bさん / 優先度: 中

• 「言われたから全部やる」は間違い。正しくは「価値と残り時間で選んだものを、確実に終わらせる」
• 1タスクは30〜60分で終わる大きさに分割する。大きいまま着手すると進捗が見えなくなる
• 完了条件を「〜される」と観測できる形で書く。「改善する」は完了条件にならない

品質管理の世界には「狩野モデル（Kanoモデル）」という有名な分類があります。1980年代に東京理科大学の狩野紀昭教授が提唱したもので、品質を「当たり前品質（ないと怒られるが、あっても褒められない）」と「魅力品質（なくても怒られないが、あると感動される）」などに分けます。トイレットペーパーがあるホテルは褒められませんが、ないと大問題になりますよね。フィードバックの取捨選択でも「これは当たり前品質の欠落か、魅力品質の提案か」と考えると優先順位がつけやすくなります。海外でもそのまま「Kano Model」と呼ばれる、日本発の世界標準です。

デグレードとは、変更によって以前は動いていた機能が壊れることです。

ジェンガを思い浮かべてください。1本抜いて上に積む、それ自体は成功しても、タワー全体がぐらつくことがあります。コードも同じで、複数の機能が同じデータや共通部品を共有しているため、1か所の変更が思わぬ場所に波及します。

• 「ログイン画面の文言だけを変えた」は波及しにくい変更です。他の機能はその文言を使っていないからです
• 「会員テーブルの項目名を変えた」は波及しやすい変更です。会員テーブルを読むすべての機能が影響を受けるからです

ここで考えてみてください。
変更の影響範囲を調べる「地図」を、みなさんはすでに持っています。何でしょうか？

Day 8で作ったCRUD図です。どの機能がどのテーブルを読み書きするかが一覧になっているので、「このテーブルを変えると、この機能たちに影響する」が一目で分かります。

変更作業は次のサイクルで回します。

1. 変更前: 影響範囲をCRUD図とAIで確認する
2. 変更する
3. 変更箇所そのものの動作を確認する
4. 周辺機能（同じテーブル・同じ共通部品を使う機能）も確認する

AIへの相談例です。特定の言語に関係なく使えます。

• 「会員情報の登録処理に入力チェックを追加したい。この変更が影響しそうな他の機能を、貼り付けた機能一覧とCRUD図から推測して」
• 「この関数を修正した。修正前と修正後のコードを貼るので、動きが変わるケースをすべて列挙して」

簡易デグレード確認リストの例です。

変更したら最低限ここを確認する
□ 変更した機能そのもの（正常な入力で動くか）
□ 変更した画面の「直前・直後」の画面遷移
□ 同じテーブル（データ）を読み書きする他の機能
□ 同じ共通部品（関数・部品・スタイル）を使う他の画面

• 「変更箇所が動いた」だけでは確認の半分。「まわりが壊れていない」まで見て完了
• 確認は手を動かす前に「どこを確認するか」を決めてから行う。行き当たりばったりの確認は漏れる
• よくある間違い: 動作確認を最後にまとめてやろうとする。正しくは1タスク終わるごとに小さく確認する（PDCAを小さく沢山）

デグレードの怖さを世界に知らしめた事件があります。2012年、米国の証券会社ナイト・キャピタルは、新システムの配備時に8台中1台のサーバだけ更新を忘れました。残っていた古いコードが誤って動き出し、わずか45分間で約4億6千万ドル（当時のレートで約360億円）の損失を出して、会社は事実上消滅しました。「古いものが残ったまま新しい変更を入れる」「変更後の確認を省く」ことの代償としては史上最大級です。みなさんの研修では失っても45分の作業時間だけですが、確認の習慣は今日から本物を身につけましょう。

新規に書くコードより、既存のコードを変更する作業のほうが実は難しいといわれます。元のコードの意図を理解しないと、正しく直せないからです。ここはAIの得意分野です。

人間の名医に例えると、手術の前にレントゲンを撮りますよね。AIに既存コードを読ませるのは、変更前のレントゲン撮影です。

• 「このコードを貼るので、何をしているか日本語で説明して」→ 理解してから直せる
• いきなり「直して」だけ伝えて出てきたコードを貼り付ける → 理解しないまま変更し、デグレードの温床になる。これはAIペアプログラミングに該当しません

変更作業で使えるAIへの依頼パターンです。

• 理解: 「この処理の流れを箇条書きで説明して。特にデータがどこで書き換わるか教えて」
• 設計相談: 「完了メッセージを出す方法を2案出して。それぞれの長所・短所と、既存コードへの影響の大きさを比べて」
• エラー解決: 「変更したらこのエラーが出た。エラーメッセージ全文と変更箇所を貼るので、原因の候補を挙げて」
• 確認観点: 「この変更のあとに手動で確認すべき操作を、チェックリスト形式で出して」

• 設計書とコードがずれたら設計書を直す。Day 12で決めたルールを今日も守る
• 設計の変更はチームに報告してから（合意した内容の変更は事前に報告して調整）
• エラーは要約せずに全文をAIに貼る。要約すると手がかりが消える

プログラマの間には「ラバーダックデバッグ」という伝統があります。机にゴム製のアヒルを置き、バグで詰まったらアヒルに向かってコードを1行ずつ声に出して説明するのです。不思議なことに、説明している途中で「あっ、ここだ」と自分で気づくことが多い。人に説明しようとすると、頭の中の思い込みが整理されるからです。みなさんにとってAIは「返事をしてくれるアヒル」です。説明するだけで気づきが得られ、さらに向こうからもヒントが返ってくる。アヒル時代から考えると、ずいぶん贅沢な環境になりました。

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「デグレードとリグレッションは同じ意味？実務ではどう使い分けるの？」
• 「フィードバックの優先順位づけがチームで割れたら、どう決めればいい？」
• 「変更の影響範囲を調べる方法を、CRUD図以外にも教えて」

朝会で確認した優先順位に従い、フィードバック対応タスクを実装します。

1. 着手前（10分）: 最初のタスクについて、変更の影響範囲をCRUD図・機能一覧とAIで確認する
2. 実装前半（9:50-11:00）: 優先度の高いタスクから実装する。1タスク終えるごとに変更箇所＋周辺の動作確認を行う
3. 休憩（11:00-11:10）
4. 実装後半（11:10-12:10）: 実装を続ける。設計書とずれたら設計書を更新し、チームに報告する
5. 仕上げ（12:10-12:20）: 本日変更した機能をチーム内で見せ合い、かんばんのカードを動かす

• フィードバック反映済みの機能（動作確認まで完了したもの）
• 更新済みかんばん
• デグレード確認のメモ（どこを確認したかの簡単な記録）

• エラーが出たら、AIに「〜という操作をしたら、このエラーが出た」とエラー全文を貼って相談しましょう
• 影響範囲が分からないときは、CRUD図を貼って「この変更で影響する機能はどれ？」と聞きましょう
• 30分詰まったら1人で抱えず、チームに共有しましょう。タスクの交換や分担の見直しも立派な対策です
• 「直す前のほうが良かった」と気づいたら、戻す判断も正解です。変更前の状態を残しておきましょう

今回学んだことを一言でまとめると、**「フィードバック反映は『直す』と『壊していないか確かめる』のセットで初めて完了」**です。

• 対応順は「核となる体験」への効果と残り時間で決める
• CRUD図は影響範囲調査の地図になる
• AIには「理解→変更→確認」の各段階で役割がある

このあとの終会で、完成までの残タスクを把握します。次回Day 16は、品質向上とテスト。今日身につけた「確かめる」習慣を、チーム全体のテストに広げます。

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

• デグレードとは何か、ジェンガ以外の自分のたとえで説明できるか
• 変更の影響範囲を調べる方法を2つ以上挙げられるか
• 今日対応したフィードバックを「なぜそれを先にやったのか」つきで説明できるか

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

• 参考リンク: 自チームで使っている開発ツール・実行環境の公式ドキュメント
• 発展課題: 「回帰テスト（リグレッションテスト）の自動化は実務でどう行われているか」をAIに聞き、手動確認との違いをまとめてみましょう

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