SLAは顧客に約束するものです。OLAsは、社内チームがその約束を守れるようにするものです。Trupeerなら、無料の運用レベル合意（OLA）テンプレートから始めて、ブランドガイドラインでカスタマイズし、さらにOLAを動画のウォークスルーに変換することで、すべての社内チームを共通のサービス基準に足並みを揃えながら、OLA作成にかかる時間を何時間も節約できます。

運用レベル合意（OLA）テンプレートとは？

運用レベル合意（operational level agreement：OLA）とは、同一組織内のチーム同士で交わす社内合意であり、組織の外部に対して行うコミットメントを支えるものです。サービスデスクは、重大インシデントに対して4時間以内に解決することを事業部門に約束します。この約束が成り立つのは、ネットワークチーム、アプリケーションチーム、そしてその連鎖の中にいるその他の担当者が、既知の時間枠の中でそれぞれの役割を果たす場合に限られます。

OLAは、そうした社内の各パーツを文章として明文化する場所です。契約ではありません。誰も誰かに対して支払いを行うわけでもありません。強制力は完全にマネジメントによるものであり、それが弱点であると同時に、契約ではできない形で誠実でいられる理由にもなります。

運用レベル合意（OLA）テンプレートとは、再利用できる構造です。つまり、当事者、対象となるサービス、コミットメント、測定方法、レビューの取り決めです。こうしたテンプレートは見つけやすいものの、ほとんどは「完全に遵守しているのに失敗する」OLAを書けてしまいます。以降のページは、その理由を扱います。

OLAとSLA：それぞれが実際に約束するもの

このファミリーには3つの文書があり、混同すると実際に深刻な問題が起きます。

サービスレベル合意（service level agreement）は、顧客または事業部門に対する約束です。顧客の条件で、通常はエンドツーエンドで書かれ、提供のデリバリーチェーンの外部にいる人々に報告されるものがこれです。

運用レベル合意（operational level agreement）は社内のもので、同じ組織に属するチーム同士の間で交わされます。SLAを実現可能にするためだけに存在し、SLAが不要とするコミットメントを含めるべきではありません。

下支え契約（underpinning contract）は、同じ連鎖を支える第三者（ベンダーや外部委託プロバイダー）との商取引上の合意です。法的な強制力があり、OLAにはそれがありません。また3つの中で最も柔軟性が低いことが多いため、SLAの後ではなく、SLAの前に合意しておくべきです。

実務上の結論は、順序（シーケンス）のルールです。まず下支え契約を合意し、次にそれらの契約で許される範囲に基づいてSLAを合意し、最後に残りを埋めるOLAを合意します。逆の順序で進める組織は、ベンダーが提供に合意していない内容まで事業部門に約束してしまうことが、日常的に起きています。

Trupeerでこのテンプレートをカスタマイズする方法

ステップ1：テンプレートセクションを開く

メインナビゲーションからテンプレートセクションへ移動します。

ステップ2：テンプレートを選択して開く

作業したいテンプレートをクリックして開きます。

ステップ3：テンプレート表示を展開する

必要に応じて、テンプレート表示を展開してレイアウトと詳細をはっきり確認します。

ステップ4：テンプレートを編集する

編集をクリックして、選択したテンプレートの変更を開始します。

エディター内では、次のことができます。

• 新しいセクションを追加

• 書式ルールを定義または更新

• ロゴを追加し、位置や関連設定を調整

ステップ5：カスタマイズしたテンプレートを保存する

必要な変更をすべて行ったら、保存をクリックして更新されたテンプレートを自分のものとして保存します。

ステップ6：プレビューしてテンプレートを微調整する

カスタマイズしたテンプレートがどのように表示されるか確認したいときは、プレビューを開きます。

プレビュー画面から、必要に応じて直接調整を続けることができ、テンプレートが希望どおりに表示されることを確認できます。

運用レベル合意（operational level agreement）テンプレートを使うと：

• 作成時間を節約：OLAs向けに構造化された空白ページをスキップできます。

• 社内チームを揃える：組み込みの項目により、各チームが自分の責任を確実に理解できます。

• ブランドに合わせ続ける：Trupeerのブランドキットでロゴ、フォント、カラーを適用します。

• 顧客のSLAを守る：強力なOLAsにより、社内の引き継ぎが外部への約束を崩すことを防ぎます。

• サービス間で標準化：すべての社内合意に同じOLAテンプレートを使用します。

• グローバルチームに対応：1クリックでOLAsを65以上の言語に翻訳できます。

なぜすべてのチームがOLAを達成しているのに、SLAが違反するのか

