プロセスドキュメントは、属人的な知識を組織の知識へと変えるものです。Trupeerなら、無料のプロセスドキュメントテンプレートから始めて、ブランドガイドラインでカスタマイズし、さらに、チームが実際に使う明確な動画ウォークスルーへと書面のプロセスドキュメントを変換することで、作成にかかる時間を何時間も節約できます。

プロセスドキュメントテンプレートとは？

プロセスドキュメントとは、実際に業務がどのように進むかを記録した書面です。手順、担当者、どの順番で行うか、どの入力が必要か、そして完成した結果がどのようなものになるかを示します。

プロセスドキュメントテンプレートは、それを記録するための再利用可能な構造です。ヘッダー項目、手順の形式、そして、初めてその業務を行う人にもドキュメントとして使えるようにする周辺情報までを含みます。

見つかるどのテンプレートも、だいたい同じものを提供します。目的、スコープ、担当者付きの番号付き手順のリスト、そしてどこかにフローチャートを置くためのスペースです。その構造自体は問題ありません。問題は、それが作り出すのが、すべてが計画どおりに進むプロセスのバージョンであり、誰も助けを必要としていないバージョンだということです。

「ハッピーパス」が誰にも必要とされなかった理由

誰かにプロセスをドキュメント化してもらうと、彼らは「どのように機能するか」を説明します。それは質問への自然な答えですが、内容としては不適切です。

ドキュメントを読む人は、通常1週間以内に標準ケースをこなせるようになります。誰かがそれを2回実演するのを見て、理解してしまえば問題ありません。できないのは、発注書番号が欠けている順序、契約と一致しない価格の顧客、廃止された部品、クレジット限度額を超えてしまったばかりの口座などに対応することです。

こうした状況は珍しくありません。多くの業務プロセスでは、件数としては少数でも、時間の大半はそれらが占めます。なぜなら、クリーンなケースよりもそれぞれが数倍時間がかかるからです。

また、理解しておく価値のある理由により、例外の内容は書くのが最も難しいものでもあります。プロセスをドキュメント化する人は、例外を何百回も扱ってきており、ずっと前から「判断」として感じなくなっています。プロセスはどう進むのかと聞かれれば、正直かつ正確にハッピーパスを説明します。なぜなら、その質問がそれを求めているからです。

結果として、ドキュメント化が不要だった部分がカバーされ、演習の本当の理由だった部分が省かれてしまいます。

Trupeerでこのテンプレートをカスタマイズする方法

ステップ1：テンプレートセクションを開く

メインナビゲーションからテンプレートセクションへ移動します。

ステップ2：テンプレートを選択して開く

作業したいテンプレートをクリックして開きます。

ステップ3：テンプレート表示を展開する

必要に応じて、テンプレート表示を展開し、レイアウトと詳細をはっきり確認します。

ステップ4：テンプレートを編集する

編集をクリックして、選択したテンプレートの変更を開始します。

エディター内で、次のことができます：

• 新しいセクションを追加

• 書式ルールを定義または更新

• ロゴを追加し、その位置および関連設定を調整

ステップ5：カスタマイズしたテンプレートを保存する

必要な変更をすべて行ったら、保存をクリックして更新されたテンプレートを自分のものとして保存します。

ステップ6：プレビューしてテンプレートを微調整する

カスタマイズしたテンプレートがどのように表示されるかを確認したいときは、プレビューを開きます。

プレビュー画面から、必要に応じて直接調整を続けることができ、テンプレートが希望どおりに表示されることを確認できます。

プロセスドキュメントテンプレートがあれば、次のことができます：

• ドキュメント作成の時間を節約：あらゆる業務プロセスに対応する構造を備えた空白ページをスキップできます。

• 属人的な知識を記録：実際に業務がどのように進むかをドキュメント化すれば、人が入れ替わっても知識を残せます。

• ブランドに沿った見せ方：Trupeerのブランドキットを使ってロゴ、フォント、カラーを適用。部門横断のプロセスドキュメントに最適です。

• プロセスドキュメントからSOPを作成：各ステップを詳細な作業手順へ変換するには、AI SOP作成者をご利用ください。

• 改善点を特定：プロセスをドキュメント化することは改善の第一歩です。テンプレートにより非効率が見える化されます。

• グローバルチームに展開：1クリックでプロセスドキュメントを65以上の言語に翻訳できます。

書く前に例外率を数える方法

何かを書く前に、実際の業務のうち標準パスに従う割合がどれくらいかを把握します。これは午後で終わり、書く内容が変わります。

