「例外」が要件定義で最もつまづくポイント
「例外」と聞くとレアケースに思えますが、現場では例外が日常的に発生しています。この例外を要件定義の段階でどれだけ洗い出せるかが、システムの完成度を大きく左右します。
「例外」とは何か
システム開発における「例外」とは、「通常の処理の流れから外れるケース」のことです。
たとえば、受注の流れを設計するとき、基本的な流れ（正常系）は「顧客が注文 → 担当者が確認 → 在庫を引当 → 出荷」です。しかし実際には、こんなことが起きます。
- 在庫が足りない場合はどうするか
- 顧客がキャンセルを申し出てきたらどうするか
- 一部だけ出荷して残りは後日という場合は？
- 同じ顧客から重複して注文が入ったら？
- 担当者が不在で承認が止まった場合は？
これらがすべて「例外」です。通常フローに含まれていないが、現場では定期的に発生する事態です。
なぜ例外が要件定義で漏れるのか
例外が要件定義から漏れる理由はいくつかあります。
「当たり前すぎて言わない」：現場の担当者にとって日常的な例外処理は、「わざわざ言うまでもない」と感じていることがあります。「在庫が足りなかったら電話で確認するのは当然でしょ」という感覚で話してくれないのです。
「ほとんどないから」という油断：「そういうケースは月に1〜2回しかない」という理由で後回しにされます。しかしシステムとして処理できなければ、その1〜2回のために業務が止まります。
通常フローの整理で精一杯：要件定義のヒアリングでは、まず「普通はどうやっているか」から始まります。正常系の整理だけで時間を使い切ってしまい、例外まで話が及ばないことがあります。
ベンダーも聞かない：ベンダーも例外を積極的に掘り起こさないケースがあります。例外を多く発見するほど実装範囲が広がり、コストも増えるため、無意識に後回しにされることがあります。
例外の種類
例外には大きく3つの種類があります。
1. 操作の例外
ユーザーが「正常でない操作」をした場合の対応です。
- 入力必須の項目を空のまま送信しようとした
- すでに削除された商品コードを入力した
- 権限のない操作をしようとした
- 同じ操作を二重に行った（ボタンを二度押した）
これらは「あってはならない操作」ではなく、「確実に起きる操作」です。対応が設計されていないと、システムが固まる・エラーが表示される・データが壊れるといった問題が起きます。
2. データの例外
想定外のデータが発生するケースです。
- 通常は数値が入る項目に0や負の値が入った
- 同じ顧客に複数の担当者が設定された
- 削除されるはずのデータが参照され続けている
- マスタデータが存在しない状態で処理が走った
「そんなデータは入らない」と思っていても、長期運用していると想定外のデータが生まれてきます。要件定義の段階でデータの境界値や禁止パターンを整理しておくと、実装時の考慮漏れを防げます。
3. 例外的なユーザー
通常とは異なる使い方をするユーザーの存在です。
- 複数の部署を兼任している社員
- 一時的な代理権限が必要な場面（担当者の長期休暇など）
- 外部スタッフや派遣社員など、正社員とは権限が異なるユーザー
- 複数の拠点を横断して管理する立場の管理者
こうした「例外的なユーザー」への対応を考えていないと、「自分の権限ではできないが、誰かに代わりにやってもらうしかない」という非効率な運用が生まれます。
例外を洗い出すための問いかけ
要件定義のヒアリングで例外を引き出すには、意識的な問いかけが必要です。
「〜できない場合は？」：「在庫が足りない場合はどうしますか」「承認者が不在の場合はどうしますか」
「〜が間違っていた場合は？」：「入力後にミスに気づいた場合はどうしますか」「送信してしまったものをキャンセルできますか」
「それ以外のパターンは？」：「通常はそうですが、例外的にこうなる場合はありますか」「この手順が使えない場面はありますか」
「過去にどんなトラブルがあったか」：現場のトラブル履歴は例外の宝庫です。「以前、これで困ったことがあって……」という話から重要な例外が出てきます。
例外をどこまで作り込むか
すべての例外に完璧に対応しようとすると、開発費と期間が無限に膨らみます。例外への対応にも優先順位が必要です。
判断の基準として、以下を参考にしてください。
- 発生頻度：月に何度も起きる例外は必ず対応する。年に1回のものは後回し可
- 業務への影響：例外が起きたときにシステムが止まる・データが壊れるリスクがあるなら対応必須
- 代替手段があるか：「システムで処理できない場合は電話で対応」という運用が成立するなら、対応を後回しにできる
完璧を目指すより「起きたとき業務が止まらない」ことを最低ラインとして、優先度を整理することが現実的です。
まとめ
例外は「ごく稀なケース」ではなく、現場では定期的に発生するものです。操作の例外・データの例外・例外的なユーザーの3種類を意識してヒアリングに臨み、「〜できない場合は？」「過去にどんなトラブルがあったか」という問いかけで洗い出します。すべてを作り込む必要はありませんが、例外への対応を考えないまま開発を進めると、リリース後の運用で必ず問題が出てきます。