目次

緑の報告書は、
誰を守っていたのか

嘘はひとつも書いていない。それなのに、役に立たない。そういう報告書がどうやって生まれるのか、という話です。

票番号04-001
報告者経理部
件名締めの最終日に、経費精算の入力が消える
状態調査中

FIRST稼働率99.9%が、隠していたもの

数字は、たいてい誰かを守るために生まれます。

守るために生まれた数字は、嘘をつきません。嘘をつかないまま、肝心なものを見えなくします。

じゃあ、ある会社の話をします。

STAGE唐揚げの「揚げる前」を作っている会社

舞台は、業務用の冷凍食品を作っている会社です。スーパーの惣菜売り場で揚げ直されている唐揚げやコロッケ、あれの「揚げる前」を作っている。工場は北関東に2つと九州に1つ。営業所が全国に8つ。社員はパートさんまで入れて900人ほどです。

情シスは7人しかいません。

900人に7人。ざっと130人にひとりです。PCの入れ替えも、アカウントの発行も、営業所のネットワークも、工場の生産管理システムも、この7人で見ています。

このチームには、業務を説明した文書が1枚もありません。

依頼は、社員が「この人に言えば早い」と知っている担当者に、個別のチャットやメールで直接届きます。担当者はそれを、その場の判断で片付ける。対応した記録は残らないので、何が何件来ているのかも、誰も知りません。「その作業、何に基づいてやったの?」と聞かれても、たぶん誰も答えられません。

それでも毎日、仕事は回っています。回しているのは、7人それぞれの記憶と判断です。

人が足りない職場では、何が起きるか。一人ひとりが自分の身を守る工夫を始めます。これがあとで効いてきます。

この春、チームの中から一人がリーダーになりました。PCとアカウントの仕事を5年やってきた人です。前のリーダーのやり方を見て覚え、自分もそのやり方で回してきた。変わったのは、座る席だけです。

この人を、ここからは「リーダー」と呼びます。この物語の主人公です。

SHIELD最初の週に渡された、出来のいい紙

リーダーになった最初の週、情シス課長が一枚の紙を差し出しました。「月次報告、来月からはあなたがまとめて。去年と同じ作り方でいいから」

紙の端を指で軽くたたいて、課長は付け足しました。「うちはちゃんと回ってる。これを見れば分かる」

情シス月次報告|3月
経費精算システムの稼働率99.9% 正常
重大障害0件 正常
問い合わせ対応件数312件 正常
バックアップの成功率100% 正常
図1 情シスの3月。全部が緑。

リーダーは、数字を集めているメンバーに聞いてみました。「この4つの項目、なんでこの4つなの?」

「前のリーダーのExcelに、監視ツールの数字を貼ってるだけで……なんでこの4つなのかは、分からないです」

この紙、よくできているんです。書いてあることは全部本当です。ただ、なぜこの形なのかは、どこにも書かれていない。形だけが、毎月そのまま受け継がれてきた。理由は、6年前までさかのぼります。

6年前の夏、基幹システムが丸2日止まりました。出荷伝票が出せなくなって、工場の前に冷凍車が並んだ。荷台の温度を保つために、エンジンをかけたまま並んでいたそうです。情シスは役員会に呼ばれ、それから半年、何が起きたのか、なぜ防げなかったのかを毎月説明させられました。

そのころインフラ担当が作ったのが、この月次報告です。毎月、稼働率と障害件数を出す。全部緑。翌月から、役員会で情シスが責められることはなくなりました。

読み解き

この紙は、報告書の形をした盾なんです。盾としては、6年間、完璧に働いてきた。

作った人を悪く言うのは簡単です。でも、あの冷凍車の列を見た人なら、同じものを作ると思う。責められる理由をひとつずつ潰していったら、こういう紙になった。優秀な人が、まじめに作った結果です。

ただ、盾には性質があります。正面からの攻撃をよく防ぐ盾ほど、向こう側の景色が見えない。

EVIDENCE経理部長は、怒鳴りに来なかった

その日のうちに、経理部長が情シスの島に来ました。手に、紙を一枚持っていた。

