どうもこんにちは。さて、第二回。組織毎のKPIのアラインについて考えましょう。
まず再掲
前回の図ですが、今回はこの左側、つまり、KPIをすり合わせる計算式について考えましょう。
早速ですが、この図を見て、「わかりました！では、自社のKPIと顧客のKPIを足せばいいんすね？」と延髄反射で顧客組織に突撃はしないでください。
おそらく「KPI教えてください」と言ったとして、そして顧客組織にKPIが実際にあったとして、それは、「擦り合わせなければいけないKPI」ではない可能性が高いです。そう思う理由は脚注に書きます。*1
筆者ならどうするか。まずは、抽象的（教科書的な汎用表現として）に。
先ほど申し上げましたように現行のKPIを教科書的に定めたKPIだと思って突き進むのは得策とは言えません。疑ってかかる必要があります。教科書的なKPIとは「サービス提供組織、または顧客組織の最終目標を達成するために達成しなければならない主要な業績の目標」。それに相当する本質的なKPIを求める必要があります。
そのためには、それぞれの組織の最終目標について理解しておかねばなりません。それは経営理念とKGIになります。ここが「KPIの背景」です。そこを収集し明文化する。それが中核を担います。
では経営理念とKGIはどのように収集できるのか。経営理念は簡単ですね。Webサイトに大体書いてある。そうでなくともIRサイトや株主総会資料を見れば大体書いてある。あとは肉付けとして、その「経営理念」をステークホルダーがどう解釈しているのかをインタビューすれば良い。
ここ、実は大事です。
経営理念だけを引っ張ってきて「経営理念がこうなのだから、ゴールはこうでしょう！」と顧客に発表するのは悪手です。「正論パンチ」と呼びます。経営理念を中心にしつつも、それぞれの組織においてはどのように解釈されているのか、それら経営理念を人が解釈し人が組織を運営します。従って、対象組織に属していない人間が、Webや総会資料上に書かれている経営理念のみを読み解いてあなた方の経営理念はこうですよね？だからKGIはこうですよね？というのは、「越権行為」に他なりませんし、人によっては無礼だと感じる人もいるかもしれません。（逆に当たれば、「良くぞそこまで考え抜いてくれた」になるかもしれませんけど、それってギャンブルではないですかねぇ）なお、これはベンダー側にも言えることです。
つまり、KPIをすり合わせる、という行為は、顧客組織とサービス提供側組織それぞれの経営理念とKGIとそれを補強するために管理単位の長と会話し「このサービスにおけるKPI」を決める。こういうことなのです。（図2：KGIとKPIの関係性）
もう少し具体的にご案内します。事例として、
- 2つのシステムで構成される1つのサービスの開発と運用を決めるにあたり
- 「ユーザ側企業」と「ベンダ側企業」の2社があり
- ユーザ側には「事業部門」「情報システム部門」、ベンダ側には「開発部門」「運用部門」の4組織がある
- 筆者はコンサルタントとして「ユーザ側情報システム部門」に雇われている
という前提で考えてみましょう。
これを示しますと図3:KGIとKPIの関係性（具体事例）になります。
コンサルタントである筆者は、ユーザ側情報システム部門として自組織（情シス）のKGIとKPIの粒度と内容を示し、他３部門に対して問いかけます。「各組織のKGIとKPIを教えてください。粒度を揃え、一度整理いたします」
そうして集まった各組織のKGIとKPIを情シスのKGIやSLAの粒度に合わせて修正するよう修正作業を行いつつ、各組織の長にインタビューします。インタビュー内容は1点。「あなたは、自組織がどうなることを期待しますか？」です。長は、いわば「自社（≠自組織）の経営目標やKGIを咀嚼し自組織の人員で達成することを考える」役割です。明文化されないKGIやKPIに対してもっとも明確な解を持っている存在です。
そうして、1つのサービスを提供する責任を負う（おそらくは）事業部門担当者に説明します。「このサービスは、XXXという目的を果たすために今回構成され、4組織が集います。それらサービスとサービスを構成する組織とあなた（事業部門のサービス担当責任者）が達成するKPIは次のとおりと定義したいと思います。……」
いかがでしょうか？イメージつきますでしょうか？各最大管理組織（企業）の単位で目標とKGIがあり、それらに基づいて、部門毎にKPIがある。この関係性を理解した上で、コンサルタントは表現しきれていないKPIを上位概念である経営目標やKGIを道具にして組織の長や担当者へのインタビューを通して設計し、「サービスとしてのKPI」として定義する。正確にはこのサービスとしてのKPIは仮であり、この後実際のサービスイン後に修正していかねばならないのですが。
さて、概念と具体とを行き来し、KPIのすり合わせ方について論じてまいりました。
これで、左側はできた。次週、右側はどう作り込むのか。そちらについて検討を深めたいと思います。
*1:筆者の過去の経験則ですが、何らかのシステム開発運用プロジェクトが始まり、キックオフミーティングが開催されたとして、その場においては、これらは何ら決まっていません。実際、筆者はいわゆるユーザ側、ベンダ側それぞれの立場を両方経験してきていますが、これらが決まっていて始まったプロジェクトはありませんでした。正確には、何となく決まっている状態で始まった、と言っていいと思います。「現行踏襲」という便利な言葉によって。今まではそれで良かったのです。なぜなら、プロジェクトのスポンサーに相当する人たちがベンダ側、ユーザ側、さらに言えばシステムそのものも「全く同一の組織内にいた」ので。極端な言い方をすれば、KPIは「実質的に内製化」されていたのです。
考えてみてください。情シス子会社を作り経営のスリム化を図ってきた過去の時代を。情シス子会社化する前は、同じ組織同じ会社の仲間でしたね。つまり同じ組織にいて、同じ目標に向かい、同じ指標で管理されてきている。そもそもKPIがズレるわけないのです。そして、その時代にできたシステムを更改する。さらにその時代を共に過ごしてきた仲間が再び集い、予算編成権を持って新しいシステムを作る。現行踏襲でも「いい塩梅」に妥当なラインを見つけることができる。そういう構造で、「現行踏襲」を可能にしていた。しかし今はどうでしょうか？そういったいわば「同じ釜の飯を食った」人たちのナレッジや暗黙知は無くなり、労働供給が制約条件になり、一社を勤め上げるという仕組みも徐々に崩壊しつつある。さらに開発チームと運用チームが分かれていたり、そもそも運用は全く関係ない組織（海外含む）にお願いをする時代。つまり、システムやサービスを作る組織が専門化され、細分化し、参加する組織が増え、それぞれがバラバラな目標を掲げつつある。
そういった暗黙知が失われていく要素が増えていっている現在において、現行のSLAやSLOだけを追求しても表現されなかったKPIとそのKPIの背景により「このサービスにとって本来あるべきSLA」に辿り着きようがないのです。今までは、「システム単体」のKPIやSLA /SLOに特化し、同じ釜の飯を食った人たちによりそこに足りない部分、または暗黙知として言語化されないKPIが立っていた。
しかし今は「システムを含むサービス」としての成立が求められる時代にあって、言語化されてこなかったKPIを含めて評価を求められる時代になった。さらに、KPIやSLA /SLOといった「指標」を教科書的に理解し使う組織と協業する（海外の運用パートナーに委託するとか、暗黙知を共有していないベンダーと一緒にシステムを作る）という時代にあって、今までと同じ考え方でKPIを定義し、SLAやSLOを決めても「顧客が本当に欲しかった（笑）」SLAにたどり着きません。したがって、延髄反射的に「KPIを教えてください！」と突撃することそのものに意味がないのです。
