プロセス文書化テンプレート:守られるプロセス文書の作り方(2026年版)

プロセス文書化とは、ある仕事が組織の中をどう流れるかを、始まりのイベントから終わりの成果まで文章で記述することです。段階を順に並べ、それぞれを担う役割、役割から役割へ渡るもの、各段階が残すもの、通常の経路が止まったときに起きることを書きます。プロセス文書化テンプレートは、その文章を流し込む決まった骨格です。10番目のプロセスも1番目と同じ読み心地になり、1つ読んだ人はどのプロセスでも迷わず読み進められます。

ほとんどのプロセスは、すでにどこかに文書化されています。2年前のワークショップで描いた図、誰も開かないwikiのページ、最初から担当してきた1人の頭の中、といった具合です。問題は文書が存在しないことではなく、守られていないことです。その理由は、どの組織でも同じ3つに集約されます。このガイドでは、まず基本を扱います。プロセス文書とは何で何でないのか、標準フォーマット、コピーして使えるテンプレート、実例です。続いて3つの理由とそれぞれの対処、文書とそのウォークスルーをチームがすでに使っているツールのどこに置くか、別の言語で読む同僚が何を得られるかを説明します。プロセス文書の真価が問われるのは、新しい営業担当、新しい看護師、新しい販売代理店の事務担当が、次の人に何かを引き継がなければならないのに、それが誰か分からない朝だからです。

プロセス文書とは何か、何でないか

プロセスのレベルで仕事のやり方を記述する文書は3種類あります。互いに、またその下にある手順書と混同されがちです。

マップは絵であり、プロセス文書は絵を使えるものにする文章であり、SOP は各ボックスの下にある詳細です。この違いが長さを決めます。各ステップのクリック操作まで説明するプロセス文書は誰も読まないマニュアルになり、文章のないプロセスマップは人によって解釈が分かれる絵になります。SOP とそのテンプレート、レビューサイクルについては SOPテンプレート と SOPの書き方 で扱っています。このガイドはその一段上、つまり SOP がどこに必要で、誰が誰に何を引き継ぐかを定めるレベルを扱います。

プロセス文書は、仕事が普段どう行われているかの描写でもありません。オーナー、バージョン、レビュー日を備えた「合意された進め方」です。だから、誰も守っていない段階は、文面に残しておくものではなく、変更するか、チームと話し合うべきものです。

含めるもの:標準フォーマット

使えるプロセス文書は、ヘッダーと8つのセクションで構成されます。ネット上のテンプレートの多くは、目的、手順、図だけで終わっています。だから多くのプロセス文書は、一度読まれて、それきりになります。

ヘッダー — 文書の識別情報で、1行に5項目です。引用できる ID(「PR-HR-02」)、バージョン(「v1.3」)、オーナー、発効日、次回レビュー日。オーナーはプロセス全体に責任を持つ名前の挙がった1人で、部署ではありません。レビュー日のないプロセスは、何か問題が起きたときにレビューされます。

