あたまがきんに君です。Product Led Growthを読んで思ったことを書きます。※今の組織に対する意見というものではなく、今まで仕事をしてきて得た情報と本書を読んだ上でより体系化されてきたものをまとめたものになります。単純に個人的な学習記録として残します。全て個人の感想・考察になります。弊社の事業については仲間を信頼しています。

本書を読もうと思った理由

一言で言えば、仕事で成長が頭打ちになってきているという悩みを解消できる本だと思ったからだ。

転職して約一年が経った頃、仕事で成長が頭打ちになってきていると感じていた。その理由は自分がやるべき範囲のことを当たり前にできるようになってきたからだ。私はなんとかやるべき範囲を広げようと思っていた。ちょうどその時に、私が続けていた社会人サッカーで、ある役割をもらった。それは、「試合に勝つための戦術をチームに導入すること」だ。その役割をこなしていく中で私の悩みに対する答えを見つけることができたのだ。

その答えとは、「やるべきことの範囲を広げるには、戦術理解度を高めることが効果的である」ということだ。

社会人サッカーでは戦術を導入していく立場だったが、その中で戦術理解度の高い個がいた。その戦術理解度の高い個は、「試合に勝つために戦術を導入する」というチームのミッションに向けて自発的に学習を繰り返し、時には周りを巻き込んでディスカッションしたり、自分の周りの連携を強化しようとする。

その結果、チームとして私が現フェーズでは手が回らないだろうと思っていた領域まで手を伸ばせるようになったのだ。要するに戦術理解度の高い個がいることで、チームのケイパビリティが向上した。その結果、チームに勝つための戦術を導入するというミッションの実現が早まったのだ。

その戦術理解度の高い個を観察してみると、戦術理解度が高いことに起因して、理想と現状のギャップに対する解像度も高まり、自分のロールを飛び越えた働きをするようになったのだと思う。もともとその個にそれほどのキャパシティはないと勝手に思っていたが、戦術理解度が高いことによって、頭をシンプルに使えるようになったようだ。空いた脳内の容量を使って自己学習やチームに必要なことを自分で考えて動くようになった。

私は不意にも、その"個"を正しくイネーブルメント（自己組織化）することができたのだった。

私がその"個"にやったこととしては、目指すべきところの言語化、問題空間の定義、問題空間を適切な階層・粒度のサブシステムに分解すること、そしてサブシステム間の関係を明示することだ。戦術理解度が高いというのは、これらを自分の頭で整理して考えている状態だと考えた。

ここまで考えた時に、私の仕事の悩みを解消するためにすべきことがわかったのだ。

私も会社や所属している事業部の戦術理解度を高めることができれば、私自身が、組織の中の個として正しくイネーブルメントされ、速い学習サイクルや適切な視点を得ることができ、やるべきこと・やれることの範囲が勝手に広がっていくのではないかと考えた。

そして、私が所属している事業部はセールス主導型のToB SaaSのサブスクリプションビジネスの分野に位置しており、事業のグロースに対して課題感がある。そしてうちの事業部長が「この本オススメ♡」と言っていたので読むことにした。

本書を読んだ後に目指すべき状態

組織の戦略を理解して、その組織に属する個として自分がイネーブルメントされている状態を目指す。要するに頭をシンプルに使えるようになっていて、適切な学習が行える状態を目指す。

具体的には以下の3つが私の頭の中で整理されている状態。

1. 事業が取り組んでいる問題空間を頂点から適切な粒度と階層のサブシステムに分解した状態（The modelの解像度を高めた状態）

2. サブシステムごとの責務と、あるサブシステムが隣のサブシステムとどう連動しているか（システム図でアウトプットしたい。）

3. アプリケーションエンジニアとして私が考え続けるべき問いは何か？（自分の業務にまで落とし込めて考えられている状態）

本書の内容

サブスクリプションビジネスを取り巻く3つの戦況の変化から、サブスクリプションビジネスが取るべき戦略は、セールス主導型GTM戦略ではなく、プロダクト主導型GTM戦略をオススメすると言う内容である。

サブスクリプションビジネスを取り巻く3つの変化は本書でこう述べられている

こういった戦況の変化を本書の内容を用いながら検証し、必要ならば（多くの場合）プロダクト主導型GTM戦略に変えていくべきであるというのが本書の主張である。

