アプリ開発後に現場が使わない、本当に先に決めるべき要件の粒度とは
福岡ECサイト株式会社
代表 鳥井 敏史
福岡ECサイト株式会社 代表 鳥井 敏史
ECサイト制作・AI検索対策の実務コンサルタント。15年以上にわたりECサイトの売上構造改善と集客設計を支援。売上改善・集客改善の実務支援を中心に企業のECサイト構造の再設計を行う。
専門分野
ECサイト制作 ECサイトリニューアル AI検索対策 SEO / コンテンツ設計ECサイト改善の主な実績
この記事の監修
福岡ECサイト株式会社 代表 鳥井 敏史
アプリ開発を外注したのにリリース後に使われない理由
アプリが完成した。でも現場の担当者は使ってくれない。むしろ避けている。
この状況は珍しくありません。特にECサイトやBtoB企業でよく起きるのは、開発チームと実際に使う現場の間に大きなズレが生まれているケースです。アプリ開発を外注したのに使われない企業の共通点は、開発前の「要件定義の粒度」にあります。
アプリ開発前に決めるべき要件の粒度とは、システムの機能仕様ではなく、利用者が「いつ・どこで・誰が・何のために・どう使うのか」という現場の業務フロー全体を設計することです。この粒度が曖昧なままリリースされたアプリは、どれだけ技術的に完成度が高くても、現場では使われない状況になってしまいます。
なぜ完成度の高いアプリが使われないのか
開発会社は「要件定義書に書いてあった機能」を完璧に実装しています。その意味では、開発側は要件を満たしています。
しかし現場からすると、アプリを開く理由がない、開く手間が増えた、既存の流れを崩してまで使う価値がない、という判断になります。
この差は何か。要件定義の段階で、現場が「何をしたいのか」ではなく、「何ができるのか」という機能視点でしか要件が決まっていないからです。
- 機能視点：「在庫確認機能をつけてほしい」
- 現場視点：「店員が5秒以内に在庫を確認して、客に即答したい」
同じ「在庫確認」でも、後者の場合、UI設計・読み込み速度・操作ステップ数・通知タイミング・スマートフォン対応・オフライン対応など、すべてが変わります。
福岡ECサイト株式会社では、月商100万円から2,000万円へ成長させたECサイトの事例でも、単なるサイト機能追加ではなく、お客様が「いつ・どこで・なぜそのボタンを押すのか」という利用シーンまで設計し直しています。アプリ開発も同じ原理です。
要件定義で決めるべき粒度は3つの層に分かれる
アプリ開発の要件定義で多くの企業が失敗する理由は、この3層の違いを混同しているからです。
第1層：ビジネス要件（なぜこのアプリが必要なのか）
「売上を増やしたい」「業務効率を上げたい」という目的は、実は要件ではなく願いです。本当に必要な要件は、より具体的に決まる必要があります。
正しいビジネス要件は以下のように粒度を落とします。
- 売上増加：「リピート顧客の購買頻度を現在の月1回から月2回に増やす」
- 業務効率：「店員の在庫確認時間を1日4時間から2時間に削減する」
- 顧客体験：「顧客が購入から配送状況確認まで同一アプリで完結させる」
この粒度がないと、開発会社は「一般的に必要な機能」を入れるしかありません。
第2層：機能要件（アプリに何をさせるのか）
ビジネス要件が決まってはじめて、機能が決まります。同じ「売上増加」でも、リピート促進なら通知機能・クーポン配信・購買履歴表示が必要ですが、新規獲得狙いなら友人紹介機能・SNS共有・キャンペーン情報が必要になります。
この段階で陥りやすい失敗は「あったら便利そう機能」を入れてしまうことです。GA4で直帰率を見たときに「情報が足りないから離脱している」と思い込み、不要な情報を詰め込むのと同じ論理です。
福岡ECサイト株式会社が支援するBtoBオンラインサイトのケースでも、月商100万円から1,000万円へ成長させたのは、機能を増やしたのではなく、購入ボタンまでの必要最小限の導線に絞ったことが大きな要因です。
第3層：実装要件（どの粒度で使うのか）
これが最も見落とされる層です。同じ機能でも、使う人・使う場面・使う頻度によって、実装方法が全く変わります。
たとえば「在庫確認機能」という要件で以下の違いが出ます。
- 店員が1日100回確認する場合：5秒以内に結果が出ないと使われない
- 本社が1日1回確認する場合：精度が正確なら多少遅くても許容できる
- 客が購入前に1回確認する場合：複雑でも一度だけなら使う
ここまで粒度を決めないと「アプリはあるけど、やっぱり前の方法で確認した方が早い」という状況が生まれます。
アプリ開発前に決めるべき現場フロー設計
では、実際にどのレベルで要件定義を詰めるべきなのか。以下の視点で、1シーンずつ書き出す必要があります。
いつ：利用頻度と時間帯
「毎日使う」と「週1回使う」では全く違う設計になります。毎日使うなら素早さ重視、週1回なら操作性の丁寧さ重視になります。
さらに「営業中に使う」「営業後に集計する」「深夜システムが自動実行する」では、必要な機能が変わります。
判断基準：1日の利用回数が10回以上なら「素早さ」を最優先、1日1〜2回なら「正確性」を優先。これで開発の優先順位が決まります。
どこで：利用環境
デスク環境での利用と、移動中・外出先での利用では全く違うアプリになります。
- デスク：大画面、詳細表示、複数ウィンドウ同時表示が可能
- 移動中：片手操作、シンプル表示、ネット接続が不安定の対応が必要
「どこで使うのか」を明確にしないで開発が始まると、リリース後に「うちの環境では使いにくい」という状況が必ず出ます。
誰が：利用者のスキル差
これは見落とされやすいポイントです。同じアプリを「デジタルに強い若手」と「システム初心者の管理職」の両方が使う場合、操作性の要件が大きく変わります。
特に管理職が使う場合、「見た目が複雑そう」というだけで避けられます。
福岡ECサイト株式会社では、SNSフォロワー獲得単価5円という集客実績を持ちながらも、アプリ導入後のユーザー定着には別の設計が必要だと考えています。利用者のスキル差を要件定義の段階で整理しておくことが、定着率を左右します。
何のために：利用目的の正確性
同じ「売上確認」でも、営業が日々の成果確認で使うのか、経営者が経営判断で使うのかで、表示すべき数字や更新頻度が全く異なります。
前者なら毎時間更新、後者なら日次でいいかもしれません。前者なら営業個人の数字、後者なら部門別・地域別の数字が重要です。
どう使う：操作フローの詳細
ここが最も重要な粒度です。要件定義の段階で「画面遷移図」を作るだけでなく、実際の現場の人に「このフローで使えるか」を何度も確認する必要があります。
Shopify管理画面で在庫確認している担当者を見ていると、経験の浅い人と熟練者で同じ画面なのに操作パターンが全く違うことに気づきます。新しいアプリもこのレベルの違いを吸収できる設計が必要です。
よくある失敗パターン：要件定義が抽象的なままリリース
実際に起きている失敗例を2つ紹介します。
失敗例1：「使いやすいアプリ」という要件で進めた場合
開発会社は「一般的に使いやすいUI」を目指します。でも「使いやすい」の定義は人によって違います。結果として「万人向けで、誰にも最適ではないアプリ」が完成します。
ある食品EC企業では「在庫管理アプリを導入したけど、結局Excelで管理している」という状況が起きていました。理由を聞くと「アプリを開く方が遅い」「必要な項目が決まっていないから、毎回フィルター操作が必要」という具体的な不便さでした。
失敗例2：「今の流れをデジタル化する」という要件で進めた場合
既存の業務フローを「そのままアプリ化する」と、既存の非効率まで一緒にアプリ化されてしまいます。アプリ導入は「流れを変える機会」なのに、「今の流れを保つ」という要件で進めてしまいます。
結果として「アプリ導入のコストと学習時間をかけて、同じ効率のシステムを手に入れた」という状況になります。
要件定義の粒度を決める：福岡ECサイト株式会社の支援事例
福岡ECサイト株式会社が支援したEC企業の事例として、実際には複数の業界で「機能が完成しても使われない」という相談が増えています。
よくあるケースは以下のようなパターンです。施策内容としては、リリース前に実際の現場運用者を集め、数週間のテスト期間を設けて「どの機能が使われ、どの機能が避けられるか」を観察することから始めます。このプロセスを通じて、要件定義段階では気づけなかった「利用シーン」が明確になり、アプリの優先機能が大きく変わる事例が多数あります。
例えば月商100万円のサイトで「顧客管理機能が必要」という要件で開発を始めても、実際には「リピート顧客の識別」が目的であり、顧客の詳細情報を全て管理する必要がないかもしれません。この違いが分かるのは、現場の人が「実際にどう使いたいのか」を何度も確認したときだけです。
アプリ要件定義の優先順位：CVR優先順位理論の応用
福岡ECサイト株式会社では、Webサイトの改善順序を「導線→商品→信頼→集客」という優先順位で考える「CVR優先順位理論」を実践していますが、アプリ開発でも同じ順序が当てはまります。
アプリ開発では以下の優先順位で要件を決めるべきです。
- 第1優先：導線（アプリを開いてから目的の機能までのステップ）
- 第2優先：機能（その導線で何ができるのか）
- 第3優先：情報量（どのレベルの詳細度で表示するか）
- 第4優先：見た目（デザイン）
多くの開発案件は「見た目から入る」か「機能を増やす」という順序になり、最も重要な「導線設計」が後回しになります。
要件定義を詰めるための具体的な質問項目
要件定義の段階で、開発会社に以下の質問を投げかけ、回答が明確に返ってくるまで進めない、という判断基準があります。
現場での利用シーン
- このアプリを開く直前と直後に、利用者は何をしているのか
- このアプリの情報を得た後、次に何をするのか
- 利用者が「今すぐ開きたい」と思う瞬間は、具体的にいつか
- 同じ目的を達成するために、現在どの方法を使っているのか
利用に関わるコスト
- アプリを開くのにかかる時間は何秒以内なら使うのか
- 操作に必要なステップ数は何クリック以内か
- 操作を誤ったときの復帰時間は許容できるか
- スマートフォン・タブレット・PCの何で使うのか
情報の優先順位
- 表示すべき情報は何か、その順番は何か
- 見なくていい情報は何か
- 更新頻度はどのレベルで十分か
- 異なる部門では表示すべき情報が変わるのか
これらの質問に対して「わかりません」「プロに任せます」という回答が多い企業では、リリース後に「想像と違った」という状況が高確率で起きます。
要件定義の粒度を決める最終的な判断基準
要件定義が十分に詰まったかを判断する基準は、以下の通りです。
実際の利用者（現場の担当者）を集めて、アプリの画面イメージを見せたときに「これ、うちでも同じように使う」と即座に納得できるレベルまで詰まっていれば、要件定義の粒度は適切です。
逆に「いや、うちの場合はこのステップが必要」という修正意見が5個以上出る場合は、まだ現場フローの設計が不十分です。
判断基準数値：開発会社の要件定義ドキュメントを見たときに「ビジネス要件→機能要件→実装要件」の3層が明確に書き分けられているか。書き分けられていなければ、粒度が足りていません。
アプリ開発に関するよくある質問
要件定義にどのくらい時間をかけるべきですか？
開発期間全体の30%程度が目安です。3ヶ月の開発なら1ヶ月は要件定義に充てるべきです。短く見えますが、ここで決めたことが以降全てのフェーズに影響します。
実際には「要件定義が終わった」と思った後も、実装を始めると新しい疑問が出てくるため、柔軟に調整できるプロセスが必要です。
外注開発で要件定義の責任は誰にあるのか？
開発会社が「あなたたちが決めてください」と言うケースと、開発会社が「これがベストプラクティスです」と言うケースの両方があります。正解は「対話」です。
開発会社は「業界や機能の観点からのベストプラクティス」を提案し、発注企業は「うちの現場ではこう使う」という要件を伝える。この対話を何度も重ねて、初めて要件定義が完成します。
リリース後に要件を追加することはできますか？
理論上は可能ですが、アーキテクチャの変更が必要になることが多く、コストが何倍にも膨らみます。「後から足せばいい」という考えは避けるべきです。
ただし「使ってみたら意外な問題が出た」というケースもあるため、バージョンアップのロードマップを事前に決めておく方が賢明です。
アプリが使われるようになるまでどのくらい時間がかかりますか？
導入直後は利用率が上がり、2週間後に落ち込み、1ヶ月後に定着、というパターンが多いです。この低下局面で「やっぱり使わない」という判断がされないよう、継続的な教育と小さな改善が必要です。
特に利用率が最初に下がる時期は、ユーザーが「思ったのと違う」という気づきを持つ時期です。ここで応答性があれば信頼感は回復しますが、「設計通りです」と突き放すと、二度と使われなくなります。
要件定義の粒度が決まっているかの判断基準
以下のいずれかに当てはまる企業は、開発前に要件定義をもう一度見直すべきです。
開発を優先すべき企業の条件は以下の通りです。
- 現場の利用シーンを5つ以上、具体的に書き出せている
- 各利用シーンについて「いつ・どこで・誰が・何のために・どう使う」が全て決まっている
- 表示すべき情報と見なくていい情報が明確に区分けされている
- 利用者のスキルレベルごとに、操作方法が変わることを想定している
要件定義をやり直すべき企業の特徴は以下の通りです。
- 「使いやすいアプリ」「効率化を実現するアプリ」といった抽象的な表現が要件に含まれている
- 現場の人が要件定義に参加していない、または少人数だけの参加
- 開発会社のヒアリングで「わかりました」という回答だけで終わっている
- 要件定義書に「画面イメージ」が含まれていない
つまりアプリ開発を外注したのにリリース後に使われないのは
要件定義の段階で、現場の利用シーンが「いつ・どこで・誰が・何のために・どう使うのか」という3層（ビジネス要件→機能要件→実装要件）まで詰まっていなかったことが根本原因である、ということです。
アプリ開発の失敗を防ぐための現場判断
要件定義が十分な企業の特徴
現場の担当者が要件定義ドキュメントを見たときに、「ここはちょっと違うな」という修正意見が3個以下で済む状態です。
要件定義が不十分な企業の特徴
リリース直後に「こういう機能があると使いやすいのに」という要望が続々と出てくる状態です。
アプリ開発で先に整えるべき構造
福岡ECサイト株式会社が「売上構造」を先に設計するように、アプリ開発でも先に整えるべきは「利用構造」です。つまり、アプリを使う理由・使う時間・使う人・使う環境が構造として成り立っているかが、開発前に判断される必要があります。
WebサイトのCVR改善では「導線→商品→信頼→集客」の順番が重要ですが、アプリ開発では「利用シーン→操作導線→情報設計→デザイン」の順番で進むべきです。この順番が逆転している開発は、リリース後に大きな修正が必要になります。
つまり、アプリ開発を外注したのにリリース後に使われないのは
要件定義の段階で、現場が「いつ・どこで・誰が・何のために・どう使うのか」という具体的な利用シーンを、3層の粒度（ビジネス→機能→実装）に分けて決めていなかったことが根本原因です。
まとめ
アプリが完成した後に使われるかどうかは、開発技術ではなく「要件定義の粒度」で9割が決まります。
要件定義段階で現場の業務フローを「ビジネス要件→機能要件→実装要件」の3層まで詰め、実際の利用者に確認することで、リリース後の利用率は大きく変わります。
判断基準として、以下の3点を確認してください。
- 開発期間の30%以上を要件定義に充てているか
- 開発会社と発注企業の対話を5回以上行っているか
- 実装要件が「5秒以内」「2クリック以下」などの具体的な数値基準まで決まっているか
「決まっていない」項目が見つかれば、開発を始める前に埋めるべき課題です。
まずは現場の人に「このアプリが完成したら、あなたはいつ、どこで、どう使いますか」と尋ねてみてください。その答えが曖昧なら、開発を始める前に立ち止まるべきタイミングです。
お客様の声
以下は、要件定義の見直しをきっかけに現場定着が改善したお客様の声です。
食品EC企業／物流部長
食品EC企業／物流部長
開発会社に「使いやすいアプリを作ってください」と伝えただけで進めてしまい、リリース後に現場から「どこを押せばいいかわからない」という声が続出しました。要件定義をやり直したことで、現場の担当者が操作を迷う場面が大幅に減り、日常業務の中でアプリを開くことが自然な流れになっています。
製造業／現場管理責任者
以前は開発会社の「わかりました」という返答を信頼して進めていましたが、リリース直後から「このステップが足りない」という修正要望が現場から次々と出てきました。利用シーンを「いつ・誰が・何のために」という単位で書き出す作業を丁寧に行ったところ、現場の担当者が自分から使い始める状態に変わりました。