1. 目的と成果。 1〜2文で、このプロセスが誰に何を届けるか、良い状態とはどういうものかを書きます。数字があれば添えます。「新入社員が初日にアカウント、機器、計画、担当バディを手にし、30日目までに30日レビューを終えている。」
2. きっかけと終了状態。 プロセスを始めるイベントと、終わらせる成果です。「署名済みの契約書が人事フォルダに届いたときに始まり、30日レビューが記録されたときに終わる。」この2文の間にあるものがプロセスで、その外にあるものは別の文書です。明確な終わりがないなら、それは2つのプロセスです。
3. 適用範囲。 このプロセスが適用される場合とされない場合を、隣接するプロセスをIDで示して書きます。「当社と契約を結ぶ従業員(国は問わない)。対象外:業務委託者(PR-HR-04)、社内異動(PR-HR-06)。」
4. 役割。 各段階に登場する役割と、それが担うものです。人事異動で文書が無効にならないよう、名前ではなく役割で書きます。そのうち1つがプロセスオーナーで、誰の担当にもなっていない引き継ぎを含め、フロー全体に責任を持ちます。
5. 段階と引き継ぎ。 文書の核心です。段階を順に並べ、それぞれに、担う役割、届くもの(入力)、出ていくものとその記録先(出力)、渡し先、期限を書きます。引き継ぎは「引き渡し先:IT、5日前まで」のように明示します。プロセスが失敗するのは引き継ぎのところで、双方が相手の担当だと思い込むからです。
6. 例外とエスカレーション。 通常の経路から外れる分岐です。許可が遅れたとき、与信審査に通らなかったとき、オーナーが不在のときに何が起きるかを書きます。各例外には判断する役割または人を明記し、「誰かに聞く」とは書きません。最後の1行で、漏れた分を拾います。「ここに記載のないもの:プロセスオーナーが判断し、次回レビューで取り上げる。」
7. 指標。 オーナーが見る2〜3個の数字です。きっかけから終了状態までのサイクルタイム、月ごとの件数、例外に当たった割合などです。ダッシュボードではなく、誰かが不満を言う前にプロセスのずれをオーナーに知らせる数字です。
8. 関連文書と改訂履歴。 各段階の下にある SOP、プロセスが実装するポリシー、マップへのリンク。続いてバージョンごとに1行、日付、変更内容、承認者を書きます。履歴があるから、同じ間違いが新しいバージョン番号で再導入されずに済みます。

含めないものは、各ルールの根拠(ポリシーの役割)、段階のクリック単位の詳細(SOP の役割)、そして人が行動に移せないものです。「円滑なオンボーディングを大切にする」は心情であって、段階ではありません。

守られるプロセス文書の作り方

守られないプロセス文書のほとんどは3つの理由で説明がつきます。それぞれの対処は、後からの強制ではなく、書き方の中にあります。

理由その1:設計されたとおりに書かれていて、実際の運用が書かれていない。 文書は、仕事を管理する人たちがワークショップで書いたものです。実際にやっている人たちは別のバージョンを持っています。脇に置いたスプレッドシートや、第3段階で電話がかかる同僚がいるような版です。対処は、書く前に証拠からマッピングすることです。実際の案件を3つ、きっかけから終了状態まで追いかけ、実際に起きたことを書き出します。メール、メッセージ、フォーム、待ち時間です。プロセスがグループチャットの中にあるなら(販売代理店からの注文が WhatsApp で届く、シフト交代が Telegram グループで決まる、など)、そのチャットが証拠であり、ウォークスルーはその履歴から始まります。「Export chat」で何が得られ、どこまでで止まるかは、WhatsAppチャットのエクスポート方法 にあります。3つの案件が食い違うところが、文書が存在する理由です。食い違いごとに、文面で直す段階なのか、チームと話し合うべきことなのかを決めます。

理由その2:誰も最新版を見つけられない。 文書は40個の他の文書と同じフォルダにあり、コピーが誰かのデスクトップにあり、3つ目の版が wiki にあります。火曜の朝にそれが必要な人は、同僚に聞いてしまいます。対処は、チームがすでに読む場所に、ヘッダーが見える形で公開することです。場所は1つ、最新版を先頭に置き、オーナーの名前とレビュー日を一番上に置きます。「これはまだ正しいか」はヘッダーで分かり、周りに聞いて回る必要がなくなります。また、段階は役割間の引き継ぎとして書かれているので、各人は自分の段階とその前後の2つの段階を1分以内で見つけられます。

理由その3:変更されたのに、段階が変わった人たちに伝わっていない。 レビューで与信審査がピッキングの前に移され、あるいは転居を伴う採用者向けのステップが追加されました。文書は更新されたのに、倉庫と採用マネージャーはそれまでと同じことを続けていました。対処は、プロセスを運用する人たちとウォークスルーを行い、変更は変更した行とともに周知することです。ウォークスルーは会議です。参加者はオーナーと各役割から1人ずつで、全員の画面に最新版を表示し、各段階をその担当者が声に出して読み、各引き継ぎを双方が確認します。ウォークスルーで変わった内容は、履歴に1行を添えた新バージョンになります。変更された3行は、その段階に関わる人たちへ、彼らがすでに読んでいる場所で、その日のうちに届けます。段階ではなくルールを変える決定は、プロセスIDをエントリに入れて 決定ログ にも記録します。

