製品リリース後の追加開発の優先順位の付け方講座

必要最低限の機能を持った製品（Minimum Viable Product, MVP）の最初の立ち上げは大きな一歩だ。それは、あなたが、何かを人々の手中に送りだして試してもらうことを意味する。これは立ち上げですらなく、１つのプロセスの始まりであるということを頭に入れておかなければならない。しかし、あなたは外の世界に出て、人々はあなたの製品を使っている。

そして今あなたはスタートアップ企業にとって最も厳しい課題に直面する：次は何を作るべきか？

あなたが、自分が作りたいと思っている、もしくは必要だと考えている機能の長いリストを持っている可能性は高い。しかし、あなたは自らの消去プロセスである程度厳しかったため、それらをMVPに採用することはなかった。今、多少のパニックが入り込んでいるのは、MVPが最高ではなく自分が重要だと思う機能を数多く抜いたことを自分で分かっていて、さらにフィードバックも転がり込み始めているからなのだ！あなたは自分の優先リストを持っているが、顧客も自分達が欲しいものを言ってくる。顧客自身で見つけたいくつかのバグだけでなく、機能のリストを渡してそれをあなたに作って欲しいと言うのだ。そう、顧客は、常に正しい・・・そうだろうか？

そうとも限らない。

ここに素晴らしいタイトルの記事がある：顧客のフィードバックが役に立たない理由。これは絶対に読んだ方がいい。さあ今すぐにでも読みに行っていいので、またここに戻って来るのだ。もしくは、この記事を読み終わってからそっちに移動してもいい。どっちにせよ、この記事は読んで欲しい。いいだろうか？

最初のMVPリリース後に機能開発を優先付けするのはとても難しい。実際、私と私の仲間が世に放った（限定的なリリース）Localmindでそれに直面している。カスタマーフィードバック、クレーム、称賛、私達自身のブレーンストーミング、忠告など、そこにはアクティビティがあふれているのだ。さらに、私達はTwitter、Facebook、Uservoice、Eメールなど複数の情報源をモニターしなければならない。

だから、私達はいくらかの試練を経て、プロセス全体の完全な制御を失うことなく機能開発を優先させるのを手助けするプロセスを考えた。

まず第一に、私達は以下のことを忘れずにやっている：作る→測る→学ぶ

私達が何か作ったとしたら、その影響を測定し、そこから学ぶことができるのが好ましい。それができなければ、私達はなぜそれを作っているのかという疑問を持たなければならない。なぜなら、真ん中辺りで自分達が正しいのか間違っているのかを知るのが難しくなるからだ。

Lenny (Localmindの創設者)は、Localmindの成功とパフォーマンスを判断するための主要メトリクスを追跡するいくつかのダッシュボードを作るという素晴らしい仕事をした。彼は、GeckoboardとMixpanel（註：共にウェブの効果測定サービス）を使用しているが、どちらもチェックする価値があるだろう。前もってメトリクスを持つことは、私達にある程度の現実と推察力を見に付けさせる。たとえユーザーが参加しているのを目にして興奮が高まっていても、一歩引いて私達が特定した主要なメトリクスを見て、“ちょっと待って、誇大広告はそれはそれでいいし、面白いが、このメトリクスは私達が求めているものとは違うぞ”と言うことができるのだ。

私達は、機能開発を優先付けする助けとするために自分達のメトリクスを（私達が常時得ているフィードバックと共に）重視しているのだ。

次に、私達は高いレベルの優先度を以下の二つの主要なカテゴリに分類した：

1. 保持力 / エンゲージメント
2. 拡散力 / バイラリティー

私達が作ることを考えている全ての機能は、これら二つのカテゴリの1つに適合しなければならないのだ。もし当てはまらなければ、私達が近い将来にそれに取り組むことはない。さらに、これらの二つのカテゴリにも優先順位がある。保持力 ＞拡散力（少なくとも今のところは）である。これはどんなウェブアプリケーション（B2BでもB2Cでも）の場合もそうであると言っておこう・・・。もし大量の人が登場して、彼らが滞在もせず、戻っても来なかったら、そもそもそんな人達をそこに登場させる意味があるだろうか？彼らに再度売り込みをすることによって取り戻すことも可能だが、それは簡単なことではない。

