約75％が「開発前のユーザー確認不足」を実感――使われないシステム・アプリを生む3つのギャップ

新規システム・アプリの約4割が「想定より使われなかった」と回答。開発前から見直すべきポイントとは

時間と予算をかけて開発したシステムやアプリが、期待したほど使われない。
新規システム・アプリの開発現場では、次のような問題が少なくありません。

「多くの機能を開発したが、実際に使われるのは一部だけだった」
「一部の部署にしか利用が広がらなかった」
「入力作業が増え、現場が従来のExcelや紙へ戻ってしまった」

システムやアプリが技術的に完成していても、現場で利用されなければ、業務改善や売上向上といった本来の目的は達成できません。

私たちEngineerforceは、新規システム・アプリの開発プロジェクトに携わった経験を持つビジネスパーソン75名を対象に、「システム・アプリ開発前後のギャップ」に関するアンケート調査を実施しました。

調査の結果、44％が、導入後の利用状況について「開発前の想定を下回った」と回答しています。

さらに、74.7％が「開発前のユーザー調査やニーズ確認が不足していた」と感じていました。

本記事では、調査結果をもとに、システム・アプリが使われなくなる構造と、開発前から取り組むべき対策を解説します。

新規システム・アプリの約4割が「想定より使われなかった」

導入後の利用状況が開発前の想定と比べてどうだったかを尋ねたところ、回答は次のようになりました。

• おおむね想定どおりだった：45.3％
• 想定をやや下回った：40.0％
• 想定を大きく下回った：4.0％
• 想定を上回った：6.7％

「想定をやや下回った」と「想定を大きく下回った」を合わせると44％です。

「おおむね想定どおりだった」の45.3％とほぼ同じ割合であり、利用状況が期待を下回ることは、決して珍しくありません。

一方、想定を上回った割合はわずか6.7％でした。

「使われない」は、完全な未利用ではなく“部分利用”として現れる

具体的な利用状況で最も多かったのは、「一部の機能しか使われなかった」の28％でした。

実際のプロジェクトでは、完全に使われないケースよりも、次のような部分利用が多く発生します。

• 多数の機能を開発したが、日常的に使われるのは一部だけ
• 特定の部署では使われているが、ほかの部署へ広がらない
• システムを導入したものの、Excelや紙も併用されている
• 管理者は利用しているが、現場担当者には定着していない
• 初回は利用されたが、継続利用されていない

ログイン数が一定数あれば「導入は完了した」と評価されることがあります。

しかし、想定した業務がシステムへ移行していなければ、二重入力や確認作業が発生し、導入前より現場の負担が増える場合もあります。

開発担当者の4人に3人が「もっとユーザーを確認すべきだった」と実感

開発前のユーザー調査やニーズ確認が不足していたと感じるかを尋ねたところ、「強く感じた」が14.7％、「やや感じた」が60.0％でした。

合計すると74.7％、およそ4人に3人が不足を感じています。

重要なのは、ユーザーに一度でも確認したかではありません。
誰に、どのような方法で、どの段階まで確認したかによって、得られる情報の質は大きく変わります。

十分なユーザー確認を行っていたのは、わずか12％

開発前にユーザーの声をどの程度確認していたかを尋ねたところ、「複数の方法を使って十分に確認していた」と回答した割合は、わずか12％でした。

回答の内訳は次のとおりです。

• 複数の方法を使って十分に確認していた：12.0％
• インタビューやテストを実施した：16.0％
• 一部のユーザーには確認していた：37.3％
• 社内メンバーを中心に確認した：28.0％
• ほとんど確認していなかった：6.7％

「一部のユーザーに確認」「社内メンバー中心」「ほとんど確認せず」を合わせると72％です。

約7割が、実際のユーザーの声を十分に反映できていない状態で開発を進めていました。「確認したか」ではなく、「意思決定に必要な情報を得られる方法で確認したか」が重要です。

十分に確認した層の想定未達はわずか11.1％、一部確認にとどまった層は57.1％

開発前のユーザー確認の程度と、導入後の利用状況を比較すると、次の結果となりました。

開発前の確認度合い	想定を下回った	おおむね想定通り	想定を上回った
十分に確認 （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%になりません

• 十分に確認していた層：想定を下回った11.1％
• インタビュー・テストを実施した層：想定を下回った33.3％
• 一部ユーザーに確認した層：想定を下回った57.1％
• 社内関係者を中心に確認した層：想定を下回った42.9％
• ほとんど確認しなかった層：想定を下回った60.0％

十分に確認していた層では、88.9％が「おおむね想定どおり」と回答しています。
一方、一部ユーザーへの確認にとどまった層では57.1％が想定を下回りました。

ただし、それぞれの回答数は大きくありません。「十分に確認した」層は9名、「ほとんど確認しなかった」層は5名です。

因果関係を断定することはできませんが、ユーザー確認の充実度と導入後の利用状況に大きな差が見られたことは、開発プロセスを見直す重要な材料になります。

社内関係者への確認だけでは、現場のニーズを捉えきれない

システム開発では、経営層、事業責任者、情報システム部門、管理職などから要望を集めることが一般的です。