手順をまとめるとこうなります。明確な始まりと終わりのあるプロセスを1つ選びます。実際の案件を3つ追います。引き継ぎを明示しながら、まず段階をテンプレートに下書きします。案件で分かったことから例外を埋めます。各役割1人でウォークスルーします。チームが読む場所に、ヘッダーにオーナーとレビュー日を入れて公開します。レビュー日をカレンダーに入れます。こうしてできた文書が守られるのは、それが正確で、見つけやすく、周知されているからです。テンプレートだけでは、この3つの性質は与えられません。

プロセス文書化テンプレート

[プロセスID] — [プロセス名]
バージョン: [n.n] · オーナー: [氏名、役割] · 発効日: [日付] · 次回レビュー: [日付]

1. 目的と成果
[1〜2文で、このプロセスが誰に何を届けるか、良い状態とはどういうものか。数字があれば添える。]

2. きっかけと終了状態
開始: [イベント] · 終了: [新たに存在している成果]

3. 適用範囲
対象: [案件、拠点、顧客、国] · 対象外: [別のプロセスが扱うもの、そのID付き]

4. 役割
プロセスオーナー: [フロー全体に責任を持つ1人]
[役割] — [このプロセスで担うもの]
[役割] — [このプロセスで担うもの]

5. 段階と引き継ぎ
5.1 [段階] — [役割] — 入力: [届くもの] — 出力: [出ていくもの、記録先] — 引き渡し先: [次の役割] — 期限: [時間的な期限]
5.2 [段階] — [役割] — 入力: … — 出力: … — 引き渡し先: … — 期限: …
5.3 [段階] — [役割] — 入力: … — 出力: … — 引き渡し先: … — 期限: …

6. 例外とエスカレーション
[条件]の場合: [何が起きるか、誰が判断するか]
[条件]の場合: [何が起きるか、誰が判断するか]
ここに記載のないもの: [役割]が判断し、次回レビューで取り上げる。

7. 指標
[オーナーが見る2〜3個の数字(サイクルタイム、月ごとの件数、例外に当たった割合など)と、それをどこで確認するか。]

8. 関連文書と改訂履歴
SOP: [ID、必要な段階ごとに1つ] · 実装するポリシー: [ポリシー] · マップ: [図へのリンク]
v[n.n] — [日付] — [変更内容] — 承認者 [氏名]
v[n.n] — [日付] — [変更内容] — 承認者 [氏名]

このテンプレートは太字のラベルを使ったプレーンテキストなので、Word ファイル、Google ドキュメント、wiki ページ、Slack の canvas、チャットのメモに、書式を整え直さずに貼り付けられます。空欄になりやすいのは2か所、引き継ぎ(「誰に、いつまでに」)とレビュー日です。この2つが、1年後もプロセスが文書どおりに運用されているかを左右します。

実例:新入社員のオンボーディング(契約署名から30日目まで)

従業員60人の会社で、3か国に採用者がいます。プロセスは4つの役割にまたがり、30日レビューが記録された時点で終わります。

PR-HR-02 — 新入社員のオンボーディング
バージョン: 1.3 · オーナー: オペレーション責任者 Inés M. · 発効日: 2026年10月1日 · 次回レビュー: 2027年4月1日

1. 目的と成果 — 新入社員が、どの国で働き始めても、初日に利用可能なアカウント、機器、最初の1か月の計画、担当バディを手にし、30日目までに30日レビューが記録されている。
2. きっかけと終了状態 — 開始: 署名済みの契約書が人事フォルダに届いたとき。終了: 30日レビューが本人のファイルに記録されたとき。
3. 適用範囲 — 当社と契約を結ぶ従業員(国、オフィス勤務かリモートかは問わない)。対象外: 業務委託者(PR-HR-04)、社内異動(PR-HR-06)。
4. 役割 — プロセスオーナー: オペレーション責任者。人事: ファイル、書類、給与、ウェルカムパック。IT: アカウント、機器、アクセス権。採用マネージャー: 計画、バディ、チェックイン。経理: 給与設定。