セッションの有効期限が切れました。
入力内容は保存されていません。もう一度ログインしてください。
ログイン画面へ

3/29 3/30 3/31

図2 経理部長が持ってきた、画面の印刷。余白に赤ペンで日付が3つ。

「毎月こうなんです。言いに来るのも、今日で最後にしようと思って」

小さな声でそれだけ言って、部長は紙を置いて帰っていきました。

次の日、リーダーは経理の島に行ってみました。そこで妙なものに気づきます。

担当者のPCの画面の端に、メモ帳が開いている。聞くと、精算の明細はまずメモ帳に打ち込んで、それからシステムに貼り付けるのだそうです。

「消えるので」

誰が始めたのかは、もう誰も覚えていない。新人も、配属されたその日にこのやり方を教わる。

3月分 交通費
3/04 本社→北関東第二工場 往復 4,280
3/11 本社→得意先(品評会) 1,960
3/18 …

※保存押す前にここにコピーしておくこと!!
図3 経理の担当者のメモ帳。最後の一行は、前任者が書いたもの。
読み解き

障害の記録には一度も出てこないし、情シスの報告書にも載らない。なのに、毎月の失敗をいちばん正確に書きとめていたのは、このメモ帳のほうでした。

人は、困りごとを報告する前に、工夫で黙って吸収してしまう。吸収されたぶんは、数字から消えます。緑の報告書と、画面の端のメモ帳。同じ職場で、同じ3月に、この2つが並んでいた。

BEHIND静かな言葉のうしろでも、子は怖がっていた

うしろを見る

経理部長は怒鳴りませんでした。担当者も「消えるので」としか言わなかった。静かな言葉ほど、うしろは見えにくいものです。2つの席のうしろを見てみます。

子は人ではなく、席につく。言葉がきつくなるのは、うしろの子が何かを怖がっているとき。6体の紹介は地図に

本社
経理部長

「毎月こうなんです。言いに来るのも、今日で最後にしようと思って」

もやすけ未翻訳

怖いのは報告書は全部緑なのに、締めは毎月止まる。何が起きているのか分からないまま、次の月が来ること

本社
経理の担当者

「消えるので」

くうらん懸念

怖いのは打ち込んだ明細が、保存の途中で消えること。消えても、どの報告にも載らないこと

せきのこ ── 席のうしろの、小さな子たち

FIND99.9%を、時間に戻してみる

報告書の数字を、時間に直してみます。

31日 × 24時間 × 0.1% = 約45分

1か月のうち、止まっていてよいのは45分。報告書はこれを守っています。では、その45分はどこにあったのか。障害の記録をめくると、こうでした。

1234567891011 1213141516171819202122 232425262728293031
問題なく使えた日 止まった日(合計およそ45分。いちばん長いのは、締め処理のさなかの25分)
図4 止まった時間は、ほぼすべて月末の3日間に集まっていた。赤ペンの日付と同じ。

平均すれば、ほとんど止まっていない。でも経理部にとっては、止まってほしくない3日間に、まとめて止まっていた。平均という数字は、この「いつ」を消してしまいます。

情シスが数えていたもの

自分たちが作って渡したものシステムが動いていた時間

99.9%。合格。

経理部が数えていたもの

それを使った結果、自分の側に起きたこと締めが期限までに終わったか

今月も終わらなかった。不合格。

図5 同じ3月が、数える場所によって合格にも不合格にもなる。
読み解き

情シスが数えていたのは、自分たちが作って渡したものです。動いているサーバー、動いている精算システム。ITILではこれをアウトプット(output)と呼びます。

経理部が数えていたのは、それを使った結果として、自分の側に起きたこと。締めが期限までに終わったか。入力が消えなかったか。残業せずに帰れたか。こちらがアウトカム(outcome)です。

報告書は全部緑なのに、現場が困っている。そういうとき、たいていこの2つがずれています。盾として作られた報告書は、自分の手元で数えられるアウトプットを数えたがる。アウトカムは相手の側で起きるので、相手に聞かないと数えられないからです。

アウトプットとアウトカム
output / outcome