検証方法や、実際にプロダクト主導型GTM戦略を行う方法も詳しく書かれているので興味がある方はぜひ一読することをオススメします。

また、プロダクト主導型GTM戦略は、フリートライアルやフリーミアムを導入するということだけではなく、文化であるとも言われていた。プロダクト主導型GTM戦略を行うには、各チームが目標達成のためにプロダクトをどのように利用できるかを考える必要がある。

この結果、各部署が一体となってシームレスなカスタマー・エクスペリエンスを生み出すことが可能になる。

思ったこと

はじめに

私が書く思ったことは、本書の内容とは関係ないことの方が多いかもしれません。普段から考えていたけど忘れられたことが、本を読んだきっかけでたまたま再燃焼したり、かなり抽象的に見ないと関連しているかどうかわからないようなトピックを無理やり持ってきたりします。そう言う意味では本当の意味で「本を読んで思ったこと」だと思います。

プロダクト主導型GTM戦略にした方がいいんかなぁ

切り替えるべきかどうかは、サブスクリプションビジネスを取り巻く3つの変化が本当に弊社の事業領域でも起きているのかを検証してからになりそうです。なので、顧客獲得コストが上昇しているかどうかは把握したいと思いました。具体的にはこちらの数値かなぁ。

• MQL獲得コスト

• MQS -> SQLのリードタイムの推移

• SQL -> クローズまでのリードタイムの推移

• 契約 -> チャーンまでの期間の推移

これらの値の推移を見たときに変化がなかったとしても、絶対的に評価することもできそう。1顧客のライフサイクル（MQL->SQL->クローズ->チャーン）の平均から、1顧客あたりの平均顧客獲得コストと平均売り上げがわかるので、これらが目指しているグロース幅（YoY +xx%）に見合うのかどうかもわかりそう。もし顧客獲得コストが高いのであれば、プロダクト主導に切り替える必要がありそう。

また、セールス主導型のビジネスのメリットとして高単価顧客がいることと書かれていたが、弊社ビジネスだとどの規模の顧客でも月額料金は同じになるので、セールス主導型の大きなメリットが一つない状態なのも考慮に入れたい。

プロダクトの価値ってなんだっけ？

私はここの解像度が低い。弊社が扱っているのは汎用型のプラットフォームなのでサクセスの定義も顧客によって様々だ。そのため深掘りすることができていなかった。ただ抽象的なサクセスの定義としては「発信がビジネスにコンバージョンすること」だと思う。

本書の中では、機能的対価、感情的対価、社会的対価というふうに分けられていたのでそれで考えてみる。

機能的対価は、ディストリビューションの機能、カスタマイズ機能、サクセス支援、等々
感情的対価は、読まれる嬉しさ、創作に集中できる嬉しさ
社会的対価は、誰でもクリエイターになれること

弊社のプロダクトはサクセスまでに少なくとも3ヶ月はかかるので、ここを1ヶ月とか1週間にできるようにしたい。最終目標のサクセスには3ヶ月以上かかるとしても、そのサクセスの手前にあるチェックポイントでそれぞれ感じてもらいたい3つの対価の解像度を上げていくことはできそう。要するに、顧客セグメントごとに解像度の高いカスタマージャーニーマップを定義すれば、やるべきことが見えてくるかもしれない。

プロダクトの価値というのは、顧客が感じるものであり、その情報を一番持っているのはCSチームだと思うので、とりあえずCSチームのスラックを漁ろうと思いました。

プロダクトのケイパビリティについて考えると整理されるぅ

開発チームがやるべきことはプロダクトのケイパビリティを向上させるために何をすべきかである。

そもそもケイパビリティとはバリューチェーン全体を通しての組織の遂行能力のことを言います。

簡単に言えば、「約束したこと守れる範囲」だと思います。さらに言い換えると「対応できる不確実性の大きさ」とか、「約束した結果を届けることができる問題空間の広さ」とか、「対応できるユースケースの数」とか、「獲得できる信頼の総量」でも良いと思います。

こちらの記事ではプロダクトケイパビリティのことを下記のように定義していました。

弊社の場合、ユースケースのカバレッジを考える上では、プロダクトの利用用途と従業員規模でグルーピングすることになるかなと勝手に思っています。

従業員規模によっては、プロダクトの継続利用が難しかったりするケースが多く見られるので、弊社のプロダクトのカバレッジは従業員規模によっては行き届いていない可能性があるかなと思いました。