5. 段階と引き継ぎ
5.1 ファイルを開く — 人事 — 入力: 署名済みの契約書 — 出力: 開始日、国、マネージャー、言語を記したオンボーディング記録。本人の言語で送ったウェルカムパック — 引き渡し先: ITと採用マネージャー — 期限: 署名から2営業日以内
5.2 アカウントと機器 — IT — 入力: 記録 — 出力: 作成済みのアカウント、本人の住所に発送したノートPC、役割プロファイルに沿ったアクセス権。記録内の確認 — 引き渡し先: 人事 — 期限: 開始日の5営業日前
5.3 書類と給与 — 人事、続いて経理 — 入力: 記録、本人の書類(国が求める場合は許可証または登録) — 出力: 給与システムへの登録、ファイル内の書類 — 引き渡し先: 採用マネージャー — 期限: 開始日
5.4 最初の1か月の計画 — 採用マネージャー — 入力: 記録 — 出力: ファイル内の30日計画、担当バディ、本人のカレンダーに入れた初週の予定、チームとのウェルカムコールの予約 — 引き渡し先: 本人(初日) — 期限: 開始日の前日
5.5 初日 — 採用マネージャーとバディ — 入力: 計画 — 出力: 実施したウェルカムコール、確認した計画、チームのチャンネルに記録した本人の未解決の質問 — 引き渡し先: 本人 — 期限: 初日の終了時
5.6 チェックイン — 採用マネージャー — 入力: 計画、記録した質問 — 出力: 7日目と30日目のチェックイン、ファイルに記録した30日レビュー — 引き渡し先: 人事(記録を閉じるため) — 期限: 30日目

6. 例外 — 開始日までに許可証または登録が下りない場合: 本人は、許可なしで可とマネージャーが指定した業務から始める。人事がフォローアップを担当し、日付を記録に残す。2日前までにノートPCが届かない場合: ITがオフィスの在庫から代替機を発送し、オペレーション責任者に当日中に伝える。当社がこれまで採用したことのない国での採用の場合: 段階5.3を一時停止し、オペレーション責任者が3営業日以内に employer-of-record の方式を決める(PR-HR-05)。
7. 指標 — 署名からアカウント準備完了までの営業日数(目標 ≤ 7)、30日目までに30日レビューが記録された採用者の割合(目標 100 %)、第1週に記録された質問(四半期レビューで読み、どの段階が質問を生み続けているかを見る)。
8. 関連 — SOP-IT-03「新規アカウントとアクセス」、SOP-HR-08「国別の給与設定」、オンボーディングポリシー §2、マップ:人事フォルダ内のスイムレーン図。
v1.3 — 2026年10月1日 — ウェルカムパックを本人の言語で送付するよう変更、7日目のチェックインを追加 — 承認者 Inés M.
v1.2 — 2026年6月3日 — 2件の納品遅延を受け、ノートPCの発送を開始の5日前に前倒し — 承認者 Inés M.

この例が何をしているかに注目してください。どの段階にも、役割、届くもの、出ていくものとその記録先、次の受け手、期限が書かれています。だから、行われなかった引き継ぎは、初日の驚きではなく、記録上の空欄として見えます。各例外には、誰が判断するかが書かれています。指標はダッシュボードではなく3つの数字です。そして履歴が、段階が今の形になっている理由を説明します。段階5.2にこの期限があるのはノートPC2台が遅れたからで、7日目のチェックインがあるのは、30日レビューで、第1週のうちに答えておくべき質問が見つかり続けたからです。

もう1つ、短い例として、販売代理店を持つ輸出企業の販売プロセスの形を示します。

