前回との接続とこの講義の役割
前回のO-09では、依存の更新を安全に運ぶための判断の型を学びました。振り返ると、カテゴリOの道具はどれも、変更を安全に扱うための部品でした。しかし部品が揃っても、それらをどの順番で通すのかが決まっていなければ、事故は防げません。この講義は、O章のすべての道具と、B-06で学んだ開発・検証・本番という3つの環境を、1本のパイプラインに束ねる締めくくりの回です。
このスライドのポイント
- O-09では、依存の更新を安全に運ぶ判断の型を学んだ
- カテゴリOの道具はどれも「変更を安全に扱う」ための部品だった
- 本講義は、それらの道具とB-06の3環境（開発・検証・本番）を1本のパイプラインに束ねる締めくくり
変更フローの定義——本番へ届くまでの6段階
変更フローとは、変更が本番へ届くまでの標準経路のことです。順に、①変更、②レビュー、③自動検査、④プレビュー、⑤承認、⑥本番反映の6段階です。①変更はブランチの上で行います。②レビューはPRで差分を確認する工程です。③自動検査は、テストなどが自動で走る仕組みで、その中身はこの先のカテゴリPやRで扱います。④プレビューは、B-06の開発環境で実物を確かめる段です。⑤承認を経て、⑥本番反映に至ります。狙いは、いきなり本番を仕組みで不可能にすることです。
このスライドのポイント
- 変更フロー＝変更が本番（A-09/B-06）へ届くまでの標準経路
- ①変更（ブランチO-05で）②レビュー（PR=O-08）③自動検査④プレビュー（B-06の開発環境）⑤承認⑥本番反映
- ③自動検査の仕組みはカテゴリP・Rで扱う
- 狙い: 「いきなり本番」を仕組みで不可能にする
なぜ必要か——「動いたから本番へ」を防ぐ
この経路を持たないと、手元で動いたから本番へ直接、という運用が続きます。それはB-06でも予告したとおり、いつか必ず事故につながります。変更フローは、工程を増やして面倒にするためのものではありません。A-09で学んだ、高リスクな変更の前に一度立ち止まるという判断を、仕組みとして自動的に働かせるためのものです。人が毎回気をつける代わりに、経路そのものが立ち止まらせてくれます。
このスライドのポイント
- この経路が無いと「手元で動いたから本番へ直接」の運用が続く
- B-06で予告したとおり、それはいつか必ず事故につながる
- 変更フローは面倒の追加ではなく、A-09の「立ち止まる」判断の自動化
構造——6段階のパイプライン
6段階を、左から右へ流れるパイプラインとして見てみます。ブランチでの変更、PRでのレビュー、自動で走る検査、プレビュー環境での確認、承認、そして本番反映の順です。それぞれの段には、これまで学んだ道具や講義が対応しています。変更はO-05のブランチ、レビューはO-08のPR、プレビューはB-06の開発環境というように、O章とB章の知識が1本の線の上にきれいに並びます。自動検査だけは、この先のカテゴリPとRで扱う、まだ学んでいない段です。
このスライドのポイント
- 6段階を左→右のパイプラインとして見る
- 各段にこれまでの道具・講義が対応: 変更=O-05ブランチ／レビュー=O-08 PR／プレビュー=B-06開発環境
- 自動検査だけは未習の段（カテゴリP・Rで扱う）
処理の流れ——経費アプリの変更を追う
経費アプリの承認ルールを変える場面で追ってみます。まず支線となるブランチを切って変更します。次にPRを出し、差分に依頼外の変更がないかを確認します。するとテストなどの検査が自動で走ります。続いてプレビュー環境で、経理担当が実物の画面を確かめます。問題がなければ承認し、最後に本番へ反映します。ここでは、人間の目による確認と、機械による検査が二重の網になっている点が大切です。片方が見落としても、もう片方が受け止めます。
このスライドのポイント
- 経費アプリの承認ルール変更が本番に届くまでの実況
- 支線で変更→PRでdiff確認→検査が自動で走る→プレビューで経理担当が確認→承認→反映
- 人の目（レビュー）と機械の検査が二重の網になる
技術サンプルカード——変更フローの地図
サンプルは、変更フロー全体を1枚に描いた地図です。6つの段のそれぞれに、対応する講義番号を添えてあります。読み方の要点は3つです。第一に、矢印は左から右への一方向で、後戻りせず本番へ近づくこと。第二に、自動検査の段だけは仕組みをまだ学んでおらず、カテゴリPとRで扱うこと。第三に、この地図は完成形であり、自分のプロジェクトに全部が揃っているとは限らないことです。AIには、今のプロジェクトの変更フローを6段階で説明し、抜けている段を指摘してもらいましょう。
混同しやすい概念——「面倒」か「保険」か
ここで混同しやすいのが、フローを面倒なものと見るか、保険と見るかです。確かに工程は増えます。しかし各段は、事故が起きる確率と、起きたときの被害を、1つずつ減らすためにあります。特に、自分1人で開発する場合でも、自動検査とプレビューの2段は価値が大きい段です。1人だからこそ、見落としを受け止めてくれる網が効きます。面倒の正体は、実は保険料だと考えてください。
バイブコーディングでの確認点——足りない段を1つずつ
実践のこつは、いきなり6段すべてを揃えようとしないことです。まず、自分のプロジェクトに今いくつの段があるかを棚卸しします。そのうえで、足りない段をAIと一緒に、1つずつ足していきます。たとえば、ブランチとPRはあるがプレビューが無い、という状態を見つけたら、次に足すのはそこだと分かります。全部を一度にやる必要はありません。1段ずつ増やすほど、変更は安全になっていきます。AIへの質問例は、「私のプロジェクトに6段のうちどの段がありますか。次に足すべき1段はどれですか」です。
このスライドのポイント
- いきなり6段すべてを揃えようとしない
- まず自分のプロジェクトに今いくつの段があるかを棚卸しする
- 足りない段をAIと一緒に1つずつ足していく
一問一答とまとめ
最後に一問一答です。変更フロー6段階の、最初と最後の段は何でしょうか。（間）答えは、ブランチでの変更に始まり、本番反映で終わる、です。30秒まとめです。変更フローとは、変更・レビュー・自動検査・プレビュー・承認・本番反映という、本番へ安全に届けるための6段階の経路でした。これでカテゴリOは修了です。変更を安全に運ぶ道が通りました。次回からはカテゴリP、この道の途中にあった自動検査、つまり品質を確かめるテストの世界へ進みます。関連資料は「Git・GitHub 完全入門」「AIアプリ公開前チェックリスト100」「Vercel公開 完全手順書」です。
このスライドのポイント
- 一問一答: 変更フロー6段階の、最初と最後の段は？
- 30秒まとめ: 変更フロー＝本番へ安全に届ける6段階の経路
- カテゴリO修了。次回はカテゴリP、品質を確かめるテストへ
- 関連資料: 「Git・GitHub 完全入門」「AIアプリ公開前チェックリスト100」「Vercel公開 完全手順書」
