業務フロー可視化の方法とは？FDEが現場で使う手順とBPMN記法

業務フローの可視化とは？目的と得られる効果は？

業務フローの可視化とは、誰が・いつ・何を・どの順番で行うかを図にして、関係者全員が同じ現状認識を持てるようにすることです。

業務フローの可視化は、マニュアル作りやシステム要件定義の前段として昔から行われてきました。FDE（Forward Deployed Engineer）の仕事では、もう少し実践寄りの意味を持ちます。FDEは顧客の現場に入り込み、ソフトウェアを「使われる状態」まで持っていく職種です。Palantirが広めた働き方でもあります。そのため業務フロー図は、報告用の資料というより、現場とエンジニアが同じものを指さして話すための「共通の地図」として使われます。

可視化の第一の目的は「現状の共通認識」をつくること

可視化の第一の目的は改善案を出すことではありません。現場・管理者・開発者が同じ現状を指して話せる状態をつくることです。

業務の現場では、同じ「受付」という言葉でも、担当者によって指している範囲が違うことがよくあります。管理者が思っている手順と、現場で実際に行われている手順がずれていることも珍しくありません。図にすると、そのずれが「このステップは誰がやっているのか」「この分岐の判断基準は何か」という具体的な問いに変わります。現場に入る立場の実感として、図の完成度よりも、図を前にした会話で出てくる「実はここは…」という一言の方が価値を持つ場面が多いと感じます。

FDEにとっての効果は、要件の手戻り削減と導入範囲の特定

FDEにとって業務フロー可視化が効くのは、要件の手戻りを減らせる点と、ソフトウェアを入れるべき範囲を絞り込める点です。

導入を検討している企業の意思決定者にとっては、「どこに投資すれば効果が出るのか」を判断する材料になる点が大きいでしょう。

業務フローを可視化する手順は？FDEの現場プロセスは？

FDEの業務フロー可視化は「範囲を決める→聞く→観る→描く→現場で検証する」の5段階で進めるのが基本です。

机の上で図を描き始めるのではなく、現場の事実を集めてから描き、描いたものを現場に戻して確かめます。この往復がFDE流の特徴です。

ステップ1〜2：対象範囲を決めてからヒアリングする

最初に業務の「始点」と「終点」を1文で定義しておくと、ヒアリングが脱線せず、図の粒度も揃います。

たとえば「顧客から問い合わせメールが届いてから、回答を送信し終えるまで」のように、トリガーと完了条件をはっきりさせます。範囲を決めないまま始めると、関連業務がどんどん芋づる式に出てきて、図がいつまでも完成しません。

ヒアリングでは、次の順番で聞くと抜けが出にくくなります。

1. 通常の流れ（いちばん多いパターン）を最初から最後まで話してもらう
2. 各ステップで「何を見て判断しているか」を聞く
3. 「うまくいかないときはどうするか」で例外処理を拾う
4. 使っているシステム・Excel・紙・チャットツールを具体的に挙げてもらう
5. 「この作業にどのくらい時間がかかるか」を本人の感覚で聞いておく

時間の数字は正確でなくてもかまいません。あとで優先順位をつけるときの手がかりになります。

ステップ3〜5：観察・作図・検証で「実際の業務」に近づける

ヒアリングだけで描いた図は「本人が思っている業務」になりがちです。現場観察と読み合わせで「実際の業務」に近づけます。

現場観察では、画面の切り替え、コピー＆ペースト、他の人への確認といった、本人が「作業」だと思っていない動作に注目します。実務上の感覚としては、ヒアリングでは出てこなかった手作業や確認の往復が、観察で見つかることが少なくありません。

作図は、最初から清書ツールを使う必要はありません。付箋やホワイトボード、draw.io や Miro などのオンラインツールでラフを描き、読み合わせで直していく方が進みやすいでしょう。読み合わせでは、担当者自身に図を指でなぞりながら説明してもらいます。どこで言葉に詰まるかを見ると、図の誤りや業務の曖昧さを見つけやすくなります。

業務フローの記法はどれを選ぶべき？フローチャート・スイムレーン・BPMNの違いは？

関係者の合意形成にはスイムレーン図、システム実装や自動化の設計にはBPMNを選ぶのが実務上の目安です。

