なぜ契約前に話すのか
リリース後に「想定と違った」となりやすいのが、障害時の連絡と復旧の期待値です。
先に最小セットを揃えておくと、見積・保守費用の説明もしやすくなります。
後回し
連絡先が曖昧
復旧時間の期待ズレ
追加費用の争い
先に合意
連絡経路が決まっている
優先度と目安時間
範囲外は別途見積
最小セットの5項目
最初から完璧なSLA表は不要です。次の5つが書かれていれば、実務の出発点になります。
除外・費用の扱い
範囲外と追加見積
応答・復旧の目安
優先度ごと
連絡先と受付時間
まずここ
上から詳細化してよい
- 連絡手段（メール・電話・チケット）と受付時間
- 障害の優先度の定義（例：業務停止／一部不具合／軽微）
- 初動応答の目安（例：業務時間内○時間以内）
- 復旧または回避策の目安（ベストエフォートか、時間目標か）
- SLAの対象外（顧客側の操作ミス・第三者障害など）
発注側が用意するとよいこと
開発会社に丸投げするのではなく、自社の業務影響を伝えられると、現実的なSLAに落ちます。
「何時までに直らないと困るか」「誰が最終判断するか」を社内で共有しておきましょう。
業務影響を整理止まったら困る時間帯
最小SLAを提案双方で文言を確認
契約に反映別紙・保守条項
よくある質問
SLAは大企業向けの話ではないですか？
規模に関係なく、「障害が起きたとき誰が何時間以内に動くか」は業務に直結します。小さくても、連絡手段と初動の目安だけ決めておくと、トラブル時の不安が減ります。
24時間365日は必須ですか？
必須ではありません。業務時間内対応・翌営業日対応など、自社の許容とコストのバランスで決めます。重要なのは、契約書か別紙で「合意した内容」が書かれていることです。
開発フェーズと運用フェーズで分けるべきですか？
はい。開発中の不具合対応と、本番稼働後の障害対応では、連絡先・優先度・費用の扱いが違います。フェーズごとに最小セットを書いておくとよいです。