今回は、他の方のWebサービス失敗談から学ぼうという話です。何回かこの視点で書いていますが、どんどん見つけ次第やっていこうというところです。
今回は、自作webサービス失敗談という記事からです。
宣伝し合うサービスが参考になる
記事の2番目にあるお互いに宣伝しあうサービスが参考になります。本サービスとは異なりますが、宣伝するというところは共通だからです。
実際に本サービスにおいても、サイトのコンセプトとしてはWebサービスに特化しています。よくあるのが単なるWebサイトやブログの投稿ですがこれらは原則掲載していません。また初期の頃はスマホアプリもオッケーでしたが特化するために対象外としました。
投稿したサービスがとくにクラウドサービスというかドメインが独自でないものだと、結構さくっと消えるので、それもチェックする意味でリンクチェックをしています。これをすることで「掲載数」という数値は減るのでインパクトは減るのですが、数で勝負できるとは思ってないのでここは諦めて、どんどん逆にリンク切れなら削除しています。
速報性などは他のサービスが優秀で、あとはスタートアップ向けとかもありますよね。個人開発とスタートアップの違いは開発者やチームの意図で明確に分かれるはずですがそこまで分かれてないのも現状かもしれませんね。というところで言えば、本サービスは個人開発よりです。スタートアップ的なものは応援はしますし掲載も出来るのですが、どっちかというと基本コンセプトがどうすれば個人で色々宣伝できるかというところだからですね。
弱小サイトが宣伝する今の考え方
記事戻すと、他の敗因として、モチベーションの欠如だったり、サイトとして集まるサイトが小さいサイトばかりなので宣伝効果が生まれないとか、色々です。ただ著者は、弱小サイトがお金をかけずに宣伝する方法が欲しいということもいっていて、全く同感です。
僕自身も同様に感じていて、多分今の結論というか、最適解になるんですが、
- 個人開発者などでなにかこうすればうまくいくという大きな宣伝媒体はない(仮にあってもそこが資本となったりするので、結果的に低単価×大量利用者となるが、そういう100均ショップモデルみたいなのはきつそう。なぜなら大量利用者となる一般ユーザーはそこまで個人サービスに興味がないから。また個人開発者自体も驚くほど少ない。驚くほどとは、想定するほど少ないはず。感覚的には10人いて業務でプログラミングをやって趣味でプログラミングは一人くらい。そこでさらに自分でサービスはこれって言う人はさらに一人。つまり1%くらいのイメージ。仮にWebエンジニアみたいな人が100万にいても、1万人規模。これがMAXだとマネタイズにもよるが市場として厳しそう。出来るって人もいるかもだけど)
- 個人支援サービスをモチベを維持しつつ、ある程度個人開発が成功(大成功じゃなくても)した人が宣伝もするみたいな、いわゆる卒業モデルっぽいものがいい。生態系モデルというか。コミュニティモデルというか。そういう個人開発者の成功者達が出資したり本業に影響を与えない範囲で、ファンドというか出資したりこのサービス面白いから投資したりとかってのが良い。これをスタートアップみたいに上場かM&Aみたいにせずに、いわゆるレベニューシェアっぽく、利益に応じて売上に応じて共有するイメージ。このモデルの課題は、そういう成功者が徒党を組めるかってことと、実際に個人開発でもそれでやっていくという熱と行動ができる人がどこまでいるかという課題がありそう。かつ、スタートアップでなくても、Webサービスの起業となるのでそう甘くないところで、成功率から回りづらいというのもある。
- 個々の個人開発者支援サービスを各自のモチベでやり続けていって、いわゆる地域リーグみたいに、どこどこのサービスで目立ったものはこれだから推薦する。登竜門モデル的なもの。個人的には在野の人を発掘していくのが面白いので、これが面白いかなと。ただこの課題は、そもそも自分のように支援系サービスをモチベを保ちつつやり続ける人は少ないし、相当厳しいのではないかというところ。年に数人いるかどうかというか、発掘できてないだけど。ただこういうのって可視化されると、「ああそういう人いるんだ、自分もやろう」みたいになる流れもあるので馬鹿にできない。小さい力を蓄積するイメージ。マッシュアップアワードみたいな感じの規模にする必要はないけど、それくらいカジュアルな感じでやれるのが良さそう。
という感じに考えています。マーケティングというところでは、もっとマーケティングが出来る人が個人開発や個人Webサービスというところにガンガン出来てくると流れが変わりそうですが、あんまりそういうパターンはないかもですね。たまたま個人開発とマーケティングが合致することはあっても、マーケティングは何でも使えるので、あえて縛る必要はないとも思うので。
失敗談から得られる最適な開発すべきサービスとは
最後に著者が教訓をまとめています。
そこから言えそうなのは、例えばですが、ユーザー投稿型にしないことで、コンテンツ自体の過疎問題を避ける。これはツール系サービスってことですね。ツール系は誰が使っているとか関係ないので、逆に誰かが使っているとか分かればプラスにはたらくのみですね。もちろん、本当に大丈夫か?みたいなサービスだと駄目ですけどね。
ツール系で、自分が使いたいサービスというところに寄せていくと、ドッグフーディング(自分で使う)出来てモチベ低下になりづらい。ただ自分が使う以上の何かにしづらいという完結してしまう課題もあり。
早く作って試す方が良い。これはMVPとか、リーン型とかもそうですね。結局コンセプトとか、提供する価値はなにかって話になってくる。そこを早く検証して、受け入れられるかどうかを調べていくと。
じゃあツール系で自分が使いつつも他の人が使ってくれるものってなんだろうかってなります。ツールってもはや過剰に溢れていてなかったから欲しいみたいなのも結構辛いのかなと。全くないわけではないですが、情報の伝達が早いのとすぐ消化されるのでなかなかというところですよね。自分主体で考えるとネタは限られそうですが、誰かの課題を解決するという企画視点でいくとまた広がりそうです。
僕の中ではこれらをWebサービスで絞ってやることもいいのですが、あくまでWebサービスは手段ではないかというところです。IT好きな人がアナログ好きなのが、僕は好きなんですけど、そういうアナログとデジタルの融合がいいのかもしれないですね。ジャストアイデアですが。

「Webサービス集めました」のひとり企画兼編集兼運営者。他、ビジネスアイデアメディア「シゴクリ」運営者でもある。アイデアをこよなく愛し、そのアイデアが形にするかを検討し続ける、ゼロイチ大好きアイデアマン。ビジネスアイデア提案、アイデアの壁打ち、起業相談等の実績多数あり。Webサービスという新たなアイデアが詰まったものに触れられるのが好きでそんな人や会社を応援したくて本サービスをやっています。