これは何か
運用設計書は、システムが本番で動き始めたあと、日々の運転（起動・停止・夜間処理・監視）、定期の作業（月次処理・バックアップ・棚卸し）、何かあったときの対応（障害・問い合わせ・変更）を、誰が・いつ・どの手順で・何を基準に行うかを決めた成果物です。
作る側は「本番稼働」を終わりと考えがちですが、使う側にとっては稼働の日が始まりです（14-01 稼働直後の集中対応期間、14-04 システムは完成しない）。運用設計書は、作る側の知識を、日々動かす側が使える形に移し替える文書です。個々の手順は OPS-003 運用手順書 に、監視の項目は OPS-002 監視・アラート一覧 に、障害の初動は OPS-004 障害対応計画 に分かれ、運用設計書はそれらの全体の骨組みです。
なぜ作るか
- 稼働後の作業を、作った人の記憶ではなく文書で引き継ぐ（OPS-009 稼働直後支援・運用引継ぎ計画）
- 「正常」とは何かを決め、監視で見るものと見ないものを決める（14-02 正常に動いているか何を見るのか）
- 障害・問い合わせ・変更のそれぞれで、誰が受け、誰が判断するかを決める
- 運用にかかる人と費用を見積もり、体制を用意する
誰が使うか・いつ作るか
- 作る人：本番移行・運用のリーダーと、運用を担当する会社。各システムの開発の取りまとめ役が内容を提供する
- 使う人：運用の当番、監視の担当、問い合わせを受ける窓口、障害対応の指揮者、業務部門のリーダー
- 一般的には、全体設計のあとに骨組みを作り、テストと移行のリハーサルで分かったことを反映し、稼働前に確定します
- アステリア案件の運用の体制、当番、作業の一覧、正常の基準は、正本に記載がありません。未確定
CASE FACTFROZEN正本に記載されたアステリア案件の事実
運用に関係する記載
- M18 本番稼働、M21 初期安定化完了
- システムに SYS-11 監視・ログ基盤がある。Vendor B クラウドブリッジの担当範囲に監視が含まれる
- P-011 山下 恵 — 本番移行・運用リーダー、P-010 宮田 直人 — テスト・品質管理リーダー、P-012 石井 稔 — セキュリティ責任者
- 重大障害判断は、AIへ最終委任しない事項
M18 から M21 までの間に、誰がどんな体制で運用し、何を正常の基準にしたかは、正本に記載がありません。未確定 上の人物がこの設計書を作成・承認したという記載もありません。未確定
主な項目
一般的には、次の項目で構成します。
- 運用の範囲と体制：対象のシステム、運用を担当する会社と役割、当番の組み方（昼・夜・休日）、連絡先
- 日々の運転：起動・停止の時刻、夜間処理の順番と終わる予定時刻、翌朝までに確かめること
- 定期の作業：月次・年次の処理、バックアップと保管の世代、アカウントと権限の棚卸し、部品の更新（DEV-005 使用ソフトウェア・依存関係一覧）
- 正常の基準と監視：何をもって正常と言うか（応答の時間、処理の終了時刻、エラーの件数）。監視で見る項目と、通知の先
- 問い合わせの受け方：窓口、記録、回答の期限、開発側へ回す条件
- 障害のときの動き：初動の連絡、重大度の仮の判定、指揮者、復旧と原因調査の分担（13-01 本番障害が起きたら最初に何をするか）
- 変更の受け方：稼働後の変更をどう受け付け、誰が承認し、いつ出すか（PRG-008 変更管理台帳）
- サービス品質の目標と報告：目標の値と、月次の報告の形（OPS-007 サービス品質目標一覧）
- 稼働直後の特別体制：集中対応期間の人数と期間、通常の体制へ戻す条件
教材用サンプル成果物の読み方を学ぶための例
教材用サンプル — 日々の運転の表と、正常の基準
この成果物は学習用サンプルです。FROZEN正本に記載されたCASE FACTと、成果物の読み方を学ぶための教材用サンプル値を区別して表示しています。
次の表は、設計書の書き方を学ぶための例です。内容はすべて教材上の架空の例で、アステリア案件の記録ではありません。
| 時刻（教材上の例） | 作業 | 担当 | 正常の基準 | 基準を外れたら |
|---|---|---|---|---|
| 22:00 | 夜間処理（工数の取り込み → 原価の集計 → 会計への連携）を開始 | 自動（監視は夜間当番） | 翌 04:00 までに全工程が終了 | 04:00 を過ぎたら夜間当番が手順書に従い確認し、06:00 までに終わらなければ指揮者へ連絡 |
| 06:30 | 夜間処理の結果確認 | 夜間当番 | エラー 0 件、件数が前営業日の ±30% 以内 | 外れたら業務部門の担当へ始業前に連絡 |
| 08:45 | 業務開始前の画面確認 | 昼当番 | 主要 5 画面が 3 秒以内に表示 | 遅い場合は監視の値を確認し、指揮者へ連絡 |
| 18:00 | 当日の問い合わせと障害の記録を整理 | 昼当番 | 未回答の問い合わせが期限内 | 期限超過があれば翌朝の会で報告 |
| 期間（教材上の例） | 体制 | 通常へ戻す条件 |
|---|---|---|
| 稼働から 2 週間 | 開発側の担当が運用の部屋に常駐。昼当番を通常の 2 倍 | 重大な障害がなく、問い合わせの件数が落ち着いたこと |
| 3 週目から 2 か月目 | 開発側は呼び出し対応。昼当番は通常の 1.5 倍 | 月次処理を 1 回、特別体制なしで終えたこと |
| 3 か月目以降 | 通常の体制 | ― |
読み方
- 「正常」が数値や時刻で書かれているか。「問題なく動いている」で終わっていないか
- 基準を外れたときに「誰が、いつまでに、何をするか」が書かれているか
- 日々・定期・何かあったときの 3 つが、それぞれ担当つきで書かれているか
- 稼働直後の特別体制と、通常へ戻す条件が書かれているか
- 運用手順書・監視一覧・障害対応計画と、矛盾していないか
書き方
- 運用の範囲と体制を先に決める（人と費用に直結する）
- 日々の運転を時刻の表にし、正常の基準と外れたときの動きを添える
- 定期の作業を暦に落とし、担当と期限を決める
- テストと移行のリハーサルで分かった「実際にかかる時間」「起きた問題」を反映する
- 運用の当番に読んでもらい、「自分の当番の言葉で説明できるか」を確かめる
何を書いてはいけないか
- 「適切に監視する」「速やかに対応する」のような、基準と期限のない決まり
- 開発側の人がいる前提の手順（引き継いだあとに回らない）
- 手順書・監視一覧と重複して書き、更新のたびにずれる内容（参照にとどめる）
- 連絡先として個人の携帯番号だけを書くこと（役割と当番表で書く）
どこを見るか
- 正常の基準（数値・時刻）
- 基準を外れたときの担当と期限
- 日々・定期・何かあったときの分担
- 稼働直後の特別体制と、戻す条件
- 手順書・監視一覧・障害対応計画との整合
赤信号
- 「正常」の基準がなく、障害かどうかを当番の感覚で決めている
- 夜間処理が遅れたときの連絡の基準がなく、翌朝になって業務部門が気づく
- 稼働直後の特別体制の終わりが決まっておらず、開発側がいつまでも抜けられない
- 設計書が稼働前に作られたまま、稼働後の変更が反映されていない
よくある失敗
- 運用設計を稼働の直前に始め、テストで分かった「実際の所要時間」が反映されないまま稼働する
- 監視の項目を増やしすぎ、通知が多くて誰も見なくなる（正常の基準を決めてから監視を決める）
- 作った会社と運用する会社が違うのに、引き継ぎの範囲が設計書に書かれておらず、稼働後に「誰がやるか」でもめる
関係するUnit・成果物・危機演習
- Unit：14-01 稼働直後の集中対応期間、14-02 正常に動いているか何を見るのか、13-01 本番障害が起きたら最初に何をするか、14-03 サービス品質を数値で管理する
- 成果物：OPS-002 監視・アラート一覧、OPS-003 運用手順書、OPS-004 障害対応計画、OPS-007 サービス品質目標一覧、OPS-009 稼働直後支援・運用引継ぎ計画
- 危機演習：この成果物を直接の題材にする危機演習はありません
AI WORKFLOW
AIは、運用設計書と、運用手順書・監視一覧・障害対応計画の間の食い違い（時刻、担当、基準）を探す下書きに役立ちます。
「次の運用設計書と運用手順書を読み比べ、同じ作業について、時刻・担当・正常の基準・外れたときの動きが食い違っている箇所を一覧にしてください。どちらが正しいかは判断せず、食い違いの箇所と該当する文だけを示してください。」
REVIEW
- AIが挙げた食い違いが、本当に食い違いか（表現の違いだけではないか）を元の文書で確かめたか
- AIが「正しい方」を決めていないか。どちらに合わせるかは人が決める
- 運用の文書を AI に渡してよいか（連絡先・構成情報の扱い）を事前に確かめたか
人間が判断すること
- 運用の体制をどの大きさで持つか（費用との釣り合い）
- 「正常」の基準をどこに置くか
- 稼働直後の特別体制を、いつ通常に戻すか
重大障害判断は、AIへ最終委任しない事項です（正本の方針）。
いつ使うか
この教材では STAGE 14｜稼働した後が本当のスタート の文脈で扱います。 アステリア案件での正式な作成・使用時期（月）は正本に記載がないため、未確定としています。
最後の問い
この設計書を読んだ運用の担当は、「稼働後、毎日・毎月・何かあったときに、誰が何をどの順で行い、何をもって正常と言うか」を、自分の当番の言葉で説明できますか？