業務フローの書き方完全ガイド｜3つの階層で「機能漏れ・手戻り」を物理的に防ぐ実践術

この記事は「要件定義の実践ガイド（全9回）」の最終回です。
本記事は単体でもお読みいただけますが、システム開発の最難関である要件定義を成功に導くためのノウハウを体系的にまとめています。
前後のプロセスもあわせて読むことで、より深い理解に繋がります。ぜひ他の連載記事もご活用ください！
全9回のシリーズ記事一覧はこちら（ページ下部へ）

「開発終盤になってから『機能が足りない』と言われた……」
「テスト段階で『想定していた動きと、現場の運用が全然違う！』とお客様から怒られた……」

システム開発の終盤になってからこうした指摘を受ける事態は、プロジェクトにとって致命的な痛手（手戻り）となります。

要件定義でのヒアリングは重要ですが、口頭や議事録の文章だけのコミュニケーションには限界があります。受け取り側の「解釈のズレ」を排除し、手戻りを防ぐためには、可視化された「業務フロー」を共通言語にすることが絶対に不可欠です。

本記事では、数多くの炎上プロジェクトを救ってきた経験に基づき、要件定義における業務フローを「3つの階層」で整理し、システムの機能一覧まで漏れなく落とし込むための超実践的な手法を完全ガイドとして解説します。

なぜ要件定義の業務フローは「3階層」必要なのか？
漏れを防ぐ！業務フロー「3つの階層」の役割
【事例で解説】3階層の構造（家族旅行で例えると？）
現場で差がつく！階層別の「書き分け」実務テクニック
最終ゴール：フローを「業務機能一覧」へ落とし込む3ステップ
まとめ：お客様と「同じ景色」を見るために

なぜ要件定義の業務フローは「3階層」必要なのか？

要件定義のスタートは、対象となる業務を正しく理解することです。図式化されたフローを用いることで、ユーザーとの認識合わせが容易になります。

しかし、現場担当者向けの詳細な手順（How）ばかりを最初から描いてしまうと、経営層や他部署が見たときに全体像（What）が全く分からず、後から「あのシステムとの連携が考慮されていない」といった大規模な漏れが発生します。

これを防ぐカギが、「3つの階層」による整理です。階層を分けてフローを描くことで、経営層から現場担当者、そして開発エンジニアまで、それぞれの視点に合わせた「同じ景色」を見ることができるようになります。

漏れを防ぐ！業務フロー「3つの階層」の役割

具体的に、以下の3つの階層（レベル）でドキュメントを作成していきます。

第1階層：業務プロセス関連図（全体を俯瞰する）

対象業務全体の情報の流れを鳥瞰（上空から見下ろす）し、1枚にまとめた図です。

焦点： プロジェクトのスコープ（システム化の対象範囲）の明確化。
内容： 「受注管理」「在庫管理」といった大きな粒度でプロセスを記述。
重要ポイント： 他システムとの連携や、今回開発しない「スコープ外」の境界線を赤枠などでハッキリと明示する。

【図の解説】
架空の「販売管理システム再構築プロジェクト」の例では、赤い点線の囲みが今回のスコープであることを示しています。これにより、「EDIシステム」や「マスター管理システム」は見直しの対象ですが、「倉庫管理システム（WMS）」や「会計システム」はスコープ外（外部連携のみ）であることが一目で判別できます。

第2階層：業務フロー（プロセスの細分化）

第1階層で洗い出した対象業務について、具体的な手順をまとめた標準的な「スイムレーン形式」の図です。

焦点： 現場担当者との課題抽出（As-Is）と、あるべき姿（To-Be）の検討。
内容： 「誰が」「いつ」「何をするか」を時系列で整理。
重要ポイント： 標準的な「正常系」だけでなく、例外処理や分岐も漏れなく書き出す。

【図の解説】
「受注管理」業務を詳細化したサンプルです。ここでは「電話で注文を受ける」という標準的な流れをスイムレーン形式で整理しています。実際の業務はより複雑になりますが、まずはこのレベルで現場担当者と現状（As-Is）の課題を共有し、改善後のフローを検討するベースとして活用します。

第3階層：システム化業務フロー（利用場面の具体化）

第2階層のフローに、具体的な「システムの操作場面」を書き込んだ最も詳細なフローです。

焦点： システム機能、画面、データとの紐付け。
内容： 現場の作業の中で「どの画面を使い」「どの機能を実行し」「どのデータを扱うか」を明記。
重要ポイント： 人間がやる作業と、システムがやる作業の「境界（インターフェース）」を浮き彫りにする。

【図の解説】
「受注管理」のフローにシステム利用場面を追加した例です。一番右側にシステムの列を設け、「在庫状況照会」画面での「在庫チェック」といった具体的な操作と、そこで扱うデータの流れを記述します。これにより、開発者が実装すべき画面や機能の要件が明確になります。

【事例で解説】3階層の構造（家族旅行で例えると？）

この3階層の構造は、「家族旅行」に例えると非常にスッキリと理解できます。

階層	システム開発での名称	家族旅行での例え
第1階層	業務プロセス関連図	旅行全体の計画
第2階層	業務フロー	予約プロセスの細分化
第3階層	システム化業務フロー	予約サイトの利用場面

階層を下る（ブレイクダウンする）流れ： まずは第1階層で「計画〜旅行〜反省」といった全体像を捉えます。次に、第2階層でその中の「旅行の予約」プロセスだけを切り出し、「新幹線〜ホテル」などの手順に分解します。最後に第3階層で、さらに「ホテル予約」だけを切り出し、予約サイトでの検索や比較といった「道具の使い方」を具体化します。

この順番を絶対に守ることで、大きな「機能の抜け漏れ」を劇的に減らすことができます。

現場で差がつく！階層別の「書き分け」実務テクニック

各階層の図を書き上げる際に、実務に精通したPMが重視しているテクニックを紹介します。

1. 業務プロセス関連図のコツ

A4用紙「1枚」に収める： 全体俯瞰が目的のため、情報を詰め込みすぎず視認性を維持します。
「物流・商流・情報流」の3つを追う： モノ、カネ、データの流れが矛盾なくつながっているかを確認します。
手作業（アナログ）を明示する： システム化しない作業や外部連携こそ、情報が途切れてトラブルの火種になりやすいため、忘れずに記載します。

2. 業務フローのコツ

操作（How）ではなく業務（What）を書く： 画面のクリック手順ではなく、業務上の「目的を持ったアクション」を明確にします。
業務の「まとまり」を意識する： 担当者が変わるタイミングや、情報の受け渡しポイントでプロセスを区切ると整理しやすくなります。
As-Isの課題抽出とTo-Beの改善提案を行う： 現状の無駄（二重入力など）を洗い出し、それをITやルール変更でどう解決するかをセットで検討します。
「情報」と「モノ」の整合性を追う： 入力したデータと、実際の物品の動きが一致しているかを確認します。
例外処理と時間軸（サイクル）を網羅する： 正常系だけでなく、エラー時の緊急対応や、日次・月次・繁忙期特有のイレギュラー業務が漏れていないか確認します。
複雑な分岐は「別紙」に逃がす： 複雑な業務ルールや条件分岐をすべてフローに書き込むと視認性が崩壊します。細かな仕様は「業務内容定義書」などの別紙に切り出して補完します。