プロダクトを構築しよう

いよいよプロダクトを構築していきます。ただ、構築には数ヶ月単位でかかるので、構築だけに焦点をあてても開発とマネジメント両面で数十ページのボリュームになってしまいます。このガイドは入門編なので、構築時のプロダクトマネジメントについて簡単に書きます。詳しくはこのセクションを切り出した発展編を別途執筆中なので、そちらをご覧ください。

それでは、このセクションではなにをするのでしょうか。つまり、プロダクトを構築するときに、プロダクトマネジメントの観点でもっとも重要なことはなんなのでしょうか。それは「どの機能を入れるかを判断すること」です。

プロダクトに入れる機能については、ユーザーストーリーマップで決めました。ただ、ユーザーストーリーマップにある機能がすべてではありません。開発していく上で、新しく必要になってくる機能が出てきたり、逆に不要な機能も出てきます。

必要なものは一旦全部入れて、いらなくなったら消せばいいのでは?と思うかもしれません。ただ、この考えはよくありません。機能はシンプルに保ち続ける必要があります。でないと、ユーザーにもっとも提供したい主要な機能の価値が薄れてしまいます。また、コードが複雑になって開発スピードが遅くなってしまいます。

では、どういう基準で入れる/入れないの判断をすればよいのでしょうか。それは、「その機能がないとプロダクトが成り立たない」機能のみを入れるようにします。

リーンキャンバスで、解決したいユーザーの課題を決めました。これをもとに、「その機能がないとユーザーの課題を解決できない」機能のみを入れるようにします。そうでないなら入れないか、あるいは削除します。この基準を守り続けることで、プロダクトをシンプルに保つことができます。これをもとに、プロダクトを構築していきましょう。

まとめ

プロダクトマネジメントという文脈で、プロダクト構築時にもっとも重要なのは機能をシンプルに保ち続けること。「それがないとプロダクトとして成り立たない」機能のみを入れるようにします。

やってみよう

プロダクトを構築しましょう。このとき、機能について入れる・入れないの判断をして、プロダクトをシンプルに保つよう心がけてみましょう。

関連記事

プロダクトに入れる機能を判断する方法については、「プロダクトに機能を追加するかどうかを判断する方法」で詳しく解説しています。あわせてご覧ください。

例: tsukuri

グロースサイクルや利用規約をつくり終え、ようやくプロダクトをつくることにしました。機能は、ユーザーストーリーマップをもとにつくっていきました。ここまでで課題や解決策、MVPをしっかり検証してきたので、「ユーザーに使ってもらえる」という手応えがあり、これがやる気をより出してくれました。

構築をふりかえってみると、ユーザーストーリーマップにある機能自体は1ヶ月でつくり終えました。それ以外の機能やインフラ構築などをふくめると、全体で3ヶ月で構築がひとまず完了しました。

ふだんからいろいろ上がってくるアイデアに対して、とにかくつくらない判断をして機能をシンプルに保てたのがよかったです。もちろんつくる判断をした機能もありますが、考え抜いた上でつくる判断をしたので、効果的な機能になりました。システムが複雑になりすぎず、開発スピードを保つことができました。

ただ、つくり終えるまで一度もユーザーに見てもらえないのは不安なので、構築と並行して次のセクションにあるプロダクトインタビューを実施しました。

著者
Hiroki Zenigami

テクニカルライター。元エンジニア。共著で「現場で使えるRuby on Rails 5」を書きました。プログラミング教室を作るのが目標です。

スポンサーリンク

ブログをはじめよう

技術ブログの始め方を、たくさんの画像で分かりやすく解説しました。これまでブログをやったことがない人でも、エンジニアにとって重要なブログを今日から始められます。

ブログをはじめる