要求管理と優先度づけの世界
Showcase Gig Advent Calendar 2022 7日目の記事です。
今回は、以下のnoteで触れられている「VOCや社内要望管理プロセスを精緻化し、強いプロダクトフィードバックを返せるようにしたい！」というお話を受けて作成した社内資料を、ほぼそのまま公開してみる試みです。
(口頭補足した部分や、内部事情に関する部分は、加筆修正しています。)
社内でこんな感じの話をしているんだな〜とか、こういう風に連携しているんだなぁ〜とか、そういった空気感もあわせて感じていただけると幸いです。
それでは、本編へ。
今回話す全体像
細かいことは後述していきますが、一旦はこういった全体の流れがあるんだなというのを抑えておきましょう。なお、上図は「要求」の流れを可視化したものであり、開発フローとはまた異なるという点にご注意ください。
社内要望は一番下の灰色の帯で、VOCについては主に緑の帯になりますが3つに分類されています。
要求の源と事業影響の関係性について
一般的にBtoBビジネスにおいては、課題解決型のアプローチを取ることが多く、「誰の」「課題を」「なぜ」解決するべきなのかを正しく理解することが重要となります。
これを理解していくための前提として、下図のように表される多層的な依存関係を抑えておきましょう。
💡 この図はBtoBtoCな事業モデルを前提として作成しています。他のモデルであっても必要に応じて以下のように読み替えればいいはず。
BtoBの場合
「消費者」の層に属するUser Personaが不要。
(あくまで「プロダクト」の視点から直接的に影響を与える「消費者」はいないという意です。バックオフィス系ツールなどが例。)
BtoCの場合
「顧客」の層が不要。
正確には「消費者」= 「顧客」であり、「消費者」の層にBuyer-User Personaのみが存在すると解釈するのがよいでしょう。
この「誰の」課題を解決するかによって、事業に対する影響が大きく変わってくるため、この要求の源について正しく理解しておきます。
なお、BtoBにおいて売上に直接関係する「顧客」については、収益化までの時間軸を元に3つに分割して整理をしています。
マーケット: TAMに影響
TAMや競合環境, マーケットニーズ等の事業機会のことを主に指す。
消費者: 顧客との関係性による
例えば飲食店の場合は、消費者に商品を提供することで収益を得ている構造にあるため、消費者のニーズが飲食店側のニーズに転化されることも多い。
潜在顧客: 将来的な売上に影響
検討中/既存顧客を除いたその他すべての顧客を指しているため、必然的に最もボリュームが大きい。この潜在顧客を正しく理解することが、最速の事業成長へとつながる。
参考:
・プロダクトマーケットマッピングを用いた開発ロードマップ作り~地図とコンパスを作ろう~ - LayerX エンジニアブログ
検討中顧客: 直近の売上に影響
獲得によって新たな売上が生まれる。SLGモデルにおいて営業チームが主に担当する部分であり、最もP/Lにヒットする対象でもある。そのため優先度が常にHighになりがちであるが、SaaSビジネスの成立要件であるCACやLTVを適切に評価しつつ、顧客にとってもROIは見合っているかを見極めたうえで判断をしていくことが重要。
参考:
・SaaS企業の「営業」に求められるスキルと素質
・BtoB SaaSで「ROI」を特定する意義とその方法──Sansanを実例に、“事業貢献数値”から組み立てる
既存顧客: 現在の売上に影響
今を支える売上であり、従量増加やアップセル/クロスセルなどカスタマーサクセスが伴走しLTVを最大化することが求められる。カスタマーヘルススコア等によるモニタリングが重要。
この分類は、最終的に行う優先度づけのプロセスにおける重要な軸となるので、適切にラベリングしカスタマープロファイルなどと紐付けておくと後で困らない。
要求を獲得し、課題を抽出する
要求の獲得手法としては数多存在するが、要求の源に応じて有効な手法は異なる。得られる情報としては「定性情報」と「定量情報」に分類することができ、それぞれ以下のように特性が異なる点を抑えておく。
定量情報
デスクリサーチ
アクティビティデータ
アンケート
などによって得られる、構造化可能なデータ。
そのため、適切な前処理を行うことでデータ分析が可能となる。
一方で、データ量も膨大になることが多く、逆算的にどういったデータを集めるべきかの設計を行えていることが重要なケースが多い。
定性情報
ユーザーインタビュー
フィードバック/リクエスト
商談 / 受失注理由
などによって得られる、非構造化データ。
そのため、デザイン思考などのアプローチを用いて、解決すべき問題を明らかにしていくことが重要となる。また、定量データを用いて裏付けを行うことも有効。
💡 定量情報と定性情報はバランス良く獲得することが重要であるが、実際には定量情報もしくは既存/商談中顧客からの「フィードバック/リクエスト」などの、受動的に集まる情報ばかりが無意識的に集まってきます。
結果として、知らないうちに既存顧客に過度に最適化されたプロダクトとなり、事業拡大を阻害しSaaSビジネスを破綻させるリスクが高まる。このリスクを低減させる意味においても、定性/定量情報を様々な要求源よりバランスよく声を集められているか、その声は一般性が認められる内容か？を常に点検することが重要です。
課題の大きさを評価し、優先順位をつける
集めた要求を分析し、解決すべき課題が明らかとなったものが、開発チケットとして積まれる。 そして、優先順位づけが行われた後に、上位のものから順に着手していくことになる。
優先順位をつけていくにあたっては様々な方針があると思うが、「ROI」はやはり外せない要素であり、これを評価できる必要がある。
Return: 課題の大きさ (≒ Outcome)
Invest: 工数
「Invest」については工数見積の世界であり、一般的にここはすでに管理されていることが多いためここでは触れない。
「Return」については銀の弾丸こそないが、考え方のコツはあったりするのでこれを理解する。
まず、要求の源は様々であるが、要求の源毎に影響範囲が異なるので1つの軸で比較し妥当性を証明することは不可能であるという前提がある。
💡 単一軸の設定と働く力学の例
・「売上」という軸の場合は、検討中顧客の要求を満たすことで新規獲得につながるため、自ずと検討中顧客の要求が上位となる
→ 直近の売上を構成し、セールスが主に負う領域。セールスうれしい。
・「LTV」という軸の場合は、既存顧客の要求を満たすことで向上する指標であるため、自ずと既存顧客の要求が上位となる
→ 現在の売上を構成し、CSが主に負う領域。CSうれしい。
・「TAM/SAMの拡大」という軸の場合は、潜在顧客もしくはマーケットの要求を満たすことで達成されるため、自ずと潜在顧客もしくはマーケットと要求が上位となる
→ 将来の売上を構成し、PMが主に負う領域。PMうれしい。
一方で、同じ要求源であれば、一元的に優先度をつけることは可能とも言えます。
売上などの定量指標を取れる場合はもちろん、オペレーション影響やUXなど定性比較にならざるを得ない場合において、範囲を絞ることで一元的な優先度づけが可能になるというメリットは大きい。
ここまでの話を踏まえ、優先順位づけには大きく2つのアプローチが取りうるでしょう。
要求元毎に優先順位付けし、リソース比率でコントロール
複合的な重み付けのルールを定め、スコアに応じた優先順位付けを行う
なお、1か2か全社で統一する必要はなく、領域毎に適切な手法を選択していることが大半かと思います。
大事なのは、どちらのプロセスに乗っているのかを理解したうえで、最終的な「軸」に相当する情報を収集することです。
「軸」が混ざっているのか否かで、優先度づけの難度は天と地ほどの差があります。
選択肢1. 要求元毎に優先順位付けし、リソース比率でコントロール
メリット
UXやオペレーション影響など、定性的な評価になるものについても相対比較による優先度づけが可能
優先順位に対する評価もシンプルかつ明瞭なものとなるため、客観的な議論がしやすい
優先順位づけの意思決定権を移譲しやすく、組織全体としてスケーラブルな仕組みにできる
顧客思考なプロダクトチームを目指していきやすい形でもある
デメリット
事業環境の変化に合わせて定期的に比率を見直さないと、横断してみた際に結果的にロスが発生する
いわゆる、隣のチームなんでそんなことに時間つかっているの？現象
比率を変えるには組織変更を伴うため、アジリティが低い
複数のチームが必要となるため、一定規模以上の開発組織でないとこの選択を取ることができない
説明
いわゆる、「新規開発チーム」「運用開発チーム」といった考え方がこちらになります。
最終的な優先度の評価でも、優先度を決めるまでのプロセスにしても、シンプルな形になるため、「選択肢2」よりも運用コストはリーズナブルであり、自律的な開発組織を目指していく場合にも有効な手法になります。
選択肢2: 複合的な重み付けのルールを定め、スコアに応じた優先順位付けを行う
メリット
ルールさえ決定してしまえば、複数の要求源にまたがっていようとも統一された比較軸の元に優先度が決定される
基本的に恣意的なコントロールは難しい
(正しい優先度であるという前提ではあるが) 本当に取り組むべき課題から順に開発を行える
プロダクトフェーズが若い、開発組織が小さいなどの複雑性が低い場合に特に有効
デメリット
あらゆるステークホルダーを集めた優先度を決定する場が必須となり、プロセスとしては必然的に重くなる
良くも悪くもルール次第であり、その優先度に対する証明や説明を行うことは困難
プラクティスとしては、厳密性を追い求めるよりかは納得感を重視したコミュニケーションツールくらいにとどめておくのが良い。
最終的になんらか定性的な意見を織り交ぜる必要が生じるので、この可視性を高める努力が求められる。
優先度順にタスクに取り組むこととなるため、クロスファンクショナルチームとして組成をしておかないとこの運用に耐ええない
開発チームはアウトプットにフォーカスすることになるので、「デリバリーチーム」「フィーチャーチーム」に寄りやすい
説明
関連する要素を洗い出し、それぞれの要素に相対的なスコアを付けることで、なかば無理矢理にでも定量化し、優先順位を定めるという手法。
💡 カスタマーヘルススコアも同様の思想ではあるが、あくまで既存顧客にフォーカスしたスコアリングの仕組みである点がここの話とは異なる。
なお、この計算軸の1つに「Confidence(確信度)」という概念が出てきますが、どれだけインパクトがあったとしてもConfidenceが低いのであればこれを高めていく活動を優先すべきであり、どのようなロジックであれConfidenceが低いものが上位とならないような工夫が必要です。
Confidenceを高める方法として、以下のような手段が取れるということは抑えておくと良いでしょう。
スコープを小さくし、多段的に検証を行う (リアルオプション)
実装前に営業活動などを行うことでニーズの検証を行う (プレトタイプ)
おわりに
最近だと、こういった一連の要求管理から優先度づけの部分を効率的に行えるSaaSなども出ているようなので、予算がある場合はそういったツールに素直に倣うというのも一手かもしれませんね。
特定領域のSaaSもかなり充実してきていて、しのごの言わずその設計思想に倣えば最良のプラクティスを最短で学べるいい時代なので、とにかくSaaSに投資するのはオススメ
— Yuta Kanehara (@yukagil) November 26, 2022
個人的には、スプシであれ、JIRAであれ、Asanaであれ、なんでもよいのですが、この一連のワークフローでツールが分断されないように設計することはMUSTかな〜と思っています。
💡 ちなみに弊社では、ClickUpというツールを用いています。フォームから要求を起票できるようにし、formulaの機能で最終的なスコアリング等を算出し、そのまま開発チケットとして渡るような形を目指しています。
ただし、やっぱりタスク管理ツールだと、インタビューなどの定性的な情報の取り扱いが苦手な感じは否めず、1から設計できる方がいるのであればNotionあたりに統合するのが結局いいのかなというお気持ち。
また、少し横道にそれるのですが、以下の記事でキーエンス社には「ニーズカード」という仕組みがあると知ったので、この仕組みについて理解を深めることでより学びが得られそうだな〜なんてことも思いました。
さて、今回は要求管理の話を中心に書きましたが、プロダクトマネージャー Advent Calendar 2022の12月17日に予定している記事では、「優先度」に関して昨今の情勢も踏まえ、もう少し深堀りしてみた記事を書く予定です。
→ 書きました！！
それでは、みなさま良いお年を🎍
おいしいごはんでも食べて次の活力にします！