ユースケースとは、顧客セグメントとも言い換えることができると思います。サイコグラフィックセグメンテーションで考えてみる場合、プロダクトの価値を感じるまでの許容時間で分けることに意味がありそうです。

そうなると、プロダクトの価値を感じるまでの許容時間が短い層には弊社のプロダクトは行き届いていない可能性があると思いました。

また、プロダクト主導型GTM戦略を取る場合は、開発チームが考え続けるべき問いとして、「プロダクトの価値を感じるまでの時間を短くするには何ができるだろうか？」があったので、プロダクトのケイパビリティを伸ばす上で優先度が高い課題がここになるかもしれないと思いました。

システム思考的に事業解像度を高めることについて考えてみる

解像度を高めるというのは、不確実性を減らす行為とも考えることができます。事業が取り組んでいる問題空間に存在する不確実性（複雑さ）は、問題空間について学習していくことで整理、削減されます。つまり、事業解像度を高めるためには、正しく学習する必要があると思います。

The Modelでいうと、役割の定義はされていると思いますが、学習の詳細な定義がされていないように思いました。

以下のように各サブシステム（カスタマーサクセスT、マーケT、セールスT）へのインプットに対して適切な情報処理を行い、アウトプットとして「それぞれのサブシステムが目標としている数値にコミットする」というのが役割の定義です。

こちらのPodcastでもthe modelの本質について議論されていますが、サブシステム間でどう情報連携をして、それを元にどう学習して、どう学習の成果をまとめるのかも話されています。かなり参考になりました。

事業を進めていく上で、各チームが得たインプットをどう自チームの学習サイクルに利用するのか？また自チームが生み出した情報をどう他チームに連携して、それをどのように使って欲しいのか？みたいな学習の定義をシステム思考を用いたモデルとして作れると良いと思います。

システム思考とは複雑なものを複雑なまま整理するツールになります。そして事業が取り組む問題空間は複雑なので、事業解像度を高める上でもシステム思考を用いることが重要です。そして問題空間のシステム構造を明らかにしていくように、各チームの学習の定義を作れるようになると、日々の事業活動の中で、どんどん学びを増やしていき、事業ドメインの複雑性をコントロールできるようになります。

そして複雑性をコントロールできるようになると、「驚き」が減るので、ケイパビリティも向上します。逆の言い方をすると、複雑性や不確実性が削減されているため、事業ドメインを広げていかないのであれば、必要な情報処理量が減っていくはずです。その余ったリソースで、まだ行き届いていないユースケースにチャレンジしていくみたいな流れが組織ケイパビリティのマネジメントな気がします。

システム図のイメージをつける場合はこちらの記事がおすすめです。

学習の定義はやはり、サブシステム（カスタマーサクセスTやマーケT、セールスT）のもう一つ抽象度の高いシステム（事業部門）が行う必要があるかなと思います。学習の定義の後は、ミーティングとか、どんな情報を共有するとかの仕組みを整えて調整していく形で周りそうな気がします。運用は欠かせませんが。

MLOpsみたいな感覚でこの学習する組織のマネジメントもできそうですね。学習の定義も合わせて行うことで事業グロースの土台となる組織ケイパビリティのマネジメントにもつながりそう。

非線形でグロースしたいならKPIは速度に加えて加速度も見るべきかも？

MQLやSQLや解約率、案件のクローズ率、ARRなどの推移はグロースの速度を測る指標のイメージ。

ドラッカーが言ってたように「計測できないものは管理できない」とすると、グロースを管理したいならば、上記の数値だけでよさそうだけど、非線形にグロースしていきたいというのを管理したいならば、速度を表す数値の管理だけではなく、加速度になるような数値を計測し、それを伸ばすことに投資をすべきな気がする。

自分が思う加速度は最初に挙げていたような数値かなと思っているところ。

• MQL獲得コスト

• MQS -> SQLのリードタイムの推移

• SQL -> クローズまでのリードタイムの推移

• 契約 -> チャーンまでの期間の推移

組織ケイパビリティの向上に注力すること = 加速度へ投資するためのリソースを確保すること

グロースという目的を達成するために必要なことは、組織のケイパビリティの向上である。ただ、加速度に投資するというのは、速度に投資するよりもリターンが遅い。より長期視点での投資になるので後回しになることも多い。

組織ケイパビリティの向上には個のイネーブルメントが重要