これはサービス管理における最も一般的なパターンで、矛盾のように見えます。

どのチームもグリーンです。ネットワークは1時間以内に応答します。アプリケーションは2時間以内に解決します。サービスデスクは30分以内にトリアージします。月次のOLA遵守レポートは読みやすく、顧客のSLA違反は重大インシデントの3分の1で発生しています。

理由は、OLAsがチーム内の時間を測定し、SLAがエンドツーエンドの時間を測定するためです。この2つの数値の差は「トランジット（移送・引き継ぎの待ち時間）」です。つまり、再割り当て後のキューにあるチケットが回収されるのを待っている時間、あるいは追加情報のために差し戻される時間です。

その時間は誰のものでもありません。どのチームのOLAにも入っておらず、どこにも報告されません。そして、合計すると、実際の作業時間の合計より大きくなることさえよくあります。

つまり、失敗はパフォーマンスの問題というより構造的なものです。既存の数値を達成するようにチームへ圧力をかけても、助けにはなりません。なぜなら、すでにチームは達成しているからです。

OLAは「作業」ではなく「引き継ぎ」を統治する

この問題を解決するための見方の転換は小さく、文書の目的そのものを変えます。

通常の書き方で作成されたOLAは、チーム自身の作業にかかる時間をチームに約束させます。これはチームがコントロールできる部分なので、チームが署名したいと思う部分でもあります。しかし、変数ではなかったため、合意しても最も役に立たないものです。

うまく書かれたOLAは、チーム同士の「インターフェース（引き継ぎ点）」をチームに約束させます。引き継ぐ前にチケットに何が入っていなければならないか。受け取るチームが回収するまでにどれくらいの時間が必要か。チケットが不完全だった場合にどうなるか。引き継ぎのギャップの間、誰がそのチケットを所有するのか。

引き継ぎが主題になると、欠けていた2つの項目が明確になります。1つ目は、受け取るチームの時計が動き始める前に「成立していなければならないこと（エントリー基準）」です。2つ目は、トランジット時間そのものを明示的に割り当てることです。これにより、チーム間のギャップが「誰のものでもない」状態ではなく、誰かの数値になります。

OLAテンプレートの他のすべては管理（アドミニストレーション）です。この2つこそが文書の中身です。

エントリー基準：時計が動き始める前に成立していなければならないこと

複数チームの連鎖において最も破壊的な行動は「差し戻し（バウンス）」です。情報が足りない状態でチケットが届き、受け取るチームがそれを返し、そして受け取るチーム側の時計がリセットされます。

差し戻しは、受け取るチームの観点からは完全に合理的です。チケットを作業できず、遵守は自分たちの解決時間で測定されるため、返すことは双方を守ります。また、経過時間の大部分がここに集まりやすいのに、チームごとに別々に測定するレポートでは見えません。

エントリー基準は、義務を上流へ移すことで解決します。各OLAの行には、そのチームが作業を受け入れるために、そのチームに必要な「具体的な項目」が列挙されます。ネットワークの引き継ぎなら、デバイス名、サイトコード、正確なエラーテキスト、最初に観測された時刻、そして他のユーザーに影響があるかどうか、などが該当します。アプリケーションの引き継ぎなら、ユーザー、トランザクション参照、再現手順、スクリーンショットなどが該当します。

そして、送信側チームのコミットメントの文言が変わります。「30分以内にトリアージ」ではなく、「30分以内に、エントリー基準を満たすチケットを引き渡す」です。同じ時計で、異なる義務。インセンティブは、実際に情報を集められるチームに移ります。

受け取るチームには拒否する権利が残りますが、権利は狭くあるべきです。拒否が有効なのは、指定されたエントリー基準が本当に欠けている場合に限り、そしてすべての拒否は理由とともに記録されます。記録することで、差し戻しを「見えない習慣」から「誰かが説明しなければならない数値」へと変えられます。

無料の運用レベル合意（operational level agreement）テンプレート：コピーするための構造

ここからコピーしてください。アスタリスク（*）が付いた項目は、標準テンプレートが省略するものです。

ヘッダー。 OLA参照とバージョン。当事者（名前で示す2つのチーム）。このOLAが支えるSLAまたはサービス。有効日、レビュー日、そしてそれぞれの側における指名されたオーナー。

スコープ。 対象となるサービス、システム、またはリクエストタイプ。そして、明確に「対象外」を記載。

サービス時間。 各当事者のカバー範囲（時間外の取り決めと、その違いを含む）。同一チェーン内の2つのチームでサービス時間が一致していないことは、よくあるうえに静かに致命的なギャップです。