PR-SA-01 — 受注から納品まで · オーナー: 輸出マネージャー · 開始: 販売代理店から注文が届いたとき · 終了: 納品が確認され、請求書が送られたとき
1. 注文の確認 — アカウント担当 — 入力:注文 — 出力:システム上で確定した注文、または販売代理店への問い合わせ — 引き渡し先:経理 — 期限:1営業日
2. 与信審査 — 経理 — 入力:確定した注文 — 出力:承認済み、または理由付きの保留 — 引き渡し先:倉庫 — 期限:1営業日
3. ピッキングと梱包 — 倉庫 — 入力:承認済みの注文 — 出力:梱包リスト付きの梱包済み荷物 — 引き渡し先:物流 — 期限:3営業日
4. 書類と出荷 — 物流 — 入力:梱包済みの注文 — 出力:手配済みの出荷、仕向地の書類の添付、システム上の追跡情報 — 引き渡し先:経理とアカウント担当 — 期限:1営業日
5. 請求と確認 — 経理、続いてアカウント担当 — 入力:出荷 — 出力:送付済みの請求書、販売代理店との納品確認とその記録 — 与信が保留された場合: アカウント担当が1営業日以内に販売代理店へ電話する。輸出マネージャーが、承認するか前払いにするかを判断する。

12行で、販売代理店の新しい事務担当も倉庫の新しい担当者も、自分が誰を待っているのかが分かります。

すでに使っているツールの中で、プロセス文書とそのウォークスルーはどこにあるか

文書そのものは、チームの文書がある場所に置かれます。共有ライブラリの Word ファイル、Google ドキュメント、wiki のページ、チャンネルの canvas などです。ウォークスルーは会議で、各プラットフォームにはウォークスルーが残したものを置く場所があります。ただし、止まる地点はそれぞれ違います。以下は、ベンダー自身のページに記載された仕様のみを、各ページを確認した月とともに示したものです。

どこでも同じことが2つあります。1つ目は、プロセス文書は書かれた1つの言語のファイルで、別の言語を読む同僚は、それか、誰かが作ったコピーを読むことです。2つ目は、ウォークスルーで変わった内容は、あとで人が同じ言語で入力して初めて文書に届くことです。これらのスイートが提供する翻訳は通話のためのもので、文書のためのものではありません。Microsoft は、主催者が Teams Premium または Microsoft 365 Copilot のライセンスを持つ場合に、Teams 会議でライブ翻訳キャプションが使えると記載しています。Google は、対象の Workspace プランで Meet の翻訳キャプションが使えると記載しています(どちらも2026年8月確認)。それぞれがどこまでカバーし、どこで止まるかは、Microsoft Teams のライブ翻訳 と Google Meet のライブ翻訳 にあります。新しい事務担当が火曜日に開くプロセスと、それを変えたウォークスルーは、これらのキャプションとは別のものであり、入力された言語のまま読まれます。

プロセス、ウォークスルー、履歴を、すべてのメンバーが読めるままにする方法

InterMIND は、チームの仕事がチャンネルの中にあるコミュニケーションの空間です。だから完成したプロセス文書には、わかりやすい置き場所があります。そのプロセスを運用するチームのチャンネルです。人事、IT、経理、採用マネージャーなど、それぞれが1つの段階を持つ人たちが集まる1つのチャンネルです。見出しと番号付きリストのあるリッチテキストのメッセージとしてノートで投稿すれば(あとから専用のメニューで編集できます)、各メンバーが自分の言語で読め、原文はトグル1つで見られます。ピン留めすれば、新しい同僚が最初に見つけるのは最新版になります。編集履歴をオンにしておけば、変更された段階の以前の文言が、現在のテキストの上に、タイムスタンプ付きの単語単位の差分として表示されます。PDF や Word 文書としてファイルをアップロードした場合は、全プランで、読み手の言語による AI 要約が付き、各ポイントは出典の段落にリンクされます。そのため、誰かが書く前から1ページの読み物が存在します。有料プランでは、ファイル自体が読み手の言語に翻訳されて開きます(文書は30言語)。マスターコピーを文書ツールに置いたままにする場合は、その更新をメールでチャンネルに届けられます。チャンネルのホストがチャンネル専用のアドレスを発行し、そこに送ったメッセージは、送信者名が付き添付ファイルも保たれた通常のメッセージとして表示されます。

