テンプレートを探す
1本ずつ探すより、使う場面や構成の層でまとまったセットから選ぶほうが早いことがあります。
セットから選ぶ
キットをすべて見る →定期作業カレンダー（年間）
月次より長い周期の作業は、決めた直後は覚えていても半年後には誰も覚えていません。年間を1枚に並べ、当月の列を数式で自動強調します（日付を手で書き換える運用にすると、必ず古いまま配られるため）。●を置くだけのカレンダーにして手順は各文書へ飛ばし、リストア試験・アカウント棚卸し・ライセンス棚卸し・EOSL更改計画など、他のテンプレートの点検を年間の時間軸に載せています。実施記録の申し送りから翌年度の計画を作る構成です。
店舗展開 標準構成書（多店舗）
多店舗（小売・飲食・サービス）の店舗展開で使う標準構成書。★これまでの文書は「1つのシステムを作る」前提でしたが、店舗展開は同じものを何十回も作るのが仕事で、失敗の形もそこから来ます。★核は3枚です。（1）標準構成 … 店舗展開の値打ちは「速く開ける」ことではなく「どの店も同じにする」ことです。1店だけ違う機器・違う設定にすると、その1店のために手順が枝分かれし、以降の全店の作業がその分だけ重くなります。例外を認めるならいつまでの例外かを書いてください。書かない例外は永久に残ります。（2）開店までの逆算 … 開店日は動かせません。回線の手配が最も長いので、そこから逆算します。前から積むと必ず溢れます。（3）現地対応 … 開店後の店舗に技術者は居ません。店員が電話越しにできることしか復旧手段になりません。「見に行けば分かる」は100店舗になると成り立ちません。
店舗運営 日次管理表（発注・ロス・シフト）
店舗運営の日次管理表（発注・ロス・シフト・クレーム）。★出店は一度きりですが、運営は毎日続きます。続くものほど型が無いと人に依存し、店長が変わった日にそれまでのやり方が全部消えるのがこの分野の典型です。★核は3つです。（1）発注とロス … 同じ表で見ます。別々に見ると必ず片方に寄り、欠品を嫌えばロスが増え、ロスを嫌えば欠品が増えます。「勘で発注する」は悪くありません。悪いのは、勘の中身が本人にしか無いことです。欠品を数えていない店が多く、機会損失が見えないまま発注が細ります。（2）シフトと作業 … 「埋まったか」ではなく「回るか」で見ます。人数だけ合っていても、できる作業が偏っていれば回りません。1人しかできない作業は、その人が休んだ日に止まります。（3）クレーム … 件数ではなく、同じことが繰り返されているかを見ます。1件ずつ処理すると気づけません。原因は仕組みの側で書きます。「注意不足」と書くと手順が変わらず、同じことが起き続けます。★景品表示法・労働基準法・食品衛生法の細部には踏み込みません。業態・規模・地域で変わるため、扱うのは管理表の型です。
提案書
提案書は放っておくと「自社ができること」を並べた資料になります。ですが読む側が知りたいのは、**自分たちの課題にどう答えるか**と、**何が含まれていないか**の2つだけです。★このテンプレートは、3枚目を「お客様の課題／出典／この提案／効果」の1対1の表にしています。課題には出典（ヒアリングシート・現行環境調査の番号）を付けます——出典の無い課題は、提案する側が想像で書いたものです。効果は測れる形で書きます（記入例は「一次対応15分以内（SLA/SLO SL-06）」「保守期限切れの機器 0台」）。「安定します」「効率化します」は効果ではありません。★5枚目は「含まれるもの／含まれないもの／含まれない理由」に1枚まるごと使います。ここを書かない提案書は、受注後に「これも入っているはず」で必ず揉めます。★6枚目の概算費用は**5年総額の行**を持たせています。初期費用だけを見せると、保守やライセンスの年額が後から出てきます（記入例に金額は入れていません。内訳の項目と行だけが型です）。★7枚目は調達のリードタイムから逆算した**発注の締切**を赤く出します。ここを示さないと「検討します」のまま日程が成立しなくなります。全10枚、16:9。発表者ノートに、そのページで話すことと外してはいけない点を入れてあります。
施工品質記録（Excel・検査/測定記録・是正まで）
施工品質記録は、施工計画書で決めた管理基準に対して「実際にどうだったか」を残す記録です。★合否だけを書かないでください。「±3mm 以内で全数合格」と書いても、全部が +2.8mm に寄っていればそれは読めません。実測値をn1〜n5で残し、平均と「かたより（規格中心比）」を数式で出します。かたよりが 0.6 を超えると橙——★全数合格でも、施工の癖か下地の設定値そのものがずれている印です。★1点でも規格を外れたら不合格にします（平均で合格にしません）。★測定器の管理番号を必ず書かせ、校正が切れた器で測った行を赤くします。校正切れの器で測った値は記録として成立しません。記入例では照度計の校正が切れた状態を1件残してあります。★不合格には是正と再検査を必ず付けます。是正日が入っているのに再検査日か結果が空の行は赤——★是正だけ書いて再検査を書かない記録が、この文書で最も多い欠落です。目視で確かめるものは施工チェック記録へ分け、「対象」に母数（3F 全10か所など）を書かせます。★管理基準は施工計画書5章を正とし、数値を二重に持ちません。記入例は施工計画書と同じ案件（ビル内の内装・電気設備工事）で、6工種の管理基準がそのまま入っています。
施工計画書（建築・共通の型）
着工前に発注者へ提出する施工計画書。工程・体制・安全衛生・品質・環境の章立てを標準化し、予想される災害と防止対策を表で整理しています。民間工事および指定様式がない場合の雛形です。
検査成績書
検査成績書です。QC工程表が「何をどう管理するか」、作業標準書が「その作業をどうやるか」を決めるのに対して、こちらは**そのとおりにやった結果どうだったか**を残します。★核は合否だけで終わらせないことです。合否だけの成績書からは、規格の中心からどれだけ寄っているかが読めません。記入例の硬度は5点とも合格ですが、HRC 55〜60 に対して 55.2〜56.1 と全部が下限側に寄っていて、QC工程表の工程能力シートで Cpk が 1.12（目標1.33）に届かない原因がそこにあります。「かたより」を数式で出し、規格の中心から70%以上寄った行は橙にします。★もう一つの核は測定器です。校正の切れた器で測った成績書は無効で、監査で最初に見られるのがここです。管理番号から校正の状態を自動で引き、記入例の表面粗さ計（SR-001）は期限が17日前に切れていて行ごと赤くなります——判定は「合格」と出るのに、です。★特採（特別採用）には承認者と承認日を必ず書かせます。空欄は赤。口頭の特採は記録に残らず、「前も通ったから」で次のロットにも引き継がれます。計量値と合否でシートを分けてあるので、どちらの列も空にならずに読めます。
構成図テンプレート（作図ルール＋部品集）
雛形・記法ルール・アイコン部品集のセット。新設＝赤枠／撤去＝グレーアウトなど更改案件の描き分けを標準化します。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）通知の設計 … 設定しただけで、実際に届くか試していない例が多くあります。抑制（メンテナンス中の停止）を解除し忘れると、以降ずっと黙ります。★既定値は製品と版で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
監視項目一覧
監視が機能しなくなる最大の原因は、閾値の設定ミスではなく★アラートが多すぎて誰も見なくなることです。項目ごとに「想定発報数（件/月）」を持たせ、合計と★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つのまとめサイトを見ていれば足りる、ということはありません）。
補助金 交付事務チェック表（申請〜検査）
補助金の交付事務チェック表（申請・審査・実績・検査）。★調達は「買う」、補助金は「出す」で、確かめるものが違います。買うときは納品されたものを見ればよいのですが、補助金は「その事業が本当に行われたか」「その支出が対象か」を書類で確かめます。現物が残らない事業（研修・調査・啓発）ほど難しくなります。★核は3つです。（1）段階ごとの事務 … 公募から事後まで18段階について、何を見るかを並べています。審査の記録は情報公開の対象になるので、誰が何を見て判断したかを書ける形で書きます。（2）対象経費 … 交付要綱に書いていないことは審査できません。審査の段になって迷うのは要綱の書き方の問題で、対象と対象外を要綱の時点で並べて書きます。「その他必要と認めるもの」は、認める基準を別に決めないと使えません。（3）返還 … 交付決定の時点で条件と方法を書きます。後から「返してください」と言っても、根拠が無ければ返ってきません。実績が下回っただけなら減額であって返還事由ではなく、この2つは区別して書きます。★補助金適正化法・自治体の規則・国庫補助の要件の細部には踏み込みません。制度・年度・団体で変わるため、扱うのは事務の型です。
要件定義書（IPA非機能要求グレードの項目体系に対応）
要件IDを起点に基本設計書・試験仕様書へトレースできる要件定義書。★各要件に「優先度（必須／推奨／任意）」と「確認方法（どの試験で確認するか）」の欄を設けました。★未決事項には決定期限と「決まらない場合の既定値」を書かせます。非機能要件はIPA「非機能要求グレード」の6大項目で整理し、詳細は非機能要件定義書へ寄せています。
証明書管理台帳
証明書は切れるまで誰も見ないので、台帳側から期限を突きつける形にしないと必ず落ちます。残日数を数式で出し、期限切れ・残30日以内・更新担当が空の行は赤、残90日以内と自己署名のままの行は橙になります。サーバ証明書だけ更新して中間CAの配布を忘れる事故（端末によって出方が変わるので発見が遅れる）を防ぐため、ルート・中間CAと信頼ストアへの配布先を別シートで持ちます。更新作業の予定・実績・検証結果を残す更新記録つき。
試験仕様書 兼 成績書
仕様書と成績書を1ファイルで兼ねるSI定番スタイル。インフラ試験の観点チェックリスト（冗長化・監視発報を含む）を同梱し、試験漏れを構造的に防ぎます。★要件カバレッジのシートで、要件の側から「この要件を確認する試験が0件」を検出します。単体・結合・総合の区分別に集計し、NGの行には不具合IDを書き戻す欄を設けました。
試験計画書
試験仕様書（1行1試験）を書き始める前に合意しておく計画側の型です。区分ごとの想定項目数と1日あたりの消化数から所要日数を数式で出し、NG想定率から再試験のぶんまで積んで、移行判定日までの余裕（営業日）を自動で出します。余裕が0以下なら赤——その計画では試験が終わる前に判定日が来ます。本番との差異を「その差異で検出できないこと」まで書かせる試験環境シート、抜けやすい観点（冗長化・監視発報・切り戻しの検証）を先に並べる試験観点シート、リードタイムから着手期限を逆算する事前準備シートつき。
詳細設計書
基本設計書と詳細設計書の境界は、日本のSIで最も曖昧なところです。そのまま作ると基本設計書の焼き直しか、パラメータシートの劣化版になります。この型では「基本設計書＝方式と方針／詳細設計書＝★設計判断とその根拠、および設定値では表せない動作／パラメータシート＝実際の設定値」と境界を置き、その表を1章に入れました。中核は2章の設計判断の一覧で、論点・採用案・却下案・理由を残します。5章は動作を★正常時／片系障害時／復旧時の3状態で書かせ、忘れられやすいフェイルバックを構造として持たせています。責任分界点・制約事項・要件IDのトレース表つき。