業務フローの要件漏れを防ぐ！「5W3H」と「As-Is / To-Be」の実践活用術
この記事は「要件定義の実践ガイド（全9回）」の第8回です。
本記事は単体でもお読みいただけますが、システム開発の最難関である要件定義を成功に導くためのノウハウを体系的にまとめています。
前後のプロセスもあわせて読むことで、より深い理解に繋がります。ぜひ他の連載記事もご活用ください！
全9回のシリーズ記事一覧はこちら（ページ下部へ）
「きれいな業務フローは描けたのに、後から『あのパターンの要件が漏れている』と発覚した……」
「現状（As-Is）とあるべき姿（To-Be）を描けと言われたが、それをどう実務（システム開発）に繋げればいいのか分からない……」
要件定義の現場で、こうした壁にぶつかるPMやエンジニアは少なくありません。 業務フローにおいて、図をきれいにルール通りに描くこと（形式）はもちろん大切ですが、それ以上に重要なのは、その図に「何が書かれているか（内容）」の網羅性です。
本記事では、数多くのプロジェクトで要件定義を主導してきた経験から、業務フローの質を劇的に高めるための戦略的なフレームワーク「As-Is / To-Be」の使い方と、情報の抜け漏れを物理的に根絶する「5W3H」の活用法について解説します。
「As-Is」と「To-Be」：2つのフローを戦略的に使い分ける
要件定義では、役割の全く異なる2つの業務フローを意識的に描き、使い分ける必要があります。
1. As-Is（アズ・イズ）：現状の「ありのまま」を写す
現在の業務の流れを、忖度なしにありのまま書き出した図です。
- 目的： 現場に隠れている「無駄（二重入力など）」「無理」「属人化」といった課題をあぶり出すため。
- 効果： いきなり新システムの話をするのではなく、まずは「今、誰が、何を、どうやっているのか」を正確に把握することで、システム化で解決すべき本当の課題が明確になります。
2. To-Be（トゥー・ビー）：理想の「あるべき姿」を描く
新システムを導入し、業務改善を行った後、「どのような業務プロセスに変わるべきか」を描いた図です。
- 目的： プロジェクトのゴールを関係者間で共有し、新システムに必要な「機能の根拠」を明確にするため。
- 効果： 「なぜそのシステム機能が必要なのか」をお客様と深く合意でき、後から仕様がブレない、迷いのない開発へと繋がります。
どちらから描き始めるべきか？（プロジェクト特性による判断）
「現状（As-Is）を固めてから理想（To-Be）を考えるか、いきなり理想から入るか」は、プロジェクトの性格によって使い分けます。
- 現状改善型（As-Isベースから入る）： 現状の明確な課題を解決し、着実な改善を目指す場合に有効。現場の運用と乖離しにくい（反発を生みにくい）メリットがあります。
- 抜本変革型（To-Beベースから入る）： DX推進など、ゼロベースで全く新しい仕組みを作る場合に有効。ただし、理想を追いすぎて現場が全くついてこれない「絵に描いた餅」にならないよう、高度な調整力が必要です。
業務フロー化がもたらす「4つの決定的なメリット」
手間をかけてまでAs-Is/To-Beの業務フローを作成することには、開発を円滑に進めるための強力なメリットがあります。
- 認識のズレを解消する「共通言語」になる： 業務が可視化されることで、関係者全員が同じ図を見ながら議論できます。「言った・言わない」や、立場による解釈の違いを最小限に抑えられます。
- ブラックボックス（属人化）を排除できる： 「特定の担当者しか知らない裏手順」や「実は誰も見ていない二重チェック」など、隠れた無駄や属人化をあぶり出し、標準化へのきっかけを作れます。
- 「全体最適」の視点で検証できる： 局所的な画面の機能改修ではなく、前後の工程を含めた業務全体の流れとして、本当に効率的で無理のない形になっているかを検証できます。
- 運用後の「資産」として転用できる： ここで整理されたTo-Beフローは、開発時のエビデンスとしてだけでなく、本番稼働後の操作マニュアルや新人教育の資料として、そのまま資産として活用可能です。
要件の解像度を劇的に高める「5W3H」の視点
情報を整理する基本のフレームワークとして「5W1H」は有名ですが、システム開発においてはこれだけでは不十分です。なぜなら、開発の根幹に関わる「コスト」と「規模」の視点が抜け落ちてしまうからです。
そこに「How Much（いくらで）」と「How Many（どれだけで）」の2つを加えた「5W3H」こそが、業務フローの各工程（作業の箱）を深掘りし、要件の抜け漏れを防ぐための強力な分析ツールとなります。
| 要素 | 着眼点 | 要件定義で深掘りするポイント（実務での例） |
|---|---|---|
| When | いつ | 処理の発生タイミング、締切日、月次・年次のサイクル、処理の順番 |
| Where | どこで | 拠点、部門、特定のシステム内、社外連携ネットワーク |
| Who | 誰が | 担当者、役割（ロール）、承認者、法人、外部連携システム |
| What | なにを | 取り扱う商品、データ（マスタ/トランザクション）、画面、帳票 |
| Why | なぜ | その作業を行う根拠、法的ルール、業務的な目的 |
| How | どうする | 具体的な操作手順、例外の分岐条件、システム的な計算式 |
| How Much | いくらで | システム単価、プロジェクト予算、ライセンス費用、コスト上限 |
| How Many | どれだけで | 処理数量、データ件数、同時接続ユーザー数、データ蓄積量 |
特に最後の「How Many（規模）」は、バッチ処理の性能要件やサーバーのデータ保存容量など、致命的なトラブルに繋がりやすい「非機能要件」に直結します。
ヒアリングの際、「業務フローの各ボックスに対して、この8つの問いに答えられるか？」というチェックリストとして5W3Hを活用することで、要件の解像度は劇的に向上し、漏れを物理的に根絶することができます。
業務フロー作成に潜む「3つの落とし穴」
メリットの多い業務フローですが、実務では以下のリスクに注意し、PMがしっかりとコントロールする必要があります。
1. リソースの過剰消費（現状分析の沼）
As-Is（現状）の整理にこだわりすぎると、あっという間に時間を使い果たしてしまいます。システム設計の時間が削られないよう、「要件定義フェーズにおける現状分析は〇週間まで」といった厳格なタイムボックス（時間管理）が必要です。
2. 現状維持バイアス（今のやり方への固執）
As-Isを細かく書きすぎると、お客様が「今のやり方」に固執してしまい、「今の画面と全く同じものを作ってくれ（現行踏襲）」と言い出すリスクが高まります。As-Isを提示する際は、常にTo-Be（改善案）をセットで提案し、未来へ目を向けさせましょう。
3. ドキュメントの陳腐化（更新ルールの不在）
設計や開発フェーズに入って仕様変更が発生した際、業務フローの図の更新が漏れると、図面と実装の実態が乖離してしまいます（陳腐化）。「仕様変更時は必ず業務フローもセットで更新する」という運用ルールを初期に決めておきましょう。
まとめ：業務フローを「戦略的」に使いこなそう
要件定義の質は、業務フローというツールをいかに戦略的に使いこなせるかで決まります。
- As-Is / To-Beで方向性を定める： 現状の課題を洗い出し、理想のあるべき姿を定義します。
- 5W3Hで要件漏れを根絶する： コストと規模（How Much/How Many）を深掘りし、非機能要件まで網羅します。
- 3つの落とし穴を回避する： リソースの枯渇・現状維持バイアス・図の陳腐化を防ぎ、最新状態を維持します。
ここで泥臭く情報を突き合わせることが、結果として大規模な手戻りを防ぎ、プロジェクトを成功へ導く最短ルートになります。
要件を深掘りする視点を得たら、最後はそれを具体的な「システム機能」へと繋げる構造化が必要です。 第9回（最終回）では、3つの階層を使い分け、機能一覧までを一気にまとめ上げる「業務フローの書き方完全ガイド」をお届けします。
要件定義シリーズ：実践ガイド一覧
[第1回] 要件定義の失敗しない進め方
[第2回] 企画構想の落とし穴を回避する点検ポイント
[第3回] 要求定義の具体的な進め方
[第4回] 非機能要件の進め方とヒアリング術
[第5回] 要件定義のWBS・タスク一覧
[第6回] 要件定義の準備術（体制と成果物）
[第7回] 業務フローの基本的な書き方
[第8回] 業務フローのフレームワーク活用術（5W3H・As-Is/To-Be）（本記事）
[第9回] 業務フローの書き方完全ガイド
