優先順位付けの手法として、RICEやValue vs Effortマトリクスといったフレームワークが紹介されます。ただ、プロダクトマネジメントを兼務している経営者の方に、これらを勧めることはあまりありません。
社長が優先順位を決めるとき、フレームワークはたいてい邪魔になるからです。
社長の判断は速い。そして多くの場合、正確です。理由は単純で、判断に必要な材料をすべて持っているからです。誰が何に困っていて、どの顧客の更新が近く、資金がいつまで持つか。これらを頭の中で同時に処理できる人が、わざわざスコアを計算する必要はありません。
問題は別のところにあります。その速さは、社長以外には再現できません。
本記事では、バックログ管理を「良い優先順位を付けるための技術」ではなく、**「社長が握っている判断を、他人が再現できる形にするための工程」**として整理します。フレームワークの解説もしますが、それは記事の後半です。使うべきタイミングが来てからで十分だからです。
その速さが問題になる、3つのサイン
兼務している間、バックログ管理は不要です。頭の中のリストで足ります。ただし、次のいずれかが起きたら、外に出す時期です。
サイン1：開発チームから「なぜこれを先に?」と聞かれるようになった
以前は聞かれなかったのに、最近は毎回のように聞かれる。これは、判断の根拠が共有されていないことに、チームが気づき始めたサインです。
説明すれば納得してもらえるうちは問題ありません。ただし説明のたびに社長の時間が使われ、しかも同じ説明を繰り返すことになります。
サイン2：自分の判断が前回と矛盾していないか、不安になる
要望の数が増えると、頭の中だけでは一貫性を保てなくなります。「先月はAを優先したのに、今月は同じ理由でBを後回しにしていないか」が確認できない状態です。
この不安が出てきたら、記憶の容量を超えています。
サイン3：営業やCSからの要望が、社長を経由しないと処理できない
要望を受け取る窓口が社長しかない状態です。社長が忙しい週は、要望が滞留します。
プロダクトの改善速度が、社長のカレンダーに律速されているのがこの状態です。
目的は「良い判断」ではなく「判断の再現性」
ここが本記事で最も伝えたい点です。
バックログ管理を導入する目的を「より良い優先順位を付けること」だと考えると、うまくいきません。社長の判断は、たいていフレームワークより正確だからです。 スコア計算に置き換えると、むしろ質が落ちます。
正しい目的は、判断を他人が再現できるようにすることです。
| 社長が判断する | 他人が判断する | |
|---|---|---|
| 速さ | 速い | 遅い |
| 精度 | 高い | 材料次第 |
| 他人が再現できるか | できない | できる |
| 社長の時間 | 使う | 使わない |
再現性を得るために、速さと精度をいくらか手放す。 これがバックログ管理の実態です。この割り切りができていないと、「自分でやったほうが早い」という結論に何度も戻ってきます。
フレームワークの前にやる3ステップ
ステップ1：頭の中のリストを、そのまま外に出す
まず、いま頭の中にある「やるべきかもしれないこと」を、順序も分類も気にせず書き出します。ツールは何でも構いません。
この段階で分類やスコアリングをしようとすると止まります。書き出すことだけが目的です。
多くの場合、40〜80件程度になります。この時点で「思ったより少ない」と感じることも、「こんなに抱えていたのか」と気づくこともあります。どちらも意味のある発見です。
ステップ2：直近10件の判断について、理由を1行書く
ここが最も重要な工程です。
過去に「これを先にやる」と決めた直近10件について、なぜそう決めたのかを1行ずつ書きます。
- 「7月の商談で3社から同じ要望が出て、うち1社の更新が近かったから」
- 「解約時のアンケートで2番目に多かった理由だったから」
- 「これができないと来期の提携先に提案できないから」
書いてみると、自分の判断軸が一貫していることに気づくはずです。 多くの場合、2〜3個の軸に集約されます。「更新が近い顧客の要望を優先する」「解約理由の上位から潰す」といった形です。
この軸こそが、渡すべきものです。 個別の判断ではありません。
ステップ3：抽出した軸を、自社の言葉でルールにする
ステップ2で見えた軸を、3〜5行のルールとして書きます。RICEのような既製のフレームワークに翻訳する必要はありません。 自社の言葉のままのほうが、判断するときに使えます。
例：
1. 更新・契約更改が3ヶ月以内に迫っている顧客の要望を最優先する
2. 解約理由の上位3件に該当するものを次に置く
3. 上記に該当しない機能要望は、四半期の頭にまとめて判断する
4. バグは影響ユーザー数に関わらず、24時間以内に対応可否を決める
5. 判断に迷ったら社長に確認する（＝1〜4で判断できない領域が、まだ渡せていない部分）
5番目を必ず入れてください。「渡せていない領域」を可視化する行であり、ここが減っていくことが権限委譲の進捗そのものになります。
既製のフレームワークは、いつ使うのか
自社ルールで運用してみて、それでも判断が割れる場面が出てきたときです。主に、社外の人や新しいメンバーと共通の土俵が必要になったときに効きます。
代表的な4つを、使いどころとあわせて整理します。
Value vs Effortマトリクス：全体を素早く仕分けたいとき
Value（事業・ユーザーへの価値）とEffort（実装工数）の2軸で4象限に振り分けます。
「価値が高く工数が小さい」（Quick Wins）を最優先、「価値が高く工数も大きい」（Major Projects）はロードマップへ、「価値が低く工数も小さい」（Fill-ins）は手が空いたときに、「価値が低く工数が大きい」（Time Sinks）は着手しない、という整理です。
細かい数値化が不要で、10分程度で全体像が見えるのが利点です。 ステップ1で書き出したリストの一次仕分けに向いています。
RICEスコアリング：上位候補が拮抗したとき
RICEスコア =（Reach × Impact × Confidence）÷ Effort
数値化により、性質の異なる施策を横並びで比較できます。ただし各要素の見積もりは主観に左右されやすく、「数字に見えるが実は感覚」になりがちです。使うなら、Reachは実際のユーザー数、Impactは過去の類似施策のデータを根拠にしてください。
全件に適用すると時間を浪費します。上位5件程度の比較に限定するのが実務的です。
MoSCoW法：リリース範囲を確定したいとき
Must have / Should have / Could have / Won’t have の4段階に分類します。特定のリリースのスコープを切るときに有効です。
注意点は、関係者の多くが自分の要望を「Must have」に入れたがることです。事前に「Must haveは全体の6割以内」といった上限を決めておくと機能します。
Kanoモデル：差別化施策を見つけたいとき
機能を「当たり前品質」「一元的品質」「魅力的品質」に分類します。競合との同質化が進んだ領域で、意識的に「魅力的品質」を組み込むために使います。
ユーザーインタビューで「あったらどう感じるか」「無かったらどう感じるか」を対で聞くと判定できます。
具体例：シリーズA前後、開発チーム5名の企業
社長が優先順位を決めており、バックログはSlackとNotionと頭の中に分散している状態から始めます。
ステップ1：書き出したところ63件。うち11件は既に不要（要望元の顧客が解約済み、他機能で代替済み）と判明し、この時点で削除。
ステップ2：直近10件の判断理由を書き出したところ、8件が「更新時期が近い顧客の要望」に紐づいていた。 本人は「顧客の声を聞いて決めている」と認識していたが、実際には契約の時間軸で判断していた。
ステップ3：この軸を含む5行のルールを作成。開発リーダーに共有したところ、「これまで判断の基準が分からなかったが、これなら自分でも仕分けできる」との反応。
結果：バグと軽微な改善については、開発リーダーが社長に確認せず着手するようになった。社長の判断が必要な件数が週12件から週4件に減少。
重要なのは、ここでフレームワークを一切使っていない点です。自社の言葉で書いた5行のルールで、判断の7割は渡せました。
運用のコツ
1. 判断の理由を1行、必ず残す。 「なぜこの優先度なのか」を一言添えるだけで、後から聞かれたときの説明コストが大きく下がります。ステップ2でやったことを、日常的に続ける形です。
2.「やらない」判断も記録する。 見送った項目を放置せず、理由を書いてアーカイブします。これをしないとバックログが「要望の墓場」になり、新しい要望が来るたびに過去との重複確認ができなくなります。
3. 棚卸しの場を定例化する。 週次または隔週で30分、要望の受け入れと優先順位の見直しをまとめて行います。都度の個別対応をやめることが、「声の大きさ優先」を防ぐ最も効果的な方法です。
4. ルールの5行目（社長に確認する領域）が減っているかを見る。 これが権限委譲の進捗指標になります。増えているなら、渡し方に問題があります。
よくある質問（FAQ）
Q1. 社長がフレームワークを使うべき場面はありますか?
社外の関係者と合意を取るときです。投資家への説明や、外部パートナーとの優先順位のすり合わせでは、共通の物差しがあると議論が速くなります。社内の判断については、自社ルールのほうが実用的です。
Q2. バックログが数百件あります。どこから手をつければよいですか?
まず削除から始めてください。 半年以上動いていない項目、要望元の顧客が既にいない項目、他の機能で代替済みの項目は、一度アーカイブします。実務では2〜3割が該当します。減らしてからValue vs Effortで仕分けると、現実的な量になります。
Q3. 優先順位を決めても、自分で覆してしまいます。
覆すこと自体は問題ありません。覆した理由を1行書いてください。 それが新しい判断軸である可能性が高く、ステップ3のルールに追加すべき項目です。ルールに書かれていない基準で判断しているから、覆すことになります。
Q4. 開発チームに優先順位を任せると、事業と噛み合わない判断になりませんか?
判断軸を渡していない場合は、そうなります。渡すのは個別の判断ではなく、軸です。 「更新が近い顧客を優先する」という軸を共有していれば、個別の判断は事業と噛み合います。噛み合わないのは、軸ではなく結論だけを渡しているときです。
まとめ
社長がプロダクトマネジメントを兼務している間、優先順位付けにフレームワークは必要ありません。判断材料をすべて持っている人の判断は、スコア計算より速く、正確です。
問題は、その速さが社長以外に再現できないことです。したがってバックログ管理の目的は、良い判断をすることではなく、判断を他人が再現できる形にすることになります。
進める順序は次のとおりです。
- 頭の中のリストを、そのまま外に出す（分類もスコアリングもしない）
- 直近10件の判断理由を1行ずつ書く（ここで自分の判断軸が見える）
- 抽出した軸を、自社の言葉で3〜5行のルールにする（既製の手法に翻訳しない）
既製のフレームワークは、社外の関係者と共通の土俵が必要になったときに使えば十分です。
まずはステップ2から試してみてください。直近10件の理由を書くだけで、自分が何を基準に判断してきたのかが見えます。 そしてそれは、1人目のPdMに渡すべきものと、ほぼ同じものです。
プロダクトマネジメントについてお気軽にご相談ください
プロダクトマネジメントの顧問支援や、1人目のPdM採用・育成のサポートを承っています。 「社長が兼務してきたが、そろそろ限界かもしれない」という段階からでもお気軽にご連絡ください。 おおむね2営業日以内にご返信します。
