春から作ってきたカードと手続きが、いつのまにか、仕事を止める側に回っていた。
方向づけと統制＝governance（evaluate・direct・monitor）。機会と需要を価値に変える仕組み＝ITIL value system。5つの構成要素＝原則・ガバナンス・バリューチェーン・プラクティス・継続的改善。いま＝mission、未来＝vision、誰のために＝purpose。
型は、目的と一緒に渡さないと、
型を守ることが目的になります。
春から1枚ずつ書き足してきたカードが、チームの足を止めていました。手を抜いた人は、どこにもいません。
12月のある日、営業所の課長から共通窓口に依頼が入りました。新しく入った人に、共有フォルダの権限を付けてほしい。第1話で作った「いつものお願い」カードにある依頼です。
ところが、このフォルダは第4話で台帳に載せたサーバーの上にありました。台帳の決まりでは、そのサーバーの設定に触るものは変更カードを書く。変更カードは課長の了承が要る。課長はその週、予算の会議で席にいませんでした。
権限が付いたのは、2日後でした。そのあいだ、新しく入った人は、隣の席の人の画面をのぞきこんで資料を読んでいました。作業そのものは、3分です。
その週の定例で、メンバーの一人が言いました。「カードを書いてる時間のほうが、作業より長いんです」。少し言いよどんでから、続けました。「春のほうが、頼んだ人は早く片付けてもらえてました」
改善のアイデアを書き込む一覧は50件を超えたまま、誰も手を付けていませんでした。書いても何も起きないので、最近は書く人もいなくなっていた。
そこへ営業本部長が顔を出しました。「ロボットを入れればいいじゃないか。承認なんか、全部自動で回せるだろう。うちの部じゃ、もう事務に使ってるよ」
定例のあと、ヘルプデスク担当が、裏紙を1枚持ってリーダーの席に来ました。権限ひとつの流れが、手書きで書き出してある。「リーダー、これ……原則の『シンプルにする』に、反してませんか。3分のことに、40分かけてます」
春には「何に基づいて」に答えられなかった人が、ITILの言葉を使ってリーダーに意見している。言葉は、この1年でチームの中に広がっていました。その言葉で最初に指摘されたのが、言葉を持ち込んだ本人です。
形は、序の緑の報告書と同じでした。6年前、責められ続けた情シスは、責められないための報告書を作った。それは盾として完璧に働き、そして相手の側を見えなくした。
リーダーが春から作ってきたカードにも、同じ性質がありました。「何に基づいてやったの？」と聞かれて困らないための盾です。盾は、全部の依頼に同じ厚さで構えたほうが安心できる。だから、3分の作業にも、工場を止めかねない変更にも、同じカードと同じ承認を通した。
型を作った人が、いちばん型に縛られる。リーダーは、春に自分が壊したものと同じ形のものを、正しさの名前で作っていたわけです。
春から、リーダーはほかの席のうしろを見てきました。今回は、カードを作ってきたリーダーの席のうしろを見ます。
子は人ではなく、席につく。言葉がきつくなるのは、うしろの子が何かを怖がっているとき。6体の紹介は地図に
「書いても何も起きないので、最近は書いてません」
怖いのは書いた改善が、「いつか」のまま積もっていくこと
「3分の作業でも、変更カードは通してください」
怖いのは「何に基づいて」と聞かれて、また答えられなくなること。だから、どこにも空白を残したくない
せきのこ ── 席のうしろの、小さな子たち
リーダーは、カードの対象になっている仕事を全部並べて、性質で分けてみました。ITIL 5は、仕事が置かれた状況によってふさわしいやり方が変わる、という複雑性思考（complexity thinking）を取り入れています。状況は3つに分けて考えます。
共有フォルダの権限は、秩序だった仕事です。何度やっても同じ結果になる。こういう仕事は、手順を決めて標準化し、できるところは自動にして、承認は前もって済ませておくのがふさわしい。毎回、課長の了承を待つ理由はありません。
ヘルプデスク担当が、裏紙の流れを指でなぞりながら言いました。「これ、もともと合意してあるサービス要求なんです。触る設定も毎回同じ。だったら標準変更にして、手順ごと前もって許可しておけばいい。変更カードは、工場を止めかねない変更のために取っておけます」
逆に、取引先の注文アプリのような新しい仕事は、どれだけ立派なカードを書いても、正解は書けません。原因と結果が、やってみるまで分からないからです。こちらには、固い手順よりも、小さく試して早く反応をもらう進め方が合う。
仕事が置かれた状況によって、ふさわしいやり方が変わるという考え方。秩序だった状況は原因と結果がはっきりしていて決まった手順で進められる。複雑な状況は原因と結果があとからしか分からず、試しながら進める。混沌とした状況はつながりが見えず、まず状況を安定させる。予測できる仕事は標準化と自動化、複雑な仕事は試行と早いフィードバック。
権限の付与は秩序だった仕事。注文アプリは複雑な仕事。同じ重さのカードを両方に当てはめたのが、渋滞の原因だった。
営業本部長のロボットの提案に、リーダーはすぐには乗りませんでした。図1の流れをそのまま自動にすると、変更カードは一瞬で書けるようになる。でも、課長の了承待ちの2日は、ロボットにはどうにもできない。そもそも、3分の作業に変更カードは要らなかった。
ITILの原則には、最適化し、自動化する（optimize and automate）があります。順番が大事で、まず最適化し、そのあと価値がある所を自動化する。ムダの多い手順をそのまま自動にすると、ムダが速く、大きくなるだけです。
あわせて効いたのが、シンプルにし、実践的にする（keep it simple and practical）です。成果を出すのに必要な最小の手順にして、価値を生まない手順は取り除く。シンプルにするのは、たいてい「簡単」なことではありません。何を削っても大丈夫かを決めるには、何のための手順だったかを分かっている必要があるからです。3分の作業から変更カードを外せたのは、そのカードが何を守るためにあるかを、作った本人が説明できたからでした。
手を付けられずにたまっていた50件の改善アイデアも、同じ渋滞の一部でした。リーダーは、ITILの継続的改善モデルの7つのステップに沿って、カードの重さの見直しを1件目として動かしました。
一度に全部を直そうとは、しませんでした。まず2種類だけ、2週間。反応を見て、次の2種類へ。原則のフィードバックをもとに反復して進化するを、そのままなぞる進め方です。権限のカードだけを軽くして終わりにせず、窓口・台帳・変更の流れ全体のどこで待ちが生まれているかも見ました。こちらは全体的に考えて取り組むにあたります。
シンプルにし、実践的にする：必要最小の手順にし、価値を生まない手順を取り除く。フィードバックをもとに反復して進化する：小さく分けて進め、前・途中・後で意見をもらう。最適化し、自動化する：まず最適化し、価値がある所を自動化する。全体的に考えて取り組む：一部だけでなく全体を1つの仕組みとして扱う。継続的改善モデルは、ビジョン→現状→目標→計画→行動→確認→維持の7ステップをくり返す。
3分の作業から変更カードを外したのがシンプルにする。2種類ずつ2週間で試したのが反復。ロボットの前に手順を削ったのが最適化してから自動化。
3分の作業から変更カードを外し、改善の一覧を2種類ずつ動かしました。この回で置かれたのは、しくみ1つと、原則1つです。
怖がっていたこと書いた改善が、「いつか」のまま積もっていくこと
怖がっていたこと「何に基づいて」と聞かれて、また答えられなくなること。だから、どこにも空白を残したくない
リーダーのくうらんを落ち着かせたのは、プラクティスではなく原則でした。原則は34のしくみの外にあって、どのしくみをどれくらいの重さで使うかを決める拠り所です。しくみを足すことで子を落ち着かせてきたこの1年で、はじめて「減らす」ことで落ち着いた子です。
番号と分類はITIL 4の並べ方です。ITIL 5の試験で押さえるのは「プラクティス＝資源のまとまり」と2つのグループまで。
せきのこ ── 席のうしろの、小さな子たち
見直しを始めて最初に来た権限の依頼は、窓口で受けたその日のうちに片付きました。変更カードは書いていません。課長の戻りを待った人も、いませんでした。
工場を止めかねない変更には、いまも同じカードと同じ承認を通しています。外したのは、3分の作業に着せていた重さだけです。春の時点では、全部に「何に基づいて」を書き足すことが、いちばん必要だった。その正解が、条件の変化で古くなった。序で自分が書いた一行が、12月になって自分に返ってきました。
| 複雑性思考complexity thinking | 状況は秩序だった・複雑・混沌の3つ。状況でやり方を変える |
| 秩序だった／複雑な／混沌としたordered / complex / chaotic | 決まった手順で進める／試しながら進める／まず安定させる |
| シンプルにし、実践的にするkeep it simple and practical | 必要最小の手順にし、価値を生まない手順を取り除く |
| フィードバックをもとに反復して進化するprogress iteratively with feedback | 小さく分けて進め、前・途中・後で意見をもらう |
| 最適化し、自動化するoptimize and automate | まず最適化し、価値がある所を自動化する |
| 全体的に考えて取り組むthink and work holistically | 一部だけを最適化せず、全体を1つの仕組みとして扱う |
| 継続的改善モデルcontinual improvement model | ビジョン→現状→目標→計画→行動→確認→維持の7ステップをくり返す |
もっと詳しく：ITIL 5 解説ガイド（従うべき原則／継続的改善モデル／バリューストリームの主要概念と適用）
Q1. 共有フォルダの権限の付与は、何度やっても同じ手順で、同じ結果になる。それなのに毎回、変更カードを書いて課長の了承を待っていた。複雑性思考で見ると、この仕事はどう扱うのがふさわしいか。
A。原因と結果がはっきりしていてくり返せる仕事は、標準化と自動化が合います。取引先の注文アプリのような前例のない仕事なら、Bの進め方です。ITIL 4のchange enablement（変更実現）のプラクティスでは、こうした変更を「標準変更」として前もって許可していました。
Q2. 権限とPC手配の2種類だけ、2週間、事前承認で回してみた。そのあと権限付与にかかる時間を測り直すと、平均で当日に片付いていた。継続的改善モデルの何番目のステップか。
C。行動のあとに測り直して、目標に届いたかを確かめるのがステップ6です。改善の前に「作業3分、待ち2日」を測ったのはステップ2、月1回の見直しを定例に入れたのはステップ7です。2と6、6と7の取り違えがよく問われます。