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

プロセスドキュメントとは、繰り返し発生する業務が実際にどのように行われているか、誰が各部分を担当するか、そしてその業務がどこで始まりどこで終わるかを記録した文書である。

業務プロセス文書は、部門ではなく実行そのものを対象に、繰り返し行われる一つの業務を順序立てたアクションの連なりとして記録する。優れたプロセスドキュメントは、回避策も含めてチームが現在実際に行っている進め方をそのまま記録し、ツールや方針が変わった週のうちに更新される。業務がどうあるべきかを記した文書は、意図を記録しているにすぎない。

プロセスドキュメントの仕組み

プロセスドキュメントの要件

• 順序立ったステップ： 文書は、繰り返し行われる一つの業務のアクションを発生順に並べているため、次に何をすべきか考えずに上から下へたどることができる。
• 一定周期でのレビュー： ヘッダーにレビュー日が記載され、業務が変わると文書も更新される。これが、生きた文書と一度書かれただけのファイルとの違いである。
• 開始地点と終了地点： ヘッダーには業務がどこで始まりどこで終わるかが明記されているため、自分の責任範囲がどこから始まりどこで引き継がれるかが分かり、一つの文書が三つの業務に膨らむこともない。
• 各ステップは役割が担う： 各ステップは特定の個人ではなく、それを実行する役割を明記しているため、その人がチームを異動しても文書は生き続ける。
• 現在の業務の実態通りに： この記録は、ステップ4の回避策も含め、チームが今実際に行っている業務を捉えている。理想版を描いた文書はチームが従わない業務を説明することになり、読者はやがてそれを開かなくなる。

プロセスドキュメントが重要な理由

一人の頭の中だけにあるプロセスは、カレンダー付きの単一障害点である。その人が2週間休みを取れば、業務は止まるか、誰かが勘で進めることになり、その勘は後になって返金、更新漏れ、あるいはチームが説明できないコンプライアンス上の指摘として表面化する。

立ち上げコストは二重にかかる。文書のない新入社員は同僚に声をかけて学ぶため、一人分のオンボーディングが二人分の時間を消費し、それが次の新入社員、そのまた次の新入社員でも繰り返される。プロセスを文書化することは、その会話の将来のすべてのバージョンと引き換えに、一度だけ半日をかけることに等しい。

同じ未文書化のプロセスを二人が実行すると、二つの異なる成果物が生まれる。これは、誰かが気づくミスとしてではなく、ばらつきとして現れるエラー率である。AtlassianはこのポイントをICUのチェックリスト研究に結びつけている。業務プロセス文書はまた、無駄なステップを可視化する。チームが一度も記述したことのないプロセスのボトルネックは見つけられず、それを取り除いたことを証明することもできない。

プロセスドキュメントの種類

プロセスドキュメントには、業務の形に応じて選ばれる5つの一般的な形式がある。そのうち2つは、次のセクションで比較する独自の用語も持っている。

プロセスドキュメント vs SOP vs プロセスマッピング

定義ではなくテストを当てはめる。監査対象の成果物であればSOP、承認プロセスのない番号付き手順は別名のプロセスドキュメント、一人にとどまるタスクは作業指示書、ワークショップ中しか開かれない文書はマップ、そして実際のシフト中に人が従うものはすべてあなたのプロセスドキュメントである。

プロセスドキュメントの作り方

1. 業務に名前を付け、境界を定める。 業務名、それを開始させる出来事、終了させる出来事を書く。作業が他のチームに引き継がれる時点で止め、その先は相手のチームの文書に任せる。
2. 入力と出力を列挙する。 署名済みの注文や記入済みのチケットなど、誰かが着手する前に存在しなければならないものと、業務完了時に存在するものを明記する。
3. 実際の進め方を記録する。 実行者に同席するか、作業中の画面を録画し、古いプロセスマップの記述ではなく、彼らが実際に行っていることから手順を取り出す。
4. 手順を順番に書き、それぞれに役割を紐づける。 各ステップに一つのアクションを与え、次に進む前に読者が確認すべき結果を明記し、それを実行する役割をステップの先頭に置く。
5. 例外を書き留める。 ハッピーパスが飛ばす分岐にはそれぞれ一文を添える。承認限度額を超える返金、口座を持たない顧客、間違った形式で届くファイルなど。
6. その業務を一度もやったことがない人に草案を渡す。 文書だけを頼りに業務を実行させ、質問されたステップはすべて書き直す。彼らの質問は、校正よりも多くの抜けを見つけ出す。
7. 業務が行われる場所で公開し、日付を入れる。 一元的で検索可能な場所に置き、ヘッダーに担当者名を記載し、公開日ではなくレビュー日を設定する。

