こんな記事を書いたんだけど、ちょっとワタシ的に連想する話で。
手順書は重要である。ただ、優先度で言えば構成管理のほうがよほど高い、という話を書きたい。
手順書の価値は「スタックトレース」
手順書がなぜ重要かというと、エラーが出たときのスタックトレースになるからだ。コーディングで言えば、例外を仕込むのと同じ行為である。価値は「どこでトラブルが起きたかを追跡できること」、ほぼそこに尽きる。
この定義を採ると、粒度についての整理もつく。よく「粒度なんて大事ではない」と言いたくなるのだが、それは正確ではない。粒度はトレースの解像度そのものなので、粗すぎれば「この30分のどこかで壊れた」としか言えなくなる。解像度は大事だ。
無駄だと思っているのは、粒度ではなく内容の形式ルールのほうである。「Aという手順を必ず含めること」といった決まりごと。ああいうものは、追跡可能性に何も寄与しないのに、レビューのコストだけを増やす。区別すべきはここだ。
- 追跡できる解像度か → 大事
- 決まった項目が並んでいるか → だいたい無駄
そして、手順書がどれだけ整っていても、事故の原因はたいてい構成管理に行き着く。
運転技術と、車の状態
交通ルールを守って注意深く運転するのは当然大事だ。だがそれと同時に、ガソリンの残量やバッテリー、つまり「状態」を意識していないといけない。
体感で言うと、注意していなくて電柱に当たった、という類の事故が4割くらい。こちらは要因も解決法も回収が楽である。残りの6割で、状態のほうから火の粉が上がる。そして回収が難しいのは、圧倒的に後者だ。
（この割合は私の実感であって、統計ではない。ただ、難易度の非対称性のほうは、それなりに普遍性があると思っている。）
手順書と構成管理の性質
| 手順書 | 構成管理 | |
|---|---|---|
| 主な情報 | どう変更するか | 何が存在するか |
| 性質 | 手続き | 事実・状態 |
| 変更時 | 作業方法を示す | 変更前後を記録する |
| 環境差異 | 間接的 | 直接扱える |
| 認知漏れ対策 | △ | ◎ |
| 障害調査 | △ | ◎ |
両者は代替関係にない。手順書は「経路」を、構成管理は「状態」を扱う。経路をいくら丁寧に書いても、状態は分からない。
では、構成管理はどこで崩れるのか
私も長らくよく分からなかったが、だいたい次のパターンに収まるらしい、と思うようになった。
1. 導入時期の違い
A環境：2025年4月に Tool A v1.2 を導入
B環境：2025年9月に Tool A v1.5 を導入
「同じTool Aだから同じもの」と認識されるが、実際にはバージョンが違う。さらに厄介なのは、B環境の導入時にA環境の担当者が関与していないことだ。誰も差が生まれた瞬間に立ち会っていない。
2. 案件単位で構成が決め打ちされる
「○○案件で必要なのでA環境にTool Aを入れる」という意思決定がある。その後、別案件で「△△案件でもTool Aが必要なのでB環境に入れる」という話が降ってくる。
このとき、Tool Aがシステム全体の構成要素ではなく、案件の成果物として扱われている。結果、こうなる。
案件X
└─ A環境
└─ Tool A v1.2
案件Y
└─ B環境
└─ Tool A v1.5
これが一番根が深いと思っている。あとで詳しく書く。
3. 個別設定が後から変更される
初期導入時は同じでも、
A環境：設定X = ON
B環境：設定X = OFF
と、何かのニーズですり替わる。そして、なぜAだけONなのかは記録されない。
私が震えた話としては、協働している別部署の人が並行で作業していて、その都合で設定が入れ替わっていた、というのがある。構成管理の問題であると同時に、意思疎通の問題でもある。
変更はどこから入ってくるのか
これが一番怖いところだ。構成を変える変更は、本来の変更管理を通らずに入ってくる。
- 障害対応
- セキュリティ対応
- ベンダー指示
- 他案件対応
- 緊急対応
- 手作業の暫定対応
つまり、正規のリリースルートを通らない。しかもこれらは受動的に入る。オーダーがあって、「“あの席"にハンバーガーを持ってきてね」と言われるから、「はい分かりました」と部分的に対応する。
こういう変更は些細なので、内部変更として扱われる。簡単な記録程度の手続きは経るが、正規のリリースではない。そしてこういうときほど、なぜか承認は浅い。
特に警戒すべきはこのあたりだと思っている。
- 他部署からの依頼
- 障害対応
- 作業トラブルの後始末（そして後始末をしない）
ただし、「承認を厚くする」は失敗する
ここで「もっと統制を強めるべきだ」と言いたくなる。実際、以前の私はそう考えていた。だがこれは筋が悪い。
理由は簡単で、横並びにしようとすると承認の壁があり、工期が5倍6倍に伸びるからだ。だからみんなやらない。入口の承認を重くすれば、人は正規ルートを迂回する。障害対応でルート外の変更が入るのは、承認が甘いからではなく、急いでいるからである。急いでいる人を承認で止めることはできない。
だから方向を変えたほうがいい。止めるのではなく、事後で捕まえる。変更してよいことにする代わりに、翌日には差分として検出される状態を作る。予防（prevention）ではなく検知（detection）に寄せる、という考え方だ。承認プロセスを軽く保ったまま、把握漏れだけを潰すのが、最も要領のいい方法なのだろう。
変更履歴は地雷である
ここからが本題かもしれない。
こういう現場において、極めて危険な主張がある。
「過去のログに残った変更を、最初から順番に適用すれば、現在の構成になるはず」
これは幻想である。この主張は、暗黙にこれだけの前提を置いている。
- ログが完全である（記録されない手作業が一つもない）
- 変更が非可換な場合、順序が正しく残っている
- 適用が冪等である
- 途中で失敗した変更の残骸が残っていない
- 環境の外側（OSパッチ、ベンダー側の変更）が動いていない
現場でこの5つが同時に成立することは、まずない。だからリプレイは原理的に破綻する。再現不能なものを再現しようとしている。
「履歴」と「あるべき姿」は別物である
私がここから学んだのは、変更履歴と構成定義はまったく別のものだ、ということだった。
これは歴史である。
2026/04/01 Tool A v1.2 を A環境に導入
2026/06/01 Tool A v1.5 を B環境に導入
2026/07/01 A環境の Tool A を v1.4 へ更新
一方、本当に必要なのはこちらだ。
環境X
Tool A v1.4
Tool B v3.2
Plugin C 有効
設定D 30
設定E 無効
「イマのありのままのすがた」である。ここに歴史は関係ない。
必要なのは、次の転換だ。
「リリースを正しく積み上げれば現在の状態になる」という発想から、 「現在あるべき状態を明示的に定義し、変更履歴はそこへ至る経路として扱う」という発想へ。
ちなみに、この考え方には既に業界の語彙がある。宣言的構成管理（desired state configuration）、構成ドリフト（configuration drift）、ドリフト検知、CMDB、GitOps あたりだ。本来は、既存の枠組みを借りたほうが早いと思う。
なぜこの幻想を打ち破れないのか
以前の私は「手順書主義だからだ」と考えていた。新規に手順書を作るのが面倒だから、既存の手順書を再利用しようとし、結果としてログを遡る発想になる、と。
だが今は、手順書は結果であって原因ではないと思っている。真犯人は二つある。
一つは、構成に対する所有者がいないこと。 前述のパターン2がそれだ。案件単位で構成が決まるということは、誰も「これが標準である」と決める権限を持っていない、ということである。あるべき姿を定義する主体が存在しないのだから、あるべき姿は定義されない。
もう一つは、差分の正当性を誰も判断できないこと。 設定XがなぜA環境だけONなのか、知っている人がもういない。意図的なのか事故なのか分からない。だから怖くて揃えられない。「何かできない事情があるのだろう」と感じるとき、その事情の正体はたいていこれだと思う。技術の問題ではなく、判断材料が失われている問題である。
どこから手をつけるか
順序としては、私自身こう考えている。まあ、実務だと権力ないから口出しするナ、になりがちだが。
1. 現状を機械的に吐かせる
これが技術的に可能なら、非常に良いだろう。
あるべき姿を定義する前に、今の姿が要る。人が台帳に書くのをやめて、各環境から構成情報を定期取得してスナップショットを取る。フォーマットは前述の「環境X」の形でいい。
2. 環境間の差分を定期実行する
これは効くだろう。パターン1（導入時期の違い）とパターン3（設定のすり替え）は、差分を取った瞬間にほぼ全部出る。別部署が並行で作業していた件も、次のスナップショットで検出される。
3. 差分ゼロを目標にしない
目標は「差分に理由がついている」状態である。全部を横並びにしようとするから工期が5倍6倍になるのであって、まず「差分が許されない項目」だけを決めて、そこだけ厳格にすればいい。残りはラベルを貼って放置してよい。
そして、この「理由をラベリングしていく」作業こそが、失われた判断材料を回復していく作業でもある。
4. 構成の所有者を、案件から環境へ移す
案件は「環境に対する変更要求を出す立場」に降格させ、成果物としてツールだとかパッケージだとかを持たせない。これは組織の話なので一番重いが、やらない限りパターン2は再発し続けることはやはり注意が必要と言えそうである。
5. 手順書側は一点だけ直す
各ステップに「完了後にこの状態になっているはず」という事後状態を書き添える。これだけで手順書が構成管理に接続され、実行結果とスナップショットを突き合わせられるようになる。粒度のルールを整備するより、はるかに費用対効果が高い。
手順書は経路を記述し、構成管理は状態を記述する。事故のほとんどは状態のほうから来るのだが、どうしても経路ばかり整備になってしまう。こういったのは、どうにかならんものかというのは非常に難しい問題である。