PBLのTA業務中にこんなやりとりがあったのと、毎年同じ話をしている気がするので、これを機にまとめてみます。
ハッカソンでさえも時々見かける、"どうしてもログイン機能から作ってしまう症候群"にかかっていて、自覚症状のないチーム。残念ながら、ログイン機能はそのチームが開発するプロダクトの本質でない場合が多いです。
限られた時間でのプロジェクトでは特に、プロダクトが解決したい問題により近い機能にそのリソースを割きたいものです。
MVPを理解して開発を進めることができれば、"どうしてもログイン機能から作ってしまう症候群"から解放されます。
MVP（Minimum Viable Product、最小実用プロダクト）とは、新しい製品やサービスを開発する際に、最小限の機能を備えた形で市場に投入する試作品のことを指します。これはユーザーからのフィードバックを早期に得て、その後の改良や本格的な開発に役立てるための重要な考え方です。
MVPの目的は主に3つ。
- 市場ニーズの検証
大きな投資をする前に、実際にユーザーが求めているかを小さな規模で確認できます。 - 開発コストとリスクの削減
全機能を作り込んでからリリースするよりも、早く安く開発できます。 - フィードバックの獲得
早期ユーザーからの意見を収集し、改善に活かします。
ユーザーからのフィードバックを頻繁に得ながらプロダクトに反映することで、そのプロダクトはよりユーザーに求められているものへ近づいていきます。頻度が高いことにより、「工数をかけて実装したのに、ユーザーに求められていたものとは違った」などという手戻り発生のリスクが減少します。
その観点で言えば、ログイン機能へのフィードバックが必要とはいえません。ログイン機能が必要かどうかは、プロダクトの他の機能によって決まることです。また、ログイン機能は、他の多くのプロダクトで実装されています。
"そのチームが新たに挑戦する本質的な機能へのフィードバックをできるだけ早くもらう"、そこにリソースを割くことが、ユーザーが求めているプロダクトを効率的に開発する方法なのです。