テンプレートを探す
1本ずつ探すより、使う場面や構成の層でまとまったセットから選ぶほうが早いことがあります。
セットから選ぶ
キットをすべて見る →情報通信 のために作った文書17 件
その業種の決まりや現場の言い方に合わせてあります
バックアップ・リストア設計/手順書
「取れている」ことと「戻せる」ことは別、を構造にした型。設計シートに最終リストア試験日と経過日数を持たせ、1年以上戻していない対象は赤、半年以上は橙になります。保存先を一次・二次の2列にして、同じ装置・同じ拠点にしか無いバックアップを橙で見せます。RPO/RTO・世代・復旧優先度が空だと赤。★「効かない事象（この方式で守れないもの）」を必須の列にしました——全ての事象に効くバックアップは存在しないので、空欄は「考えていない」の証拠になります。★レプリケーション・スナップショットは「取れている」が単独ではバックアップにならないため、方式のセルが薄紫になります（誤削除は数分で複製先へ伝わり、装置が壊れれば一緒に失われます）。記入例には、見落としやすい★仮想化基盤ホストの構成（管理サーバー側のバックアップに含まれない）と★バックアップサーバー自身の構成情報も入れてあります。リストア手順はファイル単体／サーバ全体／データベース／コンフィグの4パターンを展開済みで、試験記録の所要時間がそのままRTOの実測値になります。
ヒアリングシート（Excel・要件定義／インフラ更改・記入例つき）
全質問に「記入例」列を持つヒアリングシート。回答品質は記入例の質で決まります。必須／任意を分け、必須が埋まれば次工程へ進める設計です。
ブロックストレージ パラメータシート（Dell・HPE・富士通 ほか）
Dell PowerStore・Unity、HPE Nimble・Alletra、富士通 ETERNUS などを想定していますが、★ベンダー非依存で書いています。呼び名が違うだけで、設定する項目と踏む失敗は同じだからです。NetApp ONTAP は別シートで、どちらを採用するかの選択になります。★記入例はSANの鎖として繋いであります（サーバー本体 → HBA → FCスイッチのゾーニング → ストレージのホストマッピング → 仮想化基盤のデータストア）。★核は3枚です。（1）ホストマッピング設計 … ★ゾーニングで見えるようにしても、ストレージ側で割り当てなければ見えません。「ゾーンは通っているのに見えない」の正体で、見えるまでに2段階あります。そして★共有前提でないOSに同じボリュームを複数台から見せるとデータが壊れます。動かないのではなく壊れるので取り返しがつきません。（2）マルチパス設計 … ★冗長のはずが片パスで動いている、が構築直後から起きます。マルチパスの仕組みを入れていないと同じボリュームが複数のディスクとして見え、パスの本数は数えないと分かりません。（3）プールと容量設計 … ★プールが満杯になると、そのプール上の全ボリュームが書けなくなります。都度確保では割り当ての合計が物理容量を超えても作れてしまいます。
ポート結線表・配線表
設計書ではなく、現地作業の指示書としてそのまま使える結線表。両端の機器とポートを書けば、ケーブルに貼るラベル表記が数式で出ます。ポート一覧は機器ごとに全ポートを展開する方式で、空きポートが行として見えるため増設のたびに現地で数える必要がありません。規格ごとの最大距離とコネクタをまとめたメディア早見表つき。
メール基盤 パラメータシート（メール・グループウェア）
ドメインとしてのメール基盤（送信ドメイン認証・経路・受信の保護）のパラメータシートです。★サービスに依存しない書き方にしています。クラウドでもオンプレでも踏む失敗は同じだからです。★核は3枚です。（1）送信ドメイン認証設計 … ★SPF は1つのドメインに1レコードしか置けません。複数あると評価が失敗して全部が通らなくなります。サービスの案内どおりに「TXTレコードを追加」してしまい、2つ目ができる事故が多い項目です。★DNSを引く回数にも上限（10）があり、include を重ねると超えて失敗します。空振りする参照にも上限（2）があります。そして★DMARC は「SPFが通っている」だけでは成立しません（ドメインが揃っている必要があります）。（2）経路と送信元設計 … ★抜けるのは人が読むメールではありません。業務システムの通知・監視の通知・複合機からの送信・外部サービスです。★届かないことに、障害のときまで気づけません。（3）受信と保護設計 … ★外から来た自ドメインの差出人を止めます。最も使われる手口です。★SPFの規格値は RFC 7208 で裏を取っています。★Microsoft 365 シートはテナント側（条件付きアクセス・外部共有）で、メールの基礎には触れていません。
ラック搭載図（1U単位）
1U単位のマス目で前面・背面を描くラック搭載図。空きUがマスとして見えるので、増設のたびに現地でUを数える必要がありません。ラックごとに使用U・空きU・重量・消費電力を自動集計し、ラックの上限（U数・耐荷重・電源容量）を超えると赤くなります。PDUのコンセント割当を全展開する電源系統シートつき。搭載してから「入らない・重量が超える・電源が足りない」と分かるのが一番まずく、その場では何もできません。
不具合管理表
「おかしい」だけの報告は直せません。再現手順と期待動作を必須の列にして、空欄は赤くなります。期待動作が書けないものは不具合ではなく仕様の確認なので、QA管理表へ回す運用にしました。修正しただけでは閉じられず、再試験の結果が「合格」で初めて完了になります。検出工程を残して工程別に集計するので、受入試験・本番で出た件数がそのまま前工程の試験の足りなさを示します。原因分類ごとに「本来どの工程で防ぐか」を持つ再発防止シートつき。
作業手順書（本番作業の型）
「判断ポイント（続行/切り戻しの条件とリミット時刻）」を独立シートとして持つ作業手順書。判断リミットは「作業枠の終了−切り戻しの所要合計−予備」を数式で計算します。予定時刻は所要時間の積み上げで、実施時刻との差も自動計算。構築・移行・定期作業すべてこの型から派生できます。
切り戻し手順書
切り戻しは「頭の中にある」で済まされることが最も多い文書です。手順ごとの所要時間を積み上げ、その合計から最終判断時刻を数式で逆算します（業務開始時刻 −（切り戻し所要 ＋ 復旧確認 ＋ 業務部門の確認 ＋ 余裕））。手順を1つ足せば合計が増え、判断時刻が自動で早まります。戻す対象を機器・設定だけでなく名前解決・監視・バックアップの向き先まで洗い出し、「戻せなくなる時点」を列として持ちます。戻した後の復旧確認10項目と、実際に戻して測った検証記録つき。
基本設計書（方式と方針の型）
「基本設計＝方式と方針、詳細設計＝具体的な値」の線引きを章構成で体現。設定値はパラメータシートに書き、本書には書かないことで二重管理を防ぎます。
定期作業カレンダー（年間）
月次より長い周期の作業は、決めた直後は覚えていても半年後には誰も覚えていません。年間を1枚に並べ、当月の列を数式で自動強調します（日付を手で書き換える運用にすると、必ず古いまま配られるため）。●を置くだけのカレンダーにして手順は各文書へ飛ばし、リストア試験・アカウント棚卸し・ライセンス棚卸し・EOSL更改計画など、他のテンプレートの点検を年間の時間軸に載せています。実施記録の申し送りから翌年度の計画を作る構成です。
構成図テンプレート（作図ルール＋部品集）
雛形・記法ルール・アイコン部品集のセット。新設＝赤枠／撤去＝グレーアウトなど更改案件の描き分けを標準化します。Visio不要、PPT標準図形のみ。
構成管理・自動化 パラメータシート（Ansible / Terraform）
Ansible / Terraform で構築を自動化するときのパラメータシート。オンプレのインフラ屋に向けて、コードで作ること自体ではなく**コードで作った後に何が起きるか**を書いています。★核は3枚です。（1）差異と状態 … 緊急対応では必ず手で直されます。それは止められないので、戻す手順と期限を先に決めておかないと、コードと現物が静かにずれます。ずれていても普段は誰も困らず、困るのは作り直すときで、そのときには手遅れです。Terraform の状態ファイルは「コードと現物の対応表」で事実上の本体です。失うと作った資源を管理できなくなります（変えることも消すこともできません）。（2）適用の作法 … 適用の前に何が変わるかを見て、適用の後にもう一度流します。属性によっては変更できず「消してから作り直し」になるため、見ずに流すと本番が止まります。「1回目は通るが2回目で壊れる」は本番で初めて出るので、構築時に必ず2回流します。（3）設定時の注意 … この分野で実際に起きる24の失敗と、その回避手順。★項目名の（A）は Ansible、（T）は Terraform 固有です。★既定値は製品と版で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
構築チェックリスト
構築は「やったつもり」が最も多い工程です。機器を列に置いて1枚で全台の状況が見えるようにし、○＝確認して問題なし／×＝不合格／−＝対象外／空欄＝未実施を区別します。必須項目の達成率を機器ごとに数式で出すので、「だいたい終わった」で引き渡せません。搬入・据付から電源・ネットワーク・ハードウェア・OS・セキュリティ・運用・文書まで30項目。判断に迷う項目の確認手順と判定基準、引き渡しの完了判定と判定記録つき。
機器一覧（ハードウェア台帳）
機器IDを全シート共通のキーにしたハードウェア台帳。保守契約とEOS/EOSLの期限が近い行・過ぎた行は自動で色が付き、更改の検討漏れを防ぎます。U数・重量・消費電力はラック単位で自動集計され、ラック搭載図と電源設計の入力になります。光モジュールやディスクなど、保守がモジュール単位で発生する部材の台帳つき。
現行環境調査報告書
ヒアリングシートが「聞いたこと」なら、こちらは「調べた事実」です。申告値と実測値を並べて一致／差異を数式で出すので、「サーバは10台」と言われて実機が13台だった、が表の上で見えます。出典（誰から聞いたか・どの出力か・いつ時点か）を必須の列にし、空欄は赤。調べていない項目を空欄にせず「未調査／調査不可」を状態として残し、網羅状況を数式で集計します。用途不明のサーバ・誰も知らない通信・手順書の無い手動バッチを集める「未確認・用途不明」シートが、この調査の最大の成果になります。課題は根拠と費用・期間への影響つき。
監視基盤 パラメータシート（製品非依存）
監視基盤（Prometheus / Grafana / Zabbix ほか）のパラメータシート。監視の仕組みそのものをどう組むかを決めます。製品には依存しません（何を使っても決めることは同じです）。ここから先は Prometheus / Grafana / Zabbix などを想定しています）。★「監視項目一覧」が何を監視するかの表なのに対し、本書は仕組みの側です。監視項目一覧に書いた項目を、この基盤で実際に見られるようにします。★核は3枚です。（1）監視の監視 … 最も重い枚です。監視基盤が止まっても、止まったことを知らせる相手が居ません。「アラートが来ない」は「異常が無い」ではなく「監視が死んでいる」かもしれません。静かなほど安心に見えるので、気づくまでに何日もかかります。（2）保存と容量 … 時系列のデータは増え続けます。保存期間を決めていないとディスクが尽き、ある日突然この基盤自体が落ちます。しかも「過去のデータが要る」と気づくのは障害の後です。（3）通知の設計 … 設定しただけで、実際に届くか試していない例が多くあります。抑制（メンテナンス中の停止）を解除し忘れると、以降ずっと黙ります。★既定値は製品と版で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
どの業種でも使う文書7 件
議事録・WBS・体制表など。業種を問わず同じ形で使えます
プロジェクト計画書
「対象外事項」と「前提条件」を独立章として構造化した計画書。スコープクリープと後々の揉め事の大半は、ここの曖昧さから生まれます。★成功基準に「判定時期／判定者」、対象外事項に「理由／必要になった場合の扱い」、前提条件に「崩れたときの影響」の欄を設けました。管理方針は各領域で使う文書（WBS・課題管理表・リスク管理表など）まで決めます。
リスク管理表
リスクは「まだ起きていない問題」なので、放っておくと誰も見ません。可能性×影響度でリスク値を数式で出し、数字で並べ替えられる形にしました（15以上は赤、8以上は橙）。「高・中・低」で書くと、付けた人によって基準が変わり、上位から順に見ることもできません。点数の付け方は評価基準シートに置き、対応後の可能性・影響度から残リスクも数式で出します——対応策を書いただけで安心する状態を防ぐためです。見直し記録で、点数を変えた理由まで残します。
会議体・連絡体制定義
立ち上げで「週次定例は木曜10時」までは決めるのに、**その会で何を決められるのか**と**決まらなかったらどこへ上げるのか**が書かれないまま進みます。結果、同じ課題が毎週の定例に出続けます。★核は3つ。（1）会議体ごとに「決める人」を書かせる … 出席者を並べただけの表では、誰が決裁できるのか分かりません。決裁者が出ない会は報告会だと明示します。決める人が空の会は赤くなります。（2）決まらなかったときの上げ先を会議体IDで書かせる … 会議体どうしを繋ぎます。最終決定の場は「—」と書きます。ここを空欄にすると、決まらなかった課題の行き先が無くなります。（3）障害時の連絡を別シートにする … 平常時の会議体とは別物です。重要度と時間帯の組で経路を決め、**応答が無かった場合に何分で次へ行くか**まで書きます。★一次連絡先を個人の携帯にしないこと（1人が出ないと止まります）。報告物と提出先のシートもあり、どの文書をどの会にいつまでに出すかを対応させます。ここに出てこない文書は、作っても読まれません。
体制・役割分担表（RACI）
体制図は作るのに、**どこまでが自社の責任か**が曖昧なまま運用に入ります。RACI を作っても R（実行）と A（説明責任）の区別が付かず、両方に印を付けた表になっていることが多いです。★核は3つ。（1）Aは1つの作業に1人だけ … 数式で数えて、0人でも2人以上でも行が赤くなります。「みんなの責任」は誰の責任でもありません。R（実行）が0人の行も赤——実際に誰もやらない作業がそこに出ます。（2）同じ作業でも構築時と運用後で担当が変わる … フェーズごとに行を分けて両方書きます。1行にまとめると、引き渡した後に誰がやるのかが消えます。★記入例では「台帳の更新（運用後）」をわざとR不在にしてあります——運用に移ったあと最初に落ちるのがここで、半年後に台帳が実機と合わなくなります。（3）責任分界点を別シートで持つ … 「どこまでが自社か」は作業の割り振りとは別の話で、契約と障害時の切り分けに効きます。回線・電源・機器・OS・監視・バックアップ・データの領域ごとに、境界の証跡（ケーブル1本、サイン1枚、契約番号）まで書かせます。
変更管理表
障害の多くは「変更した直後」に起きます。何を・いつ・誰の承認で変えたかが残っていないと、障害の切り分けで最初に詰まります。承認日より前に実施日が入っている行と、承認日が無いのに実施日がある行を赤くして、承認なしの実施を表の上で見えるようにしました。切戻し手順が空の変更、実施したのに結果・事後確認が空の変更も赤。標準変更（事前承認済みの定型作業）を区分として持ち、通常変更の申請に添える影響確認チェックリスト15項目つきです。
完了報告書
「無事完了しました」で終わる報告書が最も多く、そう書かれた瞬間に、残っているものが誰の担当でもなくなります。この型は3つを構造にしました。★プロジェクト計画書で決めた成功基準に1つずつ判定を付ける（照合しないなら計画書に書いた意味がありません）。★計画との差分を期間・費用・スコープの数字で書く（「おおむね計画どおり」は差分を書いていないのと同じ）。★残作業に「誰が・いつまでに・どこで管理するか」の3つを必ず書かせる。振り返りは「続けること／やめること／次に変えること」の3分類で、一般論を書く欄を作っていません。
提案書
提案書は放っておくと「自社ができること」を並べた資料になります。ですが読む側が知りたいのは、**自分たちの課題にどう答えるか**と、**何が含まれていないか**の2つだけです。★このテンプレートは、3枚目を「お客様の課題／出典／この提案／効果」の1対1の表にしています。課題には出典（ヒアリングシート・現行環境調査の番号）を付けます——出典の無い課題は、提案する側が想像で書いたものです。効果は測れる形で書きます（記入例は「一次対応15分以内（SLA/SLO SL-06）」「保守期限切れの機器 0台」）。「安定します」「効率化します」は効果ではありません。★5枚目は「含まれるもの／含まれないもの／含まれない理由」に1枚まるごと使います。ここを書かない提案書は、受注後に「これも入っているはず」で必ず揉めます。★6枚目の概算費用は**5年総額の行**を持たせています。初期費用だけを見せると、保守やライセンスの年額が後から出てきます（記入例に金額は入れていません。内訳の項目と行だけが型です）。★7枚目は調達のリードタイムから逆算した**発注の締切**を赤く出します。ここを示さないと「検討します」のまま日程が成立しなくなります。全10枚、16:9。発表者ノートに、そのページで話すことと外してはいけない点を入れてあります。