プロセスドキュメントの例

プロセスドキュメントには9つの項目が必要である。名前、担当者、開始条件、終了条件、入力、出力、それぞれに役割が付いたステップ、例外、そして周期付きの最終レビュー日である。現場インシデント報告のプロセスでは、これらは次のように記入される。

• 業務名： 現場インシデント報告
• 担当者： 現場安全責任者
• 開始条件： 現場の誰かが負傷、ヒヤリハット、または物損を目撃または経験した時
• 終了条件： 現場安全責任者がクローズ済みインシデント記録を提出し、是正措置に担当者と期限が設定された時
• 入力： インシデント報告書、現場記録簿、現場の写真、シフト表
• 出力： 提出済みインシデント記録、クライアントへの通知、担当者付きの是正措置
• ステップ：
• 例外： 現場安全責任者は、報告義務のある負傷については24時間以内に規制当局へ報告し、聞き取りステップを省略する。第三者の資産への損害については、スーパーバイザーが先にクライアントへ通知する。
• 最終レビュー： 2026年6月　・　レビュー周期： 四半期ごと、または現場記録簿や報告基準が変わった週

実際のプロセスドキュメントを見る

以下のページは、サインインなしで最初から最後まで読める完成済みのプロセスドキュメントであり、Hintoが公開URLとして公開した文書である。これは、画面録画から社内ワークフローSOPプロジェクトを作成するという一つの繰り返し業務を対象に、それぞれスクリーンショット付きの番号付きステップとしてまとめ、最後にまとめのセクションで締めくくっている。

録画から一度でプロセスドキュメントへ

文書を書くことこそ、チームが手を止めてしまう部分であり、そのためプロセスは一人の頭の中にとどまり続ける。業務の実行を一度録画するだけで、白紙のページという壁がなくなる。録画には、回避策も含め、チームが実際に行っているプロセスがすでに含まれているからだ。

Hinto AIは画面録画を解析し、UIの状態変化やボタンのクリックを検出してスクリーンショットと文章化された手順を抽出する。ソースは、Hintoのウェブアプリやクローム拡張機能で作成した録画でも、すでに持っている動画（Loom、Zoomセッション、YouTube動画、ローカルのMP4）でもかまわない。長い録画は目次付きの複数の整理された記事になり、SOPテンプレートがそれを社内ワークフローガイドとして構成する。

リモートチームや非同期で働くチームは、ここでその答えを得る。すでに実施したZoomトレーニングセッションがそのまま文書になり、ワンクリックでカスタムドメイン付きの公開URLとして公開できる。ツールが変更されたら、影響を受けるセクションを選択してそのブロックだけの書き直しを依頼すればよく、ページ全体を作り直す必要はない。

プロセスドキュメントに関するFAQ

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

四半期ごと、加えて基盤となるツールや方針が変わった週のどちらか早い方で更新する。プロセスを所有するチームリーダーなど、ヘッダーには担当役割名を入れておく。担当者のいない文書はデフォルトで陳腐化していく。誤った画面に2回遭遇した新入社員は、ライブラリ全体への信頼を失う。

プロセスドキュメントの理想的な長さは？

1つの文書には1つの業務。通常は5〜15ステップに収まり、1画面で読み切れる長さになる。それより長い草案は、すでに2つ目の業務へと境界を越えているため、引き継ぎ地点で分割する。詳細を書き込みすぎると読者を失い、読まれない詳細は何の保護にもならない。

プロセスドキュメントへのチームの賛同はどう得るか？

実際に業務を行っている人たちと一緒に草案を作る。最初の草案が回覧される前にレビュアーと承認基準を決めておかないと、あいまいなままの不満に対して3回も修正することになる。現場の担当者自身が手直しした文書は開かれるが、彼らの頭越しに書かれた文書は迂回される。

プロセスフロー文書とは何か？

プロセスフロー文書は、このテーマで最も一般的な形式の一つであるフローチャートとして描かれた、同じ記録である。図は経路と分岐点を示す。入力、例外、担当者は含まれないため、絵だけを渡すのではなく、文章化された手順と組み合わせる。