こんな経験はありませんか？

• 「開発メンバーになんでこれ優先度高い/低いんですか？」と聞かれるとき
• 「考えていた新機能以外にビジネスサイドからの要求が尽きない。ユーザー要望は待ったなしで、技術的な課題も放置できない……。どれから手をつければいい？」と思うとき

はじめまして。株式会社GaudiyでPdMをしている三島(@kaa_a_zu)です。今は漫画やゲームのIPごとにファンコミュニティを作ることが出来るFanlinkというサービスを作っています。

実際、私も優先順位で悩んだことが何度もあります。多くの要求やアイデアに囲まれたとき、どれを先に取り組むべきか判断するのは簡単ではありません。

今回の記事ではこの課題を打破する一つの手段として、今回はICEスコアをベースにした優先順位づけの方法を紹介したいと思います。

スコアリングによる初期整理、そしてスコア化だけでは拾いきれない部分を対話や情報共有で補うことで、「なぜ今これ？」を自信を持って語れる土台を作ることができます。これを機に、“あれもこれもやりたい”状態から、一歩抜け出してみませんか？

なぜ優先順位付けが必要なのか

「優先順位付が必要なのは当たり前だろ！！」ってのはその通りなのですが、話を進める上で「私がなぜ優先順位付けが必要だ」と強く思っているのかを伝えさせてください。

みなさん経験しているようにプロダクト開発をしていると、要求は本当にあちこちから生まれます。ビジネスサイドやPdM本人の頭の中、ユーザーやクライアントからのフィードバック、エンジニアの視点など、さまざまです。そして、多くの場合、それらの要求には何らかの価値があります。アイデアが全くのマイナスになることは稀で、その要求が生まれた背景や意図を考えれば、発案者視点では「これが最優先！」と見えがちです。

ただ、プロダクト全体、ビジネス全体といった少し広い視点で見たとき、発案者が思うほど優先度が高くないケースも出てきます。そしてリソースは限られているため、同時にすべてに手をつけることはできません。ここで「何を先に手がけるべきか？」をはっきりさせる、いわゆる優先順位付けが必要になります。

また、優先順位付けは「なぜこのアイテムを先にやるのか？」あるいは「なぜこのアイテムは後回しなのか？」といった問いに対する説明材料にもなります。 単に「これが上位です」と伝えるだけでなく、下位になったアイテムも並べて見せることで、「今はここまで手が回らない理由」を明確にできます。これにより実行者や関係者が納得しやすくなり、期待値調整もスムーズです。

こうした可視化によって、チーム内外や社内外のステークホルダーから「なぜあのアイテムはすぐにやらないの？」と問われたときに、筋道立てて説明しやすくなります。結果として、意思決定そのものがより進めやすくなるはずです。

優先順位方法

方法の概要と背景

私たちのチームでは、優先順位付けにおいて、基本的な考え方としてICEスコア(Impact・Confidence・Ease)をベースにしています。ICEスコアは、施策や機能アイデアを「インパクト（Impact）」「確信度（Confidence）」「実行容易性（Ease）」の3要素で評価し、優先度を導くシンプルなフレームワークです。ただし、シンプルすぎるが故に実態にそぐわないこと発生することを何度か経験したため、いくつかの部分を補い以下のようにしています。

①Impact（アウトカム・提供価値の大きさ）

1. Impact(マネタイズ)
2. Impact(定着)
3. Impact(ユーザー間交流)

このように複数個のImpact要素を設け「2:6:2」のような重み付けをして、最終的なImpactスコアを算出しています。なぜこのような重み付をしているのかというと、Impactとひとえに言っても、プロダクトやビジネスのフェーズによって内容も重要度も異なるためです。これを行うことで例えば、成長初期は新規収益を狙うためマネタイズを強く評価し、定着やユーザー間交流は相対的に低めにする、といった調整が可能になります。　※Impact要素数はいくつでも良いです

②Confidence（不確実性の低さ）

不確実性を「リリース前にある程度確かめられるか？」といった時間軸を含めた形でスコア化しています。ただ「自信ある・ない」で終わらせないことで、いつ・どの段階で確実性が上がるのかがわかるようになります。

③Ease（開発容易性）

