異動の内示。1年で作ったものを、何にして、誰に渡すのか。
原因と結果が見えない状況＝chaotic、まず安定させる。約束どおり動くか＝warranty（可用性・キャパシティ・セキュリティ・継続性）。気候はEnvironmental。大きな被害を出す突然の出来事＝disaster。
変革は、それが日常になったときに、
はじめて終わります。
シリーズの最初に、地図のページでひとつ問いを置きました。「あなたがいなくても回る情シスは、作れるか」。この章は、その問いにリーダー自身が答える話です。
4月から本社の経営企画へ。内示を受けた日、リーダーは新しいファイルを開き、1行目に「引き継ぎ」と打ったところで、手が止まりました。
1年前、自分が引き継いだのは、全部緑の月次報告1枚でした。何に基づいているのかは、どこにも書いていなかった。今度は、自分が渡す側です。
後任は、ヘルプデスク担当に決まりました。春には、記録をつけると聞いて「それって、さぼってないか見るためですか」と硬い顔で聞いた人です。いまはチームでいちばんカードを書いていて、12月には、リーダーに原則の名前で意見もしました。
しばらく考えて、「やっている作業の一覧」を作るのはやめました。作業は、もう窓口とカードと台帳に書いてある。渡すべきなのは、それらがなぜそこにあって、どうつながっているか、のほうです。
会社が少しずつ組み立ててきたものは、第8話の時点で、ほぼITILバリュー・システムの形になっていました。欠けていたのは「継続的改善」だけ。それも12月に動き出し、いまは5つがそろっています。引き継ぎの資料は、この5つで組み立てることにしました。
この5つは、別々の部品ではありません。原則が判断の向きを決め、ガバナンスが選んで確かめ、バリューチェーンが実際に価値を生み、プラクティスがそのための資源を与え、継続的改善が全体を良くし続ける。どれか1つだけを渡しても、回らない。
1年前に引き継がれた緑の報告書は、この5つのうちの、プラクティスの中のツールの、さらにその一部でした。だから、作った人がいなくなると、形だけが残った。
引き継ぎの打ち合わせで、後任は資料をめくりながら言いました。「これ、ほとんど知ってます。毎日やってることなので」
リーダーは、それがいちばんうれしかったそうです。
異動のあいさつに第二工場へ行くと、工場長は事務所の壁の画面を指さして言いました。「変えるな、と言ったのが1年前か。あれから随分変わったのに、毎日の出荷はいつもどおりだ。通常業務を回したままの変革、ってのは、こういうことなんだろうな」
この1年は、属人化した情シスから、誰がいなくても回る情シスへの、小さな変革でした。それは、毎月の小さな変更（change）を積み重ねて進み、いま、いつもの仕事になっている。
変革が「プロジェクト」のままだと、担当者がいなくなったときに止まります。日常の手順の中に溶けたとき、変革は担当者を必要としなくなる。後任の「毎日やってることなので」は、その合図でした。
最後の月の見直しの場で、改善の一覧に新しい1件が載りました。書いたのは、インフラ担当です。
「工場のサーバー室の非常用電源を、30分から2時間に延ばす。費用の見積もりは添付。経営会議にかける資料も下書きしました。継続的改善の一覧に載せるなら、動かすところまで自分でやります」
春には、自分にしか直せないことが居場所だった人です。「書いて誰でもできるようにしたら、自分がいる意味がなくなる気がした」と打ち明けたその人が、いまは、自分が呼ばれなくて済むための改善を、自分から書いている。
ITILは、継続的改善は全員の責任だとしています。専任の担当者だけの仕事ではない。リーダーがいなくなっても改善の一覧が動き続けるなら、それはもう、チームの仕組みです。
継続的改善は、要求が変わっても、プロダクト・サービス・プラクティスを有効に保ち続けるための、くり返しの活動。バリュー・システムの構成要素の1つで、組織のすべての層に織り込まれ、全員の責任である。バリュー・システムの5つの構成要素は互いに支え合い、機会と需要を価値に変える。変革は、通常業務を止めずに、変更を積み重ねて進む。
インフラ担当が自分で書いた改善の1件。後任の「毎日やってることなので」。この2つが、変革が日常になった証拠。
この1年、各話で席のうしろを見てきました。経理部長のうしろのもやすけ。工場長のうしろのはつみみ。名人のうしろのぽつん。
子は人ではなく、席につきます。だから、人が替わっても子はいなくならない。4月からヘルプデスク担当がリーダーの席に座れば、その背中には、リーダーが背負ってきたくうらんがつきます。
それでも、1年の終わりに、子たちは落ち着いています。落ち着かせたのは、誰かの頑張りではありません。席に置いてきたしくみです。窓口、カード、台帳、約束、変更が通る道、AIに読ませる正本。しくみは、置いた人がいなくなっても席に残る。34のプラクティスを、ITILが組織の資源のまとまりとして説明するのは、このためです。
インフラ担当が非常用電源の改善を自分から書いた日、その席のぽつんは、もう丸まっていませんでした。
子は席につく。
だから、しくみも席に置く。
| 話 | 席と子 | しくみ |
|---|---|---|
| 序 | 経理部長もやすけ | 測定および報告No.6 Measurement and reporting |
| 序 | 経理の担当者くうらん | 可用性管理No.15 Availability management |
| 第1話 | 総務の担当者はつみみ | サービスデスクNo.28 Service desk |
| 第1話 | 人事の担当もやすけ | サービス・カタログ管理No.24 Service catalogue management |
| 第1話 | 隣の席のメンバーくうらん | サービス要求管理No.30 Service request management |
| 第1話 | 第二工場の事務ぽつん | インシデント管理No.19 Incident management |
| 第2話 | インフラ担当（名人）ぽつん | 要員およびタレント管理No.14 Workforce and talent management |
| 第2話 | ヘルプデスク担当はつみみ | モニタリングおよびイベント管理No.21 Monitoring and event management |
| 第2話 | 経理部長くうらん | 問題管理No.22 Problem management |
| 第2話 | 管理本部長わくもり | キャパシティとパフォーマンス管理No.17 Capacity and performance management |
| 第3話 | 工場長はつみみ | 変更実現No.18 Change enablement |
| 第3話 | ベンダーのSEくうらん | サービスの妥当性確認およびテストNo.31 Service validation and testing |
| 第3話 | 第二工場の出荷担当あとで | 展開管理No.32 Deployment management |
| 第4話 | 管理本部長わくもり | サービス財務管理No.11 Service financial management |
| 第4話 | インフラ担当くうらん | サービス構成管理No.25 Service configuration management |
| 第4話 | 北関東営業所の事務ぽつん | IT資産管理No.20 IT asset management |
| 第4話 | 情シス課長もやすけ | インフラストラクチャとプラットフォーム管理No.33 Infrastructure and platform management |
| 第5話 | 経理部長（顧客）もやすけ | サービスレベル管理No.29 Service level management |
| 第5話 | 経理の担当者（ユーザー）ぽつん | 関係管理No.10 Relationship management |
| 第6話 | 総務の担当者くうらん | リスク管理No.2 Risk management |
| 第6話 | 候補Aの営業わくもり | サプライヤ管理No.13 Supplier management |
| 第7話 | 工場長ぽつん | 組織変更の管理No.7 Organizational change management |
| 第7話 | 工場の事務の担当者もやすけ | サービスデザインNo.27 Service design |
| 第8話 | 情シス課長わくもり | ポートフォリオ管理No.8 Portfolio management |
| 第8話 | 選ばれなかった部の部長ぽつん | 事業分析No.16 Business analysis |
| 第8話 | 要望を出す部の部長もやすけ | 戦略管理No.12 Strategy management |
| 第9話 | メンバーあとで | 継続的改善No.3 Continual improvement |
| 第9話 | リーダーくうらん | シンプルにし、実践的にする原則（34には入らない） |
| 第10話 | 営業所の担当者はつみみ | リリース管理No.23 Release management |
| 第10話 | 情シス（動かす側）くうらん | ソフトウェア開発と管理No.34 Software development and management |
| 第10話 | 開発チームのリーダーもやすけ | アーキテクチャ管理No.1 Architecture management |
| 第10話 | 取引先の惣菜店あとで | プロジェクト管理No.9 Project management（途中で見つかった子） |
| 第11話 | 経理部長もやすけ | ナレッジ管理No.5 Knowledge management |
| 第11話 | 総務の担当者くうらん | 情報セキュリティ管理No.4 Information security management |
| 第11話 | ヘルプデスク担当ぽつん | 要員およびタレント管理No.14 Workforce and talent management（再登場） |
| 第12話 | 工場長あとで | サービス継続性管理No.26 Service continuity management |
| 第12話 | リンクを押した社員くうらん | 情報セキュリティ管理No.4 Information security management（再登場） |
せきのこ ── 席のうしろの、小さな子たち
リーダーが4月から座る経営企画の席のうしろにも、子がいます。たぶん、「今じゃない」が口ぐせの、あとでです。
引き継ぎ資料の最後のページに、リーダーは1年分の「正解の入れ替え」を並べました。
そして、その下に一行だけ書き足しました。「右の列も、いつか左に移る」。
12月に、リーダー自身が春の正解に縛られたように、この表の右側も、条件が変われば古くなります。人が減る、AIが変わる、会社の目的が変わる。そのとき後任のチームがすべきことは、この表を守ることではありません。表を書き換えることです。
異動の前の日、リーダーは窓口の記録を最後にもう一度だけ開きました。
その日の依頼は38件。共通窓口に届いたのが34件、個人あてのチャットに届いて転記されたのが4件。全部に番号が付いていました。AIが答えて人が確かめたもの、カードどおりに片付いたもの、変更カードを通ったもの。リーダーの名前が出てくる記録は、1件もありませんでした。
答えは、こうです。作れる。ただし、完成はしない。
仕組みは、作った人がいなくなったあとも、書き換えられ続けることで回ります。だから、作った人にできる最後の仕事は、書き換えていいと言い残して、席を立つことです。
| ITILバリュー・システムITIL value system | （再登場）機会と需要を価値に変える仕組み。5つの構成要素が支え合う |
| 5つの構成要素guiding principles / governance / value chain / management practices / continual improvement | 原則・ガバナンス・バリューチェーン・管理プラクティス・継続的改善 |
| 継続的改善continual improvement | 関連性を保つための、くり返しの活動。全員の責任 |
| 変革と通常業務transformation / BAU | （再登場）変革は、変更を積み重ねて進み、日常になったときに終わる |
試験の総まとめ：ITIL 5 解説ガイド（試験の受け方と総まとめ／まぎらわしいペア／数で覚えるもの）｜ITIL 5 用語ノート
Q1. リーダーは、引き継ぎの資料をITILバリュー・システムの構成要素で組み立てた。その目次に、構成要素として入れるべきでないものはどれか。
C。4つの側面は、すべての活動にかぶせる「見方」で、構成要素ではありません。構成要素は、原則・ガバナンス・バリューチェーン・管理プラクティス・継続的改善の5つ。管理プラクティスは手順書ではなく、人・プロセス・ツール・情報・パートナーといった資源のまとまりです。ITIL 4では、この仕組みを「サービス・バリュー・システム（SVS）」と呼んでいました。
Q2. 後任は引き継ぎの資料を見て「ほとんど知ってます。毎日やってることなので」と言った。インフラ担当は、自分が呼ばれずに済むための改善を、自分から一覧に書いた。この2つの場面の説明として、もっとも適切なのはどれか。
A。変革は、通常業務を止めずに変更を積み重ねて進み、日常になったときに終わります。継続的改善はバリュー・システムの構成要素で、組織のすべての層に織り込まれた全員の責任です。くり返すサイクルなので、終わりはありません。