多くのB2Cアプリケーションにおける課題の1つが、より多くのユーザーを抱えている時に保持力を上げることだ（それは主として拡散力が求められる）。それはどちらが後か先か分からない問題だ。私は、これが多くのスタートアップ企業が、大量ユーザーを目指し、保持力で弱い製品を数だけで埋め合わせることを願って、最初に拡散力に集中して取り組くむ原動力になっていると考えている。あり得ないことではないが、とても危険なことだ。

この簡単なカテゴリ分類は、私達に1つのはっきりとした疑問を浮かびあがらせる。“提案された機能は保持力または拡散力を改善するのか？”　もし答えが“イエス”（もしくは、少なくとも“そう思う！”）なら、それをリストに追加し、そこから優先付けを続けるだろう。

各カテゴリの中でさらに優先付けは行われる。私達が保持力を上げると考えている機能のアイディアは20あるかもしれないのだ。ではどれを最初に作るべきなのか？

ここにあなたも使うことができる基準をいくつか紹介する（重要度順）:

• なぜ? – その機能が保持力またはバイラリティーを改善するに違いないとあなたが考える理由が必要だ。Localmindでは、私達はユーザーを楽しませる方法やサプライズを実行する方法について多く考える。最近ではGamification（ゲーム化）が、保持力向上の1つの方法として大流行しているが、“その辺でいくつか手を打とう。みんなそれを気に入るだろう！”と言うのは簡単だと思う。実際にはもっと難しいものなのだ。“なぜ”と疑問を投げることは、特定の機能について仮説を紙に書き出し、それに則して質的および量的に直接テストをすることができることを意味するのだ。
• 仮説全体の検証– スタートアップ企業を始める時、あなたは、仮説を書きだしてそれを検証しようとする。あなたが作るどんな機能もそれらの仮説の確証または無効化に向かっていなければならない。
• 測定できるかどうか – 機能の影響は測定可能でなければならない。これについては前述している。
• 開発時間 – 時間はスタートアップ企業の最大の敵の1つだ。各機能に要する相対的な開発時間を比較する必要がある。
• ユーザーにとっての複雑性 – 複雑性は、ユーザーのウェブアプリケーションにおける体験を含め、数多くのことを台無しにしてしまう。初めの頃は特にそうだ。“それからこれもあったらいいな・・・”で始まる言葉を並べると、提案された機能があまりにも複雑になってくることは分かっているはずだ。こうなってくると成功の敵である。
• リスク – 新しい機能を作る時には常に何らかのリスクがつきものだ。コードベースにどれほどの影響を及ぼすかという点においてある程度の技術的リスクがある。また、人々がどんな反応を示すかという点でのユーザーリスクもある。さらには、新しい機能が今後の開発をどう後押しするかという点からのリスクもある。あなたが進みたくない道に向かわせる可能性もあるのだ。
• 新しいアイディア – 機能性の構築はとても簡単だ。アイディアを盗むことができる他のウェブアプリがあふれている。それでも構わない。しかし、創造性が際立っているかどうか、人々に“おお、これはすごい”と言わせる可能性があるかどうか、新しい機能の革新さを見ることに価値はある。
• ユーザーの意見 – ユーザーは重要だ。彼らのフィードバックが重要になる。しかし、それに頼るのは危険だ。時には、彼らのためにも彼らをうまく利用する方が良い。圧倒的な数のユーザーが何か1つのことを求めている場合でも、それが正しいことではないかもしれないのだ。それは彼らを無視しろという意味ではない。もちろん、素早い前向きなフィードバックとカスタマーサービスは絶対に必要不可欠なものだ。しかし、彼らが欲しいと言っている機能を自動的に優先させてはいけない。

気を散らすものがスタートアップ企業を台無しにする。それらはとてもゆっくりで、あなたはそれが起きていることに気付くことさえないかもしれないが、常に起きているのだ。きちんと優先順位づけされないままに機能開発が行われれば、機能開発それ自体が気を散らすものになることもある。作ることを目的に何かを作ることが、スタートアップの首を絞める。だから、機能開発に対して厳しく正直な優先順位付けのプロセスを設けることが、気を散らすものを制御して無駄を省くためには重大な意味を持つのだ。

この記事は、Instigator Blogに掲載された「How To Prioritize Feature Development After Launching an MVP」を翻訳した内容です。