この記事の結論
「マネージド」という名称だけでは作業範囲は分かりません。監視、判断、実行、結果確認を分解し、事業者・制作会社・自社のどこが担当するかを契約前に明文化します。
基盤管理と業務管理を分ける
ハードウェアやOSを事業者が管理していても、アプリの設定、データ分類、利用者の権限は自社側に残ることがあります。AWSの責任共有モデルでも、利用するサービスに応じて利用者側の責任が変わります。これを一般化しすぎず、契約先の作業一覧で確認します。
監視の後の動きを確認する
死活監視が含まれていても、停止通知だけなのか、再起動まで実施するのか、原因分析と再発防止まで含むのかで価値が違います。事業者が再起動できても、予約や注文の整合性を判断できるのは自社だけという場合があります。
変更の承認者を決める
パッチ適用、容量拡張、アクセス制限の変更が自動で行われる場合は、事前通知と停止影響を確認します。承認を待つ運用なら、担当者不在時の代理も必要です。緊急時の例外手順がなければ、承認待ちで障害が長引く可能性があります。
引継ぎ可能な資料を成果物にする
作業記録、構成図、連絡網、復元手順、契約一覧をどこまで受け取れるかを確認します。委託先が変わった際に何も分からなくなる状態を避け、更新された資料の保管先と所有者を決めます。秘密情報は別途安全な方法で受け渡します。
分担表には「実施する人」だけでなく、作業を決定する人と結果を確認する人も書きます。事業者が更新を実施しても、業務画面や取引先との連携を確認するのは利用者側という場合があります。引き渡される作業報告の内容も合わせて確認します。
| 作業 | 主担当の例 | 自社で確認すること |
|---|---|---|
| OS更新 | 事業者 | 停止影響・適用日 |
| CMS更新 | 制作会社 | 業務機能・切戻し |
| 権限見直し | 自社 | 退職者・外部委託者 |
導入・見直しのチェックリスト
- 通知だけか復旧実施まで含むか確認しましたか。
- CMSと外部連携の保守担当が明確ですか。
- 委託終了時に構成資料を引き継げますか。
参考資料と確認範囲
- AWS:Shared Responsibility Model — クラウド事業者と利用者の責任が分かれるという基本概念。各社の代行範囲は個別確認が必要です。