「ヒアリングでは『普通の注文を処理するだけ』って言っていたのに……」
開発やテストの終盤、あるいは本番リリースの直前になって、次のような言葉が顧客からポロッと出てきた経験はありませんか？
- 「そういえば、月に数回だけ手作業で処理している特殊なケースがありまして……」
- 「あ、この取引先だけは昔からの独自ルールで別フォーマットなんです」
その一言で現場は凍りつき、追加開発や手戻り対応に追われ、スケジュールは炎上。プロジェクトマネージャー（PM）やエンジニアが疲弊していく——。
私自身、かつて何度もこの「後出しの例外パターン」に頭を抱えてきました。
しかし、数々の現場で試行錯誤を重ねるうちに、ひとつの確信に至りました。それは「顧客も、自分たちの業務を正確には言語化できていない」という不都合な真実です。
本記事では、要件定義における手戻りを根本から防ぐための「生データから業務実態を逆算するアプローチ」について解説します。
1. 顧客が語る業務フローは「9割がハッピーパス」である
打ち合わせの場で顧客が説明してくれる業務内容は、基本的に「正常ケース（ハッピーパス）」がほとんどです。
顧客が決して嘘をついているわけではありません。現場の担当者にとって「たまに発生する例外的な処理」や「手作業でのリカバリー」は、あまりに日常的すぎて無意識のルーティン（当たり前）になってしまっているのです。
なぜ口頭ヒアリングだけでは例外が出ないのか？
- 人間の記憶や感覚に頼るヒアリングには限界がある
- 現場担当者が「これはシステム化と関係ない些細な例外」と自己判断してしまう
- 過去の経緯を知るベテランの暗黙知が属人化している
そのため、どれほど丁寧に口頭ヒアリングを重ねても、すべての業務パターンを事前に洗い出すのは構造的に不可能です。結果としてフェーズが進むほど枝葉の議論に振り回され、プロジェクト全体が疲弊していきます。
2. 解決策：「言葉」ではなく「生データ」で業務を定義する
この手戻りを未然に防ぐために徹底すべきなのが、「ヒアリングの前に現場の生データを預かり、データを解析して業務を逆算する」というアプローチです。
言葉による説明ではなく、実際の「データの痕跡」から隠れた業務ルールを炙り出します。
【具体例】EC・受発注システム導入現場での実例
ある受発注システムの刷新プロジェクトにおいて、当初のヒアリングでは「注文データを取り込んで出荷指示を出すシンプルな流れ」と説明されていました。
しかし、開発着手前に過去1年分の受注履歴データ（CSV）を提供いただき、傾向を分析したところ、以下の実態が判明しました。
| データ分析から見えた事実 | 現場の実態（暗黙のルール） |
| 同一住所への短時間複数注文（全体の約8%） | 同一ユーザーが数分おきに注文した際、現場が手作業で「同梱出荷」にまとめていた |
| 備考欄への特定文字列の手入力（全体の約7%） | 備考欄に「【領収書宛名：◯◯】」「【置き配希望】」と手動入力し、別処理を行っていた |
現場担当者にとっては「画面を見ながら手作業でよしなに処理する当たり前の作業」だったため、事前のヒアリングでは一切出てきませんでした。
もしこれを見落としたまま開発を進めていれば、リリース直前の受入テストで「前のシステムでできていた同梱処理ができない！」「備考欄が反映されない！」と大混乱に陥っていたはずです。
事前に生データから例外を暴いたことで、着工前に「同梱判定ロジック」と「備考欄の自動振り分け処理」を正式な仕様として定義し、大幅な手戻りを防ぐことができました。
3. 実践：生データから例外を暴く3つの分析視点
現場から生データを入手したら、以下の3つのポイントを重点的にチェックします。
① NULL値・空白の分布を調べる
- 見るべきポイント：必須項目であるはずの列に「空白」が存在しないか
- 隠れたルールの例：特定条件下（例：海外発送、特定代理店経由など）においてのみ入力が免除される「裏ルール」が存在するサインです。
② 文字列カラムの「表記揺れ」と「手入力パターン」を洗う
- 見るべきポイント：備考欄、メモ欄、品名欄などのフリー入力項目
- 隠れたルールの例：「至急」「別送」「保留」「請求書同封」などの頻出キーワードを集計することで、システム外で手運用されている運用フローが見えてきます。
③ 日時・数値の「外れ値」を抽出する
- 見るべきポイント：異常に金額が大きい/小さいレコード、土日・深夜の更新ログ
- 隠れたルールの例：例外的な大量発注時の値引き処理や、締め日後のイレギュラー処理が行われている可能性があります。
4. 顧客へのヒアリングは「データ（事実）」を起点に行う
生データの分析結果をもとにヒアリングを行うと、質問の質が劇的に変わります。
- NGな聞き方（抽象的）：
- 「同梱処理や備考欄の特別な運用はありますか？」
- ✕ 顧客：「特にないと思います（思い出せない）」
- 効果的な聞き方（事実ベース）：
- 「過去データを見ると全体の約8%で同一住所への複数注文がありますが、現場ではどのように処理されていますか？」
- ◯ 顧客：「あ、それは出荷場で手動でまとめて同梱伝票を発行していますね！」
事実（データ）をベースに質問を投げかけることで、顧客側からも「そこまで業務を見てくれているのか」と信頼感が生まれ、スムーズな合意形成につながります。
まとめ｜PMの仕事は「情報の交通整理」
プロジェクトを成功させるために必要なのは、気合いや根性論ではなく「事実（データ）に基づいた前提の設計」です。
- 顧客の言葉を鵜呑みにせず、生データで実態を掴む
- 隠れた例外パターンを着工前に仕様へ落とし込む
- チーム全員が同じ前提を持って自走できる舞台を整える
このアプローチを意識するだけで、手戻りによる不要な混乱は劇的に減り、顧客と開発チームの双方が健全にプロジェクトを推進できるようになります。
日々の要件定義やプロジェクトマネジメントで手戻りに悩んでいる方は、ぜひ次回のプロジェクトで「まず生データを見せていただくこと」から試してみてください。
コメント