正しくイネーブルメントされた個がどのように機能するかは冒頭に話した通り、チームのミッションに向けて自発的に学習を繰り返し、時には周りを巻き込んでディスカッションしたり、自分の周りの連携を強化しようとすることです。

個をイネーブルメントするには、最初に定義された目指す状態の3つの条件を満たす必要があると思います。（以下に再掲）

1. 事業が取り組んでいる問題空間を頂点から適切な粒度と階層のサブシステムに分解した状態（The modelの解像度を高めた状態）

2. サブシステムごとの責務と、あるサブシステムが隣のサブシステムとどう連動しているか（システム図でアウトプットしたい。）

3. アプリケーションエンジニアとして私が考え続けるべき問いは何か？（自分の業務にまで落とし込めて考えられている状態）

これらがあれば頭がシンプルに使えるようになります。効率的に情報処理が行われるようになるので、脳内リソースが余ります。その余ったリソースが正しい方向の学習に使われるようになるので、個のケイパビリティの向上に伴いチームとしてのケイパビリティが向上します。

組織ケイパビリティとはイネーブルメントできる従業員セグメンテーションのカバレッジになるのかなぁ

イネーブルメントについては一個上の「思ったこと」に書いたので割愛。感覚としては、最小単位のサブシステムとして正しく自己組織化するみたいなイメージ。

• 職種セグメンテーション

• 年齢セグメンテーション

• 習熟度セグメンテーション

• 性格セグメンテーション

• ユースケース的にはチームの人数とかもありそうだなぁ

• etc..

組織ケイパビリティとはイネーブルメントできる従業員セグメンテーションのカバレッジと仮置きしてみると、色々見えてくるかもしれない。

組織ケイパビリティの向上を管理する

事業拡大に伴い組織ケイパビリティの向上のKPIを採用人数とするならば、それは組織ケイパビリティの向上速度を管理しているイメージだ。だけど、向上加速度も管理する場合は、KPIには（わかんないけど）個のイネーブルメント率とかも加えたほうがいいかもしれない。

ケイパビリティ自体が持つ性質として、変化にも柔軟に対応できるという性質がある。この性質上、ケイパビリティは戦略というものにおいては絶対に考えなければならない側面であり、事業成長戦略を立てる際に、速度を落とさないように、かつ線形ではなく非線形でグロースさせたい場合はケイパビリティの理解とマネジメントが重要である。

ケイパビリティ=加速度とも考えられそうではあるが、イメージとしてケイパビリティとは速度や加速度を直接測るものではなく、戦況の変化による影響を限りなく最小化するためのものであると考える。要するに、速度や加速度の管理をより確実にさせてくれるものである。

じゃぁケイパビリティの速度/加速度を管理するためのケイパビリティは何か？という疑問が生まれてきそうだけど、カントみたいな哲学の話になりそうで時間がかかりそうなので一旦は置いておく。

事業のグロースには3つのケイパビリティが必要らしい

LayerXではプロダクト、ディストリビューション、組織の3つのケイパビリティだと定義されています。

プロダクトケイパビリティと組織ケイパビリティについては述べたので最後のディストリビューションのケイパビリティについて考える。

ディストリビューションケイパビリティとは、自分の感覚だと「その気になればプロダクトを利用してもらえる社会的、心理的、地理的セグメンテーションのカバレッジ」だと考えた。

• プロダクトが手軽に使い始めることができるようにするとかは、心理的セグメンテーションのディストリビューションケイパビリティの向上に役立つ

• ITだと地理的セグメンテーションにはあまり制限はない

• 社会的セグメンテーションについては、弊社サービスは利用言語が日本語だけなので、日本語利用者に縛られてしまう。英語対応するというのも一つの社会的セグメントの拡張の一種なのかな。

ただ、この3つは並列ではなく、組織ケイパビリティが他二つのケイパビリティの土台にある関係。

事業の適切な成長目標は組織ケイパビリティの成長に合わせたものに落ち着く気がする

組織ケイパビリティの拡大に伴った事業成長でない場合はいろんな部分に歪みが発生する気がする。残業時間が増えたり、短期視点が強くなりユーザエクスペリエンスが下がったり、カルチャーや戦略の浸透が難しくなり人員拡大ペースに対してリソース拡大ペースが鈍化したり。

次に探索するフィールドはどこになるんだろう