しかし、意思決定者と実際の利用者が同じとは限りません。

例えば、管理者にとって便利な詳細入力や集計機能が、毎日操作する現場担当者には負担になることがあります。

重要なのは、一人の「ユーザー」を想定するのではなく、システムに関係する複数の利用者を整理し、それぞれの目的、利用場面、負担を把握することです。

使われないシステム・アプリを生む3つのギャップ

ギャップ1：開発スケジュールと検証時間

調査では、約4割がスケジュール不足を理由にユーザー検証を省略したと回答しています。ユーザー調査は、開発を遅らせるための工程ではありません。不要な機能や手戻りを減らし、限られた開発期間を有効に使うための工程です。

ギャップ2：開発側の想定と現場のニーズ

約7割が、実際のユーザーの声を十分に確認できないまま開発を進めていました。

現場の業務を理解せずに設計すると、「機能としては正しいが、業務では使いにくい」システムになりかねません。

ギャップ3：リリースと定着

システムやアプリは、リリースしただけでは定着しません。

なぜ新しいシステムへ変更するのか、従来業務のどこが改善されるのかを説明し、利用状況を確認しながら改善する必要があります。

過半数が指摘――最初に決めるべきなのは「誰が使うのか」

開発前に最も必要なことを尋ねたところ、「ターゲットユーザーを具体的に決める」が56％で最多となりました。

ターゲットユーザーを整理するときは、所属部署などの属性だけでなく、次の内容まで具体化することが重要です。

• どのような目的で利用するのか
• いつ、どこで利用するのか
• どのくらいの頻度で利用するのか
• 利用前後にどのような作業があるのか
• 現在はどのような方法で対応しているのか
• システムを使わないとすれば、その理由は何か

同じ機能でも、利用者や利用場面が違えば、最適なUIや必要な情報量は変わります。

開発前に行いたい5つのユーザー検証

1．関係者とユーザーを整理する

意思決定者、管理者、現場担当者、顧客など、システムに関係する人を洗い出します。

2．現状業務を観察・ヒアリングする

「どの機能が欲しいですか」と聞くだけでなく、現在の作業手順や、判断に迷う場面を具体的に確認します。

3．課題の優先順位を付ける

発生頻度、業務への影響、対象ユーザー数、解決の緊急度を踏まえて、優先すべき課題を決めます。

4．プロトタイプで操作を確認する

ワイヤーフレームや操作可能なプロトタイプを使い、説明なしで目的の操作を完了できるかを確認します。

5．検証結果を開発要件へ反映する

調査で得られた情報を、機能の優先順位、画面構成、入力項目、導入方法などの意思決定へ反映します。

画面を描く前に、現場を知る。Engineerforceのリサーチ起点のUI／UX支援

システム開発では、「入力項目を増やしてほしい」「多くの情報を一覧で表示したい」といった具体的な要望からプロジェクトが始まることがあります。

しかし、その要望をそのまま実装しても、現場で使われるとは限りません。

EngineerforceのUI／UX支援は、画面の見た目を整えるところからは始まりません。

まず、誰が、いつ、どのような目的でシステムを使うのかを整理します。意思決定者、管理者、現場担当者など、関係する人を洗い出し、それぞれの業務と目的を確認します。

ヒアリングでは、機能要望だけでなく、現在の作業手順、判断に迷う場面、二重入力が発生している箇所、Excelや紙が残っている理由まで掘り下げます。

その結果をもとに、情報の優先順位、画面構成、必要な機能を設計します。

実装前には、ワイヤーフレームや操作可能なプロトタイプを使い、ユーザーが説明なしで目的の操作を完了できるかを確認します。どこで迷うのか、どの表現が伝わらないのかを観察し、開発コストが大きくなる前に改善します。

さらに、当社ではUI／UXデザインとシステム開発を同じプロジェクト内で連携させます。

デザイナーがユーザーの声を整理し、エンジニアが技術的な制約や実装方法を検討することで、理想だけでも技術都合だけでもない、実際に提供できる体験へ落とし込みます。

支援はリリースで終わりません。

利用データやユーザーの反応を確認し、使われていない機能、操作途中で離脱している画面、従来のExcelや紙が残っている業務を特定します。その結果をもとに、UI改善、機能の見直し、オンボーディングの改善へつなげます。

「何を作るか」より前に「誰のために作るか」を考える。完成をゴールにせず、実際に使われるところまで改善を続ける。

それが、Engineerforceのリサーチ起点のUI／UX支援です。

EngineerforceのUI／UXデザイン支援を見る
既存システムの改善について相談する

---

調査概要

• 調査対象：新規システム・アプリの開発プロジェクトに携わった経験を持つビジネスパーソン75名
• 調査方法：インターネットアンケート調査
• 調査期間：2026年10月7日～10月16日
• 調査機関：株式会社Engineerforce

※本調査は回答者の自己評価に基づく横断調査であり、ユーザー確認の程度と導入後の利用状況との因果関係を直接証明するものではありません。
※一部の区分は回答数が少ないため、割合を解釈する際には注意が必要です。