SLA

SLA導入にあたって

SLAの導入に関して簡単にまとめています。

SLAとは(Service Level Agreement)

SLAとは、サービスを提供する側とその利用者の間に結ばれるサービスのレベル(定義、範囲、内容、達成目標等)に関する合意書です。
SLA合意書の主な規定項目には以下のような項目があります。

  • SLAの目的
  • SLAの範囲及び責任
  • SLAの改定方法
  • SLA対象サービス
  • サービスレベルに関する規定
  • 報告と管理
  • サービスレベル未達・達成時の対応 等

従来情報処理サービスについては明確な評価基準などは定めていませんでした。
SLAは提供されるサービスのレベルをユーザとベンダーで合意し、その目標に向かって定量評価を行ってプロセス改善につなげる目的で導入されるようになってきました。
またSLAを効果的に実現するためには、SLA項目の選定がカギになります。

SLAの選定基準として以下のような点に考慮する必要があります。

  1. 客観的に定量データとして測定可能なもの
  2. 自動的にデータが収集可能なもの
  3. ユーザの立場でサービスレベルが把握できるもの

また、現実的なSLA設定を行うためには以下のポイントも重要です。

  1. サービスレベルの範囲をむやみに広げない
    せっかく導入するからにはあれもこれもサービスレベルを設定したくなるものですが、設定までのコストも時間もかかります。最初は重要なものだけに絞ったほうが、実効性のあるSLA管理が実現できます。
  2. SLAを合意書・契約書としてとらえすぎない
    サービスレベルの設定は固定的・永続的にとらえるべきではなく、あくまでもSLMの一環としてPDCAサイクルを実行してSLAの改善を図っていくという観点が重要です。あまり合意書・契約書という観点が前面にですぎるとベンダー・ユーザとも危険を持ちたくないため、サービスレベルの設定が難しくなります。サービスレベルの設定=ペナルティ設定ではないという考えが必要です。
    サービスレベルの合意が難しい場合は、仮運用期間などを設けてサービスレベルについて擦り合わせをすると合意が取りやすくなる場合もあります。

SLMとは(Servicr Level Management)とは

SLAとは、サービスの価値を定義するものです。では価値を定義しただけでうまくITサービスが提供されるでしょうか。サービスを定義するだけでは、目標を定義したことにしかなりません。

SLAの作成(Plan)⇒サービスの実行(Do)⇒サービスのモニタリング・評価(Check)⇒SLAの見直し(Action)

というPDCAサイクルをまわし、規定したSLAと実際のサービスレベルに差はないか、ギャップがある場合にはサービスを改善するあるいはSLAを適正な水準に見直すという作業が必要になります。こうしてSLAを有効に機能させるものをServicr Level Management(SLM)といいます。SLAを導入する場合、SLMの仕組みも構築しなければ期待する効果をあげることはできません。

SLA/SLMの導入

ITサービスに関する成熟度により導入方法は異なってきますが以下の様な導入方法が多いのではないでしょうか。

  1. 現状のITサービスの棚卸(そもそもなんのサービスが行われているか)
  2. サービス目標としてのSLA/SLM の設定
  3. SLA対象データの収集
  4. SLA結果のモニタリング
  5. SLA結果の評価、対応、必要なアクションの実施3-5の繰り返し、必要なタイミングで2に戻りPDCAサイクルを廻していく

SLA/SLMが廻るようになったら、必要に応じてボーナス&ペナルティ付きのSLA/SLMの設定という順番に導入していくと導入するときの心理的の負担が低減します。

当事務所ではSLA/SLMの導入支援サービスを実施しております。
相談は無料です。お気軽にお問合せください。

フォームでのお問合せはこちらから

SLAとITILについて

SLAの標準化の流れとしてはITIL(IT Infrastructure Library)の普及があります。
ITILは英国OGC(Office of Government Commerce)が開発したITに関するベストプラッティクスですが、最近英国以外でも普及しています。日本においてもitSMF Japanが普及活動を行っています。
ただしITILでは、最終的なSLAの実装方法は明記していませんので、各企業の状況に応じて定義する必要があります。

上流工程を巻き込んだSLAの締結

SLAは比較的運用局面で締結されることが多くなってきました。
ところでサービスレベルは運用部門だけで守られるのでしょうか。
ソフトウェアの品質は開発時に作りこまれます。つまり運用部隊がどんなにがんばっても、元々のプログラムのバグなどによるトラブルは防ぎようがありません。
自ら制御できない事項をSLAの項目(SLO)としても、対処のしようがありません。

本来は、設計/開発フェーズからシステムの品質についてのSLOとその保証値を取決め(品質合意、品質評価指標など)、その取決めた値を守った形で、運用部隊に引き渡せばより実効性の高いSLA/SLMの管理が可能となります。

壇コンサルタント事務所では、IT法務と人財コンサルティングをメイン業務にしています。
東京など関東を中心にシステム開発契約書やシステム運用契約書等のIT関係の契約書や人事制度構築・就業規則や各種社内規程作成について、作成支援・コンサルティング等各種サービスの提供をさせて頂いております。貴社の法務アドバイザーとしてお気軽にご利用ください。