コミットメント表。 リクエストタイプまたは優先度ごとに1行。トリガー、エントリー基準、応答時間、解決または引き戻し時間、割り当て済みのトランジット時間、エスカレーションポイント。

エスカレーション。 各段階で誰に連絡するか、どのルートで、どれくらいの時間後に。時間外の経路も含めます。

依存関係。 このチームが他から必要とするもの。第三者との下支え契約がある場合はそれも含め、計算を検証できるようにそれぞれの時間も記載します。

測定。 何を、どのシステムから、誰が、どの頻度で測定し、報告するか。応答時間や解決時間に加えてバウンス率も含めてください。エントリー基準が機能しているかどうかを示す指標だからです。

例外。 宣言された重大インシデントや変更凍結のように、コミットメントが適用されない合意済みの状況。

レビュー。 日付、そしてサイクル外レビューを引き起こす条件。

ここまでコピーしてください。2〜3ページに収めます。2回読む必要があるほど長いOLAは、インシデント時には参照されません。そしてインシデント時こそが重要なときです。

OLAが実際にSLAに積み上がっているか確認する方法

署名する前に計算してください。15分で済み、ほぼ例外なく省略されます。なぜなら、OLAは異なるチームと異なる日に、1つずつ交渉されるからです。

この考え方を実用的にする2つのルールがあります。トランジット時間は「それ自体の行」として表示される必要があります。なぜなら、それがこの仕組みの要点だからです。そして、どのチェーンにも余裕（ヘッドルーム）が必要です。なぜなら、SLAにちょうど合計するチェーンは、何かが少しでもずれると違反するからです。目安として10〜15%が妥当なマージンです。

合計がSLAを超える場合、正直に選べる選択肢は3つだけです。SLAを再交渉する、実現可能にする何かによってチームの時間を減らす、または引き継ぎを削除する。できないのは、「違反を保証するOLA」に署名して、その後それに対してパフォーマンスを管理することです。これは、驚くほど多くのサービスデスクが置かれている状況です。

作業よりもトランジット時間が長かった小売企業

Rendlesham Groupは、約6,000人のスタッフを抱え、店舗と本社を支える社内ITサービスデスクを運営し、複数の小売ブランドを展開しています。

事業部門に対するP2インシデントSLAは、解決まで4時間でした。P2の違反率は2年間、約38%で推移していました。すべてのチームのOLA遵守は月次で報告され、どのチームもグリーンでした。

ある人が、最終的に、違反していた120件のP2インシデントすべてについて、状態変更のタイムスタンプを付けました。

中央値の総経過時間は6時間51分でした。そのうち、チケットを実際に作業していたチーム内の時間は3時間12分。トランジットは3時間39分で、再割り当て後のキューで待っている時間、回収されるのを待つ時間、または差し戻される時間でした。

違反したインシデントの経過時間の半分以上は、誰のものでもなく、どこにも報告されていませんでした。

最大の要因は差し戻しでした。120件のうち41件は、受け取るチームによって少なくとも1回、不十分な情報のために返されており、各バウンスは中央値で1時間20分の追加に加え、そのチームの時計をリセットしていました。最も多い理由は、エラーテキストやスクリーンショットが添付されていないこと、そしてそのインシデントがどの店舗に影響するのかが確認されていないことでした。

変更は限定的でした。エントリー基準はすべてのOLAの行に書き込まれました。サービスデスクのコミットメントは「30分以内にトリアージ」から「30分以内に、エントリー基準を満たすチケットを引き渡す」へと書き換えられました。引き継ぎごとにトランジット15分を割り当て、エントリー基準が満たされた時点で受け取るチームに対してカウントされます。そして、すべてのバウンスは理由とともに記録されました。

その後の2四半期で、バウンス率はP2の34%から9%へ低下しました。中央値のトランジット時間は3時間39分から1時間6分へ減少しました。P2の違反率は38%から11%へ下がりました。

どのチームの社内解決時間も、本質的には変わりませんでした。誰もより速く作業していません。誰のものでもなかった時間が、単に誰かのものになっただけです。

運用レベル合意（operational level agreement）を段階的に作成する方法

テンプレートからではなく、SLAから始めます。顧客に対してエンドツーエンドで約束している内容を、時計の定義とともに書き出してください。

チェーンをマッピングします。そのタイプのリクエストに触れるすべてのチームを、順番に並べます。必要に応じて第三者も含めます。引き継ぎは矢印としてではなく、それぞれ独立したステップとして描きます。

