テンプレートを探す
1本ずつ探すより、使う場面や構成の層でまとまったセットから選ぶほうが早いことがあります。
セットから選ぶ
キットをすべて見る →製造・品質 のために作った文書3 件
その業種の決まりや現場の言い方に合わせてあります
QC工程表（Excel・工程能力シートつき）
受入から出荷までの工程ごとに、管理項目・規格・管理方法・検査方法・頻度・記録様式・異常時の処置を一覧化します。ISO 9001 は QC工程表の様式を規定していません（記載項目に規定があるのは IATF 16949 のコントロールプランのほうです）。特別特性の識別欄と工程能力シートつき。作業標準書・検査成績書と工程番号で連携します。
作業標準書
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日前に切れていて行ごと赤くなります——判定は「合格」と出るのに、です。★特採（特別採用）には承認者と承認日を必ず書かせます。空欄は赤。口頭の特採は記録に残らず、「前も通ったから」で次のロットにも引き継がれます。計量値と合否でシートを分けてあるので、どちらの列も空にならずに読めます。
どの業種でも使う文書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項目が完了する形にしました。完了率は数式で出るので「だいたい終わった」で引き渡せません。文書だけでなくアカウント・鍵・媒体・機器・契約書を数えて渡す資産シートと、引継時点の未解決事項を期限と責任者つきで残す残課題シートつき。