第23章 Production Readiness Review | エンジニア入門研修

この章では、作ったものを「本番相当へ出してよいか」を判断する型を学ぶ。ここでは、研修の外でも通用する一般的な専門用語だけを取り上げて解説する。

Production Readiness Review / PRR

読み：プロダクションレディネスレビュー／Production Readiness Review（略PRR）
一言で言うと：本番または本番相当へ出す前に、止める理由が残っていないかを確認する作業である。
くわしく：PRRは、動くことと出してよいことを切り分けるために行う。一度動いただけでは、危険な入力を保存できる、READMEが古い、エラー時に見る場所が分からない、戻し方がない、といった問題が残ることがある。これらを出す前に確認できる。PRRはGoogle SREなどの実務で使われる一般的な考え方で、正式な監査やペネトレーションテストとは別物である。研修の個人課題でも、誰かに見せる、レビューしてもらう、デモで使う、クラウドへ置くなら役に立つ。
具体例：支援ステータス機能、つまり学習ログにstatusを追加し needs-help だけを絞り込めるようにした改善を、本番相当へ出す前にPRRにかける。不正なstatusを保存できないか、既存ログが消えていないか、戻せるかを確認できる。
つまずきやすい点：PRRをチェックリストの丸付けだと考えると形だけになる。確認結果から、出してよいかどうかの判断につなげることが目的である。
関連語：go / no-go（第23章）、blocker（第23章）、runbook（第16章、第23章）
テキスト本文での登場箇所：第23章「PRRはチェックリスト消化ではなく判断作業である」

release candidate

読み：リリースキャンディデート／release candidate（略RC）
一言で言うと：リリース判断の対象になる、候補版の成果物である。
くわしく：release candidateは「これを出すか決める対象」を固定するために使う。何を出すのか、何を含めないのか、どの環境で確認するのか、どのPR、commit、image tag、artifactを確認したのかが曖昧だと、確認観点も最後の判断も曖昧になる。先に対象を固定すれば、確認の深さよりも先に確認対象の明確さを確保できる。一般には、リリース直前の安定した候補版をrelease candidate(RC)と呼ぶ。
具体例：支援ステータス機能の改善PRをrelease candidateとして扱う。「status追加と絞り込みは含める、通知や変更履歴は含めない、localで確認する」と決めて対象を固定できる。
つまずきやすい点：対象を固定しないまま確認を始めると、何を出すのかが途中で揺れる。included、not included、確認環境、commitやartifact、証拠一覧を先に書くとよい。
関連語：Production Readiness Review / PRR（第23章）、artifact（第23章）、evidence index（第23章）、go / no-go（第23章）
テキスト本文での登場箇所：第23章「Release Candidateを固定する」

artifact

読み：アーティファクト／artifact
一言で言うと：確認やリリースの対象になる具体的な成果物である。
くわしく：artifactは、PR、commit、build済みのcontainer image、配布ファイル、生成されたrelease noteなど、後から「どれを確認したのか」を特定するための対象を指す。PRRでは、動作確認した差分と実際に出す差分がずれると判断の根拠が崩れる。厳密なimage tagを使わない研修でも、PR番号、commit SHA、作業branch、提出ファイル名を記録すると追跡しやすい。
具体例：支援ステータス機能で、feature/status-filter branchの特定commit、またはECR image tagをrelease candidateのartifactとして記録する。
つまずきやすい点：「localで見た」で終えると、後からどの差分を見たのか分からない。可能な範囲でPR、commit、image tag、提出ファイル名を残す。
関連語：release candidate（第23章）、release decision（第23章）
テキスト本文での登場箇所：第23章「Release Candidateを固定する」

evidence index

読み：エビデンスインデックス／evidence index
一言で言うと：リリース判断に使う証拠の所在をまとめた一覧である。
くわしく：evidence indexは、regression test plan、security/accessibility readiness、performance/observability readiness、runbook、smoke testなどの証拠がどこにあるかを示す目次である。判断時に「テストは通ったはず」「ログは見た気がする」と記憶に頼るのを避ける。リンクを貼れない研修でも、ファイル名、コマンド結果、手動確認メモを残すだけで、レビューする人が根拠へたどりやすくなる。
具体例：release candidate summaryに、regression-test-plan.md: pass、security-accessibility-readiness.md: partial、smoke-test-plan.md: pass と書く。
つまずきやすい点：証拠を本文に散らばらせると、release decisionで根拠を探し直すことになる。最初に一覧化する。
関連語：release candidate（第23章）、release decision（第23章）
テキスト本文での登場箇所：第23章「Release Candidateを固定する」

blocker

