はじめに
システムの保守・運用をベンダーに委託する際、契約書に「SLA（サービスレベル合意）」という条項が設けられることがあります。しかし、実際の中身をよく確認しないまま契約してしまい、いざ障害が起きた際に「思っていた対応と違う」というトラブルになるケースを数多く見てきました。SLAで何を数値として握っておくべきかを整理します。
SLAとは何か
SLA（Service Level Agreement）とは、ベンダーが提供するサービスの品質水準を、具体的な数値として発注側とベンダーの間で合意しておく仕組みです。「きちんと対応します」という曖昧な約束ではなく、「稼働率99.9%以上」「障害発生時の初動対応は1時間以内」といった形で、客観的に測定できる基準として定めます。
SLAが明確であれば、実際のサービス水準がその基準を満たしているかを客観的に評価でき、満たしていない場合にはペナルティ（減額など）を求める根拠にもなります。逆にSLAが曖昧なままだと、「対応が遅い」と感じても、契約違反かどうかの判断ができません。
発注側が握っておくべき4つの数値
① 稼働率
システムがどれだけの時間、正常に稼働しているかを示す指標です。「99.9%」と「99.99%」では、1年あたりの許容停止時間に大きな差があります（99.9%は年間約8.7時間、99.99%は年間約52分）。自社の業務にとって、どの程度の停止がどれだけ許容できるかを踏まえて、現実的な水準を設定する必要があります。
② 障害発生時の初動対応時間
障害を検知してから、ベンダーが最初に対応を開始するまでの時間です。「検知後30分以内に一次報告」のように、具体的な時間で定義しておきます。この数値が曖昧だと、障害発生時に「いつ連絡が来るのか」がわからず、現場が不安な状態で待たされることになります。
③ 復旧目標時間
障害発生から、サービスが復旧するまでの目標時間です。重要度に応じて段階を分けて定義することをおすすめします。「業務停止に直結する重大障害は4時間以内」「軽微な不具合は翌営業日以内」のように、影響度に応じたメリハリをつけておくと、現実的な運用がしやすくなります。
④ 問い合わせへの応答時間
障害ではない通常の問い合わせに対して、どれくらいの時間で一次回答があるかという基準です。保守・運用フェーズで揉めるベンダーとの関係で触れたように、保守フェーズでのトラブルの多くは、この応答スピードに対する認識のズレから生まれます。
数値を決める際に注意すべきこと
SLAの数値は、高ければ高いほど良いというものではありません。稼働率や復旧時間の基準を厳しくするほど、ベンダー側のコストが上がり、それが契約金額に反映されます。安すぎる見積もりが危険な理由でも触れたQCDのバランスの考え方と同様に、本当に必要な水準を見極めた上で、現実的な基準を設定することが重要です。
まとめ
SLAは、ベンダーのサービス品質を客観的に評価するための数値基準です。稼働率、初動対応時間、復旧目標時間、問い合わせへの応答時間という4つの観点を具体的な数値で合意しておくことで、障害発生時の対応のズレを防げます。基準は厳しければ良いわけではなく、自社の業務にとって本当に必要な水準を見極めて設定することが重要です。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント