インフラ運用設計の必須項目5選｜運用移管トラブルを防ぐチェックリスト

「構築プロジェクトもいよいよ終盤。要件通りのシステムが組み上がり、単体・結合テストもパスした。これでようやく無事にリリースできる……！」

そう胸を撫で下ろしたのも束の間。本番公開（Go-Live）の直後から、運用保守チームから次々と問い合わせやクレームの電話が鳴り響く。

「アラートが上がったんですが、これって誰にエスカレーションすればいいですか？」
「手順書通りにコマンドを叩いたらエラーが出たんですが、切り戻しの判断基準は？」
「夜間に通知が飛んできましたが、今すぐ対応が必要なものですか？」

結局、プロジェクトメンバーが本番運用のフォローに追われ、次の案件に着手できない――。こんな苦い経験はないでしょうか。

私はこれまで、大規模インフラの最前線で運用設計やサービスマネジメント（ITIL）に携わってきました。

構築PMやPL（プロジェクトリーダー）にとって、プロジェクトのゴールは「本番公開」に見えがちです。しかし、サービスを利用するユーザーや運用チームにとって、リリースは「運用のスタート地点」に過ぎません。

この記事では、「作ったけれど運用できない」という最悪の引き継ぎトラブルを防ぐために、構築PM/PLが押さえておくべき「運用設計書の必須項目」と、客観的にリリース可否を判断する「運用移管チェックリスト」の具体的な運用法を徹底解説します。

なぜ構築PM/PLは「運用移管トラブル」に悩まされるのか？

なぜどれほど優秀なエンジニアが集まっても、運用移管でトラブルが頻発してしまうのでしょうか。その根本には、構築チームと運用チームの「目的（インセンティブ）のねじれ」があります。

プロジェクトのゴールと運用保守スタートの「認識のズレ」

• 構築チーム（PM/PL）： 納期・予算・要件定義の達成が最優先。「動くものを期限内に納品・引き渡しすること」がゴール。
• 運用保守チーム： 安定稼働・障害時の迅速な復旧・日々のオペレーション事故防止が最優先。「リスクなく安全に運用できること」がゴール。

構築側が「動いているから大丈夫」と考えて引き継ぎ資料を渡しても、運用側からすれば「万が一のときの守り方が書かれていない」と映ります。

この認識のズレが解消されないまま本番公開を迎えると、リリース後にトラブルが爆発するのです。

ITILの「移行管理（サービストランジション）」視点で見る運用移管リスク

ITILの「移行管理（サービストランジション）」の観点でも、適切な運用設計を欠いたリリースは重大なリスクとみなされます。PM/PLが陥りがちな代表的なリスクは以下の3つです。

1. 監視アラートの閾値や一次対応フローが決まらないまま「見切り発車」
   • 「とりあえず全アラートをメール通知」にした結果、通知がオオカミ少年化し、重要アラートを見落とす。
2. 連絡網・エスカレーションルートの考慮不足による初動遅延
   • 深夜にCriticalアラートが発生した際、「誰から誰へ、何分以内に連絡するか」が決まっておらず対応が後手に回る。
3. リカバリ手順が「作ったエンジニアの頭の中にしかない」状態での引き継ぎ
   • 手順書に「必要に応じて再起動する」としか書かれておらず、現場のオペレーターが判断できずに詰む。

実務でそのまま使える！インフラ運用設計書の必須「項目」5選

運用引き継ぎの失敗を防ぐ最大の武器が「運用設計書」です。非機能要件の定義を実際の運用現場で機能させるため、運用設計書に必ず盛り込むべきコア項目を5つに絞って解説します。

① 日常・定期運用タスク一覧

日々のバックアップ確認、ログローテーション、SSL/TLS証明書の更新、定例再起動など、「いつ・誰が・何を・どの順番でやるのか」をスケジュールとして落とし込みます。

② 監視設計とアラート一次対応フロー

単に「アラートを検知する」だけでは不十分です。

• 通知の重要度分類（Critical / Warning / Info）
• アラートごとの一次切り分け手順（例：ping応答がない場合はまずポート状態を確認するなど）
• 自動復旧の有無

これらが整理されて初めて、運用オペレーターは正しく判断できます。

運用側の視点や、オペレーターが現場で求める手順書のレベル感を深く理解したい方は、以下の「運用監視オペレーター脱出ロードマップ」の記事もあわせて読むと、より実効性の高い運用設計が可能です。

③ エスカレーションルートと連絡網

障害発生時、時間帯（日中・夜間・休日）や緊急度に応じて「誰に・どのような手段で・何分以内に報告するか」の連絡ラインを明記します。

SLA（サービスレベル合意書）やOLA（組織内運用合意書）を意識し、想定される許容ダウンタイムに合わせた報告ラインとレスポンス目標時間を設定することが不可欠です。

④ 障害一次対応・リカバリ手順書

最も重要なのが「切り戻し（Rollback）」を含むリカバリ手順です。サービスの再起動手順だけでなく、正常性の確認コマンド、ダメだった場合の切り戻し判断基準までを一セットで記載します。

⑤ 運用体制と権限マトリックス（RACI）

「誰が作業を実行し（R）、誰が責任を持ち（A）、誰に相談し（C）、誰に報告するのか（I）」というRACIマトリックスを定義します。

これにより、リリース後の「これってどっちのチームがやるの？」という責任の押し付け合いを防ぎます。

【実体験】「机上確認」の罠！リカバリ手順書・リストア検証の実践法