プロセスの直近の事例をサンプルとして取り出します。30件でも傾向を示すには十分で、データを集めやすいなら200件のほうがより良いです。選定サンプルではなく連続サンプルにしてください。選定サンプルは現実よりも常にきれいだからです。

それぞれについて、1つだけ質問します。これはそのまま通ったのか、それとも何かを決める必要があったのか、追跡したのか、修正したのか、エスカレーションしたのか。

次に、それらのうち通らなかったものをグループに分けて数えます。

すると2つの数字が出ます。1つはクリーンに進んだ割合で、ハッピーパスのドキュメントがカバーできる作業量を示します。もう1つは例外タイプの順位付きリストで、これが書く順番になります。

ほとんどのチームは、どちらにも驚きます。誰もが「簡単」と説明するプロセスでも、実際には3分の1か半分の事例でしかクリーンに進みません。そして上位3つの例外タイプが、残りの大半を占めることが多いのです。この3つは、14個の標準ステップすべてを合わせたよりも、書く際により注意を払う価値があります。

すべてのステップに必要な「そして、もしそうでなければ」行

この規律の最も軽いバージョンは、ほとんどコストがかからず、すでにあるドキュメントにも適用できます。

各ステップを取り上げます。各ステップには、満たされるべき条件が暗に含まれています。項目が入力されている、価格が一致している、在庫が存在する、承認が整っている、といった具合です。そして各ステップの下に、「そして、もしそうでなければ」で始まる1行を書きます。

例：発注書番号が存在し、顧客の形式になっていることを確認します。そして、もしそうでなければ：テンプレートを使ってメールで依頼者に依頼し、注文は保留キューに入れておき、配分には進まないでください。

この1行には3つの役割があります。まず、例外を表面化させます。例外は、多くの場合、誰かが初めて書き留める瞬間になります。次に、何が起きるべきかを判断させますが、実際には合意されていないことがよくあります。そして最後に、読者に「代わりに何をすべきか」を伝え、何かを思いついて対応したり、誰かを中断させたりすることを防ぎます。

「そして、もしそうでなければ」の回答が2行程度を超えて長くなる場合は、それは独立した例外セクションに入れ、独自の判断ルールを持たせ、ステップ側はそこを指すだけにします。回答が本当に「上長に確認する」であるなら、明確にそう書き、役割名も挙げてください。暗黙のエスカレーションが、排除しようとしていた中断を生み出すからです。

無料のプロセスドキュメントテンプレート：コピーするための構造

ここからコピーしてください。

ヘッダー。プロセス名：部署ではなく成果として記述。オーナー：役割として記述。最終確認日：誰かがこのドキュメントに対して最後にプロセスを実行した日。バージョン：推定される頻度とボリューム。

このプロセスが生み出すもの。完成した結果を、読者がそれを手にしたかどうか判断できるように記述します。

トリガーと境界。開始するもの、完了するもの、そしてこのドキュメントがカバーしない範囲で、そのすぐ両側にあるものを記述します。境界は、重複した矛盾するドキュメントが生まれる場所です。

関係者。名前ではなく役割で記述し、それぞれが何に責任を持つかを示します。

入力とシステム。開始する前に存在している必要があるもの、必要なシステムとアクセスを記述します。

ステップ。番号付きで、1アクションにつき1行。期待される結果と、各ステップの下にそして、もしそうでなければ行を1行ずつ記載します。

例外。サンプルからの順位付きリスト。各例外について、条件、判断ルール、承認できる人、次に何が起きるかを記載します。このセクションは通常、ステップより長くなりますが、それで正しいです。

このプロセスがカバーしないもの。明示的に記名し、それらのケースがどこへ行くのかを示します。

指標。通常どれくらい時間がかかるか、ボリューム、そしてクリーンに進む割合を記述します。最後の数値は追跡する価値があります。プロセスが変わると動くからです。

ここまでコピーしてください。従来のテンプレートに追加するべき2つは、「そして、もしそうでなければ」行と例外セクションです。それ以外は、どんなまともな構造にも必ず見つかるはずです。

プロセスドキュメントテンプレートに含めるべきもの

上記のヘッダー、境界、役割、ステップ、例外です。ドキュメントを削ろうとする人に対して守る価値のある項目は3つあります。

最終確認日（最終更新日ではない）。文言を編集することは、プロセスが今も同じやり方で動いていると確認することとは同じではありません。「誰かが実際に起きているのを見た」ことを意味する日付は、「誰かが誤字を直した」ことを意味する日付よりも価値があります。