outputは、活動によって作られ、渡されるもの。outcomeは、そのoutputによって、受け取った側に生まれる結果。

この会社では「動いている精算システム」がoutput、「期限までに終わる締め」がoutcome。緑の報告書は、outputだけを数えていた。

SEATS同じシステムなのに、うれしいことが全員違う

リーダーは、精算システムに関わる人たちに、ひとつだけ聞いて回りました。「このシステムが、どうなっていたらうれしいですか」。

経理部長締めを3営業日で終わらせて、決算の数字を遅れずに役員会に出したいcustomer
経理の担当者保存を押して、消えないこと。それだけですuser
北関東の営業所長精算は月末にまとめてやるもんでしょう。毎回やってたら営業にならないuser
管理本部長この仕組みに年いくら払っていて、それに見合っているのかsponsor
情シス(これまで)システムが止まらないことprovider
図6 情シスの答えだけが、誰の答えとも重なっていなかった。
読み解き

ITILは価値(value)を、何かについて「知覚された便益、有用性、重要性」と説明します。英語では perceived benefits, usefulness and importance。この中で効いているのは perceived、「知覚された」の一語です。

価値は、渡した側の手元にはありません。受け取った人の頭の中にある。だから、受け取る人が5人いれば、価値の中身も5通りになる。図6の答えがばらばらなのは、誰かがわがままを言っているからではありません。座っている席が違うからです。

その席にも名前があります。サービスに何が必要かを決めて、使った結果に責任を持つ人が顧客(customer)。実際に使う人がユーザー(user)。使うための予算を承認する人がスポンサー(sponsor)。経理部長は顧客、経理の担当者と営業所長はユーザー、管理本部長はスポンサーです。欲しいものが席ごとに違うのは、この役割の違いからそのまま出てきます。

価値
value

何かについて知覚された便益・有用性・重要性(the perceived benefits, usefulness and importance of something)。価値があるかどうかを決めるのは、受け取る側の知覚。

稼働率99.9%は、経理部にとって価値ではなかった。価値を決めていたのは、メモ帳に下書きしている担当者の実感だった。

TWIST月末に押し寄せる理由を作ったのは、経理部だった

インフラ担当に記録を見せると、月末の3日を指でなぞって言いました。「最終日ですよ。8つの営業所の全員が、一斉に入れるから」

「ふだんの20倍は来ます。月の途中でぽつぽつ入れてくれれば、こんなに詰まらないのに」

リーダーは、なぜ全員が最終日に入れるのかを調べました。営業本部の古い通達が出てきます。「経費の精算は、月に1回、月末にまとめて提出すること」。

出したのは、10年前の経理部でした。当時はまだ紙の領収書に判子を押していた時代で、毎日ばらばらに出されると経理が回らなかった。それで月1回にまとめてもらった。システムが入ったあとも、通達だけが残りました。

10年前経理部が「精算は月末にまとめて」と通達
システム導入後通達だけが残る
毎月の最終日8営業所が一斉に入力。ふだんの20倍
結果セッション切れで入力が消える。経理はメモ帳で自衛
図7 経理部を苦しめていた行列は、昔の経理部が自分を守るために作ったルールから始まっていた。
読み解き

情シスの盾と、同じ形をしています。昔の経理部が自分たちを守るために作ったルールが、いまの経理部を苦しめている。悪い人は、どこにもいません。

もうひとつ。「締めが期限までに終わる」という結果は、情シスだけでは作れない。サーバーをいくら強くしても、900人が最終日に押し寄せれば詰まります。経理部だけでも作れない。入力を前倒ししても、システムが弱ければやっぱり詰まる。

ITILは、価値は提供する側が一方的に届けるものではなく、提供する側と受け取る側が一緒に作るものだと考えます。これを価値の共創(value co-creation)と呼びます。

情シス止まらないシステム
消えない入力画面
締めが
期限までに
終わる
(ここで初めて価値になる)
経理部・営業所入力のタイミング
困りごとを早めに伝える
図8 価値は、渡す側と受け取る側の両方が動いたところで生まれる。

