Part 6 最終プロジェクト・動画
第22章 既存プロダクト改善
動画台本ナレーション全文
Slide 01. 既存プロダクト改善
第22章では、既存プロダクト改善を扱います。ここで言う既存プロダクトは、すでに誰かが使える状態になっていて、画面、データ、README、テスト、確認手順があるアプリのことです。第21章で作った個人プロジェクトも、ここからは既存プロダクトとして見ます。新しく作る力とは別に、今ある価値を壊さずに変える力を身につけていきます。
Slide 02. この章で持ち帰ること
この章で持ち帰ってほしいのは、改善を安全に進める型です。型と言っても難しい手続きではありません。変更前を証拠つきで確認する、要求を分ける、影響範囲を見る、互換性を考える、回帰確認を残す、PRとrelease noteで説明する。この順番で見ると、壊す可能性に早く気づけます。
Slide 03. 第21章との接続
第21章では、自由テーマの個人プロジェクトを企画し、最初に動く形まで作りました。第22章では、そのアプリに小さな改善を入れます。たとえば、学習ログ整理アプリにstatusを追加し、相談が必要なログだけを絞り込めるようにします。ここで大事なのは、新しい機能だけを見るのではなく、すでに動いている作成、一覧、既存データを守ることです。
Slide 04. 新規開発と既存改善の違い
新規開発では、まだ誰も依存していないものを作る場面が多いです。一方、既存改善では、すでにある使い方、データ、手順、期待があります。これを、この章では現在の約束と呼びます。約束は契約書のような大げさなものだけではありません。READMEの起動手順、一覧画面にログが出ること、保存済みデータが読めることも、利用者にとっては約束です。
Slide 05. 変更前の棚卸し
改善の最初の作業は、変更前の棚卸しです。棚卸しとは、今あるものを数えて状態を確認することです。画面を開く、ログを作る、一覧を見る、README通りに起動する、テストを走らせる。期待結果と実際の結果、証拠、まだ確認していないことを残します。これを先にやっておくと、変更後に何かおかしいとき、前からそうだったのか、今回壊したのかを分けて考えられます。
Slide 06. 変更要求を分解する
変更要求は、そのまま実装しません。たとえば、statusで絞り込みたいという依頼だけでは、まだ足りません。誰が何を見つけやすくしたいのか、statusはどんな値を持つのか、画面にどう表示するのか、既存ログはどう扱うのか、今回は何をやらないのかを分けます。値の意味、表示名、default、validationをそろえておくと、あとから表記や仕様がずれるのを防げます。
Slide 07. 影響範囲
影響範囲とは、この変更でどこが関係しそうかを見ることです。statusを追加するだけでも、画面の入力、一覧の絞り込み、保存処理、API、DB、テスト、READMEに触れるかもしれません。すべてを完璧に予想する必要はありません。分かったことと未確認のことを分けて書き、検索、テスト、実際の操作で確かめるのが現実的です。
Slide 08. 互換性
互換性とは、既存の使い方やデータが、変更後も壊れずに使えることです。APIの返す形を変える、DBの項目を急に必須にする、READMEと違う操作にする。こうした変更は、小さく見えても利用者を困らせます。ここでは全部を禁止するのではなく、壊す可能性があるなら、移行方法、告知、戻し方を先に考える、という姿勢を持ちます。
Slide 09. 既存データ
既存データを見るときは、すでに保存されているログが、変更後も自然に読めるかを考えます。status列を追加するなら、古いログにはstatusがありません。空を許すのか、未指定ならlearnedにするのか、あとから値を入れるのかを決めます。nullable、default、backfill、読み取り時補完は似ていますが、既存データへの効き方が違います。defaultを入れても、既存ログに自動で値が入るとは限りません。
Slide 10. migration note
migration noteは、データ変更の説明メモです。migrationは、データの形を新しい形へ移すことです。本番データ移行の細かい運用までは扱いません。研修では、何を変えたか、古いデータをどう扱うか、どう確認するか、戻すとき何に注意するかを書きます。status追加なら、既存ログはlearned扱いにすると明記します。
Slide 11. 仕様変更とリファクタリング
仕様変更とリファクタリングは分けて考えます。仕様変更は、外から見える振る舞いを変えることです。リファクタリングは、外から見える振る舞いを変えずに内部を整理することです。どちらも大事ですが、同じ大きな差分に混ぜると、レビューする人は、何が必要な変更で、何が整理なのか判断しづらくなります。
Slide 12. 回帰確認
回帰確認は、新しい機能だけでなく、前からできていたことが壊れていないかを見る確認です。status絞り込みを作ったら、絞り込みが動くかだけでなく、ログを作れるか、一覧に既存ログが出るか、不正なstatusを保存しないかも見ます。改善PRの品質は、新機能が動くことだけでは決まりません。既存の価値を守れているかで決まります。
Slide 13. characterization test
characterization testは、今の動きを記録するテストです。難しい名前ですが、意味は、今のアプリはこう動いている、という証拠をテストにすることです。既存テストが少ないプロジェクトでも、完璧なテスト群を急に作らなくて大丈夫です。まず、壊したくない主要動作を一つテストにします。
Slide 14. 小さなPR
PRは、コードを渡す箱ではなく、変更の意図と安全性をレビューしてもらう単位です。大きな改善を一度に出すと、見る人も戻す人も大変です。調査、テスト追加、必要最小限のリファクタリング、仕様変更、README更新を分けて説明できるようにします。研修では一つのPRにまとめても、PR本文の中で意図を分けて書きます。
Slide 15. release note
release noteは、何が変わったかを利用者や運用者に伝える短い文書です。技術的な差分だけでなく、利用者に見える変化を書きます。statusを追加したなら、相談が必要なログを絞り込めるようになったこと、既存ログはlearned扱いになること、必要な行動、既知の問題があるならそれも書きます。実装して終わりではなく、変化を理解できる状態にします。
Slide 16. AIで影響調査
AIは、影響範囲調査の補助に使えます。たとえば、この変更で関係しそうなファイルをUI、API、DB、テスト、READMEに分けて挙げてください、と頼めます。互換性リスクや回帰確認の候補出しにも使えます。ただし、AIの出力は仮説です。開発者が検索、差分、テスト、手動確認で確かめ、採用した提案と採用しなかった提案を残します。
Slide 17. AI利用時の注意
AIを使うときは、入力してよい情報にも注意します。APIキーやパスワードなどの秘密情報、実在の個人情報、本番データ、未公開の事業情報は入れません。また、AIが影響なしと言っても、確認済みという意味ではありません。関連ファイル、README、既存データ、validation、rollbackを検索し、テストや画面操作で確かめて、確認ログに残します。
Slide 18. ケース
ここからは、共通ケースで流れを見ます。題材は学習ログ整理アプリです。学習ログを作成でき、ログには日付、タイトル、本文、タグがあります。一覧でログを確認でき、READMEにローカル起動方法があります。大きな業務システムでなくても、すでに保存されたログと使い方があるなら、それは守る対象を持つ既存プロダクトです。
Slide 19. 変更要求
変更要求は、相談が必要なログだけを見つけたい、というものです。そのために、学習ログにstatusを追加します。statusはdraft、learned、needs-helpの三種類にし、一覧でstatusを選んで絞り込めるようにします。既存ログは、最初はlearned扱いにします。ここまで書くと、ボタンを足すだけではなく、データと確認方法まで含む変更だと分かります。
Slide 20. 守ること
この改善で動作として守ることは三つあります。一つ目は、既存ログが表示され続けること。二つ目は、これまで通りログを作成できること。三つ目は、不正なstatusを保存しないことです。別の注意として、実在の個人情報や本番データは扱いません。先に守ることを決めると、実装中の判断がしやすくなります。
Slide 21. 棚卸し例
棚卸しでは、現在の主要動作を表にします。たとえば、ログを作成できる、一覧でログを見られる、タグが表示される、README通りに起動できる、既存テストが通る、という形です。証拠として、画面確認、コマンド結果、テスト結果を残します。きれいな文書にすることより、変更前の基準として使えることが重要です。
Slide 22. 影響範囲例
status追加の影響範囲を例で見ます。UIでは入力欄と絞り込みUIが変わります。APIやサーバー側の処理では保存と取得が変わります。DBではstatus列や初期値が関係します。テストでは既存作成と新しい絞り込みを確認します。READMEでは使い方と確認方法を更新します。一つの変更でも、関係する場所は画面だけでは終わりません。
Slide 23. 互換性リスク例
互換性リスクも具体的に書きます。既存ログにstatusがないと一覧から消えるかもしれないので、learned扱いにします。APIの返す形が変わるなら、呼び出し元を確認します。不正なstatusを受け付けると絞り込みが壊れるので、保存前にチェックします。リスクと対策を並べると、レビューで確認しやすい材料になります。
Slide 24. 回帰確認例
回帰確認例では、既存機能と新機能を分けます。既存機能は、ログを作成できる、一覧に既存ログが出る、タグが表示される、README通りに起動できる。新機能は、draft、learned、needs-helpを保存できる、statusで絞り込める、不正値を保存しない。変更前の基準と変更後の期待結果も分けます。自動テストにするものと手動確認にするものも分けておくと、確認漏れが減ります。
Slide 25. safe change plan例
safe change planでは、変更手順を小さく分けます。まず今の動きを確認し、必要なら、壊したくない動きを一つテストにします。次にDBと型、保存処理、画面、絞り込みを順に変えます。各手順には、完了条件、検証、止める条件を書きます。最後にREADME、データ変更メモ、PR説明、release noteを更新します。リファクタリングが必要なら、仕様変更と混ぜすぎず、理由と範囲を書きます。
Slide 26. migration note例
migration note例では、既存ログをlearned扱いにすると書きます。データ変更は、学習ログにstatusを追加すること。既存データの扱いは、statusがないログをlearnedとして表示すること。選んだ戦略、default、backfillをしない理由も書きます。確認方法は、古いログが一覧に残り、learnedの絞り込みにも出ることを見ることです。戻す場合は、データを消すのか、使わず残すのか、roll forwardで直すのかを確認します。
Slide 27. PR説明例
PR説明には、変更理由、変更内容、互換性、データ移行、確認結果、実行していない確認、残課題を書きます。たとえば、相談が必要なログを見つけやすくするためにstatusと絞り込みを追加した、既存ログはlearned扱いにした、作成と一覧の回帰確認を実施した、という形です。最後に、既存ログの扱いと不正なstatusの確認を見てください、のようにレビューしてほしい点も書きます。
Slide 28. release note例
release noteは、PR説明よりも利用者向けに書きます。今回の例なら、学習ログにstatusが追加され、相談が必要なログを絞り込めるようになりました、と書きます。影響を受ける人、必要な行動、既存ログはlearnedとして扱われること、READMEの確認手順を更新したこと、既知の問題も書きます。技術詳細を全部書くより、使う人に見える変化を優先します。
Slide 29. Chapter 23への接続
第22章の成果物は、第23章のProduction Readiness Reviewにつながります。これは、本番に出す前に、出してよい状態かを確認するレビューです。既存振る舞いの棚卸し、影響範囲、回帰確認計画、migration note、release noteは、リリース前確認の材料になります。この章で残した判断理由、確認結果、残課題が、次章の入口になります。
Slide 30. Exercise 1-2
Exercise 1では、既存振る舞いを棚卸しします。主要操作、画面、API、DB、README、テスト、既存データを見て、変更前の基準を残します。期待結果、実際の結果、未確認事項も書きます。Exercise 2では、変更要求と影響範囲を整理します。目的、やること、やらないこと、受け入れ条件、statusなど新しい値の契約、互換性リスク、未確認事項を書きます。
Slide 31. Exercise 3
Exercise 3では、回帰確認計画を作ります。既存動作、新しいstatus機能、自動テストにするもの、手動確認にするものを分けます。既存テストが少ない場合は、壊したくない現在の動きを一つ選び、テストにします。確認しないものがある場合も、理由とあとで見る方法を残します。
Slide 32. Exercise 4-5
Exercise 4では、安全に変えるための手順と、データ変更メモを作ります。手順、止める条件、リファクタリングの境界、既存データの扱い、戻し方、AIに任せる範囲、セキュリティと依存関係の確認を書きます。Exercise 5では、改善を実装し、テスト、lint、型チェック、手動確認を行います。最後にPR説明、release note、README、第23章で確認する残課題を残します。
Slide 33. まとめ
第22章のまとめです。既存プロダクト改善では、良さそうな変更をすぐ実装する前に、現在の約束を確認します。変更要求を分解し、影響範囲、互換性、既存データ、回帰確認を見ます。PRとrelease noteでは、なぜ変えたか、何を確認したか、次に何を見るかを説明します。これが、作る力から、壊さず変える力への一歩です。