境界。重複したドキュメントの多くは、2つのチームが同じプロセスの重なり合う範囲を、それぞれどこまでが自分たちの範囲か合意せずにドキュメント化してしまうことで生まれます。

クリーン実行率。ドキュメントが実際の業務を説明しているのか、それとも理想化されたものを説明しているのかを判断できる唯一の指標です。

3つは省いてもよいものです。文書よりも早く日付が古くなるため、変更されるインターフェースのスクリーンショット。プロセスが存在する理由の説明（これはポリシーに属します）。そして、ITドキュメントにあるシステムの詳細（言い直すのではなく参照すべきもの）です。

31%の注文をカバーした配布担当者

Pellowe Trading（企業間取引のディストリビューター）は、2人の経験豊富なコーディネーターが互いに1か月以内に退職したタイミングで、注文処理をドキュメント化しました。

ドキュメントは、どの通常の基準でも徹底的でした。14ステップ、フローチャート、スクリーンショット、22ページ。両方のコーディネーターが退職する前に承認済みでした。

代わりの2名が着任しました。6週間のうちに、注文の滞留（バックログ）は約40件から約310件へ増え、財務の締め処理は9日遅れました。

調査では、連続する200件の注文を調べ、記載された14ステップを逸脱せずに進んだ件数を確認しました。

63件でした。残りの137件は、少なくとも1つの例外に当たっていました。

順位付きで、その例外は次のとおりでした。顧客の発注書番号が欠けている、または形式が間違っている：41回。注文書の価格が契約の価格表と一致しない：29回。代替が必要な廃止部品：22回。クレジット限度額の超過：18回。口座に登録されていない配送先住所：14回。分割配送の依頼：13回。

この6つのうち1つも、22ページのどこにも出てきませんでした。

退職した2人のコーディネーターは、これらを何年も週に数回ずつ扱っていました。引き継ぎの際にどれも持ち出されず、何かを隠していたわけでもありません。注文プロセスはどう動くのかと聞かれ、彼らはその質問に正確に答えていました。

バックログの解消には11週間と、つなぎの採用が必要でした。2人の顧客が口座を移しました。財務チームは、遅延請求による保有コストと失われたマージンを、概算で約64,000ポンドと見積もりました。

書き直しには4日かかりました。同じ14ステップで、各ステップに「そして、もしそうでなければ」行を追加し、さらに6つの指定されたケースをカバーする独立した例外セクションも用意しました。実際の判断ルールも明記しました。価格の上書きを承認できる人と上限の金額、代替ルールとそれを承認する人、クレジット限度額のエスカレーションの手順です。

新しいコーディネーター2名と、財務の担当者1名が作成しました。誰かの記憶ではなく、200件の注文サンプルをもとに作業しました。この細部が重要だったのは、記憶だけで書けたはずの人たちはすでにいなくなっており、サンプルのほうが彼らよりも良い情報源になっていることが分かったからです。

6か月後、注文あたりの例外対応の中央値は22分から7分へと減少し、バックログは50件未満で安定しました。さらに200件の新しいサンプルでは、誰かにエスカレーションせずにドキュメントだけで84%が解決できることが示されました。

プロセスドキュメントを作成する方法：ステップバイステップ

まずサンプルを取り、例外を数えます。その他の作業は、実際に何をドキュメント化しているのかが分かれば、ずっと簡単になります。

可能なら、別の人による実演を2回観察します。同じドキュメント化されたプロセスでも、2人が異なるやり方で実行すること自体が発見になります。

ステップの前に、境界と成果（アウトカム）を書きます。これらがドキュメントの肥大化を止めるからです。

ステップは「プロセスが本来どうあるべきか」ではなく、観察した内容から書きます。違いがある場合は、なだめて整えるのではなく、その違いを記録してください。違いは、採用する価値のある改善であるか、修正すべき問題であることが多いからです。

各ステップに「そして、もしそうでなければ」行を追加します。ステップを書くのにかかった時間より長くなることを想定してください。

例外セクションは、順位付きリストから上から順に書きます。そして、ボリュームの大半を占めるものをカバーしたところで止めます。完璧な網羅が目標ではなく、達成もできません。

次に、実際の事例をドキュメントから実行する人（その業務をやったことがない人）に、あなたが見守りながら実行してもらい、何も言わないでください。彼らが尋ねるすべての質問は欠陥であり、その質問は例外に集まります。

質の低いプロセスドキュメントがもたらす影響

目に見えるコストはオンボーディング時間で、それが最小のものです。

