クラウド運用代行 事業者選定ガイド

提案書に書かれた対応時間はどれも似て見えます。分かれるのはその時計がいつから回るかです。検知時刻なのか、顧客が電話した時刻なのか、代行先の受付システムに登録された時刻なのかで、同じ30分がまったく別の約束になります。受付窓口がメール一つだけなら、深夜の障害で時計は担当者が出社してから回り始めます。

応答と復旧も分けて読みます。多くの約束は初動応答の時間であり、復旧時間まで約束する事業者はまれです。初動応答だけ守り復旧に数日かかっても違反にならない契約が実際にあります。応答の後に何をするのか、何時間ごとに経過を知らせるのか、等級を上げられるのは誰かを同じ表に書かせてください。この表がないと、障害が長引く間こちらから状況を尋ねることが業務になります。

約束を守れなかったとき何が起きるかも確認します。多くは月額の一部をクレジットで返して終わりです。サービス停止による損失に比べれば小さい額なので、この条項は賠償ではなく代行先が自らに科す罰点と読むほうが正確です。

等級の定義は自社サービスを基準に書き直します。代行先の標準等級表はサーバーが落ちたかどうかを基準に書かれていることが多い一方、決済だけが失敗して他は正常という状態は自社にとって最上位の障害です。自社のサービスで何が止まれば1等級なのかを契約の付属文書に記しておけば、深夜に等級を巡って争いません。

約束に実効があるかは人の配置で確認します。夜間当番が交代勤務なのか呼び出し待機なのか、一人が同時に何社を見ているのか、自社サービスを知る人が何人いるのかを尋ねてください。24時間と書かれていても夜に起きている人がいなければ、その一文は電話を受けるという約束に近いものです。

運用を任せるとはアクセス権を渡すことです。最上位の管理者アカウントまで渡せば代行先は自社の環境で何でもでき、逆に権限を絞りすぎれば障害のたびに承認を待って復旧が遅れます。境界は役割で引きます。参照と再起動は常時開き、リソースの作成と削除、権限変更は承認手順の後ろに置きます。障害時だけ開く一時権限を別に用意すれば、平時の権限を広げずに復旧を遅らせません。

アカウント名義はさらに重要です。代行先名義のアカウントの中に自社のリソースが入っていると、契約終了時にリソースを移す必要があり、その移行作業は新規プロジェクトほどの規模になります。アカウントは顧客名義で作り、代行先は管理権限を預かる構造が後々安全です。ドメインと証明書、DNSも同じ原則に従います。代行先のアカウントに登録されたドメインは、関係がこじれたときの交渉材料になります。請求まで代行先が処理する構造を選ぶなら、原本の請求明細を毎月受け取ってください。

誰がいつ何をしたかが残るかも見ます。監査ログが代行先のアカウントにだけ貯まると、事故のとき自社は記録を依頼する側になります。ログは自社アカウントに保存されるようにし、保管期間を契約書に記します。

接続手段の管理方法も同じ場で尋ねます。サーバー接続鍵とデータベースのパスワードをどこに保管するのか、代行先の担当が替わるとき権限を何日以内に回収するのか、再委託があるかを確認します。再委託があれば、実際に自社の環境へ入るのは契約書に名前のない会社の人員です。

障害より頻繁なのが変更です。パッチと構成修正、リソース増設が毎週起こり、障害原因の相当数は直前の変更です。定期作業枠がいつか、緊急変更は誰が事後承認するのか、自社側の承認者が何人いるのかを先に決めます。締めや精算のように止められない予定はカレンダーに先に置き、その期間は作業枠を開けません。承認者が自社にいなければ、代行先が自ら変えて自ら記録する状態になります。

記録の形式も決めます。変更履歴が代行先担当者のチャットにしか残らなければ、担当が替わった瞬間に消えます。何をいつなぜ変え、戻すにはどの手順を踏むのかが一か所に残ってはじめて、障害調査で直前の変更を見つけられます。

承認にも時間の約束が要ります。自社の承認が遅れて作業が延びた件と、代行先が遅れて延びた件を分けて記録しなければ、遅延の責任は毎回あいまいになります。変更が失敗したときの切り戻し作業まで定額に含まれるかもここで決めます。

