2年ほど前から趣味でWEBサービスを開発しており、今まで学んだことを振り返ってみました。
「もし過去の自分にアドバイスを伝えられるなら」といったスタンスで書いてみましたので、サービス開発に興味がある方のお役に立てれば幸いです。
アイデア編
ユーザーの課題にフォーカスする
まずはアイデアを考える時、ユーザーの中にある痛みを解決するアイデアを考えます。
その思い浮かべたサービスによって、人の中にある「課題（痛み）」を解決できるでしょうか。人に使われるサービスというのは、総じてユーザーの課題に焦点を当てたものです。
課題のソリューション（解決方法）を考えるのは、まずは課題の質を上げてからにしましょう。
（もちろん趣味として開発する場合でしたら、使いたい技術を選択しそこからアイデアを考えるのもアリです）
差別化を意識しすぎない
誤解を恐れずに言えば、下手にアイデアの差別化をしないでください。アイデアそのものを差別化しようとすると、課題にフォーカスしていない、つまりは作り手である開発者視点の機能を実装してしまいがちです。
差別化というのは、ユーザーにとってより良い価値を提供するための結果論でしかありません。
その差別化は本当にユーザーのためになるのでしょうか。差別化が目的となっていないでしょうか。
「ユーザーの課題を解決する」サービスを作る事を念頭に置いておきましょう。
一言で表せれるサービスか
そのアイデアを一言で表現できないのであれば、アイデアの磨き込みが足りなかったり、ユーザーにとって核心を突いたアイデアでは無かったりする場合があります。
このサービスは（誰）の（課題）を（どのように）解決するのか一言で表せれるでしょうか。ここが明確になるほどサービスの軸のブレが少なくなります。またサービスのコンセプトを簡潔にするといった意味でも大切です。
自分が欲している物を作る
自分が欲しいと思うサービスであり、そしてアイデアの分野について詳しいのであれば尚良しです。
当たり前ですが、「自分ごと」であればあるほど実際のユーザーと同じ視線で開発に取り組むことができます。
またサービスを運営していると、勧誘を断られたり、誰にも使ってくれなかったりする時があって少しメンタルが傷つきます。ましてや一人で起業することとなれば、モチベーション維持は想像以上に困難です。そういった時に正常な心を保つためにも、自分ごとであることは大切です。
実装編
「あったら良い」機能は要らない
手を動かしていると、「こんな機能あったら良いな」と次々とアイデアが浮かんできます。きっと楽しいことだと思います。しかしリリースするのは、本当に必要なコアとなる機能だけにしましょう。
実際に「必要だ」という声を聞かず実装してしまえば、無駄に終わってしまうケースがほとんどです。その機能は9割以上の人が使うものでしょうか？「あったら良い（Nice to have）」な機能はリリース前に作るものではありません。
まずはその人の痛みを解決する機能だけを磨き込みましょう。
そのコードにテストは必要なのか
「テストが無いコードはレガシーコードである」
「テストを書く時間が無いのではなく、テストを書かないから時間が無くなるのです」
テスト界隈には様々な名言があり、私も同意見です。しかしこの言葉をきちんと咀嚼して取り入れなければなりません。
基本的に立ち上げ当初のサービスは変更の連続です。サービスをリリースし、ユーザーからのフィードバックを貰うことで、修正箇所は沢山出てきます。時には書いたコードの全てを捨て去るでしょう。
テストを書く際は、本当にテストを書く時間に見合ったメリットがあるのかを考えて下さい。それは誰のためのテストで、何のためのテストでしょう。テストはあくまでも効率化の手段です。書くとしても、初めは大まかな振る舞いテストで十分です。
リリース編
小さく立ち上げる
前述しましたが、まずはコアとなる機能だけをリリースします。完成度は75%ほどで構いません。大事なのはそのサービスが実際にユーザーに使ってもらえるものか確認することです。完成度を高めるよりも、まずはユーザーの反応を確かめましょう。
まだまだ無名な段階では「恥ずかしい状態」でどんどん出していく必要があります。
有料広告は不要
Life Time Value（顧客生涯価値、LTV）が分かっていない状態で有料広告を出すのは、穴の空いたバケツに水をいれるようなものです。広告出稿を始める前に、まずユニットエコノミクスを健全な状態に持っていく必要があります。
（ユニットエコノミクスについては、スタートアップのお金と指標入門講座が参考になります。）
例えば「顧客を400円で獲得して、その顧客によって200円を回収できる」という状態で有料広告を出しても、ただ200円の損失を重ねるだけです。このような状態はユニットエコノミクスが不健全であると言えます。
それに対し健全である状態は、「顧客を400円で獲得して、その顧客によって1000円を回収できる」というような、顧客を獲得すれば2～3倍の収益が生み出せれる状態のことを指します。
人が居なければまず身近な人、もしくはTwitterなどで興味を持ちそうな人に声をかけてみましょう。そのアイデアに自信があれば、積極的に声を掛けられるはずです。
バッサリ捨てる
「リリースした機能の反応が思っていたほど良くなかった…」
そんな時は思い切って削除しましょう。
今までの時間や労力が全て無駄になり心理的に辛いでしょうが、バッサリと捨てて下さい。サービスは変更の連続で、時には引き算も大切です。
Instagramは当初ただの位置情報共有サービスで、写真投稿はオマケの機能でした。YouTubeも初めは動画を使った出会い系サイト（デート相手のマッチングサイト）でした。
最初に思い浮かべたビジネスモデルが成立するケースはほとんどありません。
UXを磨き込み、できる限りの改善を行っても成功の兆しがなければ、思い切ってピボット（軌道修正）してみましょう。
そのピボットが成功のカギとなるかも知れません。
PMF（Product Market Fit）を目指す
スタートアップ界隈でよく聞くのがこのPMF（Product Market Fit）。具体的には「このサービスが無くなったらどう思うか？」という質問に対して、40%以上のユーザーが「非常に残念」と答えた場合にPMFが達成できたと言えます。
PMF達成を目指すには、AARRRモデルなどの指標を用いながらPDCAサイクルを回し続ける必要があります。
具体的な手法は「起業の科学 スタートアップサイエンス - 田所 雅之 (著)」という書籍で解説されています。アイデアの考え方からスケールまでが詳しく書かれており、サービス開発者にかなりおすすめの書籍です。
おおまかなPMF達成までの流れは以下の通りです。
- Customer Problem Fit（顧客の課題の質を高める）
- Problem Solution Fit（課題のソリューションの質を高める）
- Product Market Fit（サービスの質を高める）
「課題の質を高め」そして「課題のソリューションの質を高める」ことを意識しましょう。
あとがき
書きながら振り返ってみると色々学んだなーと感じます。
やはり心から技術の勉強を楽しめるのが、サービス開発の醍醐味ですね。これからも色々なモノを作っていきたいと思っています。