ここでは、私が過去に携わった現場で実際に起きた「ヒヤリとする失敗談」をご紹介します。手順書を整備したつもりでも、検証方法を誤ると本番で手痛いしっぺ返しを喰らいます。

起動・停止はOKでも「データ復旧」で詰まるケース

ある大規模なインフラ移行プロジェクトでのことです。運用テストフェーズにおいて、サーバーの起動・停止手順や、日次のバックアップ手順については、全サーバーで実際にコマンドを叩いて実機検証を実施し、「問題なし」と判断していました。

しかし、「既存データを上書きするリストア（データ復旧）試験」だけは、本番環境への影響やテストデータの作成コストを恐れ、「手順の目視確認（机上確認）」だけで済ませてしまっていたのです。

「バックアップが取れているんだから、戻すコマンドも通るだろう」――チーム全体にそんな油断がありました。

本番リリース後に発覚した「想定時間の大幅超過」

本番リリースから数週間後、設定変更作業に伴うトラブルが発生し、急遽データをバックアップからリストアして「切り戻し」を行う事態になりました。

あらかじめ作成していた切り戻し手順書に従ってリストアを開始したのですが……想定していた時間を遥かに超えても処理が終わりません。

実は、対象データベースの容量が大きくなった際のリストア速度や、展開時のディスクI/O負荷を考慮できておらず、机上計算の数倍の時間がかかることがその場で判明したのです。

結果として、メンテナンスの予定時間を大幅に超過し、早朝のサービス稼働開始に遅延の影響を出してしまいました。

教訓：切り戻し・リストア手順こそ「実時間」を計測せよ

この苦い経験から得た最大の教訓は、「切り戻しやリストアなどの非常時手順こそ、実機で実際に動かして『所要時間』を計測しなければ意味がない」ということです。

• 手順に誤りがないか（コマンドやパスの不備はないか）
• 想定どおりの時間で完了するか（許容されるダウンタイム内に収まるか）

手順書を作る際は、単にやり方を書くだけでなく、「この処理には実測で〇〇分かかる」という時間軸のデータを添えて運用チームへ渡すことが、PM/PLとしての本当の配慮です。

構築終盤におけるテスト観点の洗い出しや、漏れのない計画の立て方については、以下の「インフラ試験の観点リストと書き方]」の記事でも詳しく解説しています。

感覚に頼らない！運用移管を成功させる「チェックリスト」と判定基準

リリース直前になると、「多少の不備はあるけれど、納期があるからGoにしたい」という圧力が強まりがちです。しかし、感情や雰囲気に流された判定は、リリース後の大炎上を引き起こします。

客観的にリリース可否を判定するため、以下のような「運用移管判定チェックリスト」を設け、判定ゲート（Go/No-Go判定会議）を必ず通過させる仕組みを作りましょう。

PM/PLが使える「運用移管判定チェックリスト」

判定カテゴリ	チェック項目例	必須/任意	判定結果
ドキュメント	運用設計書・各種手順書が作成され、運用チームの承認を得ているか	必須	Pass / Fail
監視設定	本番同等の監視設定が完了し、テスト通知の受電確認ができているか	必須	Pass / Fail
運用テスト	実機での障害リカバリ・リストアテストを実施し、所要時間を計測したか	必須	Pass / Fail
連絡体制	夜間・休日を含むエスカレーションルートと緊急連絡網が確定しているか	必須	Pass / Fail
引き継ぎ	運用チームへのレクチャー（講習会）を実施し、質疑応答が完了しているか	任意	Pass / Fail

「条件付きGo」を決断する際のリスクマネジメント

プロジェクトの事情により、どうしても「未完了項目」を抱えたままリリースせざるを得ない場合があります（いわゆる「条件付きGo」）。

この判断を下す場合、PM/PLは以下の3原則を厳守してください。

1. 「必須項目」の未完了によるGoは絶対に行わない（監視未設定やリストア未検証でのGoは極めて危険）
2. 残課題の「対応期限」と「暫定運用フロー（誰がカバーするか）」を明文化する
3. 構築チームの初期手厚いサポート期間（ハイパーケア期間）を延長する

まとめ｜運用のしやすさは構築フェーズの品質で決まる

インフラ構築プロジェクトの本当のゴールは、「システムを単に完成させること」ではなく、「運用保守チームが安全・確実にシステムを維持できる状態を作ること」です。

• 運用設計書には「平常時」だけでなく「障害時の切り戻し」まで具体化する
• リストアやリカバリ手順は、机上確認で終わらせず「実際の所要時間」まで計測する
• 運用移管チェックリストを設け、客観的な基準でリリース可否を判定する

とはいえ、多忙なプロジェクト終盤にこれらの項目をゼロからドキュメント化するのは至難の業です。

属人化を防ぎ、効率よく移管を進めるためには、自社（あるいは自分自身）で汎用的な「運用設計書テンプレート」や「移管チェックリスト」の標準フォーマットを持っておくことが、PM/PLとしてプロジェクトを円滑に回す強力な武器になります。

これらを構築フェーズの段階から計画に組み込んでおくことで、リリース後のトラブルは激減し、運用チームからも「〇〇さんのプロジェクトは引き継ぎが本当にスムーズで助かる」と絶大な信頼を得られるようになります。

プロジェクトを「綺麗なバトンタッチ」で締めくくるために、ぜひ次の案件から「運用設計」と「移管判定ゲート」を実践してみてください！