Easeは実際の開発工数ベースで評価します。「1週間以内で開発できるか、1ヶ月以上かかるのか」といった区分で点数化することで、規模感を直感的につかめます。

④汎用的実現性

私たちが作っているサービスはtoBサービスの形に近く異なる事情を持つクライアント様に利用していただいています。プロダクトとして複数クライアントに提供する際、どれだけ共通化できるか、あるいはクライアントごとに個別対応が必要なのか、といった点をスコアにします。

このような機械・定量的なスコアリングは、「とりあえずの並び替え」を高速で行い、最初の議論材料を作ることが目的です。あくまでスタート地点であり、これが最終決定ではありません。スコアを基にした初期の並び替えを行うことで、「なぜこのアイテムはこの位置にいるのか？」という問いかけや、ビジネス側・開発側で想定している前提条件の言語化を促す土台ができます。

方法の詳細

前述したImpact、Confidence、Ease、汎用的実現性を基に具体的には以下のようにスコアリングをしています。※具体的な点数や内容は記事用に変えています

Impact例

9点：全ユーザーに影響
5点：50%のユーザーに影響
1点：10%未満のユーザーに影響
このImpactスコアはさらにマネタイズ(7)、定着(2)、ユーザー間交流(1)といった重みをかけて総合Impactスコアを算出します。

Confidence例

5点：不確実性が小さい
4点：リリース前に確実になる
3点：ある程度不確実性がある
1点：リリースまで不明

Ease例

6点：1週間以内
4点：1-2週間
3点：1ヶ月以内
1点：1ヶ月以上

汎用的実現性例

3点：全ての提供先で実現可能
2点：交渉次第で実現可能
1点：全ての提供先に共通適用は難しい

総合スコア算出の計算式は以下です。

合計Impactスコア = (マネタイズスコア × 7) + (定着スコア × 2) + (交流スコア × 1)
総合スコア = (合計Impactスコア) + (Confidence,Ease,汎用的実現性スコアの合計)

なお、最初に各項目に設定する点数は仮決め状態でスタートし一旦埋めてみることをおすすめします。自チームでは、当初「Ease」の「1週間以内でできる」には9点を設定していました。しかしこの設定だと、細かな作業アイテムばかりが突出して優先度が上がり、結果的にチームとして望まない優先順位がアウトプットされてしまいました。そこで、途中から「1週間以内でできる」を6点に引き下げ、全体のバランスを取っています。

また、スコアを付ける際には「点数」だけでなく上記例に示したような「補助文章としての判断基準」を明記することが重要です。例えば「5点と6点はどう違うのか」が明確でなければ、人によって解釈が異なり、スコアがブレてしまいます。補助文章を用意することで、誰が採点しても概ね同じ感覚でスコアリングでき、結果がブレにくくなります。

スコアリング例(チャットサービス編)

以下は、チャットサービスを例にした10個のバックログアイテムと、それらに対して本記事で紹介したスコアリング手法を適用した一例です。今回の例では、Impactは [マネタイズ(7), 定着(2), ユーザー間交流(1)] の重みを合わせた総合Impactスコアとしています。また、Confidence・Ease・汎用的実現性は仮の基準点数を付与しています。 ※各アイテムはAIに出力してもらった仮のものです。

上記の例から、以下のようなことがわかると思います。

1. 有料プラン決済フロー改善（アイテム1）はImpactが極めて高く、Confidenceもそこそこ、Easeは中程度、汎用性も高いため、総合スコアが非常に高く出ています。
2. UI微調整（アイテム4）はImpactこそ低いものの、Easeが非常に高く（1週間以内で可能）かつConfidenceや汎用性が高いため、意外と上位に来てしまうケースがありました。自チームではこのような状況を避けるためにEaseの点数を9から6に調整した経緯があります。
3. コミュニティ関連機能（アイテム8）はインパクトが比較的低い分、総合スコアも抑え目になっています。これを改善したければImpactやConfidenceスコアの見直し、あるいはBiz要求や対話を通じてこの機能が本当に持つ価値を再検討する必要があるかもしれません。

このように、スコアリング結果を見ることで「なぜこのアイテムが上位/下位なのか？」を可視化できます。そして、ここから対話や点数基準の再設定を行うことで、よりチームに合った優先順位付けを見つけていくことが可能となります。

スコア化で補えない要素と対話の重要性

