約75%が「開発前のユーザー確認が不足していた」と実感!”使われないシステム・アプリ”を生む開発前ギャップの実態を調査
新規システム・アプリの開発後、「期待したほど現場で使われなかった」という経験を持つ開発担当者は少なくありません。
業務効率化やDX推進を目的に開発したにもかかわらず、「一部の機能しか活用されない」「特定の部署でしか利用が広がらない」、あるいは「Excelなどの従来手法に戻ってしまう」など、こうした『開発前の想定』と『導入後の現実』のギャップは、多くの開発現場に共通する課題です。
株式会社Engineerforceでは、こうした実態を明らかにするため、新規システム・アプリの開発プロジェクトに携わった経験を持つビジネスパーソン75名を対象に、「システム・アプリ開発前後のギャップ」に関するアンケート調査を実施しました。
調査の結果、新規システム・アプリの導入後、約4割(44%)が「想定より使われなかった」と回答しました。
さらに、開発担当者の約75%(74.7%)が「開発前のユーザー調査・ニーズ確認が不足していた」と実感しており、開発プロセスにおけるユーザー検証の不足が、「使われないシステム・アプリ」を生む大きな要因であることが浮き彫りになっています。
本記事では、調査データをもとに「システム・アプリが使われない原因」を構造的に整理し、開発前に取り組むべきポイントを明らかにしています。
新規開発を控えている方や、導入済みシステム・アプリの利用率に課題を感じている方にとって、次のプロジェクトで同じ失敗を繰り返さないための判断材料としてご活用ください。
調査概要
株式会社Engineerforceは、新規システム・アプリの開発・導入後に生じる「想定と現実のギャップ」の実態を明らかにするため、開発プロジェクトの経験者を対象にアンケート調査を実施しました。
【調査概要】
| 項目 | 内容 |
| 調査対象 | 新規システム・アプリの開発プロジェクトに携わった経験を持つビジネスパーソン75名 |
| 調査方法 | インターネットアンケート調査 |
| 実施期間 | 2026年10月7日〜2026年10月16日 |
| 調査機関 | 株式会社Engineerforce |
※本調査では、社内向け業務システム・顧客向けサービスアプリなど、種類を問わず「新規に開発したシステム・アプリ」を対象としています。回答はいずれも、直近で携わったプロジェクトについてのものです。
新規システム・アプリの導入後、約4割が「想定より使われなかった」と回答
新規システム・アプリの導入後、利用状況が想定を下回ったと感じている開発担当者は約4割(44%)にのぼることがわかりました。
導入後の利用状況について「開発・導入前の想定と比べてどうだったか」を聞いたところ、「おおむね想定通りだった」が45.3%で最多となった一方、「想定をやや下回った」が40%、「想定を大きく下回った」が4%と、合計44%が想定を下回る結果に直面しています。

「想定通り」と「想定を下回った」がほぼ同じ割合で並んでおり、新規システム・アプリの開発は、約2人に1人が利用状況に何らかの課題を抱える可能性があるといえます。
想定を上回った割合はわずか6.7%にとどまっており、開発前の見込みを超えて活用されるケースは決して多くありません。
最多は「一部の機能しか使われなかった」
システム・アプリが「使われなかった」といっても、完全に利用されなかったわけではないケースが大半です。具体的な状況を聞いたところ、最多は「一部の機能しか使われなかった」(28%)でした。

注目すべきは、上位の回答がいずれも「まったく使われなかった」ではなく、「部分的にしか活用されなかった」という状況を示している点です。
開発したシステム・アプリ自体は導入されているものの、一部の機能に利用が偏る、一部の部署でしか使われない、あるいはExcelなどの従来手法と併用されてしまうといった「中途半端な利用」が実態として多く発生しています。
実際に、自由回答でも以下のような声が寄せられました。

こうした声からも、「使われない」問題の多くは、全否定ではなく『部分的な活用不足』として現れていることがわかります。
利用が伸びなかった背景には「オンボーディング」「業務フロー」「操作性」の課題がある
システム・アプリが想定どおりに利用されなかった理由として最も多かったのは、「導入時の説明・マニュアル・オンボーディングが不足していた」(21.3%)でした。

