こんにちは。ついにやってまいりました。最終回。KPI/SLA/SLOの関係性を考えると最後は経営に行き着く。という話。これを直感的に理解できる部分もあるのですが、その直感をちゃんと説明します。
まず今までの図を再度更新し、KGI/KPI/SLA/SLOの関係性を定義し直しましょう。(図1: KGI〜SLOの全体(更新版))
定性的な経営理念や経営目標からKGIを起こします。このKGIは、顧客組織（いわゆるユーザ企業）とサービス提供組織（いわゆるベンダ）それぞれのKGIになります。強引に言えばこれ、各事業体の経営計画や目標利益になります。
そのKGIに対して、各組織を運営する長が咀嚼した結果、どのように組織を運営するのか、その組織の目標を何とするかを合わせて、「サービスとしてのKPI」を統合して定めます。そのサービスとしてのKPIに関して全責任を負うのは、「サービス構成組織」(注: 当ブログのみの用語)です。そのサービス構成組織が定めたKPIを分解することで、サービスとしてのSLAが設計されます。そして、既存のツールから定義されたSLOをそのSLAを達成する具体的な目標として紐付け、可視化できるようにする。その時、可視化できないSLAがあったとしても、KPIを説明できるようであれば、一時的には放置する。
今まで説明してきたことは上記の通りです。
では、なぜ、これが経営なのでしょうか？そもそも経営とは何なのでしょうか？手元の辞書を引くと、次の記載がありました。「事業目的を達成するために、継続的・計画的に意思決定を行って実行に移し、事業を管理・遂行すること」
この事業がいわゆるサービスな訳です。この図にあるサービス構成組織とは、簡単に言えば、そのサービスを事業とみなし、目的(関連事業体の経営目標やKGI)を達成するために、継続的・計画的に意思決定を行って実行に移し、サービスを管理・遂行することなのです。
サービス管理と経営、一緒ですよね？
つまり、SLAやSLOを定義することは、サービスの経営計画を決めること。その経営目標を達成するためにKPIを要素分解し個別具体的な目標値を設定し運営することなのです。
そう理解して再度図を眺めると一つのことが理解できると思います。KGI/KPIがあり、その上でSLA /SLOを定義する理由。それは、複数の事業体が協働するが故に起きることなのだと。ちょっと極論ですが、一つの事業体、つまり、完全に統一された一つの会社で全てが完結するのであれば、実はKGIは一つしかなく、結果、サービスとしてのKPIも一つないしはかなり小さい幅で統一できます。つまり、KPIについて幅を持って定義する必要性はありません。しかし、現在において、サービス提供企業はますます増え、コラボレーションする、協働する、サービスを利用するなどの関係性が高まっています。アレな話ですが、パブリッククラウドを一切使っていない一定規模以上の企業はいないでしょう。*1
これの意味するところ、サービス構成組織は、自分たちのサービスの内容を把握し、今後の変化に対応するために、KGIを取得していかねばならない。これはつまり、こういうことです。
例えば、Microsoft社が、ライセンス料を値上げするのは、彼らのKGIが変化したからです。KGIが変化し、クライアント先に対する重みづけ(……という言い方はあれかな？優先度というべきか、、、)が変化したためです。それに対応するために、自分たちのサービスのKPIを変える。そういうことなのです。*2
サービスとしてのKPIは、結局のところ、サービスを事業と捉えた際、サービス提供組織のKGIをまとめて、自分たち（サービス構成組織）のKGIとして定義する行為だということです。したがって、サービスとしてのKPIを定義し責任を負うサービス構成組織の長になる人物とは、サービスの経営者になります。では、このサービス構成組織の長は誰がなるべきなのでしょうか？正直に申し上げます。「わかりません」。これは、「解がない」のではなく、「場合による」からです。このサービスに対して最も責任を負うという意味では、「発起人」に相当する方がなるべきなのでしょうが、そもそもこの発起人を誰がするべきかがわからないのです。いくつか事例を考えてみましょう。
標準PCサービス(社員共通サービス)の場合、経営者として相応しいのは、いわゆる情報システム部門と言えるかもしれません。なぜなら、事業部門から見ると、各種ガバナンスにより定義された安心安全なPCで業務を遂行したいのであって、これら標準PCサービスでなし得たいことは自分たち固有の要件としてありません。この標準PCサービスを構成する各種リソースを提供するベンダは、このサービスを運営しなければならないわけではなく、その提供する各種リソースを提供することによる対価を得ることが目標です。したがって、サプライヤが相応しく、経営者ではありません。この標準PCサービスの共通的な目標を定義できる存在としては情報システム部門が相応しいと言えます。
では、特殊PCサービス(部門固有サービス)の場合、経営者として相応しいのは誰でしょうか？情シスでしょうか？その要件をもつ事業部門でしょうか？
情シスとしては、共通PCには共通的な目標を立てる必要がありますが、部門固有PCについては、自分達のプロセスを変えずにサプライヤとして関与するということもできます。逆に、自分たちにとって追加の資金を得る、または他のKGIで未達となる目標の穴埋めとしてイニシアチブを取り、プロセスを変えて自分達がPCサービスの経営者として追加費用を頂いて管理するという方法もありうります。事業部門とて同様です。自分達の目標にふさわしいPCを調達し自分達で管理運営する（自分達が経営者となる）という方法もありますし、固有PCのガバナンスを含めて面倒を見てもらうことで追加の人員を雇う必要がないと考え、追加の費用を払って特殊なサービス形態を持って自分達が顧客として立つこともできます。
お気づきでしょうか？ITIL4の4つの側面、「組織と人材」「パートナとサプライヤ」「プロセスとバリューストリーム」に言及しています。さらに言えば、6つの外部要因にも言及していますよね。
このように、それぞれの4つの側面を考えた際最も自分達の戦略にとってふさわしい方法を選択する必要があるため「場合による」のです。裏返すと、ITIL4の4つの側面、7つの原則、6つの外部要因で状況を整理し分析できる人を懐刀に置いた人がサービスの経営者にふさわしいのかもしれません。
さて、四回わたって解説してまいりました。SLA/SLO。何らかヒントになることはあったでしょうか？チケット化することは大切なのですが、チケットに全ての情報をためることは無謀です。（現場が疲弊します）第三回で説明したとおり、7つの原則に従いKGIからSLOまで落とすことも大切ですが、今回説明したとおり4つの側面に従い自分達の戦略を決める必要もあります。ITIL4のフレームワークを使いどんなSLA/SLOを決めてゆくべきか、ITIL4を羅針盤として、SLAとそれを支えるSLOを決めてゆく。テーラーメイド化されたITSMを作り上げ、サービスを経営していって欲しいと思います。
*1:というか、中小零細企業こそパブリッククラウドは使って欲しいのですけど。というか、実態としては使っているのですけど。例えば、弥生会計クラウド（ソリューション）とか。ああいうものって、実態としてはAWSとかOCIとか使ってると思うのですよ。
*2:ちょっと例えてみましょう。こういうことです。
社員向けの共通サービス(MS365)があったとします。この時、KGIとして定めるべきは、自社のKGIを分解し自分の組織の目標として定義したもの、とともに、MS365を提供するMicrosoft社のKGI、またはそのKGIに基づいた自社への目標を理解しておく。これ、ものすごいことを書いているように見えますが、みなさん来年度予算を作るときに普段やってらっしゃいますよね。ですので、意識を変えるのです。来年度の予算だてという行為そのものがこのように各社のKGIをすり合わせて「共通サービスのKPI」に落とし込む意識を持つ。これを思わずに。予算申請をしても業務は完了するのですが、仕事は完了しません。KPIとして定めきっていないため、変化に対応できなくなるでしょう。
