Part 6 最終プロジェクト・動画
第23章 Production Readiness Review
動画台本ナレーション全文
Slide 01. Production Readiness Review
第23章では、Production Readiness Reviewを扱います。略してPRRとも呼ばれます。日本語では、本番に出す前に、止める理由が残っていないか確認すること、と考えてください。正式な監査そのものをやる章ではありません。第21章で作り、第22章で改善した個人プロダクトを、届けてよいか、動かし続けられるか、問題が起きたとき気づけるか、という視点で確認します。
Slide 02. この章で持ち帰ること
この章で持ち帰ってほしいのは、リリース判断の根拠を作る型です。チェックリストを埋めること自体が目的ではありません。何をリリースするか、どの主要フローを確認したか、危ない点や使いにくい点が残っていないか、何を未確認として残すか。これを説明できる状態にして、go、go with follow-up、no-goのどれかを選べるようにします。
Slide 03. 第22章との接続
第22章では、学習ログ整理アプリにstatusを追加し、needs-helpだけを絞り込めるようにする改善PRを作りました。第23章では、その改善PRをrelease candidateとして扱います。release candidateは、リリース候補という意味です。つまり、まだ確認は必要だけれど、この差分を出すつもりで固定し、リリース前の確認対象にする、ということです。PR、commit、image tag、証拠一覧を書いておくと、あとから何を確認したのか追えます。
Slide 04. PRRは承認儀式ではない
PRRは、誰かに承認印をもらうためだけの儀式ではありません。目的は、確認したこと、まだ不安なこと、受け入れるリスクを言葉にすることです。完璧な状態を作れないとリリースできない、という話でもありません。大事なのは、どこまで確認済みで、どこからがfollow-upなのかを、レビューする人と同じ一覧で見られるようにすることです。
Slide 05. release candidate
リリース前確認は、release candidate、つまりリリース候補を決めるところから始めます。今回含める変更は何か、含めない変更は何か、既知の問題は何か、どの環境で確認したかを書きます。あわせて、確認対象のartifactやcommit、判断に使う証拠の場所も書きます。ここが曖昧だと、確認する範囲も曖昧になります。たとえば、status追加は入れるが、通知機能や大きなUI刷新は今回は含めない、と書きます。
Slide 06. 主要フローとリスク
次に、主要ユーザーフローとリスクを並べます。主要フローは、壊れるとプロダクトの価値に直撃する操作です。学習ログアプリなら、ログを作成する、一覧で確認する、needs-helpだけを絞り込む、が候補になります。すべての画面を同じ深さで見るのではなく、壊れたとき困るものから確認します。ここでは網羅より優先順位が大事です。
Slide 07. readinessの観点
readinessは、準備ができている状態、という意味です。この章では六つの観点で見ます。危ない使い方ができないか、誰でも操作しやすいか、遅すぎないか、問題が起きたときログや数字で追えるか、手順どおり動かせるか、文書が今の実装と合っているかです。英語名はこの後出ますが、ここでは全部覚えなくて大丈夫です。重大な見落としを減らすための観点として使います。
Slide 08. security readiness
security readinessでは、利用者やデータを危険にしないかを確認します。入力検証、認可、secret、依存関係、ログを見ます。入力検証は、不正な値を受け付けないことです。認可は、その人がやってよい操作だけを許すことです。secretはAPIキーやパスワードのような秘密情報です。AWSアカウントIDはsecretそのものではありませんが、公開提出やAI入力に不要なら含めません。危ない点が残っているときは、あとで直すで進めず、no-goとして止めて相談します。
Slide 09. accessibility readiness
accessibility readinessでは、使える人を不必要に減らしていないかを確認します。キーボードだけで操作できるか、入力欄にラベルがあるか、フォーカス位置が見えるか、エラー表示が分かるか、色だけで状態を伝えていないかを見ます。statusの追加や絞り込みUIは、画面を見ながら操作する人だけでなく、キーボードや支援技術を使う人にも影響します。
Slide 10. performance readiness
performance readinessでは、主要操作が現実的に使える速さかを見ます。研修では大規模負荷試験までは行いません。主要画面の表示、API応答、DB query、一覧件数が増えたときの懸念を確認します。測った場合は、環境、データ件数、操作、計測方法を一緒に残します。ここでの目的は、速さを競うことではありません。利用者が、ログを作る、一覧を見る、絞り込む、という主要操作を無理なく完了できるかを見ることです。
Slide 11. observability readiness
observability readinessでは、問題が起きたときに調べる手がかりがあるかを見ます。observabilityは、ログや数字を見て、何が起きたか追えることです。ログ、メトリクス、トレースという言葉が出てきますが、ここではまず、エラー時にどのログを見るかを決めます。あわせて、secretや個人情報をログに出していないか、そのログを提出物やAI入力へ共有してよいかも確認します。
Slide 12. operational readiness
operational readinessでは、動かしたあとに運用できるかを見ます。見るものは、作業手順、リリース直後の確認、問題が起きたときの戻し方、使い終わったリソースの片付けです。runbookは作業手順書です。do not proceed条件、問題時のエスカレーション条件、cleanupまで書くと実行しやすくなります。rollbackは前の状態へ戻すこと、revertは変更を打ち消す差分を入れることです。研修環境では、AWSリソースの確認場所や削除手順も運用確認に含めます。
Slide 13. documentation readiness
documentation readinessでは、文書が今の実装と合っているかを確認します。README、release note、migration note、runbook、known issuesを見ます。known issuesは、既知の問題です。文書確認は、文章をきれいにする作業ではありません。使う人、レビューする人、未来の自分が、起動方法、変更内容、制限、困ったときの確認先で迷わないようにします。
Slide 14. smoke test
smoke testは、リリース前に手順を決め、リリース直後に最低限使えるかを短時間で確認するテストです。名前の由来は、電源を入れて煙が出ないかを見るような最小確認です。長い総合テストではありません。主要フローを一つから三つに絞り、手順、期待結果、実際の結果、pass/fail、失敗時の対応を書きます。たとえば、起動、ログ作成、needs-help絞り込みを短く確認します。
Slide 15. release decision
PRRの最後は、release decision、つまりリリース判断をはっきり書きます。選択肢は、go、go with follow-up、no-goです。goは、このまま進める判断です。go with follow-upは、リリースはできるが、あとで追う残課題がある判断です。no-goは、危ない点が残るので今は出さない判断です。判断には、根拠、未確認事項、受け入れるリスク、follow-upの担当と期限を書きます。判断マトリクスにすると、blocker、smoke test、skipped check、accepted riskを一枚で見られます。
Slide 16. AIで抜け漏れ確認
AIは、PRRの抜け漏れ確認に使えます。たとえば、セキュリティ、アクセシビリティ、性能、ログ確認、運用手順、文書の観点で不足を挙げてください、と頼めます。runbookやsmoke test、release decision文書の下書きレビューにも使えます。ただし、AIの提案はそのまま採用しません。コード、設定、ログ、実行結果、公式資料で自分が確かめて初めて根拠になります。
Slide 17. AI利用時の注意
AIに、リリースしてよいかを丸投げしません。goかno-goかの判断は、確認した人が責任を持ちます。また、secret、実在の個人情報、本番データ、AWS account id、内部URL、未公開情報は入力しません。AWS account idはAPIキーではありませんが、環境を識別できる情報なので不要なら伏せます。入力前に秘密情報がないか見る。採用前にコードやログで確かめる。共有前やPR前に、根拠として書いてよい内容か確認する。この順番で使います。
Slide 18. ケース
ここからは、第22章の学習ログstatus改善を例にします。リリース候補は、学習ログにstatusを追加し、needs-helpだけを絞り込めるようにする変更です。既存ログはlearned扱いにし、READMEとrelease noteも更新済みとします。この前提で、何を確認し、何を残課題にするかを順番に見ます。
Slide 19. release candidate例
release candidate例では、変更内容と非対象を分けます。含めるものは、status追加、draft、learned、needs-helpの三種類、一覧での絞り込み、既存ログのlearned扱い、READMEとrelease note更新です。含めないものは、通知機能、権限機能、大量データ向けの最適化などです。さらに、PR、commit、migration note、release note、確認証拠の場所を書きます。含めないものを書くことで、レビュー範囲を必要以上に広げずに済みます。
Slide 20. 主要フロー例
主要フローは三つに絞ります。一つ目は、既存ログが一覧に表示されること。二つ目は、新しいログにstatusを保存できること。三つ目は、needs-helpだけを絞り込めることです。余裕があれば、不正なstatusが保存されないことも重要な確認です。ここで選んだ主要フローが、smoke testやrelease decisionの根拠になります。
Slide 21. security確認例
security確認例では、不正なstatusとsecretを見ます。statusがdraft、learned、needs-help以外なら保存しないこと。権限があるアプリなら、他人のログを勝手に変えられないこと。ログやREADMEやGitにsecret、個人情報、本番データが混ざっていないこと。依存関係の警告があれば内容を見ること。ここで重大な問題が見つかったら、no-goを選べることが大事です。
Slide 22. accessibility確認例
accessibility確認例では、status絞り込みをキーボードだけで操作できるかを見ます。Tabで絞り込みに移動できるか、選択中の状態が見えるか、ラベルが読み取れるか、エラー表示が色だけに依存していないかを確認します。自動チェックは便利ですが、それだけで終わらせません。主要操作を手で一度たどるだけでも、見落としがかなり減ります。
Slide 23. performance確認例
performance確認例では、一覧件数が増えたときの影響を見ます。研修用データが少ないうちは問題が出なくても、全件取得してから画面側で絞り込んでいるなら、件数が増えたとき重くなるかもしれません。今回は、主要操作の体感は問題なし、大量データ時の絞り込み性能は未確認、と書けます。これはgo with follow-upの材料になります。
Slide 24. observability確認例
observability確認例では、問題が起きたときにどこを見るかを書きます。起動に失敗したら起動ログ、画面操作でエラーが出たらアプリのログ、デプロイに失敗したらGitHub ActionsやApp Runnerのイベントを見る、という形です。CloudWatch Logsなどのサービス名は、実際に使っている環境に合わせて書きます。同時に、ログにsecretや個人情報を出していないかも確認します。
Slide 25. runbook例
runbook例では、リリース前、リリース直後、問題時、片付けを分けます。リリース前はテスト、lint、環境変数、migration noteを確認します。リリース直後はsmoke testとログ確認をします。問題時は、症状ごとに重大度、見る場所、対応、エスカレーション条件を書きます。戻す場合はrevertかrollbackの方針を書きます。研修環境なら、不要なAWSリソースの片付けも忘れずに入れます。
Slide 26. smoke test例
smoke test例は三つに絞ります。一つ目、アプリを開き、既存ログが表示されること。二つ目、statusがneeds-helpのログを作成できること。三つ目、needs-helpだけで絞り込めること。失敗したときの対応も書きます。たとえば、既存ログが出なければmigration noteとDBを確認し、絞り込みが失敗すればAPIと画面の状態を確認する、という形です。
Slide 27. release decision例
release decision例は、go with follow-upにします。理由は、主要フロー、既存ログ、入力検証、README、smoke testは確認済みだからです。一方で、大量データ時の絞り込み性能と、CloudWatch Logsでのエラー確認は未確認としてfollow-upにします。ここで大事なのは、なんとなく大丈夫と言わないことです。根拠と残るリスクを同じ文書に書きます。
Slide 28. follow-up issue例
follow-up issueは、未確認や残課題を追跡できる形にしたものです。P1は早めに追うもの、P2は次に余裕を見て追うもの、くらいに考えてください。例は、一覧件数が増えた場合の性能確認、CloudWatch Logsでのvalidation error確認、status絞り込みの自動テスト追加です。優先度、理由、次の行動に加えて、担当、期限、statusを書くと、リリース後に忘れにくくなります。
Slide 29. Chapter 24への接続
第24章では、最終発表と次の学習計画を扱います。第23章のPRR結果は、最終発表で、なぜ届けられる状態だと言えるかを説明する材料になります。goにできなかった場合も失敗ではありません。重大なリスクを見つけて止めたこと、次に何を直すべきかを説明できれば、それは実務に近い学びです。
Slide 30. Exercise 1
Exercise 1では、release candidateを整理します。最初に書くのは、今回リリースする変更、今回はリリースしないもの、どの環境で確認したかです。さらに、PR、commit、artifact、証拠一覧を書ける範囲で加えます。余裕があれば、主要ユーザーフローと既知の問題も加えます。成果物はrelease-candidate-summary.mdです。第22章のPR、release note、migration noteを材料にして、確認対象を固定してください。
Slide 31. Exercise 2
Exercise 2では、production readiness checklistを作ります。六つの観点ごとに、何を確認するか、どう確認するか、結果はどうだったかを書きます。確認できない項目がある場合は、理由、リスク、担当、期限、follow-upを書きます。チェックリストは、考えることを省く道具ではありません。レビュー前に、見落としを減らし、相談しやすくするための道具です。
Slide 32. Exercise 3-4
Exercise 3では、securityとaccessibilityを確認します。入力検証、認可、secret、ログ、依存関係、キーボード操作、ラベル、フォーカス、エラー表示を見ます。Exercise 4では、performanceとobservabilityを確認します。主要操作の速さ、データ量が増えたときの懸念、エラー時に見るログ、秘密情報がログに出ていないかを記録します。
Slide 33. Exercise 5
Exercise 5では、リリース判断にまとめます。release-runbook.mdとsmoke-test-plan.mdで、リリース前、直後、問題時、戻し方、片付けの手順を書きます。smoke testは三項目程度に絞り、実際の結果とpass/failを残します。最後にrelease-decision.mdでgo、go with follow-up、no-goを選び、判断マトリクス、理由、証拠を書きます。残課題はfollow-up-issues.mdに担当、期限、statusつきで残します。
Slide 34. まとめ
第23章のまとめです。Production Readiness Reviewは、承認儀式ではなく、本番前に確認したことと残る不安を説明できるようにする型です。release candidateを固定し、主要フローとリスクを見つけ、六つのreadiness観点で確認します。smoke testとrunbookで、直後の確認と問題時の動き方も用意します。最後は、なぜ届けてよいと言えるかを自分の言葉で話しましょう。