要件定義で見落としがちな例外処理を生成AIで洗い出す手順
こういった経験ないですか？
通常の業務フローは聞けたのに、「その場合はどうするの？」と後から例外が出てくる
要件定義書では「登録する」と書いたものの、重複登録や入力途中の離脱時の扱いが決まっていない
利用部門とのレビューでは問題なさそうだったのに、テスト工程で運用上の穴が見つかる
ベテラン担当者が暗黙に処理している判断が、資料には一切書かれていない
実は、例外処理の見落としは「確認が足りない」というより、確認する観点を最初から持てていないことが原因かもしれません。
要件定義では、まず通常どおりに進むケースを整理します。ただ、実務で困るのはたいてい通常どおりに進まなかったときです。入力内容が不足していたとき、申請者が途中で変更になったとき、連携先が止まっていたとき。こうした場面を一人で思いつくのは、意外と難しいものです。
そこで私は、業務フローのたたきを生成AIに渡し、「例外になりそうな場面」を質問リストに変えてもらうことがあります。AIに要件を決めてもらうのではなく、利用部門に確認すべき論点を増やすために使うイメージです。
この記事を読むと、通常フローしかない状態から、例外処理を確認するための質問リストを作れるようになります。今日の要件確認やレビュー前に、10分ほどで試せる方法です。
例外処理は「機能」ではなく「業務の変化」から考える
例外処理というと、エラー画面やバリデーションを想像しがちです。でも要件定義で先に確認したいのは、システムの動きよりも業務側の変化です。
たとえば、経費精算の申請機能を考えてみます。
通常フローは、次のように書けます。
社員が申請を入力する
上長が承認する
経理が確認する
支払データを作成する
このままでも流れは分かりますが、実際には次のような場面があります。
申請後に上長が異動・退職したら、誰が承認するのか
差し戻し中に申請者が内容を修正したら、承認は最初からやり直すのか
支払データ作成後に金額の誤りが判明したら、取り消せるのか
経理担当者が休みの場合、確認作業を引き継げるのか
添付した領収書の画像が読めない場合、どの時点で誰が連絡するのか
ここで大事なのは、「システムでどう実装するか」を急いで決めないことです。先に業務として誰が何を判断し、どこまで戻せるべきかを確認します。この順番にすると、利用部門との会話が具体的になります。
生成AIには「抜けを指摘して」ではなく、役割を渡す
「この要件の抜け漏れを指摘して」とだけ聞くと、AIの回答は広すぎたり、一般論になったりします。
使いやすいのは、AIにレビュー担当の役割と、見てほしい観点を渡す方法です。通常フローをそのまま貼り付けて、次のテンプレートを使ってみてください。
あなたは業務システムの要件定義を支援するSEです。
以下の通常業務フローを読み、利用部門に確認すべき
「例外・判断が必要な場面」を洗い出してください。
特に次の観点で考えてください。
- 担当者や承認者の変更・不在
- 入力ミス、重複、差し戻し、取り消し
- 締切や処理期限
- 外部システム連携の失敗・遅延
- 権限不足、閲覧範囲、引き継ぎ
出力は表形式にしてください。
列は「想定される場面」「確認したい質問」「決めるべきこと」です。
推測で仕様を決めず、確認質問として書いてください。
【通常業務フロー】
（ここに現在のフローやメモを貼る）
最後の「推測で仕様を決めず、確認質問として書いてください」は入れておくのがおすすめです。AIはもっともらしい運用案まで書いてくれますが、その案が自社に合うとは限りません。要件定義の段階では、答えを作るより、確認漏れを防ぐほうが先です。
出力をそのまま要件にしないための見方
AIが出した質問リストは便利ですが、全部を採用する必要はありません。私は次の3つに分けて見ています。
必ず確認するもの：現場で発生しそうで、放置すると処理が止まるもの
運用で吸収できるもの：頻度が低く、手順書や担当者判断で対応できるもの
今回の対象外にするもの：将来的には必要でも、今回の改修範囲では扱わないもの
たとえば「承認者が不在の場合」は、ほぼ必ず確認が必要です。一方で「添付ファイルが破損している場合」の対応は、既存の問い合わせ窓口で運用できるかもしれません。
この仕分けをせずにAIの出力を要件定義書へ貼ると、論点だけが増えて、プロジェクトが進みにくくなります。AIの役割は要件を膨らませることではなく、決めるべきことを見えるようにすることです。
利用部門への確認は「もし〜なら」で聞く
質問リストを持って打ち合わせに行くときは、専門用語のまま聞かないほうが会話が進みます。
たとえば「承認経路の例外処理を定義してください」ではなく、こう聞きます。
申請を出したあとに上長が異動した場合、この申請は誰に承認してもらう運用ですか？
経理確認のあとで金額の誤りに気づいた場合、申請者自身で修正できますか？ それとも経理側で差し戻しますか？
「もしこの状況になったら」と具体的な場面を置くと、現場の担当者も実際の経験を思い出しやすくなります。すると、「年に数回だけど、そのときは総務にメールしている」といった、資料には載っていない運用が出てきます。
ここで聞けた内容は、システム要件だけでなく、運用ルールや権限設計の材料にもなります。
まずは1つの業務フローだけで試す
最初から大きな業務全体をAIに渡すと、質問が多すぎて扱いにくくなります。まずは「申請」「承認」「登録」など、1つの小さなフローで十分です。
私なら、次の順で進めます。
現在の通常フローを5〜10行で書く
テンプレートに貼り、例外確認の質問を出す
出力から重要そうな3件だけ選ぶ
利用部門との次回確認で「もし〜なら」と質問する
決まった内容だけを要件・運用ルールへ反映する
注意点として、社外秘の情報や個人情報をそのまま外部の生成AIサービスへ入力してよいかは、必ず自社のルールを確認してください。案件名、氏名、取引先名、金額などは伏せて、業務構造だけを抽象化して試す方法でも十分使えます。
まとめ
生成AIは、要件定義の正解を出してくれる道具というより、「聞きそびれていた質問」に気づかせてくれる壁打ち相手です。
通常フローを作ったら、次は例外になりそうな場面を確認する。このひと手間を入れるだけで、後工程での「それは想定していませんでした」を減らしやすくなります。
次の要件確認では、まず1つのフローをテンプレートに貼ってみてください。AIの出力を答えとして採用するのではなく、利用部門に聞くための質問集として使うのがコツです。