この結果から、利用が伸びなかった理由は大きく3つの領域に整理できます。
| ①オンボーディングの課題(21.3%) | ・システム・アプリ自体の品質ではなく、導入後の「届け方」に問題があったケース ・使い方や導入メリットが伝わらなければ、利用は定着しない |
| ②業務フローとのミスマッチ(18.7%) | ・開発前に想定した利用シーンと現場の業務プロセスにズレがあったケース ・ワークフローを把握しないまま設計すると、ユーザーにとって「余計な手間が増えるシステム」になりかねない |
| ③操作性・機能設計の課題(18.7%+17.3%) | ・画面のわかりにくさや不要な機能の盛り込みすぎに起因するケース ・前項で「一部の機能しか使われなかった」が最多だった結果と直結しており、機能を増やすこと自体が利用のハードルを上げている構図がある |
これら3つの課題に共通するのは、いずれも「開発前にユーザーの実態を把握していれば防げた可能性がある」という点です。
次の章では、開発前のユーザー検証がどの程度行われていたのか、その実態を掘り下げます。
システム・アプリの開発担当者、約75%が「開発前のユーザー調査・ニーズ確認が不足していた」と実感
開発・導入後に振り返った結果、開発担当者の約75%(74.7%)が「開発前のユーザー調査やニーズ確認が不足していた」と感じていることがわかりました。
開発後にユーザー調査の不足を感じたかを聞いたところ、「やや感じた」が60%で最多、「強く感じた」が14.7%と続き、合計74.7%が不足を実感しています。

「あまり感じなかった」「まったく感じなかった」と回答した割合は合計25.3%にとどまっており、4人に3人が「もっとユーザーの声を確認しておくべきだった」と感じている計算になります。
前章で見た「約4割が想定を下回った」という結果と合わせると、開発担当者自身が「利用されなかった原因は開発前の検証不足にある」と認識していることがうかがえます。
開発前に十分なユーザー確認を行っていたのは約1割
開発前にユーザーの声をどの程度確認していたかを聞いたところ、「複数の方法を使って十分に確認していた」と回答したのはわずか12%(約1割)にとどまりました。

最多は「一部のユーザーには確認していた」(37.3%)ですが、これは十分な検証とはいえません。
「社内メンバー中心」(28%)と「ほとんど確認せず」(6.7%)を合わせると、約7割(72%)が実際のユーザーの声を十分に反映できていない状態で開発を進めていたことになります。
さらに注目すべきは、開発前のユーザー確認の程度と、導入後の利用状況に明確な相関がある点です。
【開発前の確認度合い別】導入後の利用状況
| 開発前の確認度合い | 想定を下回った | おおむね想定通り | 想定を上回った |
| 十分に確認(n=9) | 11.1% | 88.9% | 0% |
| インタビュー・テスト実施(n=12) | 33.3% | 50.0% | 16.7% |
| 一部ユーザーに確認(n=28) | 57.1% | 32.1% | 7.1% |
| 社内関係者中心(n=21) | 42.9% | 47.6% | 0% |
| ほとんど確認せず(n=5) | 60.0% | 20.0% | 20.0% |
※「想定を下回った」は「大きく下回った」と「やや下回った」の合計。「利用状況を把握していない/判断できない」の回答を含めて算出しているため、各行の合計は100%になりません
「十分に確認していた」群は、88.9%が「おおむね想定通り」と回答し、想定を下回ったのはわずか11.1%です。一方、「一部ユーザーに確認」にとどまった群は57.1%が想定を下回り、「ほとんど確認していなかった」群では60%が想定を下回る結果となりました。
このデータは、開発前にユーザーの声をどれだけ確認したかが、導入後の利用状況を大きく左右することを示しています。
「十分に確認した」と「一部確認した」の間には、結果に約5倍の差(11.1% vs 57.1%)が生まれており、『確認したつもり』と『十分な確認』の間にある溝は想像以上に深いといえます。
検証を省いた最大の理由は「スケジュールに余裕がなかった」
ユーザーの意見を十分に取り入れられなかった理由として、最も多かったのは「開発スケジュールに余裕がなかった」(38.7%)でした。

約4割がスケジュールの制約を挙げている点は、ユーザー検証の重要性を理解していても実行に移せない構造的な問題を示しています。
リリース日や納期が先に決まっている開発プロジェクトでは、検証工程が「削れる工程」として扱われやすく、結果としてユーザーの声を聞かないまま開発が進んでしまう実態があります。
2番目に多かった「経営層・責任者が決めた要件を優先する必要があった」(22.7%)も、意思決定者の判断が優先されることで現場の声が開発に反映されにくくなる構造的な課題を示しています。
自由回答でも、こうした構造的な課題を裏付ける声が寄せられています。

これらの声が示すのは、ユーザー検証が省かれる原因は「やらなくていいと思った」からではなく、「やりたくてもやれなかった」というプロジェクト構造にあるという点です。
スケジュールの逼迫と意思決定構造の硬直化という2つの壁が、開発前のユーザー検証を阻んでいる実態が浮き彫りになりました。
「使われるシステム・アプリ」に必要なのは、まず『誰が使うのか』を決めること
「実際に使われるシステム・アプリ」を作るために開発前に最も必要なことを聞いたところ、最多は「ターゲットユーザーを具体的に決める」(56%)でした。

