積み上がる機能リクエストにどう優先順位をつけるか
1分で読めます
機能リクエストを追跡することは、それらがどこに存在するかを解決する。どれを先に出すかは解決せず、その二番目の問いこそがチームが本当に行き詰まるものだ。グループ化され、ラベル付けされた三百件のリクエストを抱えるバックログでも、決定のルールはやはり必要になる。「最も要望の多いものを作る」は、二つのリクエストが僅差で、三つ目に声の大きな支持者がいるまでしか機能せず、それはたいていの週で起きることだからだ。以下のフレームワークは同じ問いに対する競合する答えではない。それぞれが異なるタイプのリクエストに合っており、すべてに一つだけを使うことこそが実際の間違いであることが多い。
機能リクエストの優先順位付けはロードマップの優先順位付けと何が違うのか
ロードマップの決定は戦略から始まり、何を作るべきかを問う。機能リクエストの決定はすでに存在する需要から始まり、それに対応すべきかを問い、この二つは十分に頻繁に別方向へ引っ張るため、あるリクエストは高い需要を持ちながら作るべきではないこともあれば、低い需要を持ちながら戦略的なアカウントを開くという理由で価値があることもある。すべてのリクエストをロードマップの投票として扱うことは、この確認を飛ばしてしまう。
| フレームワーク | 何を重視するか | どこで破綻するか |
|---|---|---|
| 生のリクエスト数 | 何人が要望したか | 実際の需要より覚えやすい名前を優遇する |
| RICE | リーチ、インパクト、確信度、労力 | 新しいリクエストでは誰も持たない見積もりを必要とする |
| 収益による重み付け | アカウントの価値に応じて誰が要望したか | まだ大きな価値を持たないアカウントからのリクエストを無視する |
| 公開投票 | 目に見える、低コストのシグナル | どこを見ればよいかすでに知っている利用者にしか届かない |
RICEとは何か、機能リクエストに機能するのか
RICEはアイデアをリーチ、インパクト、確信度、労力で採点し、比較可能な数値を得るために最初の三つを四つ目で割る。これはチームがすでに信じているロードマップのアイデア向けに作られたもので、難しい部分は異なる賭けを互いに比較することにある。機能リクエストはすでにリーチの数値を伴っている。要望した人数であり、それは新しいロードマップのアイデアが通常持つリーチより具体的だ。RICEがリクエストに対して緊張するのは確信度とインパクトだ。チームはリクエストが本物であると確信していても、それがどれだけ指標を動かすかの根拠を持たないことがある。すでに名前と実際の利用者の痕跡を持つリクエストの「インパクト」は、部屋の外の誰もまだ見たことのないアイデアのインパクトとは異なる種類の見積もりだからだ。
RICEは真剣に検討されていてまだ決まっていないリクエストに使う。入ってくるすべてのリクエストに適用してはならない。採点の手間は、決着をつけるものを必要とするほど僅差のものだけで元が取れる。
収益で重み付けすべきか、誰が要望したかで重み付けすべきか
誰が要望したかによるが、収益だけではない。更新が近いアカウント、すでにエスカレーションしたことのあるアカウント、そしてそのリクエストが進行中の商談を開くアカウントは、平坦な収益の数値だけでは捉えられない緊急性を帯びており、トライアル登録からのリクエストでも、まもなく収益になる決定をブロックしているなら依然として重要になり得る。収益による重み付けはこれらの中で最も計算しやすく、まさにそれゆえに過信しやすい。本当の利害のないアカウントからのノイズを正しく取り除く一方で、まだパイプラインにいるはるかに大きなアカウントをもたらすはずのリクエストを同じくらい簡単に格下げしてしまうこともある。
投票は実際どんな役割を果たすのか
すでに存在するリクエストにとっては安価で継続的なシグナルだが、そもそもどのリクエストが存在すべきかを発見するには不向きな方法だ。投票数は、すでにそのリクエストを見つけてクリックする価値があると判断した利用者にしか届かない。つまり公開ロードマップの投票合計は、需要と同じくらい可視性も反映しているということだ。リストの上位に近い古いリクエストは、見つけやすいという理由だけで投票を集め続け、同じくらい本物である新しいリクエストはゼロから始まる。公開ロードマップの記事は、ロードマップから投票を完全に外すことを主張している。投票は順番通りに積み上げていくランキングとしてではなく、グループ化し新しさで重み付けする必要のあるシグナルとして扱おう。 サポートチケット対機能リクエストは、投票数における別の 盲点を扱っている。それに遭遇するユーザーがボードを決して見つけられない場合、本物のギャップが ほとんど投票を生まないことがある一方で、サポートには騒がしく現れる。
最も声の大きな顧客が勝つのはいつであり、それは問題なのか
時にはそうであり、それが問題になるのは誰もそれに気づかないときだけだ。頻繁にエスカレーションし、詳細なチケットを書き、あるいはチームの誰かと直接のつながりを持つ顧客は、同じくらい正当なリクエストを持つより静かな顧客よりも早くリクエストを検討してもらえるだろう。それを一度も確認しない優先順位付けのプロセスは、最も主張が強い者を、最も根拠が強い者ではなく、体系的に優遇してしまう。声の大きな顧客は直すべき問題ではない。彼らのリクエストはしばしば本当に重要だ。直すべきは習慣のほうだ。定期的にソース別にバックログを見直し、同じひとつかみのアカウントが最近リリースされたものの大半を説明していないか確認し、それが実際の需要のある場所と一致しているかを自問することだ。
優先順位付けの決定はどうやって返答に変わるのか
ここでのすべての決定は勝者と敗者の両方を生み、両者とも説明のない状態変更ではなく、実際の理由づけを名指しする返答に値する。機能リクエストの断り方は、通らなかったリクエストに何を伝えるべきかを、通り一遍の拒絶のように聞こえさせずに関係を保つやり方で扱っている。これらすべてをそもそも可能にするグループ化とラベル付けの作業は機能リクエストの追跡で扱われている。優先順位付けは、すでに記録され、比較できるほどうまくグループ化されたリクエストに対してのみ機能する。
FAQ
機能リクエストの優先順位付けに最適なフレームワークは何か? 単独で完結するものはない。最も声の大きなシグナルを見つけるには生の数値を使い、真剣な候補の短いリストを比較するにはRICEを使い、戦略的なアカウントからの静かな需要が、より声は大きいが重要度の低いグループを上回っている場合を捉えるには収益やアカウントの確認を使う。
機能リクエストはロードマップのアイデアと同じように優先順位付けすべきか? いいえ。ロードマップのアイデアは戦略から始まり、機能リクエストはすでに存在する需要から始まる。両者を一緒に採点すると、既存の需要は少なくてもよく練られた戦略的な賭けが、単により多くの人が要望しただけのリクエストに一貫して負けてしまう。
公開ロードマップの投票は需要を正確に反映しているのか? すでにそのリクエストを見つけた人々の間でのみだ。より古く、より目立つリクエストは、新しいリクエストの背後にどれだけ本物の需要があるかにかかわらず、より速く投票を集める。だから投票の合計は、順番通りに積み上げるランキングとしてではなく、グループ化され新しさで重み付けされたシグナルとして扱おう。
機能リクエストの優先順位はどのくらいの頻度で再評価すべきか? 誰かがエスカレーションしたときだけでなく、固定のサイクルでだ。リクエストを再グループ化し重み付けを再確認する月次または四半期ごとの見直しは、何がリリースされるかを支配するひとつかみのアカウントのようなずれを捉える。純粋に受動的なプロセスでは決して自ら明らかにならないものだ。
この記事の技術的な記述は第三者による確認を受けていません。誤りがあればお知らせください。修正します。