業務フローの基本的な書き方｜要件定義の手戻りを防ぐ作図の基本と6つの鉄則
この記事は「要件定義の実践ガイド（全9回）」の第7回です。
本記事は単体でもお読みいただけますが、システム開発の最難関である要件定義を成功に導くためのノウハウを体系的にまとめています。
前後のプロセスもあわせて読むことで、より深い理解に繋がります。ぜひ他の連載記事もご活用ください！
全9回のシリーズ記事一覧はこちら（ページ下部へ）
「このフロー、例外処理が考慮漏れしていてプログラムが組めません……」 「開発に入ってから『そんな業務の流れだとは聞いていない』と言われた……」
要件定義を進める際、業務フローは単なる「お絵かき」ではなく、プロジェクトの成否を分ける極めて重要なツール（共通言語）になります。
基本を疎かにしたまま自己流で作図していると、お客様との認識ズレが生じ、後続の設計・開発工程で致命的な手戻りを招くことになります。現場のPMやエンジニアにとって、開発後半での仕様変更ほど恐ろしいものはありません。
本記事では、数多くのプロジェクト現場を見てきた経験から、初めて業務フローを書く方はもちろん、改めて基本を整理したいエンジニアに向けて、現場で即使える「作図前の事前準備」と「6つの鉄則」をわかりやすく解説します。
業務フローの役割：なぜ「共通言語」として必要なのか？
業務フローとは、複雑な業務のプロセス（流れ）を可視化したものです。文章だけでは伝わりにくい全体の流れを直感的に理解できるようにし、お客様と開発側の「理解の食い違い」を最小限に抑える役割を持ちます。
業務フローを作成することで、プロジェクトには主に以下の4つのメリットがもたらされます。
- 現状の可視化： 属人化している業務の流れを客観的に評価し、ブラックボックスをなくします。
- 無駄の発見： プロセスの中に潜む「二重入力」や「待機時間」などの停滞ポイントを特定できます。
- あるべき姿の検証： 部門をまたがる情報の流れを整理し、システム導入後の最適なプロセスを検討できます。
- ドキュメントの資産化： ここで決定した手順は、そのまま稼働後の業務マニュアルや引き継ぎ資料として活用できます。
いきなり書かない！迷走を防ぐ「3つの事前準備」
業務フロー作成ツールを開いて、いきなり図形を並べ始めるのは迷走の元です。まずは土台となる以下の3点を整えましょう。
1. 記号のルール（凡例）を決める
最も大切なのは「プロジェクト内で使う記号を統一する」ことです。標準的なJIS規格などに厳密にこだわりすぎず、お客様が見た瞬間に意味が伝わる表現を心がけましょう。
必ず「凡例」を作成し、打ち合わせの冒頭で定義を共有します。「パソコン操作ならPCのアイコン」「メール送信なら封筒のアイコン」などを使う工夫で、説明の手間がぐっと減ります。
【事例：プロジェクトで定義しておくと便利な記号の凡例】
| 記号 | 意味 | 説明 |
|---|---|---|
 | 開始 | 業務プロセスの「開始」を表す。 |
 | 終了 | 業務プロセスの「終了（完了）」を表す。 |
 | 分岐・合流 | 作業の分岐や合流ポイントを表す。線の上に分岐条件も記載する。 |
 | 人による作業 | システムを使わない、人による判断や手作業を表す。 |
 | システム作業 | ユーザーがシステムを利用して行う作業を表す。 |
 | システム機能 | 裏側で動くシステム単体の機能（自動処理など）を表す。 |
 | 画面 | 利用される画面を表す。具体的な画面名を記述する。 |
 | 帳票 | 利用される帳票を表す。具体的な帳票名を記述する。 |
 | データ | 利用されるデータを表す。具体的なデータ名を記述する。 |
 | 作業の流れ | 作業を矢印でつなげて、プロセスの順序を表す。 |
 | データの流れ | データを矢印でつなげて、情報の移動や連携を表す。 |
 | 結合子 | 同一ページ内での矢印のつながりを表す（中に番号を振る）。※同じ数字同士がつながる。 |
 | 他ページ結合子 | ページをまたがる矢印のつながりを表す（中にアルファベットを振る）。※同じ英字同士がつながる。 |