より大きなコストは静かに発生します。中断です。プロセスを知っている人が、プロセスを聞かれて週の時間を費やす状態ですが、チケットとしては出てこないため見えません。不整合です。同じ入力から2人が異なる結果を出しても、顧客が比較するまで誰も気づきません。キーパーソンリスクです。1人が不在だとプロセスが回らないのに、それが隠れたままになり、不在になって初めて露呈します。

そして意思決定のズレです。ドキュメントに何をすべきか書かれていないと、人はそれぞれ合理的に判断しますが、その判断は時間とともに分岐し、最終的には「ドキュメント化すべき単一のプロセス」が存在しなくなります。

この4つすべてに共通するパターンは、質の低いドキュメントが失敗を生むのではないということです。生むのは、ゆっくりとした劣化で、それが作業量、要員、システムの問題だと見なされます。そのため、当事者が体験しているのに、修正されることはほとんどありません。

良いプロセスドキュメントテンプレートの条件は？

3つありますが、そのどれもレイアウトではありません。

例外を求めることです。手順の表があるだけで他に何もないテンプレートは、毎回ハッピーパスのドキュメントを生み出します。なぜなら、それが招いているからです。

最終更新日ではなく「最終確認日」があることです。これにより、メンテナンスの意味が変わります。

そして境界の記述を強制することです。同じプロセスが、異なる境界を持つ3つのチームによって3回もドキュメント化されないようにするためです。

それ以外では、フォーマットは多くのテンプレート比較が示唆するほど重要ではありません。例外をカバーするシンプルなドキュメントは、例外をカバーしない洗練されたドキュメントに勝ちます。

プロセスドキュメントの形式：テキスト、フローチャート、チェックリスト

3つの形式があり、選択は好みではなく、業務の形に合わせるべきです。

番号付きステップは、開始と完了が明確で分岐が少ない線形プロセスに適しています。ほとんどの管理系および業務系プロセスはここに当てはまり、上記のテンプレートはそれを前提にしています。

フローチャートまたはスイムレーンは、本当に分岐があるプロセス、または複数の役割にまたがり、担当の引き継ぎが発生するプロセスに適しています。スイムレーンは、「この部分の仕事は誰の担当？」という問いが繰り返し出てくるときに特に有効です。詳細を入れる器としては不向きなので、置き換えるのではなくテキスト版と組み合わせてください。

チェックリストは、順序よりも網羅性が重要なプロセスに適しており、メインドキュメントというよりは補助的な成果物として併用すると効果的です。

役立つ目安：プロセスに本物の判断ポイントが3つ以上あるなら、書くだけでなくフローチャートでも描きます。3つ未満なら、フローチャートは飾りで、番号付きリストがドキュメントです。

プロセスドキュメント、SOP、作業手順書：どれですか？

3つの用語は同じ意味として使われることがありますが、その下には実際の違いがあります。

プロセスドキュメントは、業務がどのように流れるか（多くの場合、役割をまたいで）を説明するもので、記述的です。ここではどうやって実施するのかに答えます。

SOPは権威ある、規範的なものです。タスクを行うための承認済みの方法を示し、管理されており、それからの逸脱は逸脱です。当社のSOPテンプレートは構造をカバーしています。

作業手順書は最も粒度が細かく、1つの役割が1つのステーションで行う1つの作業を扱います。規制のある環境や製造現場では、管理されたドキュメントであり、当社の製造作業手順書テンプレートがそれをカバーしています。

実務的なテストは「結果」です。ドキュメントから離れても、単に別のやり方で作業するだけなら、それはプロセスドキュメントです。そこから離れることが不適合（ノンコンフォーマンス）なら、SOPまたは作業手順書であり、プロセスドキュメントにはない版管理、承認、レビューサイクルが必要です。

プロセスが1人の頭の中にあり、その人が離れる状況では、ドキュメント化の取り組みは実質的に引き継ぎです。当社のナレッジトランスファーSOPでは、その適切な進め方をカバーしています。なぜ「誰かに自分の仕事のやり方を聞くこと」がハッピーパスにつながるのかも含めています。

WordやExcelでプロセスドキュメントテンプレートをもらえますか？

ドキュメントはWordまたはGoogle Docsです。各ステップに「そして、もしそうでなければ」行と例外セクションがあり、標準テンプレートでは省略されがちな構造付きの文章として扱われます。セルよりもドキュメントのほうが読みやすいです。

Excelは2つの補助的な成果物に適しています。例外ログ（つまり、1行に1事例を入れ、例外タイプを記録したあなたのサンプル）。これが順位付きリストを生み、後で再実行して何かが変わったかどうかを確認できます。そしてプロセス登録簿（すべてのプロセスを、オーナー、最終確認日、クリーン実行率とともに一覧化したもの）。これにより、それらのライブラリを管理できます。

