Dit 公式
@dit-official
Dit公式テンプレート。インフラプロジェクトの標準ドキュメントを提供します。
公開テンプレート（111）
議事録テンプレート（基本形）
決定事項ファーストの議事録。読み手が最初に知りたい「決まったこと・宿題」を冒頭に置く構成です。定例会・顧客打合せに。
課題管理表
「ボール（今どちらが持っているか）」と滞留日数で塩漬け課題を防ぐ課題管理表。完了条件・起票元の列つき。期限超過と記入漏れの自動色付け・プルダウン設定済み。
作業手順書（本番作業の型）
「判断ポイント（続行/切り戻しの条件とリミット時刻）」を独立シートとして持つ作業手順書。判断リミットは「作業枠の終了−切り戻しの所要合計−予備」を数式で計算します。予定時刻は所要時間の積み上げで、実施時刻との差も自動計算。構築・移行・定期作業すべてこの型から派生できます。
進捗報告書（週次定例）
信号機サマリ1枚で全体が伝わる週次報告。「ご依頼事項・要決定事項」専用スライドで報告会を意思決定の場に変えます。
施工計画書（建築・共通の型）
着工前に発注者へ提出する施工計画書。工程・体制・安全衛生・品質・環境の章立てを標準化し、予想される災害と防止対策を表で整理しています。民間工事および指定様式がない場合の雛形です。
QC工程表（Excel・工程能力シートつき）
受入から出荷までの工程ごとに、管理項目・規格・管理方法・検査方法・頻度・記録様式・異常時の処置を一覧化します。ISO 9001 は QC工程表の様式を規定していません（記載項目に規定があるのは IATF 16949 のコントロールプランのほうです）。特別特性の識別欄と工程能力シートつき。作業標準書・検査成績書と工程番号で連携します。
WBS・スケジュール表（Excel・ガントチャート自動描画）
進捗率を0/50/100%の3値に制限し、「90%が3週間続く」問題を防ぐWBS。先行タスクより先に始める計画、10営業日を超えるタスク、予定終了を過ぎた未完了タスクを数式で検出します（マクロ不使用）。ガントチャートは条件付き書式で自動描画。
プロジェクト計画書
「対象外事項」と「前提条件」を独立章として構造化した計画書。スコープクリープと後々の揉め事の大半は、ここの曖昧さから生まれます。★成功基準に「判定時期／判定者」、対象外事項に「理由／必要になった場合の扱い」、前提条件に「崩れたときの影響」の欄を設けました。管理方針は各領域で使う文書（WBS・課題管理表・リスク管理表など）まで決めます。
ヒアリングシート（Excel・要件定義／インフラ更改・記入例つき）
全質問に「記入例」列を持つヒアリングシート。回答品質は記入例の質で決まります。必須／任意を分け、必須が埋まれば次工程へ進める設計です。
要件定義書（IPA非機能要求グレードの項目体系に対応）
要件IDを起点に基本設計書・試験仕様書へトレースできる要件定義書。★各要件に「優先度（必須／推奨／任意）」と「確認方法（どの試験で確認するか）」の欄を設けました。★未決事項には決定期限と「決まらない場合の既定値」を書かせます。非機能要件はIPA「非機能要求グレード」の6大項目で整理し、詳細は非機能要件定義書へ寄せています。
基本設計書（方式と方針の型）
「基本設計＝方式と方針、詳細設計＝具体的な値」の線引きを章構成で体現。設定値はパラメータシートに書き、本書には書かないことで二重管理を防ぎます。
試験仕様書 兼 成績書
仕様書と成績書を1ファイルで兼ねるSI定番スタイル。インフラ試験の観点チェックリスト（冗長化・監視発報を含む）を同梱し、試験漏れを構造的に防ぎます。★要件カバレッジのシートで、要件の側から「この要件を確認する試験が0件」を検出します。単体・結合・総合の区分別に集計し、NGの行には不具合IDを書き戻す欄を設けました。
IPアドレス管理表
セグメントの全アドレスを行に展開する台帳。「空き」が行として見えることで、重複払い出しを防ぎます。★セグメントごとの使用率を数式で出します（80%超で橙、90%超で赤）——IPは足りなくなってから増やせず、/24 を /23 へ広げるにはそのセグメントの全機器のアドレスを変えることになるためです。★ホスト名の重複を自動で検出し、使用中なのに用途・ホスト名が空の行、最終更新から1年以上動いていない行も色で出します。.0（ネットワークアドレス）と .255（ブロードキャスト）も「禁止」の行として残し、なぜ払い出せないかが見えるようにしました。★v3 では「実体（実機／仮想IP／機器のIF）」の列を追加しました。VIP・フローティングIP・ゲートウェイのSVIは★機器一覧に出てこないのにアドレスを消費するので、台帳に載せ忘れると後から同じIPを別の機器へ払い出して本番で衝突します。実機なのに機器IDが空の行は赤、仮想IPは薄紫で区別し、セグメント一覧に「うち仮想IP」の件数も出します（記入例はサーバー10台に対して使用中が14個になります）。払い出し記録シートつき。
構成図テンプレート（作図ルール＋部品集）
雛形・記法ルール・アイコン部品集のセット。新設＝赤枠／撤去＝グレーアウトなど更改案件の描き分けを標準化します。Visio不要、PPT標準図形のみ。
移行計画書
「判定基準」「切り戻し発動基準」「最終判断時刻（ポイント・オブ・ノーリターン）」を必須の構造として持つ移行計画書。移行の失敗は作業ミスより判断の遅れで致命傷になります。
監視項目一覧
監視が機能しなくなる最大の原因は、閾値の設定ミスではなく★アラートが多すぎて誰も見なくなることです。項目ごとに「想定発報数（件/月）」を持たせ、合計と★1日あたりの件数を数式で出します——1日10件を超えたら、その監視は運用に渡してはいけません。★もう1つの原因は「起きても業務が動いてしまうもの」で、v3 では「業務影響（即時／性能／潜在）」の列を足しました。冗長が失われた状態（パスが1本・スタックが1台・HAが片系・仮想IPが待機系）、バックアップの失敗、保存先の空き、ログ転送の停止、レプリケーションの遅れ、書込キャッシュ保護部品の劣化、証明書の期限は★起きても業務は動く＝潜在で、監視に入れていなければ次の1つで全断になるまで誰も気づけません。★潜在なのに重要度が「通知」の行は赤くなり、件数も集計されます。一次対応（障害対応フローの INC-xx）と閾値の根拠も必須の列で、空欄は赤。監視基盤そのものを別の仕組みから監視する項目と、★「監視の穴」シート（監視していないものを、していないと書いて残す）つき。
通信要件一覧（FWルール表）
ゾーン定義とゾーン間ポリシーを先に決め、個別ルールをその例外として書くFWルール表。送信元・宛先・サービスが any の行と、有効期限が過ぎた行には自動で色が付きます。★ゾーン間ポリシーに「≠（この区間はFWを通らない）」の記号を持たせてあります。VLAN間ルーティングをコアスイッチで行う構成では社内セグメント同士の通信がFWまで上がってこないため、ここを「×」と書くと止まっているつもりで素通りします。効かないルールの例と、棚卸しでヒット0からそれを見つける流れまで記入例に入れてあります。AD認証の内訳やIPsec・vSphereなど、毎回調べ直しているポート番号を約60件収録済み。FW機種を問わず使えます。
AWSパラメータシート（Excel・14サービス分）
主要AWSサービスの設定値を台帳形式（設定項目が行・リソースが列）で記録する Excel パラメータシート。既定値の列を持ち、既定値から変えた欄だけ自動で色が付くので、どこで設計判断をしたかが一目で分かります。VPC・サブネット・ルートテーブル・セキュリティグループ・EC2・EBS・ALB・RDS・S3・KMS・IAM・Route 53・CloudWatch・Backup の14サービス分。
機器一覧（ハードウェア台帳）
機器IDを全シート共通のキーにしたハードウェア台帳。保守契約とEOS/EOSLの期限が近い行・過ぎた行は自動で色が付き、更改の検討漏れを防ぎます。U数・重量・消費電力はラック単位で自動集計され、ラック搭載図と電源設計の入力になります。光モジュールやディスクなど、保守がモジュール単位で発生する部材の台帳つき。
ポート結線表・配線表
設計書ではなく、現地作業の指示書としてそのまま使える結線表。両端の機器とポートを書けば、ケーブルに貼るラベル表記が数式で出ます。ポート一覧は機器ごとに全ポートを展開する方式で、空きポートが行として見えるため増設のたびに現地で数える必要がありません。規格ごとの最大距離とコネクタをまとめたメディア早見表つき。
VLAN管理表
VLAN IDの付番規約から作るVLAN管理表。VLAN IDとセグメントの重複、規格範囲外のID、用途の記入漏れは自動で赤くなります。「どの機器にどのVLANを作るか」の収容マトリクスと、リンクごとの許可VLAN・ネイティブVLANを書くトランク設計を同梱し、「VLANは作ったがトランクに載せていない」「両端のネイティブVLANが違う」という現地で最も多い2つの詰まりを設計側で潰します。IPアドレス管理表と対で使えます。
ラック搭載図（1U単位）
1U単位のマス目で前面・背面を描くラック搭載図。空きUがマスとして見えるので、増設のたびに現地でUを数える必要がありません。ラックごとに使用U・空きU・重量・消費電力を自動集計し、ラックの上限（U数・耐荷重・電源容量）を超えると赤くなります。PDUのコンセント割当を全展開する電源系統シートつき。搭載してから「入らない・重量が超える・電源が足りない」と分かるのが一番まずく、その場では何もできません。
アカウント・権限管理表（Excel・棚卸し記録つき）
「今このシステムに誰が入れるのか」を即答できる状態にするための台帳。棚卸しから1年以上経った行、有効期限が切れた行、退職時の扱いが決まっていない行、特権なのにMFAが無い行は自動で赤くなります。パスワードは書かせず保管場所だけを持つ設計です。権限定義（ロール）と棚卸し記録を同梱し、監査で問われる「いつ誰が何件確認したか」まで残せます。
証明書管理台帳
証明書は切れるまで誰も見ないので、台帳側から期限を突きつける形にしないと必ず落ちます。残日数を数式で出し、期限切れ・残30日以内・更新担当が空の行は赤、残90日以内と自己署名のままの行は橙になります。サーバ証明書だけ更新して中間CAの配布を忘れる事故（端末によって出方が変わるので発見が遅れる）を防ぐため、ルート・中間CAと信頼ストアへの配布先を別シートで持ちます。更新作業の予定・実績・検証結果を残す更新記録つき。
ソフトウェア・ライセンス管理表
「何本持っていて何本使っているか」を数式で出すライセンス台帳。割当数は割当一覧から自動集計し（解除日が入った行は除外）、保有数を超えた行は赤、余りが無い行と契約終了まで90日以内の行は橙になります。監査で指摘されるのは過剰割当だけと考えてよく、そこを常に見える状態にするための型です。数え方（物理コア／ソケット／ユーザー／デバイス）はベンダーの製品条項でしか決まらないため、確認すべき観点と出典を残す確認シートを同梱しています。
ゾーニング設計表（SAN）
FC構成では必須の設計表。ゾーニングを間違えると、見えるはずのLUNが見えないか、見えてはいけないサーバから見えます（後者は気づかないまま運用に入ります）。WWPNは桁数（16進16桁）と重複を数式で検査し、外れた行は赤くなります。★ホスト1台あたりのパス本数は「HBAのポート数 × 同じファブリックにいるターゲットのポート数」です（記入例は 2×2＝4本）。ゾーンが1つ欠けると3本になりますが業務は動いてしまうので、適用記録に「パス本数の確認」を独立した行として入れてあります——★「見えている」ではなく本数を数えてください。エイリアスを先に定義してゾーンをエイリアスで組む構成にしてあるので、HBA交換のたびに全ゾーンを書き換える必要がありません。1イニシエータ1ターゲットのゾーニングを標準にし、適用記録で「保存して有効化したか・検証したか」まで残します。
運用手順書（日次・週次・月次）
引き渡し後に毎日使う運用手順書。作業一覧・作業手順・実施記録の3点セットです。手順には期待結果と異常時の一次対応を必須列として持たせ、「確認する」だけで何をもって正常とするかが人によって変わる状態を防ぎます。実施記録は日付を1〜31日に展開する方式で、やっていない日が空欄として見えます。○だけでなく値（ディスク使用率・バックアップ成功数）を毎日残す欄があり、月次の容量レビューでそのまま使えます。月次作業は証明書管理台帳・ライセンス管理表・アカウント管理表の点検と対にしてあります。
障害対応フロー・一次対応手順
監視項目一覧と1対1で対応させる障害対応の型。閾値を決めただけで「検知したら誰が何をするか」が決まっていない監視は、鳴っても誰も動かないアラートになります。一次対応は「決められた手当」だけを書かせ、判断が要るものはエスカレーションへ倒す構成です。着手・報告の目標時間、時間帯ごとの一次受けと判断権限、障害記録（検知方法つき）まで含みます。障害記録の所要時間は数式で出るのでRTOの実績値として使えます。
バックアップ・リストア設計/手順書
「取れている」ことと「戻せる」ことは別、を構造にした型。設計シートに最終リストア試験日と経過日数を持たせ、1年以上戻していない対象は赤、半年以上は橙になります。保存先を一次・二次の2列にして、同じ装置・同じ拠点にしか無いバックアップを橙で見せます。RPO/RTO・世代・復旧優先度が空だと赤。★「効かない事象（この方式で守れないもの）」を必須の列にしました——全ての事象に効くバックアップは存在しないので、空欄は「考えていない」の証拠になります。★レプリケーション・スナップショットは「取れている」が単独ではバックアップにならないため、方式のセルが薄紫になります（誤削除は数分で複製先へ伝わり、装置が壊れれば一緒に失われます）。記入例には、見落としやすい★仮想化基盤ホストの構成（管理サーバー側のバックアップに含まれない）と★バックアップサーバー自身の構成情報も入れてあります。リストア手順はファイル単体／サーバ全体／データベース／コンフィグの4パターンを展開済みで、試験記録の所要時間がそのままRTOの実測値になります。
ジョブ・バッチ一覧
夜間バッチは、止まったことより「止まったまま朝を迎える」ことが問題になります。起動時刻・依存関係・失敗時の対応・リラン可否を1枚にして、夜間の当番がこれだけで判断できる形にしました。ジョブネットのシートは終了時刻と後続までの余裕を数式で出し、余裕がマイナスなら重なり、15分未満なら1回の遅延で後続が崩れることが色で分かります。深夜帯は25時表記（25:00＝翌1:00）で書くため、前日の夜か翌日の朝かが表から読めます。
定期作業カレンダー（年間）
月次より長い周期の作業は、決めた直後は覚えていても半年後には誰も覚えていません。年間を1枚に並べ、当月の列を数式で自動強調します（日付を手で書き換える運用にすると、必ず古いまま配られるため）。●を置くだけのカレンダーにして手順は各文書へ飛ばし、リストア試験・アカウント棚卸し・ライセンス棚卸し・EOSL更改計画など、他のテンプレートの点検を年間の時間軸に載せています。実施記録の申し送りから翌年度の計画を作る構成です。
運用引継書
引き継ぎは「説明した」と「受け取った」がずれます。説明した側は終わったつもりで、受けた側は聞いていないと言う。項目ごとに説明日・説明者・受領者・受領日を持ち、両方そろって初めて1項目が完了する形にしました。完了率は数式で出るので「だいたい終わった」で引き渡せません。文書だけでなくアカウント・鍵・媒体・機器・契約書を数えて渡す資産シートと、引継時点の未解決事項を期限と責任者つきで残す残課題シートつき。
SLA/SLO定義書
「99.9%」と書いただけの合意は、達成／未達を議論できません。SLA（契約上の合意・未達に扱いあり）とSLO（内部目標）を区分として分け、可用性の目標値から月あたりの許容停止時間を数式で出します（99.9%＝月43.2分、99.5%＝月216分）。分で見て初めて、その数字が守れるかを判断できます。測定方法・計画停止の扱い・未達時の扱いが空だと赤くなり、実績シートでは達成／未達を数式で判定します。除外事項シートで、計画停止・外部要因・測定不能の扱いを先に合意します。
リスク管理表
リスクは「まだ起きていない問題」なので、放っておくと誰も見ません。可能性×影響度でリスク値を数式で出し、数字で並べ替えられる形にしました（15以上は赤、8以上は橙）。「高・中・低」で書くと、付けた人によって基準が変わり、上位から順に見ることもできません。点数の付け方は評価基準シートに置き、対応後の可能性・影響度から残リスクも数式で出します——対応策を書いただけで安心する状態を防ぐためです。見直し記録で、点数を変えた理由まで残します。
変更管理表
障害の多くは「変更した直後」に起きます。何を・いつ・誰の承認で変えたかが残っていないと、障害の切り分けで最初に詰まります。承認日より前に実施日が入っている行と、承認日が無いのに実施日がある行を赤くして、承認なしの実施を表の上で見えるようにしました。切戻し手順が空の変更、実施したのに結果・事後確認が空の変更も赤。標準変更（事前承認済みの定型作業）を区分として持ち、通常変更の申請に添える影響確認チェックリスト15項目つきです。
QA管理表（質問票）
回答が返ってこない質問の多くは、聞き方に原因があります。「回答期限」と「遅れると何が止まるか」を必須の列にして、催促の根拠が表の上にある状態にしました。「こちらの案（たたき台）」の欄が空だと橙になります——丸投げの質問は考える負担を相手に渡すので返ってきません。遅延日数を数式で出し、期限超過は赤・3日前から橙。宛先別の未回答件数と最大遅延を自動集計します。返ってこない書き方と返ってくる書き方を対比した「質問の書き方」シートつき。
不具合管理表
「おかしい」だけの報告は直せません。再現手順と期待動作を必須の列にして、空欄は赤くなります。期待動作が書けないものは不具合ではなく仕様の確認なので、QA管理表へ回す運用にしました。修正しただけでは閉じられず、再試験の結果が「合格」で初めて完了になります。検出工程を残して工程別に集計するので、受入試験・本番で出た件数がそのまま前工程の試験の足りなさを示します。原因分類ごとに「本来どの工程で防ぐか」を持つ再発防止シートつき。
ドキュメント管理台帳（納品物一覧）
文書は作った瞬間から古くなります。更新責任者を必須の列にして、空欄は赤くなります——「みんなで直す」は「誰も直さない」と同じだからです。最終更新日からの経過日数を数式で出し、1年以上更新されていない文書は赤、半年以上は橙。次回見直し日を過ぎた行も赤になります。納品の要否と納品日を分けて持つので、社内文書と納品物を同じ台帳で管理でき、「これは納品するのか」を毎回聞かずに済みます。版数・ファイル名・保管場所・権限の決めごとと、納品・受領記録つき。
構築チェックリスト
構築は「やったつもり」が最も多い工程です。機器を列に置いて1枚で全台の状況が見えるようにし、○＝確認して問題なし／×＝不合格／−＝対象外／空欄＝未実施を区別します。必須項目の達成率を機器ごとに数式で出すので、「だいたい終わった」で引き渡せません。搬入・据付から電源・ネットワーク・ハードウェア・OS・セキュリティ・運用・文書まで30項目。判断に迷う項目の確認手順と判定基準、引き渡しの完了判定と判定記録つき。
移行判定チェックリスト（Go/NoGo）
移行の失敗は、作業ミスより判断の遅れで致命傷になります。「まだいけるかもしれない」で最終判断時刻を越えると、切り戻す時間が無くなります。判定を1回にせず、前日・開始前・中間・最終判断の4点で判定する構成にしました。Go条件とNoGo条件を両方書かせ、片方でも空だと赤くなります——当日に「これはNoGoか」を議論すると必ず遅れるためです。最終判断時刻は「業務開始時刻 −（切り戻し所要時間＋確認時間＋余裕）」で逆算します。
切り戻し手順書
切り戻しは「頭の中にある」で済まされることが最も多い文書です。手順ごとの所要時間を積み上げ、その合計から最終判断時刻を数式で逆算します（業務開始時刻 −（切り戻し所要 ＋ 復旧確認 ＋ 業務部門の確認 ＋ 余裕））。手順を1つ足せば合計が増え、判断時刻が自動で早まります。戻す対象を機器・設定だけでなく名前解決・監視・バックアップの向き先まで洗い出し、「戻せなくなる時点」を列として持ちます。戻した後の復旧確認10項目と、実際に戻して測った検証記録つき。
試験計画書
試験仕様書（1行1試験）を書き始める前に合意しておく計画側の型です。区分ごとの想定項目数と1日あたりの消化数から所要日数を数式で出し、NG想定率から再試験のぶんまで積んで、移行判定日までの余裕（営業日）を自動で出します。余裕が0以下なら赤——その計画では試験が終わる前に判定日が来ます。本番との差異を「その差異で検出できないこと」まで書かせる試験環境シート、抜けやすい観点（冗長化・監視発報・切り戻しの検証）を先に並べる試験観点シート、リードタイムから着手期限を逆算する事前準備シートつき。
現行環境調査報告書
ヒアリングシートが「聞いたこと」なら、こちらは「調べた事実」です。申告値と実測値を並べて一致／差異を数式で出すので、「サーバは10台」と言われて実機が13台だった、が表の上で見えます。出典（誰から聞いたか・どの出力か・いつ時点か）を必須の列にし、空欄は赤。調べていない項目を空欄にせず「未調査／調査不可」を状態として残し、網羅状況を数式で集計します。用途不明のサーバ・誰も知らない通信・手順書の無い手動バッチを集める「未確認・用途不明」シートが、この調査の最大の成果になります。課題は根拠と費用・期間への影響つき。
サイジング設計書
「メモリ64GB」と書いてあるが、なぜ64GBなのかが誰にも分からない——これが最も多い型です。現行の実測値から必要量を数式で積み上げます（実測 →（1+成長率)^目標年数 → ピーク係数 → 目標使用率で割る）。前提を1つ直せば必要量が右端まで自動で追従します。機器割当シートでは必要量をサイジング計算から自動転記し、余裕率と**片系停止時の使用率**を出します——N+1は1台落ちたら残りが全負荷を受けるので、総搭載量だけを見ていると片系停止時の不足に気づけません。運用開始後に実測と突き合わせる見直し記録つき。
電源容量・重量計算表
ラック搭載図がラックの中を見るのに対し、こちらは**ラックの外側**——分電盤・受電・空調・床・搬入経路で足りるかを見ます。機器ごとの定格(W)と実測(W)を両方持ち、実測が無ければ定格で計上します（0にすると集計が過小になり、そのほうが危険なため）。ラック集計では★床荷重(kg/m²)を出します——ラック単体の耐荷重を満たしていても、床の設計荷重を超えることがあり、設置面積で割らないと出てきません。分電盤集計は★片系停止時の使用率を出します。搬入経路は「満載のまま運ぶ」前提で計算するので、機器を降ろして搬入するかどうかがここで決まります。
キッティング手順書
現地へ持ち込む前に、事務所や倉庫でどこまでやるかを決める型です。構築チェックリストが「据え付けたあとの確認」なのに対し、こちらは「持ち込む前の準備」。受入検品では★付属品まで行として数えます——レール・光モジュール・ネジの欠品は納期が2週間かかることがあり、現地の開梱で気づくと搬入日そのものを動かすことになります。機器の割当ではシリアル・機器ID・ホスト名の重複を自動で検出し、同型機の取り違えを防ぎます。進捗シートは工程ごとの○×から出荷可否を数式で出し、★全工程が終わっていないのに出荷日が入っている行を赤くします。
詳細設計書
基本設計書と詳細設計書の境界は、日本のSIで最も曖昧なところです。そのまま作ると基本設計書の焼き直しか、パラメータシートの劣化版になります。この型では「基本設計書＝方式と方針／詳細設計書＝★設計判断とその根拠、および設定値では表せない動作／パラメータシート＝実際の設定値」と境界を置き、その表を1章に入れました。中核は2章の設計判断の一覧で、論点・採用案・却下案・理由を残します。5章は動作を★正常時／片系障害時／復旧時の3状態で書かせ、忘れられやすいフェイルバックを構造として持たせています。責任分界点・制約事項・要件IDのトレース表つき。
非機能要件定義書（Excel一覧版）
要件定義書（Word）が合意した内容を文書として残すのに対し、こちらは★決まっているか・合意したか・いくらかかるかを管理する版です。IPA非機能要求グレードの6大項目・35中項目を全部並べ、対象外にするものも「対象外」と書いて残します（機能要件と違い、非機能は聞かなければ存在しないまま進むため）。レベル（0〜5）と具体値を必ず選ばせ、★コスト影響を列として持ちます——書かないと「全部いちばん高いレベルで」と言われ、見積りの段階で戻ることになります。コスト影響が大なのに未合意の行は赤。合意率と「要件定義を終えられる状態か」を数式で出し、レベルの目安表と合意記録を同梱しています。
セキュリティ設計書
セキュリティ設計が効かなくなる最大の原因は、★対策から書き始めることです。「FWを入れる」「多要素認証を入れる」と製品と機能を並べても、何の脅威に対してかが書かれていないと、効いていない対策に金を払い、効くべき脅威が抜けます。本書は 守る対象（情報資産）→ 脅威 → 対策 の順でしか書けない構成にしました。脅威と対策の対応表が中核で、対策を打ってなお残るものは★残存リスクとして「受容した人・理由・見直し時期」つきで残します。対策ごとに「効かなくなる条件」を書かせる対策一覧、信頼境界の定義、インシデント時の判断基準と報告先つき。
完了報告書
「無事完了しました」で終わる報告書が最も多く、そう書かれた瞬間に、残っているものが誰の担当でもなくなります。この型は3つを構造にしました。★プロジェクト計画書で決めた成功基準に1つずつ判定を付ける（照合しないなら計画書に書いた意味がありません）。★計画との差分を期間・費用・スコープの数字で書く（「おおむね計画どおり」は差分を書いていないのと同じ）。★残作業に「誰が・いつまでに・どこで管理するか」の3つを必ず書かせる。振り返りは「続けること／やめること／次に変えること」の3分類で、一般論を書く欄を作っていません。
Cisco Catalyst パラメータシート（C9200/C9300・IOS-XE 17.x）
Cisco Catalyst（C9200/C9300・IOS-XE 17.x）に機種とOS版を固定したパラメータシート。汎用のパラメータシートでは「管理IP」「VLAN」程度の粒度まで薄まり、実際に投入する値（コマンド名・既定値・投入順）が書けません。★既定値は機種と版で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。★設定が入っているかを確認する「確認コマンド集」と、この機種で実際に起きる失敗を集めた「投入時の注意」を同梱しました。スタックは1台の論理機器として1列で扱います。
YAMAHA RTX パラメータシート（RTX1300/RTX1220）
国内の中小〜中堅で最も普及している拠点ルーター向け。コマンド体系が他社と大きく違うため、汎用のパラメータシートでは書けません。★核は「フィルタ設計」シートです。RTX の secure filter は列挙した順に評価され、フィルタ番号の大小では決まりません。番号を振り直しても評価順は変わらず、逆に列挙の順序を入れ替えると挙動が変わります。★確認コマンド集と、この機種で実際に起きる失敗を集めた「投入時の注意」を同梱しました。記入例は主回線＋IPsec VPN バックアップの拠点ルーター構成です。
FortiGate パラメータシート（FortiOS 7.x）
FortiGate（FortiOS 7.x）のパラメータシート。国内UTM市場でシェア上位です。GUIで設定する機器なので、CLIだけを書いても現場で辿れません。画面の階層とコマンドを並べた「GUI画面対応」シートを同梱しました。★核は「ポリシー設計」シートです。ファイアウォールポリシーは上から順に評価され、最初に一致した1本で処理が決まります。ポリシーIDは作った順に振られるだけで評価順ではなく、GUIも既定では順序が見えません。★もう一つの核は「HA設計」シートです。「同期される項目」と「機器ごとの項目」を列で分けています。ここを混ぜると、セカンダリに入れた設定が同期で消える／優先度を上げたのに切り替わらない、という形で出ます。★既定値は機種と版で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
vSphere パラメータシート（ESXi 8 / vCenter 8）
VMware vSphere（ESXi 8 / vCenter 8）のパラメータシート。国内の中小〜中堅で最も普及している仮想化基盤です。汎用のパラメータシートではホスト名と管理IP程度しか書けず、実際に事故になる設定が落ちます。★核は「ネットワーク設計」シートです。チーミングとフェイルオーバー順序はポートグループごとにvSwitchの設定を上書きできるため、上書きの有無を表に持たないと、vSwitch側を直したときに一部のポートグループだけ挙動が変わります。VLANの付け方（ポートグループに付ける／物理側をアクセスポートにする／4095でゲストに渡す）と物理側のチャネル方式の組み合わせも、ここで固定します。★もう一つの核は「vCenter・クラスタ」シートです。分離応答・アドミッション制御・再起動の優先度・EVC は、既定のままにすると「障害のときだけ」問題が出ます。★既定値は版とライセンスで変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
Windows Server パラメータシート（Windows Server 2022）
台数で言えば最も多いOS。汎用のパラメータシートでは「ホスト名」「IPアドレス」で終わってしまい、実際に事故になる設定が落ちます。★核は「ファイアウォール設計」シートです。Windowsファイアウォールにはプロファイルが3つあり（ドメイン／プライベート／パブリック）、規則は選んだプロファイルでしか効きません。さらにプロファイルは NLA が自動判定するため、起動時にドメインコントローラーへ到達できないとパブリックに落ち、ドメインの規則が効かなくなります。「ここからは繋がるのに、あそこからは繋がらない」の大半がこれです。★共通設計の「更新と再起動」では、再起動をいつ行うかを設計として決めさせています。無期限に延ばすと更新は当たったことにならず、既定のままだと業務時間中に再起動します。★既定値は版と累積更新で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
Active Directory パラメータシート（AD DS / Windows Server 2022）
FSMO・機能レベル・サイトとレプリケーション・GPOの適用順を書く Active Directory（AD DS）のパラメータシートです。★核は2枚です。（1）サイト・レプリケーション設計 … サブネットをサイトへ登録していないと、クライアントがどのDCで認証するかが決まりません。拠点の端末が本社のDCで認証して遅くなる形で出ますが、動いてはいるので気づけません。（2）GPO設計 … 適用順は ローカル → サイト → ドメイン → OU で、後に適用されたものが勝ちます。さらに同一コンテナ内の複数リンクは「リンクの順序」の番号が小さいものが後に適用されて勝ちます（番号が大きい方ではありません）。★FSMOは5役割それぞれ「停止したときに何が起きるか」を備考に書いてあります。★既定値は版とドメインの作成時期で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。★Windows Server パラメータシートとは別に立てています。OSのベースラインとはパラメータの性質が違い、混ぜると両方が薄くなるためです。
RHEL 9 / Rocky 9 パラメータシート
エンタープライズLinuxの主流。RHEL と Rocky / AlmaLinux は同じ系統なので1本にまとめ、違う箇所（サブスクリプション）だけを分けて書いています。★核は2枚です。（1）SELinux設計 … 「動かない」の原因がSELinuxであることは多いのに、エラーメッセージがSELinuxを指しません。そのため無効化して回避されがちですが、無効から有効へ戻すには全体の再ラベル付けが必要になり、実質戻せなくなります。ラベル・ブール・ポートの3つで大半が解けることを表にしました。（2）firewalld ゾーン設計 … どのゾーンにも明示的に割り当てていないインターフェースは既定ゾーンに入り、送信元による割り当てはインターフェースによる割り当てより優先されます。--permanent の付け忘れ（消える）と --reload の忘れ（効かない）が両方向で起きます。★既定値は版とインストール時の選択で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
Dell iDRAC 9 パラメータシート
Dell iDRAC 9 のパラメータシート。物理サーバーには必ず付いているのに、パラメータシートに載っていないことが多い機器です。OS導入より前に設定しておく必要があり、飛ばすと現地へ行き直すことになります。★核は2枚です。（1）機能とライセンス … リモートコンソールと仮想メディアは上位ライセンスが必要です。ここを確認せずに「リモートで構築する」計画を立てると、当日になってISOをマウントできないことが分かります。機能ごとに必要なライセンスと、無い場合の代替手段を書きます。（2）アラート設計 … BMCはサーバーが落ちても生きている唯一の経路で、ハードウェア障害を最初に知るのはここです。何をどこへ通知し、受けたらどうするかまで決めます。★管理経路の選択（専用NIC か 共有LOM か）も落とし穴で、共有LOMにするとOS側のNIC設定を変えた瞬間に管理経路が切れることがあります。★既定値は世代とfirmwareで変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
HPE iLO パラメータシート（iLO 5 / iLO 6）
HPE ProLiant の管理コントローラ iLO 5 / iLO 6 のパラメータシートです。★核は2枚です。（1）機能とライセンス … グラフィカルなリモートコンソールと仮想メディアは iLO Advanced が必要です。評価ライセンスで構築して、期限が切れてから使えないと気づく事故があります。（2）アラート設計 … BMCはサーバーが落ちても生きている唯一の経路です。何をどこへ通知し、受けたらどうするかまで決めます。★このシートでは「拠点に置いたサーバーのBMC」も扱います。拠点の回線が切れればBMCにも届かないため、「BMCがあるから遠隔で復旧できる」は回線が生きている場合の話です。★AHSログはメーカーへの問い合わせで必ず求められます。取り方を知らないと障害の初動がそこから始まります。★既定値は世代とfirmwareで変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。★Dell iDRAC シートと同じ骨格ですが、ライセンスの名称・CLI・既定値・ログの種類が違うため統合していません。HPEを使う人がDellの記述を読まされないようにするのが機種別シートの趣旨です。
Microsoft 365 パラメータシート（テナント）
Microsoft 365 テナントのパラメータシート。機器ではありませんが、設定項目に既定値があり、既定のままだと事故になるという構造は機器のパラメータシートと同じです。★核は2枚です。（1）条件付きアクセス設計 … 全ユーザーを対象にしたポリシーで緊急アクセス用アカウントを除外し忘れると、管理者を含む全員が締め出され、戻す手段が無くなります。ポリシーごとに状態・対象・除外を表で持ちます。（2）外部共有・ゲスト設計 … 既定のままだと、リンクを知っていれば認証なしで開ける共有が作れます。作った本人もどこまで広がったかを把握できません。★オンプレADとのハイブリッドも扱います。ADのUPNサフィックスが検証済みドメインと一致していないと、同期はできてもサインインできません。★既定値はテナントの作成時期とライセンスで変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
Azure パラメータシート（サブスクリプション）
Azure のサブスクリプション・リソースグループ・ネットワーク・コストを書くパラメータシートです。★核は2枚です。（1）NSG設計 … 優先度の小さいものから評価され、最初に一致したルールで決まります。既定ルールが最後にあり、受信は拒否ですが送信はインターネットへ許可されています。さらにサブネットとNICの両方にNSGを付けると両方が評価され、片方だけ見て「開けたのに通らない」となるのが典型です。（2）コスト設計 … 止めたつもりでも課金が続くものがあります。OSの中からシャットダウンしただけでは計算資源の課金が止まりません。「何が課金され、何をすれば止まるか」を表にしないと、請求書を見てから調べることになります。★アドレス空間はオンプレと重ねないでください。記入例はオンプレ 192.168.0.0/16 に対して Azure 側を 10.10.0.0/16 にしてあります。★Microsoft 365 シートと同じ Entra ID を使いますが、設計の軸が違うため別に立てています。
NetApp ONTAP パラメータシート（ONTAP 9.x）
NetApp ONTAP 9.x のパラメータシート。ストレージは設定を間違えたときの復旧が最も重く、止まると上に載っている全部が止まります。★核は2枚です。（1）容量設計 … シンプロビジョニングとスナップショットの組み合わせで、アグリゲートが満杯になるとその上のボリュームが書き込めなくなります。1つのボリュームの暴走が全部を止めます。「ファイルを消したのに空き容量が増えない」もスナップショットが掴んでいるためで、この表は利用者への説明にも使えます。（2）LIF設計 … LIFは役割ごとにフェイルオーバーの挙動が違います。ファイル共有（NAS）のLIFは別ポート・別ノードへ移動しますが、iSCSI/FC（SAN）のLIFは移動せず、冗長はホスト側のマルチパスで担保します。ここを取り違えると片系障害の想定を誤ります。★記入例は vSphere パラメータシートのiSCSIデータストアを提供するストレージという位置づけにしてあります。
SQL Server パラメータシート（SQL Server 2022）
SQL Server 2022 のパラメータシート。Windows環境にほぼ必ずあります。既定値のまま動いてしまうため、問題が出るのは負荷が上がってからか、障害が起きてからです。★核は2枚です。（1）バックアップ・復旧設計 … 完全復旧モデルなのにトランザクションログのバックアップを取っていないと、ログが増え続けてディスクが枯渇し、データベースが止まります。新規データベースは雛形（model）を引き継いで既定で完全復旧モデルになるため、意識せずにこの状態になります。（2）インスタンス設定 … メモリ・並列度・tempdb・自動拡張の既定値は、そのままだと性能が出ない・OSを圧迫する・拡張のたびに止まる、という形で効いてきます。★照合順序はインストール時に決まり、後から変えるにはシステムデータベースの再構築が必要です。導入前に確定させてください。★記入例は Windows Server パラメータシートの業務アプリサーバーに同居する構成にしてあります。
Nutanix AHV パラメータシート（AOS 6.x）
Nutanix AHV（AOS 6.x）のパラメータシート。HCIの国内主力です。vSphereシートと同じ位置づけ（どちらを採用するかの選択）です。★核は2枚です。（1）耐障害性・容量設計 … 「容量が余っているように見えて、実は1ノード落ちたら復旧できない」が起きます。ノードが落ちると残りのノードでデータを作り直すため、常に1ノード分の空きが必要です。使用率だけを見ていると、この状態に気づけません。再構築中はさらに余裕が減り、そこで2台目が落ちると停止します。（2）ネットワーク設計 … 管理（ハイパーバイザ・ストレージ制御VM）と業務が同じ経路に乗ります。物理スイッチ側で管理VLANを落とすと、クラスタそのものが見えなくなります。アップリンクの束ね方も物理側と揃っていないと、帯域も冗長も想定どおりになりません。★既定値は版と構成で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
バックアップソフト パラメータシート（Veeam / Arcserve 等）
Veeam・Arcserve などバックアップ製品の設定値を書くパラメータシートです。★核は3枚です。（1）保持・世代設計 … 「14世代」が何日前まで戻れるかは方式で変わります。世代は回数であって日数ではありません。増分は前の復元ポイントに依存するため、連鎖の途中が壊れるとそこから先が戻せません。そして最大の問題は、保持を短くしても・復元ポイントが消えても、「戻したいとき」まで誰も気づかないことです。（2）リポジトリ設計 … 保存先は数ではなく「何に耐えるか」で数えます。同じ拠点・同じ認証で入れる先を2つ用意しても、耐えられる事象は増えません。（3）整合性とリストア … ★ジョブが「成功」でも整合性が取れているとは限りません。整合性の処理に失敗しても、警告のままバックアップが完了することがあります。★製品ごとに画面も用語も違うため、確証のない既定値・挙動は「要確認」と明記しています。★既存の「バックアップ・リストア設計/手順書」が「何を・どこまで戻すか」を決める文書なのに対し、こちらは「それを製品にどう設定するか」を書く側です。RPO/RTOをこのシートで決め直さないでください。
F5 BIG-IP パラメータシート（LTM / TMOS 17.x）
F5 BIG-IP（LTM / TMOS 17.x）のパラメータシート。国内エンタープライズのロードバランサの定番です。★核は3枚です。（1）モニター設計 … 「監視は上がっているのに振り分けられない」「落ちているのに送り続ける」はここで決まります。モニターを付ける対象で落ちる範囲が変わり、ノード（IPだけ）に付けたモニターはそのIPを使うすべてのプールに効くため、1サービスだけ落とすつもりが全部落ちます。静的ファイルを見に行くモニターは、アプリが落ちても上がったままになります。（2）SNATと経路設計 … 「振り分けはされているのにページが出ない」の多くは戻りの経路です。行きはVIP宛なので必ずBIG-IPを通りますが、戻りはサーバーの経路次第で直接返り、通信が成立しません。SNATを入れると解決しますが、今度はサーバーのログのクライアントIPが全部BIG-IPになります。（3）パーシステンスとHA … 「ログインが切れる」はここです。維持の方式には使える条件が先にあり、HAを組んでも接続のミラーリングをしていなければ切替の瞬間に既存の接続は切れます。★既定値は版と構成で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
Palo Alto パラメータシート（PAN-OS 11.x）
エンタープライズ・大規模向けの次世代ファイアウォール Palo Alto（PAN-OS 11.x）のパラメータシートです。★核は3枚です。（1）セキュリティポリシー設計 … 上から順で最初に一致したもので決まるのはFortiGateと同じですが、この機器に固有なのは既定の扱いです。★同一ゾーン内の通信は既定で許可され、ゾーン間は既定で拒否になります。そして★この2つの既定のルールは、既定ではログを取りません。制御したい通信を同じゾーンに入れると、素通りした上に記録も残りません。（2）App-IDとサービス設計 … ポートではなくアプリケーションで判定します。アプリは数パケット流れるまで確定せず、確定した時点でポリシーが評価し直されます。依存するアプリを許可しないと通りません。★サービスを any にすると、アプリを絞ってもポートは全部開きます。（3）復号設計 … 復号しなければアプリは ssl 止まりになり、絞った意味がなくなります。ただし復号は技術だけの判断ではありません。★既定値は版と構成で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。★FortiGateシートと同じ位置づけ（本社境界をどちらで作るかの選択）なので、記入例も同じ案件・同じ位置に置いてあります。両方を同時に入れる想定ではありません。
PostgreSQL / MySQL パラメータシート
OSS系データベースの2大製品を1枚にまとめています。設定項目の「概念」は共通で、名前と既定値だけが違うため、PostgreSQL と MySQL のパラメータ名を並記する対応表の形にしました。使う製品の列だけを埋めてください。★核は3枚です。（1）接続と認証設計 … 「繋がらない」の原因がここに集まります。★待ち受けるアドレスの既定はローカルのみで、そのままだと外から繋がりません。接続元の許可は★PostgreSQL は上から順で最初に一致した行、MySQL はより具体的なホストが優先されるため、追加した行が効かないことがあります。さらに接続数の上限はアプリ側の接続プールの合計と合わせないと、DBが正常でも新規接続だけが拒否されます。（2）バックアップと復旧設計 … まるごと取っただけでは取得時点にしか戻れません。任意の時点へ戻すには変更の記録（WALのアーカイブ／バイナリログ）が要ります。★レプリケーションはバックアップではありません。誤削除は複製先へ即座に伝わります。（3）保守設計 … 更新・削除で出た不要領域は自動では戻りません。★整理が止まると表が膨らみ、PostgreSQL では内部の番号が一周した時点で書き込みが止まります。統計情報が古いと実行計画が変わり、突然遅くなります。★既定値は版で変わるため、公式ドキュメントで裏が取れたものだけを記載し、それ以外は「要確認」と明記しています。
Webサーバー パラメータシート（IIS / Apache / nginx）
Webサーバーの主要3製品を1枚にまとめています。設定項目の「概念」は共通で名前と書き方だけが違うため、3製品のパラメータ名を並記する対応表の形にしました。使う製品の列だけを埋めてください。★核は3枚です。（1）サイトとTLS設計 … 名前で振り分けたとき、★どの名前にも一致しなかった要求がどこへ行くかが製品ごとに決まっています。Apache は最初に定義した VirtualHost、nginx は default_server（指定が無ければ最初の server ブロック）、IIS はホスト名なしのバインドが受けます。受け皿を明示しないと、IPアドレスで直接叩いただけで内部向けのサイトが見えます。名前で分けているのに証明書が1枚しか無いと、別サイトの証明書が返ります。（2）ログとクライアントIP … ロードバランサの配下では★アクセスログの送信元が全部LBのアドレスになります。元のIPを渡してもらい受け側で記録する設定が要りますが、★無条件に信頼すると利用者が自由に偽装できます。信頼する送信元をLBのアドレスだけに限定してください。（3）公開範囲設計 … 既定のままだと余計なものが見えます。索引ファイルが無いディレクトリの一覧、置き忘れた .bak、詳細なエラーページ、製品名と版数。「置かない」が第一ですが、置かれる前提で塞ぐ設計にします。
Cisco ASA / FTD パラメータシート
Cisco ASA / FTD の設定値を書くパラメータシートです。この機種は既存環境で残存していることが多く、更改案件では「現行がどう通しているか」を読む文書としても使います（現行環境調査報告書と対で読んでください）。★核は3枚です。（1）インターフェースと security-level 設計 … インターフェースごとに 0〜100 の数値を持ち、★その大小だけで既定の通り方が決まります。高いところから低いところへは何も書かなくても通り、低いところから高いところへは通らず、同じ数値同士も通りません。ゾーン間が既定で拒否になる機種とは考え方が逆になる場面があり、他機種の感覚をそのまま持ち込むと「書いていない通信が通っている」状態になります。（2）ACL と NAT 設計 … ★ACL を1本付けた時点で、そのインターフェースの入力は全部 ACL で決まり、security-level による既定の許可は消えます。「1つ足すだけ」のつもりが全断になります。★ACL に書くのは変換後（実際の）アドレスで、古い世代の設定をそのまま持ち込むと合いません。NAT は書いた場所ではなく区分で評価順が決まります。（3）反映と ASA / FTD の違い … 同じ筐体でも中身が違い、★ASA は入力した時点で有効、FTD は配備しないと反映されません。どちらも★設定を変えても既に張られている接続は残ります。★FortiGate・Palo Alto シートと同じ位置づけ（本社境界をどれで作るかの選択）です。
A10 Thunder パラメータシート（ACOS）
国内シェアの高いロードバランサ A10 Thunder（ACOS）のパラメータシートです。★核は3枚です。（1）ヘルスモニター設計 … 監視を付ける対象で落ちる範囲が変わります。サービスグループのメンバーに付ければそのメンバーだけですが、★実サーバーに付けると、その実サーバーを使っている全部のサービスグループから外れます。1つ落とすつもりが全部落ちます。（2）戻りの経路と source NAT … 行きはVIP宛なので必ずこの機器を通りますが、戻りはサーバーの経路次第で直接返り、通信が成立しません。★この機種は ip nat pool を作っただけでは効きません。仮想ポート側で使うと指定するまでが1組で、プールを作った時点で満足しやすいのが落とし穴です。（3）保存と冗長（VRRP-A）… ★設定を入れた時点では動きますが保存されていません。そして★冗長を組んでいると、保存を実行するまで「未同期」のままになります。保存を忘れると、保存もされず同期もされません。★構成・コマンド・冗長の仕様は A10 公式ドキュメントで裏を取り、確証のないものは「要確認」と明記しています。★BIG-IPシートと同じ位置づけ（負荷分散をどちらで作るかの選択）なので、記入例も同じ案件・同じ位置に置いてあります。両方を同時に入れる想定ではありません。
サーバー本体 パラメータシート（BIOS/UEFI・RAID・ファームウェア）
サーバー本体（BIOS/UEFI・RAID・ファームウェア）のパラメータシート。富士通 PRIMERGY（iRMC）／Lenovo ThinkSystem（XCC）／NEC Express5800（EXPRESSSCOPE エンジン）などを想定していますが、★ベンダー非依存で書いています。呼び名が違うだけで、設定する項目と踏む失敗は同じだからです。Dell PowerEdge・HPE ProLiant でも同じ考え方で使えます。★既存の iDRAC シート・iLO シートとの分担 … あちらは管理コントローラ側（アクセス・ライセンス・アラート）、こちらは本体側（起動方式・アレイ・ファームウェア）です。★核は3枚です。（1）ブート設計 … 起動方式（UEFIかどうか）とセキュアブートは、★OSを入れた後で変えると起動しなくなります。最初に決めるしかありません。起動の順序は、保守で挿した媒体から立ち上がる事故につながります。（2）RAID（アレイ）設計 … ★構成は後から変えられません。作り直しはデータ消去なので、運用開始後は実質できません。さらに★書き込みキャッシュを守る部品（電池・コンデンサ）が寿命で切れると、キャッシュが自動で無効になって性能が落ちます。設定を何も変えていないのに急に遅くなるので、原因にたどり着きにくい項目です。（3）ファームウェア設計 … ★最新が正解ではありません。仮想化基盤やストレージ側が「この版」と指定する対応表があり、単体で最新にすると外れます。
FCスイッチ パラメータシート（Brocade / Fabric OS）
SANのFCスイッチ（Brocade / Fabric OS）のパラメータシートです。★核は3枚です。（1）ゾーニング設計 … ★有効なゾーン設定が無いときの既定は「全機器が互いに見える」です。ゾーンを入れる前の期間は、何も書いていないのに全部が見えています。そして★定義しただけでは効きません（定義と有効は別）。ファブリックで効いている設定は1つだけなので、新しい設定を作って有効にすると、それまでの内容が丸ごと効かなくなります。（2）ファブリックとマージ設計 … ISLを繋ぐと設定が合流し、競合があるとマージされず★ISLが分離します。★中身が同じでもメンバーの並び順が違うだけで不一致と判定され、分離します。ドメインIDが両方とも固定されていると、片方を変えるまで解決しません。（3）反映と退避 … 有効化と保存は別の操作で、既定ポリシーも確定の操作をしないと効きません。★既定ポリシー・マージ時の分離条件・並び順の判定は Broadcom の公式ドキュメントで裏を取っています。★既存の「ゾーニング設計表」との分担は、あちらが「どの機器とどの機器を組むか」（WWPN・エイリアス・ゾーン定義・適用記録）、こちらが「それをスイッチにどう設定し、どう反映し、増設時に何が起きるか」です。
ブロックストレージ パラメータシート（Dell・HPE・富士通 ほか）
Dell PowerStore・Unity、HPE Nimble・Alletra、富士通 ETERNUS などを想定していますが、★ベンダー非依存で書いています。呼び名が違うだけで、設定する項目と踏む失敗は同じだからです。NetApp ONTAP は別シートで、どちらを採用するかの選択になります。★記入例はSANの鎖として繋いであります（サーバー本体 → HBA → FCスイッチのゾーニング → ストレージのホストマッピング → 仮想化基盤のデータストア）。★核は3枚です。（1）ホストマッピング設計 … ★ゾーニングで見えるようにしても、ストレージ側で割り当てなければ見えません。「ゾーンは通っているのに見えない」の正体で、見えるまでに2段階あります。そして★共有前提でないOSに同じボリュームを複数台から見せるとデータが壊れます。動かないのではなく壊れるので取り返しがつきません。（2）マルチパス設計 … ★冗長のはずが片パスで動いている、が構築直後から起きます。マルチパスの仕組みを入れていないと同じボリュームが複数のディスクとして見え、パスの本数は数えないと分かりません。（3）プールと容量設計 … ★プールが満杯になると、そのプール上の全ボリュームが書けなくなります。都度確保では割り当ての合計が物理容量を超えても作れてしまいます。
Hyper-V / Azure Stack HCI パラメータシート
Hyper-V / Azure Stack HCI で仮想化基盤を作るときのパラメータシートです。★核は3枚です。（1）クラスタとクォーラム設計 … クラスタが動き続けられるかは★過半数を保てるかで決まります。「1台落ちても大丈夫」は台数と監視の組み合わせで決まるので、台数だけでは判断できません。★偶数ノードでは監視（ウィットネス）が必須で、無いと片方が落ちたときに同数で分かれてクラスタ全体が止まります。そして★監視をクラスタの中に置くと一緒に落ちて意味がありません。（2）記憶域とVM設計 … ★全ノードへ同じ番号で見せ、共有ボリュームに変換しないとVMを移動できません。所有ノードへの迂回が起きると「急に遅くなった」の形で出ます。★VMの世代は作成時に決まり、後から変えられません。（3）ネットワーク設計 … ★クラスタ通信が詰まると、ノードが落ちたと判定されて動いているVMが強制的に移動します。業務は動いているのに勝手に移る形で出るので原因が分かりにくい項目です。★もう一つ、Azure Stack HCI 固有として、導入後30日以内の登録と30日ごとの同期が必要で、切れると既存VMは動き続けるものの新規作成と移動ができなくなります（Microsoft の公式ドキュメントで確認済み）。★vSphere・Nutanix AHV と同じ位置づけ（仮想化基盤をどれで作るかの選択）です。
ソフトウェアLB パラメータシート（nginx / HAProxy）
nginx / HAProxy でロードバランサを作るときのパラメータシートです。★装置を買わない選択肢なので、装置側の2本（BIG-IP・A10 Thunder）とは核が違います。★核は3枚です。（1）ヘルスチェック設計 … ★nginx の無償版には能動的なヘルスチェックがありません（NGINX Plus の機能）。無償版で使えるのは受動的な確認だけで、max_fails（既定1回）と fail_timeout（既定10秒）により、★実際の利用者のリクエストが失敗しないと「落ちた」と分かりません。つまり最初の何人かは必ずエラーになります。HAProxy は無償版でも能動的に確認できるので、★製品を選ぶ段階で効く違いです。（2）設定の反映と冗長 … 設定はテキストなので★1つの誤字で全サービスが落ちます。必ず検査してから反映してください。再読み込みと再起動を取り違えると既存の接続が切れます。そして★装置と違って筐体のHAが無く、冗長は自分で組むことになります。監視の経路が1本だと両方が現用になり、同じIPが2つ存在します。（3）OSと資源設計 … ★装置ではないのでOS側の上限が効きます。同時接続数はLBの設定だけ上げても増えず、バックエンドへ出る送信元ポートが枯渇すると「途中から繋がらない」形で出ます。★能動的な確認の可否は nginx 公式ドキュメントで裏を取っています。
スイッチ パラメータシート（Cisco以外 / アライド・HPE・エクストリーム ほか）
アライド・HPE・エクストリームなど Cisco以外 のスイッチのパラメータシートです。★ベンダー非依存で書き、★Catalyst と考え方が違うところに寄せてあります。★核は3枚です。（1）VLANとタグ設計 … ★Cisco は「ポートの型（access / trunk）を選ぶ」ですが、多くの機種は「VLANごとに untagged / tagged でポートを入れる」書き方です。考え方が根本的に違うので、Cisco の感覚で読むと設定の意味を取り違えます。表に「Cisco での言い方」の列を持たせて、頭の中を移せるようにしました。★上位で管理VLANを通し忘れると管理に入れなくなり、復旧は現地作業になります。（2）ループ防止設計 … ★ループを作ると、そのVLANの通信が全部止まります。1本繋いだ瞬間に起きて、抜くまで戻りません。エッジポートの設定を飛ばすと「ケーブルを挿してもすぐ繋がらない」になります。（3）他ベンダーとの相互接続 … ★リンク集約の方式・タグの解釈・ループ防止の方式・MTU が揃っていないと、繋がらないか不安定になります。MTU の食い違いは「小さい通信は通るのに大きいのが落ちる」形で出ます。★Cisco Catalyst シートとの分担は、あちらが Catalyst 固有のコマンドで書いた1機種のシート、こちらがそれ以外の機種です。記入例は同じ案件で、Cisco のコアスイッチに別ベンダーのフロアスイッチを増設する構成にしました（相互接続の核が実例として効くため）。
NAS パラメータシート（QNAP / Synology ほか）
小規模拠点向け NAS（QNAP / Synology ほか）のパラメータシート。バックアップ用途で実際に使われる機種です。★ベンダー非依存で書いています。NetApp ONTAP・ブロックストレージのシートはデータセンターに置く業務用の共有ストレージですが、こちらは拠点に置く小さい箱で、管理画面がWebで、機能を後から追加できて、★インターネットへ出す仕組みが用意されているという点がまったく違います。踏む失敗も別物です。★記入例はバックアップソフトのシートに繋げてあり、あちらの repo-secondary（大阪支店）がこの機種にあたります。★核は3枚です。（1）外部アクセスと公開範囲 … ★この機種で最大の事故要因です。インターネットから使う仕組みが用意されていて、導入時に有効化を促されます。さらに★機器が自分でファイアウォールに穴を開ける仕組みがあり、「開けた覚えがないのに外から届く」が起きます。被害が出るのはたいていここです。（2）共有と権限設計 … ★誰でも読める設定や全員向けの権限が既定で付いていることがあります。そして★書ける範囲を絞らないと、端末が暗号化されたときに書ける範囲が全部やられます。（3）バックアップ保存先としての設計 … ★「別の場所にある」だけでは保護になりません。本社と同じ認証で入れるなら、本社をやられた時点で一緒にやられます。
Cisco MDS パラメータシート（NX-OS）
Cisco MDS（NX-OS）で SANのFCスイッチを作るときのパラメータシートです。★VSAN と★反映の仕方に集中しています。★核は3枚です。（1）VSAN設計 … 同じ筐体を論理的に分ける仕組みで、★VSANごとにファブリックの仕組みが独立します。ゾーニングもVSANごとなので、「有効な設定は1つ」という他機種の感覚で読むと取り違えます。★ポートをVSANに入れ忘れると VSAN 1 に入ります。★VSANをまたぐ通信はできません。（2）ゾーニングと反映 … 有効化はVSANごとで、有効化と保存は別の操作です。そして★既定ゾーンの方針はファブリックの他のスイッチに配布されません。ゾーンの内容は配られるのに、既定ゾーンの方針だけは各スイッチで設定が必要です。増設したスイッチだけ方針が違う、が起きます。ここが最も見落とす点です。（3）ファブリックと増設 … ドメインIDはVSANごと。ポートのモードを明示します。★既定ゾーンの扱い・拡張ゾーニングのコミット・拡張ゾーニングが既定で無効であることは Cisco 公式ドキュメントで裏を取っています。★Brocade FCスイッチ シートと同じ位置づけ（SANのFCスイッチをどちらで作るかの選択）です。共通する話（ゾーンの中身をどう決めるか、WWPNで組む、開始側1つ・対象側1つ）はあちらとゾーニング設計表に任せています。
メール基盤 パラメータシート（メール・グループウェア）
ドメインとしてのメール基盤（送信ドメイン認証・経路・受信の保護）のパラメータシートです。★サービスに依存しない書き方にしています。クラウドでもオンプレでも踏む失敗は同じだからです。★核は3枚です。（1）送信ドメイン認証設計 … ★SPF は1つのドメインに1レコードしか置けません。複数あると評価が失敗して全部が通らなくなります。サービスの案内どおりに「TXTレコードを追加」してしまい、2つ目ができる事故が多い項目です。★DNSを引く回数にも上限（10）があり、include を重ねると超えて失敗します。空振りする参照にも上限（2）があります。そして★DMARC は「SPFが通っている」だけでは成立しません（ドメインが揃っている必要があります）。（2）経路と送信元設計 … ★抜けるのは人が読むメールではありません。業務システムの通知・監視の通知・複合機からの送信・外部サービスです。★届かないことに、障害のときまで気づけません。（3）受信と保護設計 … ★外から来た自ドメインの差出人を止めます。最も使われる手口です。★SPFの規格値は RFC 7208 で裏を取っています。★Microsoft 365 シートはテナント側（条件付きアクセス・外部共有）で、メールの基礎には触れていません。
BMC パラメータシート（iRMC / XCC / EXPRESSSCOPE）
Dell iDRAC・HPE iLO 以外の管理コントローラ——富士通 iRMC / Lenovo XCC / NEC EXPRESSSCOPE の3製品対応表です。★核は2枚。（1）名前の対応表 … ビデオリダイレクション／リモートコンソール／リモートKVM は全部「画面を遠隔で見る機能」、バーチャルメディア／仮想メディア／リモートメディアは全部「ISOを遠隔で挿す機能」。★呼び名が違うだけの項目を、違う機能だと思って設計しないための表です。（2）ライセンスと機能 … ★3社とも「画面を見る」と「ISOを挿す」は追加ライセンスが要ります。ここを確認せずに「リモートで構築する」計画を立てると、当日になってISOをマウントできないことが分かります。しかも★罠が3社で違います——富士通はライセンスがキーと microSD カードの組で来ることがあり（物理媒体なので現地に持って行かないと有効化できない）、Lenovo は Standard → Advanced → Enterprise の順にしか上げられず（飛び級できない）、NEC は★30日間の評価ライセンスが付属します（構築中は使えてしまい、切れたことに気づくのは次の保守作業のとき）。サーバー本体（BIOS/UEFI・RAID・ファームウェア）は別のシートです。
脆弱性管理台帳
公表された脆弱性を「当てたか」で管理する台帳は多いのですが、実務で本当に困るのは**当てられないもの**のほうで、そこが記録に残りません。監査で聞かれるのも「当てたか」ではなく「なぜ当てていないか」です。★核は3つ。（1）優先度を CVSS だけで決めない … 到達性（インターネットから触れるか）を列にして、数式で優先度を出します。CVSS 9.8 でも到達経路が無ければ後回しでよく、CVSS 7 でも公開サーバーなら先に当てます。この2軸が無い台帳は、数字の大きい順に並べたところで手が止まります。（2）「適用しない」と決めたものを別シートにする … 恒久的に残るので、月次の一覧に混ぜると流れて誰も見なくなります。★再評価日を必須にして、永久に放置できないようにしてあります。（3）緩和策が何に依存しているかを書かせる … 「FWで塞いでいるから当てない」は、そのFWルールが消えた瞬間に破綻します。依存先を通信要件一覧のルールIDで書けば、棚卸しでそのルールを消すときにこの台帳から戻ってこられます。記入例では、緩和が**期限切れのFWルール**に依存している状態をわざと置いてあります。情報源のシートもあり、機器一覧のメーカー分だけ行を作る形にしています（1つのまとめサイトを見ていれば足りる、ということはありません）。
会議体・連絡体制定義
立ち上げで「週次定例は木曜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枚、契約番号）まで書かせます。
キャパシティ管理表
サイジング設計書は「5年後にどれだけ要るか」を見積もります。ですが運用に入ったあと、**その見積りが当たったかを誰も確認しません**。増設の判断は、たいてい「そろそろ厳しいらしい」という感覚で始まります。★核は「使用率だけを見ない」ことです。増加の速さと**調達のリードタイム**を並べ、判断ラインに到達するまでの月数を数式で出します。到達予測がリードタイムを下回った行は赤くなります——★記入例の「バックアップ保存先」は使用率73%で判断ライン80%に届いていないのに、到達予測1.8か月 < リードタイム2か月で**すでに手遅れ**という状態にしてあります。使用率だけを見ていると「まだ余裕がある」に見えます。サイジング設計書の想定値も列に持たせ、見積りと実績を並べます（★記入例の拠点間回線は、5年後のピークを181Mbpsと見積もったのに契約が100Mbps。設計時点で増速が前提だったのに発注されていません）。★「1台停止時」の行も作ります——全体の使用率が低くても、1台落ちたときに載らなければ冗長ではありません。月次の記録シートもあり、同じ条件で毎月採った値をここから写します。
提案書
提案書は放っておくと「自社ができること」を並べた資料になります。ですが読む側が知りたいのは、**自分たちの課題にどう答えるか**と、**何が含まれていないか**の2つだけです。★このテンプレートは、3枚目を「お客様の課題／出典／この提案／効果」の1対1の表にしています。課題には出典（ヒアリングシート・現行環境調査の番号）を付けます——出典の無い課題は、提案する側が想像で書いたものです。効果は測れる形で書きます（記入例は「一次対応15分以内（SLA/SLO SL-06）」「保守期限切れの機器 0台」）。「安定します」「効率化します」は効果ではありません。★5枚目は「含まれるもの／含まれないもの／含まれない理由」に1枚まるごと使います。ここを書かない提案書は、受注後に「これも入っているはず」で必ず揉めます。★6枚目の概算費用は**5年総額の行**を持たせています。初期費用だけを見せると、保守やライセンスの年額が後から出てきます（記入例に金額は入れていません。内訳の項目と行だけが型です）。★7枚目は調達のリードタイムから逆算した**発注の締切**を赤く出します。ここを示さないと「検討します」のまま日程が成立しなくなります。全10枚、16:9。発表者ノートに、そのページで話すことと外してはいけない点を入れてあります。
作業標準書
QC工程表は「何をどう管理するか」を決めます。ですが**その作業をどうやるか**は書きません。QC工程表の使い方には「工程Noは作業標準書と一致させてください」と書いてあるのに、その作業標準書がカタログにありませんでした。ここを埋める1本です。★核は「急所」と**その理由**を必ず書かせることです。「対角の順で締める」だけでは、急いでいるときに省かれます。「片側から締めると座面が浮き、規定トルクでも後で緩む」まで書いて初めて守られ、違う状況でも判断できるようになります。理由が空の行は赤くなります。★工程Noと管理項目を QC工程表と同じ言葉にします。ずれると、標準書どおりに作業してもどの管理項目を満たしたのかが分かりません。★一覧シートは QC工程表の工程をそのまま並べ、**標準書が無い工程を赤く**します——記入例の工程40（熱処理）がそれで、QC工程表には硬度・炉温の管理項目があり、工程能力シートでは Cpk 1.12 と目標1.33に届いていません。**標準書が無い工程で工程能力が出ない**のは偶然ではないことが多いです。★教育・力量の記録が別シートにあります。標準書があっても、認定していない人や期限切れの人が作業していたら標準は守られていません。標準時間を手順ごとに持ち、合計を数式で出すので、工数見積りの根拠にもなります。
検査成績書
検査成績書です。QC工程表が「何をどう管理するか」、作業標準書が「その作業をどうやるか」を決めるのに対して、こちらは**そのとおりにやった結果どうだったか**を残します。★核は合否だけで終わらせないことです。合否だけの成績書からは、規格の中心からどれだけ寄っているかが読めません。記入例の硬度は5点とも合格ですが、HRC 55〜60 に対して 55.2〜56.1 と全部が下限側に寄っていて、QC工程表の工程能力シートで Cpk が 1.12（目標1.33）に届かない原因がそこにあります。「かたより」を数式で出し、規格の中心から70%以上寄った行は橙にします。★もう一つの核は測定器です。校正の切れた器で測った成績書は無効で、監査で最初に見られるのがここです。管理番号から校正の状態を自動で引き、記入例の表面粗さ計（SR-001）は期限が17日前に切れていて行ごと赤くなります——判定は「合格」と出るのに、です。★特採（特別採用）には承認者と承認日を必ず書かせます。空欄は赤。口頭の特採は記録に残らず、「前も通ったから」で次のロットにも引き継がれます。計量値と合否でシートを分けてあるので、どちらの列も空にならずに読めます。
移行設計書（データ移行・件数の突合つき）
移行設計書です。移行のフェーズには移行計画書・移行判定チェックリスト・切り戻し手順書がありますが、どれも**いつ移すか・戻すか**の文書で、**何を・どう移すか**を書く文書がありませんでした。ここを埋める1本です。★核は「件数の突合」です。「移行しました」では終われません。**移行元 − 対象外 − エラー ＝ 移行先**が成り立つことを数式で示します。合わないまま本番へ行くと、足りないことに後から気づけません。記入例のFWポリシーは差が2件出たまま「完了」になっていて、行ごと赤くなります。★桁あふれ・未定義コード・重複は、実データを流すまで出ません。「入るはず」で設計され、リハーサルで初めて落ちます。項目マッピングに「事前に洗うもの」の欄を持たせ、件数が残っている行は橙、対応が空の行は赤にしました。★移行しないものも必ず行にします。「全部持っていく」は決めていないのと同じで、当日に「これは移すんでしたっけ」が出ます。理由が空の行は赤です。★リハーサルの所要時間を残します。移行計画書の「最終判断時刻」は作業枠から逆算しますが、その枠に収まるかはリハーサルの実績でしか分かりません。記入例の1回目は240分の枠に対して268分で、28分超過しています。
RFP回答書（Excel・要求項目への対応表／記入例つき）
RFP回答書は、発注者が出した要求項目に1件ずつ可否を返す対応表です。★判定を「○可／△条件／▲代替／×不可」の4つに分けます。条件付きや代替を○にまとめると、受注後に無償で対応を求められます。★「読み取り」の列を持たせています——RFPの要求は曖昧なことが多く、何を求められていると解釈したかを示さない回答は評価できません。読み替えて答えるなら、読み替えたことを明示します。★RFPの時点では現地を調べていません。「調べれば分かる」ことに○を付けず、発注者への質問書（QN-xx）で聞くか、△にして条件へ書きます。★費用や追加ライセンスが要るものは○ではなく△にし、費用影響を立てます。回答書と見積書は別の人が見るので、回答書だけを見た人は無償だと読みます。★必須要求に×を付けるときこそ、理由と代替の道筋まで書きます。隠して○にすると、受注できても実行できない約束が契約に入ります。未回答・条件の書き漏れ・根拠の無い○・質問の回答を待たずに付けた○を、数式と色で自動検出します（マクロ不使用）。章別の集計では、全項目が○になった章を橙で出します——全部○の回答書は、読まずに答えている疑いがあります。★提出物・様式のシートつき。質問書の提出期限は提案書より前にあり、聞ける期間が先に終わります。記入例は提案書と同じ架空案件（提出期限 2026/04/20・発注のご判断 2026/06/12）で揃えてあり、受注後の引き継ぎ先として要件定義書の REQ-xxx まで書いてあります。
施工品質記録（Excel・検査/測定記録・是正まで）
施工品質記録は、施工計画書で決めた管理基準に対して「実際にどうだったか」を残す記録です。★合否だけを書かないでください。「±3mm 以内で全数合格」と書いても、全部が +2.8mm に寄っていればそれは読めません。実測値をn1〜n5で残し、平均と「かたより（規格中心比）」を数式で出します。かたよりが 0.6 を超えると橙——★全数合格でも、施工の癖か下地の設定値そのものがずれている印です。★1点でも規格を外れたら不合格にします（平均で合格にしません）。★測定器の管理番号を必ず書かせ、校正が切れた器で測った行を赤くします。校正切れの器で測った値は記録として成立しません。記入例では照度計の校正が切れた状態を1件残してあります。★不合格には是正と再検査を必ず付けます。是正日が入っているのに再検査日か結果が空の行は赤——★是正だけ書いて再検査を書かない記録が、この文書で最も多い欠落です。目視で確かめるものは施工チェック記録へ分け、「対象」に母数（3F 全10か所など）を書かせます。★管理基準は施工計画書5章を正とし、数値を二重に持ちません。記入例は施工計画書と同じ案件（ビル内の内装・電気設備工事）で、6工種の管理基準がそのまま入っています。
Kubernetes パラメータシート（オンプレのコンテナ基盤）
オンプレのコンテナ基盤（Kubernetes）のパラメータシート。★核は3枚です。（1）資源設計 …「CPU使用率に余裕がある」と「要求量（requests）の合計に余裕がある」は別のものです。置き場所は要求量の合計で決まるため、使用率が20%でもPodが1つも置けないことがあります。置けないPodはエラーではなく「待ち（Pending）」として残るので、監視していないと誰も気づきません。（2）ネットワーク設計 … PodとServiceのアドレス範囲が社内の既存ネットワークと重なると、その相手にだけ繋がらないという分かりにくい壊れ方をします。しかも後から変えるにはクラスタを作り直すことになります。通信制限（NetworkPolicy）は、通信の担い手（CNI）が対応していないと書いても黙って無視されます。（3）期限管理 … クラスタの証明書には期限があり、切れるとAPIに繋がらなくなります。業務のコンテナは動いたままなので「動いているのに何も操作できない」状態になります。★既定値はディストリビューションと版で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
構成管理・自動化 パラメータシート（Ansible / Terraform）
Ansible / Terraform で構築を自動化するときのパラメータシート。オンプレのインフラ屋に向けて、コードで作ること自体ではなく**コードで作った後に何が起きるか**を書いています。★核は3枚です。（1）差異と状態 … 緊急対応では必ず手で直されます。それは止められないので、戻す手順と期限を先に決めておかないと、コードと現物が静かにずれます。ずれていても普段は誰も困らず、困るのは作り直すときで、そのときには手遅れです。Terraform の状態ファイルは「コードと現物の対応表」で事実上の本体です。失うと作った資源を管理できなくなります（変えることも消すこともできません）。（2）適用の作法 … 適用の前に何が変わるかを見て、適用の後にもう一度流します。属性によっては変更できず「消してから作り直し」になるため、見ずに流すと本番が止まります。「1回目は通るが2回目で壊れる」は本番で初めて出るので、構築時に必ず2回流します。（3）設定時の注意 … この分野で実際に起きる24の失敗と、その回避手順。★項目名の（A）は Ansible、（T）は Terraform 固有です。★既定値は製品と版で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
CI/CD パイプライン設計シート（製品非依存）
CI/CD パイプラインの設計シート。製品には依存しません（Jenkins / GitLab / GitHub Actions など何を使っても決めることは同じです）。★核は3枚です。（1）止める仕組み … 自動化の値打ちは「速く出せる」ことではなく「間違ったものを止められる」ことです。止める条件を決めずに自動化すると、壊れたものが速く本番へ届くようになります。特に「失敗しても進む」設定を1つでも作ると、以降そこは常に通ります。試験の実行件数も見てください。0件でも「成功」になる仕組みが多く、試験が動いていないのに緑に見えます。（2）権限と資格情報 … パイプラインは本番を変えられる権限を持ち、人より強くなりがちです。資格情報がログに出た瞬間、見た人全員が本番を触れるようになります。（3）設定時の注意 … この分野で実際に起きる24の失敗と、その回避手順。★既定値は製品と版で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
監視基盤 パラメータシート（製品非依存）
監視基盤（Prometheus / Grafana / Zabbix ほか）のパラメータシート。監視の仕組みそのものをどう組むかを決めます。製品には依存しません（何を使っても決めることは同じです）。ここから先は Prometheus / Grafana / Zabbix などを想定しています）。★「監視項目一覧」が何を監視するかの表なのに対し、本書は仕組みの側です。監視項目一覧に書いた項目を、この基盤で実際に見られるようにします。★核は3枚です。（1）監視の監視 … 最も重い枚です。監視基盤が止まっても、止まったことを知らせる相手が居ません。「アラートが来ない」は「異常が無い」ではなく「監視が死んでいる」かもしれません。静かなほど安心に見えるので、気づくまでに何日もかかります。（2）保存と容量 … 時系列のデータは増え続けます。保存期間を決めていないとディスクが尽き、ある日突然この基盤自体が落ちます。しかも「過去のデータが要る」と気づくのは障害の後です。（3）通知の設計 … 設定しただけで、実際に届くか試していない例が多くあります。抑制（メンテナンス中の停止）を解除し忘れると、以降ずっと黙ります。★既定値は製品と版で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
VDI パラメータシート（仮想デスクトップ基盤）
VDI（仮想デスクトップ基盤）のパラメータシート。製品には依存しません（何を使っても決めることは同じです）。★核は3枚です。（1）同時利用と資源 … VDI の事故は「足りない」ではなく「同時に集まる」で起きます。台数分の資源を用意しても、朝9時に全員が一斉にログオンすると入れません。平均で設計すると必ず失敗します。しかも遅いだけで止まらないので、基盤の問題だと気づかれにくいのが厄介です。（2）利用者データ … 仮想デスクトップは作り直す前提のものが多く、どこに置いたものが残るかを決めていないと、作り直した瞬間に利用者のデータが消えます。「デスクトップに置いてあったのに」は、消えてから分かります。（3）接続と切断 … 画面を閉じただけでは終わりません。切断後の扱いを決めていないとセッションが残り続けて資源を食い、翌朝に入れなくなります。★既定値は製品と版で変わるため、確証のあるものだけを記載し、それ以外は「要確認」と明記しています。
店舗展開 標準構成書（多店舗）
多店舗（小売・飲食・サービス）の店舗展開で使う標準構成書。★これまでの文書は「1つのシステムを作る」前提でしたが、店舗展開は同じものを何十回も作るのが仕事で、失敗の形もそこから来ます。★核は3枚です。（1）標準構成 … 店舗展開の値打ちは「速く開ける」ことではなく「どの店も同じにする」ことです。1店だけ違う機器・違う設定にすると、その1店のために手順が枝分かれし、以降の全店の作業がその分だけ重くなります。例外を認めるならいつまでの例外かを書いてください。書かない例外は永久に残ります。（2）開店までの逆算 … 開店日は動かせません。回線の手配が最も長いので、そこから逆算します。前から積むと必ず溢れます。（3）現地対応 … 開店後の店舗に技術者は居ません。店員が電話越しにできることしか復旧手段になりません。「見に行けば分かる」は100店舗になると成り立ちません。
医療機関 システム更改計画書（止められない現場）
医療機関（病院・診療所）のシステム更改計画書。★これまでの文書は「止めてよい夜間帯がある」前提でしたが、医療は違います。入院がある限り、止まっている間も患者は居ます。「止められない」のではなく「止まっている間に何が起きるかを決めてから止める」と考えます。★核は3枚です。（1）止める時間の合意 … 止める時間は IT が決めるものではありません。診療科ごとに事情が違うので、誰と何を合意したかを残さないと当日に「聞いていない」が必ず出ます。「夜間なら空いている」も成り立ちません。救急は夜のほうが動きます。（2）止まっている間の運用 … システムが止まっている間も診療は続きます。紙で回す手順と、戻ってからの入力し直しまで決めて初めて止められます。（3）連携先の棚卸し … 電子カルテは単体では動きません。検査・画像・調剤・会計とつながっており、片方だけ更改すると連携が切れます。★制度・法令の細部には踏み込みません（版と地域で変わるため）。扱うのはインフラ更改の進め方です。
調達仕様書（公共調達・発注側）
公共調達で発注側が要求を書く調達仕様書。★Dit には既に RFP回答書（受注側が答える文書）があり、本書はその対です。同じ案件の両側が揃います。★核は3枚です。（1）要求の書き方 … 失敗は「書き漏れ」ではなく「評価できない書き方」です。「高性能であること」と書くと全社が○を付け、差が出ません。数値か、○×で判定できる形にします。判定できない要求は、評価するときに自分が困ります。（2）公平性の確保 … 特定製品の型番を書くと、その1社しか応札できません。★「実質1社しか満たせない条件」は、書いた本人が最も気づきません。現行機と同じ構成を前提に書くと、自然にそうなります。（3）質問と回答 … 入札の質問回答は仕様書と同じ効力を持ちます。口頭で答えず、全社に同じ内容を同じタイミングで公開します。★制度・法令の細部（地方自治法・会計規則など）には踏み込みません。団体・年度で変わるため、扱うのは書き方の側です。
金融機関 システムリスク管理表（報告が要る現場）
金融機関のシステムリスク管理表。★これまでの文書は「直せば終わり」でしたが、金融は違います。直したあとに、外部へ説明する仕事が残り、しかも説明の期限はこちらの都合では決められません。★核は3枚です。（1）事象の区分 … 障害が起きてから「これは報告が要るのか」を相談すると必ず遅れます。どの事象がどの区分になるかを平時に決めて表にします。迷ったら重いほうに倒してください。後から下げるのは記録に残せば説明できますが、上げるのは「なぜ最初に気づかなかったか」を問われます。（2）時刻と記録 … 報告の期限は「気づいた時刻」ではなく「起きた時刻」から数えられることがあります。検知が遅れた分だけ、報告に使える時間が減ります。時刻同期が無いと、何が先に起きたかを説明できません。（3）平時の備え … 直す人と説明する人を分けてください。同じ人だと必ずどちらかが止まります。★制度・法令・監督指針の細部には踏み込みません。業態・年度で変わるため、扱うのは管理表の作り方です。
介護施設 事業継続計画（BCP）
介護施設の事業継続計画（BCP）。★これまでの近い文書（バックアップ・リストア設計）は「データを守る」話でしたが、介護は違います。守るのは人の生活で、しかも避難できない利用者が居ます。電気が止まっても、水が出なくても、職員が来られなくても、その場でケアが続きます。★核は3枚です。（1）続けること／諦めること … 全部を続けようとすると全部が中途半端になり、職員が先に倒れます。命に関わるケア（食事・水分・排泄・投薬・医療機器）と、そうでないもの（入浴・レクリエーション）を分けます。（2）人の回し方 … 災害で困るのは設備より人です。道路が寸断され、職員自身も被災します。出勤できる人数の段階ごとに、何ができて何を諦めるかを決めておきます。「応援を呼ぶ」は計画ではありません。（3）決める人と備え … 施設長が不在のときに誰が決めるかを、順位で3番目まで名前で書きます。「本部の指示を待つ」は、通信が切れた時点で成り立ちません。★制度（BCP義務化・自治体の指針）の細部には踏み込みません。年度・自治体で変わるため、扱うのは計画の作り方です。
食品 衛生管理記録（HACCP の考え方）
食品の衛生管理記録（HACCP の考え方を取り入れた記録の型）。★製造の品質記録（検査成績書・QC工程表）は「作ったものが規格に合うか」を見ますが、食品は違います。規格に合っていても、記録が無ければ出荷できません。記録を残すこと自体が求められる分野です。★核は3枚です。（1）重要管理点 … 全部の工程を同じ重さで管理すると、どこも守れません。健康被害に直結する工程だけを選び、そこは必ず記録します。選ばなかった理由も残してください。（2）外れたとき … 記録の値打ちは「守れた」を残すことではなく「外れたときに何をしたか」を残せることです。温度が上がった・時間が超えた、は必ず起きます。そのときの処置が残っていないと、出荷したものが安全だったと説明できません。（3）さかのぼり … どのロットがどこへ行ったかを辿れないと回収できません。「たぶんこの日の分」では範囲が決まりません。★制度（食品衛生法・業種別手引書）の細部には踏み込みません。業種・規模・年度で変わるため、扱うのは記録の型です。
倉庫作業手順書（入荷〜出荷）
倉庫の入荷から出荷までを工程ごとに決めた手順書。★倉庫の事故は、作業そのものより「確認を飛ばしたこと」で起きます。入荷検品を飛ばせば、在庫は最初から合っていません。だから工程ごとに「誰が確認するか」「何を残すか」を決めてあります。★核は3つです。（1）工程別手順 … 入荷・格納・保管・ピッキング・梱包・出荷・返品の22工程について、何を確認し、誰が見て、何を記録するかを並べています。（2）在庫が合わないとき … 在庫差異は必ず出ます。出ること自体は問題ではありません。問題は、出たあと「システムを実数に合わせたのか、実数を探し直したのか」が残らないことです。残っていないと、次に差異が出たときに同じ調べ方ができません。（3）誤出荷を止める … 誤出荷は「気をつける」では減りません。ダブルチェックは人が増えるだけで、同じ思い込みは2人とも通します。バーコード・重量・員数という別の情報で照合する形にします。★倉庫業法・貨物自動車運送事業法・改善基準告示の細部には踏み込みません。事業の種類・規模・年度で変わるため、扱うのは作業の型です。
運行管理記録（点呼・日報・拘束時間）
運行管理の記録の型（点呼・日報・拘束時間）。★この分野は「記録が無いこと自体が問われます」。倉庫の在庫は合わなければ後から分かりますが、点呼は残っていなければ「やっていない」と扱われます。やったかどうかではなく、残っているかで判定されます。★核は3つです。（1）点呼 … 乗務前・乗務後・中間の12項目について、何で見て何を残すかを並べています。酒気帯びの確認は検知器を使い、結果を数値で残します。「異常なし」だけの記録は何も証明しません。（2）拘束時間 … 翌日に集計しても遅く、配車を決める時点で見ます。超えてから気づいても戻せません。（3）日報 … 書かせるだけで誰も見ない日報は時間を捨てているのと同じです。項目を増やす前に、その項目を何に使うかを決めます。荷待ち時間は、荷主と話すときの唯一の根拠になります。★貨物自動車運送事業法・改善基準告示・道路交通法の細部には踏み込みません。事業の種類・車両の区分・年度で変わるため、扱うのは記録の型です。
個人情報管理台帳（保有・委託・漏えい時）
個人情報の管理台帳（保有・委託・開示請求・漏えい時）。★医療（要配慮個人情報）を基準に作っていますが、業種を問わず要る文書です。重いほうに合わせてあるので、他の業種では削れる欄があります。★核は3つです。（1）保有する情報 … 部署ごとではなく業務ごとに書きます。「顧客名簿」では足りません。どの業務で・何のために・どこに置いてあるかです。置き場所が分からない個人情報は、漏れたときに範囲が決まりません。保管期限の無いものは永久に残り、その分だけ危険が増えます。バックアップと共有フォルダを忘れないでください。（2）外に出すもの … 委託先・クラウド・共同利用。自社の外に出た時点で見えなくなります。委託先が漏らしても、責任は委託した側にあります。再委託を許したかまで残します。（3）開示請求と漏えい時 … 起きてから考えると必ず遅れます。報告の期限は「気づいた時点」から数えます。「全容が分からないから報告しない」で遅れるのが典型です。★個人情報保護法・ガイドライン・条例の細部には踏み込みません。業種・規模・年度で変わるため、扱うのは台帳の型です。
介護 サービス提供記録・点検表（実地指導の型）
介護のサービス提供記録と点検表（実地指導で見られる形）。★この分野は「記録が無い＝提供していない」と扱われ、しかも後から書けません。実地指導では計画・記録・請求の3つが揃って初めて「やった」と認められ、1つでも欠けると返還になります。書き方の問題ではなく、揃っているかの問題です。★核は3つです。（1）計画と記録と請求 … ケアプランに無いサービスは記録があっても請求できません。逆に、計画にあって記録が無いものも請求できません。3つが1本の線でつながっているかを月次で確かめます。（2）加算の要件 … 「取れる」ではなく「満たし続けている」かで見ます。取り始めるときは確かめても、続いているかは誰も見ません。人員が減った月・研修をやらなかった月に切れていて、後から見つかると返還になります。（3）身体拘束・虐待防止 … 記録の有無そのものが問われます。「やっていない」ことの証明は記録でしかできません。指針・委員会・研修の3点セットは、開催したことを残していないと無かったことになります。★介護保険法・運営基準・自治体の解釈の細部には踏み込みません。サービス種別・地域・年度で変わるため、扱うのは記録の型です。
食品表示・原材料管理表（アレルゲン・期限）
食品の表示と原材料の管理表（アレルゲン・産地・期限）。★衛生管理は「作る過程」を見ますが、表示は「出したもの」を見ます。別物です。温度も時間も守って作ったものでも、表示が違えば回収になります。しかも表示の誤りは、出荷したあとにしか分からないことが多いです。★核は3つです。（1）原材料から表示へ … 仕入先が原材料を変えても、こちらの表示は自動では変わりません。規格書が変わった日を追えないと、いつから表示が違ったかが決まらず、回収の範囲も決まりません。（2）アレルゲン … 「入れた」だけでなく「混ざった」も見ます。同じ器具・同じラインで意図せず混ざるので、使った器具と洗浄の順番まで見ないと防げません。「入っていません」と書くほうが、書かないより難しいです。（3）期限の決め方 … 誰かが決めた数字が引き継がれ、根拠が分からなくなります。試験の結果と安全係数を残さないと、短くも長くもできません（変えてよいか誰も判断できない）。★食品表示法・アレルゲンの品目・自治体の運用の細部には踏み込みません。品目・規模・年度で変わるため、扱うのは管理表の型です。
店舗運営 日次管理表（発注・ロス・シフト）
店舗運営の日次管理表（発注・ロス・シフト・クレーム）。★出店は一度きりですが、運営は毎日続きます。続くものほど型が無いと人に依存し、店長が変わった日にそれまでのやり方が全部消えるのがこの分野の典型です。★核は3つです。（1）発注とロス … 同じ表で見ます。別々に見ると必ず片方に寄り、欠品を嫌えばロスが増え、ロスを嫌えば欠品が増えます。「勘で発注する」は悪くありません。悪いのは、勘の中身が本人にしか無いことです。欠品を数えていない店が多く、機会損失が見えないまま発注が細ります。（2）シフトと作業 … 「埋まったか」ではなく「回るか」で見ます。人数だけ合っていても、できる作業が偏っていれば回りません。1人しかできない作業は、その人が休んだ日に止まります。（3）クレーム … 件数ではなく、同じことが繰り返されているかを見ます。1件ずつ処理すると気づけません。原因は仕組みの側で書きます。「注意不足」と書くと手順が変わらず、同じことが起き続けます。★景品表示法・労働基準法・食品衛生法の細部には踏み込みません。業態・規模・地域で変わるため、扱うのは管理表の型です。
補助金 交付事務チェック表（申請〜検査）
補助金の交付事務チェック表（申請・審査・実績・検査）。★調達は「買う」、補助金は「出す」で、確かめるものが違います。買うときは納品されたものを見ればよいのですが、補助金は「その事業が本当に行われたか」「その支出が対象か」を書類で確かめます。現物が残らない事業（研修・調査・啓発）ほど難しくなります。★核は3つです。（1）段階ごとの事務 … 公募から事後まで18段階について、何を見るかを並べています。審査の記録は情報公開の対象になるので、誰が何を見て判断したかを書ける形で書きます。（2）対象経費 … 交付要綱に書いていないことは審査できません。審査の段になって迷うのは要綱の書き方の問題で、対象と対象外を要綱の時点で並べて書きます。「その他必要と認めるもの」は、認める基準を別に決めないと使えません。（3）返還 … 交付決定の時点で条件と方法を書きます。後から「返してください」と言っても、根拠が無ければ返ってきません。実績が下回っただけなら減額であって返還事由ではなく、この2つは区別して書きます。★補助金適正化法・自治体の規則・国庫補助の要件の細部には踏み込みません。制度・年度・団体で変わるため、扱うのは事務の型です。
顧客管理チェック表（本人確認・反社・疑わしい取引）
顧客管理のチェック表（本人確認・反社・疑わしい取引・苦情）。★システムリスクは「止まったとき」の話ですが、顧客管理は「入口で止める」話です。入れてしまったあとに気づくのと、入口で止めるのとでは、かかる手間が桁で違います。★核は3つです。（1）本人確認 … 取引の入口だけでなく続きも見ます。口座を作るときは確かめても、そのあと住所も職業も変わります。「作ったときの情報」で何年も動いているのが、この分野の典型的な穴です。（2）反社・疑わしい取引 … 反社の確認は「確認した日」を残します。データベースは更新されるので、いつ時点で確認したかが無いと、後から「そのときは載っていなかった」と説明できません。疑わしい取引は現場が「判断しない」で上げる形にします。現場に判断させると上がってきません。上げたが該当しなかった記録も残します（上げたこと自体を評価しないと、次から上がらない）。（3）苦情 … 件数ではなく、同じことが繰り返されているかを見ます。受けたその場で相手の言葉のまま書きます。★犯罪収益移転防止法・金融庁のガイドライン・業態ごとの規制の細部には踏み込みません。業態・規模・年度で変わるため、扱うのは確認の型です。
医療安全 インシデント報告・再発防止台帳（報告から対策の確認まで）
医療安全のインシデント報告・再発防止台帳（報告／影響レベル／要因・対策／確認項目）。★この分野は「報告が集まるか」が全てです。集まらない台帳は、危ないところを教えてくれません。しかも報告は、放っておくと止まる方向にしか動きません。書く手間があり、書けば自分の落ち度として扱われうるからです。★核は4つです。（1）報告した人を責めない … 責めた瞬間、その部署からの報告は止まります。件数は減り、数字の上では安全になったように見えます。★報告件数が減った月がいちばん危ないと考えてください。だからこの台帳には当事者の実名欄を作っていません。職種と経験年数だけです。（2）レベル0・1（実害が出なかったもの）こそ集める … 実害の出た事例は誰でも上げます。上がってこないのは、間に合ったほうです。実害の出た事例しか並んでいない台帳は、手前を拾えていないという意味です。（3）「確認不足」「注意不足」で閉じない … それは原因ではなく、起きたことの言い換えです。人の注意で防ぐ対策は必ず戻ってきます。★仕組みで止める ＞ 物を変える ＞ 手順を変える ＞ 注意を促す、の順に効きます。（4）対策を出して終わりにしない … 確認の日を対策と同時に決めます。決めていない対策は誰も見に来ず、半年後には期限切れの対策だけが並びます。★報告（MS-…）と対策（CA-…）を番号でつなぎます。同じ対策に複数の報告がぶら下がってかまいません。つないでおかないと「繰り返しているか」が見えません。★医療事故調査制度・報告の期限・院内の規程の細部には踏み込みません。病院の規模・機能・年度で変わるため、扱うのは記録の型です。