2. 業務の「粒度」を合わせる
「何をするか（What）」を書くのか、それとも画面のボタン等「どう操作するか（How）」を書くのか、事前に関係者間で方針を合わせます。
基本的には、要件定義の段階では「What（業務の目的と結果）」の観点でまとめると、本質的な課題が見えやすくなります。迷ったら、「1つの業務フローをA4用紙1枚（または1画面）に収める」というルールを設けるのがおすすめです。1枚に収まらない場合は、粒度が細かすぎる（操作手順書になっている）サインです。
3. 現行資料（現物）を収集する
ヒアリングを効率的に進めるために、既存の業務マニュアル、現行システムの画面キャプチャ、実際に現場で使われている帳票（Excelや紙の伝票）などを事前に手元に揃えましょう。「言葉」だけのヒアリングでは見落としがちな例外処理や細かいデータ項目も、「現物」があることで正確に可視化できるようになります。
現場で差がつく！見やすいフローを書くための「6つの鉄則」
事前準備が整ったら、いよいよ作図です。ここでは、後工程のエンジニアやお客様が見たときに「わかりやすい」と感じる実務的な鉄則を6つ紹介します。
1. 登場人物は部署ではなく「役割（ロール）」にする
単なる「営業部」といった部門名だけでなく、その中での「役割（担当者、承認者など）」に注目してレーンを分けましょう。 「1つの作業（箱）には1人の担当者しか入れない」のが鉄則です。これにより、後の工程でシステムの権限設計（誰にどのメニューを見せるか）を行う際の混乱を防ぐことができます。
2. スイムレーンの向き（縦・横）を工夫する
作業範囲を明確にする「スイムレーン」は、やり取りの多い部署やシステム同士を隣り合わせに配置するのがコツです。これにより矢印が短くなり、格段に読みやすくなります。また、プロジェクトの特性に合わせて縦横の軸を使い分けましょう。
- 縦軸（上から下へ）： A4縦で印刷して配布する場合に適した、馴染みのある形式。
- 横軸（左から右へ）： 時系列の変化が追いやすく、PCのワイドモニターでスクロールしながら見るのに適した形式。
3. プロセスの「開始」と「終了」を明記する
「どこから始まって、どこで終わる業務なのか」を、専用の記号（角丸の枠など）を使って必ず明記します。これがないと、読み手はスタート地点を探すことになり、業務の完結条件も曖昧になります。開始と終了を明確にすることは、要件のスコープ（開発範囲）を定義することと同義です。
4. 矢印（線の流れ）を極力交差させない
複雑な業務ほど矢印が増えますが、線が交差しすぎると直感的に流れが追えなくなります。記号の配置やレーンの順番を入れ替える工夫をし、どうしても交差する場合は、3本以上の線が一点に重ならないよう配慮しましょう。
5. 「インプット」と「アウトプット」を常に意識する
すべての作業には、必ず「きっかけ（電話・メール・データ受信等）」と「結果（伝票発行・データ更新・次担当への依頼等）」が存在します。これを意識して図に落とし込むことで、データの発生源と行き先、情報の流れが正確に把握できるようになります。
6. 例外パターンの「分岐条件」を見逃さない
正常な流れ（ハッピーパス）だけでなく、「在庫がある場合 / ない場合」「時間帯や金額による条件」「エラー発生時」といった例外的なパターンも含めて網羅的に確認し、ひし形（◇）の分岐記号で表現しましょう。この「分岐条件の整理」こそが、後のシステム設計におけるプログラムロジックの根幹になります。
まとめ：業務フローは要件定義の「羅針盤」
要件定義の本質は、業務プロセスのあるべき姿を決め、標準化することにあります。業務フローはそのための強力な羅針盤となります。
- 可視化： 現場の暗黙知を白日の下にさらし、関係者全員の共通認識を作る。
- 改善： 誰の目にも明らかな「無駄」を見つけ出し、プロセスを最適化する。
- 標準化： システム導入後、誰が担当しても同じ結果が出せる資産にする。
まずは身近な業務から、A4用紙1枚に収めるつもりでペンを動かしてみてください。
図の基本的な描き方をマスターしたら、次はそこに盛り込む「情報の密度」を高めるステップです。 第8回では、要件の抜け漏れを物理的に防ぐための戦略的な活用術として、「5W3H」や「As-Is / To-Be」といったフレームワークを活用した業務フローの考え方を解説します。
要件定義シリーズ：実践ガイド一覧
[第1回] 要件定義の失敗しない進め方
[第2回] 企画構想の落とし穴を回避する点検ポイント
[第3回] 要求定義の具体的な進め方
[第4回] 非機能要件の進め方とヒアリング術
[第5回] 要件定義のWBS・タスク一覧
[第6回] 要件定義の準備術（体制と成果物）
[第7回] 業務フローの基本的な書き方（本記事）
[第8回] 業務フローのフレームワーク活用術（5W3H・As-Is/To-Be）
[第9回] 業務フローの書き方完全ガイド
