目次

1. はじめに
2. 前提
3. 正しい順序で価値を届ける重要性
4. toBプロダクトにおける優先順位づけ
5. 優先順位づけの考え方
6. Reach & Impact
7. Confidence
8. Effort
9. スコアはあくまで参考値
10. やってよかったこと

すべて表示

はじめに

Shippioプロダクトマネージャーのヤギヌマ（@ygnmn）です。
本noteはプロダクトマネージャー Advent Calendar 2022の20日目の記事です。

プロダクト開発のコアは「顧客にとって正しいものを正しくつくる」営みです（こちらの名著の受け売り）が、加えて「正しい順序で価値を届ける」ことも同様に重要です。

「正しい順序」と一言で言っても、それを見定めるのはとても難しく、プロダクト開発に携わる人間の頭を悩ませる永遠の課題です。

今回は、当社にて試行錯誤しながら実践している施策の優先順位づけとその考え方についてご紹介します。

アドベントカレンダー12/5公開の記事でTakuya Asakoさんもnote社における施策の優先順位づけについて参考になる事例を紹介してくださっていました。こちらも是非あわせてご一読ください！

前提

• 私が所属するShippioは「理想の物流体験を社会に実装する」をミッションに掲げ、toBプロダクトを開発している貿易DXスタートアップです。
• 2022年9月にシリーズBの資金調達を行い、デジタルフォワーディング事業を主軸としつつ、新しくSaaS事業を立ち上げているフェーズです。
• 私は、デジタルフォワーディングおよび絶賛立ち上げ中のSaaS事業における荷主顧客向けプロダクトを担当しています。

正しい順序で価値を届ける重要性

なぜ「正しい順序で価値を届ける」ことが大事なのでしょうか？

それは、スタートアップのプロダクト開発では時間もリソースも有限な一方、それでもいち早く顧客の課題を解決し、より大きな価値を届ける必要があるからです。

日々顧客の声を聞いたり、社内メンバーと話していると、やりたい施策、やるべきと感じる施策は無数に出てきます。

しかし、それらの優先順位づけが甘く、提供価値が小さい施策や、提供価値は大きいが開発期間が長い施策だけにリソースを注ぎ続けてしまうと、顧客はやがて離反してしまいます。世界中で多くのソフトウェアが提供される今の時代、代替案を探して乗り換えることは容易です。顧客は待ってくれません。

また、同じ施策でも提供するタイミングによって価値の大きさが異なることも往々にしてあります。今取り組むべきなのか、半年後に取り組むべきなのか、これを判断するのもまた難しい問題です。

目指すゴールにむけた最短距離を行くためにも、同じ期間内で顧客に届ける価値を最大化するためにも、「正しい順序」を見定めることが重要です。

toBプロダクトにおける優先順位づけ

ここからは、当社での優先順位づけの考え方と実践している手法についてご紹介します。

優先順位づけの考え方

「正しい順序」とはどのように見定めるとよいのでしょうか。

実のところ「正しい順序」というものは存在しないと思っています。正しいか否かは、振り返ってはじめてわかるものです。ただし、できる限り「”正しそう”な順序」に近づけることはできるはずです。

そのためには、なるべく個々人のバイアスを取り除いて、顧客への提供価値とROIを数値化して比較することが大事と考えました。そこで採用したのがRICEのフレームワークです。

施策ごとに

・Reach: 価値を感じる顧客の数・Impact: 提供できる価値の大きさ・Confidence: 自信の度合い・Effort: 開発工数

の4要素を組み合わせてRICEスコアを算出し、優先順位づけに活用します。

大手SaaS企業Intercomで使われている手法です。詳細は是非こちらの記事を読んでみてください。

Reach & Impact

まずはReachとImpactに対して、スコアの定義を行います。以下は実際にNotionで書き出したReachスコアの定義表です。

以下はImpactスコアの定義表の一部です。

Impactスコアでは、単一の指標で提供価値の大きさを測ることが難しいため、以下4つの細分化した項目の合算値をTotal Impactとして算出する定義としました。

