変更要約: 初版
5.3供給者管理とアンダーピニング契約
外部供給者に依存する部分をSLAと整合させる供給者管理--外部供給者との契約であるUC（アンダーピニング契約）、顧客SLAとUC/OLAの整合、供給者の評価とレビュー、障害時の責任分界、そしてクラウド利用時の共有責任モデル--を、SLA目標を最終的に守るサービスマネージャの判断として学びます。
現代のサービスは、回線事業者・クラウド事業者・保守業者など多数の外部供給者に支えられて成り立っています。顧客に約束したSLAを守れるかは、これら供給者が提供する部分の品質に大きく左右されます。しかし供給者の品質は自動的に整うわけではなく、顧客SLAが要求する水準を、供給者との契約（UC）や社内合意（OLA）に正しく落とし込み、履行状況を評価し続ける運用が必要です。この節では、外部供給者との契約であるUC、顧客SLAとの整合、供給者評価、障害時の責任分界、そしてクラウドの共有責任モデルを、SLAを最終的に守るサービスマネージャの判断として学びます。
5.3.1UC・OLAとSLAの整合
- SLA＝サービス提供者と顧客の間で合意するサービス品質の取決め。OLA＝SLAを支える社内の運用チーム間の合意（運用レベル合意）。UC（アンダーピニング契約）＝SLAを支える外部供給者との契約。三者は「顧客への約束（SLA）を、社内（OLA）と外部（UC）の下支えが確実に満たす」という支持関係にある。
- 整合の要点：UC/OLAが約束する水準は、顧客SLAが要求する水準を確実に満たす（少なくとも上回る）必要がある。例えば顧客に「復旧目標4時間」を約束しながら、その復旧に不可欠な保守供給者とのUCが「オンサイト対応は翌営業日」では、供給者が契約どおり動いても顧客SLAを守れない。このSLAとUCの不整合は、供給者の落ち度ではなくサービスマネージャの設計の落ち度であり、契約締結・見直し時に必ず突き合わせる。
5.3.2供給者評価・責任分界・共有責任
- 供給者評価＝UCで定めた指標（可用性・応答時間・対応時間等）に照らして供給者の履行状況を定期的にレビューし、未達があれば改善を求める運用。委託しても説明責任（アカウンタビリティ）は自組織に残る--「供給者に任せたから自分たちは無関係」ではなく、顧客に対する最終責任はサービス提供者が負う。
- 責任分界（点）＝障害・変更時に「どこまでが供給者の責任範囲で、どこからが自組織か」を明確にした境界。曖昧だと障害時に責任の押し付け合いが起き復旧が遅れる。クラウドの共有責任モデルはこの典型で、例えばIaaSでは概ねクラウド事業者が物理・基盤（電源/空調/ハードウェア/仮想化基盤）を、利用者がOS以上（OS設定・ミドルウェア・アプリ・データ・アクセス管理）を責任分担する（SaaSほど事業者側の範囲が広がる）。どの層まで供給者が担うかを理解して運用設計する。
「SLA(提供者⇔顧客)／OLA(社内)／UC(外部供給者との契約)」「UC/OLAは顧客SLAが要求する水準を確実に満たす必要--SLAとUCの不整合はサービスマネージャの設計の落ち度」「委託しても顧客への説明責任は自組織に残る」「クラウド共有責任＝IaaSは事業者が基盤、利用者がOS以上、SaaSほど事業者範囲が広い」が最頻出です。責任分界を曖昧にしない、が要点。
あるサービスマネージャが、顧客と「重大障害からの復旧目標（RTO）4時間」を含むSLAで契約している基幹サービスを担当しているとします。このサービスは、ハードウェア保守を外部の保守業者に委託しており、その契約（UC）を見直す時期に来ました。現行UCを確認すると、保守業者のオンサイト（現地）対応は「連絡から翌営業日まで」という条件でした。ここでサービスマネージャは、顧客SLAの「復旧4時間」と、保守業者UCの「翌営業日対応」が明らかに不整合であることに気づきます。仮に重大なハードウェア故障が金曜夜に起きれば、保守業者は契約どおり月曜に来れば足りることになり、その時点で顧客SLAは大幅に違反してしまいます。これは保守業者の落ち度ではなく、顧客への約束（SLA）を下支えする契約（UC）を、必要な水準に整合させていなかったサービスマネージャ側の設計の問題です。対応として、サービスマネージャは複数の選択肢を検討しました。第一に、UCを「重大障害時は4時間以内オンサイト」へ引き上げる交渉（当然コストは上がる）。第二に、保守を待たずに復旧できるよう予備機（コールドスタンバイ）を自組織側で確保し、故障時は予備機へ切り替えてRTOを満たしつつ、故障機の物理修理は翌営業日UCのままとする設計。第三に、そもそも顧客SLAのRTOが事業上本当に4時間必要かを顧客と再協議する。ここで重要なのは、「供給者が契約どおり動けばSLAを守れる」構造になっているかを、UC締結・見直しのたびに顧客SLAと突き合わせて検証することです。委託していても顧客への最終的な説明責任は自組織に残るため、供給者任せにせず、SLA・OLA・UCの支持関係が破綻していないかを設計・運用し続けるのが、供給者管理におけるサービスマネージャの判断です。
| 取決め | 当事者 | 位置づけ |
|---|---|---|
| SLA | サービス提供者 ⇔ 顧客 | 顧客に約束するサービス品質 |
| OLA | 社内の運用チーム間 | SLAを社内で下支えする合意 |
| UC（アンダーピニング契約） | サービス提供者 ⇔ 外部供給者 | SLAを外部から下支えする契約 |
ひっかけ： 「供給者が契約（UC）どおりに対応したのに顧客SLAを違反したのだから、それは供給者の責任だ」は誤りです--UCが顧客SLAの要求水準に整合していなかったのであれば、それは下支え契約を整合させなかったサービスマネージャ側の設計の落ち度です。また「クラウドに載せれば可用性もセキュリティも全て事業者の責任」も誤り＝共有責任モデルにより、IaaSではOS以上（設定・データ・アクセス管理等）は利用者の責任であり、委託しても顧客への説明責任は自組織に残ります。
5.3.3この節のまとめ
- SLA（提供者⇔顧客）を、OLA（社内）とUC（外部供給者との契約）が下支えし、UC/OLAは顧客SLAの要求水準を確実に満たす必要がある
- SLAとUCの不整合は供給者ではなくサービスマネージャの設計の落ち度であり、UC締結・見直しのたびに顧客SLAと突き合わせて検証する。委託しても顧客への説明責任は自組織に残る
- 障害時に備え責任分界を明確にし、クラウドの共有責任モデル（IaaSは事業者が基盤・利用者がOS以上、SaaSほど事業者範囲が広い）を理解して運用設計する
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 顧客SLAに「重大障害からの復旧目標(RTO)4時間」を含む基幹サービスで、ハードウェア保守を委託する外部業者とのUCを見直したところ、保守業者のオンサイト対応が「連絡から翌営業日まで」だった。サービスマネージャの判断として最も適切なものはどれか。
Q2. サービスを支える取決めについて、SLA・OLA・UCの当事者の組合せとして正しいものはどれか。
Q3. IaaSのクラウド基盤上で自社サービスを運用している。共有責任モデルに照らし、可用性やセキュリティに関する運用の考え方として最も適切なものはどれか。