運用設計とSLA策定
運用は要件定義の一部として先に決める
納品して終わりの開発は、障害が起きた瞬間に信用を失います。逆に、運用設計とSLA（Service Level Agreement）を要件定義の段階から織り込むと、障害対応の速さ・品質・コストの見通しが一気にクリアになります。決める順番はシンプルです。「誰のどの体験を守るか」→「数値（SLO/SLI）」→「計測と監視」→「体制と手順」→「自動化と継続改善」。この順を外すと、あとで現場が回りません。
運用で最初に決めるチェック項目
- 重要ユーザー体験：カート投入、決済、検索、API呼び出しなどの守るべき操作
- 運用機能の範囲：監視（可用性/遅延/エラー率）、ログ保全、バックアップ、キャパシティ計画、権限管理
- 体制：一次受付、二次対応、オンコール、エスカレーション経路、意思決定権限
- 窓口時間とチャネル：平日9:00–18:00/24×7、メール/チャット/電話、重大度での切り替え
- 変更管理：リリース基準、凍結期間、ロールバック条件、緊急変更の承認
- コストと指標：オンコール手当、監視ツール費、SLA未達時の補償形態
これらは設計書の巻末ではなく、非機能要件の中心に置きます。要件の曖昧さをAIで下書きするのも有効です。たとえばChatGPTやClaudeで「SLAの除外条件」文例を複数生成し、法務・現場でレビューしやすくします。Geminiで過去障害のログを要約し、監視しきい値の初期案に落とし込むのも手です。
SLA/SLO/SLIを合意可能な数値まで落とす
SLAは対外合意、SLOは内部目標、SLIは計測指標です。言葉だけでは運用にならないので、以下の粒度まで数値化します。
- 可用性：月間稼働率99.9%（許容停止43.8分）。計測点はユーザー操作のP95成功率を合成
- 応答時間：P95で検索API 800ms以下、カート追加 500ms以下
- エラー率：HTTP 5xxは5分平均で1%未満
- RPO/RTO：RPO 15分、RTO 60分（決済系はRPO 0、RTO 30分）
- サポート：重大度1の一次応答10分以内、暫定復旧60分以内、恒久対策を5営業日内提示
重大度定義と例
- SEV1：売上直結の操作が全滅または50%以上で失敗。経営報告と24×7対応
- SEV2：一部機能の劣化。営業時間は即時対応、時間外は翌営業日
- SEV3：回避策ありの軽微。次回リリースで解消
数値は「どこから、誰が、どう測るか」を明記します。例：監視は外形監視と内部メトリクスの両方、集計はUTC、障害判定は連続3分超の基準違反、除外は計画停止・ユーザー環境依存・基盤事業者の大規模障害。補償はクレジット上限を月額の20%とし、遅延報告で無効化など。文言はCopilotでコードに計測フックを埋め込み、監視ダッシュボードの定義と同期させるとズレません。
インシデントと変更の運用フローを設計する
障害はフローで短くします。Runbook・エスカレーション・コミュニケーションの3点を標準化します。
標準フロー（要点）
- 検知：SLO違反を自動検知。SEV自動推定とオンコール呼び出し
- 一次切り分け：5分で範囲確定。影響/開始時刻/対象KPI/暫定対処を記録
- 連絡：テンプレで社内外に告知。頻度はSEV1で15分ごと更新
- 暫定復旧：トラフィック迂回、機能フラグOFF、ロールバック
- 恒久対策：事後分析、アクションにオーナーと期限を設定、追跡
RACIは「インシデントコマンダー（判断）」「コミュニケーションリード（対外）」「テックリード（技術）」「ビジネス連絡窓口（商用影響）」を固定します。変更管理はリスクスコアで自動化し、エラーバジェットを下回ったら新機能リリースを停止し信頼性改善に全振り、という運用に切り替えます。障害時の外部向け文面はChatGPTで草案を作り、Claudeで平易表現へリライトしてから承認に回すと速いです。
身近な企業活用例：地方で20店舗を展開する中堅スーパーのEC刷新
状況：店頭連動のECを刷新。従業員は全社で約300名、ECは月間注文2万件。初期運用は「営業時間サポートのみ・監視はサーバー死活中心」。
失敗：連休セール初日、検索のP95が5秒超に悪化。死活監視は通っていたため検知が遅れ、2時間で離脱が急増。重大度定義がなく、誰が判断するか曖昧で復旧に手間取りました。推定の機会損失は数百万円規模、カスタマーサポートもパンク。
改善：運用設計から見直し。SLOを「稼働率99.9%、検索API P95 800ms以下、決済成功率99.95%」に設定。SLIは外形監視と実トランザクションで二重化。RPO 15分、RTO 60分。重大度はSEV1〜3を導入し、SEV1は24×7でオンコール。Runbookに「検索が遅いときの暫定復旧（キャッシュ層増設→機能フラグで高負荷機能を一時停止→トラフィック整流）」を明記。変更はブルーグリーン＋自動ロールバック。通知テンプレを整備し、Geminiでエラーログを要約して一次切り分けに活用、Copilotでメトリクス計測コードを追加。障害報告書はClaudeで下書きし、社内共有を迅速化。外部向けステータスはChatGPTで初稿を生成して法務チェックを短縮。
結果：次の大型セールではスパイク時に自動で機能フラグが発火し、MTTRは72分→18分に短縮。サポート問い合わせは30%減、NPSは+12。SLAの未達はゼロに近づき、運用コストはオンコール最適化と自動化で月20%削減。経営側の意思決定（販促投下量やリリース可否）も、SLOとエラーバジェットを見ながら行えるようになりました。
受託開発ソリューション事業との接点
受託開発では、要件・設計・開発・テストの各工程に運用設計とSLAを埋め込み、RFP段階で「守る体験」と「測り方」の仮説を提示することが、契約の透明性とプロジェクト成功率を高めます。SLAは納品後の保守契約だけでなく、設計の優先順位やテスト観点、監視の実装、変更リスクの取り扱いまで一貫させるための共通言語です。開発の成果物と運用の現場が同じ数値で会話できるようにしておくこと—それが受託開発ソリューション事業における信頼性と継続価値の土台になります。
