名人が休んだ月、同じ障害が起きた。直せる人は、どこにもいなかった。
計画外の中断や品質の低下＝incident。あらかじめ合意された通常の依頼＝service request（合意がなければ、まだサービス要求になれていない）。戻すのがsupport、届け続けるのがdeliver。作り直す前に現場で見て測る＝start where you are。
直すのが速い人がいる職場ほど、
同じ障害が、何度でも起きます。
誰かの怠慢の話ではありません。速く直せば直すほど、なぜ止まったのかを考える理由が消えていく。そういう仕組みの話です。
5月の締めの最終日、インフラ担当は休みでした。半年前から決まっていた研修です。
その日、精算システムが遅くなりました。画面が固まり、経理の担当者たちはいつものようにメモ帳から貼り直す。今回は、いつまでたっても戻らない。受話器を置くたびに、ヘルプデスクの電話がまた鳴りました。
ヘルプデスク担当が、インフラ担当の個人チャットに送りました。「精算が固まってます。窓口にはインシデントで起票しました。どうすればいいですか」
研修の休み時間に、返事が来ました。「サーバー再起動すれば戻るよ」
ところが、そのサーバーの管理画面に入れる人が、ほかにいませんでした。ログイン画面を開いても、パスワードの欄でカーソルが点滅するだけ。打ち込む文字は研修に出ている一人の頭の中にしかなく、手順もどこにも書いていない。結局、研修が終わるのを待って、インフラ担当が自宅から入って再起動しました。経理の画面が戻ったのは、固まってから3時間後でした。
いつもなら15分で終わる話です。名人がいれば15分。いなければ3時間。この差が、名人という人の値打ちであり、同時にこのチームの弱点の大きさでもあります。
次の日、リーダーはインフラ担当に頼みました。「精算が遅いって連絡、これまでどれくらい来てました？」
少し考えてから、インフラ担当は自分の個人チャットを検索しました。「精算」「遅い」「再起動」。結果を下へ送っても、なかなか終わりが来ません。
2年で62回。毎月、締めの時期に、同じ形で。
第1話で、チームの依頼は個人のチャットとメールに散らばっていて、記録が残らないという話をしました。ここで起きているのは、その裏返しです。記録はあった。ただし、インフラ担当の個人チャットの中にだけ。本人が検索しない限り、誰にも見えない記録です。
ここで、ITILの名前を2つ渡します。
経理の画面が固まって、締めの入力が止まる。計画外にサービスが止まったり、品質が落ちたりすること。これは前回出てきたインシデント（incident）です。名人は62回のインシデントを、全部きれいに片付けてきた。
では、その62回のインシデントを起こしていたものは何か。ITILは、インシデントの原因、または原因になりうるものを問題（problem）と呼びます。
62回直して、一度も解いていない。手を抜いていたのなら、話は簡単でした。
インシデントを片付ける仕事の出来は、どれだけ早く通常に戻したかで測られます。前回出てきたサポート（support）の物差しです。この物差しで見ると、名人は満点でした。15分で戻す。経理も「助かりました」と言う。誰も困っていない。
そして、速く戻るほど、原因を調べる理由がなくなる。調べるのには何日もかかるし、その時間は誰からも頼まれていない。評価もされない。サポートが上手すぎると、問題は水面の下に沈んだままになるんです。
リーダーは、インフラ担当と二人で話しました。責めるつもりはないと最初に言ってから、なぜ原因を調べなかったのかを聞いた。
しばらく黙ってから、返事がありました。「調べようと思ったことは、何回もありますよ」
「でも、ログを追い始めると2日は潰れる。その間に、個人チャットに別の依頼が10件たまる。再起動なら15分。……どっちを選ぶかって言われたら、再起動です」
それから、少し言いにくそうに付け足しました。
「あと、正直に言うと……書いて誰でもできるようにしたら、自分がいる意味がなくなる気がしてたのも、あります」
はじめの言い分は、2日と15分を比べれば説明がつきます。付け足した一言のほうは、つきません。
このチームでは「名人にしか直せない」ことが、そのまま名人の居場所になっていました。頼られる人が、できる人。第1話で出てきた価値観です。その価値観の中では、手順を書いて誰でもできるようにすることは、自分の居場所を自分で消すことになる。
だから「書いてください」とお願いするだけでは、何も変わりません。変えるべきは、書いた人が損をする仕組みのほうです。
名人の最後の一言で、この回のうしろ側が少し見えました。名人の席だけでなく、名人を待っていた席と、話を聞きつけた席のうしろにも、子がいます。
子は人ではなく、席につく。言葉がきつくなるのは、うしろの子が何かを怖がっているとき。6体の紹介は地図に
「書いて誰でもできるようにしたら、自分がいる意味がなくなる気がしてた」
怖いのは自分にしかできないことがなくなって、席の意味まで消えること
「精算が固まってます。どうすればいいですか」
怖いのは止まったことを、いつも経理からの電話で最後に知ること
「戻ったのは分かりました。それで、来月は？」
怖いのはなぜ止まったのかが空いたまま、次の締めが来ること
「サーバーを大きくすれば済むなら、いくらかかるの」
怖いのは足りないから増やす、を毎年言われて、予算の枠があふれること
せきのこ ── 席のうしろの、小さな子たち
リーダーは、インフラ担当の個人チャットへの依頼を、2週間だけほかの6人で引き受けることにしました。そのかわり、精算システムの原因を調べることを、インフラ担当の正式な仕事にした。
10日目に、原因が分かりました。月末になると、締め処理のバッチと、全国8つの営業所からの一斉入力が重なる。そのとき、サーバーの中で接続が解放されずに積み上がり、最後は固まる。再起動すると、積み上がった接続が一度に消えるので、戻る。
直すには、ベンダーにサーバーの設定を変えてもらう必要がありました。すぐにはできません。
原因は分かった。けれど、まだ直っていない。この状態にも、ITILは名前を付けています。分析は済んだが、まだ解決していない問題を既知のエラー（known error）と呼びます。
そして、名人がやってきた再起動。完全に直せるまでの間、インシデントの影響を減らしたり、なくしたりするための手を、ITIL 4では回避策（workaround）と呼んでいました。名人の技には、ちゃんと名前があったわけです。
problemは、ひとつ以上のインシデントの原因、または原因になりうるもの。known errorは、分析は済んだが、まだ解決していない問題。
62回の「精算が遅い」がインシデント。それを起こしていた「接続が積み上がって固まる」が問題。原因が分かってベンダーの対応待ちの今が、既知のエラー。
リーダーとインフラ担当は次に、再起動のやり方を1枚にまとめました。第1話の「いつものお願い」カードと同じ形です。
このカードを作るのをいちばん嫌がっていたのは、インフラ担当でした。ところが、ほかの2人が練習で再起動に成功した日、こう言ったそうです。「これで来月、研修に行っても電話が鳴らないですね」
積み上がるのが月末だと分かれば、打てる手がもうひとつ増えます。締めの前に、計画して再起動しておけばいい。経理には前もって知らせて、入力の少ない時間帯を選ぶ。
物差し：どれだけ早く戻したか
物差し：合意したサービスレベルを守れたか
どちらも8つのライフサイクル活動の一部。operateは、日々サービスを動かすこと。成功は合意したサービスレベルに対する実績で測る。supportは、中断のあとにサービスを戻すこと。成功はどれだけ早く通常のサービスに戻したかで測る。
名人はサポートの名人だった。止まる前の再起動を予定に組み込んだことで、同じ作業が運用の側に移った。
名人には、ひそかに誇りにしていた数字がありました。精算システムの障害の、平均復旧時間。15分。
15分は、記録どおりの数字です。ただ、序で出てきたとおり、経理部が欲しいのは締めの3日間、止まらずに入力できることです。15分で戻ってくれることは、その代わりになりません。
めざす結果を得るために、どうしても欠かせない前提条件。ITILはこれを重要成功要因（critical success factor、CSF）と呼びます。それを確かめるために見張ったり報告したりする測定値が、メトリクス（metric、指標）です。
平均復旧時間は、止まった回数が多いほど、練習を積んで短くなっていきます。つまり、問題が放置されるほど、名人の数字は良くなる。数字は嘘をついていないのに、数字が良くなるほど事態が悪くなる。序の緑の報告書と同じ形です。
だから順番が大事になります。測りやすい数字から始めない。めざす結果と、そのために欠かせない条件（CSF）を先に決めて、それを確かめる数字を選ぶ。
名人がいなくても戻せる。固まる前に分かる。なぜ固まるのかも分かっている。この回で置かれたしくみは4つです。
怖がっていたこと自分にしかできないことがなくなって、席の意味まで消えること
怖がっていたこと止まったことを、いつも経理からの電話で最後に知ること
情報＝記録しておけばよい。警告＝影響が出る前に手を打てる。例外＝基準を外れていて、影響が出ている。
意味のある状態の変化を拾い、重さで分ける。全部に同じように反応しないことが、見張る仕事の半分です。ヘルプデスク担当が経理からの電話より先に気づけるのは、真ん中の「警告」があるからです。
怖がっていたことなぜ止まったのかが空いたまま、次の締めが来ること
怖がっていたこと足りないから増やす、を毎年言われて、予算の枠があふれること
同時に使う人数：20人 ／ 画面が開くまで：
数字は、しくみを説明するための目安です。
名人の頭の中にあったものが、4つのしくみに分かれて席に残りました。名人が研修に行く日も、もう子は待たされません。
番号と分類はITIL 4の並べ方です。ITIL 5の試験で押さえるのは「プラクティス＝資源のまとまり」と2つのグループまで。
せきのこ ── 席のうしろの、小さな子たち
2年間、精算は締めのたびに固まり、そのたびに15分ほどで戻りました。経理は「助かりました」と返し、締めは毎月どうにか終わった。個人チャットに依頼が10件たまっていく中で、ログを追って2日潰すより、15分の再起動を選ぶ。あの条件なら、誰がその席に座っても、同じ手を打ったはずです。
ただ、その手には前提がひとつありました。名人が、いつもそこにいること。5月の締めの最終日、その前提が一日だけ外れて、経理の画面は3時間戻らなかった。名人も休む。研修に行く。いつか異動もする。頭の中にしかない回避策は、名人がいない日には、会社にとって存在しないのと同じです。
リーダーはもうひとつ約束しました。カードを作った人、問題を突き止めた人を、障害を速く直した人と同じくらい評価する。名人の居場所を、「自分にしか直せない」から「自分がいなくても直せるようにした」へ移すためです。
| 問題problem | ひとつ以上のインシデントの原因、または原因になりうるもの |
| 既知のエラーknown error | 分析は済んだが、まだ解決していない問題。例：原因が分かり、ベンダーの対応を待っている今の状態 |
| 回避策workaround | （ITIL 4の用語）完全な解決ができるまでの間、インシデントや問題の影響を減らす、またはなくす方法。例：再起動 |
| 運用operate | ライフサイクル活動の1つ。日々サービスを動かす。成功は合意したサービスレベルに対する実績で測る |
| サポートsupport | ライフサイクル活動の1つ。中断のあとにサービスを戻す。成功はどれだけ早く通常に戻したかで測る |
| 重要成功要因critical success factor（CSF） | めざす結果を得るために欠かせない前提条件 |
| メトリクスmetric | 管理や改善のために、見張ったり報告したりする測定値・計算値 |
もっと詳しく：ITIL 5 解説ガイド（8つの活動と成功の測り方／運用の言葉／メトリクスと重要成功要因）
Q1. インフラ担当が10日かけて、締め処理と一斉入力が重なると接続が積み上がって固まる、と突き止めた。根本から直すには、ベンダーの設定変更を待たなければならない。いまの状態を何と呼ぶか。
C。一回一回の「精算が固まった」がインシデント、それを起こしている原因が問題（problem）です。分析は済んだが、まだ解決していない問題を既知のエラーと呼びます。直るまでの間、再起動でしのぐ手は、ITIL 4の言い方では回避策（workaround）です。
Q2. リーダーたちは、締めの前に計画して再起動し、経理には前もって知らせることにした。止まってから戻していたころとくらべて、この作業はどのライフサイクル活動に移り、何で成功を測ることになるか。
B。止まってから戻すのはサポート（support）で、物差しは戻す速さです。名人の「平均15分」はこの物差しでした。予定に組み込んで日々動かす側に移れば運用（operate）になり、合意したサービスレベルに対する実績で測ります。Cは移行（transition）、Dは構築（build）の物差しです。