月次レビューはこの記録を読む場です。前月の障害と変更、未処理課題を同じ文書で報告してもらい、翌月にやることを決めます。レビューが指標を数枚読んで終わる会議なら、代行先は改善ではなく維持だけを売っています。

代行先が自社のツールで監視すると契約期間中は楽です。問題は終わるときです。ダッシュボードとアラート規則、しきい値が代行先の契約内にあると、契約が終わる日に監視も一緒に消えます。自社のサービスをどんな目で見てきたかが、まるごと他社の資産だったことになります。数年分の指標履歴も一緒に失われます。

ツールのアカウントを誰が所有するのか、アラート規則とダッシュボード定義を書き出せるのか、指標履歴を引き継げるのかを契約前に確認します。ランブックも同じです。障害の種類ごとの確認順序と対処コマンドが書かれた文書は運用資産であり、代行先が作ったものでも自社の保管場所に併せて残す取り決めにするほうがよいです。

アラートは件数で見ません。アラートが多いほど安全になるわけではなく、むしろ無視されやすくなります。前月に発生したアラートのうち実際の対処につながった割合を尋ねると、代行先がアラートを設計してきたのか、点けたままにしてきたのかが表れます。対処なく閉じるアラートが大半なら、当番はすでに通知を読んでいません。

見積は定額と従量の二通りで出てきます。定額は予算を立てやすい一方、その金額に何が含まれるかは契約ごとに違います。月何件までの依頼が含まれるのか、夜間の呼び出しが含まれるのか、何名を前提とした価格なのかが書かれていなければ、忙しい月ごとに追加請求が付きます。

従量は実際に使った分だけ払います。その代わり静かな月は安く障害の多い月は高いため、最も必要な場面で費用を理由に呼び出しをためらわせます。どちらを選ぶにせよ、別請求となる項目を一覧で受け取ってください。移行と再構築、新規構築、セキュリティ事故対応、定例レビューへの参加は運用定額から外れることがよくあります。一覧を見比べると、定額の高い提案のほうが総額では安い場合も出てきます。

クラウド利用料を代行先が再販する構造なら、マージン率を尋ねます。利用料と運用費が一枚の請求書で届くと、どちらが上がったのか見えません。コスト削減も併せて任せる場合は、利害がずれる点も確認します。利用料にマージンが乗る構造では、使用量が減れば代行先の売上も減ります。

契約条件そのものにも値段があります。オンボーディング費用が別に付くのか、最低契約期間が何か月か、自動更新条項があるのか、解約通知を何週間前に出す必要があるのかが、乗り換える自由の値段を決めます。初月の見積が安い代わりに解約通知期限が三か月の契約は、安い契約ではありません。

運用代行契約は始めるより終えるほうが難しく、だからこそ終了条項を契約前に読みます。引き継ぎの範囲と期間、並行運用を何週間行うのか、文書とスクリプトをどの形式で渡すのか、権限移管を誰がいつ行うのかが書かれている必要があります。引き継ぎを別費用として請求する条項があるかもこのとき見ます。

選び方を誤った契約が終わると、環境は残り説明が消えます。なぜこのリソースがあるのか誰も知らず、アラートは切られており、復旧手順は代行先担当者の記憶にしかなかった状態になります。次の代行先はその状態を把握するだけで数か月を使います。その時間も自社が払った代金の一部でした。代行先が悪い会社だから起きるのではなく、何を残すかを契約に書かなかったから起きます。

だから選ぶ基準は、毎月届く報告書よりも残る資産に近いものです。契約初月に何を受け取り最終月に何を返してもらうのかを提案書に書かせると、金額の近い二つの提案が別々の商品だったことが表れます。

短く始める方法もあります。一四半期分の範囲をまず任せ、その間に残る文書と応答記録を見て拡大を決めれば、判断の根拠は提案書ではなく実際の運用になります。試行期間を断る代行先より、試行期間に何を残すかを先に書いてくる代行先のほうが、契約の終わり方もおおむね整っています。