マネジメントの”キホンのキ” その２
〜もしも（サービス）マネジメントをしなかったら？〜
「マネジメントの”キホンのキ”その１」では、インシデント管理の具体例で「なぜマネジメントをするのか？」を考えました。しかし、マネジメントおよび、定義と測定の関係については深堀せずに自明のものとしていました。今回はここを掘り下げてみましょう。
「マネジメント」をしない場合と過剰な対応をした場合について、まずは身近な例で考える
今回もまずはドラッカーの格言を引用します。
【マネジメントに関する重要な格言】
“「定義」できなければ「測定」できない
「測定」できなければ「コントロール」できない
「コントロール」できなければ「マネジメント」できない “
なぜ？となってしまう本稿の筆者（以下「筆者」）自身のために、日々取り組んでいる自分の健康に関するマネジメントに置き換えてみました。
【筆者の隠れ貧血マネジメント】
血中ヘモグロビン濃度が12.0～16.0 g/dlであれば基準値範囲と定義されている。
採血結果で測定値と基準値を比較し、範囲外の場合はコントロールする。
鉄分の摂取量をコントロールして、貧血による諸症状を防止する。
筆者にとってのこのマネジメントの成果は「日々健康にご機嫌ライフを送ること」なのですが、その敵である貧血の諸症状はギリギリまで姿を現しません。貧血予防をマネジメントの達成目標とした時に、日常生活の中で可能な対応は鉄分の摂取量の調整（コントロール）であり、その適量を知るには血中ヘモグロビン値を把握（測定）し、健康の目安とされる基準値（定義）と比較する必要があります。
筆者の隠れ貧血マネジメントは、会社の健康診断や通院を予約(Plan)し、採血(Do)し、結果を見て(Check)、測定値が基準値範囲の下限を下回った場合には通院や投薬などの是正処置を講じる(Act)、というPDCAサイクルを回し続けること、と言えます。貧血の自覚症状がない筆者の主観はあてになりませんので、筆者にとってのこのマネジメントの欠如は、（医療に関わる情報を発信することが本稿の目的ではないので詳細は割愛しますが）健康を損なうことによるご機嫌ライフの危機を招きます。
とはいえ、血中ヘモグロビン値は過剰でも害がありますので、リスクを大きく見過ぎるあまりに鉄剤を必要以上に飲むのは悪手です。定期的に客観的な測定結果を基準値範囲に照らしコントロールできることではじめて、適切な隠れ貧血マネジメントが可能になります。過ぎたるは猶及ばざるが如し。
サービスマネジメントで考える、マネジメントの欠如と存在意義
では、サービスマネジメントに戻りましょう。なぜ管理プロセスやプロセス評価指標、サービスレベル指標（Service Level Indicator、略してSLI）を定義し、サービスレベル目標（Service Level Objective、略してSLO）やプロセス測定をするのでしょうか。
事業成果を下支えする要素すなわち評価指標と、その達成度合いを示す測定指標を可視化し、事業部門とIT部門が共通認識をもって客観的なデータに基づいて、サービスについての判断をするためです。
ここでは品質と変更管理で思考してみます。
まずはマネジメントの欠如です。サービスの品質管理が不十分で、品質について定義および測定されていなければ、品質に対する要求事項として本来サービスに備わっていなければならない機能もしくは非機能が満たされているかどうかさえ分からない状況になります。障害の発生を過度に恐れ保守的になり新しいサービスの展開や既存サービスの改善を積極的に進められないとなっては、競合との競争において不利になりえます。
では有効なマネジメントが存在する場合はどうでしょうか？ サービスレベル指標（SLI）とサービスレベル目標（SLO）が定義され、測定が可能になり、サービスレベルを合意できるようになります。
【とあるサービスのサービスマネジメント
～変更管理とリリースおよび展開管理の例～】
SLIを「合意済みサービス提供時間内」における「実際にサービスが提供できた時間」の割合、SLOを99.5%と定義する。
ヘルスチェック応答を集計して得た測定値とSLOを比較し、範囲外の場合はエラーバジェットの残量に応じて、リリース可否をコントロールし、ユーザー満足度を維持する。
では、コントロールの基準となるエラーバジェット（サービスレベルが損なわれた状態の許容範囲）の算出で使われるSLIやSLOはどのように決定すればよいのでしょうか。ユーザーが一番にこのサービスに求めることが、サービスが約束通りに利用可能なことである場合、それを端的に示すSLIとして可用性指標を選びます。そして、ユーザー満足度というのは主観的ではありますが、ユーザー満足をもたらすと考えられる程度のサービス可用性を客観的な数値で表したものがSLOとなります。
エラーの発生が十分にエラーバジェット内に収まっていること(Plan)が、計測(Do)により確認(Check)できれば、事業部門はサービス戦略上重要な新機能をリリースするという判断ができます。一方、エラーバジェットを超過していることが判明した場合は、失敗がユーザー満足度の低下や信頼の喪失につながりかねない挑戦的な新機能のリリースは延期し、既存バグの修正を優先して品質改善に注力する（Act）という選択をIT部門がすることも可能になります。
時間が経過しエラーバジェットが回復したならば、新機能のリリースが可能になります。このPDCAサイクルを継続するためには、SLIとSLOを合意し、可用性を自動計測し、ダッシュボードでエラーバジェットを確認し、明確なリリース判定基準が事業側とIT側で合意されている必要があります。
この例であれば、エラーバジェットが0.4%残されており、新機能の変更に起因する障害が発生した場合のリカバリ所要時間がバジェット内に十分に止まると予測されるならリリースは実行され、そうでない場合にはリリースが延期になる可能性が高くなります。既にエラーバジェットが残されていない場合には新機能のリリースはエラーバジェットの回復まで停止され、障害対応や品質改善のためのリリースのみが許可されます。
この例のように、サービスが提供する価値を代表する計測可能な指標を定義して測定し、エラーバジェットを確認し、新機能のリリースという攻めと守りのアクションのバランスをコントロールし、品質をマネジメントし、なおかつ仕組みとして継続すること。これにより事業にITが提供するべき価値を常に最適化することが、サービスマネジメントの存在意義です。
その３に続く