ウォークスルーはそのチャンネルから始まります。通話中は、Share to conference で最新版を全員の画面のビデオタイルの隣に表示します。ノート、あるいはチャットでリンクした Google Docs や OneDrive の文書を共有でき、各参加者は独立してスクロールし、自分の言語で読みます。共有されたノートは共有した人がライブで編集するので、部屋の全員が見守る中、変更された引き継ぎがその場で形になります。通話が終わると、recap が会議そのものから作られます。サマリー、合意・未決・争点とマークされたポイント、担当者付きの action items で、各行にタイムスタンプが残ります。セッション中に共有された文書の要約も、話された内容と並んで加わります。recap はメール、チャンネルのメッセージ、カレンダーイベントのリンクとして届き、サインインしているメンバー全員が自分の言語で読みます。記録は読み手ごとに翻訳されるもので、その場で使われた言語で1回だけ書かれるものではありません。どのメンバーも編集でき、編集のたびに作成者と改訂履歴が残り、チャンネルには過去のすべてのセッションの recap が残ります。そのため、v1.3 を生んだウォークスルーは、v1.3 のノートからクリック1回の距離にあります。メンバー個人のアシスタント(Claude、ChatGPT、Copilot、Gemini など)は、MCP コネクタ経由で、recap、文字起こし、チャット、共有ファイルのテキストを1つの質問で検索し、文書そのものも読みます。たとえば「なぜノートPCは開始日の5日前に発送されるのか」という質問です。これは AI 機能をオンにしている組織で動作します。上の表と並べると、違いは事実を述べるだけで明らかです。これらのスイートが提供するキャプションは、通話の進行中にそれを翻訳します。ここでは、プロセス、そのウォークスルー、その履歴が1つの記録になっていて、各メンバーが自分の言語で読みます。

プロセスに関わる人が、常に従業員とは限りません。販売代理店の受注担当、他国の給与代行会社、1つの段階を担う業務委託者などです。チャンネルの外部メンバーはメールで無料アカウントに参加し、プロセスとその履歴を他のメンバーと同じように読めます。アカウントを持たない人は1回の会議のゲストです。リンクから、スマートフォンからでも、無料でウォークスルーに参加し、自分の言語でライブで聞けますが、その後に記録は残りません。ホストが空間を提供し、有料プランでは、直近28日間にアクティブだったメンバー、つまり会議に参加した、チャットに書き込んだ、アシスタントに質問した人の分だけ支払います。静かになったメンバーは、無料でアクセスを保ちます。

• 完全な recap を開く — あなたの recap を書くのと同じコードで描画された、実際の記録です。
• ライブデモを試す — サインアップ不要。話すと、部屋の声が聞き手ごとに翻訳されて聞こえます。

プロセス文書化という技術は、どのツールでも変わりません。実際の案件を3つ追い、第三者が確認できる引き継ぎとして段階を書き、各役割1人でウォークスルーを行う作業は、誰かがやらなければなりません。残らなくていいのは、その後の第2の仕事です。つまり、すべてのバージョンの翻訳コピーを手作業で保管し、ウォークスルーで変わった内容を、他の言語で読む人たちのために1つの言語で打ち直す作業です。

FAQ

プロセス文書化とは何ですか?

プロセス文書化とは、ある仕事が組織の中をどう流れるかを、始まりのイベントから終わりの成果まで文章で記述することです。段階を順に並べ、それぞれを担う役割、役割から役割へ渡るもの、各段階が残すもの、通常の経路を外れた例外とその判断者、オーナーが見る少数の数字を書きます。図であるプロセスマップと、各段階のやり方を手順ごとに記述する SOP の中間に位置します。

プロセス文書には何を含めるべきですか?

ID、バージョン、オーナー、発効日、次回レビュー日を記したヘッダー。目的と成果。きっかけと終了状態。プロセスが対象としないものを含む適用範囲。名前の挙がった1人のプロセスオーナーを含む役割。順序立てた段階(それぞれに、役割、入力、出力とその記録先、次の役割、期限)。例外ごとに判断者を決めた例外とエスカレーション。2〜3個の指標。そして、関連する SOP、実装するポリシー、改訂履歴です。

プロセスをステップごとに文書化するには、どうすればよいですか?

明確なきっかけと終了状態のあるプロセスを1つ選びます。実際の案件を3つ、最初から最後まで追い、分岐も含めて実際に起きたことを書き出します。まず段階を、テンプレートの中で、それぞれを引き継ぎ(役割、入力、出力、次の役割、期限)として下書きします。案件で明らかになった例外を、それぞれ誰が判断するかとともに加えます。目的、適用範囲、役割、ヘッダーを埋めます。各役割1人で文書をウォークスルーし、各自が自分の段階を声に出して読み、引き継ぎを確認します。チームがすでに読む場所に、オーナーとレビュー日が見える形で公開し、レビュー日をカレンダーに入れます。