読み：ブロッカー／blocker
一言で言うと：このまま出すと大きな問題が起きるため、出す前に直すべき項目である。
くわしく：blockerは、利用者、安全性、運用に重大な影響があり、リリースを止める理由になる課題を指す。残っていてもよい課題（受容するリスクや後で追うfollow-up）と区別するために使う。blockerがあるなら、出すより先に直す。何がblockerで、なぜそう言えるかを説明できることが大切である。
具体例：支援ステータス機能で、不正なstatusを保存できる、secretがログやREADMEに出ている、既存ログが表示されない、といった問題はblockerになる。これらが残るなら出さない。
つまずきやすい点：すべての不安をblockerにすると何も出せなくなる。影響の大きさで、blocker、受容するリスク、follow-upに分ける。
関連語：accepted risk（第23章）、go / no-go（第23章）
テキスト本文での登場箇所：第23章「Security Readinessは危ない使い方を防ぐ確認である」

accepted risk

読み：アクセプテッドリスク／accepted risk
一言で言うと：残っているが、影響と追跡方法を理解したうえで今回は受け入れるリスクである。
くわしく：accepted riskは、リスク管理の一般的な考え方で、ゼロにできないリスクを意識的に受け入れることを指す。すべてのリスクを消すことはできないので、出す前に「受け入れるもの、先に直すもの、後で追うもの」に分けて整理できる。受け入れると決めたら、なぜ受け入れてよいか、影響はどの程度か、どう追うかを記録する。隠したまま残すのとは違う。
具体例：支援ステータス機能で、大量データ時の絞り込み性能は未計測だが、現在の研修データ量では問題が小さいと判断し、accepted riskとして受け入れる。あわせてfollow-upで追う。
つまずきやすい点：「未確認だが問題ないと思う」で済ませると、受容ではなく見落としになる。影響と追跡方法をセットで書く。
関連語：blocker（第23章）、go / no-go（第23章）
テキスト本文での登場箇所：第23章「Release Decisionは証拠とリスクで書く」

skipped check

読み：スキップドチェック／skipped check
一言で言うと：本来確認したいが、今回は実行しなかった確認項目である。
くわしく：skipped checkは、隠すものではなく判断材料として明示するもの。理由、残るリスク、owner、期限、follow-upを書くと、go with follow-upにできるか、no-goにすべきかを検討しやすい。理由がなく、リスクも追跡方法もないskippedは、単なる見落としに近い。
具体例：大量データ時の性能確認は研修範囲外で未実施とし、件数増加時に遅くなる可能性をrisk、次回の計測をfollow-upとして残す。
つまずきやすい点：「今回はやっていません」だけで終える。なぜ省略したか、何が残リスクか、誰がいつ追うかを一緒に書く。
関連語：accepted risk（第23章）、follow-up（第23章）、go / no-go（第23章）
テキスト本文での登場箇所：第23章「Readiness Checklistは六つの見方で作る」

follow-up

読み：フォローアップ／follow-up
一言で言うと：リリース後または次の作業で追う残課題である。
くわしく：follow-upは「あとで見る」という曖昧なメモではなく、owner、期限、次の行動を持つ追跡対象である。go with follow-upを選ぶときは、残したリスクが本当に追われる形になっているかを見る。ownerや期限がないfollow-upは、実務では忘れられやすい。
具体例：大量データ時の絞り込み性能を、サンプル件数を増やして計測する課題としてP1で残す。
つまずきやすい点：「未確認」とだけ書いて、誰がいつ何をするかを書かない。判断の根拠として弱くなる。
関連語：skipped check（第23章）、accepted risk（第23章）、go / no-go（第23章）
テキスト本文での登場箇所：第23章「Follow-up Issuesは追跡可能にする」

go / no-go

読み：ゴーノーゴー／go / no-go
一言で言うと：出してよいか、止めるかを決めるリリース可否のゲート判断である。
くわしく：go / no-goは、意思決定の場で「進める(go)」「止める(no-go)」を明確に選ぶための一般的な言い方である。気分や雰囲気ではなく、証拠、影響、残課題、追跡方法で決める。goは進めてよい、no-goはblockerがあるので今は出さず先に直す、という判断になる。なお本書ではgoとno-goの中間に「go with follow-up」（追跡すべき残課題を明示して進める）という選択肢を置いているが、これは本書独自の整理であり、基本はgoかno-goの可否判断と考えるとよい。
具体例：支援ステータス機能のPRRで、主要フローとsecurity確認が通り、blockerがなければgoにできる。逆に不正statusを保存できるならno-goにする。
つまずきやすい点：判断を後回しにして「だいたい大丈夫」で出すと、根拠が説明できない。何を確認したか、何を受け入れたかを示してから判断する。
関連語：blocker（第23章）、accepted risk（第23章）、Production Readiness Review / PRR（第23章）
テキスト本文での登場箇所：第23章「Release Decisionは証拠とリスクで書く」

decision matrix

