技術力には自信があった。企画にも自分なりの手応えがあった。それでも、リリースした自社サービスに、顧客がまったく付かなかった——そんな経験があります。

以前、SNS投稿をサポートするツール「楽きじ」というサービスを、企画から開発、運用、営業まで一人で担当してリリースしました。しかし、結果として顧客はまったく付きませんでした。25年以上、受託開発では数々のプロジェクトを成功させてきた自負がありましたが、自社サービスとなると、まったく勝手が違うことを痛感した経験です。この記事では、この失敗から見えてきたことと、顧客を付けるために今実践していることをお伝えします。

何を作ったのか

「楽きじ」は、SNSへの投稿作業をサポートするツールでした。技術的には特に問題なく動くものが作れており、機能面でも一定の完成度があったと感じています。しかし、リリース後、ユーザーがまったく増えませんでした。

企画・開発・運用・営業まで一人で担当していたため、良いものを作れば使ってもらえるはずだという思い込みのまま、開発に多くの時間を注いでしまっていました。振り返ってみると、これこそが最大の問題だったと感じています。

なぜ、顧客が付かなかったのか

1. 「作れるもの」を作ってしまっていた

受託開発の現場では、顧客からの要望を起点に開発を進めるため、「本当に必要とされているもの」から自然と離れにくい構造になっています。しかし、自社サービスでは、その"顧客からの要望"という制約がありません。結果として、自分の技術で作れるもの、作りたいものを優先してしまい、「本当に困っている人が、お金を払ってでも欲しいと思うものか」という視点が弱くなっていました。

2. リリース前に、誰にも困りごとを聞いていなかった

企画段階で、実際にSNS投稿に困っている人に直接ヒアリングするというプロセスを、十分に行っていませんでした。自分の中で「きっとこう困っているはずだ」という想定だけで機能を決めてしまい、実際の利用者の声を反映せずに開発を進めてしまったことが、大きな反省点です。

3. 「作ってから広める」という順序になっていた

開発が完成してから、営業や告知に力を入れるという順序で進めていました。しかし、この順序だと、開発に費やした時間の分だけ、「本当に需要があるか」を確認するタイミングが遅くなります。需要が読めないまま開発期間を長く取ってしまったことが、結果的にリスクを大きくしていました。

4. 「なぜ、今のやり方で困っている人がそれを使うのか」の説明が弱かった

同じような課題を解決する方法は、無料のツールや、既存のやり方（手作業、他のサービスの組み合わせなど）としてすでに存在していることがほとんどです。「なぜ、既存のやり方から乗り換えてまで、このサービスを使う必要があるのか」を、明確に言語化できていませんでした。ここが弱いと、どれだけ機能が良くても、利用者が"わざわざ変える"動機を持ってもらえません。

この経験から、顧客を付けるために変えたこと

現在、お問合せ対応用のAIチャットボットを新たに開発していますが、この経験を踏まえて、進め方を大きく変えています。

1. 開発前に、小さくても検証できる形を用意する

いきなり本格的な機能を作り込むのではなく、最小限の機能でまず動くものを用意し、実際に使ってもらえるかを早い段階で確認するようにしています。開発に時間をかけすぎる前に、「本当に欲しいと思ってもらえるか」を確かめる方を優先しています。

2. 「誰の、どんな困りごとを解決するか」を、一文で言えるようにする

サービスの説明を、「誰が」「どんな場面で」「何に困っていて」「それがどう解決されるか」という一文にまとめられるかを、企画の最初に必ず確認するようにしています。ここが曖昧なまま進めてしまうと、「楽きじ」のときと同じ失敗を繰り返すことになります。

3. 価格や導入のハードルを、最初から具体的に想定しておく

機能を作ることだけに意識が向いていると、「実際にいくらなら使ってもらえるか」「導入までの手間はどのくらいか」という視点が後回しになりがちです。今は、企画の段階から、価格帯や導入のしやすさを具体的にイメージしながら進めるようにしています。

4. 開発と並行して、認知を広げる動きを始める

「完成してから知ってもらう」のではなく、開発の途中段階から、どういう人に向けたサービスなのかを発信し、興味を持ってくれそうな人との接点を作る動きを並行して進めています。完成を待たずに反応を集めることで、方向性の軌道修正がしやすくなります。

5. 一人で完結させず、外部の視点を早めに入れる

自社サービスの企画・開発・運用・営業を一人で担当していると、自分の思い込みに気づく機会が減ってしまいます。今は、開発の初期段階から、身近な人やターゲットに近い人に率直な意見を求めるようにしています。「良い機能だと思う」という感想より、「お金を払ってでも使いたいか」を率直に聞くことを意識しています。

失敗から得た、一番大きな学び

技術力があれば良いものは作れます。しかし、良いものを作ることと、顧客に選んでもらえることは、まったく別の努力が必要だということを、この経験から痛感しました。

受託開発では当たり前にできていた「相手の困りごとを起点に考える」というプロセスを、自社サービスでも同じように、企画の最初から徹底する必要がある——これが、この失敗から得た一番の学びです。

まとめ

自社サービスに顧客が付かなかった経験から見えてきたのは、次のような点です。

  • 「作れるもの」ではなく「求められているもの」を作れているかを常に問い直す
  • リリース前に、実際の利用者の声を聞くプロセスを省略しない
  • 開発してから広めるのではなく、小さく検証しながら進める
  • 「誰の、どんな困りごとを解決するか」を一文で説明できる状態にする
  • 一人で完結させず、外部の率直な意見を早い段階で取り入れる

技術があるからこそ「作れてしまう」という状態は、時に危険にもなり得ます。作る前に、本当に必要とされているかを確かめる仕組みを、企画の段階から組み込んでおくことが、次の自社サービスを成功させるための一番の備えだと感じています。