皆さん、こんにちは！もしくはこんばんは！ 楽楽精算プロダクトマネージャーのwekkyyyyです。
前回は、「楽楽精算PdMの業務内容を紹介します」というタイトルで記事を書かせていただきました。 tech-blog.rakus.co.jp
今回は、第二弾としてPBIの優先度設定方法のポイントと設定することの狙いというテーマでブログを記載します。
今回このテーマで書こうと思ったきっかけは、 弊社内やPdMコミュニティの中で
- 「なんでこの案件が優先されるんだろう？他にもあるのに。。。」
- 「次に何開発するんだろう？できれば少しずつ視野にいれていきたいな。。」
といった疑問を持たれている方が一定数いることを確認でき、そういった方達の一助になる対応事例を提供できれば・・・と思ったことです。
かく言う私も、PdM駆け出しの頃は上記のことを思ってました。 それを不満という形で上司にぶつけてしまい、よくないコミュニケーションを取ってしまっていました。（今思うと非常に恥ずかしいし申し訳ない限りです）
前提
- 弊社プロダクトの中で「楽楽精算」での事例を記載しております。
- 優先度設定方法の一例として捉えてください。
※企業によってそれぞれの状況、考え方があるので適した形を探してください。
PBIの優先度設定の狙い
1. 関係者が、先を見据えて行動できる土台をつくる
プロダクトマネージャー目線：
顕在化している課題に対するソリューション案を検討し蓄積していくことを狙っています。
- それにより開発リソースの空きが出た際にすぐに開発に要求仕様を渡せるようなるためです。
次に調査すべき課題の計画を事前に立てておき、動き出しを早くすることを狙っています。
- 調査計画を立てるためには意外と時間がかかると考えているためです。(どういう計画？は別記事で書く予定です)
エンジニア目線：
- 技術改善提案をする際に、効果を増加できる案件があるか事前に把握し提案タイミング、内容を図れるようなることを狙っています。
- 技術に寄ってしまって、ユーザーニーズ、ビジネスゴールと紐づかないことを避けるためです。
2. 優先度について会話のレベルを上げる
- 「今の優先度設定方法だと〜の課題がある。なので〜のように変えよう。」というコミュニケーションにしていくことを狙っています。
- 優先度設定方法の土台がないと、前提認識内容が合わずに関係者コミュニケーションが難しくなることが多いと考えているためです。
PBIの優先度設定方法のポイント
1. 開発カテゴリ分類を決める
楽楽精算では、以下の開発カテゴリに分けています。
2. カテゴリの優先度を決める
楽楽精算では、維持管理案件が基本優先されるようにしています。
※対応期限により後回しにすることはあります。
3. カテゴリ内の優先度指標を決める
- 維持管理：対応期限（期日が早いものから）
- 財務効果：失注、解約MRRの合計MRR（金額が高いものから）
を楽楽精算では指標として定めています。
財務効果において、「それで事業目標を達成できるの？」という声がありそうですが、それはまた別記事で説明します。
4. 開発リスト入りの条件を決める
ここまでを見ると、維持管理に入れてしまえば何でも優先されるようにみえてしまいます。
ですが、その状態は健全ではないのでチェッカー(事業本部長、開発部長の承認）を置いています。
注意点
- 上記が基本ルールとなりますが、事業戦略的な事情で一部優先度変わる場合もありえます。
- ユーザビリティ観点で見ないわけではありません。失注や解約に結びつかない事象は優先度が下がるという形です。
- バグ、インシデント対応は、別途しきい値を決めて対応を進めていく必要があります。
- コスト削減案件がある場合 財務効果観点で優先度を決めます。
今後の執筆内容(変更可能性あり)
- 開発案件につなぐ営業/CSからのVoC収集方法
- ラクスのプロダクトマネージャーに必要なスキル
- エンジニアとのコミュニケーション術
ラクスのPdMとして活躍してみませんか?
楽楽精算PdMは、引き続き人材を募集しております。 是非カジュアル面談からお申し込みいただけると幸いです。
