「すぐやっておきます」で片付いた設定変更が、経理の喜んだその日に、工場の出荷を止めた。3人の言い分は、全部本当だった。
インシデントの原因＝problem、分析は済んだが、まだ解決していない問題＝known error、直るまでの間に影響を減らす手＝workaround。止まってから戻すのがsupport（物差しは戻す速さ）、日々動かすのがoperate（物差しは合意したサービスレベル）。めざす結果に欠かせない前提＝CSF、それを確かめる数字＝metric。
変更の大きさは、作業の量では測れません。
止まるものの大きさで測ります。
設定を1か所変えるだけの作業でも、止まるものが工場の出荷なら、それは大きな変更です。この当たり前のことが、個人チャットで頼まれて、個人チャットで引き受けられると、どうしても見えなくなる。この回は、その見えなくなり方の話です。
6月の月初、ベンダーのSEが精算システムのサーバーの設定を1か所変えました。前回、インフラ担当が突き止めた「接続が積み上がって固まる」問題の対策です。接続を早めに切るように、待ち時間の設定値を短くした。
効果はすぐに出ました。その月の締めで、精算システムは一度も固まらなかった。経理部長から、短いメッセージが届きました。「今月は、メモ帳を使わずに済んだそうです」
同じ日、第二工場から窓口に連絡が入りました。出荷ラベルが、全ラインで印刷できない。ラインの終わりでは、貼るものを待つ箱が積み上がり始めていました。
原因が分かるまでに、2時間かかりました。出荷ラベルのシステムは、精算システムと同じサーバーの上で動いていたのです。ラベルの印刷は、時間のかかる処理です。ふだんなら、短くなった待ち時間にも収まる。ところが締めの日は、同じサーバーに8つの営業所の入力が押し寄せ、印刷が待ち時間の途中で切られていた。
しかも、誰が、いつ、何を変えたのかが、どこにも記録されていませんでした。インフラ担当が設定ファイルの更新日時に気づき、課長に聞いてようやく分かった。頼んだのも、引き受けたのも、個人チャットでした。
リーダーは、3人から別々に話を聞きました。
「うちはずっと『止めるな、変えるな』と言ってきた。変えるなら、せめて前の日に言ってほしかった」
「ラベルが出ないと、冷凍の唐揚げが出荷場に積まれていく。あそこは冷凍庫じゃない。時間がたてば品温が上がって、基準を超えた分は全部捨てるしかない。……2時間止まって、どれだけ捨てたか。情シスの人は知らないだろう」
見えていたもの：止まった現場と、捨てる箱の数「頼まれたとおりにやりました。設定値を1か所、変えただけです。テスト用の環境は契約に入っていないので、本番で直接やるしかありません。工場のシステムが同じサーバーに載っているなんて、聞いていませんでした。そこは、うちの契約の外なので」
見えていたもの：契約の範囲と、頼まれた1行「経理の件を、早く片付けたかった。6年前のことがあるから、月末にまた止まるのだけは避けたかったんです。設定1か所と聞いて、正直、誰かに相談するほどのことじゃないと思いました」
見えていたもの：経理の月末と、6年前の記憶工場長は現場を、SEは契約を、課長は経理の月末を、それぞれまじめに見ていた。見ていなかったのは、この変更が通る道の全体です。精算の設定を変えると、同じサーバーの上で何が揺れるのか。それを確かめる役目が、誰にもなかった。
そして、全体が見えなかった理由のひとつが、また個人チャットです。課長とSEの二人の間で始まって、二人の間で終わった。二人の外にいる工場長には、知らせが届く経路そのものがありませんでした。「その設定、何に基づいて変えたの？」と後から聞かれても、答えは「チャットで頼まれたので」になる。第1話と同じ形です。
3人の言い分は、どれも本当でした。工場長とベンダーのSE、それにラベルが止まった出荷場。席を順にめくると、子は別々のものを怖がっています。
子は人ではなく、席につく。言葉がきつくなるのは、うしろの子が何かを怖がっているとき。6体の紹介は地図に
「変えるなら、せめて前の日に言ってほしかった」
怖いのは自分の知らないところで、ラインにつながるものが変わること
「テスト用の環境は契約に入っていないので、本番で直接やるしかなかったんです」
怖いのは確かめる場所がないまま、本番でぶっつけになること
「出荷の日だけは、やめてください。今日じゃない」
怖いのはいちばん止めてはいけない日に、変更が入ってくること
せきのこ ── 席のうしろの、小さな子たち
新しく作ったものや、変えたものを、実際に使われている場所に持ち込むまでには、ふつう段階があります。ITIL 5は、製品とサービスの一生を8つの活動に分けていて、そのうち2つがここに関係します。
ひとつは構築（build）。部品を作って、確かめる活動です。成功の物差しは、仕様どおりに作られ、テストで確かめられたか。もうひとつが移行（transition）。変更を本番に移す活動で、成功の物差しは本番に持ち込んだエラーの数と、事業への影響です。
移行の物差しで今回を測ると、こうなります。本番に持ち込んだエラーは1件。事業への影響は、第二工場の出荷が2時間止まり、品温が基準を超えた製品を廃棄したこと。経理の問題は解けたのに、移行としては失敗でした。
付け加えると、戻すのは簡単でした。原因が分かってから、設定を元の値に戻すまで5分。戻し方が先に決まっていて、誰が何を変えたかが分かっていれば、2時間は10分で済んだはずです。
設定を戻すと決めたとき、インフラ担当はこう言いました。「戻せば、精算はまた月末に固まります。既知のエラーに逆戻りです。でも、回避策の再起動はもう3人でできる。工場を止めておくよりはいい」
どちらも8つのライフサイクル活動の一部。buildは、部品を作って確かめること。成功は仕様どおりに作られ、テストで確かめられたかで測る。transitionは、変更を本番に移すこと。成功は本番に持ち込んだエラーの数と、事業への影響で測る。
今回は、設定値を決めたところで構築を終え、確かめないまま移行した。持ち込んだエラーは1件、影響は出荷の2時間停止と廃棄。
工場長と話したあと、リーダーは会社の中期計画を読み返しました。表紙に「DX推進」と書いてある。
本社の会議では「変えろ」と言われる。工場では「変えるな」と言われる。情シスは、そのあいだに立っています。
ITILは、組織の「変える」と「変えない」を、3つの言葉で呼び分けています。
工場長の「変えるな」は、通常業務（BAU）を守るための、筋の通った防御です。冷凍食品の工場では、ラインが2時間止まれば製品を捨てることになる。変えたせいで止まった経験があれば、変えないのがいちばん安全だと考えるのは当然です。
でも、何も変えなければ、精算は毎月固まり続ける。中期計画の変革（transformation）も、一歩も進みません。
だから解くべきなのは、「変えるか、変えないか」ではない。止めずに変えるには、どうすればいいかです。その答えが、さっきの「本番に入るまでに通るはずだった道」、つまり構築と移行をきちんと通すことでした。
changeは、製品・サービス・仕事のやり方などを変えること（少しずつ積み重ねる）。transformationは、組織の動き方そのものを根本から変えること。BAUは、確立した業務をいつもどおり回している状態。
精算サーバーの設定値は変更。中期計画のDXは変革。工場の毎日の出荷は通常業務。変革は、通常業務を止めずに、変更を積み重ねて進むしかない。
リーダーは、第1話と第2話で作ったものを、変更にも当てはめました。変更の依頼も、チームの共通窓口を通す。そして1枚のカードに書く。
カードを見た工場長は、「戻し方」の欄で目を止め、しばらく黙ってから、こう言ったそうです。「止まっても5分で戻ると分かっているなら、話は別だ」。工場長が嫌がっていたのは、変更そのものではなかった。何が起きるか分からない変更を、知らないうちに入れられることでした。
SEも、カードには協力的でした。ただ、検証用の環境は今の契約に入っていません。今回は特別に用意してもらいましたが、続けるなら契約を見直す必要がある。この話は、夏にもう一度出てきます。
やり直しの変更がうまくいったあと、SEが提案してきました。「毎回、人の手で設定を変えるから、ミスが出るんですよ。確かめが済んだら、本番まで自動で入るようにしませんか。速いですし」
工場長は首を振りました。「自動で勝手に入るのは困る」
ここで、ITILが区別している2つの言葉が役に立ちます。継続的デリバリー（continuous delivery）は、いつでも本番に出せる状態を保っておき、本番に出すかどうかは人が判断して決めるやり方。継続的デプロイメント（continuous deployment）は、本番への反映まで自動で行うやり方です。
速く変えたいSEと、止めたくない工場長。どちらか一方を選ぶ必要はありませんでした。止まったときの痛みが小さいところは自動で速く、痛みが大きいところは、出せる状態まで自動にして、最後の一歩だけ人が決める。
continuous deliveryは、いつでも本番に出せる状態を保つこと。本番に出すかは判断して決める。continuous deploymentは、本番への反映まで自動で行うこと。
工場のラベルに関わるものは、出せる状態にしておき、出す日は工場長と決める（デリバリー）。精算の画面の小さな直しは、確かめが通れば自動で出す（デプロイメント）。
「止めるな、変えるな」と言っていた工場長が、変更カードの「戻し方」の欄でしばらく手を止めました。3体の子に置かれたしくみは、どれも、変更が本番に入るまでの道の上にあります。
怖がっていたこと自分の知らないところで、ラインにつながるものが変わること
急ぐ変更でも、評価と許可は省かない。急ぐために後回しにできるのは、書類のほうです。事前に許可した手順でできるものは、毎回の承認を待たない。
怖がっていたこと確かめる場所がないまま、本番でぶっつけになること
怖がっていたこといちばん止めてはいけない日に、変更が入ってくること
変える前に知らせる、確かめてから移す、移す日を選ぶ。3つは別々のしくみですが、1本の道の上に並んでいます。どれか1つが欠けると、その場所の子がまた怖がりはじめます。
番号と分類はITIL 4の並べ方です。ITIL 5の試験で押さえるのは「プラクティス＝資源のまとまり」と2つのグループまで。
せきのこ ── 席のうしろの、小さな子たち
「ありがとうございます！」。SEの「対応しました」に、課長はそう返していました。6年前に責められ続けた人の、感嘆符です。月末にまた止まることを何より恐れてきたから、いちばん速い手を選んだ。SEは契約どおりに誠実に動き、工場長は現場を守るために「変えるな」と言い続けてきた。
3人がそれぞれの持ち場で手を尽くして、それでも工場は止まった。足りなかったのは、3人の正しさをつなぐ道のほうです。
| 構築build | ライフサイクル活動の1つ。部品を作って確かめる。成功は、仕様どおりに作られ、テストで確かめられたかで測る |
| 移行transition | ライフサイクル活動の1つ。変更を本番に移す。成功は、本番に持ち込んだエラーの数と、事業への影響で測る |
| 変更change | 製品・サービス・仕事のやり方などを変えること。少しずつ積み重ねる |
| 変革transformation | 組織の動き方そのものを根本から変えること |
| 通常業務business as usual（BAU） | 確立した業務をいつもどおり回している状態 |
| 継続的デリバリーcontinuous delivery | いつでも本番に出せる状態を保つ。出すかは判断して決める |
| 継続的デプロイメントcontinuous deployment | 本番への反映まで自動で行う |
もっと詳しく：ITIL 5 解説ガイド（8つの活動と成功の測り方／構築とリリースの言葉／変更・変革・BAU）
Q1. ベンダーのSEが設定を1か所変え、精算システムは月末に固まらなくなった。ところが同じ日、同じサーバーで動く出荷ラベルが2時間止まった。ライフサイクル活動「移行」の物差しで、この変更をどう評価するか。
B。移行（transition）の成功は、本番に持ち込んだエラーの数と、事業への影響で測ります。Cの戻す速さはサポート（support）の物差し、Dの「仕様どおりか」は構築（build）の物差しです。変更を評価して許可する仕事は、ITIL 4では change enablement（変更実現。初期の呼び名は change control）というプラクティスで扱っていました。
Q2. この話には、本社の中期計画の「DX推進」、精算サーバーの設定値を1か所変えること、工場が毎日ラベルを印刷して出荷すること、の3つが出てくる。この順に名前を当てた組み合わせとして正しいものはどれか。
A。組織の動き方そのものを根本から変えるのが変革（transformation）、少しずつ変えるのが変更（change）、確立した業務をいつもどおり回している状態が通常業務（business as usual、BAU）です。工場長の「変えるな」は通常業務を守る話で、変革は通常業務を止めずに、変更を積み重ねて進むことになります。