打ち合わせには毎回出ているのに、納品されたシステムが「現場の本当の業務を分かっていない仕様」になっている——中小企業のシステム開発で頻発する悲劇です。原因の多くはシステム会社のヒアリングが浅く、業務の表面だけをなぞって要件定義に落としたことにあります。ヒアリングが浅いと、リリース後に「これでは使えない」が連発し、大規模な作り直しか諦めかの選択になります。本記事では浅いヒアリングの典型パターンと、発注側が誘導すべき深掘りポイントを経営者目線で整理します。

この記事の結論(3行)

  • ヒアリング不足は「現場を訪問しない」「業務時系列を聞かない」「例外パターンを聞かない」の3つで完成する
  • 発注側は受け身で待たず、「現場見学」「1日の業務時系列」「例外20パターン」を自ら提示することで深掘りを誘導できる
  • ヒアリングの深さは見積もり段階で判別可能。提案資料に業務理解の痕跡があるかをチェックすべき
表面的なヒアリングしかできていないベンダーと、現場の実態が伝わらない発注者のイメージ

なぜシステム会社のヒアリングは浅くなりがちなのか

システム会社のヒアリングが浅くなるのは、ベンダーの怠慢だけが原因ではありません。発注側と開発側の双方に、ヒアリングを浅くしてしまう構造的な要因があります。中小企業の案件では特にこの構造が表面化しやすく、結果として「業務を知らない開発」が量産されます。

  • 限られた商談時間で要件をまとめようとする
  • 業務担当者ではなく経営者だけと話してしまう
  • 「動いているシステムを真似ればいい」と考えてしまう

この3つが重なると、ヒアリングは「打ち合わせを2〜3回した」レベルで終わってしまい、現場の本当の動きが伝わらないまま要件定義に進みます。

限られた商談時間で要件をまとめようとする

ベンダーは契約前の商談段階で見積もりを出す必要があり、ヒアリング時間が十分に取れません。1〜2時間の打ち合わせ2〜3回で要件をざっくり把握し、見積もりを提示する流れになります。この段階では業務の表面しか分からないため、見積もりも誤差が大きくなり、後で「想定外」が次々と出てきます。

業務担当者ではなく経営者だけと話してしまう

ベンダーの営業は、決裁権を持つ経営者と話したがります。一方で実際にシステムを使うのは現場の担当者です。経営者の話だけで要件定義をまとめると、「経営者は知らない現場のルール」が要件から抜け落ちます。「請求書は月末に出すが、特定の取引先だけ20日締め」「在庫の棚卸しは月1だが、特定商品だけ週1」のような現場ルールが、リリース後に問題として浮上します。

「動いているシステムを真似ればいい」と考えてしまう

既存システムの置き換え案件では、「いまのシステムを見れば分かる」と考えるベンダーが多くいます。しかし既存システムには「使われていない機能」「使われ方が当初の想定と違う機能」「現場の独自運用で回避されている機能」が混在しています。表面だけ真似すると、こうした実態が反映されず、リリース後に現場から拒絶されます。

ヒアリング不足が招く5つの悲劇

浅いヒアリングがもたらす具体的な悲劇を、5つのパターンで整理します。どれも中小企業の現場で頻発しているものです。

| 悲劇のパターン | 症状 | 後の追加コスト | 防止策 | |---|---|---|---| | 現場拒絶型 | リリース後に現場が使ってくれない | 業務再ヒアリング+改修50〜200万円 | 現場担当者を要件定義に巻き込む | | 例外処理欠落型 | 通常パターンしか動かない | 例外分岐の追加開発30〜100万円 | 例外パターンを20件以上洗い出す | | 業務フロー逆行型 | システムの順番が業務と合わない | 業務フロー再設計+改修100〜300万円 | 1日の業務時系列をヒアリング | | 帳票ずれ型 | 帳票の項目や様式が業務と違う | 帳票改修1帳票あたり5〜15万円 | 現行帳票のサンプルを共有 | | データ移行不能型 | 既存データが新システムに乗らない | 移行スクリプト追加50〜200万円 | データ実物のサンプルを共有 |