読み：ディシジョンマトリクス／decision matrix
一言で言うと：判断に効く項目と状態を表にして、結論への影響を見える化する整理である。
くわしく：PRRのdecision matrixでは、blocker、smoke test、skipped check、accepted riskなどを並べる。目的は点数計算ではなく、判断の根拠を一箇所で見られるようにすること。goにする理由、go with follow-upにする理由、no-goにする理由を、表から説明しやすくなる。
具体例：high severity blockerはなし、smoke testはpass、skipped checkはdocumented、accepted riskはdocumentedなので、go with follow-upと判断する。
つまずきやすい点：表を作っただけで判断を書かない。decision matrixはrelease decisionを支える材料であり、最後は自分の言葉で結論を書く。
関連語：release decision（第23章）、go / no-go（第23章）、accepted risk（第23章）
テキスト本文での登場箇所：第23章「Release Decisionは証拠とリスクで書く」

release decision

読み：リリースディシジョン／release decision
一言で言うと：go、go with follow-up、no-goの結論と根拠を残す文書である。
くわしく：release decisionには、判断、理由、証拠、accepted risk、blocker、follow-up owner and dateを書く。判断マトリクスを使うと、blockerがないこと、smoke testが通ったこと、skipped checkが追跡可能であることを同じ文書で説明しやすい。
具体例：主要フローとsmoke testはpass、blockerなし、大量データ性能はfollow-upとして追うため、go with follow-upと書く。
つまずきやすい点：「大丈夫そう」で終える。判断には、何を確認したか、何を受け入れたか、何を先送りしたかが必要である。
関連語：decision matrix（第23章）、go / no-go（第23章）、accepted risk（第23章）
テキスト本文での登場箇所：第23章「Release Decisionは証拠とリスクで書く」

smoke test

読み：スモークテスト／smoke test
→ 第16章を参照。
本章での補足：本章では、リリース直後に短時間で主要動線が生きているかを見る最小確認として使う。すべてのテストを再実行するのではなく、「出した直後にこれが通らなければまずい」という確認を三つ程度に絞る。支援ステータス機能なら、一覧表示、needs-help絞り込み、新規ログ作成を一つずつ確認できる。
テキスト本文での登場箇所：第23章「Smoke Testは短く主要動線を見る」

runbook

読み：ランブック／runbook
→ 第16章を参照（詳しい定義は第16章に譲る）。
本章での補足：本章では、リリース前、リリース中、リリース後、問題時対応、rollback、cleanupの手順をまとめた手順書として扱う。問題が起きたときに読むものなので、長い背景説明よりも、手順と判断条件を短く書く。支援ステータス機能なら、出す前の確認、出した後のsmoke test、一覧が開かないときの対応、戻し方までを並べておける。
テキスト本文での登場箇所：第23章「Operations Readinessは手順どおり動かせるかを見る」

operations readiness

読み：オペレーションズレディネス／operations readiness
一言で言うと：リリース、確認、戻し、片付けを手順どおり実行できるかを見る観点である。
くわしく：operations readinessでは、runbook、smoke test、問題時対応、rollbackまたはrevert、cleanupを確認する。実装が動いても、問題時に見る場所や戻し方が分からないと安全に出しにくい。研修の小さなアプリでも、do not proceed条件とエスカレーション条件を書くと判断しやすくなる。
具体例：一覧が開かない、既存ログが消えたように見える、不正statusが保存できる、という症状ごとに見る場所と対応を書く。
つまずきやすい点：作業前の背景説明だけを書き、問題時の具体的な手順や片付けがない。
関連語：runbook（第23章）、rollback（第23章）、cleanup（第23章）
テキスト本文での登場箇所：第23章「Operations Readinessは手順どおり動かせるかを見る」

rollback

読み：ロールバック／rollback
→ 第16章を参照。
本章での補足：本章では、release runbookの一部として、問題発生時に前の状態へ戻す方針を用意しておくことを扱う。データ変更がある場合は、戻したときに既存ログが読めることを先に確認する。
テキスト本文での登場箇所：第23章「Operations Readinessは手順どおり動かせるかを見る」

cleanup

読み：クリーンアップ／cleanup
一言で言うと：作業後に不要なデータ、ログ、resource、残タスクを片付けることである。
くわしく：PRRのcleanupでは、一時データやdebug logを消す、follow-up issueを作る、release decisionを更新する、研修用AWS resourceの削除対象と削除確認を記録する。特にクラウド環境では、不要なresourceを残すと費用やセキュリティリスクにつながる。cleanupは作業の最後のおまけではなく、runbookに含める運用手順である。
具体例：動作確認用に作った一時ログを消し、使い終わった研修用AWS resourceの削除担当と削除確認をfollow-upに残す。
つまずきやすい点：動作確認が終わったところで満足し、debug logやクラウドresourceを残したままにする。
関連語：runbook（第23章）、operations readiness（第23章）、follow-up（第23章）
テキスト本文での登場箇所：第23章「Operations Readinessは手順どおり動かせるかを見る」