優先度の「なんとなく」から脱却する。優先度を明確にするためのステップ

こんにちは、WantedlyでPdMをしている上山です。 Visit Social Squad で Wantedly Visitの開発に携わっています。 直近では、ダイレクトメッセージやタイムラインといったソーシャル機能の施策を担当しました。

優先度を決める時の「なんとなく」からの脱却

プロダクトマネージャー1年目の頃、私はプロダクトの優先度を「なんとなく」で決めてしまうことが多くありました。当時は、開発が進む中でデザイナーやエンジニアから仕様の優先順位を問われても、その場限りの主観で回答を繰り返していました。自分の中にある完成形のイメージ自体が曖昧だったため、判断基準がその都度変動してしまい、意思決定の理由を周囲に説明できなかったのです。

優先度の説明ができないことで、ステークホルダーとの合意形成がスムーズに進まない、仕様変更や開発の遅延が発生するといった課題を抱えていました。こうした失敗を経て、現在は主観による判断を避け、理由を持って優先度を決めるためのプロセスを実務に取り入れています。

本記事では、現在実践している3つのステップを整理して紹介します。

なぜ優先度決定が「なんとなく」になっていたのか

優先度が曖昧になっていた最大の要因は、「企画した自分が一番プロダクトを理解している」という過信にあったと考えています。当時は、自分の中にある完成形のイメージを基準に判断を下していました。しかし、完成系のイメージは言語化されていないため、検討が進むにつれて細部が変わりやすく、結果として判断の基準がその時々で変動していました。「なぜその判断をしたのか」という理由を自ら説明できない状態だったのです。

優先度の理由が説明出来ていなかった結果、以下のような問題が発生していました。

• 優先度付けの理由が説明できないため、周囲の意見で優先度が変わる 
• • 優先度の理由を示せないため、ステークホルダーからの「やっぱりこれも入れたい」という意見を適切に調整できず、場当たり的に優先度を変更していました。
• 一貫性のない判断が引き起こす、チームへの負荷
• • 優先度が頻繁に変わることで開発に手戻りが発生し、結果としてリリース日が延びてしまうなど、チームに過度な負担をかけていました。

このような失敗の経験を経て、属人的な「感覚」ではなく、プロセスに基づいた判断の必要性を痛感しました。

優先度を決めるために必要な3つのステップ

優先度を決める際に「なんとなく」をなくし、理由のある判断をするために、現在は以下の3つのステップを踏んでいます。

ステップ1：要求・要件を並べて比較できる状態にする

優先度を検討する際、まずは判断の対象となる要素をすべて可視化し、同じ土俵に乗せることから始めます。要求・要件を一覧化し、「これを通すなら、こちらを削る」といった相対的な比較ができる状態を作ることではじめて、トレードオフの検討が可能になります。

要求・要件を一覧化する際、比較をスムーズにするために「要求・要件の粒度を揃える」ことも意識しています。例えば「検索機能（機能の塊）」と「ボタンの色（詳細な仕様）」を同じレベルで比較すると、重要度の判断が難しくなります。そのため私の場合は、ユーザー行動単位（例：「商品をカートに入れる」等）で整理することで、比較対象の条件を揃えるようにしています。

ステップ2：優先度を決めるのに必要な情報を揃える

次に、優先度を決めるための材料として「ユーザーにとってどのような価値があるか」と「制約」を整理します。

判断の基準が主観によって変動するのを防ぐため、ユーザーにとっての価値は「誰が・いつ・なにをして、なにを得るか」まで具体化しておきます。表現が曖昧なままだと、検討が進むにつれて「あれもこれも必要」と判断がブレる原因になるからです。

「ユーザーにとっての価値」を言語化した上で、品質・工数といった現実的な「制約」を判断基準に加えます。「ユーザーに価値を届けるために不可欠な体験」が、現実的なリソースの範囲内で成立するかを照らし合わせることで、根拠のある優先度を導き出せるようになります。

ステップ3：優先度の定義を言語化する

最後に、議論を始める前の前提条件として、優先度の定義を明確にします。よく「高・中・低」といったラベルで優先度をつけることがありますが、ラベルだけでは、人によって解釈が分かれてしまうからです。例えば、ある人にとっての「優先度：高」は「何があってもリリースに含めるもの」であっても、別の人にとっては「価値が高いから、できれば入れたいもの」というニュアンスかもしれません。

こうした優先度の解釈のズレを未然に防ぐために、優先度ラベルには必ず「何を指すのか」という具体的な定義をセットで持たせるようにしています。

• 高：ユーザーに価値を届けるために不可欠なもの
• 中：ユーザーにとっての価値は満たすが、ユーザー体験に障壁があるもの
• 低：ユーザーにとっての価値には直接影響しないが、ユーザー体験やブランド価値等を高めるもの

優先度の定義を言語化しておくことで、個人の主観ではなく「定義に照らし合わせるとどうか」という議論ができるようになります。

まとめ

以前の私は、優先度を「決めているつもり」になっていました。しかし実際には、判断の理由を自分でも言語化できていないことで周囲を困惑させ、結果としてチームに負担をかけたり、プロジェクトのスピードを損なっていたと感じます。

現在は、以下の3つのステップを意識することで、理由を持った優先度の判断ができるようになってきました。

• ステップ1：要求・要件を並べて比較できる状態にする
• ステップ2：優先度を決めるのに必要な情報を揃える
• ステップ3：優先度の定義を言語化する

このプロセスを踏むようになってから、主観による「なんとなく」の判断が減り、「なぜこの優先度なのか」を自信を持って周囲に説明できるようになりました。

優先度を決めることは、限られたリソースの中で「ユーザーに価値を確実に届けるための手段」です。正解は一つではありませんが、プロセスを整えることで、プロダクトマネージャーとしての意思決定に一貫性を持たせられるようになったことが、自分にとって一番大きな変化でした。