締め会 2022-03-04 プロダクトを中心に考える #とは 1

自己紹介 2017/4からCTOとしてジョイン サーバー、インフラ側のエンジニア セキュリティとか採用広報とか開発に関 わること全般やってきた 2021/10からbc PdMをやり始める 2

2021/10からbc PdMをやり始めて考えたことを共有 3

早速ですがこういうことありませんか？ Biz プロダクトの価値が上がっていない様に 感じる なんとなく開発スピードが遅い様に感じ る 使われないもの作ってるなーと感じる 今それよりも大事な機能作って欲しいな と感じる Dev なんのために作ってるのかわからないと 感じる 方針がコロコロ変わって価値が蓄積され ないと感じる やることが決まって降りてくるので社内 受託っぽく感じる 今着手できるのはこの施策なのでこれを やるしか無いと思って開発してる 4

なんでこういうのが発生するのか？ 5

ROXX CTOのブログ 目的不確実性をコントロール下に置くには、bizdev間での協力が重要なのだと再認識。 devメンバーがどんなことを考え、開発しているのか、bisメンバーがどんなお客様の課 題に直面しているのかを理解し合うことが重要。 あってますか？ — Sorachi Yanagihara (@_soratoon_) 6

半分あってて半分違うという認識 7

別にROXXだけが直面している課題ではない →「人」の問題ではなく「システム」の問題だと考えている 8

今日のお品書き Biz vs Devの構造的な問題 それをどうやって解消するのか 9

Biz vs Devの構造的な問題 10

devメンバーがどんなことを考え、開発しているのか、bisメンバーがどんなお客様の課 題に直面しているのかを理解し合うことが重要。 図にするとこういう感じ 11

この構図ではないのではないか 12

製造業の構図で考えてみる 13

車を作る 1. 車を作るロボットに投資し 2. そのロボットに働いてもらうこと で車を作る 3. 車を売ってお金を得る 一回ロボットをちゃんと作ってしまえ ば、売上-原価が利益として入ってくる モデルになる 14

車を作るロボットを作る人 ロボットを一回作ってしまえば収益にな るのであれば、ロボットを作る人は最初 にショットで雇うだけで十分 15

ソフトウェアの台頭 “software is eating the world.” 16

あらゆる面でソフトウェア化が進んでいる ソフトウェアというものは、「常に変更が可能」なもの 変更が容易なのであれば、価値の向上も容易になる ソフトウェアの台頭により、ユーザの当たり前は「一定の価値を得られる」という状態 から「価値が漸進的に上がっていくこと」になってきている つまり、価値が上がり続ける仕組みに対してユーザはお金を払ってくれるという世界になっ てきている →なので月額課金モデルの相性がよいというだけで、月額課金モデルがSaaSの本質ではない 17

さっきの図で説明すると… 車は常にバージョンが上がり続け ることが前提となった それを作るロボットもバージョン が上がり続ける必要がある ロボットを作る人は一回作るだけ ではなく、継続的に改修していく 必要がある →つまり僕らはDevを雇っている以上、 ソフトウェア的に価値を提供し続けるこ とを前提としている 18

会計指標で抽象化する PL:車を売る、BS:ロボットを作る、GP:ロボットを作るスピードを上げる 19

THE MODEL型組織に当て はめると… PLを追ってるBizはそれ ぞれに時間の差はあれど 同じ次元で活動している 開発や人事といったとこ ろはユーザ価値につなが るスピードを早める次元 で活動している その間にB/S(以降「プロ ダクト価値」と呼ぶ)が いる 20

つまり… Bizが追ってる次元と、Devが追ってる次元に2段階の差が構造上存在している P/L(利益)を追っている人とG/P(生産性)を追ってる人の間にB/S(プロダクト価値)の 次元が存在する その構造を取っ払って、 Biz ⇔ Dev という形で考えようとするから認識に齟齬が生まれ る 「BizがXXをやってくれないから」「DevがYYをやってくれないから」は双方やる 責任があるわけではない。 「プロダクト価値」に当たる役割をちゃんと設けられればこの認識の齟齬はなくなる 21

じゃあこのプロダクト価値って具体的に何なの？ 22

その前に 僕らって何のために事業やってるんだっけ 23

顧客を今の状態からあるべき状態にするため その対価として顧客からお金をもらっている 24

つまりこういう感じ 25

2 どういう状態にしたいか 1 誰を 3 なぜ僕らがやるのか 26

「誰を」「どういう状態にしたいか」「なぜ僕らがやるのか」は変わら ない 様々な機能が追加され いろいろな方々が配属されたとしても 顧客にどうなってほしいのかというのは変わらないはず。 僕らはソフトウェア的に価値を提供したいと思っているので、それを漸進的に向上し続けら れるかどうかが「プロダクト価値」が追うべき指標 例)車を作るとして スリル感のある乗車体験を与えたいか 家族で一家団欒の体験を与えたいか によって車が持つ価値が変わる 27

擦り合うべきは Biz⇔Devではなく、 Biz+Dev⇔顧客 僕らが思う「顧客にこう なってほしい」と 顧客が思う「こういうこ とをしてほしい」が 互いにそろうかどうかが大事 であり、その実現のために DevとBizが役割分担して実 現していく 28

定性的な理想状態だけではなく、数値で物を語る 誰をどういう状態にしたいというだけだと、現状を理解することが難しい 共通言語で語るためには測定可能な数値にし、現状と理想の差分を認識しないと目先何 をしないといけないかがわからない 現状の数値は顧客の現状を示してくれる、その差分がすり合わせるべきものである 29

「プロダクト価値」で追うべき数字=NSM プロダクトの成功を常に指し示すような指標を航海における北極星のようなものとして North Star Metricsといいます。 https://note.com/ozyozyo/n/n4935c95d062a 下記の条件を満たす指標 ビジョン、顧客価値、事業収益のInput Metricになっている AARRR(Pirate Metrics)のどの項目の改善にもつながっている 測定可能である(月に1度など、高頻度で計測できないものはNG) 総会員数などの積み上げた数字ではなく、計測期間だけの結果 ユーザーがプロダクトの価値を感じている瞬間であること 例 slack: メッセージの送信数 Amazon: プライムユーザーの平均購入数 30

まとめ BizとDevの認識の齟齬は構造上の問題から発生する。 齟齬を解決するには「誰を」「どうしたいのか」という認識の統一が必要 認識を揃えるためには数値化が必要で、NSMと呼ばれている 31

チェックリスト 「誰を」「どうしたいのか」は擦り合っているか それを図る指標は存在するか それを達成することが目標設定の根幹にあるか まだできていないというのがあれば、ぜひ一緒に作っていきましょう 32