CHOICEリーダーがやったこと。うまくいかなかったこと

リーダーは、月次報告に一行だけ足しました。「月末3営業日、締めは止まらずに終わったか」。この行の判定は、情シスではなく経理部長に付けてもらうことにした。

それから営業本部に、精算を週1回にできないかと相談しました。営業本部長の返事は短いものでした。「営業に余計な手間を増やすな」。

だから4月の締めも、やっぱり詰まりました。経理の担当者の画面の端には、今月もメモ帳が開いていた。月次報告に、6年ぶりの赤が出ます。

情シス月次報告|4月
経費精算システムの稼働率99.9% 正常
重大障害0件 正常
問い合わせ対応件数298件 正常
バックアップの成功率100% 正常
月末3営業日、締めは止まらずに終わったか
判定:経理部長
いいえ 未達
図9 4月の月次報告。最後の一行だけが、相手の側を数えている。

課長は渋い顔をしました。「赤を出すと、役員会で何か言われるぞ」。

経理部長は、赤い行をしばらく見ていました。「赤ですね」とだけ言って、紙を二つに折り、胸ポケットに入れた。部長が月次報告を持ち帰ったのは、6年間で初めてだったそうです。

読み解き

問題は、何ひとつ解決していません。報告書の数字だけを見れば、6年続いた全部緑の記録が途切れたぶん、むしろ悪くなったとさえ言える。ただ、盾を下ろせば、最初に見えるのは赤です。赤が出たのは、ようやく相手の側を数えはじめたからでした。

RELIEF子はまだ笑わない。それでも、顔を上げた

しくみを置く

4月の締めは、やっぱり詰まりました。だからこの回の子たちは、まだ笑っていません。それでも、怖がっていたものに数字と名前が付いて、うつむくのはやめました。顔を上げさせたしくみには、ITILの名前があります。

経理部長のうしろのもやすけ

怖がっていたこと報告書は全部緑なのに、締めは毎月止まる。何が起きているのか分からないまま、次の月が来ること

No.6|ITIL 4の分類:一般管理
測定および報告
Measurement and reporting
目的
適切なデータを集め、文脈の中で正しく評価して、判断の不確かさを減らす
この話では
数字を「誰が、何を判断するために見るのか」から選び直した。赤が出ても、その赤が判断の材料になる
顔を上げたのは
月次報告に足した一行。「月末3営業日、締めは止まらずに終わったか」を、自分の目で判定できる
経理の担当者のうしろのくうらん

怖がっていたこと打ち込んだ明細が、保存の途中で消えること。消えても、どの報告にも載らないこと

No.15|ITIL 4の分類:サービス管理
可用性管理
Availability management
目的
顧客と利用者のニーズを満たす、合意した水準の可用性をサービスに保たせる
この話では
99.9%を時間に戻すと、止まった時間は締めの3日に集まっていた。可用性は、合意した「いつ」まで含めて決める。平均の数字だけでは足りない
顔を上げたのは
止まった45分が「いつ」だったのかを、情シスが見に来たこと

体験稼働率を、止まっている時間に戻してみる

ひと月(30日)で止まってよい時間:

2つとも、ITILがプラクティスと呼ぶしくみのひとつです。人・手順・道具・情報・外の会社をまとめたもので、誰か一人の頑張りとは違い、席に残ります。このあとの話で、子はもう少し先まで落ち着いていきます。

番号と分類はITIL 4の並べ方です。ITIL 5の試験で押さえるのは「プラクティス=資源のまとまり」と2つのグループまで。

せきのこ ── 席のうしろの、小さな子たち

SHIFT正解が、入れ替わる

4月の報告を出したあと、リーダーは一人で去年の月次報告を見返していました。

去年まで、自分もこの紙の数字を貼る側にいた。緑が並ぶと、ほっとした。経理の画面の端にメモ帳が開いていることには、5年間、一度も気づかなかった。

読み解き

緑が並ぶと、ほっとする。その感覚は、6年前の夏から受け継がれてきたものです。あのあと半年、情シスは役員会で責められ続けた。責められ続けるチームは、仕事になりません。だから、責められない数字を揃えた。あの条件の中では、それがいちばん正しい答えでした。