各引き継ぎについて、受け取るチームに1つだけ質問します。「作業を開始するために、チケットには何が必要ですか？こちらに戻ってこないで済むように。」書き留めたその答えが、エントリー基準です。チームはこれに対して、すぐに正確に答えられますが、ほとんどのチームはこれまで一度も聞かれたことがありません。

次に、上記の計算に沿って時間を合意します。チームごとに個別に進めるのではなく、全員が同席した1回の会話として行うと、1時間で済み、合計の問題を完全に防げます。

トランジットを明示的に割り当て、誰が所有するかを決めます。引き継ぎごとに15分は妥当な出発点であり、受け取るチームに対してカウントされるべきです。

測定方法を合意します。バウンス率を含め、どこから取得するかも決めます。ツールで出せない場合は、最初のレビューで気づくのではなく、署名する前に分かっていることが重要です。

そして、正式化する前に四半期分回してみます。最初のバージョンは1〜2か所で間違っていることが多く、署名が存在する前に直した方が簡単です。

よくあるOLAのミスと、それぞれがもたらすコスト

チェーンではなくチームを測定する。 全員がグリーンなのに、SLAが違反する。最も多い失敗であり、このページのテーマです。

エントリー基準がない。 差し戻しが受け取るチームの合理的な防衛策になり、経過時間が見えないまま膨らみます。

合計が合わない時間。 設定したOLAは違反を保証しているのに、誰もそれを合計したことがありません。

サービス時間が一致していない。 あるチームは6時まで、次のチームは5時までカバーします。5時以降に届いたものは一晩滞留しますが、両チームとも自分たちの時間内に収まっているため、どのレポートにも出てきません。

SLAの文言をOLAにそのままコピーする。 ペナルティ、クレジット、法的な文言はここには属しません。それらを持ち込むと、チームは誠実に交渉するのではなく、防衛的に交渉するようになります。

第三者と一緒にOLAを書く。 お金のやり取りが発生するなら、それは下支え契約であり、テンプレートではありません。調達や法務の関与が必要です。このIT調達ポリシーテンプレートでは、承認のプロセスをカバーしています。

署名してファイルに保存するだけ。 誰もレビューしないOLAは、約1年ほどで存在しなくなったサービスチェーンを説明することになります。

OLAができた後の管理とレビュー方法

コンポーネントではなくチェーンを報告します。重要なのは1つの数値です。つまり、SLAに対するエンドツーエンドのパフォーマンスです。OLAの指標は、それを説明するために存在し、単独で立つためではありません。

四半期ごとに、すべての当事者が同席してレビューします。二者間のレビューでは元の問題が再現されます。なぜなら、ギャップは同じ会話に決して登場しない当事者同士の間に存在するからです。

見るべきものは3つです。引き継ぎごとのバウンス率。エントリー基準の改善が必要な場所を教えてくれます。引き継ぎごとのトランジット時間。キューが形成されている場所を示します。そして、OLAが説明していない経路をたどったインシデントの割合。これにより、文書が現実からずれていることが分かります。

チームの再編、システムのチーム間移動、第三者の新規参入、またはSLAの変更があったときは、サイクル外レビューをトリガーします。これら4つは、年次レビューサイクルが想定するよりもずっと頻繁に起きます。

OLA、SLA、または下支え契約：どれが必要ですか？

コミットメントの相手が、デリバリ組織の外部の誰かである場合（外部の顧客であっても、提供される社内の事業部門であっても）、それはSLAです。

同一組織内の2つのチームの間で、金銭のやり取りが発生しない場合、それはOLAです。

商取引上の取り決めのもとでサプライヤーと行う場合、それは下支え契約であり、このテンプレートではなく、法務と調達が必要です。

厄介なのは、共有サービスセンターや、チャージバックモデルを持つ社内チームです。これはOLAとSLAの間に位置します。実務的な答えは、OLAとして書き、ペナルティに関する文言を削除することです。社内のペナルティ制度は、確実に防衛的な行動と、より悪いサービスを生み出すからです。

ここまでの上に重なる、顧客向けの定義や回答文言については、エンドユーザーが実際に見る層をカバーするヘルプデスク回答テンプレートとチケットおよび解決テンプレートをご覧ください。

WordまたはExcelでOLAテンプレートを入手できますか？

合意書（agreement）としてのWordです。スコープ、例外、レビューのセクションは文章であり、署名のために文書が回覧されるためです。

Excelは特に2つの部分に適しています。コミットメント表です。エントリー基準、時間、トランジットの割り当てを、並べ替えや確認ができる列に入れたい場合に使います。そして計算用シートです。各チェーンがSLAに対して合計され、ヘッドルームが不足しているものがフラグされます。2つ目のシートは、最初に作る価値があることが多いです。なぜなら、それが交渉しようとしていた内容を変えることがよくあるからです。

