Rui Software戻せない変更は、安全にできない：可逆性の設計【第5回】
この記事を読み終えると、変更を可逆（戻せる）な形に分解する5つの技術を使い分けられ、戻せない操作を識別して段取りを設計でき、「戻し方を試したことがあるか」という基準でリリースを判断できるようになります。ジュニアエンジニア向け 成果の出し方シリーズ（全12回）の第5回です。
🎯 テーマの主役：「可逆性」
今回の主役は可逆性（reversibility）です。一言で言えば、可逆性とは「元に戻せる性質」であり、変更の安全さを決める最大の要因です。慎重さではありません。戻せるかどうかです。
日常の例えで言うなら、扉です。世の中には押せば戻れる扉（両開きの扉）と、入ったら戻れない扉（一方通行の扉）があります。両開きの扉は、入ってみて違ったら戻ればよい。だから迷ったら入ってみるのが正解です。一方通行の扉は、入る前に確認しなければなりません。中を見てから戻る、という選択肢がないからです。そして重要なのは、この2つを同じ速さで通ってはいけないということです。
ソフトウェアの変更も同じ構造です。コードの変更は、たいてい戻せます。デプロイを巻き戻せば元に戻ります。しかしデータの削除、外部への送信、公開したAPI、締結した契約は戻せません。そして、戻せない変更の代表例であるデータ削除は、戻せる変更と同じ手順で承認されがちです。これが事故の構造です。
この記事の仮説はこうです。変更の安全性は「どれだけ確認したか」ではなく「どれだけ戻せる形にしたか」で決まる。したがって安全な開発とは、検証を増やす努力ではなく、可逆性を設計する努力である。もしこれが正しければ、あなたの仕事の進め方は「確認を増やす」から「戻せる形に分ける」へ変わります。そしてこれは、リリースを遅くするどころか、速くします。戻せると分かっていれば、出す判断が速くなるからです。
なお第4回で扱った影響分析は「危険を知る」技術でした。今回の第5回は「危険を小さくする」技術です。両方揃って初めて、安全な変更ができます。
動機：「戻し方が分からない」まま、戻す必要が来る
リリース前の確認で、ジュニアエンジニアが最も詰まる質問があります。「で、まずいときはどう戻すの？」です。
この質問に対して「もう一度デプロイすれば戻ります」と答えて、実際に戻せなかったという経験は、多くの人が持っています。理由はいくつもあります。デプロイは戻せても、データベースの変更は戻せない。戻しても、外部に送った通知は取り消せない。古いバージョンに戻したら、新しい形式で保存されたデータが読めない。
ここで重要なのは、戻し方は「後で考える」ものではないということです。戻し方は設計の一部であり、設計した時点で決まっているものです。第2回で「障害対応の速さは事前の準備で決まる」と書きました。戻し方も同じです。戻せない設計で出したものは、障害時に戻せません。
この記事のゴールは、あなたが「戻し方」を設計に含めて出せるようになることです。
🔍 検証①：決定には2種類ある
まず、意思決定の種類を分けます。この区別を持っていると、判断の速さと安全を両立できます。
両方向の扉（Two-way door）は、後で戻せる決定です。開けてみて、違ったら戻る。だから速く決めてよい。むしろ、速く決めることが正解です。迷う時間がもったいないからです。
一方通行の扉（One-way door）は、後で戻せない決定です。だからゆっくり決める。情報を集め、関係者を巻き込み、記録を残します。
この区別は、Amazonの株主向け書簡で広く知られるようになった考え方です。重要なのは、この2つを混同すると両方失敗することです。両方向の扉に時間をかけすぎると遅くなり、一方通行の扉を速く通ると取り返しがつきません。
| 種類 | 例 | 決め方 | 誤った扱いをすると |
|---|---|---|---|
| 両方向の扉 | コードの内部構造・UI文言・設定値・フラグ | 速く決めて、出して、直す | 検討に時間をかけすぎて遅くなる |
| 一方通行の扉 | データ削除・公開API・契約・外部への一斉送信 | 確認・合意・記録を作る | 取り返しのつかない事故になる |
| 境界（判断が要る） | データ形式の変更・権限変更・移行 | 可逆な形に分けてから出す | 戻せない前提で進めてしまう |
そして、あなたの仕事の多くは「境界」にあります。データ形式の変更は、工夫すれば可逆にできます。権限変更も、段階的に適用すれば可逆にできます。可逆性を設計するとは、一方通行の扉を、両方向の扉に作り替える作業です。これが、この記事で身につける技術です。
🔍 検証②：戻せないものは何か
次に、戻せないものを具体的に列挙します。識別できないものは設計できません。
第一に、外部に伝わったものです。メール、通知、公開されたAPI、Webhook、印刷物、対外的な告知。一度伝わった情報は、取り消せません。第二に、消えたデータです。削除、上書き、マイグレーションでの変換。第三に、時間です。締切、有効期限、定期処理の実行時刻。一度過ぎた締切は戻りません。第四に、他者の判断です。利用者が契約を結んだ、別チームがあなたのAPIに依存した、外部が前提にしてしまった。第五に、お金と権利です。決済、請求、与信、契約。
| 戻せないもの | なぜ戻せないか | 可逆に近づける工夫 |
|---|---|---|
| 外部への送信 | 相手の手元に届いた情報は消せない | 送信前の確認・遅延送信・少数先行・取り消し可能時間 |
| 削除したデータ | 物理的に消えると復元できない | 論理削除（印を付けるだけ）・一定期間の退避・削除の前段階 |
| 公開したAPI・仕様 | 外部が依存すると変更できない | 旧形式を併存させる・段階的な非推奨告知 |
| データ形式の変換 | 変換後に古いコードが読めなくなる | 旧形式と新形式を併存させる（拡張→移行→縮小） |
| 過ぎた時間・期限 | 物理的に巻き戻せない | 実行を遅らせられる設計・実行前の停止手段 |
| 決済・契約・権利 | 法的・金銭的な実体が動く | 承認を分ける・少額先行・取り消し期間の設定 |
注目してほしいのは、右の列に「工夫」があることです。戻せないものを、完全に可逆にはできません。しかし「戻しやすく」はできます。送信なら遅らせる、削除なら印を付けるだけにする、形式変更なら併存させる。完全な可逆ではなく、被害を小さくする方向に寄せる——これが現実的な可逆性の設計です。
🔍 検証③：コードは戻せるが、データは戻りにくい
次に、この非対称性を理解します。可逆性の難しさは、ほぼこの1点に集約されます。
コードは戻せます。デプロイは前のバージョンに戻せます。設定も戻せます。だからコードの変更は両方向の扉です。ところがデータは戻りにくい。理由は3つあります。第一に、新しい形式で書かれたデータを、古いコードが読めない。第二に、上書きされたデータの元の値が失われる。第三に、削除されたデータは戻らない。
ここから重要な設計原則が導かれます。コードとデータの変更を、同時に出してはいけない。コードを先に出して、データは新旧両方の形式に対応できる状態で動かす。そしてデータの移行が完了してから、古い形式の対応を外す。この3段階の進め方は拡張→移行→縮小と呼ばれ、データを壊さずに形式を変える標準的な手順です。
この3段階の価値は、戻りにくい部分（③縮小）を最後に分離できることです。①②の段階ではいつでも止められます。だからリスクの高い部分だけを、最後に・小さく・ゆっくり実行できます。可逆性の設計とは、不可逆な部分を最後に小さく切り出す作業だと言ってもよいくらいです。
🔍 検証④：戻せる形にする5つの技術
次に、具体的な技術を並べます。この5つを持っていれば、ほとんどの変更を可逆にできます。
①フィーチャーフラグ：コードは出しておいて、機能のオン・オフを設定で切り替える技術です。「出した」と「有効にした」を分離できます。問題が起きたらフラグを切るだけで止血できます（第2回の「止める」が即座に使える）。ただし、不要になったフラグを消す習慣がないと、フラグが増えて誰も把握できなくなります。
②段階的リリース：影響を一部に限定して出す技術です。社内だけ、1%だけ、特定の地域だけ、特定の利用者だけ。カナリアリリースと呼ばれる手法では、少数に先に出して観測してから全体に広げます。影響範囲を「分析」でなく「設計」で狭める手段です。
③拡張→移行→縮小：検証③で扱ったデータ形式の変更手順です。
④二重化と切り替え：新旧の両方に書き、読み出しだけを切り替える技術です。読み出しを新に切り替えて問題が出れば、旧に戻すだけで復旧します。両方に書くので、戻してもデータが失われません。
⑤遅延実行と取り消し可能時間：送信・確定・実行をすぐにやらない技術です。送信前に一定時間置く、下書き状態を挟む、実行前なら誰でも止められる設計にする。不可逆な操作に、可逆な入口を作る発想です。
| 技術 | 何を分離するか | 止血がどう速くなるか | コスト |
|---|---|---|---|
| フィーチャーフラグ | 「配布」と「有効化」 | フラグを切るだけで止まる | 不要なフラグの管理 |
| 段階的リリース | 「一部」と「全部」 | 影響が一部に限定される | リリース手順が増える |
| 拡張→移行→縮小 | 「コード」と「データ」 | ①②の段階で止められる | 一時的に複雑になる |
| 二重化と切り替え | 「書き込み」と「読み出し」 | 読み出しを戻すだけで復旧 | 一時的に2倍の書き込み |
| 遅延実行・下書き | 「決定」と「実行」 | 実行前に止められる | 手順と待ち時間が増える |
そして重要なのは、これらの技術は「ゆっくりする技術」ではないことです。フィーチャーフラグを切るのは、デプロイを巻き戻すより速い。1%に出すのは、全社に出すより速く決められる。可逆性は、リリースを遅くするのではなく、判断を速くします。戻せると分かっているから、迷わず出せるのです。第1回で「成果は提供の後にしか発生しない」と書きました。提供を速くする技術は、成果を早く生みます。
🔍 検証⑤：戻し方は、試すまで存在しない
最後に、最も見落とされる事実です。戻し方は、試したことがある人だけが使えます。
ここで知っておくべき事例があります。ある有名な事故では、データベースの復旧が必要になったとき、用意されていた5つのバックアップ手段のうち4つが機能せず、復旧に長時間を要しました。バックアップは取られていました。しかし戻せませんでした。原因は復元手順が試されていなかったことです。
| 「用意している」状態 | 「使える」状態 | 差を埋める行動 |
|---|---|---|
| バックアップを取っている | 復元できる | 定期的に復元を試す |
| 戻す手順が書いてある | 手順どおりに戻せる | 訓練で1回実行する |
| フラグを実装した | フラグで止まる | 本番で1回切ってみる |
| 旧バージョンが残っている | 旧に戻せる | 実際に戻して、また出してみる |
戻し方を試すという発想は、平時には無駄に見えます。動いているものをわざわざ戻すのですから。しかしこれが最も費用対効果の高い訓練です。第2回で「戻すを1回経験しておくと手が震えない」と書いたのは、この理由です。
そして、戻し方を試すと、設計の穴が見つかります。「戻すとフラグの状態が不整合になる」「戻すとキューに古いメッセージが残る」「戻すと戻す処理そのものが失敗する」。これらは机上では絶対に見つかりません。試すことでしか見つかりません。戻し方の訓練は、リスクの発見手段でもあるのです。
結果：可逆性チェックリスト
変更を出す前に、次の項目を確認します。
【変更の分類】
□ この変更は、両方向の扉か、一方通行の扉か
□ 一方通行なら、なぜ可逆にできないのか（回避策を検討したか）
【分離できているか】
□ 「配布」と「有効化」を分けられるか（フィーチャーフラグ）
□ 「一部」と「全部」を分けられるか（段階的リリース）
□ 「コード」と「データ」を分けられるか（拡張→移行→縮小）
□ 「書き込み」と「読み出し」を分けられるか（二重化と切り替え）
□ 「決定」と「実行」を分けられるか（遅延実行・下書き）
【止血の即応性】
□ 問題が起きたとき、何秒で止められるか
□ 止める権限は誰が持っているか
□ 止める操作は、落ちているシステムに依存していないか（第2回）
【戻し方の実在性】
□ 戻し方を、実際に試したことがあるか
□ 戻したときに不整合が起きないか
□ データを戻す必要がある場合、復元を試したことがあるか
【不可逆な操作】
□ 削除・送信・公開は、十分に遅らせて実行しているか
□ 取り消し可能な期間や、下書きの状態を挟んでいるか
□ 記録（誰が・いつ・何を）が残るか
このチェックリストで最も重要なのは、最後の「不可逆な操作」です。可逆にできないものは、遅らせる・小さくする・記録するの3つで守ります。遅らせる（実行を待つ）、小さくする（少数先行）、記録する（取り返しがつかなくなったときに、経緯を辿れるようにする）。
考察：可逆性は、勇気の代わりになる
ここまでを踏まえて、1つ踏み込んだ話をします。可逆性は、技術の話である以上に、心理の話です。
人は戻せないと思うと、動けなくなります。そして動けないと、変化が起きません。承認に時間がかかり、検討が長引き、その間に状況が変わります。逆に戻せると分かっていると、人は大胆に動けます。「まず出して、違ったら直そう」と言える。可逆性は、組織の意思決定速度を上げる装置です。
これはジュニアエンジニアにとって重要な意味を持ちます。あなたが変更を可逆な形に分解して提案すると、上長の判断が速くなります。「この変更は、フラグで切り替えられる形にしました。問題があれば30秒で止められます。そして戻し方は試してあります」——この説明は、承認を速くします。可逆性は、あなたの提案を通す技術でもあるのです。第8回で扱う提案の前提条件が、この可逆性です。
もう1つの考察は、可逆性にはコストがかかるということです。フラグの管理、両対応の期間、段階的リリースの手順。これらは複雑さを増やします。だからすべての変更を可逆にする必要はありません。影響の広さに応じて、可逆性の水準を選ぶのが正解です。内部の小さな変更は、そのまま出して戻せばよい。全利用者に届く変更は、可逆な形に分解する。この強弱の付け方が、実務のセンスです。そして強弱の判断根拠は、第4回の影響分析にあります。
📌 注目ポイント
核心は4点です。第一に、決定には「戻せる両方向の扉」と「戻せない一方通行の扉」があり、扱いを分けること。第二に、コードは戻せるがデータは戻りにくいという非対称性を理解し、コードとデータを同時に変えないこと。第三に、可逆性は5つの技術（フラグ・段階・拡張縮小・二重化・遅延）で作れること。第四に、戻し方は試すまで存在しないこと。
特に第二点は、実務で最も事故を生む部分です。「コードを戻したのに壊れ続ける」という現象は、ほぼこの非対称性から来ます。データが新形式で書かれた後、古いコードはそれを読めません。だから拡張→移行→縮小の順序が必要になります。
💡 活用事例：バックアップは「取っている」だけでは意味がない
可逆性の最も分かりやすい事例は、バックアップです。取っていることと戻せることは違います。
ある年の事故では、本番データベースが誤って削除されました。用意されていた復元手段は5つありました。しかし実際に試すと、4つが機能しませんでした。残る1つも想定よりはるかに時間がかかることが判明し、復旧には18時間を要しました。バックアップは毎日取られていたにもかかわらず、です。
| 用意していたもの | 実際に起きたこと | 不足していたもの |
|---|---|---|
| 5つのバックアップ手段 | 4つが機能しなかった | 復元の定期的な試行 |
| 復元手順の文書 | 手順の前提が古くなっていた | 手順の実行による検証 |
| 監視とアラート | 削除は検知できた | 検知後の止血手段（戻せなかった） |
この事例が教えるのは、可逆性は「用意」ではなく「実証」で測るということです。「バックアップを取っています」ではなく「先月、復元を試しました」と言えることが、本当の可逆性です。そしてこの発想は、あなた個人の仕事にも適用できます。「戻し方を書きました」ではなく「戻して、また出しました」。この一言が言える人は、チームからの信頼が変わります。
✅ 要点まとめ
- 可逆性が変更の安全さを決める。慎重さではない
- 決定は両方向の扉（速く決める）と一方通行の扉（慎重に決める）に分ける
- コードは戻せるがデータは戻りにくい。だから同時に変えない
- 拡張→移行→縮小で、戻りにくい部分（縮小）を最後に分離する
- 可逆性を作る技術は5つ：フラグ・段階・拡張縮小・二重化・遅延実行
- 戻し方は試すまで存在しない。訓練が最も費用対効果の高い安全策
- 不可逆な操作は遅らせる・小さくする・記録するの3つで守る
- 可逆性はリリースを遅くしない。むしろ判断を速くする
🚀 取り込み方：明日から使う3段階
今日（5分でできること）：次に出す変更を1つ選び、「これは両方向の扉か、一方通行の扉か」を判定してください。一方通行だと分かったら、「どうすれば両方向にできるか」を1つだけ考えます。削除なら論理削除にする、送信なら下書きを挟む、形式変更なら併存させる。1つ思いつくだけで、その変更は安全になります。
今週（小さく試す）：戻し方を1回試してください。小さなリリースを出し、戻して、また出します。フラグがあるなら、本番で切って、また入れてみます。この1回で、机上では見つからない穴が1つは見つかります（状態の不整合、キャッシュの残り、キューの中身）。見つけた穴を記録しておくと、次回の設計が変わります。
今月（業務に組み込む）：チームに「可逆性チェックリスト」（結果の節）を提案します。あわせて、「止める権限」と「止める手順」を1枚にまとめる作業を提案します。第2回でも同じ提案をしましたが、今回は「設計段階で可逆にする」という入口側の対策です。止血の準備（第2回）と可逆性の設計（第5回）は、車の両輪です。どちらか片方だけでは、事故は減りません。
🔥 ハマりポイント：可逆性で外す3つの型
その1：「デプロイを戻せば大丈夫」と思いがちだが、実はデータは戻らない
症状は、コードを戻したのに症状が消えず、むしろ悪化する。原因は新形式で書かれたデータを、古いコードが読めないことです。対処は、コードとデータを同時に変えないことです。先に両対応のコードを出し、データの移行が終わってから古い対応を外す。この順序を守るだけで、「戻したのに壊れる」のほとんどが消えます。第4回の時間方向の影響を、設計で解決するのがこの技術です。
その2：「戻し方は手順書に書いてある」と思いがちだが、実は書いてあるだけでは使えない
症状は、いざというときに手順の前提が古くて使えない。原因は手順を実行して検証していないことです。対処は、訓練で1回実行することです。そして手順に「最終確認日」を書きます。「最終確認2026-09-12」。この日付が古くなったら、手順は疑うべきです。第2回で書いた「手順は試したことがある人だけが使える」を、日付で管理するわけです。
その3：「フラグを立てれば安全」と思いがちだが、実はフラグが負債になる
症状は、フラグが50個になり、どれが有効か誰も把握できない。原因はフラグの削除を計画に含めていないことです。対処は、フラグに「作成日」と「削除予定」をセットで持たせることです。フラグは「一時的な借金」であり、返済（削除）まで含めて1つの仕事です。フラグを立てるPRと同じPRに、削除予定日を書くだけで、負債化をかなり防げます。これは第4回の「削除の難しさ」と同じ問題です。
🔄 代替アプローチとの比較：リリース戦略の選択
可逆性を高める方法は複数あり、組み合わせて使います。どれが優れているかではなく、変更の性質で選ぶものです。
| 戦略 | 仕組み | 向いているケース | 弱い点 |
|---|---|---|---|
| 一括デプロイ | 全台を一度に更新 | 影響が狭い・検証が済んでいる | 問題が出ると全体に波及 |
| ローリング | 台数を分けて順に更新 | ステートレスなサーバー | 新旧混在時の互換性が必要 |
| Blue-Green | 新旧2環境を用意して切り替える | 即座に戻したい | 環境コストが2倍 |
| カナリア | 一部の利用者に先に出す | 影響の予測が難しい | 少数では気づけない不具合もある |
| フィーチャーフラグ | 配布と有効化を分ける | 機能単位で止めたい | フラグの管理負荷 |
| ダークローンチ | 新経路を動かすが結果は使わない | 性能・正しさを本番で比較したい | 実装の二重化が必要 |
カナリアが向かないケースも正直に書きます。少数の利用者でしか起きない不具合は、カナリアでは検出できません。たとえば特定のデータを持つ1社だけで起きる問題は、1%に配っても9割の確率で見逃します。この場合はカナリアではなく、影響の分析（第4回）と、止める手段（第2回）で守ります。すべてのリスクを1つの手法で解こうとしないこと。複数の手法を重ねて、リスクごとに担当させるのが設計です。
📅 今後の展望：可逆性は「ソフトウェアの前提」になりつつある
可逆性を高める道具は、この10年で標準装備に近づきました。フィーチャーフラグは専用のサービスとして提供され、段階的リリースはプラットフォームの機能になり、デプロイツールは自動で切り戻すようになりました。可逆性は、個人の工夫から、環境の機能へ移っています。
この流れで、エンジニアに求められる役割が変わります。フラグを実装することは環境がやってくれます。しかし「どの単位で切れるようにするか」「どこまで併存させるか」「何を不可逆と見なすか」は、設計する人の判断です。つまり、可逆性の設計は、自動化が進むほど価値が上がります。
もう1つの流れは、データの可逆性への関心の高まりです。論理削除（消さずに印を付ける）、変更履歴の保持、イベントの追記型保存。これらは「戻せるデータ設計」として広がっています。削除の代わりに記録を残すという発想は、監査・法規制・問い合わせ対応の面でも必要とされています。「消す」から「記録する」へ——これは、データを扱うすべてのエンジニアに関わる変化です。そして可逆性の設計ができる人は、この変化の中心にいます。
まとめ
この記事では、変更を戻せる形にする技術を扱いました。可逆性が安全さを決めます。決定は両方向の扉と一方通行の扉に分け、コードとデータを同時に変えず、拡張→移行→縮小の順で進めます。可逆性を作る技術は5つ（フラグ・段階・拡張縮小・二重化・遅延実行）で、戻し方は試すまで存在しません。
これを読んだあなたは、変更を可逆な形に分解して提案し、戻し方を試してからリリースできるようになりました。ここまでの第1回から第5回で、「状況を掴む」と「安全に変える」の技術が揃いました。次の第6回からは、人を動かす技術に入ります。最初は進捗と悪い知らせの伝え方です。遅れは「発覚」より「申告」が安い——それが次のテーマです。
参考文献
- Jeff Bezos「2015 Letter to Shareholders」（Amazon, 2016年公開） — 一方通行の扉と両方向の扉（Type 1 / Type 2 decisions）の原典。 https://www.aboutamazon.com/
- Martin Fowler「ParallelChange」（2014） — 拡張→移行→縮小というデータ変更手順の解説。 https://martinfowler.com/
- Pete Hodgson「Feature Toggles (aka Feature Flags)」（martinfowler.com, 2017） — フラグの分類と管理の指針。 https://martinfowler.com/
- Jez Humble & David Farley『Continuous Delivery』（2010） — Blue-Greenデプロイと自動化されたリリース。 https://continuousdelivery.com/
- Google『Site Reliability Engineering』 — カナリアリリースと段階的展開。 https://sre.google/
- Google『The Site Reliability Workbook』第16章 Canarying Releases — 段階的リリースの実務手順。 https://sre.google/
- GitLab 公式ポストモーテム（2017年1月31日のデータベース障害） — バックアップが機能しなかった経緯の一次説明。 https://about.gitlab.com/
- NIST SP 800-34『Contingency Planning Guide for Federal Information Systems』 — 復旧計画と訓練の要件。 https://csrc.nist.gov/
- ISO/IEC 27001／27002 — 情報セキュリティ管理におけるバックアップと復旧の要件。 https://www.iso.org/
- The Twelve-Factor App「V. Build, release, run」 — ビルド・リリース・実行の分離。 https://12factor.net/
- Michael Nygard『Release It!』（第2版, 2018） — サーキットブレーカーと、壊れても被害を広げない設計。
- Michael Feathers『Working Effectively with Legacy Code』（2004） — 振る舞いを変えずに安全に変更する技術。
- David D. Woods『Resilience Engineering』 — 可逆性と回復力の考え方。
- Nicole Forsgren, Jez Humble, Gene Kim『Accelerate』（2018） — デプロイ頻度と変更失敗率の関係。 https://dora.dev/
- IPA『安全なウェブサイトの作り方』 — 変更時の事故を避ける実務的指針。 https://www.ipa.go.jp/
- 金融庁『金融機関のITガバナンスに関する対話の状況』等の報告 — 大規模更改における段階移行の重要性。 https://www.fsa.go.jp/