テンプレートを探す
1本ずつ探すより、使う場面や構成の層でまとまったセットから選ぶほうが早いことがあります。
セットから選ぶ
キットをすべて見る →物流・倉庫 のために作った文書2 件
その業種の決まりや現場の言い方に合わせてあります
倉庫作業手順書（入荷〜出荷）
倉庫の入荷から出荷までを工程ごとに決めた手順書。★倉庫の事故は、作業そのものより「確認を飛ばしたこと」で起きます。入荷検品を飛ばせば、在庫は最初から合っていません。だから工程ごとに「誰が確認するか」「何を残すか」を決めてあります。★核は3つです。（1）工程別手順 … 入荷・格納・保管・ピッキング・梱包・出荷・返品の22工程について、何を確認し、誰が見て、何を記録するかを並べています。（2）在庫が合わないとき … 在庫差異は必ず出ます。出ること自体は問題ではありません。問題は、出たあと「システムを実数に合わせたのか、実数を探し直したのか」が残らないことです。残っていないと、次に差異が出たときに同じ調べ方ができません。（3）誤出荷を止める … 誤出荷は「気をつける」では減りません。ダブルチェックは人が増えるだけで、同じ思い込みは2人とも通します。バーコード・重量・員数という別の情報で照合する形にします。★倉庫業法・貨物自動車運送事業法・改善基準告示の細部には踏み込みません。事業の種類・規模・年度で変わるため、扱うのは作業の型です。
運行管理記録（点呼・日報・拘束時間）
運行管理の記録の型（点呼・日報・拘束時間）。★この分野は「記録が無いこと自体が問われます」。倉庫の在庫は合わなければ後から分かりますが、点呼は残っていなければ「やっていない」と扱われます。やったかどうかではなく、残っているかで判定されます。★核は3つです。（1）点呼 … 乗務前・乗務後・中間の12項目について、何で見て何を残すかを並べています。酒気帯びの確認は検知器を使い、結果を数値で残します。「異常なし」だけの記録は何も証明しません。（2）拘束時間 … 翌日に集計しても遅く、配車を決める時点で見ます。超えてから気づいても戻せません。（3）日報 … 書かせるだけで誰も見ない日報は時間を捨てているのと同じです。項目を増やす前に、その項目を何に使うかを決めます。荷待ち時間は、荷主と話すときの唯一の根拠になります。★貨物自動車運送事業法・改善基準告示・道路交通法の細部には踏み込みません。事業の種類・車両の区分・年度で変わるため、扱うのは記録の型です。
どの業種でも使う文書19 件
議事録・WBS・体制表など。業種を問わず同じ形で使えます
QA管理表（質問票）
回答が返ってこない質問の多くは、聞き方に原因があります。「回答期限」と「遅れると何が止まるか」を必須の列にして、催促の根拠が表の上にある状態にしました。「こちらの案（たたき台）」の欄が空だと橙になります——丸投げの質問は考える負担を相手に渡すので返ってきません。遅延日数を数式で出し、期限超過は赤・3日前から橙。宛先別の未回答件数と最大遅延を自動集計します。返ってこない書き方と返ってくる書き方を対比した「質問の書き方」シートつき。
RFP回答書（Excel・要求項目への対応表／記入例つき）
RFP回答書は、発注者が出した要求項目に1件ずつ可否を返す対応表です。★判定を「○可／△条件／▲代替／×不可」の4つに分けます。条件付きや代替を○にまとめると、受注後に無償で対応を求められます。★「読み取り」の列を持たせています——RFPの要求は曖昧なことが多く、何を求められていると解釈したかを示さない回答は評価できません。読み替えて答えるなら、読み替えたことを明示します。★RFPの時点では現地を調べていません。「調べれば分かる」ことに○を付けず、発注者への質問書（QN-xx）で聞くか、△にして条件へ書きます。★費用や追加ライセンスが要るものは○ではなく△にし、費用影響を立てます。回答書と見積書は別の人が見るので、回答書だけを見た人は無償だと読みます。★必須要求に×を付けるときこそ、理由と代替の道筋まで書きます。隠して○にすると、受注できても実行できない約束が契約に入ります。未回答・条件の書き漏れ・根拠の無い○・質問の回答を待たずに付けた○を、数式と色で自動検出します（マクロ不使用）。章別の集計では、全項目が○になった章を橙で出します——全部○の回答書は、読まずに答えている疑いがあります。★提出物・様式のシートつき。質問書の提出期限は提案書より前にあり、聞ける期間が先に終わります。記入例は提案書と同じ架空案件（提出期限 2026/04/20・発注のご判断 2026/06/12）で揃えてあり、受注後の引き継ぎ先として要件定義書の REQ-xxx まで書いてあります。
WBS・スケジュール表（Excel・ガントチャート自動描画）
進捗率を0/50/100%の3値に制限し、「90%が3週間続く」問題を防ぐWBS。先行タスクより先に始める計画、10営業日を超えるタスク、予定終了を過ぎた未完了タスクを数式で検出します（マクロ不使用）。ガントチャートは条件付き書式で自動描画。
ドキュメント管理台帳（納品物一覧）
文書は作った瞬間から古くなります。更新責任者を必須の列にして、空欄は赤くなります——「みんなで直す」は「誰も直さない」と同じだからです。最終更新日からの経過日数を数式で出し、1年以上更新されていない文書は赤、半年以上は橙。次回見直し日を過ぎた行も赤になります。納品の要否と納品日を分けて持つので、社内文書と納品物を同じ台帳で管理でき、「これは納品するのか」を毎回聞かずに済みます。版数・ファイル名・保管場所・権限の決めごとと、納品・受領記録つき。
プロジェクト計画書
「対象外事項」と「前提条件」を独立章として構造化した計画書。スコープクリープと後々の揉め事の大半は、ここの曖昧さから生まれます。★成功基準に「判定時期／判定者」、対象外事項に「理由／必要になった場合の扱い」、前提条件に「崩れたときの影響」の欄を設けました。管理方針は各領域で使う文書（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。発表者ノートに、そのページで話すことと外してはいけない点を入れてあります。
課題管理表
「ボール（今どちらが持っているか）」と滞留日数で塩漬け課題を防ぐ課題管理表。完了条件・起票元の列つき。期限超過と記入漏れの自動色付け・プルダウン設定済み。
議事録テンプレート（基本形）
決定事項ファーストの議事録。読み手が最初に知りたい「決まったこと・宿題」を冒頭に置く構成です。定例会・顧客打合せに。
議事録（クラウド移行・軽量版）
クラウド移行版をさらに簡略化した軽量版。短時間の打合せ向け。
議事録（クラウド移行案件向け）
公式議事録をフォークし、クラウド移行案件向けに決定事項の粒度と体制欄を調整。
議事録（監査対応・発言録つき）
発言録を残す監査・トラブル対応向けの派生。誰がいつ何を発言したかを追える。★記録者の解釈は「補足」の列に分け、発言そのものと混ぜない。
議事録（社内定例向け）
公式の議事録テンプレをフォークして社内向けに簡略化。社名・敬称欄を削り、Slack転記を前提に宿題事項を先頭へ移動。
進捗報告書（週次定例）
信号機サマリ1枚で全体が伝わる週次報告。「ご依頼事項・要決定事項」専用スライドで報告会を意思決定の場に変えます。
運用引継書
引き継ぎは「説明した」と「受け取った」がずれます。説明した側は終わったつもりで、受けた側は聞いていないと言う。項目ごとに説明日・説明者・受領者・受領日を持ち、両方そろって初めて1項目が完了する形にしました。完了率は数式で出るので「だいたい終わった」で引き渡せません。文書だけでなくアカウント・鍵・媒体・機器・契約書を数えて渡す資産シートと、引継時点の未解決事項を期限と責任者つきで残す残課題シートつき。