開発者が運用を兼務していて、障害調査や更新作業のたびに開発が止まる。SaaS運用の外注を検討しているものの、「何を、どこまで頼めばよいか」が分からない。そんなときは、今ある資料と作業を使って、依頼したい範囲を整理するところから始められます。
「監視」「バックアップ」「障害対応」は、同じ名称でも事業者によって含む作業が異なります。見積もりを比べる前に、対象、実施条件、判断者を揃えることが必要です。未確認の項目は未確認のまま伝え、調査を依頼する範囲と分けます。
特に障害時は、通知を受ける人、原因を調べる人、本番変更を承認する人、利用者へ連絡する人が必要です。これらを「運用一式」に含めたままにすると、対応を始める段階で担当や承認範囲の確認が必要になるおそれがあります。
この記事では、見積もりを依頼する前に確認する内容を6項目に整理します。
- 何を持っているか（資産の棚卸し）
- いま誰が何をしているか（運用実態）
- どこまで任せ、何を自社に残すか（責任範囲）
- 定型作業と、個別に範囲・工数を決める作業の区別
- 対応時間帯への期待
- 引き継ぎと撤退の可能性
最初に責任範囲を決める
運用委託では、作業を実行する人と、業務上の判断をする人を分けて考えます。外部事業者がサーバーの状態を確認しても、利用者への告知や本番変更の最終承認まで代行できるとは限りません。
- 監視通知を受け取るだけか、一次調査まで行うか
- 設定変更は誰が承認し、誰が実行するか
- 契約時間外に連絡を受けた場合、いつ対応を開始するか
- 原因調査や復旧作業は月額内か、別途見積もりか
この4点を見積書、作業範囲記述書、運用手順書のいずれかへ記載します。障害発生後ではなく、契約前に確認できる状態にすることが目的です。
整理1：何を持っているか（資産の棚卸し）
最初に、運用対象を一覧にします。すべてを把握できていない場合は、未確認の対象も記載します。
- クラウド環境（AWSアカウント、利用サービス、構成図の有無）
- アカウントと権限（管理画面、ドメイン、証明書、外部サービス）
- ドキュメント（構成図、手順書、過去の障害記録と更新日）
外部事業者が対象を調査する場合も、最初から「構成図作成を含む」と見積もるのか、既存資料を前提にするのかで工数が変わります。構成図がない場合は、管理している環境と担当者が分かる一覧から始め、調査が必要な箇所を明記します。
整理2：いま誰が何をしているか（運用実態の可視化）
次に、現在行っている作業と発生条件を記録します。
- 障害に最初に気づくのは誰か。夜間・休日はどうしているか
- 定期的な作業（更新、バックアップ確認、証明書、ライブラリ更新）は誰がいつやっているか
- 担当者が不在のとき、代わりに確認・実行できる人と手順があるか
作業ごとに、頻度、所要時間、必要な権限、実行条件、完了の確認方法を記載します。この一覧が、月額作業と個別作業を分ける見積もりの基礎になります。
整理3：どこまで任せ、何を自社に残すか（責任範囲の線引き）
運用を委託する際は、次のような判断を誰が担うか決めます。
- 変更の承認：本番環境に手を入れてよいかの最終判断
- 業務判断：機能の優先度、利用者への告知、障害時の対外対応
- データの中身：顧客データの内容そのものに関する判断
自社に残す判断と、事前に条件を定めて委託先に任せる判断を分けます。たとえば、定型的な変更は対象と手順を事前承認し、その範囲を超える変更は個別承認にする方法があります。通常時・緊急時それぞれの承認者、委任する条件、実施後の報告方法を合意しておきます。
図1：運用委託の分担例。実際の担当、対応時間、承認・委任条件は個別に決めます。
整理4：定型作業と、個別に範囲・工数を決める作業を分ける
見積もりを整理するため、ここでは作業を次の2つに分けます。
| 種類 | 例 | 発生の仕方 |
|---|---|---|
| 定型作業 | バックアップ結果の確認、更新情報の確認、月次報告など、頻度と手順を決めた作業 | 毎月ほぼ一定 |
| 個別に範囲・工数を決める作業 | 障害の原因調査、攻撃への対応、大規模な構成変更、個別の追加開発 | 計画的な変更と、突発的な対応の両方がある |
定型作業は、実施頻度と手順をもとに工数を見積もります。構成変更や追加開発は計画的に範囲を決められる場合がありますが、障害の原因調査などは着手前に作業量を確定できない場合があります。「手順が定まっているか」と「予定された作業か」を分けて整理します。
契約前に、月額に含む作業、作業時間の上限、上限を超えた場合の承認方法と単価を確認します。「障害対応を含む」と書かれている場合も、一次調査、復旧作業、恒久対策のどこまでを指すかを分けて確認します。
整理5：対応時間帯への期待をそろえる
「監視システムが24時間稼働すること」と「人が24時間対応すること」は異なります。監視システムが常時動作していても、人が通知を確認し、調査や復旧を開始する時間は契約によって異なります。
確認するのは、受付時間、対応開始時間、一次回答の目安、緊急度の判定条件、時間外の連絡経路です。24時間の有人対応が必要な場合は、委託先の交代体制や、解決できない場合の連絡先・引き継ぎ手順まで確認します。必要な時間帯と、実際に提供される対応範囲を見積もり時に照合します。
整理6：引き継ぎと撤退の可能性（出口を確認してから入る）
契約終了時に必要なデータと権限を、契約開始前に確認します。
- 構成図・手順書などのドキュメントは納品され、自社の資産として残るか
- AWS、ドメイン、リポジトリなどの管理権限を誰が保持するか
- 設定、ログ、手順書をどの形式で受け取れるか
- 契約終了時の引き継ぎ作業、期間、費用が定義されているか
アカウントを事業者名義だけで作ると、契約終了時の移管が難しくなる場合があります。お客様が所有すべきアカウントと、事業者が作業用に持つ権限を分けます。秘密情報の返却・削除方法も契約へ含めます。
SaaS運用の外注をしないほうがよいケースもある
次の場合は、継続運用を一括で委託する必要があるかを見直します。
- 既存の運用体制が機能しており、不足している作業が限られている
- 統制や契約の制約で、運用を社外に出せない
- サービスの要件や構成が大きく変わっており、定常運用の範囲をまだ定義できない
構成や作業が未整理の場合は、継続契約の前に棚卸しだけを依頼する方法があります。棚卸し結果を使って、内製を続けるか、どの作業を委託するかを判断します。
相談前に、今分かっていることを一枚にする
6項目を最初から完全に埋める必要はありません。次の形式で、現在の状態と依頼したいことを記録すると、外注先が調査すべき範囲も伝えやすくなります。記入例は架空のものです。
| 項目 | 記入例 |
|---|---|
| 対象 | AWS上のWebサービス。構成図は未更新 |
| 困っている作業 | 障害調査が特定の開発者に集中している |
| 依頼したい範囲 | 平日の一次調査と、手順書の整理を相談したい |
| 自社に残す判断 | 本番変更の承認、利用者への告知 |
| 対応時間と追加作業 | 夜間対応の要否、月額の上限、超過時の扱いを確認したい |
| 引き継ぎ | 既存ベンダーから受け取れる資料は未確認 |
このメモをもとに、見積もりの対象、対応時間、月額内の作業、追加費用、終了時の引き継ぎを照合します。不明点を調べる作業自体が有償になる場合は、調査に入る前に範囲と費用を確認します。
運用の委託範囲について相談する
「既存ベンダーから何を引き継げばよいか」「開発者が兼務している作業のどこを外部へ任せられるか」など、依頼範囲が決まる前の状況もお知らせください。
現在の体制、困っている作業、希望する対応時期をもとに、CloudOpsでの運用支援や個別の調査・移行作業について、対応可否・範囲・費用をご案内します。
