要件定義で抜け漏れが起きる理由
――現場の暗黙知は、待っていても出てこない
「聞いたはずなのに、出てこなかった」
前回は、要求と要件の違いをテーマにお伝えしました。顧客は「要求」で話し、SEは「要件」で考える。この間に翻訳が必要であり、その翻訳を誰がどのタイミングで行うかが曖昧なまま進むことが、手戻りの原因になるという話でした。
今回はその前段にある問題を掘り下げます。そもそも、顧客から引き出すべき情報が十分に引き出せていない。この問題です。
第1回でお伝えしたとおり、暗黙知に起因する欠落は「書かれていないことが問題なのではなく、書くべきだったことを誰も認識していなかった」という状態です。自分のメモや議事録、要件定義書を何度読み返しても気づけない。欠落しているのは「言葉」ではなく「問い」だからです。
では、暗黙知はどこに潜んでいるのか。そしてどうすれば引き出せるのか。今回はこの2点を具体的に整理します。
暗黙知が潜みやすい場所
現場経験から、特に注意が必要な領域を7つ挙げます。ヒアリングの設計に、そのまま使えるチェックリストとして活用してください。
① 例外処理とエラーシナリオ
業務には必ず「通常ケース」と「例外ケース」があります。ヒアリングで自然に出てくるのは、ほとんどの場合「通常ケース」だけです。
「注文が入ったら在庫を確認して出荷する」という流れは説明できます。しかし「在庫がなかったとき」「支払いが遅延しているとき」「返品が発生したとき」という例外ケースは、聞かれなければ出てきません。
システムは例外ケースで壊れます。通常ケースだけ要件化されたシステムは、現実の業務に耐えられません。
② 権限とアクセス制御
「誰がどのデータを見られるか」「誰がどの操作を実行できるか」は、組織の中では暗黙のルールとして機能していることが多いです。「経理のデータは経理部しか見られない」は当然のことすぎて、ヒアリングで言及されないことがあります。
権限設計の抜け漏れは、セキュリティ上の問題に直結します。後から発覚したときのコストは特に高くなります。
③ タイミングと締め処理
「月末に何が起きるか」「年度末に何が変わるか」「決算期にどんな処理が走るか」——業務には時間軸に紐づいた特別な処理が必ずあります。これらは日常的な業務フローの説明では出てこないことが多く、「特定の時期に何が必要か」という問いを明示的に立てる必要があります。
④ 組織や取引先ごとの例外
「基本的にはこうだが、A社だけは違う」「通常はこの手順だが、このユーザーグループは別のフローを使う」
こうした例外は、業務に慣れた人間には当然のことですが、外部のSEには見えません。
第1回でお伝えした投資顧問会社の実話
「月間報告書は全部です」と確認を取ったにもかかわらず、A社向けの特殊書式が漏れていた。は、まさにこのパターンです。「全取引先で同じ処理ですか？」「例外的な対応が必要なケースはありますか？」という問いを、意図的に立てる必要があります。
⑤ 過去のトラブルから生まれたルール
長年の業務の中で発生したトラブルや失敗の経験から生まれたルールは、特に暗黙知化しやすいものです。「昔こういう問題があったから、この手順だけは必ず二重チェックする」というルールは、その背景を知っている人間には自明ですが、新しいシステムの要件として明示されないことがあります。
このタイプの暗黙知は、「なぜその手順になっているのか」という理由を聞くことで浮かび上がることがあります。「なぜ二重チェックしているのですか？」という問いが、過去のトラブルを引き出す入口になります。
⑥ 現場の運用実態と建前の乖離
マニュアルや規定に書かれていることと、実際の現場で行われていることが異なるケースがあります。「規定ではこうなっているが、実際はこうやっている」という状態です。
システムは実態に合わせて作る必要があります。建前だけをヒアリングしてシステムを作ると、誰も使わないシステムが出来上がります。「実際の現場ではどうやっていますか？」という問いを、規定の確認とは別に立てる必要があります。
⑦ ステークホルダーの網羅漏れ
要件定義のヒアリングに「誰が出てきているか」は、そのまま「誰の業務視点が反映されているか」に直結します。しかし、関係する部門の全員が打ち合わせに参加できるとは限りません。
あるプロジェクトで、こんなことがありました。本来ヒアリングに参加すべき部門の担当者が、多忙を理由に打ち合わせに出てこられない。代わりに別の部門長が「あちらの部門はこんな感じだと思います」と答えてくれていました。SEはその場にいる人がシステム全体の業務を把握していると思い込み、疑問を持ちませんでした。
システムが完成してから、その部門の実態とは大きく乖離していることが発覚しました。
この問題の厄介な点は、SEが「ステークホルダーが揃っていない」という事実自体に気づけないことです。誰が関係者で、誰がまだ話を聞けていないかを把握していなければ、欠落に気づくことができません。
ヒアリングの設計段階で「このシステムに関わる部門・役割は誰か」を明示的に洗い出し、全員から話を聞けているかを確認する必要があります。「打ち合わせに来た人の話を聞いた」と「必要なステークホルダー全員から話を聞いた」は、まったく別のことです。
暗黙知を引き出すためのアプローチ
潜んでいる場所が分かったとして、どうすれば引き出せるのでしょうか。有効なアプローチをいくつか紹介します。
「通常ケース」の後に「例外ケース」を必ずセットで聞く
「通常はどうやって処理しますか？」という問いの後に、必ず「例外的なケースはありますか？」「うまくいかないときはどうしますか？」という問いをセットで立てる習慣を持つことです。
通常ケースの説明が終わった段階で例外の問いを立てると、担当者の思考が「例外を思い出すモード」に切り替わりやすくなります。これだけで引き出せる情報の量は大きく変わります。
実際の業務を「見せてもらう」
口頭でのヒアリングだけでなく、実際の業務の手順を画面で見せてもらったり、現場で使っているExcelやメモを見せてもらったりすることで、言語化されていない知識が浮かび上がることがあります。
「このExcelのシートは何のためにありますか？」という問いが、新たな要件の発見につながることは少なくありません。特に、複雑なExcelが現場で使われている場合、そのExcelが担っている機能がそのままシステムの要件になることがあります。
「困っていること」「面倒なこと」を聞く
「現在の業務で困っていることは何ですか？」「手間がかかっている作業はどれですか？」という問いは、暗黙知を引き出す入口として有効です。
困りごとの背景には、現在の仕組みの欠陥があり、その欠陥を補うための暗黙のルールが存在していることが多いからです。「毎月末にこの作業だけ手作業でやっています」という話の裏に、システム化すべき要件が隠れていることがあります。
複数の担当者に同じことを聞く
一人の担当者へのヒアリングだけでは、その人が持っていない暗黙知は出てきません。同じ業務に携わる複数の担当者に話を聞くことで、一人では気づかなかった観点が出てくることがあります。
また、担当者によって説明が異なる場合、そこに業務ルールの曖昧さや矛盾が潜んでいることを示しています。矛盾自体が、重要な要件の発見につながることがあります。「誰に話を聞いたか」だけでなく、「話を聞けていない関係者がいないか」を常に意識することが重要です。打ち合わせに出てきた人が、システム全体の業務を把握しているとは限りません。
「他の人が同じ業務をするとしたら」という問いを使う
「あなたが急に休んで、別のスタッフがこの業務をやることになったとしたら、何を引き継ぎますか？」という問いは、暗黙知を言語化させる有効な手法です。
普段当たり前にやっていることを「他人に伝えるとしたら」という視点に切り替えることで、言語化されていなかった手順やルールが浮かび上がりやすくなります。「引き継ぎメモを書くとしたら何を書きますか？」という聞き方も同様の効果があります。
それでも、引き出しきれない
ここまでいくつかのアプローチを紹介しましたが、正直に言います。どれだけ工夫しても、すべての暗黙知を引き出しきることはできません。
理由は3つあります。
１つ目は、担当者自身が気づいていない暗黙知は、いくら聞いても出てこないということです。「当たり前すぎて言語化したことがない」知識は、問いを立てても引き出せないことがあります。
２つ目は、「何を聞くべきか」自体がSEの経験とドメイン知識に依存するということです。例外ケースを聞くにしても、「どんな例外が起きうるか」を予測できなければ、的外れな問いしか立てられません。初級SEはもちろん、ベテランSEでもドメインが変われば同じ問題に直面します。
３つ目は、ヒアリングには時間的・物理的な制約があるということです。すべての関係者から十分な時間をかけてヒアリングできるプロジェクトばかりではありません。
だからこそ、「引き出す努力」と同時に、「欠落を検出する仕組み」が必要です。
ヒアリングでどれだけ丁寧に情報を集めても、それが「十分かどうか」を判断する基準がなければ、完了の確認ができません。「聞いた」という事実と「必要な情報を引き出せた」という事実は、まったく別のことです。
引き出す努力を最大化しながら、それでも残る欠落をどう検出するか。この2つをセットで考えることが、要件定義における抜け漏れ対策の現実的なアプローチです。
AI時代における、この問題の変化
AIが下流工程を担う時代において、暗黙知の問題はさらに深刻になります。
これまでは、開発の途中で「あれ、この処理どうするんだっけ」という疑問が生じた際に、エンジニアが顧客に確認を取ることができました。人間が実装する過程で、要件の欠落に気づき、補完する機会があったのです。
AIが実装を担う場合、この補完が起きません。要件定義書に書かれていないことは、そのまま実装されません。例外処理が要件化されていなければ、例外が発生したときに何も起きない。あるいは予期しない動作をするシステムが生まれます。
暗黙知に起因する欠落は、AI時代においては「後から気づいて修正できる問題」から「最初から検出しなければならない問題」に変わりつつあります。
まとめ
暗黙知は、待っていても出てきません。潜みやすい場所を知り、能動的に引き出す工夫が必要です。
例外処理・権限・締め処理・取引先ごとの例外・過去のトラブル由来のルール・現場の運用実態・ステークホルダーの網羅
これらは、ヒアリングで意図的に問いを立てなければ出てこない領域です。「通常ケースの後に例外ケースを聞く」「実際の業務を見せてもらう」「複数の担当者に話を聞く」といったアプローチが有効です。
しかし、どれだけ工夫しても引き出しきれない暗黙知は残ります。だからこそ「引き出す努力」と「欠落を検出する仕組み」の両方が必要です。ヒアリングの質を上げることと、その結果の品質を客観的に測ることは、セットで考える必要があります。
この問題に、仕組みで向き合うツールがあります。
AiRee（アイリー）は、要件定義の完了度をスコアで可視化するAIプラットフォームです。「勘」に頼らず、構造的な欠落を検出します。
現在（2026年7月31日まで）、10社限定で無償トライアルを受付中です。
［先行トライアルに応募する →］ ［資料をダウンロードする →］
最後までご覧いただきありがとうございました。
メルマガ登録をしていただければ、コラムが更新された時にお知らせします。
また、AI要件定義プラットフォーム AiRee（アイリー）の情報も合わせてお届けします。