ウェブサービスは、開発に入るといろんな機能を追加していくことになります。勘違いされやすいのですが、機能はたくさんあった方がいいかというとまったく逆で、プロダクトの本質はいかに機能をシンプルに保つか、いかにつくらない判断をするかが重要になってきます。
この記事では、なぜプロダクトに機能を追加するかどうかを判断する必要があるのか、判断のしかたについて書いていきます。
テクニカルライター。元エンジニア。共著で「現場で使えるRuby on Rails 5」を書きました。プログラミング教室を作るのが目標です。
なぜ機能を追加するかどうか判断するのか
プロダクトに追加する機能をしっかり判断する理由はふたつあります。それはプロダクトをシンプルに保つため、開発スピードを保つためです。
プロダクトをシンプルに保つ
まずひとつめ、プロダクトで重要なのはシンプルであることです。プロダクトが提供したい価値を、雑音なくユーザーにストレートに届けることです。それでユーザーに響かなければ、どんな機能をつけても響くことはありません。
たとえば「検索」という文脈でGoogleとYahoo!を比較してみるといいかもしれません。プロダクトをシンプルに保つために、追加する機能を判断する必要があります。
開発スピードを保つ
また、プロダクトの開発スピードも重要です。とくにProduct Market Fitを達成するまでは、開発スピードがなによりも重要な要素になってきます。たくさんの機能を実装してしまうと、ソースコード上も、ユーザーへの説明責任という意味でも身動きが取りづらくなってしまいます。BtoBのプロダクトならなおさらです。
機能はコストであると考え、コストをふやさないためにも追加する機能を判断する必要があるという認識が重要です。
どんな機能を追加すべきか
では、具体的にどんな機能を追加すべきでしょうか。これはプロダクトのステージによって変わります。まず、プロダクトがMVPであれば「その機能がないとプロダクトとして成り立たないもの」、PMF期であれば「プロダクトにあるべき機能」を追加します。
「プロダクトにあった方がいい（なくても問題ない）」というレベルの機能は決して追加してはいけません。この機能を追加してしまうと、プロダクトがシンプルでなくなり、開発スピードが一気に遅くなってしまいます。
機能の重要度
ここで、機能の重要度について考えてみます。機能とはそもそもユーザーのなにかしらの課題を解決するものです。この課題を重要度でレベルをつけると次のように分けられます。
- レベル1: 解決した方がいい（しなくてもいい）課題
- レベル2: 解決すべき課題
- レベル3: 解決しないと成り立たない課題
MVP期ではレベル3、PMF期でもレベル2の課題のみを解決する機能を提供し、レベル1の課題は決して解決しないようにします。
事例
たとえばレシピ共有サービスを例にみてみます。ユーザーはレシピの投稿や閲覧、検索がないとおそらくレシピ共有サービスは利用しないでしょう（レベル3）。あとで見たいレシピは保存できるべきですが、できなくてもさいあく検索でなんとかなります（レベル2）。
レシピに必要な材料を購入できるEC機能はどうでしょうか。あった方がいいかもしれませんが、なくても問題ありません。むしろ、あると「レシピを見る」という本質的な価値がぶれてしまい、離脱するユーザーが出てくるかもしれません。
まずは解決しないと成り立たない課題のみを機能として提供して、次に解決すべき課題にとりくみます。解決した方がいい、というレベルの課題は解決すべきではありません。あるいは、ECなどの大きな課題は別のプロダクトとして提供する可能性もあるかもしれません。が、まずは今つくっているプロダクトを成功させることを目指すべきです。
追加する機能を判断する方法
前章では機能の重要度について書きました。では、とある機能があったとして、この機能を追加するかどうかはどうやって判断するのでしょうか。これは4つのステップで判断していきます。
- ユーザーの課題を抽出する
- 課題の重要度にレベルをつける
- 解決する課題を決める
- 解決策をゼロベースで考える
1. ユーザーの課題を抽出する
とある機能について、その機能が解決しようとするユーザーの本質的な課題はなにか？を考えます。たとえばブログサービスにコメント機能をつけるかどうか。このアイデアの本質は「ユーザーは投稿者とコミュニケーションをとりたい」あるいは「記事に対して自分の意見を主張したい」などが考えられます。
2. 課題の重要度にレベルをつける
前章で示した3つの重要度、つまり次のように課題にレベルをつけます。
- レベル1: 解決した方がいい課題
- レベル2: 解決すべき課題
- レベル3: 解決しないと成り立たない課題
ブログの例だと、ユーザーと投稿者がコミュニケーションをとれないとプロダクトとして成り立たなければレベル3になりますが、たいていの場合そうではないでしょう。
3. 解決する課題を決める
これも前章で示しましたが、MVP期はレベル3の「解決しないと成り立たない課題」、PMF期は「解決すべき課題」に対して、追加する判断をします。解決した方がいい、というレベルの課題は決して解決しないようにします。
4. 解決策をゼロベースで考える
「追加するかどうか判断する」という問いの答えにはなっていませんが、よりよい機能として実装するために必要なプロセスです。解決する課題を決めたら、その課題を解決する機能をゼロベースで、つまりそれまで出ていたアイデアを無視して考え直します。
たとえばブログの例では、機能のアイデアは「コメント機能をつけたい」でした。これに関するユーザーの本質的な課題は「投稿者とコミュニケーションをとりたい」です。たんにコミュニケーションをとるだけなら、べつにメールフォームでもいいでしょう。
読んだことを伝えたいだけならリアクション機能があればいいかもしれません。あるいは「自分の意見を主張したい」ならTwitterでコメントつきシェアができればいいかもしれません。「コメント機能を追加する」というアイデアひとつでも、ユーザーの課題から見直すことでいろいろな解決策につながることがわかります。
「解決しないと成り立たない」はどう判断するか
解決しないと成り立たない機能かどうかは、どう判断すればいいのでしょうか。これは、プロダクトのミッション、あるいはフックモデルやグロースサイクルといったプロダクトについて定義している文書をもとに判断します。
万が一「あった方がいい」レベルの機能を追加してしまった、あるいはすでに存在している場合は、削除するよう計画に入れましょう。
ありがちだけどよくない例
ユーザーから「こういう機能がほしい」という要望をもらったりします。よくある、開発者にとってはうれしい話だと思います。こういった機能をそのまま実装してしまうケースが多く見受けられます。ただ、これはよくありません。「ユーザーを大切にしたい」という気持ちでやっているのかもしれませんが、これではユーザーにとって本当に価値のあるものは届けられません。
ユーザーはたしかにほしいものを伝えているかもしれません。ただ、ユーザーは自分にとって本当に価値のある機能がなにかをしりません。ユーザーが「こういう機能がほしい」といったときに、その機能の本質的な課題に目を向けるのが開発者の役目です。本質的な課題を抽出して、プロダクトが解決すべき課題であれば、よりすぐれた解決策を機能として提供する。
「解決した方がいい」レベルの機能であれば、なぜ採用しないのか？プロダクトの背景をもとにユーザーに示すことで、ユーザーの共感をつくり、プロダクトもシンプルに保てます。ユーザーからもらったアイデアをそのまま実装するのは、ユーザーファーストではなくたんなる思考停止だということを認識する必要があります。よりよい機能として提供して、ユーザーをおどろかせましょう。
まとめ
プロダクトに追加する機能は慎重に選択し、できるだけシンプルに保つ必要があります。判断基準としては、アイデアの中にあるユーザーの本質的な課題を抽出して、解決しないとプロダクトが成り立たない、あるいは解決すべき課題にのみ焦点をあてます。
重要度の高い課題についてゼロベースで解決策を考えることで、シンプルな機能をユーザーにストレートに提供することができます。
