見出し画像

あなたは回避できてる？ROI にまつわる7つの落とし穴

はたけ

意思決定の天才達は何を考えているのか？

日々は意思決定の連続です。そしてその意思決定のために、みんな大なり小なり ROI、つまり投資対効果について思いを巡らせたことがあるでしょう。

しかし、「自分は ROI の見立てがうまい」「自分は意思決定がうまい」と自信を持って言える人はいったいどれだけいるでしょうか？

世の中には、ROI の見立てとそれに基づく意思決定が天才的に上手い人たちがいます。

彼彼女らは、ふとした問いからはじめて、事業や組織全体の流れを変えることが得意です。重要なのは、事業や組織のフェーズ・職種・ビジネスモデル等に関わらず、そのような一見天才的な思考にはある種のパターンが存在する点です。特に落とし穴には明らかなパターンがあり、彼彼女らはそれらを回避したり、自在に使いこなしたりすることに長けているのです。

ラッキーなことに、現職 Ubie においても天才たちが在籍しており、自分も直近5年間で意思決定が抜群に上手い彼彼女らと一緒に働く機会を得ました。また、自分自身も深く関与した数えきれないほどの失敗、2回の PMF、1回のターンアラウンド等を通じて、そのいくらかを血肉にすることもできました。

この記事は、事業責任者、プロダクトマネージャー、プロダクトオーナーと呼ばれる人たちをはじめ、広く「ROI の見立てがうまい人、意思決定が上手い人は何を考えているのか」という問いに関心のある人を読み手として想定しています。

繰り返しになりますが、ROI の見立てとそれに基づく意思決定には典型的な落とし穴があります。これらを意識的に回避するだけで、スタートアップで必要な ROI の意思決定のセンスを、再現性を持って高めることができます。

以下ではまず ROI のゆるやかな定義からはじめて、その後典型的な落とし穴としていくつかのパターンに触れます。その後、それらにどうやって立ち向かうかに話を展開します。

ROI の議論で見落とされがちな価値

Ubie Discovery では ROI に基づいたプロダクト開発や事業開発が徹底されています。
一般に ROI の見積もりというと、たとえば人件費や販管費、商談数、商談あたり売上等、直接的に P/L への価値貢献が期待できる変数が扱われがちかと思います。しかし、これらだけをインプットに ROI を見立てて意思決定するだけでは、多くの「見えづらい」価値を見逃してしまうことをここで強調しておきたいです。

「見えづらい」価値とはなんでしょうか？社内ではよく「アセット」「B/S 価値」と呼んでいるものですが、たとえば次のような変数が存在しています。

  • データ

  • ブランド

  • ネットワーク外部性

  • 技術的負債

  • ユーザー体験

  • Ubie の採用要件 Ubieness を備えた人材

心当たりがある方もきっと多いと思いますが、これらは比較的 P/L に直接計上しづらいものです。しかしスタートアップにおいては明らかに中長期的な成長に資する変数であり、かつ、どんなに賢い人であってもヒトがもつ認知バイアスの影響によってつい過小評価しがちなものです。Ubie Discovery においては、P/L への直接的な貢献が期待できる変数に加えて、これらのアセットを変数に加味して ROI の意思決定をすることがどのチームであっても推奨されています。この先で触れる「ROI にまつわる7つの落とし穴」については、このような視点もあるということを念頭において読んでいただければと思います。

ここでは ROI の見積もりに登場しうる変数をざっと見てきました。次に、ROI の意思決定が得意な人たちは、いったい何を考えているのでしょうか？以下ではそれらを一つずつを見ていきましょう。

ROI にまつわる7つの落とし穴

1. 四半期や半期ごとの ROI に囚われる

  • 多くのスタートアップでは、OKR 等を活用して四半期や半期単位で目標設定を行うケースが多いでしょう。

  • 現在志向バイアス、つまり「未来の利益よりも目先の利益を優先してしまう」というヒトの特性は、中長期的な ROI を短期的な ROI と比べて過小評価してしまうという形で現れます。

    • 中長期的リターンの過小評価の例としては、ブランディングや大規模なデータの回収、他社とのパートナーシップが挙げられるでしょう。これらは短期的な OKR とは相性が悪いことも多く、つい優先度が下がりがちになったり、手段が目的化しがちです。

    • 中長期的インベストメントの過小評価の例でいうと、たとえば今期で何かのサービスをリリースするとしたとき、次期以降その運用にどれだけのコストがかかるかを無視したり、するケースがあるでしょう

  • つい忘れがちなことですが、四半期や半期といったタイムフレームは、あくまで人間が考え出した概念にすぎません。たとえリターンやインベストメントが中長期的な場合でも、それが本当に重要なものなのであれば、中長期で得たいリターンから逆算してマイルストンを明確にし、四半期や半期といったタイムフレームを超えて投資し続ける覚悟をもつ必要があるでしょう。

