テンプレートを探す
1本ずつ探すより、使う場面や構成の層でまとまったセットから選ぶほうが早いことがあります。
セットから選ぶ
キットをすべて見る →情報通信 のために作った文書15 件
その業種の決まりや現場の言い方に合わせてあります
監視項目一覧
監視が機能しなくなる最大の原因は、閾値の設定ミスではなく★アラートが多すぎて誰も見なくなることです。項目ごとに「想定発報数（件/月）」を持たせ、合計と★1日あたりの件数を数式で出します——1日10件を超えたら、その監視は運用に渡してはいけません。★もう1つの原因は「起きても業務が動いてしまうもの」で、v3 では「業務影響（即時／性能／潜在）」の列を足しました。冗長が失われた状態（パスが1本・スタックが1台・HAが片系・仮想IPが待機系）、バックアップの失敗、保存先の空き、ログ転送の停止、レプリケーションの遅れ、書込キャッシュ保護部品の劣化、証明書の期限は★起きても業務は動く＝潜在で、監視に入れていなければ次の1つで全断になるまで誰も気づけません。★潜在なのに重要度が「通知」の行は赤くなり、件数も集計されます。一次対応（障害対応フローの INC-xx）と閾値の根拠も必須の列で、空欄は赤。監視基盤そのものを別の仕組みから監視する項目と、★「監視の穴」シート（監視していないものを、していないと書いて残す）つき。
移行判定チェックリスト（Go/NoGo）
移行の失敗は、作業ミスより判断の遅れで致命傷になります。「まだいけるかもしれない」で最終判断時刻を越えると、切り戻す時間が無くなります。判定を1回にせず、前日・開始前・中間・最終判断の4点で判定する構成にしました。Go条件とNoGo条件を両方書かせ、片方でも空だと赤くなります——当日に「これはNoGoか」を議論すると必ず遅れるためです。最終判断時刻は「業務開始時刻 −（切り戻し所要時間＋確認時間＋余裕）」で逆算します。
移行計画書
「判定基準」「切り戻し発動基準」「最終判断時刻（ポイント・オブ・ノーリターン）」を必須の構造として持つ移行計画書。移行の失敗は作業ミスより判断の遅れで致命傷になります。
移行設計書（データ移行・件数の突合つき）
移行設計書です。移行のフェーズには移行計画書・移行判定チェックリスト・切り戻し手順書がありますが、どれも**いつ移すか・戻すか**の文書で、**何を・どう移すか**を書く文書がありませんでした。ここを埋める1本です。★核は「件数の突合」です。「移行しました」では終われません。**移行元 − 対象外 − エラー ＝ 移行先**が成り立つことを数式で示します。合わないまま本番へ行くと、足りないことに後から気づけません。記入例のFWポリシーは差が2件出たまま「完了」になっていて、行ごと赤くなります。★桁あふれ・未定義コード・重複は、実データを流すまで出ません。「入るはず」で設計され、リハーサルで初めて落ちます。項目マッピングに「事前に洗うもの」の欄を持たせ、件数が残っている行は橙、対応が空の行は赤にしました。★移行しないものも必ず行にします。「全部持っていく」は決めていないのと同じで、当日に「これは移すんでしたっけ」が出ます。理由が空の行は赤です。★リハーサルの所要時間を残します。移行計画書の「最終判断時刻」は作業枠から逆算しますが、その枠に収まるかはリハーサルの実績でしか分かりません。記入例の1回目は240分の枠に対して268分で、28分超過しています。
脆弱性管理台帳
公表された脆弱性を「当てたか」で管理する台帳は多いのですが、実務で本当に困るのは**当てられないもの**のほうで、そこが記録に残りません。監査で聞かれるのも「当てたか」ではなく「なぜ当てていないか」です。★核は3つ。（1）優先度を CVSS だけで決めない … 到達性（インターネットから触れるか）を列にして、数式で優先度を出します。CVSS 9.8 でも到達経路が無ければ後回しでよく、CVSS 7 でも公開サーバーなら先に当てます。この2軸が無い台帳は、数字の大きい順に並べたところで手が止まります。（2）「適用しない」と決めたものを別シートにする … 恒久的に残るので、月次の一覧に混ぜると流れて誰も見なくなります。★再評価日を必須にして、永久に放置できないようにしてあります。（3）緩和策が何に依存しているかを書かせる … 「FWで塞いでいるから当てない」は、そのFWルールが消えた瞬間に破綻します。依存先を通信要件一覧のルールIDで書けば、棚卸しでそのルールを消すときにこの台帳から戻ってこられます。記入例では、緩和が**期限切れのFWルール**に依存している状態をわざと置いてあります。情報源のシートもあり、機器一覧のメーカー分だけ行を作る形にしています（1つのまとめサイトを見ていれば足りる、ということはありません）。
要件定義書（IPA非機能要求グレードの項目体系に対応）
要件IDを起点に基本設計書・試験仕様書へトレースできる要件定義書。★各要件に「優先度（必須／推奨／任意）」と「確認方法（どの試験で確認するか）」の欄を設けました。★未決事項には決定期限と「決まらない場合の既定値」を書かせます。非機能要件はIPA「非機能要求グレード」の6大項目で整理し、詳細は非機能要件定義書へ寄せています。
証明書管理台帳
証明書は切れるまで誰も見ないので、台帳側から期限を突きつける形にしないと必ず落ちます。残日数を数式で出し、期限切れ・残30日以内・更新担当が空の行は赤、残90日以内と自己署名のままの行は橙になります。サーバ証明書だけ更新して中間CAの配布を忘れる事故（端末によって出方が変わるので発見が遅れる）を防ぐため、ルート・中間CAと信頼ストアへの配布先を別シートで持ちます。更新作業の予定・実績・検証結果を残す更新記録つき。
試験仕様書 兼 成績書
仕様書と成績書を1ファイルで兼ねるSI定番スタイル。インフラ試験の観点チェックリスト（冗長化・監視発報を含む）を同梱し、試験漏れを構造的に防ぎます。★要件カバレッジのシートで、要件の側から「この要件を確認する試験が0件」を検出します。単体・結合・総合の区分別に集計し、NGの行には不具合IDを書き戻す欄を設けました。
試験計画書
試験仕様書（1行1試験）を書き始める前に合意しておく計画側の型です。区分ごとの想定項目数と1日あたりの消化数から所要日数を数式で出し、NG想定率から再試験のぶんまで積んで、移行判定日までの余裕（営業日）を自動で出します。余裕が0以下なら赤——その計画では試験が終わる前に判定日が来ます。本番との差異を「その差異で検出できないこと」まで書かせる試験環境シート、抜けやすい観点（冗長化・監視発報・切り戻しの検証）を先に並べる試験観点シート、リードタイムから着手期限を逆算する事前準備シートつき。
詳細設計書
基本設計書と詳細設計書の境界は、日本のSIで最も曖昧なところです。そのまま作ると基本設計書の焼き直しか、パラメータシートの劣化版になります。この型では「基本設計書＝方式と方針／詳細設計書＝★設計判断とその根拠、および設定値では表せない動作／パラメータシート＝実際の設定値」と境界を置き、その表を1章に入れました。中核は2章の設計判断の一覧で、論点・採用案・却下案・理由を残します。5章は動作を★正常時／片系障害時／復旧時の3状態で書かせ、忘れられやすいフェイルバックを構造として持たせています。責任分界点・制約事項・要件IDのトレース表つき。
通信要件一覧（FWルール表）
ゾーン定義とゾーン間ポリシーを先に決め、個別ルールをその例外として書くFWルール表。送信元・宛先・サービスが any の行と、有効期限が過ぎた行には自動で色が付きます。★ゾーン間ポリシーに「≠（この区間はFWを通らない）」の記号を持たせてあります。VLAN間ルーティングをコアスイッチで行う構成では社内セグメント同士の通信がFWまで上がってこないため、ここを「×」と書くと止まっているつもりで素通りします。効かないルールの例と、棚卸しでヒット0からそれを見つける流れまで記入例に入れてあります。AD認証の内訳やIPsec・vSphereなど、毎回調べ直しているポート番号を約60件収録済み。FW機種を問わず使えます。
運用手順書（日次・週次・月次）
引き渡し後に毎日使う運用手順書。作業一覧・作業手順・実施記録の3点セットです。手順には期待結果と異常時の一次対応を必須列として持たせ、「確認する」だけで何をもって正常とするかが人によって変わる状態を防ぎます。実施記録は日付を1〜31日に展開する方式で、やっていない日が空欄として見えます。○だけでなく値（ディスク使用率・バックアップ成功数）を毎日残す欄があり、月次の容量レビューでそのまま使えます。月次作業は証明書管理台帳・ライセンス管理表・アカウント管理表の点検と対にしてあります。
障害対応フロー・一次対応手順
監視項目一覧と1対1で対応させる障害対応の型。閾値を決めただけで「検知したら誰が何をするか」が決まっていない監視は、鳴っても誰も動かないアラートになります。一次対応は「決められた手当」だけを書かせ、判断が要るものはエスカレーションへ倒す構成です。着手・報告の目標時間、時間帯ごとの一次受けと判断権限、障害記録（検知方法つき）まで含みます。障害記録の所要時間は数式で出るのでRTOの実績値として使えます。
電源容量・重量計算表
ラック搭載図がラックの中を見るのに対し、こちらは**ラックの外側**——分電盤・受電・空調・床・搬入経路で足りるかを見ます。機器ごとの定格(W)と実測(W)を両方持ち、実測が無ければ定格で計上します（0にすると集計が過小になり、そのほうが危険なため）。ラック集計では★床荷重(kg/m²)を出します——ラック単体の耐荷重を満たしていても、床の設計荷重を超えることがあり、設置面積で割らないと出てきません。分電盤集計は★片系停止時の使用率を出します。搬入経路は「満載のまま運ぶ」前提で計算するので、機器を降ろして搬入するかどうかがここで決まります。
非機能要件定義書（Excel一覧版）
要件定義書（Word）が合意した内容を文書として残すのに対し、こちらは★決まっているか・合意したか・いくらかかるかを管理する版です。IPA非機能要求グレードの6大項目・35中項目を全部並べ、対象外にするものも「対象外」と書いて残します（機能要件と違い、非機能は聞かなければ存在しないまま進むため）。レベル（0〜5）と具体値を必ず選ばせ、★コスト影響を列として持ちます——書かないと「全部いちばん高いレベルで」と言われ、見積りの段階で戻ることになります。コスト影響が大なのに未合意の行は赤。合意率と「要件定義を終えられる状態か」を数式で出し、レベルの目安表と合意記録を同梱しています。
どの業種でも使う文書8 件
議事録・WBS・体制表など。業種を問わず同じ形で使えます
課題管理表
「ボール（今どちらが持っているか）」と滞留日数で塩漬け課題を防ぐ課題管理表。完了条件・起票元の列つき。期限超過と記入漏れの自動色付け・プルダウン設定済み。
議事録テンプレート（基本形）
決定事項ファーストの議事録。読み手が最初に知りたい「決まったこと・宿題」を冒頭に置く構成です。定例会・顧客打合せに。
議事録（クラウド移行・軽量版）
クラウド移行版をさらに簡略化した軽量版。短時間の打合せ向け。
議事録（クラウド移行案件向け）
公式議事録をフォークし、クラウド移行案件向けに決定事項の粒度と体制欄を調整。
議事録（監査対応・発言録つき）
発言録を残す監査・トラブル対応向けの派生。誰がいつ何を発言したかを追える。★記録者の解釈は「補足」の列に分け、発言そのものと混ぜない。
議事録（社内定例向け）
公式の議事録テンプレをフォークして社内向けに簡略化。社名・敬称欄を削り、Slack転記を前提に宿題事項を先頭へ移動。
進捗報告書（週次定例）
信号機サマリ1枚で全体が伝わる週次報告。「ご依頼事項・要決定事項」専用スライドで報告会を意思決定の場に変えます。
運用引継書
引き継ぎは「説明した」と「受け取った」がずれます。説明した側は終わったつもりで、受けた側は聞いていないと言う。項目ごとに説明日・説明者・受領者・受領日を持ち、両方そろって初めて1項目が完了する形にしました。完了率は数式で出るので「だいたい終わった」で引き渡せません。文書だけでなくアカウント・鍵・媒体・機器・契約書を数えて渡す資産シートと、引継時点の未解決事項を期限と責任者つきで残す残課題シートつき。