スタートアップの成長速度を決める"改善サイクル”の教科書
第二創業期のスタートアップだったROXXにジョインしてから、早5年が経った。解が見えない状況で解を見つけるプロセスは、時には残酷で、時には非常に充実した満足感を得られる。しかし、実行方法を間違えれば、泥沼にハマり抜け出せなくなるばかりか、光すらも見失いアクションを取れなくなってしまう人も多く存在する。
とはいえ、解がない中で解を見出すための改善サイクルは、組織に精度高く根づけば根付くほど、事業成長速度が上がるエンジンのような存在である。(あくまで最低限必要なエンジンであり、非連続もしくは持続可能性が高い成長のためには全く違う要素が多分に必要である)
ただ残念なことに、当該プロセスの修正や精度向上のためにマネジメントリソースの多くが割かれていることも少なくない。この改善精度の向上に使われるリソースは本来は必要のないものである。フィードバックする側もフィードバックされる側も、修正リソースが発生するだけでなく、「不足を認め修正する」というプロセスは双方に一定の精神的コストもかかるものである。
私自身も大手からスタートアップに転職したての頃は、創業者からフィードバックされる内容について、その必要性と重要性が全く理解できず、苦しんでいた。(フィードバックする側はその何倍もの苦しさを抱えていたことは自分がフィードバック側になり初めて知った) 自分自身や自分自身の行動を具体的に変化させることで、課題解決するという経験がなかった自分は、自分を変えずに出せる成果が限界値だと勘違いしていた。しかし、ROXXの創業経営陣は無知でなんのバリューも出せなかった私に根気強く向き合い続けてくれたおかげで、自分自身を変化させることで事業数値を改善することの重要性と楽しみを知ることができた。
だからこそ、当該改善プロセスを文章にまとめることにより、経営者やマネジメント層はこのnoteを送るだけでメンバーに体系的に改善サイクルを回すための基礎を理解してもらえ、フィードバックする側/される側の負担を軽減できると嬉しい。また、改善精度をあげたい方々は、当該noteに基づき実践することで改善速度を上げることができ、そして何より自らを変化させることで事業数値を改善する楽しみを知ってもらえるようなnoteにしたい。
そんな願いを込めて、下記のような方々に向けて稚拙ながら筆をとる。
・自身の組織の仮説検証や改善精度に課題感を持っている経営者やマネジメント層の方々
・自らの仮説検証や改善速度をさらに上げたい方々
・上司から指摘されていることの全体像が見えず、ストレスが溜まっている方々
・仕事の楽しみを見出したい方々
なお、特にSaaSなどのtoBビジネスにおいては、ビジネスサイドにおける仮説検証精度が非常に重要だと考えており、ビジネスサイドの読者を想定した文章とし、具体例は全て営業の事例を用いて記載する。
□仮説の粒度が全てを決める
当該改善プロセスにおいて最も重要なことは、仮説の粒度である。全ての物事には因果関係が存在する。つまり動かしたい結果には要因が存在する。スタートアップにおいては新規検証が多く、大手企業に存在するような「〜すれば〜となる」という先代が導き出した勝ち筋がないケースがほとんどである。そのような状況下の中では、仮説検証プロセスを経ることで得たい結果に対して、その結果と結びつく要素(要因)をどれだけ早く見つけ出すかのゲームである。またその要素同士の関連性を見出し、最もクリティカルなアクションに落とし込み、そのアクションをパターン化するゲームである。
このゲームにおいて、最もやってはいけないのは「抽象度が高い状態でアクションし続ける」ことである。抽象度が高いアクションからは、次のアクションにつながる学びが得られない、失敗だったかすらもわからないアクションは限られたリソースで戦うスタートアップにおいては大きな損失であり、失敗すらできないことは失敗すること以上に大きな損失であることを肝に銘じなければいけない。
仮説の粒度についても、ビジネスサイドの中でもどの事業にも存在するであろう営業の事例を用いて説明する。セールスが成約率をあげるというミッションを担っていた場合に、「成約率が低いのはクロージング精度が低いからではないか」という仮説を立て、その対策として「クロージングロープレを実施する」というような場合は仮説の粒度が荒く改善が進まない典型例である。
この場合は、もう数歩踏み込んで「クロージング精度が低い」要因を分解して仮説を立てなければいけない。「クロージング精度が低いのは〜という顧客属性において〜という訴求の根拠が弱いからではないか」というようにできるだけ細かく具体的にできていないことが特定できる粒度に分解する。常に失注理由を分析し、導入できたはずの顧客をどの顧客と定義し、その顧客の払拭できなかった懸念がなんなのか、その顧客の懸念を払拭するために自身の商談に足りていないのは「懸念払拭のためのファクトデータか」それとも「そのファクトがより伝わりやすくなるストーリーなどの伝え方なのか」ここまで粒度を上げて仮説を立てることによって、初めてアクションが具体的になり、週次単位での成約率改善に必要なアクションが進んでいく。
もし仮に仮説が間違っていた場合も、粒度が細かければ、早期に得られた結果から軌道修正することができる。しかし、上記のようなロープレの実施は毎日繰り返しても、一体何がよくなったのか、はたまた悪くなったのかが不明確で、下手すると改善のためのアクションを起こしているようで全く改善が進まずに非生産的な時間をひたすら繰り返すことになる。もしくはたまたま改善がされた場合でも、育成の時にメンバーが同様の課題にぶつかった際に改善アクションの解像度が低いが故に、同じアクションで改善ができないケースにぶち当たる。リソースが限られているからこそ、最速で改善サイクルを回し続けるに最も重要な要素は仮説の粒度である。
□6つの仮説検証ステップ
抽象的な話から始まったが、ここからは具体的な仮説検証プロセスについて記載する。主に仮説検証プロセスは6つに分類される。このプロセスのうち、組織フェーズやマネジメント体制によって、一人が全てのプロセスを横断することもあれば、組織内で分業されているケースもある。
またこのプロセスは具体と抽象のスコープを1段階ずらすことによって、また別の階層が存在するため、階層ごとに実施者が異なるケースがある。だからこそ、組織フェーズによって階層が存在する場合には、下からは一つ上の階層における要素が見えないケースが多いことをマネジメント側は理解しなければいけない。マネジメント層は決して「視野が狭いな」という言葉で片付けてはいけない。あなたが見えている景色や情報は正しい前提で、差分がメンバーに理解できるまで分解して伝達しなければいけない。
1. マイルストーン設定
2. イシューを立てる
3. 現状分析
4. 要因仮説立て
5. アクション決め
6. todo化
それぞれ具体的なプロセスと、重要なポイントについて記載する。
○マイルストーン(ゴール)設定
まず全ての出発点となるのはマイルストーン(ゴール)設定である。
組織、もしくは個人が担っているミッションに対して、目指すべき定量的な状態を定義する。基本的には経営戦略に紐づいて策定された事業計画の因数分解となることが多い。しかし事業フェーズや組織体制、読者のレイヤーによっては自らで最終ゴールの尺度と時間軸を設定する場合があるので、もう少し掘り上げる。
ゴール設定時にまず重要となるポイントは、どの速度で山を登るのかという時間軸と尺度の設定である。この時間軸と尺度の設計には非常にセンスが問われる。基本的にはこの出発地点からブレイクダウンして改善が進むので、設定した以上のところには到達できないので、低いところに目標を設定すると現状維持もしくはそれ以下の結果となる。だからこそスタートアップは普通では到達できないような高い目標を設定することこそ正義となりがちである。
しかし、この尺度が異常値だと組織面であらゆる問題が生じ、健全に仮説検証が行われなくなることも多々ある。つまり、中長期で見た時に到達速度が逆に遅くなるケースが往々にして存在する。この目標設定次第で、十分不十分という判断が下される以上、この設定が何より重要である。
具体例を挙げると、新規MRR500万円をギリギリ作れるほどの能力を持った営業マーケ組織が新規MRR600万円を追い続けることは、組織崩壊のリスクだけでなく、中長期的に価値となる要素への投資が一切行われなくなる。MQLの獲得だけでなく、MALの獲得や、刈り取りではない過去訪問顧客のナーチャリングや、オンボーディングプロセスの体系化、などである。
そのような緊急度は低い(過度に高い目標下においては短期目標の達成に近づくことが緊急度が高い課題となる)が重要度が高い、アセットとなるアクションが全く行われなくなる。そうなると、本質的な事業成長は全く見込めない。それだけなく、短期的な思考が重視されるカルチャーがチームに根付くことは後々修正が不可能なほど大きな負債となる。
2つ目の重要なポイントは、(当たり前かもしれないですが)状態を定量化すること、そして時間軸を明確に設定することである。事業フェーズやチームのミッションによっては非常に定量化するのが困難な場合も存在する。しかし、一部不確実性が高く目標を決め切るのが難しい場合や細部にて整合性がとれないような事象が生じる場合でも、曖昧なゴール設定ではなく、明確に定量化した目標設定をすべきである。目指すべき状態が共通認識をとれ、辿り着いたのか、辿り着かなかったのか、その要因は何かということが、ゴールを定義した時点で後から振り返られるようにしておく必要がある。
事業全体であれば、9月までにMRR1億円を目指す、営業組織であれば、今期中に新規MRR500万円を安定創出(3ヶ月連続達成）できるようになるなどの定量的な状態である。営業個人であれば、3ヶ月以内に成約率を10%から15%に引き上げる、というように、明確に期日と現状とのギャップが明確になるものにする。基本的には抽象度が高い目標から決まり、その目標を達成するためにブレイクダウンされた目標が設計されていく。特に個人のスキルベースでの目標設定の際に、定量化しない目標を設定しまうことがあるが、これは具体的な改善アクションにつながらないことが多い。
○イシューを立てる
ゴールが設定された後は、そのゴールを達成するために、どの課題に向き合うべきかを明確にする必要がある。スタートアップなどの最適な勝ち筋が見えていない環境や新規検証においては、向き合うべき課題の特定、つまりイシュー設定が非常に重要である。またMRRなどのシンプルな因数分解で成り立つ指標であれば特定は容易であるが、変数が多い指標であればあるほど非常に課題特定難易度が高くなる。
そんな時にありがちな過ちとしては、いきなり現状分析から入ることである。とにかく分析だ、と分析することが目的となる、この分析に膨大な時間をかけてしまう。分析する前にまずはイシューを立てる必要がある。(この辺は、名著である『イシューから始めよ』に詳しく書かれているので、割愛します) このイシューは分析すべき箇所や切り口を明確化する問いとなる。
この問いの精度が高ければ高いほど課題の特定も早くなる、そして課題特定後の結果への影響度合いという観点でも非常にイシュー精度は重要である。このイシュー精度こそが、あらゆる切り口で日本でも重要なテーマとなっている「生産性」を高める上では非常に重要な要素であると思う。
ちなみにイシューから始めよには、良いイシューの条件は何か、という問いに対して、は下記の3点をあげているので引用してイシューについての解説は終わりとする。
①本質的な選択肢（答えが出ると今後の検討方向性に大きな影響を与える）
②深い仮説がある（ここまでスタンスを取るのか、というところまで一気に踏み込んでいて、常識を否定・覆すような洞察がある）
③答えを出せる（既存の手法、あるいは現在着手しうるアプローチで答えを出せる）
○現状分析
イシューを立てた後に初めて分析に入る。分析はあくまでも一つの手段であり、分析はいくらしても事業は成長しない、事業価値も上がらない。分析はその分析結果をもとに、課題を正しく特定し、その課題を解決することや施策が実行される(もしくは現状の打ち手の軌道修正が行われる)ことで初めて価値をうむ。なので分析ありきで動き出すのは非常に危険である。
まずはイシューを立てる。データは見るべき角度やセグメントの切り方によって如何様にも見せることができる。だからこそ、どの切り口で物事を検証すべきなのかというデータを出す軸となるイシューがあって始めてアクションに繋がるような価値のある分析をすることができる。
例えば、「〜業界の成約率を上げる」、というイシューをもとに、業界セグメント別の成約率を出してみる。そして業界セグメント別の失注要因を比較していく。そこで初めて業界別の自分自身の商談における課題が見えてくる。そこから次に要因仮説に落とし込んでいく。
分析手法や統計的にスキルは深ぼることで精度を上げることはできるが、そこまで統計や分析スキルがなくても、toBビジネスであれば算数レベルの計算でも十分な示唆が得られる。
○仮説立て
定量的に、そしてファクトをもとに進んでいけるフェーズは現状分析までで、ここからはある意味センスが問われる部分に入る。新たに決めた切り口で施策を打つ前の段階では、”結果”が存在しないので、これが要因となっているであろうと仮説を構築する。分析で目をつけた課題に対して、「なぜその課題が起きているのか？」という部分に確からしい仮説を立てるプロセスである。ここでありがちなのは、パッと頭に思いついた仮説に囚われ、すぐに施策に落とし込むことである。想像以上にこの仮説には個人のバイアスが絡み付いていることを無視してはいけない。
まずは想定される要因を全て洗い出す、とにかくまずは網羅的に洗い出してみる。その上で、客観性が担保される状態を作った上で(ここで第三者の助言を得ることは非常に価値がある)、優先順位をつける。
ここの要因仮説精度が低ければ、実行しても結果を生み出している真因にたどり着くのが遅くなるため、得たい結果が得られるのも遅くなる。逆に立てた仮説が直撃しなくても、少しでも得たい結果に変動があれば、その結果を元に仮説を微修正することで解に近づいていくことができる。
こちらも前章からの具体的事例を踏襲する。「〜業界の成約率が低い」と言う現状分析に対して、その要因を仮説立てしていく。なぜそうなっているのか、を繰り返す。トヨタの5回なぜを繰り返すというのが有名だが、とにかく思いつく限りの要因を列挙する。この時に失注要因などの定性ではあるが一定仮説の拠り所となる情報があれば参照すると仮説構築精度は高くなる。
しかし、あくまでも定性情報であることを忘れてはいけない。「費用対効果」「ニーズ不一致」などの項目で失注要因を取得していた時に、どの要因に当てはまるかは営業担当者の主観によって結果が変わる可能性もある。また失注要因の選択肢自体に課題がある可能性もある。すぐに失注要因を一覧化して要因仮説を立てたくなるが、あくまでも参照情報として扱うことが重要である。
その上で、「〜業界の成約率が低いのは〜業界の知識が不足しているが故にニーズを顕在化させるほどのヒアリングができていない」などの要因仮説を立てる。もしくは他の担当者のデータも参照し、実は全てのセールスが〜業界の成約率が低いなどの場合には、そもそもプロダクト的に〜業界は狙うべきターゲットでない、と言う結論になる場合もある。その場合は、イシュー構築フェーズにもどる。これを繰り返す。
○施策(アクション)決め
確からしい要因仮説を構築できたら、施策(アクション)に落とし込む。施策を考えるときには、「これを実行すれば本当に次からは同様の要因での当該結果が起きなくなるか」という点を重点的にチェックする。これが実行できていれば、本当に〜という要因の失注は無くなるか、というように、何度も得たい結果に対して、起きてほしくないマイナスの結果を想定して思考を繰り返す。
もしくは、すでにその課題をクリアしている成功事例をもとに、成功事例を転用して、アクションに落としていく。しかし基本的には解がないシーンを想定したnoteなので、その要因が2度と起きない状態となっているのかを想像し思考を繰り返すことが重要である。実際に過去の商談の事例をイメージし、「アクションを実行したときに過去に起きた結果は変わるのか？」この状態を完全にイメージできるまで施策を練る。
具体的に上記の事例に基づくと「〜業界の成約率が低いのは〜業界の知識が不足しているが故にニーズを顕在化させるほどのヒアリングができていない」という要因仮説に対して、2.3の施策(アクション)を決定する。
(1) 〜業界の中でも〜という知識が不足しているので、〜についての情報をインプットしドキュメントにまとめてアウトプットする
(2) 上記アウトプット過程で得られた情報をもとに、〜業界専用のヒアリングシートを作成する
(3)作成したヒアリングシートをもとに、〜業界の顧客に最も成約率が高いセールス担当にロープレをお願いして不足をできるだけ多く指摘してもらい修正のためのアクションを3つ以上策定し実行する
というように、具体的なアクションを設計する。2度とその要因が起きない状態にまでたどり着くであろう施策を作る。「〜をインプットする」などのアウトプットの変化まで起こさないアクションで止まらないことが何より重要である。
○todo化
施策(アクション)が決定したら最後にtodo化する。todo化におけるポイントは、改善速度を最大するために、思考と実行を明確に分けて考えるということである。だからこそ実行フェーズでは一切の迷いがなく、無思考で走れるようにする。無思考というと誤解がありそうだが、実行する中で次の改善に向けたヒントが溢れ出てくるので、追加で思考しながら走るための思考余白を残しておくということである。
つまり、決めたことの実行には一切の思考をしなくても実行ができる状態にしておく必要がある。当該コンテキストや知識を全く知らない新メンバーにtodoを渡したとしても問題なく実行できるほど、これ以上分解の余地がない状態にする。2つ目のポイントは、期日を明確に設定することである。todo化のポイントは具体的なアクションに落とすこと、そして明確に期日を切ること、この2つが重要である。
最後の具体的な事例としては、「上記アウトプットをもとに、〜業界専用のヒアリングシートを作成する」という施策に対しては、
(1)〜業界に詳しい担当者に抑えるべきポイントをヒアリングする 2/17 15:00
(2)自分自身の中でヒアリングすべきポイントをスプレッドシートに30個ブレストする 2/17 17:00
(3)2つの情報からヒアリングすべき情報の優先順位を決め、いらない情報は捨てる 2/17 18:00
(4)上記内容をスプレッドシートに落とし込み、記入欄を作成する」というように、それぞれのアクションとともに期日を設定する。 2/17 19:00
□チェックポイント
ここまで思考しアウトプットができたら、最後に下記項目をもとに見直しを行い、不足がないか確認する。言語化できていないことは思考できていないと同義と言っても過言ではないので、社内に共有しないとしても(共有した方が色んな角度でフィードバックもらえる可能性が出るのでフィードバックもらったほうが得たい結果にたどりづく速度は速くなる)、自分自身でしっかりと文章に落とし込み、振り返りをすることは非常に重要である。
- 当該期間(振り返りをしている期間、週次なら週、月次なら月)解決したい課題は何か(3つ以内)
- その課題優先順位が上位の理由は何か？
- その課題が解決された状態は、定量的にどのような状態になる(ex 商談実施率が5%改善され、商談数が〜件増える)
- その課題が生まれている要因は何か
- その複数の要因仮説のうち、検証すべき内容は何か
- それを検証するために、新しく何を実行するのか
- todoは分解不可能な粒度になっており、期日は明確か
□最後に
文章で羅列したので、読みづらい箇所もあったかと思いますが、最後までお読みいただき、ありがとうございました。私自身も発展途上の未熟な中ではありますが、現状重要だと思っているポイントを言語化してみました。ただこれはあくまでも最低限の基本の改善サイクルに必要な要素であり、当たり前に実行できて初めて、より資産性のあるアクションの話や中長期のアセットとなる施策の話ができると思っており、息するようにこの水準で実行ができるようになると、変数が複雑に絡み合う課題に対しても、よりシンプルに、そして迷うことなく、コトに向き合うことができるようになっていくと考えています。
この基本改善プロセスは仕事だけでなく、何を実行するにも重要な基礎だと考えているので、私自身さらに改善プロセスにおける解像度を上げていきたいと思っています。Twitterなどでコメント付きでシェアいただけると大変嬉しいです(シンプルに感想だけでも書いてよかったなと喜びます)
久しぶりにnoteを書いたら非常に長くなってしまい、情けない限りですが、少しでも参考になったらぜひTwitterやFacebookでシェアいただけると嬉しいです。反響次第では週1くらいの更新していきます。
少しでも多くの方に、自らを変化させることで結果が大きく変わるという体験が届くとこれ以上に嬉しいことはないです。
Twitterもぜひフォローお待ちしてます！
いいなと思ったら応援しよう！
