Rui Software「手元では動く」を卒業する：CI/CDとリリースの設計【第7回】
「手元では動くのに、本番では動かない」。この言葉が何度も出るなら、問題はコードではなく環境・手順・状態のばらつきです。この記事を読み終えると、自動化（CI/CD）が何を守っているのかを説明でき、戻せるリリースを設計できるようになります。ジュニアエンジニア向け開発フロー入門シリーズ（全8回）の第7回です。
🎯 テーマの主役：「自動化されたリリース」——再現できる手順
今回の主役はCI/CD（継続的インテグレーション／継続的デリバリー）とリリースです。一言で言えば、CI/CDとは「変更を本番に届けるまでの手順を、毎回同じ結果になるように自動化した流れ」です。
日常の例えで言うなら、工場の検品ラインです。手作りの工房では、職人が1つずつ確認して出荷します。職人が優秀なら品質は高いですが、同じ品質を毎日何百個も出すことはできません。疲れている日は抜けが出ます。工場のラインでは、決められた検査を必ず全ての製品が通ります。職人の注意力に頼らず、仕組みが品質を保証します。CI/CDは、ソフトウェアの検品ラインです。
もう1つの大事な性質は、手順そのものが記録になることです。「どうやって本番に出したか」が自動化された手順として残っていれば、誰でも、いつでも、同じ手順を実行できます。手作業のデプロイは「あの人にしかできない」状態になりやすく、その人が休むと出せなくなります。
第6回までで、変更は「レビューされ、テストされた」状態になりました。今回の第7回は関門7の「リリース」です。第1回の出口条件は「戻す手順がある」でした。この記事では、戻せる出し方を含めて設計します。
この関門を通せるようになると、次の4つができるようになります。第一に、「手元では動く」の原因を3つに切り分けられること。第二に、自動で確認すべき項目を列挙できること。第三に、リリースの戦略（一括・段階的・切り替え型）を選べること。第四に、戻し方を先に決めてから出すことです。
動機：リリースが「特別な行事」になっていないか
リリースについて、次のような状態に心当たりはないでしょうか。リリースは月に1回の大きな行事で、関係者が集まり、夜遅くまで作業する。手順書はあるが、最新かどうか誰も確信がない。作業中に「あれ、次は何だっけ」という会話が飛び交う。終わった後は打ち上げのような達成感があり、翌日は「今回は何事もなく終わった」と安堵する。
この状態は、一見「丁寧にやっている」ように見えます。しかし構造としては、リリースが特別な行事になっている時点で、リスクが最大化しています。理由は3つです。①手順が記録ではなく記憶に依存している（抜けが起きる）、②変更が溜まっている（問題の切り分けが困難）、③頻度が低いので手順に慣れていない（毎回が本番勝負）。
第2回から第6回までで、私たちは変更を小さく、レビュー可能に、テスト可能にしてきました。しかしリリースが手作業の行事のままだと、小さく作った意味が最後の工程で失われます。100の小さな変更を溜めて1回で出すと、問題が起きたときに100のうちどれが原因か分かりません。
この記事の仮説はこうです。リリースの安全性は、確認の厳しさではなく「1回に出す量の小ささ」と「戻せることが事前に決まっていること」で決まる。もしこれが正しければ、リリースの設計は頻度を上げ、1回の量を減らし、戻し方を自動化する方向に向かいます。
🔍 検証①：「手元では動く」が壊れる3つの理由
まず、「手元では動くのに本番では動かない」という現象の正体を分解します。原因は、3つのばらつきに分類できます。
① 環境のばらつき：手元の言語のバージョン、ライブラリのバージョン、OS、設定ファイルの値、外部サービスの接続先。手元では動くが本番では動かない、の最頻出の原因です。特に依存ライブラリのバージョンは、手元と本番で違うと同じコードでも違う動作になります。
② 手順のばらつき：手作業のデプロイは、毎回わずかに違います。手順の順番、実行し忘れ、手元のファイルの状態、環境変数の設定し忘れ。人は疲労・割り込み・時間帯の影響を受けます。第1回で見たWHOのチェックリストの話を思い出してください。手順の確認は、人の注意力に依存させないことが本質でした。
③ 状態のばらつき：データベースの中身、キャッシュ、他の変更との関係。手元のデータは空に近く、本番のデータは数年分あります。本番のデータ量と分布でしか発生しない問題は、手元では永遠に再現しません。
| ばらつき | 具体例 | 自動化でどう対処するか |
|---|---|---|
| 環境 | ライブラリのバージョン違い、設定値の違い | 依存を固定して記録する。設定を環境ごとに管理する。コンテナで環境ごと再現する |
| 手順 | 実行し忘れ、順番の違い、手作業の抜け | 手順を自動化し、コードとして残す。検査を通らないと出荷できないようにする |
| 状態 | データ量、既存データの分布、他機能との干渉 | 本番に近いデータで確認する。小さく出して本番で観測する（カナリア） |
この3つは、「丁寧にやる」では解決しません。丁寧さは人の注意力に依存するからです。解決するのは、ばらつきを構造的に減らす仕組みです。環境は固定し、手順は自動化し、状態の違いは小さく観測する。これがCI/CDの目的です。
🔍 検証②：CI（継続的インテグレーション）——変更のたびに自動で確認する
CI（継続的インテグレーション）は、変更を本流に統合するたびに、自動で確認を走らせる仕組みです。ポイントは「たびに」です。月に1回まとめて確認するのではなく、変更のたびに小さく確認します。
CIで自動化する項目は、次のように整理できます。重要なのは、安い確認を先に、高い確認を後に並べることです。ビルドが通らないコードにテストを実行しても意味がないので、早く失敗するものを先に置きます。
| 順番 | 自動で確認する内容 | 検知できる問題 | 実行時間の目安 |
|---|---|---|---|
| 1 | 依存の取得とビルド | 壊れたコード。依存の欠落 | 数十秒〜数分 |
| 2 | 静的解析・型検査・整形チェック | 書き方の規則違反。型の不整合（第3回の境界） | 数十秒 |
| 3 | 単体テスト | ロジックの誤り（第6回の土台） | 数秒〜数分 |
| 4 | 結合テスト | モジュール間の食い違い（マーズ探査機の事例） | 数分 |
| 5 | 依存ライブラリの脆弱性検査 | 既知の脆弱性を含む依存 | 数十秒〜数分 |
| 6 | E2Eテスト（少数） | 利用者の操作の流れの破壊 | 数分〜数十分 |
CIの効果は「バグを減らす」だけではありません。レビュアーの負担を減らします。第5回で見たように、レビューは人間が判断すべきことに集中するのが理想です。「ビルドが通るか」「テストが通るか」は機械が確認し、人間は設計と意図を見る——この分担を作るのがCIです。また、「手元では動く」の環境ばらつきも、CI上で動かすことで検出できます。CIは多くの場合、本番に近いクリーンな環境で実行されるからです。
🔍 検証③：デプロイの戦略——一度に全部を出さない
CD は、文脈によって2つの意味で使われます。継続的デリバリー（いつでも本番に出せる状態を保つ）と、継続的デプロイ（自動で本番まで出す）です。どちらの場合も、「どう出すか」の戦略に選択肢があります。ここがリリース設計の中心です。
| 戦略 | やり方 | 問題が起きたとき | 向いている場面 |
|---|---|---|---|
| 一括（ビッグバン） | 全サーバーを一度に切り替える | 全利用者に影響。切り戻しの時間が長い | 小規模・影響範囲が限られる場合 |
| ローリング | サーバーを少しずつ新バージョンに置き換える | 影響が一部に限定される | 複数サーバーがある標準的な構成 |
| Blue-Green | 旧環境と新環境を並べ、切り替えで一気に移す | 切り替えを戻せば即復旧 | 戻す速さを最優先する場合 |
| カナリア | 一部の利用者だけ新バージョンに振り分ける | 影響を最小に観測できる | 本番で小さく確かめたい場合 |
| フィーチャーフラグ | コードは出しておき、機能のON/OFFを設定で切り替える | 設定を切れば機能を止められる | 機能単位で出したい場合。デプロイとリリースを分離できる |
特に重要なのがフィーチャーフラグです。これは「コードを本番に置くこと（デプロイ）」と「利用者に使わせること（リリース）」を分離します。完成前にコードを出しておき、安全なタイミングで機能をONにできます。ただし、フラグが増えすぎるとどの組み合わせで動いているか分からなくなるので、役目を終えたフラグは削除する運用が必須です。
これらの戦略に共通する考え方は、「一度に全部を出さない」ことです。理由は検証①で見た「状態のばらつき」です。本番でしか出ない問題は、出してみるまで分かりません。ならば、影響を小さくした状態で出して、観測してから広げるのが合理的です。第1回のコスト原則（早く見つけるほど安い）の、リリース版です。
🔍 検証④：戻せるリリース——「戻し方」を先に決める
リリース設計で最も重要な項目は、戻し方です。第1回の関門7の出口条件は「戻す手順がある」でした。ここでは、戻し方の選択肢を整理します。
| 戻し方 | やり方 | 速さ | 注意点 |
|---|---|---|---|
| ロールバック | 前のバージョンに戻す | 速い（数分） | データベースの変更が含まれると戻せない場合がある |
| 打ち消し（revert） | 問題の変更を打ち消す変更を出す（第4回） | やや遅い | 原因の変更を特定できている必要がある |
| フィーチャーフラグを切る | 機能をOFFにする | 最速（設定変更のみ） | フラグが用意されている機能に限る |
| 前進修正（fix forward） | 問題を直した修正をすぐ出す | 内容による | 原因が明確で、修正が小さい場合のみ |
最も戻しにくいのは、データベースの変更です。コードは前のバージョンに戻せますが、消した列や変換したデータは戻せません。これに対処するのが後方互換な変更の原則です。たとえば列名を変える場合、次の3段階に分けます。①新しい列を追加して両方に書く → ②古い列を読まなくなる → ③古い列を削除する。各段階は独立して出せて、どの段階でも戻せます。「1回のリリースで完結させようとしない」のがコツです。これは第3回で見た「変えにくいもの（データの形）」を、時間方向に分割して安全にする技術です。
戻し方を先に決めるとは、具体的には次のことを決めておくことです。誰が判断するか（障害の規模によって変わる）、何をもって戻すと決めるか（誤りの増加率、対応時間の見込み）、戻す手順をどこに書いておくか（手順書、ランブック）。判断と手順を事前に決めておけば、障害の最中に議論する必要がありません。障害対応では、判断に迷う時間が最も高くつきます（第8回で詳しく扱います）。
🔍 検証⑤：出してよいかの判定とバージョン
リリースの判定は、自動チェックと人の判断の組み合わせです。自動で見るのは「壊れていないか」（検証②のCI）、人が判断するのは「いま出してよいか」です。後者には、影響範囲（誰がどう変わるか）、タイミング（利用者が少ない時間帯か、他チームのリリースと衝突しないか）、準備（サポートへの連絡、手順書の更新）が含まれます。
出した変更の記録として、バージョン番号とリリースノートがあります。バージョン番号の慣習として広く使われているのがセマンティックバージョニング（意味のあるバージョン番号）です。
| 番号の位置 | 上げる条件 | 例 | 利用者への意味 |
|---|---|---|---|
| メジャー（1.0.0 → 2.0.0） | 互換性が壊れる変更 | APIの項目削除、設定の廃止 | 「対応が必要かもしれない」 |
| マイナー（1.0.0 → 1.1.0） | 互換性を保った機能追加 | 新しいAPIの追加 | 「安全に更新できる」 |
| パッチ（1.0.0 → 1.0.1） | 互換性を保った不具合修正 | 計算の誤り修正 | 「そのまま更新してよい」 |
リリースノートは「何が変わったか」を利用者とサポートの言葉で書きます。第4回で見たConventional Commitsのような形式でコミットを書いておくと、リリースノートの自動生成が可能になります。「何が変わったか」の記録は、問い合わせ対応の生命線です。「先週から動きが変わった」という連絡に対して、リリースの履歴を見れば原因の候補が分かる状態を作ります。
🔍 検証⑥：頻度と安定性はトレードオフではない
「リリースの頻度を上げると、障害が増えるのでは」という懸念は自然です。しかし、DORA（DevOps Research and Assessment）の一連の調査が示したのは逆の結果でした。デプロイ頻度が高い組織ほど、変更失敗率が低く、障害からの復旧も速い傾向が報告されています。
なぜ逆になるのか。理由は本記事で見てきたとおりです。頻度が高い＝1回の変更が小さい。変更が小さければ、問題の切り分けが容易で、戻すのも速い。さらに、手順に慣れているので、リリース作業そのもののミスが減ります。逆に、月1回の大きなリリースは、変更が溜まり・切り分けが難しく・手順に不慣れという三重の不利を抱えます。
| 観点 | 大きなリリース（低頻度） | 小さなリリース（高頻度） |
|---|---|---|
| 1回の変更量 | 多い | 少ない |
| 問題の切り分け | 候補が多く困難 | 候補が少なく容易 |
| 戻す範囲 | 広い（多くの変更を巻き戻す） | 狭い（直前の小さな変更） |
| 手順の習熟 | 低い（月1回） | 高い（毎日） |
| 利用者への影響 | まとめて大きく変わる | 小さく継続的に変わる |
| 障害時の心理的負担 | 「全部やり直し」になりやすい | 「1つ戻すだけ」で済む |
結果：変更が本番に届くまでの標準的な流れ
ここまでの内容を、1つの流れとしてまとめます。第4回から第8回までが、この流れのどこに対応するかを意識しながら読んでください。
| # | 段階 | 自動で行うこと | 人が行うこと |
|---|---|---|---|
| 1 | 変更を作る | — | 設計・実装・コミット（第3回・第4回） |
| 2 | CI | ビルド・静的解析・テスト・脆弱性検査 | 失敗の修正。結果の確認 |
| 3 | レビュー | — | 設計と意図の確認（第5回） |
| 4 | ステージング確認 | テスト環境へのデプロイ | 本番に近い環境での動作確認 |
| 5 | リリース判定 | チェック結果の集約 | タイミング・影響範囲の判断（本文検証⑤） |
| 6 | 本番へ出す | 戦略に沿ったデプロイ（ローリング等） | 監視の確認。異常時の判断 |
| 7 | 観測 | エラー率・応答時間の監視 | 問題時の切り戻し判断（第8回） |
考察：自動化の目的は「速さ」ではなく「再現性」である
ここからは、検証では扱いきれなかった解釈を述べます。CI/CDの文脈では「速くなる」ことが強調されますが、自動化の本質は速さではなく再現性だと私は考えます。手作業は速いこともあります（慣れた人が1回やるなら）。しかし同じ結果を保証できません。自動化は毎回まったく同じ手順を実行します。
この性質は、学習の面で大きな意味を持ちます。手作業のデプロイでは、失敗の原因が「手順のどこか」に埋もれます。自動化された手順では、失敗した箇所がログに残ります。「今回は成功したが何が違ったのか分からない」が、「この手順のここで失敗した」に変わります。失敗が記録されるから、改善できます。これは第4回の履歴、第6回のテストと同じ構造です。
もう1つ、リリースの心理的な変化も重要です。リリースが手作業の大行事だと、リリースが怖くなります。怖いと、まとめて出そうとし、まとめるとさらに怖くなります（検証⑥の悪循環）。自動化された小さなリリースでは、「今日も出した」が日常になります。第1回で見た「関門の重さは戻しにくさに比例させる」は、リリースでは「戻せるなら、頻繁に出してよい」という形になります。
AI時代の視点を加えます。AIがコードを生成する速度が上がると、変更の量が増えます。このとき、リリースが手作業だとボトルネックはリリース工程に移り、溜まった変更がリスクになります。逆に、CI/CDが整っていれば、AIが増やした変更を安全に流せます。第7回までの各回で扱った「小さく・レビュー可能に・テスト可能に」は、変更量が増える時代の前提条件になっていくと考えられます。
📌 注目ポイント
- 「手元では動く」の原因は環境・手順・状態の3つのばらつき。丁寧さでは解決しない
- CIは変更のたびに自動で確認する仕組み。安い確認を先に並べ、早く失敗させる
- 機械が確認できること（ビルド・型・テスト）は機械に任せ、人間は設計と意図に集中する
- デプロイ戦略は一度に全部を出さない方向に選ぶ（ローリング・Blue-Green・カナリア）
- フィーチャーフラグでデプロイとリリースを分離できる。役目を終えたフラグは削除する
- 戻し方を先に決める。戻し方の最速手段が「フラグを切る」になるよう準備する
- データベースの変更は後方互換な3段階に分ける。1回で完結させない
- バージョンはセマンティックバージョニングで意味を持たせる。リリースノートは利用者の言葉で
- 頻度と安定はトレードオフではない。1回の量を減らすと両方が改善する
💡 活用事例：1日10回から、11.6秒に1回へ
リリースの常識がどう変わったかを示す、対照的な2つの事例があります。
1つ目は、Flickr（写真共有サービス）の2009年の発表です。当時、Flickrのエンジニアたちは「1日に10回以上のデプロイ」を実践していると報告しました（”10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”）。それまで、多くの組織では月1回や四半期に1回のリリースが普通でしたから、1日10回は当時としては極端な数字でした。この発表で強調されたのは、技術だけでなく文化です。開発チームと運用チームが同じ目標を持ち、自動化と監視で協力すること。この発表は、のちに「DevOps」と呼ばれる流れの原点の1つとして広く参照されています。
2つ目は、Amazonの2011年の講演です（Velocity 2011でのJon Jenkins氏の発表）。Amazonは当時、平均11.6秒に1回のペースで本番環境にデプロイしていたと報告されました。これは「1日10回」からさらに3桁上の数字です。しかも、デプロイの大半は開発者自身が実行し、専用のリリース担当者が介在しない運用でした（いわゆる「あなたが作ったものを、あなたが出す」という考え方です）。これを可能にしたのは、CI/CDの自動化、小さな変更、監視、そして戻せる仕組みです。
この2つの事例の間にあるのは、技術の進歩だけではありません。「リリースは特別な行事」という前提を捨て、「リリースは日常の作業」として設計し直したことが本質です。そしてその前提が変わったからこそ、自動化の投資が回収できました。あなたのチームが月1回のリリースをしているなら、いきなり11.6秒を目指す必要はありません。まず週1回にし、CIで自動確認を回し、戻し方を決める。順番に進めれば、頻度は自然に上がります。
✅ 要点まとめ
- 「手元では動く」は環境・手順・状態のばらつき。仕組みで減らす
- CIは変更のたびに自動確認する。安い確認から順に並べ、早く失敗させる
- 自動化は人の注意力への依存を外す。WHOチェックリストと同じ思想（第1回）
- デプロイは一度に全部出さない。カナリアやフラグで影響を小さく観測する
- デプロイとリリースを分ける（フィーチャーフラグ）。不要になったフラグは消す
- 戻し方を出す前に決める。最速はフラグ、次に切り戻し、最後に打ち消し
- データベースは後方互換な3段階で変更する。戻せる単位に分ける
- バージョンとリリースノートは利用者との約束の記録。自動生成できる形にする
- 頻度を上げるほど安定する。小さな変更は切り分けと復旧が速い
🚀 取り込み方：明日から使う3段階
今日（5分でできること）：自分のプロジェクトで「本番に出す手順」を書き出してみてください。頭の中にある手順を、箇条書きで構いません。書き出した中から、自動化できそうな1つ（テストの実行、整形の確認など）に印を付けます。書き出すだけで、手順が人に依存している度合いが見えます。
今週（小さく試す）：リポジトリにCIの設定を1つ追加してください。「テストを自動で実行する」だけで十分です（GitHub Actions、GitLab CI、CircleCIなど、ホスティングサービスの標準機能で始められます）。あわせて、戻し方を1つ書きます。「問題が出たら、まず◯◯を切る／前のバージョンに戻す手順は△△」というメモをリポジトリに置きます。
今月（定着させる）：次のリリースで、1回の量を減らすか、頻度を上げることを試してください。たとえば、まとめて出していた機能を2回に分ける、リリースの間隔を半分にする。難しければ、フィーチャーフラグの導入を提案するのも有効です（コードを出してから機能をONにする）。あわせて、リリースのたびにかかった時間と手作業の回数を記録すると、自動化の効果が数字で見えます。
🔥 ハマりポイント
その1：自動化は大企業のものだと思う
CI/CDと聞くと、大規模な仕組みを想像しますが、始めの一歩は「テストを自動で実行する」だけです。数十行の設定ファイルで始められ、手作業の確認が1つ減るだけでも価値があります。逆に、最初から完璧なパイプラインを作ろうとすると、設定の維持が負担になり、誰も触らなくなります。小さく始めて、痛みのある箇所から自動化します。
症状：自動化の計画が大きすぎて着手できない。原因：完成形から逆算している。対処：「いま手作業で最も面倒な1つ」から始める。
その2：手動デプロイのほうが「丁寧」だと思う
手作業には「毎回確認できる」という安心感があります。しかし実際には、手作業は毎回わずかに違い、抜けが起きます。自動化された手順は毎回まったく同じで、確認項目も必ず全部実行されます。丁寧さの正体は「注意力」ではなく「確認項目が全て実行されること」です。
症状：手動リリースで毎回小さな手順ミスが起きる。原因：注意力に依存している。対処：手順を書き出し、自動化できる順に移す。
その3：戻し方を考えずに出す
「今回は大丈夫」という前提でリリースすると、問題が出たときに慌てます。問題が起きてから「どう戻すか」を考えると、判断に時間がかかり、被害が拡大します。第1回の原則（失敗は後ろで見つけるほど高い）が、最も強く効くのがリリースです。出す前に戻し方を決め、書いておく。これだけで障害対応の初動が数分変わります。
症状：障害時に「どうしよう」から会議が始まる。原因：戻し方が事前に決まっていない。対処：戻し方の判断基準（誰が・何をもって）と手順を事前に書き、リポジトリに置く。
その4：リリースノートを書かない
「社内のツールだから」とリリースノートを省略すると、「先週から動きが変わった」という問い合わせに対して、何が変わったかを調べる調査が発生します。「どのリリースで変わったか」「意図は何だったか」が記録されていれば、調査は数分です。リリースノートは自分たちの未来のための記録です（第4回のコミットメッセージと同じ構造です）。
症状：問い合わせのたびに履歴を手作業で追う。原因：リリースの記録がない。対処：コミットメッセージの形式を整え、リリースノートを自動生成する。
🔄 代替技術との比較：リリースの自動化レベル
自動化には段階があります。自チームがどの段階にいて、次にどこへ進むかを判断する材料として読んでください。
| レベル | 状態 | 特徴 | 次に進むためにやること |
|---|---|---|---|
| 0 | 完全手作業 | 手順は人の記憶。属人的 | 手順を書き出して共有する |
| 1 | 手順書がある | 属人性は下がるが、実行は手作業 | 確認（テスト）の自動実行を始める |
| 2 | CIがある | 変更のたびにテストが走る | ビルドとデプロイの自動化 |
| 3 | デリバリー自動化 | いつでも出せる。リリース判断は人が行う | 監視と戻し方の整備。カナリア導入 |
| 4 | デプロイ自動化 | 本番まで自動。小さく頻繁に出せる | 観測の高度化（第8回）。フラグ運用 |
補足として、サプライチェーンの完全性という観点が近年重要になっています。「ビルドしたもの」と「出荷したもの」が同じであることを検証できるようにする取り組み（SLSA、SBOM、ビルドの署名など）が標準化しつつあります。これは、依存ライブラリ経由の攻撃が現実の脅威になったことへの対応です。自動化されたパイプラインは、この検証の基盤にもなります。手作業のビルドでは「何が入ったか」を保証できないからです。
また、環境の再現にも選択肢があります。コンテナ（Dockerなど）で環境ごと固定する、仮想マシンのイメージで固定する、設定管理ツールで構成をコード化する。いずれも目的は同じで、「手元と本番の環境のばらつきを減らす」ことです。第3回の「環境も1つの設計対象」という見方が、リリースの安全性に直結します。
📅 今後の展望：プラットフォームと供給網の時代
リリースを巡る変化を3つ挙げます。第一に、プラットフォームエンジニアリングです。CI/CD・監視・環境構築を、各チームが個別に作るのではなく、社内の共通プラットフォームとして提供する動きが広がっています（ThoughtworksのTechnology Radarなどで継続的に注目されています）。開発者はリリースの手順そのものを学ぶ負担が減り、プロダクトの設計に時間を使えます。ただし、プラットフォームがブラックボックス化すると、問題時の対応が難しくなるという副作用もあります。中で何が起きているかを知る力は引き続き必要です。
第二に、ソフトウェア供給網のセキュリティです。ビルド環境そのものが攻撃対象になりうるため、ビルドの再現性・完全性の検証が標準化しつつあります。SLSA（Supply-chain Levels for Software Artifacts）のような枠組みでは、ビルドがどの程度検証可能かがレベルとして定義されています。「どう作られたか」を説明できることが、セキュリティと監査の両面で求められるようになっています。
第三に、AIの活用です。デプロイの異常検知、リリースノートの自動生成、障害予測といった領域でAIの活用が進んでいます。ただし、リリースの判断（出してよいか、戻すか）の最終責任は人間にあります。AIは判断材料を速く集める役割を担い、判断そのものは第2回から第7回までで見てきた基準（受け入れ条件・設計・テスト・戻し方）に基づいて人間が行う——この分担が、当面の現実的な形になると考えられます。
まとめ
この記事を読んだあなたは、次にリリースするとき、「戻し方は何か」を先に確認するようになります。そして、「手元では動く」と言いたくなったとき、環境・手順・状態のどこが違うのかを切り分けられるようになります。
リリースは、開発の成果を世に出す瞬間です。だからこそ、気合いと根性で臨む行事ではなく、日常の作業として設計します。小さく出し、自動で確認し、戻せるようにしておく。この3つがそろえば、リリースは怖い行事ではなく、普通の一日の仕事になります。
最終回の第8回では、関門8の「運用と障害対応」を掘ります。出した後、システムは静かに動き続けます。その静けさの中で異常に気づく仕組みをどう作るか、そして壊れたときの最初の10分に何をするかを扱います。
参考文献
- Jez Humble, David Farley, “Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation”, Addison-Wesley, 2010 — https://continuousdelivery.com/
- Jez Humble, “Continuous Delivery vs Continuous Deployment”（CDの2つの意味） — https://continuousdelivery.com/2010/08/continuous-delivery-vs-continuous-deployment/
- Nicole Forsgren, Jez Humble, Gene Kim, “Accelerate: The Science of Lean Software and DevOps”, IT Revolution Press, 2018 — https://itrevolution.com/
- DORA, “Accelerate State of DevOps Report” — https://dora.dev/
- John Allspaw, Paul Hammond, “10+ Deploys Per Day: Dev and Ops Cooperation at Flickr”, Velocity 2009 — https://www.slideshare.net/jallspaw/10-deploys-per-day-dev-and-ops-cooperation-at-flickr
- Jon Jenkins, “Velocity Culture”, Velocity 2011（Amazonのデプロイ頻度に関する講演） — https://www.youtube.com/watch?v=dxk8b9rSKOo
- Martin Fowler, “BlueGreenDeployment” — https://martinfowler.com/bliki/BlueGreenDeployment.html
- Martin Fowler, “CanaryRelease” — https://martinfowler.com/bliki/CanaryRelease.html
- Pete Hodgson, Martin Fowler, “Feature Toggles (aka Feature Flags)” — https://martinfowler.com/articles/feature-toggles.html
- Semantic Versioning, “Semantic Versioning 2.0.0” — https://semver.org/lang/ja/
- Keep a Changelog, “Keep a Changelog 1.1.0”（変更履歴の形式） — https://keepachangelog.com/ja/1.1.0/
- Google, “Site Reliability Engineering”（Release Engineering の章） — https://sre.google/sre-book/release-engineering/
- SLSA, “Supply-chain Levels for Software Artifacts”（ビルドの完全性） — https://slsa.dev/
- NIST, “Secure Software Development Framework (SSDF) SP 800-218” — https://csrc.nist.gov/pubs/sp/800/218/final
- Thoughtworks, “Technology Radar”（プラットフォームエンジニアリングの動向） — https://www.thoughtworks.com/radar
- 情報処理推進機構（IPA）, 「ソフトウェア開発データ白書」 — https://www.ipa.go.jp/