なにしてみよっか

サービスってなんだろな?を細々と。基本マニアックなネタが多いです。トヨタ生産方式を信奉してます。某製造業の営業と社内SEをやってました。

KPI/SLA/SLOの関係性を考える 3/4-サービスとしてのSLA/SLO-

こんにちは。本日は続いての第三回。サービスとしてのSLA/SLOを考えましょう。まずはお馴染みの再掲。

図1:理想的なKPI/SLA/SLO

今回は、この図の右側、「対象サービスにおけるSLA/SLOの決め方」です。断っておきますが、本日論じるのは、SLA/SLOの個別具体なパラメータとして何が適切かということを示しません。従って、SLAとは稼働率XX%になっているべきで━━━━というようなことを記載いたしません。(ただし、結果的に稼働率SLAになる可能性は否定しません)

本日論じるのは、「SLA/SLOはどうやって決めていくのか」というプロセスを論じます。そのプロセスの元になっている背景や前提を理解いただく必要があり、そのために第二回がありました。

では、始めます。

前回までで、サービスとしてのKPIを定めていくプロセスを論じました。関係する最大組織(ユーザ企業、ベンダ企業)の経営理念やKGIを把握し、最大組織の中で関連する組織(要するに部・室)のKPIを把握する。その上で最大組織の中で関連する組織の長(簡単に言えば、各部長)がそれら経営理念やKGIをどのように捉えて組織を運営していっているのかをインタビューし「真の関連組織のKPI」を把握する。その上でそれらをまとめて、「サービスとしてのKPI」を導き出す。ここまでを説明してきました。

さて、そうやって導かれたサービスとしてのKPIを今度はSLAやSLOという個別具体的な数字に落とし込んでいかねばならない。その方法、つまりは方程式を論じていきましょう。

おっとその前に、今までどの教科書にも定義されていない新たな言葉を定義させてください。

「サービス構成組織」=顧客組織とサービス提供組織(要するにベンダー等)の集合体

サービスを提供するために各組織のKPIを持ち寄り、最終的にサービスとしてのKPIを定めましたね?それの成果の責任や説明責任を負う単位です。いわば「サービスとしてのKPI」を定めた張本人(またはそれに準じる組織)です。ここで勘違いして欲しくないのは、サービス構成組織のサービスと、サービス提供組織のサービスは違う「サービス」であるということです。

サービス構成組織のサービスは、「サービスとしてのKPI」になります。それに対し、

サービス提供組織のサービスは、「顧客組織に提供するサービス」を指しています。

これは、ITIL4で言うサービス関係を理解していないと勘違いしやすいかもしれません。本論とは異なりますので、こちらは脚注に記載します。*1

さて、サービスとしてのKPIが定まりました。そこからSLAに落とさねばなりません。そして、SLAからさらにSLOを考えねばなりません。この関係を表したものが図2:KPI/SLA/SLOです。

図2:KPI/SLA/SLO

では、ここで質問です。この時KPIにはどのような業績の指標が書かれているべきでしょうか?

筆者の場合であれば、下記のように考えます。

  • 当該サービスが標準PCサービス(いわゆる共通系のサービス)の場合:運用費用が1台あたりXX円以内であること、運用費用がXXX千円以内であること
  • 当該サービスが人事評価支援サービス(例えばカオナビとか、HRBrainとか)の場合:運用費用が管理職一人当たりXX円以下であること、管理職の人事評価業務に費やした時間がXX時間/年削減されること

お気づきの方もいるかもしれませんが、要するに期待効果なんですね。ちょっと逆説的ですが、KGIと経営理念に基づき組織を運営している長のインタビューを通して、それらを実現させるための具体的な目標値、それがKPIになります。なので、ふわっとした定性的な概念や状態を示すのは、経営理念とKGIまでで、それをどう解釈しどのような数値にするのか(KPIとして定めるのか)は、長が意識し、それを運営者がダイレクションし、運営者とサービス提供組織が決めていく。その結果、サービスとしてのKPIが決まる。

では、このKPIをどのようにSLAに落とし込むのか。このKPIを分解するんです。そして、ここも大切なのですが、SLOからSLAに向かうのです。(図3:KPI/SLA/SLOの構成)

図3:KPI/SLA/SLOの構成

KPIはSLAに分解されるのですが、SLOはSLAから落とすのではなく、SLOからSLAに向かって紐づけられます。

結果的にどのSLOとも紐づかないSLAが存在する可能性は出てきますが、それは受容します(左から3番目のSLA)。ただし、全てのKPIは何らかのSLOとリンクしている状態にしなければいけません。つまり、可視化の確度が低いのは受容しても、可視化できない状態はダメです。

