AI開発で「動いたが使われない」という結果になる大きな原因の一つが、要件と現場業務のずれである。経営層や管理部門の要望だけで要件を固め、実際にその業務を行う現場のヒアリングが不足すると、現場の実態に合わないものができあがる。
本記事では、現場ヒアリング不足で要件がずれる問題を発注者の視点で整理し、発注前に確認すべき項目と開発会社への質問を示す。要件のずれは、開発が進むほど修正コストが大きくなる。発注前と要件定義の段階で、誰に何を聞くかを設計しておくことが重要である。聞く相手と聞く内容を間違えると、丁寧にヒアリングしても要件はずれてしまう。誰に、何を、どの順で聞くかを設計することが、現場で使われる要件をつくる第一歩になる。
結論：要件定義では現場の例外、承認、KPIを先に聞く
AI開発の要件がずれる最大の原因は、要望を出す人と実際に使う人が違うことにある。GXOが要件整理で重視するのは、現場の例外処理、承認フロー、既存システム、改善したい業務KPIを、発注前から聞ける状態にすることである。
- 経営層、管理部門、現場担当者の認識差を確認する
- マニュアルにない例外と二重入力の発生箇所を聞く
- 処理時間、件数、ミス率など、効果測定の指標を決める
この情報がないまま仕様を固めると、技術的には動いても現場で使われない要件になりやすい。
MANUFACTURING DX
Excel限界から受発注システムへ、同規模の概算は？
中小製造業の概算費用・導入期間・役割分担マトリクスをその場で確認。要件整理テンプレも無料提供します。
要件がずれると、どこに表れるか
要件と現場のずれは、次のような形で表面化する。
- 現場の例外的なケースに対応できず、結局は手作業が残る
- 承認のフローが実態と違い、運用に乗らない
- 既存システムとの連携が想定と違い、二重入力が発生する
- 評価の指標が現場の感覚と合わず、「精度が高い」と言われても使えない
- 現場が「自分たちは聞かれていない」と感じ、導入に協力的でなくなる
これらは技術的な不具合ではなく、要件の出発点がずれていることに起因する。
なぜ現場ヒアリングが不足するのか
要望を出す人と、業務を行う人が違う
AI導入の要望は、経営層やDX担当から出ることが多い。一方、実際にその業務を行うのは現場である。両者の間に認識の差があると、要望どおりに作っても現場では使えない。
例外処理が見えていない
業務には、マニュアルに書かれていない例外が必ずある。「この取引先だけは別の手順」「この条件のときは上長が判断」といった例外は、現場に聞かないと出てこない。例外を無視した要件は、現場で破綻する。
既存システムとの関係が把握されていない
現場は複数のシステムを使い分けている。新しいAIがそこにどう組み込まれるかを把握せずに要件を固めると、連携できずに二重入力が発生する。
業務KPIと結びついていない
「AIで効率化したい」という要望が、現場のどの指標（処理件数、時間、ミス率など）を改善するのかと結びついていないと、効果を測れず、改善の方向も定まらない。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
ヒアリング不足で起きるずれと、その対策
| ずれの種類 | 具体例 | ヒアリングで確認すべきこと |
|---|---|---|
| 例外処理 | 特殊な取引先・条件への対応漏れ | 現場の「例外」「イレギュラー」 |
| 承認フロー | 実態と違う承認経路 | 誰が、何を、どの順で承認するか |
| 既存システム | 連携できず二重入力 | 現場が使うシステムと操作 |
| 業務KPI | 効果を測れない | 改善したい指標と現状値 |
| 利用シーン | 使うタイミングが合わない | いつ、どの場面で使うか |
これらは現場に聞かなければ出てこない情報である。発注前に「誰に聞くか」を決めておきたい。
現場ヒアリングで使える質問例
現場ヒアリングは、長時間かけなくても、聞くべき点を押さえれば要件のずれを大きく減らせる。次のような質問は、短い時間でも実態を引き出しやすい。
- この業務で、マニュアルどおりに進まないのはどんなときですか（例外を引き出す）
- 「これは面倒だ」と感じる作業はどれですか（改善の優先度が見える）
- 判断に迷ったとき、誰に確認しますか（承認や相談の経路が分かる）
- いま、どのシステムや画面を、どの順で使っていますか（既存システムとの関係）
- この作業のミスは、どんなときに、どのくらい起きますか（業務KPIの手がかり）
- もしAIが手伝うなら、どの作業を任せたいですか（現場の期待を知る）
これらは「正解」を聞く質問ではなく、現場の実態と困りごとを引き出す質問である。回答の中に、要件に反映すべき例外や制約が含まれていることが多い。
ヒアリングでは、要望を出した人と現場の認識が食い違う場面にも注目したい。たとえば、管理部門は「効率化」を求めているが、現場は「ミスを減らしたい」と考えている、といったずれである。このずれを早く見つけられると、要件の優先順位を正しく設定できる。ヒアリングの目的は、現場を問い詰めることではなく、業務の実態を一緒に言語化することにある。現場が「自分たちの業務として相談できた」と感じられると、導入後の協力も得やすくなる。
発注前に確認すべき項目
- 要望を出す人と、実際に業務を行う現場担当者を区別したか
- ヒアリング対象に、現場の実務担当者を含めたか
- 現場の例外・イレギュラーな対応を洗い出す機会を設けたか
- 承認フロー（誰が、何を、どの順で承認するか）を確認したか
- 現場が使っている既存システムと、その操作を把握したか
- 改善したい業務KPI（件数、時間、ミス率など）と現状値を確認したか
- AIを使う具体的な場面（いつ、どこで）を現場と共有したか
開発会社に確認する質問
| 質問 | 確認したいこと |
|---|---|
| 要件定義で現場の誰にヒアリングしますか | 現場に踏み込むか |
| 例外処理はどう洗い出しますか | イレギュラーを拾う方法 |
| 既存システムとの連携はどう確認しますか | 連携の調査範囲 |
| 業務KPIはどう設定しますか | 効果測定の前提 |
| 要件がずれたとき、どの段階で気づけますか | 手戻りを防ぐ仕組み |
要件定義を「発注者が書いた仕様の確認」だけで済ませる会社より、現場に入って業務を理解しようとする会社のほうが、ずれは小さくなる。
GXOに相談する前に整理するとよい情報
- 改善したい業務と、それを実際に行っている担当者
- その業務の標準的な流れと、よくある例外
- 関係する承認の経路
- 現場が使っているシステム
- 改善したい指標（件数、時間、ミス率など）と、現状のおおよその数値
現場の実態が共有されていると、要件定義の段階で「使われない要件」を避けやすくなる。要件をRFPに落とす観点はAI開発のRFPに入れるべき項目も参考になる。
これらが整理されていなくても相談は可能である。改善したい業務と、その業務を担う現場担当者が見えていれば、誰に何を聞くかの設計から一緒に進められる。
参考にした外部観点
現場ヒアリングはAI開発だけの作業ではなく、DXを進めるための認識合わせでもある。IPAのDX推進指標は経営者や関係者が現状や課題を共有するための観点を提供しており、NIST AI Risk Management FrameworkはAIリスクを組織で管理する枠組みを示している。
要件定義前には、現場担当者3人以上、例外処理10件、直近30日分の実作業、3ヶ月後に改善したいKPI、1年続く運用体制を確認すると、要件のずれを見つけやすい。
関連記事
よくある質問
Q1. 現場が忙しく、ヒアリングの時間を取れません
短時間でも、実務担当者数名から「例外」と「困りごと」を聞くだけで、要件のずれは大きく減る。全工程を聞く必要はなく、つまずきやすい箇所に絞ると効率的である。
Q2. 現場ヒアリングは開発会社に任せてよいですか
開発会社に任せてよいが、発注者側も「誰に聞くべきか」を示し、現場が協力できる体制を作る必要がある。現場が「自分たちの業務だ」と感じられると、導入後の定着も進みやすい。
Q3. 要件は最初に全部固めるべきですか
すべてを最初に固めるより、現場と確認しながら段階的に詰めるほうが、ずれに早く気づける。PoCや小規模な検証を挟む進め方が有効である。
Q4. ヒアリングの結果は、どうやって要件に反映すればよいですか
聞き取った内容は、「対応すべき例外」「残すべき人の判断」「連携が必要なシステム」「改善したい指標」といった観点で整理すると、要件に落としやすい。すべてを実装対象にする必要はなく、優先度を付けて、まず効果の大きいものから要件に含めるとよい。整理した内容は現場にも共有し、認識のずれがないかを確認しておくと、後の手戻りを防げる。
Q5. 要件は一度固めたら、変えないほうがよいですか
AI開発では、検証しながら要件を調整するほうが現実的である。最初にすべてを固めようとすると、現場で使ってみて初めて分かるずれに対応できない。PoCや小規模な検証を挟み、現場の反応を見て要件を見直す前提で進めると、ずれを早い段階で修正できる。要件を変えること自体は失敗ではなく、ずれに気づけたという前進である。重要なのは、変更の理由と影響を関係者で共有し、際限なく広がらないように範囲を管理することである。
現場に合う要件を、発注前に整理しませんか
GXOでは、現場ヒアリングの対象、例外処理、承認フロー、既存システム、業務KPIを整理し、使われるAI開発の要件定義を支援します。
※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。