「それ、何に基づいてやったの？」と聞かれて、誰も答えられなかった。チームの仕事の「入口」の話です。
動いている精算システム＝output。締めが期限までに終わること＝outcome。価値は受け取る側の知覚で決まり（value）、提供する側と受け取る側が一緒に作る（value co-creation）。決める人が顧客（customer）、使う人がユーザー（user）、お金を承認する人がスポンサー（sponsor）。
記録が残らないのは、だらしないからではありません。
記録しないほうが得をする仕組みに、なっているからです。
記録しないと、誰が何を得するのか。
リーダーになって2週目のことです。隣の席のメンバーが、共有フォルダに権限を付けているのが目に入りました。
「それ、誰の依頼？」
「北関東の営業所の課長です。チャットで来ました」
「その権限、付けていいって、誰が決めたの？」
マウスの上で、メンバーの手が止まりました。少し考えてから、こう答えた。「……前もやってたので」
リーダー自身、去年までまったく同じ答え方をしていたはずです。答えられないのは、答えがどこにも書かれていないからです。
試しに、そのメンバーのチャットを見せてもらいました。
同じ週、情シス課長から頼まれごとがありました。「来年度の人員の相談をしたいから、うちに来る問い合わせが月に何件くらいか、出しておいて」
さっそく、チームの全員に聞いて回りました。
答えは、100件から300件。3倍も違います。しかも、根拠を出せる人は一人もいません。チャットとメールは7人の受信箱にばらばらに散っていて、対応の記録もつけていない。何が、何件来ているのかを知る方法が、そもそもなかったんです。
件数が分からないと、何が困るのか。まず、人を増やしてほしいと言えない。「忙しいんです」は、数字がなければ感想として扱われます。何から直せばいいかも決められない。いちばん多い困りごとが何なのか分からないので、目立った一件に振り回される。
見落とされやすいのは、その先です。チームの頑張りが、外から見えない。どれだけ片付けても、数が残らなければ、会社にとっては「何も起きなかった月」と同じです。
記録がなくて、いちばん損をしているのは、毎日チャットを片付けている本人たちです。
リーダーは、7人に一つだけ頼みました。「1週間、届いた依頼を全部、チームの共有チャンネルに転記してください。どこから、何の用件で、どうやって届いたか。それだけでいいです」
ヘルプデスク担当が、少し硬い顔で聞きました。「それって、さぼってないか見るためですか」
「誰が休んでも、頼んだ人を待たせないためです。数は、誰の評価にも使いません」
記録の話をすると、まず「監視される」と受け取られます。目的を先に言葉にしておかないと、転記はすぐに止まる。
1週目に転記されたのは61件でした。少なすぎる気がして、リーダーは2つめのお願いをします。「同じ週の自分のチャットとメールをさかのぼって、転記し忘れたものを拾ってください」。拾い直すと、94件になりました。
拾い漏れがいちばん多かったのは、ヘルプデスク担当です。ほかの6人のぶんまで電話に出ていては、転記まで手が回りません。いちばん忙しい人の仕事ほど、記録に残らない。だから94件は、「少なくとも94件」と読むのが正しい数字です。
この94件を並べて、初めて絵が描けました。
届き方と用件で分けると、こうでした。
届き方
用件
課長も、インフラ担当も、ヘルプデスク担当も、全員が少なく見積もっていました。一人ひとりに見えているのは、自分あての分だけだからです。7つの受信箱に分かれた仕事の合計は、誰の目にも入っていなかった。
リーダーはまだ、何ひとつ改善していません。仕組みを入れる前に、いま実際に何が起きているかを現場で見て数えただけです。
思い込みや又聞きに頼らず、現場を直接見て測る。ITILはこれを、仕事を進めるときの原則のひとつとして現状からはじめる（start where you are）と呼んでいます。「全部作り直す」でも「何も変えない」でもなく、いまあるものを見て、使えるものは使う。最初の一歩は、たいていこれです。
数えてみると、届いたものは大きく2つの箱に分かれました。
→ 一刻も早く元に戻すのが目的
→ 決まった手順で、待たせずに応える
左の箱、計画外にサービスが止まったり、品質が落ちたりしたものを、ITILではインシデント（incident）と呼びます。完全に止まっていなくても、「遅い」「一部だけ使えない」も含みます。
右の箱がサービス要求（service request）です。ここで、ITILの定義をちゃんと読んでみます。
利用者からの、あらかじめ合意された通常の依頼。壊れているわけではない。パスワードのリセット、機器の手配、権限の付与、情報の問い合わせ、苦情やお礼など。
では、このチームに届いた50件の「いつものお願い」は、あらかじめ合意されていたか。
94件のうち50件は、見た目は「いつものお願い」でした。でも定義に照らすと、このチームにサービス要求は1件もなかったことになります。誰が頼んでいいのか、何を確かめてから応えるのか、どこまでやったら終わりなのか。何ひとつ合意されていなかったからです。
合意がないから、毎回その場の判断になる。その場の判断は、記録されない。だから「何に基づいてやったの？」に答えられない。冒頭のメンバーの「……前もやってたので」は、この構造が、そのまま口から出てきた言葉です。
逆に言えば、やることは決まります。いつものお願いを、本当の意味のサービス要求にする。そのために、合意を作る。手始めに選んだのは、件数の多い5つです。
箱を分けてみると、入口の後ろで動いている仕事も、2種類だったことが分かります。
壊れたとき
お願いのとき
どちらも、製品とサービスの一生を8つに分けた活動（ライフサイクル活動）の一部。Supportは、問題・インシデント・問い合わせ・依頼に対応して通常の状態に戻すこと。何かを作ったり展開したりはしない。Deliverは、動いているサービスとその価値を、利用者が使える状態に保ち続けること。
「見積システムが開かない」を直すのも、「新入社員にPCとアカウントを」に応えるのも、入口の仕事はSupport。届けたアカウントで毎日ちゃんと仕事ができる状態が、Deliverの成果。
入口を作る前の週に、こんなことがありました。ヘルプデスク担当に、ほぼ同時に2通のチャットが届いた。
ヘルプデスク担当は、社長の壁紙を先に直しました。5分で終わった。その間も、工場の出荷口では、トラックがエンジンをかけたまま待っていた。出発が遅れ、納品の時間に間に合わない便が出ました。
あとで事情を聞いた社長は、こう言ったそうです。「なんで工場を先にやらなかったの」
社長も、工場を先にしてほしかった。なのに壁紙が先になったのは、ヘルプデスク担当の判断が悪かったからではありません。個人あてのチャットには、誰から来たかしか書いていないからです。何が止まっていて、何人が待っているかは、開いてみないと分からない。並べて比べる場所もない。だから順番は、送り主の肩書きで決まってしまう。
入口を1つにして並べると、初めて「業務への影響の大きさ」と「急ぎ具合」で比べられるようになります。
個人あてのチャットは、頼む側にも受ける側にも速いやり方でした。ただ、その速さの裏で待たされていた子が、4体います。
子は人ではなく、席につく。言葉がきつくなるのは、うしろの子が何かを怖がっているとき。6体の紹介は地図に
「先週お願いした件、どうなってます？ 担当の方、お休みだったみたいで」
怖いのは頼んだ件が、知らないところで止まっていること
「来月の新人のPCとアカウント、誰に何を伝えればいいんでしたっけ」
怖いのは何を、誰に、どう頼めば通るのか分からないまま、新人の初日が来ること
「……前もやってたので」
怖いのは「何に基づいて」と聞かれたとき、自分の判断しか答えがないこと
「出荷ラベルが印刷できません。トラック3台が積み込みを待っています」
怖いのは誰から来たかで順番が決まって、工場の件が後回しにされること
せきのこ ── 席のうしろの、小さな子たち
数えた1週間が終わったとき、ヘルプデスク担当がぽつりと言いました。「転記してる間に、もう1件片付けられるんですけどね」
計算としては、そのとおりです。評価はずっと、どれだけ片付けたかと、「あの人に頼めば早い」という評判で決まってきた。頼られれば、うれしくもある。この条件なら、記録に時間を使うのは損です。記録しない人のほうが速く見えて、評判も上がる。
数えるためだけの作業は、足していません。記録は、仕事の通り道に置いておくものです。入口で番号を付ければ、数はそこを通った跡として、勝手に残ります。
リーダーは、評価のほうも変えると約束しました。片付けた件数に加えて、カードを作ったことも、記録を残したことも、仕事として数える。記録しないほうが得をする仕組みのままで「記録してください」と頼んでも、続かないからです。
共通窓口ができ、全社に案内が出ました。課長には「少なくとも月400件。うち3分の2は、壊れてはいないお願いと質問」と、根拠つきで報告できました。ただ、個人あてのチャットは、ゼロにはなりません。いまも毎週何件か届く。そのたびにメンバーは「窓口に転記しておきますね」と返して、番号を付けています。
いちばん効いたのは、パスワードの件でした。週に24件、ヘルプデスク担当が一件ずつ手で戻していたものを、社員が自分で画面から戻せるようにしたのです。翌月、パスワードのチャットはほとんど来なくなりました。
service action 担当者が毎回作業する
access to resources 社員が仕組みを自分で使う
サービスとして差し出すもの（オファリング）は、グッズの移転（所有権が渡る物）、リソースへのアクセス（提供者の資源を決めた条件で使える）、サービス・アクション（提供者が利用者のために作業する）の3つでできている。デジタルの提供者は、自動化やセルフサービスでサービス・アクションを減らし、アクセスに置き換えていく傾向がある。
パスワードを戻す作業は、担当者の作業（サービス・アクション）から、社員が自分で使う画面（リソースへのアクセス）に変わった。新入社員に配るPCは、所有権が会社に残るならアクセス、本人に渡すならグッズ。
番号の付いた記録が1か月分たまったころ、ヘルプデスク担当が画面を見ながら言いました。「あの、これ……先月も来てました。その前の月も」
| インシデントincident | 計画外のサービスの中断、または品質の低下。遅いのも含む |
| サービス要求service request | あらかじめ合意された、通常の依頼。苦情やお礼も含む。インシデントではない。合意がなければ、まだサービス要求になれていない |
| サポートsupport | ライフサイクル活動の1つ。インシデントや問題に対応し、通常に戻す。何も作らず、何も展開しない。出来は復旧の速さで測る |
| 提供deliver | ライフサイクル活動の1つ。利用者がサービスを使い続けられるように届ける |
| オファリングの3要素transfer of goods / access to resources / service actions | 所有権が移る＝グッズ、移らず使える＝アクセス、提供者が作業する＝サービス・アクション。セルフサービスはサービス・アクションを減らす |
| 現状からはじめるstart where you are | 従うべき原則の1つ。作り直す前に、いまあるものを現場で直接見て測り、使えるものは使う |
もっと詳しく：ITIL 5 解説ガイド（サービス・オファリング／8つの活動／従うべき原則）
共通窓口ができて1か月。個人あてのチャットはゼロにはなっていません。それでも、4体の子が怖がっていたものには、それぞれ答えが置かれました。
怖がっていたこと頼んだ件が、知らないところで止まっていること
怖がっていたこと何を、誰に、どう頼めば通るのか分からないまま、新人の初日が来ること
怖がっていたこと「何に基づいて」と聞かれたとき、自分の判断しか答えがないこと
怖がっていたこと誰から来たかで順番が決まって、工場の件が後回しにされること
4つとも、ITILがプラクティスと呼ぶしくみです。人・手順・道具・情報・外の会社をまとめたもので、担当が休んでも席に残ります。入口のしくみが4つも要るのは、入口に並ぶ子が4種類いたからです。
番号と分類はITIL 4の並べ方です。ITIL 5の試験で押さえるのは「プラクティス＝資源のまとまり」と2つのグループまで。
せきのこ ── 席のうしろの、小さな子たち
Q1. リーダーは仕組みを入れる前に、7人に1週間、届いた依頼をすべて共有チャンネルに転記してもらい、少なくとも94件という数をつかんだ。この進め方にもっとも近い「従うべき原則」はどれか。
B。100件から300件までばらついた見立てに頼らず、現場で直接見て測ったので「現状からはじめる」です。従うべき原則は7つあり、ITIL バリュー・システムの5つの構成要素の1つです。Dは、手順を整えてから、価値のあるところを自動化するという原則です。
Q2. 第二工場から「出荷ラベルが印刷できない。トラック3台が積み込みを待っている」と連絡が来た。これを直して通常の状態に戻す仕事は、8つのライフサイクル活動のどれにあたるか。
C。ラベルが印刷できないのは計画外の中断なので、インシデント（incident）です。それを通常の状態に戻すのがサポートで、成功はどれだけ早く戻したかで測ります。運用は「動かし続ける」、提供は「利用者に届け続ける」、移行は「本番へ安全に移す」活動です。ITIL 4のバリューチェーン（6つの活動）では「提供とサポート（deliver and support）」が1つの活動でしたが、ITIL 5の8つの活動では、運用・提供・サポートに分かれています。