事業がどのユースケースに対応していく（どの方向に問題空間を広げていく）のかは楽しみ。レバレッジが一番大きい領域から、事業が取り組んでいく問題空間を拡張していくかつ、歪まないように会社のMVVと照らし合わせて長期視点を欠かさないようにするみたいな感じになるんだろうなぁ。

（意思決定については直観でディレクション、ディレクションをファクトベースで定量的に検証、MVVで定性的に検証するイメージ）

全然関係ないけどずっと考えてた個人のパフォーマンスの話とケイパビリティマネジメントについて

個人のパフォーマンスの評価については以下の式で表すことができる気がする。

タスクに必要な情報処理量✖️必要な情報処理量の削減量

• タスクに必要な情報処理量（下にいくほど大きい）

  • すでに知っている（既知）

  • 自分だけが知らない（技術的問題 小）

  • チーム内で誰も知らない（技術的問題 中）

  • 会社内で誰も知らない（技術的問題 大）

  • 事例がない（適応課題）

• 必要な情報処理量の削減量（下にいくほど大きい）

  • 次の機会でも同じ量の情報処理量が求められる

  • 学習定着による削減（必要な情報が自分の中のみある状態）

  • ドキュメンテーション（整理）による削減（必要な情報がまとまっていて誰でも参照できる）

  • 仕組み化による削減（必要な情報が部分的になくなる）

  • 自動化による削減（必要な情報が完全にゼロになる）

各項目で下になればなるほど影響範囲も増えていくため、不確実性も高い難しいタスクになる。

ケイパビリティマネジメントの観点で言えば、ある人に任せるタスクが、すでにその人はよく知っている問題空間の場合に、学習による情報処理必要量の削減が見込めないのでチームとしてのケイパビリティの向上（加速度への投資）にはならない。一方で属人化を防ぐためにその人がドキュメンテーションをした場合は、情報処理必要量の削減に貢献しているので、チームのケイパビリティとしては向上する。

上記の記事では、「誰がやっても同じような結果になるタスクをシニアに任せるのは、時給の無駄が発生していることになる」と書かれていたが、加速度に投資できない状況に加えて、コストを無駄に浪費していることにつながるのは結構シリアスに捉えなければならない状況な気がする。

自分がマネジメントする時にはこーゆーことを意識して取り組みたいと思った。すでに退職してしまったが自分の元チームリーダーはこのタスクの振り方がめちゃうまかった気がする。

あとは業務内容に対して、比較的若い（経験が浅い）エンジニアが多かったのも相性がよく、成功要因の一つな気もする。

目指すべき状態になるためのTODO整理

1. The Modelの解像度を高める

まだトップ（事業部長）の考えが全然把握できていない気がするから、微妙に周辺ロジックが繋がっていない気がする。多分現在事業をどういう方向で拡張していくかを考えていると思うので、現在のカバレッジの外の世界を知らないといけない気がする。

2. サブシステムの責務や連携をシステム図で表す(WIP)

上記のPodcastを聴いて「学習の定義」をシステム図に表してみたい。

システム図のイメージはこちらの書籍で書かれていた感じ。リソースとインプット、アウトプット、フィードバックループみたいな感じ。興味ある方はぜひ。複雑な世の中を数次元高く整理できます。

3. プロダクト開発チームが考えるべき問いは何か？

• エンジニア組織のケイパビリティ向上のために自分ができることはなんだろうか？

こちらの解像度を高めるために、LeanとDevOpsの科学を再読したい。ケイパビリティの話がめちゃあるので参照したい。

• プロダクトがより早く顧客に価値を感じてもらえるようにするにはどうしたら良いだろうか？

世の中のプロダクト事例から学ぶ必要があるのと、サクセスチームのスラックを覗きたい。ただ、TTVの削減にあたって小手先でやれることは結構やり切った気がするので、大きなプロジェクトとしてやっていかないとな気がする。

• 事業部のケイパビリティの向上にどうやって貢献できるだろう

戦略的意思決定に必要なデータに簡単にアクセスできるようにしたら嬉しいかもねぇ。加速度的な部分。

最後に

事業とかやったことないから全部考察の域を出ないんだけど、いつかやる時にこれらの検証ができるなぁ。

雑多に考えていたことが全部出せた感があってとても嬉しい。頭が本当に軽くなった。

あとは自分が考えるべき問いが明確になった気がするので、これらをもっと深めて実際のPjtとか事業戦略に落とし込んで来期の目標を立てられる気がする。