テンプレートを探す
1本ずつ探すより、使う場面や構成の層でまとまったセットから選ぶほうが早いことがあります。
セットから選ぶ
キットをすべて見る →切り戻し手順書
切り戻しは「頭の中にある」で済まされることが最も多い文書です。手順ごとの所要時間を積み上げ、その合計から最終判断時刻を数式で逆算します（業務開始時刻 −（切り戻し所要 ＋ 復旧確認 ＋ 業務部門の確認 ＋ 余裕））。手順を1つ足せば合計が増え、判断時刻が自動で早まります。戻す対象を機器・設定だけでなく名前解決・監視・バックアップの向き先まで洗い出し、「戻せなくなる時点」を列として持ちます。戻した後の復旧確認10項目と、実際に戻して測った検証記録つき。
移行判定チェックリスト（Go/NoGo）
移行の失敗は、作業ミスより判断の遅れで致命傷になります。「まだいけるかもしれない」で最終判断時刻を越えると、切り戻す時間が無くなります。判定を1回にせず、前日・開始前・中間・最終判断の4点で判定する構成にしました。Go条件とNoGo条件を両方書かせ、片方でも空だと赤くなります——当日に「これはNoGoか」を議論すると必ず遅れるためです。最終判断時刻は「業務開始時刻 −（切り戻し所要時間＋確認時間＋余裕）」で逆算します。
移行計画書
「判定基準」「切り戻し発動基準」「最終判断時刻（ポイント・オブ・ノーリターン）」を必須の構造として持つ移行計画書。移行の失敗は作業ミスより判断の遅れで致命傷になります。
移行設計書（データ移行・件数の突合つき）
移行設計書です。移行のフェーズには移行計画書・移行判定チェックリスト・切り戻し手順書がありますが、どれも**いつ移すか・戻すか**の文書で、**何を・どう移すか**を書く文書がありませんでした。ここを埋める1本です。★核は「件数の突合」です。「移行しました」では終われません。**移行元 − 対象外 − エラー ＝ 移行先**が成り立つことを数式で示します。合わないまま本番へ行くと、足りないことに後から気づけません。記入例のFWポリシーは差が2件出たまま「完了」になっていて、行ごと赤くなります。★桁あふれ・未定義コード・重複は、実データを流すまで出ません。「入るはず」で設計され、リハーサルで初めて落ちます。項目マッピングに「事前に洗うもの」の欄を持たせ、件数が残っている行は橙、対応が空の行は赤にしました。★移行しないものも必ず行にします。「全部持っていく」は決めていないのと同じで、当日に「これは移すんでしたっけ」が出ます。理由が空の行は赤です。★リハーサルの所要時間を残します。移行計画書の「最終判断時刻」は作業枠から逆算しますが、その枠に収まるかはリハーサルの実績でしか分かりません。記入例の1回目は240分の枠に対して268分で、28分超過しています。