プロダクト

個人開発で挫折しないための課題と機能の優先順位づけ

バートリーのさいとうです。

今回は、個人開発で挫折しないための課題と機能の優先順位づけというテーマで個人開発を進めていく中で得られた学びをサクッと紹介します。

  • 個人開発をして収益を得たい
  • 個人開発がなかなか前に進まない
  • 個人開発のモチベーションが続かない

以上のいずれかに当てはまる方には、以下で解説するアジャイルと優先順位という考え方を理解しながら、最後まで効率的に個人開発を進めることができるようになると思います。

陥りがちな罠

前回までの記事で、開発するプロダクトが解決する課題設定の話をしました。

もしまだ読んでいない方がいれば読んでみてください。

いざ解決する課題を決め、機能を決めていきます。

自分が全て決めて作ることができるので、どんどんワクワクしてこんな機能やあんな機能を作りたいと夢が膨らみます。ただし、ここで陥りがちな罠として

たくさん開発したいものがあることで、全部開発が終わらなくてリリースがどんどん遅れる

があります。

そうすると以下の弊害が出てきます。

  • 開発が終わらずリリース出来ない(=市場に出せず使ってもらえない)ことで、開発へのモチベーションが下がる
  • 本当は必要ではない機能を開発してしまうことで、プロダクトを通して提供したかった最大の価値に気づいてもらえない

意外と人間、最初にワクワクしていても、簡単にモチベーションが下がるものです。1人で開発しているので、自分が開発しなければそのプロダクトは一生リリースされません。

具体的には、本当にこれ作りたいんだっけ?と我に返ってしまったり、仕事が忙しくなるなどの外部要因によって、まぁいっかとなってしまう。

このような経験をされた方も少なくないんじゃないでしょうか。

なぜ陥るのか

なぜこのような罠に陥るかというと、以下のような誤解があるためです。

  • プロダクトは最初から完璧でなくてはいけない
  • 社会に出しても恥ずかしくないプロダクトを作らないといけない
  • できるだけ多くのことができるプロダクトでなくてはいけない

ここは人間の価値観なども影響してきます。「失敗したくない」と思えば(自分が考えうる)完璧なプロダクトにしてからリリースしたいと思ってしまいます。

ただし、これらはすべて全て誤解・勿体無い考え方です。
特に企画~最初のリリースまでの期間で望ましいのは

  • 最初は開発する機能に優先順位をつけて、必要最小限のプロダクトを作る
  • なるべく早くリリースする
  • 使ってもらってフィードバックを受けて改善していく
  • プロダクトを使う人や要望に合わせて継続的に肉付けのように機能の追加開発をしていく

となります。ではこれらを実現するためにはどうすれば良いのでしょうか?

どうすれば良いか

結論としては

  • アジャイル型の開発を行う
  • 課題と機能の優先順位を決めて、優先度の高いものから開発していく

詳細は以下で解説していきます。

アジャイルとは

アジャイル(英: agile)は直訳すると「俊敏/迅速である」という意味です。

次に説明する優先順位とProduct Prioritization Frameworkを理解するために重要なので、「アジャイルを知らないよ」という方向けにアジャイルとは?を説明します。
知っているよ、という方は読み飛ばしても大丈夫です。

特にベンチャーやスタートアップなどのソフトウェア開発の現場では、アジャイルソフトウェア開発という開発手法として取り入れられています。アジャイルソフトウェア開発宣言では、アジャイル開発に関わる人が重要視するべきポイントがまとまっています。

以下に最も端的にまとめられた最重要なポイントを引用します。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

アジャイルソフトウェア開発宣言

なぜアジャイルなのか

現代はVUCAの時代と呼ばれ、人類史上最も不確実性が高い時代なんて呼ばれたりします。

朝起きたら世界が変わるようなプロダクトがリリースされている、なんてことも最近多いです。直近リリースされ話題になっているChatGPT-4Github Copilot xのリリースはその最たる例です。

このように日進月歩で変化していく社会では、顧客が求めるものがどんどん移り変わっていきます。例えば、英語ができずに翻訳家が必要だと思っていたけど、もうAIに任せられそうだ、とかです。

だから、計画通りに進めること以上に変化に対応し、完璧なドキュメントを1ヶ月かけて頑張って作るのではなくまずは動くサービスを作り、契約やツールなどに固執せず、顧客からの要望や願いを叶えるために協調し最適な解決策を見つけるための対話を行うことが大切です。

アジャイルvsウォーターフォール

アジャイルと対極のウォーターフォール型という開発手法があります(元々ほとんどのソフトウェア開発はウォーターフォール型でした)。これらは、綿密に立てられた計画に従い、その計画通りに進める手法です。

