個人開発の失敗から学んだことのメモ
個人開発の失敗から学んだことのメモ
個人開発を2年半やってますが、その中で色々学んだので、それをメモします。
1. 要件をちゃんとする
これが原点にして頂点で大事なことです。要件がちゃんと定まってないものをいくら作ってもしょうがないです。もちろん思いがけない成功というものはあるかもしれませんが、最初の要件が固まらないまま作ってしまうと、人に説明する時に終わります(実体験)。
対策
以下の項目をしっかりまとめる。なるべく丁寧にまとめる。解像度が荒いことを書くのはNG(例: 〇〇する人は困っているので、サイトを使って解決するなど)
自分の立場の明確化
-
背景・課題・目的の明確化
背景・課題: 現在どういう状況なのか、どういう課題があってそれをどうしたいのか。どのくらいその課題は深刻なのか。
目的: ユーザーに対して何をして欲しいのか、どのような体験をして欲しいのか、ユーザーがどうなって欲しいのか -
対象ユーザーの明確化
一体誰が対象なのか。具体的にSNSのアカウントの名指しレベルできるレベルで決める。個人開発であれば~30人いれば十分なので、30人ぐらいはリストアップできると思う。もし、サービスができたらDMリストにもできるし、作る価値は絶対にある。 -
市場背景整理
- 類似サービスの調査
- ユーザーの評価ポイントの整理
- 類似サービスはどのように集客しているのか
- ユーザーのボトルネックなところの調査
自分が何をするのか
- サービス戦略を考える
いわゆるコンセプト。自分のサービスは、この課題をこれを軸にして解決していくことを決める。
このコンセプトを使えば、最も効率よく最も多くの人の課題を解決できることを模索する。
よくあるコンセプトは、「安い、シンプル、高機能、おしゃれ、ストレスなし、管理コスト０、キャラクターが可愛い」など。
コンセプトのイメージをつかむためには、〇〇✖️カフェは確定しているコンカフェとかが参考になるかもしれない。このコンセプトはどんなユーザーをターゲットにどのような需要に対してどのように供給している（課題を解決してる）かを考えると視野が広がるかも
- 戦術を考える(具体的な機能の話)
ここはみんな大好きで大得意と思うので、特には触れないが、戦略の失敗は戦術では取り返せない。つまり、コンセプトの失敗を機能で取り返すのは無理である。
コンカフェを例に挙げると、需要ないわけわからんコンセプトのカフェは、どんな良いイベントやシステム、料理を取り入れたとしても基本的には詰みなのと同じ。そもそもそんな店求めてない。
具体的にユーザーが何をするか
- 典型的なユーザーフロー
気をつけるポイント としては、ユーザーのアクションフローによって、本当にユーザーの課題は解決しているのかを確認
本当によくあるのが、5.戦術 からスタートするパターン。こんな機能考えた後に、6.ユーザーフローを考えて、その後に、1.の課題を捻る出すパターン
これは、うまくいかないケースが殆ど。
自分の考えとしては、もう世の中の大抵のことは誰かがやっているので、まずはその人を真似ること。もしも誰もやっていないのであれば、必ず理由があるので、それを真剣に考えること。
2. 定義した課題は深刻か？
例えばちょっと便利ぐらいであれば、わざわざサービスを作ったとしても誰も使わない。ちょっと便利になるぐらいだったら新しいことをはじめるという労力よりもちょっと不便のままで良いから。
対策
具体的にどのくらい困っているかめんどくさいかを体験しよう。もし、そこまでじゃね？っと思うのであれば別にそのままでいいと思う。これは、我慢できないだろ。って思うのであればその課題は解決する価値があると思う。
3. ユーザーがサービスを想像できるか
人は想像できないものを敬遠することが非常に多い。それが仮に超実益があるものだとしても（格安SIMとか）。なので、基本的には、未だかつて類似サービスがなかったものに関しては手を出さない方が無難。
対策
開発する時は、「〇〇の〇〇バージョンみたいなもの」と一言で説明できることを条件にしよう。
4. 技術駆動型ではないか
これに関しては、もうみんな言っている。勉強のために作っているのか、人が使うために作っているのかははっきりした方がいい。
対策
課題を解決する以外の目的で新しい技術なんて採用するのはやめよう。
5. 定期的にアンケートを取ってユーザーが満足している自信があるか、定期的に使ってもらう工夫はしているか
これはありがちだけど、登録して終わりってパターンは非常に多いし、1.6のユーザーフローを考える時も、一回きりを想定して考えていることが殆どなため、そうなるべくしてなるケースが非常に多い。なので、どうやって思い出してもらえるか。どうやって、ユーザーに戻ってきてもらうか、戻ってきてユーザーが使いづつけて、ユーザーの満足度を高いまま維持できるかを考えないとまずい。
対策
恋愛と同じで、付き合ってからが本番というのを理解しよう。効果的な対策は俺も知らん。
6. 1課題に対して、1サイト
これは1の要件をちゃんとしていれば防げるが、課題を複数で、それれの解決策を複数ある場合、それを見せられた方は「なにこれぇー」ってなりやすい。あくまで一つのサイト、アプリに対して一つにしよう。昔みたいにとりあえず色々作ってればいろんな人が興味を持ってくれた時代は終わったのだ。
対策
要件定義をちゃんとしよう。
7.作ってすぐ見せるのはやめよう
残念ながら世間は我々の母親ではないし、世の中には高品質なサービスが出来上がっている。なので、公開するのは勝手だが、作り込んでない段階でユーザーに見せられても、ユーザーは困るだけである。
対策
なので、知らない人にいきなり見せるのではなくまずは友人や知人に、「作ってみたので、レビューもらえますか？」という風に進めた方が良い。説明しているうちに矛盾に気がつくことは多々ある。
最後に
世の中にはもうサービスはありふれているので、既存のサービスを横展開（ターゲットを変えるだけ）か、既存のサービスの強化バージョンを出す以外に一般人がユーザーを抱えるのは難しいと思う。
また、開発していて思ったのは、開発者バイアスの恐ろしさである。ものを作り始めた時点で、脳が勝手に物事を都合のいい方向に進めてしまい、現実を正確に把握することはできなくなったがために、人に見せた時に変な感じになったことが多々あった。
ものを作り始める前に要件をなるべく解像度高く作り、Figmaかなんかで外観だけでも作ってから、クラウドファンディングを使って需要があるかどうか募ってみるのが一番賢いと思う。
なにはともあれ、一回失敗してみないとこの感覚は身につかないと思うので、「なるべく短いスパンでPDCAを回し続ける」ことなのかと思う。
Discussion