2. 「負債」を恐れ過ぎ

  • スタートアップにはさまざまな負債が存在します。いわゆる技術的負債をはじめ、ユーザー体験の負債や、ブランドの負債、オペレーションの負債、カルチャーの負債等が存在するでしょう (少なくとも Ubie ではこれらを負債として認知した上で、適切に制御しようと試みています)。

  • たとえばスタートアップにおいては次のようなアンチパターンが挙げられるでしょう。

    • まだゼロイチフェーズで PMF に到達していないのに、技術的負債の返済に躍起になる。

    • まだシンプルな設計でいいのに、将来使うであろうコンポーネントまでつくってデザインシステムを構築しようとする。

    • まだ顧客がほとんどいないのに、完璧なオペレーションを構築しようとする。

  • アセットを生み出すため活動の大半は、大なり小なり負債も同時に計上します。負債をまったく積まないは無理です。変化の大きいスタートアップにおいて、負債そのものを恐るかわりに、「いつ負債を返済すべきか」の見極めを適切に行うのが重要です。

3. 事業責任者がリターンよりインベストメントばかり気にする

  • Ubie Discovery では組織的にスクラムが導入されています。スクラムの世界では、プロダクトオーナーは ROI の最大化に責務を担い、開発者は個々の価値の実現に対して責務を担っています。

  • あくまで傾向ですが、プロダクト開発の経験が少ないプロダクトオーナーほど開発者に遠慮しがちで、開発者への負担が増大することを恐れて初手の施策から小さくまとまってしまうことがあります。

  • 最終的にチームとしての ROI が最大にするため、プロダクトオーナーは最初から小さくまとまることなく、まず「いかにして期待リターンを100倍にできるか」から議論を出発させ、その上で開発者と一緒に実現可能な部分まで削ぎ落としていくとスムーズでしょう。