なぜ、SLOに紐づかないSLAを許容するかというと、7つの原則*2を意味します。特に「3.フィードバックを元に反復して進化する」「5.包括的に考えて取り組む」に従うためです。図3をよく見てください。確かにSLOに紐づかないSLAが1つあります。しかそのSLAの元となるKPIは別のSLAでどの程度の確度になるかは分かりませんが、ある程度の可視化はできる。そのような構成になっています。つまり、全てのKPIは今のままでも何らか情報を取得し把握することはできる。もし仮に、このSL Aに紐づく目標を作り定義しようとすると、運用現場の負荷が増し、運用手順が増えたり、記録のための仕事(もはやブルシットジョブ)を増やすことになりかねない。それは、果たして本当に必要なものなのでしょうか。今のままでも十分FBが得られ、反復できるのであれば、無理やりSLOを作るのではなく、このSLAが足りないKPIについては参考情報、または(他の2つに比べ)確度の低いKPIとして扱った方が全体的な負荷がとれた運用体制となります。

さて、ここで勘の良い方は気がついたと思います。SLOとは、運用管理ツール(SNOWとかRedmineとかJiraとか)や監視ツール(Zabbixとか)で取れるデータなのです。現状の取れるデータから始め、FBをえて、反復して、その上で、今取れていないSLAがやはり必要となれば、その(SLO取得のためにツール構築を行うという投資の)正当性を示し、K GI達成のための見通しを示し、そこからSLAの根拠となるツールを構築するのです。それまでは放っておいていいのです。

さて、これで、一度左側と右側、それぞれについて解説してまいりました。一度まとめます。(図4: KGI〜SLOの全体の構成)

図4:KGI〜SLOの全体の構成

前回お示しした通り、経営理念やKGIを道具として、サービス提供組織ごとのKPIを導き出します。その上で、サービス構成組織として当該サービスに求められるKPIを導き出します。

今回ご説明した通り、サービス構成組織のKPIをSLAレベルに分解します。そして、今手元にある道具から導けるデータをSLOとしてSLAに紐づけます。最後に、手元にある道具から定義したSLOが、サービス構成組織として当該サービスに求められるKPIに紐づいているかどうかを確認します。この際、SLOに紐づかないKPIがあった場合は、対処しなければいけません。しかし、全てのKPIが何らかのSLOに紐づいているのであれば、中に浮いたSLAについては一旦横に置いておいて構いません。

 

いかがでしたでしょうか?これで、KPI〜SLOに至るまでの全体の関係性に関しては終わりとなります。次回最終回、第四回:KPI/SLA/SLOの関係性を考える4/4 -KPI/SLA /SLOを定義することは「経営」である-に続きたいと思います。

*1:例えば、ここに、企業標準PCを提供し、PCを維持し、サポートまでを行う「標準PCサービス」があったとしましょう。

この場合、サービス構成組織の提供するサービスは「標準PCサービス」になります。対して、サービス提供組織のサービスは、この「標準PCサービス」を構成する各種サービス、つまり「PC購買サービス」「PCキッティングサービス」「PCサポートサービス」などの各種サービスを提供するベンダ、ないしは組織になります。よってもって愚直に記載しますと、「(カタログ化された)サービス(を)構成(する)組織」が「サービス構成組織」。「(カタログ化されたサービスを提供するためのリソースとなる)サービス(を)提供(する)組織」が「サービス提供組織」となります。そしてこのような書き方をするのは、ITI4の一般的マネジメントプラクティスの「ポートフォリオ管理プラクティス」並びにサービスマネジメントラクティスの「サービスカタログ管理」を参照しているためです。サービス提供組織をリソース提供組織としても良かったのですが、ITIL4の概念として「サービス関係」がうたわれており、そもそもベンダ組織から見れば、顧客組織をユーザとして提供しているサービスです。捉え方の違いにすぎません。顧客から見ればリソース、ベンダから見ればサービス。視点の違いをどう入れ込むかに苦心し、最終的に「サービス」の捉え方の違いを説明し全体整合性をとるべきであると結論づけました。結果わかりにくくなるというか混乱を招いている気もしないではありません

*2:7つの原則は「1.価値に着目する」「2.現状から始める」「3.フィードバックを基に反復して進化する」「4.協働し可視性を高める」「5.包括的に考えて取り組む」「6.シンプルで実践的にする」「7.最適化して自動化する」です。この“中に浮いたSLA”問題は、確かに35で整理できるのですがそれを補強する素材として、126そして、ツールに対して投資するという部分は7で説明できますよね。やはり7つの原則は「原則」なのです。