ボクココ

サービス開発を成功させるまでの歩み

良いサービスの作るシンプルな考え方

ども、@kimihom です。

f:id:cevid_cpp:20170929233715p:plain

今回は Heroku Meetup#18 で LT してきたので、その内容と発表後記的な感じでまとめてみる。前に書いた記事を基にしているので、被る部分もいくつかある。

LT 登壇資料

まずは以下の資料をざっと見て欲しい。言っていることは至ってシンプルな内容である。

顧客がブランド名を聞いて思い浮かべるのは極わずか

パッと有名なブランド「ディズニー」 や 「Starbucks」 などを聞いて皆さんは何を思い浮かべるだろうか?きっと1つもしくは2つのことだけをイメージしただろう。各ブランドは当然、その他にも色々なビジネスをやっているだろうし商品を販売している。だけども、ブランド名を聞いて、それが良いか悪いかは象徴的な数個の特徴だけをベースに判断されるのである。

当然、私たちがこれから作る新しいサービスも同じ運命にある。どんなに色々な機能を作っても、顧客がそのサービスを評価するのは、象徴的な1,2 個の特徴のみである。だからこそ、サービスのコア機能を磨き続けることが、良いサービスを作って成功させるための唯一の条件である。

よくある悪い例を説明しよう。例えばあなたは晴れてサービスをローンチできたとする。そこで何名かの顧客にフィードバックを得ると思うのだけど、"こうしたら使う"的な 回答が得られた時に、作ってしまったサービスをベースに "機能追加" によって対応してしまうことがよくある。これこそがそのサービスの失敗に足を踏み入れる第一歩だと思っていただきたい。

「いやいや、俺はそんなことしないよ」と思っている方もいるだろう。それは、"別サービス名としてサービスをローンチする" というやり方だ。Yahoo! ニュースと Yahoo! ショッピング があるかのように。改めて思い出していただきたい。そのブランド名を聞いて顧客が思い浮かべるのはたかだか1,2 個だ。まだ評価すらされていない段階で、このようなサービスの多角化は、顧客がそのブランドを評価してもらうのを迷わせてしまう。それは、そもそも良い悪いの判断をする以前の段階であり、致命的な問題だ。

ブランドを大切にしつつもそのブランドで良い印象を持っていただくために、1つのコア機能で圧倒的な印象を与える。それがサービスを成功させるためのシンプルな条件である。

1つのコア機能を持った最低限のプロダクトをよく "MVP" という表現で表される。誰だって、最初の一歩のリリースは MVP になるのは当たり前でできて当然だ。しかし、問題はローンチした後だ。ユーザーの調査などを通じてサービス/機能削除をせずに "機能追加"で対応してしまうようでは、MVP の "エ" の字もやりとげていないということを自覚するべきである。

全てをぶっ壊せば良いのである。今までそれが例え何ヶ月かけて作ったものだとしても。

正しいインフラを選ぶことが、サービスの運命を左右する

この記事は、サービス開発をあくまで自己満で終わらせるのではなく、多くの顧客に使ってもらうようにするための記事である。その意味で何度もこのブログで言及してるけど、仮説検証の段階でインフラにこだわることほど無駄な時間はない。以下に早く仮説検証できるかって意味ではそもそもサービスを作り始める前からプロトタイプなどで聞き込みだってできることだろう。

これは何もスタートアップだけの話ではない。個人開発を成功させたいというエンジニアの方も多いことだろう。エンジニアが1人で開発するとどうしても自己満で終わってしまうのだけども、それは自分のやりたいこと以外に集中できないと、単なる作業になってしまって飽きるという問題が考えられる。正しいインフラを使えば、あらゆる面倒な作業は自動化できよう。

ではどんなインフラを選ぶか。先ほどの資料に回答の1つを載せているので、よろしければ検討いただけると幸いである。

終わりに

来いよ高みへ! 自分の作ったサービスで日本中、世界中の人たちから使われるサービス。誰かから言われて訳のわからない機能を作らされるのではなく、自分の意思でサービスを改善し運営して生きていく。今の時代、そんな自由を手に入れられる土台が整っている。

もちろんその実現のためには1人エンジニアだけでは足りないかもしれない。ただ、あなたのその思いに共感した人たちと手を組み、正しい選択と実行を伴えば 夢物語ではなくなってきている。

皆さんのサービス開発の成功を心より祈りつつ、次回の Heroku Meetup を楽しみにしている。