・Depth Impact: 業務効率化の深さ。メインユーザーである貿易実務者の業務がどれだけ効率化されるか。こちらのnoteで紹介したSalesチームが行っている”業務定量評価”をもとにしています。・Width Impact: 業務効率化の幅。顧客企業内でどれだけ多くの/多様な部門のユーザーが業務を効率化できるか。・Breadth Impact: 業務効率化の奥行。顧客企業が扱う輸出入案件の何割において業務を効率化できるか。・Blocker Solving Impact: どれだけ大きなサービス導入のブロッカーを取り除けるか。

定義を決めたあとは、それに従って施策ごとにスコアを入力します。

ただし、toBプロダクトにおいてReachやImpactについて解像度が最も高いのは、プロダクト開発チームではなく日々最前線で顧客と接しているSalesやCSのメンバーです。

SalesやCSが持つ知見を反映させるためにも、月1-2回の頻度で「Reach&Impactスコアリング定例」を実施し、SalesとCSのメンバーと一緒にディスカッションしながらスコアを入力していきます。
当社では、貿易業務の経験が豊富なドメインエキスパートが多く在籍しているので、そういったメンバーのドメイン知識もここで取り入れるよう意識しています。

Confidence

Confidenceスコアは、施策により見込める成果に対する自信の度合いです。
これにも定義をつくり、顧客ヒアリングやCSチームからの意見を参考にしながら、プロダクトマネージャーが施策ごとにスコアを入力していきます。

Effort

Effortスコアは、施策を実施するのにかかる開発工数です。これに関しても、プロダクトマネージャーの一存では判断ができません。

開発ボリュームについてなるべく開発チームの考えを反映させるためにも、月2-3回程度のリズムで”T-Shirt-Sizing Weekly”（Tシャツ見積もり定例）を設け、BackEndとFrontEndそれぞれの観点で施策ごとの開発工数をラフに見積もります。

プロダクトマネージャーからは、施策のイメージを箇条書きで説明したり、ホワイトボードにラフスケッチを書くなどして概要を説明します。この時に気をつけたポイントは2点です。

1. プロダクトマネージャーは、ワイヤーフレームやPRDのような過度に具体的なアウトプットは用意しません。毎回重めなアウトプットを用意するとなると、開催すること自体が億劫になってしまいます。目的はあくまでラフな見積であって、仕様を決め切ることではありません。
2. 開発チームには、Tシャツ見積もりはあくまで施策の優先順位を決めるための参考情報であって、細かく開発スケジュールを見積もるための活動ではないことを伝えます。1つの施策に対してじっくり精緻な見積もりを行うのではなく、「この施策は〇〇と同じ規模に見えるから、スコアは8としよう」といった簡易な形で実施し、ある程度雑でも良いのでより多くの施策にスコアリングすることを重視します。

Effortスコアの数値化については、各社・各事業でさまざまな方法があるようですが、当社では普段からスクラム開発の中で使っているストーリーポイントの考え方をそのまま活用し、フィボナッチ数列（1, 2, 3, 5, 8…）を用いています。

T シャツ見積もりを使ってプロジェクトを見積もる方法 • AsanaT シャツ見積もりを使って取り組みにかかる時間や工数を見積もりましょう。T シャツ見積もりの活用法をご紹介します。asana.com

スコアはあくまで参考値

こうやって各チームからの協力を得ながら、Reach / Impact / Confidence / Effortのスコアを数値化し、RICEスコアを算出します。以下は、実際にRICEスコアを算出した施策の一覧です。

これで一件落着。優先順位づけも完了！

となりそうなところですが、RICEスコアの降順をそのまま優先順位とするのは危険です。RICEスコアはあくまで参考値にしかなりません。

スタートアップのプロダクト開発では事業・競合環境やフォーカスするエリアが頻繁に変わったり、ある施策と他の施策が依存関係にあったりなど、RICEスコアでは表現しきれない変動要素が多くあります。

