テンプレートを探す
1本ずつ探すより、使う場面や構成の層でまとまったセットから選ぶほうが早いことがあります。
セットから選ぶ
キットをすべて見る →バックアップソフト パラメータシート（Veeam / Arcserve 等）
Veeam・Arcserve などバックアップ製品の設定値を書くパラメータシートです。★核は3枚です。（1）保持・世代設計 … 「14世代」が何日前まで戻れるかは方式で変わります。世代は回数であって日数ではありません。増分は前の復元ポイントに依存するため、連鎖の途中が壊れるとそこから先が戻せません。そして最大の問題は、保持を短くしても・復元ポイントが消えても、「戻したいとき」まで誰も気づかないことです。（2）リポジトリ設計 … 保存先は数ではなく「何に耐えるか」で数えます。同じ拠点・同じ認証で入れる先を2つ用意しても、耐えられる事象は増えません。（3）整合性とリストア … ★ジョブが「成功」でも整合性が取れているとは限りません。整合性の処理に失敗しても、警告のままバックアップが完了することがあります。★製品ごとに画面も用語も違うため、確証のない既定値・挙動は「要確認」と明記しています。★既存の「バックアップ・リストア設計/手順書」が「何を・どこまで戻すか」を決める文書なのに対し、こちらは「それを製品にどう設定するか」を書く側です。RPO/RTOをこのシートで決め直さないでください。
バックアップ・リストア設計/手順書
「取れている」ことと「戻せる」ことは別、を構造にした型。設計シートに最終リストア試験日と経過日数を持たせ、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）プールと容量設計 … ★プールが満杯になると、そのプール上の全ボリュームが書けなくなります。都度確保では割り当ての合計が物理容量を超えても作れてしまいます。
プロジェクト計画書
「対象外事項」と「前提条件」を独立章として構造化した計画書。スコープクリープと後々の揉め事の大半は、ここの曖昧さから生まれます。★成功基準に「判定時期／判定者」、対象外事項に「理由／必要になった場合の扱い」、前提条件に「崩れたときの影響」の欄を設けました。管理方針は各領域で使う文書（WBS・課題管理表・リスク管理表など）まで決めます。
ポート結線表・配線表
設計書ではなく、現地作業の指示書としてそのまま使える結線表。両端の機器とポートを書けば、ケーブルに貼るラベル表記が数式で出ます。ポート一覧は機器ごとに全ポートを展開する方式で、空きポートが行として見えるため増設のたびに現地で数える必要がありません。規格ごとの最大距離とコネクタをまとめたメディア早見表つき。
メール基盤 パラメータシート（メール・グループウェア）
ドメインとしてのメール基盤（送信ドメイン認証・経路・受信の保護）のパラメータシートです。★サービスに依存しない書き方にしています。クラウドでもオンプレでも踏む失敗は同じだからです。★核は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のコンセント割当を全展開する電源系統シートつき。搭載してから「入らない・重量が超える・電源が足りない」と分かるのが一番まずく、その場では何もできません。
リスク管理表
リスクは「まだ起きていない問題」なので、放っておくと誰も見ません。可能性×影響度でリスク値を数式で出し、数字で並べ替えられる形にしました（15以上は赤、8以上は橙）。「高・中・低」で書くと、付けた人によって基準が変わり、上位から順に見ることもできません。点数の付け方は評価基準シートに置き、対応後の可能性・影響度から残リスクも数式で出します——対応策を書いただけで安心する状態を防ぐためです。見直し記録で、点数を変えた理由まで残します。
不具合管理表
「おかしい」だけの報告は直せません。再現手順と期待動作を必須の列にして、空欄は赤くなります。期待動作が書けないものは不具合ではなく仕様の確認なので、QA管理表へ回す運用にしました。修正しただけでは閉じられず、再試験の結果が「合格」で初めて完了になります。検出工程を残して工程別に集計するので、受入試験・本番で出た件数がそのまま前工程の試験の足りなさを示します。原因分類ごとに「本来どの工程で防ぐか」を持つ再発防止シートつき。
介護 サービス提供記録・点検表（実地指導の型）
介護のサービス提供記録と点検表（実地指導で見られる形）。★この分野は「記録が無い＝提供していない」と扱われ、しかも後から書けません。実地指導では計画・記録・請求の3つが揃って初めて「やった」と認められ、1つでも欠けると返還になります。書き方の問題ではなく、揃っているかの問題です。★核は3つです。（1）計画と記録と請求 … ケアプランに無いサービスは記録があっても請求できません。逆に、計画にあって記録が無いものも請求できません。3つが1本の線でつながっているかを月次で確かめます。（2）加算の要件 … 「取れる」ではなく「満たし続けている」かで見ます。取り始めるときは確かめても、続いているかは誰も見ません。人員が減った月・研修をやらなかった月に切れていて、後から見つかると返還になります。（3）身体拘束・虐待防止 … 記録の有無そのものが問われます。「やっていない」ことの証明は記録でしかできません。指針・委員会・研修の3点セットは、開催したことを残していないと無かったことになります。★介護保険法・運営基準・自治体の解釈の細部には踏み込みません。サービス種別・地域・年度で変わるため、扱うのは記録の型です。
介護施設 事業継続計画（BCP）
介護施設の事業継続計画（BCP）。★これまでの近い文書（バックアップ・リストア設計）は「データを守る」話でしたが、介護は違います。守るのは人の生活で、しかも避難できない利用者が居ます。電気が止まっても、水が出なくても、職員が来られなくても、その場でケアが続きます。★核は3枚です。（1）続けること／諦めること … 全部を続けようとすると全部が中途半端になり、職員が先に倒れます。命に関わるケア（食事・水分・排泄・投薬・医療機器）と、そうでないもの（入浴・レクリエーション）を分けます。（2）人の回し方 … 災害で困るのは設備より人です。道路が寸断され、職員自身も被災します。出勤できる人数の段階ごとに、何ができて何を諦めるかを決めておきます。「応援を呼ぶ」は計画ではありません。（3）決める人と備え … 施設長が不在のときに誰が決めるかを、順位で3番目まで名前で書きます。「本部の指示を待つ」は、通信が切れた時点で成り立ちません。★制度（BCP義務化・自治体の指針）の細部には踏み込みません。年度・自治体で変わるため、扱うのは計画の作り方です。
会議体・連絡体制定義
立ち上げで「週次定例は木曜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枚、契約番号）まで書かせます。
作業手順書（本番作業の型）
「判断ポイント（続行/切り戻しの条件とリミット時刻）」を独立シートとして持つ作業手順書。判断リミットは「作業枠の終了−切り戻しの所要合計−予備」を数式で計算します。予定時刻は所要時間の積み上げで、実施時刻との差も自動計算。構築・移行・定期作業すべてこの型から派生できます。
作業標準書
QC工程表は「何をどう管理するか」を決めます。ですが**その作業をどうやるか**は書きません。QC工程表の使い方には「工程Noは作業標準書と一致させてください」と書いてあるのに、その作業標準書がカタログにありませんでした。ここを埋める1本です。★核は「急所」と**その理由**を必ず書かせることです。「対角の順で締める」だけでは、急いでいるときに省かれます。「片側から締めると座面が浮き、規定トルクでも後で緩む」まで書いて初めて守られ、違う状況でも判断できるようになります。理由が空の行は赤くなります。★工程Noと管理項目を QC工程表と同じ言葉にします。ずれると、標準書どおりに作業してもどの管理項目を満たしたのかが分かりません。★一覧シートは QC工程表の工程をそのまま並べ、**標準書が無い工程を赤く**します——記入例の工程40（熱処理）がそれで、QC工程表には硬度・炉温の管理項目があり、工程能力シートでは Cpk 1.12 と目標1.33に届いていません。**標準書が無い工程で工程能力が出ない**のは偶然ではないことが多いです。★教育・力量の記録が別シートにあります。標準書があっても、認定していない人や期限切れの人が作業していたら標準は守られていません。標準時間を手順ごとに持ち、合計を数式で出すので、工数見積りの根拠にもなります。
倉庫作業手順書（入荷〜出荷）
倉庫の入荷から出荷までを工程ごとに決めた手順書。★倉庫の事故は、作業そのものより「確認を飛ばしたこと」で起きます。入荷検品を飛ばせば、在庫は最初から合っていません。だから工程ごとに「誰が確認するか」「何を残すか」を決めてあります。★核は3つです。（1）工程別手順 … 入荷・格納・保管・ピッキング・梱包・出荷・返品の22工程について、何を確認し、誰が見て、何を記録するかを並べています。（2）在庫が合わないとき … 在庫差異は必ず出ます。出ること自体は問題ではありません。問題は、出たあと「システムを実数に合わせたのか、実数を探し直したのか」が残らないことです。残っていないと、次に差異が出たときに同じ調べ方ができません。（3）誤出荷を止める … 誤出荷は「気をつける」では減りません。ダブルチェックは人が増えるだけで、同じ思い込みは2人とも通します。バーコード・重量・員数という別の情報で照合する形にします。★倉庫業法・貨物自動車運送事業法・改善基準告示の細部には踏み込みません。事業の種類・規模・年度で変わるため、扱うのは作業の型です。
個人情報管理台帳（保有・委託・漏えい時）
個人情報の管理台帳（保有・委託・開示請求・漏えい時）。★医療（要配慮個人情報）を基準に作っていますが、業種を問わず要る文書です。重いほうに合わせてあるので、他の業種では削れる欄があります。★核は3つです。（1）保有する情報 … 部署ごとではなく業務ごとに書きます。「顧客名簿」では足りません。どの業務で・何のために・どこに置いてあるかです。置き場所が分からない個人情報は、漏れたときに範囲が決まりません。保管期限の無いものは永久に残り、その分だけ危険が増えます。バックアップと共有フォルダを忘れないでください。（2）外に出すもの … 委託先・クラウド・共同利用。自社の外に出た時点で見えなくなります。委託先が漏らしても、責任は委託した側にあります。再委託を許したかまで残します。（3）開示請求と漏えい時 … 起きてから考えると必ず遅れます。報告の期限は「気づいた時点」から数えます。「全容が分からないから報告しない」で遅れるのが典型です。★個人情報保護法・ガイドライン・条例の細部には踏み込みません。業種・規模・年度で変わるため、扱うのは台帳の型です。
切り戻し手順書
切り戻しは「頭の中にある」で済まされることが最も多い文書です。手順ごとの所要時間を積み上げ、その合計から最終判断時刻を数式で逆算します（業務開始時刻 −（切り戻し所要 ＋ 復旧確認 ＋ 業務部門の確認 ＋ 余裕））。手順を1つ足せば合計が増え、判断時刻が自動で早まります。戻す対象を機器・設定だけでなく名前解決・監視・バックアップの向き先まで洗い出し、「戻せなくなる時点」を列として持ちます。戻した後の復旧確認10項目と、実際に戻して測った検証記録つき。
医療安全 インシデント報告・再発防止台帳（報告から対策の確認まで）
医療安全のインシデント報告・再発防止台帳（報告／影響レベル／要因・対策／確認項目）。★この分野は「報告が集まるか」が全てです。集まらない台帳は、危ないところを教えてくれません。しかも報告は、放っておくと止まる方向にしか動きません。書く手間があり、書けば自分の落ち度として扱われうるからです。★核は4つです。（1）報告した人を責めない … 責めた瞬間、その部署からの報告は止まります。件数は減り、数字の上では安全になったように見えます。★報告件数が減った月がいちばん危ないと考えてください。だからこの台帳には当事者の実名欄を作っていません。職種と経験年数だけです。（2）レベル0・1（実害が出なかったもの）こそ集める … 実害の出た事例は誰でも上げます。上がってこないのは、間に合ったほうです。実害の出た事例しか並んでいない台帳は、手前を拾えていないという意味です。（3）「確認不足」「注意不足」で閉じない … それは原因ではなく、起きたことの言い換えです。人の注意で防ぐ対策は必ず戻ってきます。★仕組みで止める ＞ 物を変える ＞ 手順を変える ＞ 注意を促す、の順に効きます。（4）対策を出して終わりにしない … 確認の日を対策と同時に決めます。決めていない対策は誰も見に来ず、半年後には期限切れの対策だけが並びます。★報告（MS-…）と対策（CA-…）を番号でつなぎます。同じ対策に複数の報告がぶら下がってかまいません。つないでおかないと「繰り返しているか」が見えません。★医療事故調査制度・報告の期限・院内の規程の細部には踏み込みません。病院の規模・機能・年度で変わるため、扱うのは記録の型です。
医療機関 システム更改計画書（止められない現場）
医療機関（病院・診療所）のシステム更改計画書。★これまでの文書は「止めてよい夜間帯がある」前提でしたが、医療は違います。入院がある限り、止まっている間も患者は居ます。「止められない」のではなく「止まっている間に何が起きるかを決めてから止める」と考えます。★核は3枚です。（1）止める時間の合意 … 止める時間は IT が決めるものではありません。診療科ごとに事情が違うので、誰と何を合意したかを残さないと当日に「聞いていない」が必ず出ます。「夜間なら空いている」も成り立ちません。救急は夜のほうが動きます。（2）止まっている間の運用 … システムが止まっている間も診療は続きます。紙で回す手順と、戻ってからの入力し直しまで決めて初めて止められます。（3）連携先の棚卸し … 電子カルテは単体では動きません。検査・画像・調剤・会計とつながっており、片方だけ更改すると連携が切れます。★制度・法令の細部には踏み込みません（版と地域で変わるため）。扱うのはインフラ更改の進め方です。
基本設計書（方式と方針の型）
「基本設計＝方式と方針、詳細設計＝具体的な値」の線引きを章構成で体現。設定値はパラメータシートに書き、本書には書かないことで二重管理を防ぎます。
変更管理表
障害の多くは「変更した直後」に起きます。何を・いつ・誰の承認で変えたかが残っていないと、障害の切り分けで最初に詰まります。承認日より前に実施日が入っている行と、承認日が無いのに実施日がある行を赤くして、承認なしの実施を表の上で見えるようにしました。切戻し手順が空の変更、実施したのに結果・事後確認が空の変更も赤。標準変更（事前承認済みの定型作業）を区分として持ち、通常変更の申請に添える影響確認チェックリスト15項目つきです。
完了報告書
「無事完了しました」で終わる報告書が最も多く、そう書かれた瞬間に、残っているものが誰の担当でもなくなります。この型は3つを構造にしました。★プロジェクト計画書で決めた成功基準に1つずつ判定を付ける（照合しないなら計画書に書いた意味がありません）。★計画との差分を期間・費用・スコープの数字で書く（「おおむね計画どおり」は差分を書いていないのと同じ）。★残作業に「誰が・いつまでに・どこで管理するか」の3つを必ず書かせる。振り返りは「続けること／やめること／次に変えること」の3分類で、一般論を書く欄を作っていません。