すべての高機能チームは優先順位をつけなければならない。月に一度でも、週に一度でもない。- しかし、厳しく、冷酷に。
優先順位付けとは、最も重要なことを最初に行うことを意味します。プロダクトを作るのであれば、最も顧客価値を生み出すことを最初に行うことを意味します。
私の経験では、優先順位を決定する技術は、その決定が非常に複雑になるため、チームに伝授するのが最も難しいスキルの1つです。通常、優先順位決定はプロダクトマネージャーの中核的な責任ですが、私は、最高のチームとは、全員が同じ目標に向かってマニアックに優先順位を決定し、互いに一貫性のある方法でそれを行っているチームであることを発見しました。
この記事では、優先順位付けについて考えるためのフレームワークについて紹介します。
この記事は、「Ruthless prioritization」を著者の了承を得た上で翻訳したものです。
著者：Brandon Chu
翻訳者：渡辺圭祐
優先順位付けのフレームワーク
プロダクトマネジメントにおける優先順位付けは、2つのスコープに分けることができます：
- プロジェクト間の優先順位付け – これは、チームが次に行うべきプロジェクトを決定することです。
- プロジェクト内での作業の優先順位付け – これは、プロジェクトをいかに効率的に実行するかということです。
これからわかるように、それぞれのスコープに取り組むべき方法は大きく異なります。なぜなら、それぞれが異なるタイプの決断を迫られているからです。
プロジェクト間の優先順位を決めるとき、あなたはひとつの大きな決断を下さなければなりません。私のチームは次に何に投資するのか？これに取り組む正しい方法は、パズルを完成させるようなものです。すべてのピースを見つけるために厳密なプロセスを適用し、すべてのピースがどのように組み合わされるかに答えがあります。
プロジェクトの中で仕事の優先順位をつける場合、同じ決断を何百回も下さなければなりません。これは絶対に行う必要なのか？これに対する正しいアプローチ方法は、プロダクトを作るという無秩序な性質を受け入れ、絶対に必要なことを素早く決断する冷酷な考え方を身につけることです。
プロジェクト間の優先順位付け
パズルを解くための厳密なプロセス：私のチームは次に何に投資するのか？
この質問に答えるには厳密さが必要かもしれませんが、プロセスは複雑ではありません：
- 各プロジェクトの投資利益率を見積もる
- 3つの制約条件を適用する：依存関係、スケジュール、チーム構成
- パズルを組み立てる – ROI + 制約に基づいてプロジェクトを順番に進める
これらのコンセプトのほとんどは読者にとって新しいものではないと思うので、かなり手短に説明します。
1. 投資利益率の見積もり
すべてのプロジェクトの優先順位付けの基本は、投資利益率（ROI）です。ROIは、チームが単位時間内に生み出す顧客価値の量として測定されます。優先順位付けの目標は、時間の経過とともに生み出される顧客価値を最大化する仕事を常に行うことです。
プロジェクト間の優先順位を決めるには、2つのデータを見積もる必要があります：
- 生み出される顧客価値の量
- プロジェクトの完了までにかかる時間
各プロジェクトについてこのデータを入手したら、それらを単純に比較すれば、ほら、優先順位が決まります。
もちろん、インパクトとエフォートの両方を見積もるのは難しいことで有名ですが、見積もるたびに間違っている確率が等しいと仮定すれば、ROIを計算することはプロジェクトの優先順位付けの正当な方法です。
ヒント：見積もりの労力を2倍、インパクトを半分にすれば、より現実に近くなる。
2. 制約条件を適用する
人生はスプレッドシートのように整然としているわけではないので、優先順位の決定に織り込まなければならない制約もあります。あなたが対処しなければならない主な制約は、依存関係、スケジュール、チーム構成です。
依存関係
依存関係とは、ある作業単位が完了しないと、別の作業単位が進まない場合に生じます。
例えば、あなたがモバイルチームで、顧客の携帯電話にシームレスなワンタップ決済ボタンを作りたいとします。あなたは、これが最もROIの高いプロジェクトであると認識し、早急に実行したいと考えました。
しかし、それを実現するためには、そもそも決済を受け付ける機能が必要であり、現在別のチームが取り組んでいます。他のチームの完成に依存しているということは、あなたはまだ何もできないということであり、正しい優先順位付けの決定は、ワンタップ機能を延期し、次にROIの高いプロジェクトを行うことです。
プロダクト作りには依存関係がつきものであり、規模が大きくなればなるほど、より複雑なシステムが構築されるため、プロダクトが成功すればするほど、依存関係は悪化します。大企業では、依存関係を理解し回避することが、優先順位をつける上で最も重要な次元になることが多いです。
余談ですが、スタートアップのスピードが速いのは、彼らがより懸命に働き、より野心的だからだと考える人が多いです。実際は、スピードの違いのほとんどは、依存関係がはるかに少ない（そして、何か失敗したときに動揺する顧客が少ない）ことから来ています。
逆の依存関係
他のチームの目標達成に大いに役立つプロジェクトがある場合があります。この場合、あなたは依存関係にあります。
もしあなたが、自分のプロダクトよりも会社のROIを最適化しているのなら（そうあるべきだが）、チームの優先順位を正しく決定するために、自分のプロジェクトだけでなく、ブロックを解除した依存プロジェクトの累積ROIを評価する必要があります。
他のチームのブロック解除に取り組むチームを見るたびに、私は彼らから尊敬の念を抱きます。このようなチームは、プロダクト会社にとって縁の下の力持ちであり、最も大きな力を発揮するチームなのです。
タイムライン
タイムラインは典型的な制約であり、誰もが経験したことがあるものです。特に深刻なのは、ROIの最も高い機能が出荷される前に、あなたのスタートアップが資金を使い果たして死んでしまうことです。
このような場合、もちろん正しい優先順位付けの決定は、時間枠内で達成可能なROIの最も高いプロジェクトを行うことです。
チームの構成
すべてのチームが平等というわけではなく、チーム内の特定の人たちの構成によって、どのプロジェクトに優先順位をつけるか、異なる決断が必要になることもあります。
例えば、インターンの集まりのような、入社して間もない人ばかりのチームがある場合です（インターンに失礼かもしれませんが、全ソフトウェアの50％はインターンによって作られています）。
このような状況では、たとえROIが最も高くても、顧客に対するリスクが大きいプロジェクトを優先することには注意すべきです。その代わりに、重要なコードやユーザー・エクスペリエンス・ジャーニーに触れないプロジェクトを優先した方が良い場合が多いです。
新人チームは、まず小さな成果を出荷して、足元を固めましょう。本番用の機能をいくつか開発したら、より複雑なプロジェクトに進むことができます。
プロジェクト間の優先順位付け： パズルを完成させ、仕事に取り掛かる
上記のすべての情報を収集するのに必要な作業量を矮小化しているが、いったんすべてを手に入れたら、あとはピースを組み立てるだけです。
プロジェクト内での仕事の優先順位付け
判断する冷酷な考え方: これは絶対に必要なのか？
プロジェクトの実行中は、優先順位付けの性質が異なります。混沌としています。毎日のように決断が求められ、プロジェクト間で優先順位をつけるときのように、ひとつひとつを深く分析する時間はありません。また、実際の顧客が影響を受け、自分たちの評判が危うく感じられるかもしれないので、チームにとってはより感情的な時間でもあります。
プロダクト作りのスピードとカオスに対抗する唯一の方法は、非情なマインドセットを身につけることです。チームが行っている作業を常に意識し、その作業の必要性について彼らに挑戦します。
冷酷なマインドセットを持つということは、現実を受け入れるということです。それは、どこに重点を置くべきか、日々厳しい選択を迫られることを認識することです。完璧なプロダクトを出荷することは幻想であり、出荷するためには常にトレードオフが必要だということを認識することです。
冷酷な考え方を持つことは、出荷する意志を持つことです。ステークホルダーや顧客の期待はチームに大きなプレッシャーを与え、その結果、チームは出荷を恐れるようになります。そして、小さな問題で汗をかくようになり、何も行動できなくなるようになるのです。重要なこと、つまり時間をかけて生み出される顧客価値を見失い、完璧であろうとし始めるのです。
立ち上げ時にバグがないチームを教えてくれれば、もっと前に出荷すべきだったチームを教えましょう。
現実には、プロジェクト内での作業の優先順位付けは混沌としているため、そのプロセスを定義することは無謀です。より生産的な戦略とは、「これは絶対に必要なのか」という問いに冷酷に答えられるよう、プロダクト開発のコンセプトをチームに浸透させることです。以下は、この記事の残りの部分で取り上げるものです：
- 優先順位決定システムの構築
- クオリティとスピードのトレードオフを行うためにプロダクトの仮定を使用する
- 出荷の時間的価値
1. 優先順位決定システムの構築
すべてのソフトウェアは負債です。現在バグがあり、時間が経てばさらにバグが増えます。新しいバグに直面したとき、チームがそれを修正すべきかどうかを素早く判断できなければ、最も重要な仕事に集中する能力が常に中断されることになります。
バグが出るたびに優先順位付けのミーティングをする余裕はないでしょうから、バグを修正するタイミングや次に進むタイミングを判断するシステムを作ることが、最もレバレッジの高いことの1つです。
以下は、私がチームのために生産的だと感じた例です：
X軸はバグがユーザーに影響を与える頻度を表し、Y軸はそのバグの深刻度を表します。赤い点がバグです。
このシステムを使うには、チームと協力して、どの程度の深刻度（この場合、ユーザーが支払えないこと）が深刻すぎるか、どの程度の頻度（この場合、影響を受けるユーザーが5％）が頻度高すぎるかを定義します。そして、そのバグがどのゾーンに当てはまるか、少なくとも1つのアクションをバックログに入れ、何もしない、というアクションセットに合意します。
これに投資すれば、あなたのチームはバグのトリアージマシンになり、誰かが価値の低いバグに取り組む可能性は組織的に取り除かれます。
2. クオリティとスピードのトレードオフを行うためにプロダクトの仮定を使う
プロダクトの初期に創業者が書いたクソコードについてよく耳にします。会社が成功するにつれて、このコードはチームに加わる新しいエンジニアにとって悪夢となっていきます。
創業者は下手なプログラマーだったのでしょうか？そうかもしれません。しかし、可能性が高いのは、当時はプロダクトが成功する見込みがなかったため、コードのクオリティにはあまり関心がなかったということです。それよりも、スピードと自分たちのアイデアの検証を重視していたのです。
出荷するためには、どのチームも必ずクオリティを犠牲にします。そしてそれは、プロダクトのクオリティにとって何が不可欠か、という優先順位の決定に帰着します。
ここで、スピード対クオリティのスペクトラムの正しい位置に自分を導く便利な方法を紹介しましょう。それは、プロダクトの仮定をベースにすることです。プロダクトの仮定とは、顧客の問題や、顧客のために構築しようとしているソリューションについて、あなたが抱いている基本的な信念のことです。
フェイスブックの初期の頃の単純な例で言えば、人々はオンラインでお互いにつながりたいと思っているという問題仮説があったでしょう。その問題が検証された後、他のユーザーを友達として追加できるようなプロダクトアイデアを考えました。
あなたのプロダクトについて考えてみると、このようなプロダクトの仮定に関して、3つの状況が考えられます：
- 解決しようとしている問題が想定である。
- 既知の問題を解決するためのソリューションが仮定である。
- どちらも仮定ではない（あなたは何が必要で、なぜ必要なのかを正確に知っている）。
このスペクトルの左側に位置する場合、顧客の問題について想定はしていますが、それが本当かどうかはわかりません。このような状況では、できるだけ早く出荷するために手を抜くべきで、存在しない問題を解決しようとするリスクを最小限に抑えることができます。
一方、あなたが解決しようとしている問題と、適切なソリューションを構築する方法について高い確信がある場合は、その機能が成功し、将来にわたって拡張する必要があることが分かっているため、クオリティを最大限に高めるべきです。
よく、チームを「実験」するチームと「コア」な仕事をするチームに分けている企業を見かけません。私の意見では、このような組織構造は、ほとんどのチームがプロダクトの想定スペクトルを理解できず、スピードとクオリティのどちらかにギアを切り替えることができないことを反映していません。
3. 出荷の時間的価値
ソフトウェアは、出荷されて初めて顧客に価値をもたらします。
このように、顧客により早く何かを出荷することに価値を置くことができるはずです。これは、私が少し前に書いた「出荷の時間的価値」という概念です。
例として、プロダクトチームがしばしば直面する困難な選択は、80％の顧客ベースには早く機能を出荷し、最後の20％にはその機能を遅らせるかどうかです。この選択は通常、最後の20％の構築には多くのニッチな機能が必要で、（最初の80％の構築の）倍の時間がかかる場合に生じます。
この選択を分解してみましょう：
図を見てみると、80％の顧客は、選択肢#1では付加価値を得る期間を享受しているのに対し、選択肢#2では待たなければならないことがわかります。では、#1を選ぶのは当然なのでしょうか？そうとは言い切れませんが、チームにとっては難しい選択です：
- なぜなら、その機能が機能しない20％の顧客は、彼らをサポートしないというあなたの選択を間違いなく認識し、腹を立てるだろうからです。彼らにとっては、何も提供しないよりも悪いことなのです。
- その機能が使える80％の顧客は、その機能を早く手に入れることで得られる特別な価値を実際には認識していません。
この2つの効果の皮肉なところは、時間をかけてより多くの顧客価値を提供するという決断を下すことで、実際に腹を立てる顧客が増えるということです。不思議な時代です。
上記のようなことがあるにもかかわらず、このような選択を迫られた場合、私は通常、非情になって出荷することをチームに勧めます。その理由はこうです：
- もし顧客が完全な背景を知り、私たちのために決断を下すことができるのであれば、彼らの大半は私たちがそれを出荷することを望むでしょう。
- 長い目で見れば、チームが一貫してこの戦略に従えば、顧客が80%|20%の良い方に転ぶ回数は均等になり、その結果、常に100%を待つ企業と比較して、常に機能を早く手に入れることの効果が積み重なり、顧客は時間とともに指数関数的に多くの価値を得ることになります。
顧客により早く出荷することに価値を置くことは、理解するのは簡単ですが、痛みを伴うため行動に移すのは難しい概念の一つです。冷酷な優先順位決定者はこれを見抜き、顧客の利益のために行動します。
プロジェクト内での仕事の優先順位付け：冷酷な考え方は不自然
今回取り上げたコンセプトは、経験から学んだ内面化する価値のあるものに過ぎません。もっとたくさんあるし、自分の経験に基づいてこれらを微調整するのです。
悲しいことに、この業界のほとんどのチームは、プロダクト会社の中核的なミームであるにもかかわらず、冷酷な優先順位付けをするインセンティブを与えられていません。
例えば、大規模な組織では、チームは常に機能を出荷しており、ほとんどの社員は顧客が発表するまでその発表について聞くことすらありません。そのような環境において、従業員は自分のチームメイトが、同じ場所にいる他の従業員よりも3倍速く出荷できたことを理解できると思いますか？そうではないでしょう。むしろ、チームメイトが意識的に受け入れていたにもかかわらず、プロダクトに欠けているものしか目に入らないのです。
対照的に、完璧に洗練されたプロダクトは、社内で多くの賞賛を受ける傾向があります。出荷に2年もかかったのは残念です。そのような機能が出来るとは思っていなかったために解約したすべての顧客についてほとんど考えていませんのは残念です。
もっと良くなるようにチームに挑戦させる。冷酷になるよう挑め。
優先順位付けは技術である
あなたのチームの時間は、企業が自由に使える最も貴重な資源であり、もしあなたの仕事の一部がその時間を管理することであるなら、あなたはそれが得意になる必要があります。それは技術であり、練習すれば意図的にうまくなるものです。
優先順位の付け方について、最後にもうひとつだけ真実をお伝えしたい。「現在の計画よりも早く目標を達成する方法は必ずある。」
常に。それを見つければいいのです。計画会議の最後に、「どうすれば半分の時間でできるでしょうか」と尋ねれば、奇跡的にチームは方法を見つけてくれます。
何年もプロダクトを出荷してきましたが、より少ない投資時間で同じ顧客価値を生み出す方法をチームが見つけられなかったという状況に私はまだ出くわしたことがありません。また、チームが物事の優先順位を完璧に決めたという状況にも出会ったことがありません。
常に方法はあるということを受け入れるなら、今プロジェクトを実行中であろうと、次にどのプロジェクトに取り組むかを決定中であろうと、冷酷かつ厳密に優先順位をつけることが唯一の論理的なことです。
たとえプロジェクトが国全体であっても。
終わりに、考えておくべきことがあります：
- この記事が役に立ったと感じたら、推薦またはシェアしてください。人々がこの記事に価値を見出すことを知ることは、私に書く🔋を与えてくれます。
- このような記事をもっと読みたい、あるいは投稿してあなたのストーリーを共有したいとお考えの方は、プロダクトマネジメントのブラックボックスを購読してください。
フォローして最新情報をチェック！
PM Library 