そのため当社では、RICEスコアを用いてなるべく定量的にROIを可視化した上で、最後は事業・プロダクト全体のObjectiveとの整合性を加味しながら、プロダクトマネージャーが意思を乗せて手で並び替えて優先順位を決めています。例えば、向こう半年は「業務効率化の幅」にフォーカスすべきという方針であれば、Width Impactが高い施策の優先順位を上げる、といった具合です。

やってよかったこと

優先順位で悩む時間が減った

個人の感覚で優先順位をつけていた時は「どっちの方が優先度高いだろう？」「この優先順位でよいのだろうか？」といった漠然とした疑問・不安を抱えながら、他チームとも曖昧なディスカッションを繰り返していました。

それが、ある程度決まった型でスコアを可視化することで

・この施策は明確に優先順位を上げた方が良い・この施策は今は着手すべきではない

といった判断を無駄なく行えるようになった気がします。

SalesやCSと共通言語ができた

どんな施策においても、SalesとCSのメンバーと会話する時はReachとImpactについて考え明確化する癖がつきました。

・この施策は最近要望が増えてるけど、実際のReachはどれほどだろう？・この施策のDepth Impactは、もっと大きいのではないか？

といった形で、共通言語をもとに施策の期待効果について会話できるようになりました。ディスカッションと合意形成がスムーズに進むようになった感覚があります。

開発チームと未来の構想を共有できるようになった

これは予想外の副次的な効果でしたが、開発チームに今後中長期的にやろうとしている施策を前もって共有することで、一緒にワクワクできるようになりました。

誰の何を解決するためにこれから何を作ろうとしているのか、今後の構想も含めて話せる時間はなかなか簡単には確保しづらいものです。”T-Shirt-Sizing Weekly”を活用することでこの時間を確保できているのはとても良いなと感じています。

また、ラフな仕様すらないコンセプト段階で開発チームにシェアすることで、事前に実装上の懸念点や考慮ポイントが洗い出せるので、仕様策定にも活かすことができます。

課題

そこそこ工数がかかる

Sales、CS、開発チームの協力を得て定期的にミーティングを実施することで、スコアリングの精度は高まります。一方で、会社単位で見るとそこそこの工数がかかっています。慣れることで効率化はできますが、ここは今も課題に感じているポイントです。開発チームからは代表者のみがMTGに出席する、ミーティングを月1-2回のペースに減らす、といった改善を考えています。

Cが低いけど前に進めるべき施策を軽視しがち

ReachとImpactのスコアが大きくても、Effortが大きくConfidenceが低い、ムーショット系の施策のRICEスコアは低く算出されてしまうので、やや軽視しがちです。ではこういった施策の優先順位が低いかというと、一概にそうとは言えないと思っています。

・Confidenceスコアを高めるためのアクションは取れないのか？・そのアクショは何か小さくモノをリリースすることなのか？・あるいはユーザーインタビューなのか、プロトタイプをあててみることなのか？

といったことは常に考え、必要に応じて強い意志をもって優先順位をあげることも大事です。

繰り返しになりますが、RICEスコアの降順をそのまま優先順位とせず、スコアから読み取れるインサイトを活かし次のアクションに繋げることが大事だなと感じています。

まとめ

• 「正しい順序で価値を届ける」ことは、とっても大事だけどめちゃくちゃ難しい。
• 当社では、RICEのフレームワークを使って試行錯誤している。
• 他チームと協力しながら優先順位づけすることで一定の成果がでてきた。
• でも課題も多いので、改善がんばります。

というお話でした。

さいごに

Shippioではあらゆるポジションで積極採用中です！

• 0.1 → 10を目指すデジタルフォワーディング事業
• 0 → 1で絶賛立ち上げ中のSaaSプロダクト（詳細）
• 0 → 1で絶賛立ち上げ中の物流事業者向けプロダクト（詳細）

など、理想の物流体験を社会に実装すべく、様々なプロジェクトが動きはじめています。

▼プロダクトマネージャー向け求人はこちら

▼採用サイトはこちら

カジュアルに話してみたいという方はTwitter DM（@ygnmn）からお声がけください！