過半数の開発担当者が「まず誰が使うのかを明確にすべきだ」と回答しています。
前章で見たとおり、開発前にユーザーを十分に確認した群は88.9%が想定どおりの利用状況を達成していました。
「誰のために作るのか」を最初に定義することが、その後の設計・機能選定・導入計画のすべてに影響するという実感が、この数字に表れています。
「利用場面の観察」「インタビュー」も4割超が必要と回答
2位の「実際の業務や利用場面を観察する」(44%)、3位の「ユーザーが困っていることをインタビューで確認する」(42.7%)も、ともに4割超の回答を集めました。
注目すべきは、上位3項目がいずれも「実際のユーザーに直接接触するアクション」であるという点です。
- 1位:ターゲットユーザーの具体化(56%) ⇒ ユーザー像を定義する
- 2位:利用場面の観察(44%) ⇒ ユーザーの行動を直接見る
- 3位:インタビューで確認(42.7%) ⇒ ユーザーの声を直接聞く
一方で、4位の「必要な機能と不要な機能の整理」(40%)は社内で完結できる作業です。上位3つと4位の間には、「ユーザーに会いに行くかどうか」という明確な境界線があります。
この結果は、開発担当者自身が「机上の要件定義だけでは不十分であり、実際のユーザーの行動を観察し、声を聴くプロセスが不可欠だ」と認識していることを示しています。
要件定義書やヒアリングシートを社内で回すだけでなく、ユーザーの現場に足を運び、実際の業務フローや利用状況を自分の目で確かめるプロセスが求められているといえるでしょう。
「開発側の想定」と「現場」のズレ
自由回答では、開発前に確認しておけばよかった具体的なエピソードが数多く寄せられました。その多くに共通するのは、「開発側が想定した使い方」と「現場で実際に求められていた使い方」のギャップです。

これらの声に共通しているのは、開発側が「便利なはずだ」「効率化できるはずだ」と想定していた機能や設計が、現場の実態とかみ合わなかったという経験です。
「開発前に現場を見ていれば防げた」という振り返りが多いことからも、前項の質問で「利用場面の観察」「インタビュー確認」が上位に挙がった背景がうかがえます。
「使われないシステム・アプリ」を防ぐ鍵は、開発プロセスに潜む3つのギャップを埋めること
本調査では、新規システム・アプリの導入後に約4割が「想定より利用されなかった」と回答し、さらに約75%が「開発前のユーザー調査が不足していた」と実感していることが明らかになりました。
一方、開発前に十分なユーザー確認を行っていた群は88.9%が想定どおりの利用を達成しており、事前検証の有無が導入後の成果を大きく左右しています。
これらの結果から、「使われないシステム・アプリ」を生む原因は、開発から導入までのプロセスに存在する3つのギャップに集約されます。
| ギャップ①「開発スケジュール」 | 本調査では約4割がスケジュール不足を理由にユーザー検証を省略したと回答 |
| ギャップ②「開発側の想定」と「現場のニーズ」 | 約7割がユーザーの声を十分に確認できず、機能と現場ニーズにズレが発生 |
| ギャップ③「リリース」と「定着」 | 導入時の説明やオンボーディングの不足(21.3%)により、従来のExcelや紙への逆戻りが発生 |
開発担当者の56%が「ターゲットユーザーの具体化」を最も必要なことに挙げたように、「誰のために、何を作るのか」を開発前に明確にすることが、これら3つのギャップを埋める第一歩です。
株式会社Engineerforceでは、開発前のUI/UXリサーチから設計・開発・導入支援までを一貫して手がけています。「使われるシステム・アプリ」の実現に向けて、まずはお気軽にご相談ください。
■会社概要
| 会社名 | 株式会社Engineerforce(エンジニアフォース) |
| 代表者 | 代表取締役 飯田佳明 |
| 所在地 | 〒150-0031 東京都渋谷区桜丘町23番17号 シティコート桜丘408 |
| 設立 | 2020年8月4日 |
| 資本金 | 1,000万円 |
| 事業内容 | ソフトウェア開発、UI/UXデザイン、コンサルティング、プロダクト開発 |
| URL | https://engineerforce.io/ |
■本アンケートの引用について
本アンケート結果を引用する場合は、必ず「株式会社Engineerforce」の明記と本記事URL(https://engineerforce.io/)の記載をお願いします。