繰り返しになりますが、この機械的なスコアリングはあくまで初期の整理ツールで、全てをカバーできるわけではありません。 ビジネスサイドからの強い要求や、スコアでは表しきれない技術負債の影響、今後のビジネス戦略など、優先順位を判断する際には必ず「対話」が必要となります。

Biz要求への対応のための言語化：

ビジネスサイドが「なぜ今この機能が必要なのか」を明確にすることで、チーム全体が戦略的な意図を共有できます。これは、スコアリングだけでは見えない背景を補完し、チーム内の納得度を向上させます。

技術負債に対する優先度引き上げ：

技術負債は短期的なビジネスインパクトには表れにくいため、スコア上は低くなりがちです。しかし、これを軽視していると、将来的な拡張性や安定性に悪影響が出る可能性があります。

負債解消の重要性や負債の返し方については以前説明をしているでのよかったら見てください。

https://techblog.gaudiy.com/entry/2021/12/24/133453

どのように技術負債の優先度を上げるのかについては、株式会社ログラスの松岡さん が先日とても分かりやすい記事を書いていたのでこちらも是非見てください。

https://zenn.dev/loglass/articles/961e283e6fbe71

さて、ここで問題なのは、そもそもエンジニアが「技術負債を優先して解消すべき」と言い出せない状況が生まれることです。この「言い出せない」には大きく2つの観点が存在します。

心理的安全性・雰囲気の観点：

PdMや上司に対して懸念を示すことがネガティブに捉えられたり、「言わないほうが得」と感じる雰囲気がチーム内にある場合、エンジニアは率直な意見表明をためらいます。この状況は短期的には表面的なスムーズさが保たれるかもしれませんが、こうした状況を放置すると、後になって大きな問題が顕在化したときに手遅れとなり、最終的にはPdMや会社全体にとって不利益をもたらします。意見を気兼ねなく言える心理的安全性を確保し、エンジニアの視点や懸念を歓迎する文化を育むことが欠かせません。

情報提供・見える化の観点：

将来控えている開発計画、イベントスケジュール、流入KPIなどが共有されておらず、エンジニア側が将来起き得る問題を根拠を持って説明できない状況も問題です。何を根拠に「技術負債解消が必要」と言えばよいのか情報が無ければ、主張に説得力が生まれず、意見は埋もれがちです。逆に、ロードマップや運用予定、成長見込みデータなどを常に共有しておくことで、エンジニアは「今ここで手を打たないと、数ヶ月後のイベントで大規模な障害が発生するリスクがある」といった明確な理由を示せます。この情報的裏付けこそが、エンジニアの声を優先度判断のテーブルにしっかり乗せるための強力な武器となります。

まとめ

今回紹介したのは、ICEスコアをベースに、拡張した優先順位付けの方法論です。最初のスコアリングは高速で「とりあえず並べて」チーム内で共通言語をつくるための手段であり、ゴールではありません。

実際には、Biz要求や技術負債など、スコアだけでは判断できない要素が出てきます。そのためには、チーム内での対話や情報共有、心理的安全性が欠かせません。スコアはあくまでキッカケであり、本質的な意思決定は、コミュニケーションや文化、環境整備の中で形作られていくものだと考えています。

もしも少しでも共感したり、使ってみたいと思ってくれたら嬉しいです。また、記事への感想やみなさんが行っている優先順位付の方法も教えてください！

あとがき

最後に、この記事で紹介した方法や考え方は、私自身がこれまでの経験を通して「今のところベスト」と感じているプラクティスです。自信はあります。ただ、正直、まだ100％活用できているとは言い切れません。特に、技術負債に関するエンジニアの声を引き出しやすい状況づくりなど、課題は残っています。だからこそ、繰り返し試行錯誤し、スキルを磨き続けていきたいと思います。

そして、どれだけ工夫しても、チーム開発である以上、一人で完璧に回すことは難しいものです。現に、私は今でも仲間たちに助けられています。最終的には、チームメンバーとの対話と協力こそが、この手法をより良く、より有効なものに育てていく鍵だと考えています。

「早く行きたければ一人で行け、遠くへ行きたければみんなで行け」という言葉があるように、遠くに早く行くためにもチームが同じ方向を向けるように引き続き精進していきたいと思っています。