変わったのは条件のほうです。6年前、報告書を読んでいたのは、障害を問いただす役員会でした。いま困っているのは、締めの3日間を抱えた経理部です。同じ答えでも、条件が変われば古くなる。ITILを入れるというのは、古くなった正解を、新しい正解に入れ替えることです。

この回で入れ替わった正解
正解
今まで責められない数字を、自分たちの手元で揃える
→
これから相手の側で起きた結果を、相手と一緒に数える
価値観
今まで赤を出さないことが、チームを守ること
→
これから赤を早く見せることが、チームを守ること
ITILの言葉
今までアウトプット(output)を数える
→
これからアウトカム(outcome)と、受け取る側の価値(value)を数える

メンバーの仕事で変わること

  • 報告の数字を貼る前に、使っている部署に一行だけ聞きに行く
  • 「正常に稼働しています」と返す前に、相手の側で何が起きているかを聞く
  • 赤い行が出ても、消さずに報告に載せる

リーダーが先に約束すること

  • 赤い行を、誰かを責める材料には使わない
  • 赤を見つけて載せたことを、ちゃんと仕事として数える

手間は少し増えます。その代わり、メモ帳で黙って自衛している人が、社内から一人ずつ減っていく。

残った問い メモ帳のことをもっと知りたくて、リーダーは経理部からの問い合わせの記録を探しました。見つかりません。問い合わせは、7人それぞれの個別チャットとメールに、ばらばらに届いていたのです。誰が、どの依頼を、何に基づいて片付けたのか。それも、どこにも残っていませんでした。

この回で付いた名前

アウトプットoutput活動によって作られ、渡されるもの。例:動いている精算システム、月次報告
アウトカムoutcomeoutputによって、受け取った側に生まれる結果。例:締めが期限までに終わる
価値value知覚された便益・有用性・重要性(perceived benefits, usefulness and importance)。受け取る側が決める
価値の共創value co-creation価値は、提供する側と受け取る側が一緒に作る
顧客customerサービスに必要なことを決め、利用の結果に責任を持つ。例:経理部長
ユーザーuserサービスを実際に使う。例:経理の担当者、営業所長
スポンサーsponsorサービスを使うための予算を承認する。例:管理本部長

もっと詳しく:ITIL 5 解説ガイド(領域1 重要な用語・価値の共創・サービス関係)|ITILを理解するための解説 02 価値の考え方

CHECK確かめる

Q1. 4月の月次報告に、リーダーは「月末3営業日、締めは止まらずに終わったか」という行を足し、その判定を経理部長に付けてもらうことにした。この行が数えているものとして、もっとも適切なものはどれか。

  1. A情シスが作って渡したアウトプット output
  2. B経理部の側に生まれたアウトカム outcome
  3. C精算システムにかかるコスト cost
  4. D情シスが片付けた仕事の量
答えを開く

B。稼働率99.9%は、動いている精算システムというアウトプットの側の数字です。締めが期限までに終わったかどうかは、受け取った経理部の側に起きた結果なので、アウトカムにあたります。判定を経理部長に頼んだのは、価値があるかどうかを決めるのが受け取る側の知覚(perceived)だからです。

Q2. インフラ担当は「月の途中でぽつぽつ入れてくれれば、こんなに詰まらないのに」と言った。「締めが期限までに終わる」という結果について、ITILの考え方にもっとも合うものはどれか。

  1. A情シスがサーバーを強くすれば、情シスだけで実現できる
  2. B月末にまとめて入力するのは経理部の都合なので、経理部だけで解決すべきだ
  3. C情シスと、経理部・営業所の両方が動いたときに、初めて価値になる
  4. D価値の大きさは、情シスがかけた費用で決まる
答えを開く

C。価値は、提供する側と受け取る側が一緒に作るものと考えます。これが価値の共創(value co-creation)です。Aは、提供者が一方的に価値を届けるという古い見方です。Dのように提供者のコストで価値を測るのも誤りで、価値を判断するのは受け取る側です。