建設現場やセキュアなプロダクト開発においては取り入れられるべき考え方ですが、個人開発ではその特徴自体が逆に弊害になります。

だから、アジャイル型で開発することを推奨します。

本当の課題を優先づけしてそれを解決する機能を作る

ここまででアジャイルとアジャイルソフトウェア開発について理解できたと思います。

勘の良い方は気付きつつあるかもしれませんが、ここで出てくるのが以下の疑問です。

必要最小限でまずは動くものをリリースすると言っても、何が開発するプロダクトの必要最小限と定義されるのかが分からない

ここで出てくるのが、解決する課題と開発する機能の優先順位をどのように決めるかという考え方です。

ここからは、解決する課題の優先順位の付け方と、機能の開発優先順位をつけるための手法を紹介していきます。

課題の優先順位

まずは課題の優先順位を決めていきます。

先に結論をお伝えすると、根本にある課題を最も優先順位の高い課題として設定します。

では、その根本にある課題はどのように見定められるのでしょうか?

簡単です。「なぜ?」と問えば良いのです。具体的には

その課題自体はなぜ生じているのか?

を考えていきます。

例えば、ダイエットできないという課題を解決しようとします。

この時点では、ダイエットできないのはなぜか?が明確ではないので考えてみます。

  • お菓子を食べ過ぎてしまうから
  • 運動する習慣がないから
  • 夜遅くにご飯を食べてしまうから

3つくらい思い浮かびます。例えば1つ目のお菓子を食べ過ぎてしまうことが課題だとしたら

  • お菓子を食べた日をメモしてアラートを出す

みたいな機能を搭載したプロダクトを作るのが良いかもしれないです。
しかし、ここに罠があります。

本当にその課題で良いのか?

よく考えてみてください。お菓子を食べた日をメモすることを継続できますか?絶対億劫になって続きません(鋼の意志を持つ方ならできるかもしれませんが、そもそもそういう人はアプリに頼らない気もします)。

ここからがポイントで、お菓子を食べ過ぎてしまうことが課題だと特定しましたが、更に2つの観点で課題を深掘ります。

  • お菓子を食べ過ぎてしまうのはなぜか?を深ぼる(本来の課題の深掘り)
  • お菓子を食べた日をメモするのが億劫になってしまうのはなぜかを深ぼる(解決策の課題の深掘り)

僕だったら以下のように考えます。

お菓子を食べた日をメモするのが億劫になってしまうのは、メモを毎日手動でするのが億劫だから
→ メモをする必要があるのはなぜ?
→→ 自動でお菓子を食べた履歴が残らないから
→→→ お菓子を食べるという行為を自動でログとして記録できたら良さそう!

最初の時点で定義した課題より詳細で根本的な、本当にユーザーが困っている課題を見つけることができていると思います。

この課題を最優先に解決する課題として定義します。

機能の優先順位

ここまで来れば、優先順位上位の課題を解決するためにどんな機能を作るかを考えるだけです。

とはいえ、その課題を解決する方法はたくさんあるので、Product Prioritization Frameworkを使います。

miroでこのフレームワークを使うとサッと作れるのでおすすめです。

設定する軸は

  • 価値があるかどうか
  • ユーザーから期待・想定されているか

となります。

具体的な手順としては以下の2ステップで行います。

  • 必要だと思う機能を全部書き出す
  • 書き出した課題を以下のマトリクス上で分類していく

そうすると以下の画像のようになります。

左上の分類した機能が、課題に対して最も期待されていて、かつ大きな価値を提供できる機能であると判断できます。

この判断が正しいかどうかは作ってリリースしてみないと分からないですが、少なくとも考えうる機能を全部作ろうとしてリリースが遅れたり、完成させられずリリースできない状態よりはずっとマシです。

なぜなら、リリースして使ってもらえる、もらえないにかかわらず、何かしらのユーザーからのフィードバックが受け取れるからです(使ってもらえないということは、課題か機能の設定がミスっている、もしくは知られていない(マーケティング領域)など、起きている問題を把握するきっかけになります)

ちなみに、画像の左上に書いてあるMVPとは

Minimum Viable Product

顧客に価値を提供できる最小限のプロダクト

のことを指します。

現状の開発

個人開発をする方に少しでも有益になれば良いなと思うので、プロダクトのことをまとめているページは公開しようと思います。

フィードバック等ありましたら、Notion上でコメントできるように設定しているのでよければお願いします笑

まとめ

まとめ
  • 個人開発では最初から計画通り完璧に遂行する事は難しい
  • 個人開発ではアジャイルソフトウェア開発の思想に則り開発する
  • 解決する課題と開発する機能に優先順位をつける

個人開発はプチPMの気持ちになれて楽しいですね。

最後まで読んでいただきありがとうございました。

COMMENT

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

CAPTCHA