PowerPointは、プロセスを説明する際にフローチャートまたはスイムレーン表示に向いており、ドキュメントそのものではありません。

PDFは、プロセスが検証された後に発行される版で、ライブのコピーから書き出します。

書かずにプロセスをドキュメント化する方法

例外の内容は、決して書かれない部分であり、その理由は「気が進まない」からではなく「時間」です。知っている人のそばに座って、彼らが何をしているかを記録し、その後、メモを読みやすいものにするために夕方を費やす必要があります。

記録すれば、その多くが不要になります。Trupeer AIは、画面録画を、すでにステップと画面がキャプチャされた書面の手順へ変換します。つまり、知っている人が一度実演するだけで済み、説明する必要がなくなります。

有効なコツは、標準ケースではなく例外を記録することです。次に価格の不一致や発注書の欠落が発生したら、それを扱う人に、その対応を自分で録画してもらいます。2週間で6回の録画があれば、書き留めようとして1年かけてもカバーできない多くの内容をカバーできます。

記録する。ブランド化する。翻訳する。Trupeerする。

出力は、あなたのナレッジベースにあるガイドやドキュメントとして、統一されたブランドで提供されます。SOP作成者は、管理が必要な手順をカバーし、当社のジョブエイドテンプレートは、1つのステップを人が繰り返し間違えるときの短い参照用をカバーします。セットアップ手順はドキュメントテンプレートセットアップガイドにあります。

よくある質問

Wordで無料のプロセスドキュメントテンプレートはありますか？

上記の構造は、そのままWordまたはGoogle Docsに貼り付けられます。「そして、もしそうでなければ」行や、標準テンプレートが省略しがちな例外セクションも含まれます。ゲート付きのダウンロードやフォームはありません。ステップを書く前に例外セクションを追加してください。先にステップを書くと、利用可能な工数を消費しがちだからです。

Excelで無料のプロセスドキュメントテンプレートはありますか？

Excelは、ドキュメント本体ではなく、例外ログとプロセス登録簿に適しています。ログは、サンプルした各事例につき1行で、例外タイプを記録します。これが順位付きリストを作ります。登録簿は、すべてのプロセスをオーナー、最終確認日、クリーン実行率とともに一覧化し、どのドキュメントが古くなっているかを判断するために使います。

PDFで無料のプロセスドキュメントテンプレートはありますか？

ドキュメントが、そこからプロセスを実行している誰かによって検証された後に書き出し、編集可能な作業版として保管してください。例外は新しいものが出るたびに継続的に追加されるため、凍結されたプロセスドキュメントは多くの場合、すぐに古くなります。

PowerPointでプロセスドキュメントテンプレートはありますか？

プロセスを実行するのではなく、それを理解する必要がある人に対して説明する場合は、フローチャートまたはスイムレーン表示としてスライドを使ってください。詳細を入れる器としては不適切なので、代わりに作るのではなく、ドキュメントから組み立ててください。

Wordでステップバイステップのプロセステンプレートはありますか？

それは、上記の構造にあるステップセクションです。番号付きのアクションを1行につき1つずつ記載し、各行に期待される結果と「そして、もしそうでなければ」行を付けます。2つのプロセスかどうかを検討する前に、約12ステップまでにしてください。2行を超えるものは例外セクションに入れます。

プロセスドキュメントはどれくらいの長さにすべきですか？

例外が必要とする分だけです。通常は、ステップが1〜2ページに収まり、例外セクションがそれより長くなることを意味します。ステップだけで例外がないドキュメントは短くなりがちで、使われません。長さはページ数ではなく、新しい人がそこから実際の事例を完了できるかどうかで判断してください。

誰がプロセスドキュメントを書くべきですか？

プロセスを実行する人です。記憶ではなく、実際の事例のサンプルをもとに作業します。上の実例がその根拠です。経験年数のある2人が、自分たちのプロセスを徹底的にドキュメント化し、すべての例外を省きました。うっかりではなく、彼らが尋ねられた質問がハッピーパスを招く内容だったからです。

プロセスドキュメントはどのくらいの頻度で見直すべきですか？

スケジュールではなくトリガーに基づいて行います。システムが変わったとき、新しい例外タイプが2回出てきたとき、プロセスのオーナーが離れるとき、クリーン実行率が動いたときです。年に1回、20件を再サンプリングするのは1時間で済み、予定された読み直しよりも多くのことが分かります。