Feedback Loop

昨今のWebサービスは作ることよりも使ってもらう方が難しい。技術の進化により作ること自体はかなり簡単になった。小慣れた機能や美しいデザインも作れる。難しいのはサービスを知ってもらい、そして使い続けてもらうことである。

「ビルドインパブリック」という手法がある。これはリリースしたサービスの開発状況や改善の様子をXやブログで公開していき、それによりサービスのユーザーを増やしていく方法。自分の使っているサービスの新機能が出来上がっていく様子を知れるのは何となく面白い。リリース時点では機能が足りてなくても、その後すぐに追加されそうであれば利用を続けてもらえる可能性もあがる。そんな事情もあり、特にXなどでコミュニティが形成されている開発者に向けたサービスなどではビルドインパブリックがよく用いられている。

認知してもらうには継続的な発信が必要だが、自分の開発しているものであればネタには困らない。そういう意味でビルドインパブリックはよくできた手法だが、個人的には落とし穴もあるように感じる。開発で難しいのは後方の互換性を保つことで、新しい機能をリリースする際に他のシステムや過去データが壊れないように気をつけるのは思った以上に難しい。公に発信するとなるとトピックが欲しいので次々とリリースすることに力学が働くが、突貫で作ってしまうと負債になり後半の開発にブレーキがかかりだす。では作り込んでから一気に出せば良いかというとそうでもない。市場のタイミングを逃すリスクがあったり、リリースしないとそもそも反応がないので誰も必要としていないものを作り込んでいる可能性がある。結局はバランスということになり、どこに重心を置くかは開発チームの性格によって違いが出る。

日本だと有名なのはInkdropというサービスを開発しているTakuyaさん。開発の様子や考えなどを発信しながらファンを増やされている。見た目上はブログを書くだけなので簡単に見えるが、その内容が芯を喰ったものであったり、その人なりの考えがあって読み応えがあったりでないとすぐに人は離れてしまう。そして何よりまず魅力的なプロダクトがあるというのが大前提。そもそも価値のないプロダクトでは周りをどれだけ豪華に飾っても真に響くことはない。それに良いプロダクトであればそれ自体に宣伝効果がある（クチコミで広がる）。まずはコアのプロダクトに集中、そして次に広める。どちらも大事だが、順番があることは忘れないようにしたい。