5つの悲劇は、いずれも発注前のヒアリング段階で防げます。発注側の責任で防げる部分が大きく、ベンダー任せにしないことが重要です。自社の案件でこれらの悲劇を防げる状態かを確認したい場合は、業務改善・システム見積もりAI適正診断で個別に整理できます。

悲劇1: 現場拒絶型

リリース後に現場担当者が「これでは仕事にならない」と使ってくれず、結局元のExcelやAccessに戻ってしまうパターンです。原因は要件定義に現場担当者が一切関わっていなかったこと。経営者と情報システム部だけで要件を決めた結果、現場の細かい運用ルールが反映されず、システムが浮いてしまいます。投資した数百万円が事実上の死蔵となり、半年後にもう一度同じ予算を組み直すか、運用を諦めるかの二択になります。

悲劇2: 例外処理欠落型

通常パターンの業務は動くのに、例外的なパターン(イレギュラーな顧客、特殊な取引条件、月末の特殊処理など)が一切想定されていないパターンです。実業務では2〜3割が例外パターンなので、これに対応できないと現場の作業効率はむしろ下がります。例外パターンの追加開発が後から30〜100万円乗ります。

悲劇3: 業務フロー逆行型

システムの画面遷移や入力順序が、現場の業務フローと逆行しているパターンです。「現場では先に在庫確認してから受注を入力するのに、システムは受注を先に入力させる」のような事態。1日の業務時系列をヒアリングしていれば防げますが、機能仕様だけ聞いて作るとこのズレが頻発します。現場では1件あたり数十秒の操作差が、年間で数百時間のロスに直結します。改修費用とは別に、現場担当者の業務効率低下による機会損失が積み重なる点が、このパターンの本当の怖さです。

悲劇4: 帳票ずれ型

帳票の項目・様式・並び順が、業務で使っているものと違うパターンです。請求書・納品書・月次集計表など、業務の対外的なやり取りに使う帳票がずれていると、取引先からクレームが入ります。現行帳票のサンプルを発注前に共有していれば、ほぼ防げる失敗です。

悲劇5: データ移行不能型

既存データが新システムに乗らないパターンです。データ項目の不一致、文字コードの違い、桁数の超過、必須項目の欠落——こうした要素が積み重なり、移行スクリプトが破綻します。発注前にデータの実物サンプル100件をベンダーに共有していれば、見積もり段階で発覚できる問題です。10年単位で蓄積されたデータには、初期設計時には想定していなかった揺れが必ず含まれており、サンプルを開いて初めて見える問題があります。

5つの悲劇パターンを示す比較図

経営者目線で考える「ヒアリングの深さの見極め方」

ここからは経営の話です。ヒアリングが浅いベンダーかどうかは、契約前の見積もり段階である程度判別できます。経営者がヒアリングの深さを見極める3つの観点を持っておくと、「業務を知らない開発」を未然に防げます。

第一に、「現場見学を提案してきたか」。提案資料を作る前に「実際に現場を見せてほしい」と申し出てくるベンダーは、業務理解に重きを置いています。一方で、最初の打ち合わせ後すぐに見積もりが出てくるベンダーは、表面理解で要件をまとめている可能性が高いと言えます。第二に、「業務担当者との打ち合わせを希望したか」。経営者だけとの打ち合わせで満足するベンダーは、現場の実態を聞く意思が薄いと判断できます。第三に、「例外パターンを質問してきたか」。「月末の特殊処理は?」「イレギュラーな取引先は?」「過去の例外事例は?」などを質問してくるベンダーは、リリース後の使われ方を想像できています。

この3つの観点でベンダーの行動を観察すると、契約前の段階で「業務理解の深さ」が見えてきます。安価な見積もりに飛びついて後で大規模な作り直しになるより、ヒアリングが深いベンダーに少し高めの見積もりを支払うほうが、トータルコストは下がります。

ぷらすわんの実例:建築・建設業マッチング「けんぞくん」での深掘りヒアリング

ぷらすわんが手掛けた「けんぞくん」の事例をお伝えします。けんぞくんは建設業界のマッチングプラットフォームで、57機能・30.8人月という規模感。市場相場では2500〜4000万円のところを2000万円規模で立ち上げました。

