新規事業のシステムが使われない原因｜作る前後の確認点
新規事業でシステムを作ったのに、思ったように使われない。この悩みの原因の多くは、開発の出来そのものより、作る前の確認不足と、作った直後の見方にあります。この記事では、使われない状態を3つの形に分け、作る前と作った直後にそれぞれ何を確かめておくとよいかを整理します。
新規事業のシステムが「使われない」とは、どういう状態か
「使われない」と一言でいっても、状態は一つではありません。どこで止まっているのかによって、見直すべき場所が変わります。私たちは、次の3つの形に分けて考えると整理しやすいと考えています。
1. そもそも使い始めてもらえない
ひとつめは、システムを公開しても、登録や最初の利用にたどり着かない状態です。想定した利用者に存在が届いていない場合もあれば、届いていても「自分に必要なものだ」と感じてもらえていない場合もあります。
この形の背景には、解決したい困りごとが、利用者にとってそれほど切実ではなかったという可能性があります。機能の不足というより、作る前の仮説に問題があるケースです。
2. 使い始めたが、続かない
ふたつめは、一度は触ってもらえたものの、2回目、3回目につながらない状態です。最初の登録はあっても、その先で「何をすればよいのか分からない」「今までのやり方のほうが早い」と感じられて離れてしまいます。
この形では、最初の一回の体験や、今使っている手段との比べられ方が問題になりやすいです。
3. 使われてはいるが、事業にならない
みっつめは、利用そのものはあるのに、事業として成り立つ形になっていない状態です。利用者が増えても収益につながらない、社内の一部の人しか使っていない、といった形で現れます。
この場合、システムの使いやすさよりも、事業の設計とシステムの設計がつながっていないことが原因になりやすいです。「システムを作る」ことと「事業をつくる」ことは、別の作業だからです。
3つの形のどれに当たるかによって、打つ手は大きく違います。次の章からは、作る前に確かめたいことと、作った直後に確かめたいことを順に見ていきます。
作る前に確かめたいこと
使われない原因の多くは、開発に入る前の段階にあります。開発が始まってからでは直しにくい点を、先に確認しておくことが大切です。
誰の、どの場面の困りごとかを一文で言えるか
最初に確かめたいのは、このシステムが「誰の」「どんな場面の」困りごとを解決するのかを、一文で言えるかどうかです。「中小企業向け」「働く人向け」のような広い言い方では、まだ足りません。
たとえば「小さな店舗の店長が、閉店後にその日の予約状況を振り返る場面」のように、人と場面が思い浮かぶ粒度まで絞れているかを確認します。人と場面が具体的になるほど、必要な機能と不要な機能の線引きがしやすくなります。
今の代わりの手段は何かを把握しているか
利用者は、システムがなくても何かしらの方法で困りごとをしのいでいます。紙、表計算ソフト、チャットアプリ、人づての連絡など、手段はさまざまです。新しいシステムは、こうした今の手段と比べられます。
「今のやり方より、どこがどれだけ楽になるのか」を説明できないと、利用者が乗り換える理由が生まれません。作る前に、今の手段を実際に見せてもらい、どこで困っているのかを確かめておくと、見当違いの機能を作るリスクを減らせます。
最初の一回の使い方を言葉にできるか
次に、利用者が初めてシステムを開いてから、最初の成果を得るまでの流れを言葉にできるかを確認します。登録、設定、データの入力、結果の確認といった一連の流れが長いほど、途中で離れる人が増えます。
「初めて使う人が、何分で何を体験できるのか」を先に考えておくと、最初に作るべき範囲が見えてきます。機能の絞り方については、MVP開発の機能の絞り方｜最初に作るものと後回しの基準でも詳しく整理しています。
「使われた」と言える基準を先に決めているか
見落とされやすいのが、「どうなれば使われたと言えるのか」という基準です。基準がないまま公開すると、結果を見ても、うまくいったのか失敗したのかが判断できません。
たとえば、次のような項目を、作る前に決めておきます。
- 最初の利用から一定期間内に、再び使った人がどれくらいいるか
- 特定の操作（予約、投稿、依頼など）を最後まで終えた人がどれくらいいるか
- 利用者から、どんな声が何件寄せられたら「続ける」と判断するか
数字の置き方は事業によって違うため、ここでは具体的な値までは示しません。大切なのは、結果を見る前に基準を決めておくことです。進め方はMVP検証の指標を先に決める方法｜判断基準の作り方で整理しています。
決裁者と現場が、同じ目的を見ているか
新規事業では、経営陣（決裁者）と現場（立案者）が同じ目的を見ているのに、判断の材料と進める速度が違うために、話が噛み合わなくなることがあります。この状態で開発を進めると、現場が作りたいものと、決裁者が期待するものにずれが生じ、公開後に「思っていたものと違う」となりやすくなります。
ずれているのは目的ではなく、進め方であることが多いです。この点は新規事業で経営陣と現場がすれ違う原因は進め方のズレでも触れています。作る前に、「何をもって成功とするか」を関係者で言葉にしておくと、公開後の判断がぶれにくくなります。
作った直後に確かめたいこと
システムができあがった直後は、公開の準備や周知に意識が向きがちです。しかし、この時期にこそ、使われない原因の手がかりが集まります。
使い始めの壁を、実際に歩いて確かめる
公開したら、まず作った側の人が、初めて使う人の立場で最初から最後まで操作してみます。開発に関わった人は操作に慣れているため、つまずきに気づきにくいものです。
可能であれば、システムの内容を知らない人に、説明なしで触ってもらうのが有効です。画面の前で止まった場所、迷った場所、質問が出た場所を記録します。どこで止まるのかが分かれば、直す場所も絞れます。
少人数に触ってもらってから広げる
最初から広く公開すると、うまくいかなかった場合に、原因が見えにくくなります。まず少人数の利用者に使ってもらい、使い方や反応を観察してから範囲を広げるほうが、原因を特定しやすくなります。
公開範囲の決め方は、新規事業のクローズドβ｜進め方と公開範囲の決め方で整理しています。また、触ってもらう際に何を聞くかは、プロトタイプのユーザーテスト｜新規事業での確かめ方と質問が参考になります。
数字と声を、両方見る
利用状況の数字は、「何が起きたか」を教えてくれますが、「なぜ起きたか」は教えてくれません。逆に、利用者の声は理由を教えてくれますが、全体の傾向は分かりません。
たとえば、登録後に離脱する人が多いという数字が出たとします。その理由が、入力項目の多さなのか、最初の画面の分かりにくさなのか、そもそも期待と違ったのかは、数字だけでは判断できません。数字で場所を見つけ、声や観察で理由を確かめるという順番で見ていくと、見直しの方向が定まります。
機能を足す前に、使われない理由を確かめる
使われないと分かると、「機能が足りないのでは」と考えて、機能を追加したくなります。ただ、原因が機能不足ではない場合、機能を足すほどに画面が複雑になり、かえって使われにくくなることがあります。
機能の追加は、使われない理由が「できないことがあるから」だと確認できてから検討します。追加要望の扱い方については、システム開発の仕様変更への対応｜追加要望の扱い方も参考になります。
システムの作りの面から見直したいこと
利用者の側の問題だけでなく、システム側の作りが原因になっていることもあります。確認しておきたい代表的な点を挙げます。
初期データが空で、価値が伝わらない
マッチングや投稿型のサービスのように、データが集まって初めて価値が出るシステムでは、最初の画面が空っぽだと、利用者は何のためのものか分かりません。最初に触れた瞬間に価値を感じてもらえるよう、初期のデータをどう用意するかを考えておく必要があります。
実物に近いデータを用意する工夫は、プロトタイプのダミーデータの用意のしかた｜実物に近づけるで触れています。
運営側の仕組みが足りず、続けられない
利用者向けの画面だけを作り、運営側が状況を確認したり、問い合わせに対応したり、内容を修正したりする仕組みがないと、運営が回らなくなります。結果として、サービスの質が下がり、使われなくなることがあります。
ただし、運営用の画面を最初から作り込みすぎる必要はありません。どこまでを最初に作るのかの見極めは、新規事業の管理画面開発｜最初に作る範囲の見極め方を参考にしてください。
利用者が使う場所と、提供の形が合っていない
利用者が普段使う環境と、提供する形が合っていないことも、使われない原因になります。スマートフォンで使う場面が中心なのに、パソコン向けの画面だけを用意している、あるいは逆の場合などです。
Webで始めるのか、アプリで始めるのかは、利用場面から逆算して決めるのが基本です。判断の基準は新規事業のアプリ・Web開発｜最初の選び方の基準で整理しています。
事業の収益の形と、システムの作りがつながっていない
利用はあるのに事業にならない場合、システムの作りと事業の収益の形がつながっていないことが考えられます。どの操作が事業の価値につながるのか、どこで対価が生まれるのかが、システムの設計に反映されていないという状態です。
新規事業ではシステムが事業そのものになる場合も多く、システムの設計は事業の設計と切り離せません。この考え方は新規事業のシステム設計とビジネスモデルの作り方で触れています。
使われないと分かったときの判断：直す、絞る、やめる
確認の結果、思うように使われていないことが分かった場合、取れる選択肢は大きく3つあります。
直す
使われない理由が特定でき、直せば改善が見込める場合は、その部分を直して再度確かめます。たとえば、最初の登録の流れが長すぎて離脱している場合は、入力項目を減らして、同じ基準で再度測ります。
直すときのポイントは、一度に多くを変えないことです。いくつも同時に変えると、どの変更が効いたのか分からなくなります。
絞る
機能が多すぎて、価値が伝わりにくくなっている場合は、機能を絞って、最も価値の高い部分に集中します。利用者の声から、一部の機能だけが繰り返し使われていると分かった場合は、そこを中心に作り直すという判断も考えられます。
やめる
仮説そのものが外れていた場合は、事業をやめる、あるいは大きく方向を変えるという判断も必要です。やめることは失敗というより、大きな投資をする前に、小さく確かめられたということでもあります。
先に「どういう結果になったらやめるのか」を決めておくと、判断が感情に左右されにくくなります。具体的な考え方は新規事業の撤退判断｜プロトタイプで「やめる」と決める基準で整理しています。また、小さく作って確かめる投資判断の進め方は、新規事業の開発は小さく作って確かめる投資判断の進め方でも触れています。
作る前に、動く実物で確かめるという考え方
ここまでの確認の多くは、実物があると進めやすくなります。企画書や言葉だけで、「誰のどの場面で、どう使われるか」を想像するには限界があるためです。実際に画面を触ると、「ここは使わない」「この流れは長い」といった指摘が、具体的に出てきます。
従来の開発では、言葉だけで要件を決めることによる認識違いや、要件定義の抜け漏れ、食い違いが起きやすくなります。費用と仕様を先に固めてしまうことで、作った後に「思っていたものと違う」と気づく失敗にもつながります。「使われない」という問題も、この延長線上にあります。
そこで有効なのが、本開発の前に、動くプロトタイプで確かめる進め方です。プロトタイプを使えば、次のようなことを早い段階で確認できます。
- 想定した利用者が、説明なしで最初の操作を終えられるか
- 今使っている手段と比べて、どこに価値を感じてもらえるか
- 決裁者と現場が、同じ画面を見ながら、目的や優先順位をすり合わせられるか
- 使われた基準として決めた指標が、実際に測れる形になっているか
実物を見ながら話すと、認識のずれは早い段階で表に出ます。ずれを直すコストは、開発が進むほど大きくなるため、早く見つけられること自体に意味があります。実物を見ながらすり合わせる効果は、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせでも触れています。
また、動くシステムで事業のアイデアを確かめる手順は、新規事業のアイデア検証方法｜動くシステムで確かめる手順で整理しています。近年はAIを使った開発によって、プロトタイプを短い期間で作りやすくなっています。その仕組みはAIでプロトタイプを短期間で作れる理由｜工程ごとの仕組みで解説しています。
なお、プロトタイプで確かめる範囲と、本開発に引き継ぐ範囲を考えておくことも大切です。作り直しになるのか、引き継げるのかについては、MVPから本開発は作り直し？引き継げる部分と見直す点が参考になります。
まとめ
新規事業で作ったシステムが使われない原因は、開発の出来より、作る前と作った直後の確認にあることが多いです。この記事の要点を整理します。
- 「使われない」には、使い始めてもらえない、続かない、事業にならない、という3つの形があり、見直す場所がそれぞれ違う
- 作る前には、誰のどの場面の困りごとか、今の代わりの手段は何か、最初の一回の使い方、使われた基準、決裁者と現場の目的を確かめる
- 作った直後には、初めての人の立場で操作を確かめ、少人数から始めて、数字と声の両方から理由を探る
- 機能を足す前に、使われない理由が機能不足なのかを確かめる
- 結果によって、直す、絞る、やめるを判断する。やめる基準は先に決めておく
- 企画書だけで想像せず、動く実物で確かめると、ずれを早い段階で見つけやすい
使われない原因を、公開後ではなく、作る前や作った直後に見つけられれば、新規事業の判断はずっと落ち着いて行えます。
JustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断できる受託開発サービスです。仕様が固まっていない段階や、稟議を通す前の段階でも相談できます。新規事業のシステムを、動く形で確かめながら進めたい場合は、JustFitのサービス紹介をご覧ください。