記法の選び方で迷ったときは、「その図を誰が読み、何に使うか」から逆算します。現場の担当者に見せる図と、開発チームやワークフローエンジンに渡す図では、求められる厳密さが違うからです。

フローチャート・スイムレーン図・BPMNの比較

3つの記法は表現力と学習コストが段階的に違います。まずは「誰が担当するか」を表せるかどうかで判断すると選びやすくなります。

BPMN 2.0の基本要素は5種類を押さえれば読める

BPMN 2.0は要素が多い記法ですが、イベント・アクティビティ・ゲートウェイ・フロー・プール/レーンの5種類を押さえれば基本は読めます。

BPMN（Business Process Model and Notation）は業界標準化団体 OMG（Object Management Group）が策定した記法です。BPMN 2.0 は2011年に正式版が公開され、2013年には ISO/IEC 19510 として国際規格になりました。

注意したいのは、BPMN の全要素を最初から使おうとしないことです。現場の担当者に見せる段階では、上の5種類だけで描いたスイムレーン型のBPMNに留めておく方が、読み合わせがスムーズに進むと考えています。

使い分けの判断基準は「読み手」と「次の工程」

同じ業務でも、段階に応じて記法を切り替えるのが現実的です。最初からBPMNで完璧に描く必要はありません。

1. 現状把握・合意形成の段階：スイムレーン図（またはBPMNの基本要素だけ）で描く
2. 課題特定の段階：同じ図に、手作業・待ち時間・二重入力の箇所を印で重ねる
3. 設計・実装の段階：自動化する範囲だけを BPMN 2.0 で厳密に描き直す（Camunda Modeler などの BPMN 対応ツールを使うと、ワークフローエンジンとつなげやすくなります）

FDEの立場から見ると、1と3を同じ人が行き来できることに価値があります。現場の言葉で描いた図を、エンジニアが実装できる粒度に翻訳する作業こそ、FDEという職種が担う中心的な役割の一つだからです。

業務フロー可視化でよくある失敗と対策は？

よくある失敗は「理想を描く」「粒度がばらばら」「描いて終わる」の3つで、どれも手順とルールを先に決めておけば防げます。

失敗1：理想の業務（To-Be）を現状として描いてしまう

いちばん多い失敗は、マニュアル上の「あるべき手順」を現状として描いてしまうことです。As-Is と To-Be は必ず別の図に分けます。

ヒアリングの相手が管理者だけだったり、規程集をもとに描いたりすると、この失敗が起きやすくなります。対策は、ステップ3の現場観察を省かないことと、図のタイトルに「As-Is（2026年9月時点）」のように状態と日付を明記することです。日付を入れておくと、あとで改善効果を比べるときにも役立ちます。

失敗2：粒度が揃わず、図が読めなくなる

「受注処理」という大きな箱の隣に「ボタンを押す」という小さな箱が並ぶと、図は一気に読みにくくなります。粒度のルールを先に決めましょう。

実務上使いやすいのは、「1つのタスクは、1人の担当者が1回の着手で終えられる作業」という定義です。それより細かい操作手順は、タスクに注記として付けるか、別の詳細図に分けます。全体図は1枚に収まる程度の要素数に抑え、詳細はサブプロセスとして切り出すと、意思決定者向けと実務者向けの両方に対応できます。

失敗3：描いて終わり、誰も更新しない

業務フロー図は、完成した瞬間から古くなり始めます。更新担当と更新タイミングを決めない図は、数か月で使われなくなると考えておくべきです。

FDEは導入が終わればいずれ現場を離れます。そのため、図の保守を顧客側に引き継げる形にしておくことが大切です。具体的には、顧客側で更新担当者を決め、ツールを顧客が普段使っているものに揃え、システム改修や組織変更のタイミングで見直すルールをあらかじめ合意しておくとよいでしょう。業務フロー図を「FDEの作業資料」ではなく「顧客の資産」として残すことが、FDEが関わるプロジェクトの価値を長く保つことにつながります。

業務フロー可視化は、図を描く技術以上に、現場に入って事実を集め、描いた図を現場に戻して確かめる往復の技術です。記法はスイムレーン図から始め、自動化が必要な範囲だけBPMN 2.0で厳密に描く。この段階的な進め方が、FDEの現場では現実的だと考えています。

姉妹メディアの関連記事