このプロジェクトでコストを抑えながら現場で使われるシステムを作れた要因の1つが、深掘りヒアリングです。発注前の段階で、建設会社の現場事務所に複数回足を運び、見積もり依頼から契約までの業務フローを丸1日観察しました。その中で発覚したのが、「電話とFAXとメールが混在した発注経路」「現場監督が手書きで管理している進捗表」「下請けへの発注書を手書きで書いている事務員」など、教科書通りのシステム設計では対応できない現場の実態です。

これらをヒアリングで把握できたから、57機能の中身が「現場が実際に使う機能」だけで構成されたシステムを30.8人月で組み上げられました。表面ヒアリングだけで進めていたら、機能数は同じでも現場が使わないシステムになり、リリース後に2〜3回の改修が必要だったでしょう。発注前にヒアリングの深さを項目別に整理したい場合は、現状を整理してから比較するのが現実的です。

建設業の現場事務所で深掘りヒアリングを行う様子をイメージ

ベンダーのヒアリングを深めるための5つの誘導方法

ベンダー任せにせず、発注側からヒアリングを深めるための5つの誘導方法を整理します。

  • 初回打ち合わせ前に「現場見学」を提案する
  • 「1日の業務時系列」をヒアリング項目に追加する
  • 「例外パターン20件」を発注側で洗い出して共有する
  • 業務担当者を打ち合わせに必ず同席させる
  • 現行データのサンプル100件と現行帳票を事前共有する

この5つは、どれも発注側がリードできる項目です。受け身でヒアリングを待つのではなく、こちらから材料を提供することで、ヒアリングの深さは2〜3倍に上がります。

初回打ち合わせ前に「現場見学」を提案する

ベンダーとの初回打ち合わせの前に、「弊社の現場を一度見ていただきたい」と提案してください。半日から1日程度、現場での業務を観察してもらうだけで、その後の打ち合わせの質が大きく変わります。見積もり提示前にこのプロセスを入れるベンダーは、業務理解への意欲が高いと判断できます。

「1日の業務時系列」をヒアリング項目に追加する

機能仕様の説明ではなく、「現場担当者の1日のスケジュール」をヒアリング項目に追加してください。朝の出社から退社まで、何時に何をするかを時系列で説明することで、業務フロー逆行型の失敗を防げます。これだけでヒアリングの深さが大きく変わります。

「例外パターン20件」を発注側で洗い出して共有する

業務で発生する例外パターンを20件以上、発注側で事前に洗い出してベンダーに共有してください。「特定取引先だけ請求条件が違う」「月末の特殊処理」「イレギュラーな返品対応」など、現場で起きる例外をリスト化しておくと、例外処理欠落型の失敗を未然に防げます。

業務担当者を打ち合わせに必ず同席させる

経営者だけでなく、実際にシステムを使う業務担当者を打ち合わせに同席させてください。担当者が話す現場の細かい運用ルールは、経営者が把握していないものが多くあります。この同席があるかないかで、リリース後の現場拒絶リスクが大きく変わります。

現行データのサンプル100件と現行帳票を事前共有する

現行システムまたはExcelのデータサンプル100件と、現在使っている帳票のサンプルをベンダーに事前共有してください。データ移行不能型と帳票ずれ型の失敗が、これだけでほぼ防げます。発注前の見積もり段階で他社と比較を依頼する場合も、このサンプルを共有した上で比較すると精度が上がります。

まとめ

システム会社のヒアリング不足は、「現場拒絶」「例外処理欠落」「業務フロー逆行」「帳票ずれ」「データ移行不能」の5つの悲劇を招きます。これらを防ぐには、ベンダー任せにせず発注側から「現場見学」「1日の業務時系列」「例外パターン20件」を提示し、深掘りヒアリングを誘導することが効きます。

ヒアリングの深さは、契約前の見積もり段階で見極めることができます。安価な見積もりに飛びつくより、深く聞いてくるベンダーを選んだほうが、トータルコストは下がります。発注前にベンダーのヒアリング姿勢を診断することで、業務を知らない開発を未然に防げます。