4. ROI の再評価を忘れる

  • ROI は常に変わります。先月見積もった ROI が、今月も変わらず同じであるといったことはほとんどないです。これはスタートアップでもかなり多くのプロダクトマネージャーやプロダクトオーナーが見落としている重要な点です。ROI は期待リターンと想定インベストメント、さらにそれらをそれぞれ分解した変数で構成されるため、そのどれか一つの変数でも変わるといつの間にか ROI の見立てまで変わっていることがよくあります。

  • たとえばユーザーリサーチをしていると、明らかに光輝くダイヤの原石のようなインサイトが得られて、さっそく実装したくてたまらなくなることがあります。ただ、それを元にいざ本格的な実装をしようとすると、まだ前提条件のAとBとCが揃っていないため、まともに実装できない、またはできたとしても ROI はまだ低いことに気づき、「これは今じゃないだろう」といった意思決定をすることが頻繁にあります。これを Ubie では「戦略的保留 (ペンディング)」と言います。将来的に想定インベストメントが小さくなる、または期待リターンが大きくなる可能性が十分に高いなら、今すぐやらないことの価値が高く、戦略的保留が望ましいです。

  • ここで重要なのは、その時点でどのような意思決定をしたかを後からすぐ思い出しやすい・再現しやすいよう簡易的にでも記録しておくことです。Ubie 社内ではこれを Decision-making Log と呼んで活用しています。これは頻繁に事業環境が変わるスタートアップにおいて非常に有効な手段で、あとから環境が変わったタイミングでスムーズに ROI の再見積もりを行ったり、過去の経緯を新メンバーに共有したりすることが可能になります (詳細は次章で解説）。

5. 現有戦力の延長線上でのみ未来を考える

  • 現状のリソースの延長線上で考えるというのも、スタートアップのプロダクト開発・事業開発の典型的なアンチパターンです。

  • 特に人的資源は線形成長を想定しやすいもっとも典型的な例ですが、たとえば凄腕エンジニアが一人入ったら単純に「1人月」増えるどころの変化ではなくなることも頻繁にあります。また、エンジニアリング以外でもこれはあてはまります。たとえば他社との協業による販路拡大、再現性のあるリファラルスキームの発明、定期的に発生するオペレーションの自動化等がまさにそうです。

  • 現状のリソースにとらわれすぎず、この制約条件を削ったら何ができそうか、この拡大ペースを10倍速にするにはどうしたらいいか、などハックできる方法を考えてみるのは、戦況を変える変化を狙って起こす上でとても有効です。

6. 感度の高い変数と感度の低い変数を区別しない

  • 世の中には、同じ刺激を与えた時に、10倍変化する「感度の高い変数」とせいぜい1.1倍しか変化しない「感度の低い変数」があります。スタートアップの事業の ROI の意思決定に携わる人、たとえばプロダクトオーナーやプロダクトマネージャーの重要な仕事は、この前者のような指標を特定して、かつ伸ばすことです。

  • 感度の高低については、数字の変化やユーザー行動の変化を毎日仮説を持って見ている人だけが気づける境地があります。深追いしてもせいぜい小さな改善しか見込めない場合は、そこを深追いするのを止めて、次の仮説を試すようチームの方向を軌道修正するのもプロダクトオーナーやプロダクトマネージャーの重要な仕事です。

7. なんとなく惰性で継続する

  • スタートアップの大きな強みは意思決定のスピードです。スピードだけで全てうまくいくわけではありませんが、もし誰か・どこかの部署に忖度して何かの意思決定を躊躇ったり、惰性で何かを継続する場合、それはすなわちほとんど自ら失敗確率を上げにいっていると同義になるでしょう。

  • 多くの場合、何かを始めた後のステップでやるべき事業上の意思決定は、次の4つのどれかに収斂します。たったこれだけです。「なんとなく様子見する」「なんとなく惰性で継続する」といったオプションが含まれていないことに注意してください。

    • 活動を加速させる

    • 活動を止める/減速させる

    • 活動の方向性を変える

    • 活動の方向性をキープする (意識的に様子見する)

  • このあたりの意思決定が抜群に速い人は、より少ない情報で意思決定が可能ですし、事前にリリース後どのように効果検証するかの設計をサボらず行っているのをよく見かけます。リリースしてから考えよう、がまず存在しないです。

これらの落とし穴とどう立ち向かうか

以上が ROI にまつわる7つの典型的な落とし穴です。

あなたが事業責任者、プロダクトマネージャー、プロダクトオーナーであれば、もしかしたら個々の話は聞いたことがあったり実践したことがあるかもしれません。ただ、これらをチームレベルや組織レベルで徹底して実践できているケースは、弊社を含めまだまだ少ないように感じます。

ではこれらを実装するためにはどうすればよいでしょうか？どうすれば落とし穴を回避できるようになるでしょうか？以下、実際にやってみてよかったおすすめのアプローチ4つを簡単にご紹介します。

a. ROI の意思決定の記録を残す

  • 重要な意思決定をした際には、当時どのような経緯でどのような意思決定をしたのか、簡単で構わないのでとにかく記録しておくことが重要です。

  • 落とし穴のパートでも紹介した弊社で使っている Decision-making log のフォーマットは、たとえば次のようなものです。

  • ✍️ Decision-making log で記録しておくとよい要素

    • 目的はなんだったか

    • 当時のチームや事業の状況はどうだったか

    • ROI を見積もる際に考慮した変数は何か

    • それぞれの変数をどう評価したか

    • 結論として、何を決めたか

    • ネクストアクション

    • (もし戦略的保留をする場合) いつまで保留するのか。再開するなら何がトリガーになりうるか

  • このような意思決定の記録には2つの効用があります。

    • 単純に後で思い出しやすい：数ヶ月後、当時の結論だけ覚えていても、どのような経緯でROI をどのように評価しその意思決定に至ったかを思い出すのが大変、というケースは少なくありません。そのような場面で、すぐ当時の意思決定を再現でき、すぐ ROI の再評価を行える、という効用があります。Slack の記録を発掘したり、当時の担当者を探してその人の記憶を掘り起こす旅をするより10倍ラクです。

    • 何かをやめることに対しての躊躇がなくなる：一般に、何かをやめることは「失敗」と捉えられがちですが、これに対しての心理的ハードルがかなり下がります。

b. What if…? で複数のシナリオを常に考える

  • どんなにデプロイの回数が多いチームでも、試行回数そのものは有限です。

  • そんな中でも、what if…? (もし…だったらどうする?) を問い続けて ROI の変数をいじって複数のシナリオパターンをチームで考えてみる、というのが有効です。このような問いの多いチームは、明らかに軌道修正が大胆かつスピードが速いです。

  • 自分の場合、特によくやるのが以下3つの問いです。これらは今日から実践できることだと思うので、ぜひ試してみてください。

    • 「実は取り除ける/固定できる変数はないか。その制約条件を取り除くと、何ができるか」

    • 「もし、ある変数を取り除いたらどうなるか」

    • 「もし、ある変数が100倍に伸びたら何が起こるか」

c. {自分/チーム/組織全体} が {過小評価/過大評価} している可能性の高い変数は何かを考えてみる

  • 要はメタ認知をしようという話ではあるのですが、メタ認知をチーム/組織全体に広げてやってみることが重要と考えています。今置かれている環境と、そのなかでの自分の位置付けについて適切な認知ができているチームや組織は正直かなり強くて、軌道修正のスピードが尋常じゃないです。

  • 多くの場合、自分が疎い分野についての ROI 見積もりはだいたい乱暴になりがちです。また、自分個人の場合に比べて、チームや組織の場合は要求されるメタ認知のレベルが高くなります。

  • ではどうするか。基本的には計測・比較・相対化する中で過大評価や過小評価をキャリブレーションしようという営みは同じです。認知の歪みがどこで起きているかを様々なレイヤーで注意深く観察することが重要です。

d. 一度設定した OKR をまめに点検する

  • 目標設定は重要ですが、それ以上に目標の軌道修正こそ重要です。期初からパーフェクトであることはほとんどの場合においてありません。

  • Ubie Discovery では、週次や月次でメンバーを入れ替えながら OKR を見直す定例がチェックポイントとして機能しており、そのタイミングで何の活動を止めるべきか、逆に何を加速させるべきか、などの議論を行っています。これによって、OKR の形骸化を防ごうとしています。

  • 既にあなたの企業でこのように目標設定を見直す会議体があるのであれば、毎週15分や30分だけでもいいのでぜひやってみて、以下4つのどのオプションを取るべきか考えてみてください。明らかに OKR の軌道修正が捗るので、おすすめです。

  • ✍️ 何かを始めた後のステップでやるべき事業上の意思決定

    • 活動を加速させる

    • 活動を止める/減速させる

    • 活動の方向性を変える

    • 活動の方向性をキープする (意識的に様子見する) 

以上、ここまでで「ROI の見立てがうまい人、意思決定が上手い人は何を考えているのか」という問いに対して、自分のこれまでの経験から比較的再現性をもって言えそうなことをつらつらと書いてきました。

繰り返しになりますが、ROI の見立てとそれに基づく意思決定には典型的な落とし穴があります。これらを意識的に回避するだけで、スタートアップで必要な意思決定のセンスを、再現性を持って高めることができます。

We Are Hiring.

Ubie では、全組織にて積極採用中です。
人生は一度きりです。
「テクノロジーで人々を適切な医療に案内する」というこれまでの医療体験を大きく変える壮大なミッション、ぜひ一緒にやってみませんか？

Ubie Discovery (プロダクト開発・事業開発組織)

  • QA エンジニア

  • ソフトウェアエンジニア (デリバリー&サクセス)

  • 基盤開発エンジニア

  • SRE (Site Reliability Engineer）

  • プロダクト開発エンジニア

  • Strategic Technical Solutions Engineer

  • メディカルコンテンツディレクター

  • パートナーマネジメント・事業開発

  • 医師

Ubie Corporate (コーポレート組織)

  • 法務

  • ミドルオフィス

  • 経営企画リード

Ubie Customer Science (医療機関事業組織)

  • パートナーセールス

  • フィールドセールス

  • カスタマーサクセス

  • 事業部長・マネージャー候補

  • 人事責任者

Ubie Pharma Innovation (製薬事業組織)

  • アカウントプリンシパル

  • アカウントマネージャー

  • 人事責任者候補

  • 製薬事業開発 Ops

  • ミドルオフィス

  • イベントマーケター

Ubie Global (海外事業組織)

  • Full-Stack Business Development Lead (NY-based)

  • Sales Lead (NY/NJ-based)

  • Lead Software Engineer (India-based)

  • Lead Software Engineer (Japan-based)

  • Lead Product Designer (Japan-based)

  • Lead Product Designer (Singapore-based)

参考にしたもの

  • その他無数の社内での実践知

この記事が気に入ったらサポートをしてみませんか？