プロセス文書化と SOP の違いは何ですか?

プロセス文書化は、役割やチームをまたいで仕事がどう流れるか(段階、引き継ぎ、各段階が残すもの)を、プロセスごとに1ページのレベルで記述します。SOP は、その段階の1つを1つの役割がどう行うかを、各ステップが生む結果に至るまで手順ごとに記述します。プロセス文書は SOP がどこに必要で、誰が誰に何を引き継ぐかを教えてくれます。1つの SOP は、火曜の朝に1人が何をすればよいかを教えてくれます。チーム横断のプロセス全体について SOP を書くと、誰も開かないマニュアルになります。SOP の詳細度でプロセス文書を書いても、同じ結果になります。

プロセス文書化の例には何がありますか?

明確な始まりと終わりがあり、役割をまたぐ繰り返しのフローなら何でも該当します。契約署名から30日目までの新入社員のオンボーディング、販売代理店からの注文から納品確認と請求まで、顧客の苦情の受付からクローズまで、紹介から初回予約までの患者、承認された企画書からカタログ掲載までの新商品、タイムシートから請求書送付までの月次決算などです。このガイドの実例は、新入社員のオンボーディングで、4つの役割にまたがる6つの段階、3つの例外、3バージョンの履歴を持ち、その後に短い受注から納品までの例が続きます。

Word や Google ドキュメントで使えるプロセス文書化テンプレートはありますか?

このガイドのテンプレートは太字のラベルを使ったプレーンテキストなので、Word 文書、Google ドキュメント、wiki ページ、Slack の canvas、チャットのメモに、書式を整え直さずに貼り付けられます。ファイル形式よりもフォーマットが重要です。文書を保管するものには、オーナーとレビュー日を含むヘッダー、きっかけと終了状態、期限付きで役割間の引き継ぎとして書かれた段階、例外ごとに決まった判断者、改訂履歴が必要です。そして、プロセスを運用する人たちがすでに読んでいる場所にある必要があります。

プロセス文書は誰が書くべきですか?

プロセスオーナーです。フロー全体に責任を持つ名前の挙がった1人で、通常は、そのプロセスが主に通る領域のマネージャーです。これに、段階を担う各役割から1人ずつが加わります。ペンとレビュー日を持つのはオーナーで、段階を実際に行う人たちは共著者です。彼らについて書いた文書は、設計どおりのプロセスを描き、実際のプロセスは彼らの頭の中にあるままになるからです。新人はテスターです。自分の段階とその前後の2つの段階を1分以内で見つけられれば、その文書は機能しています。

プロセス文書はどのくらいの頻度で更新すべきですか?

ヘッダーに書かれたレビュー日に更新します。6か月または12か月ごとが一般的で、規制のあるプロセスならもっと短くします。次の4つのうちどれかが起きたときは、それより早く更新します。引き継ぎが失敗して誰も担当していなかった、段階が依存するツールやフォームが変わった、プロセスが実装するルールが変わった、指標が動いた、のいずれかです。更新ごとに、何が変わり誰が承認したかを1行で履歴に書いた新バージョンを作ります。古いバージョンは残し、段階が変わった人たちには、変更した行とともに、その日のうちに伝えます。

出典:Microsoft — Take meeting notes in Microsoft Teams、Microsoft — Use live captions in Microsoft Teams meetings、Zoom — Using Meeting Summary with AI Companion、Google — Calendar & Meet settings for "Take notes for me"、Google Meet — "Take notes for me" in Google Meet、Google Meet — Use translated captions、Slack — Meeting agenda template (canvas)。Microsoft、Google、Slack の会議ノートとテンプレートのページは2026年10月に確認し、Zoom の会議サマリーのページと、Teams および Meet のキャプションのページは2026年8月に確認しました。ベンダーはプラン、機能、対応言語を随時変更します。最新の状況は各社のページでご確認ください。