署名済みの版はPDFです。ソースからエクスポートします。作業版は編集可能な状態に保ってください。エントリー基準は、実際のバウンスが見えてくる最初の四半期の後に調整が必要になるためです。

OLAと現実を歩調を揃える方法

OLAは、常に変化する作業の連鎖を記述します。チームは再編され、システムは移動し、ツールは変わり、文書は最後に誰かが更新するものです。

最も早く陳腐化するのはエントリー基準です。なぜなら、それは「チケットに何が含まれていなければならないか」を説明しており、「チケットに何が含まれていなければならないか」は、現在のツールや現在のプロセスが実際にどう動いているかに依存するからです。

Trupeer AIは、基盤となる手順を最新の状態に保つコストを低くすることで支援します。トリアージまたは引き継ぎのプロセスを一度記録すると、手順と画面がキャプチャされた書面の手順が得られます。サービスデスクはそれに従うことができ、どの情報が収集されているかが明確に分かります。ツールが変わったら、書き直すのではなく再記録してください。

記録する。ブランド化する。翻訳する。Trupeerする。

SOP creatorは、OLAが依存する手順をカバーし、またIT SOPテンプレートでは、それらのうちどれを維持する価値があるかを判断する方法をカバーしています。Documentationでは、合意と手順を一緒に保ち、セットアップ手順はドキュメントテンプレートセットアップガイドに記載されています。

よくある質問

Wordで無料の運用レベル合意（operational level agreement）テンプレートはありますか？

上記の構造は、エントリー基準や標準テンプレートが省略するトランジット割り当ての項目を含めて、そのままWordまたはGoogle Docsに貼り付けられます。ゲート付きのダウンロードもフォームもありません。コミットメント表はスプレッドシートで管理し、参照してください。ここは並べ替えと合計が必要なためです。

PDFで無料の運用レベル合意（operational level agreement）テンプレートはありますか？

当事者が合意したら、署名済みの版をPDFにエクスポートし、作業用のコピーは編集可能な状態で保管します。エントリー基準は、実際にどのチケットがバウンスされているかが見えてくる最初の四半期以降に、ほぼ確実に調整が必要になります。

Excelで無料の運用レベル合意（operational level agreement）テンプレートはありますか？

Excelは、コミットメント表と計算チェックのための最適な場所です。引き継ぎごとに1行、SLAに対する累計を表示し、ヘッドルームが10%未満のチェーンをフラグします。交渉の前にこのシートを作っておくと、交渉される内容が変わりやすくなります。

運用レベル合意（operational level agreement）のPDF例はどこで見られますか？

いくつかのITSMベンダーや政府機関が、OLAやSLAのテンプレートをドキュメントとして公開しており、構造としては妥当です。内容ではなくセクションの読み方として参考にしてください。公開されている例に含まれるコミットメントは誰かの別のチェーンであり、また、その時間はそれを支えるために作られたSLAの外では意味を持たないためです。

運用レベル合意（operational level agreement）は誰が署名しますか？

各側に指名されたオーナーです。これはサービス管理の機能ではなく、そのチームのデリバリーに責任を持つマネージャーであるべきです。サービス管理だけが署名するOLAは願望に過ぎません。なぜなら、それをリソースする必要がある人が同席していないからです。

サービスデスクは何件のOLAを用意する必要がありますか？

多くのチームが想定するよりも少なくて済みます。定期的に作業をやり取りするチームペアごとに1つ、サービスごとに1つではなく、1つのコミットメント表でそのすべてのリクエストタイプをカバーします。12件程度を超えると、メンテナンスが制約になり、レビューされるよりも早く文書が古くなっていきます。

運用レベル合意（operational level agreement）にはペナルティが必要ですか？

いいえ。強制するための法的な関係はなく、社内のペナルティ制度は確実に防衛的な行動を生みます。チームは作業を拒否し、時計の開始時刻をめぐって議論し、結果ではなく自分たちの数値を最適化します。チェーンをエンドツーエンドで報告してください。そうすれば、誰かが罰金を科されなくても、共有される結果が可視化されます。

OLAはどのくらいの頻度でレビューすべきですか？

四半期ごとに、すべての当事者が同席して行います。さらに、チームが再編されたとき、システムがチーム間で移動したとき、第三者がチェーンに入ってきたとき、または基盤となるSLAが変更されたときは、サイクル外レビューも実施します。四半期のタイミングはずれを捉え、トリガーは文書が翌日には現実と合わなくなるような変更を捉えます。