POのビジネスセンスに依存するのが、スクラム開発の課題　仮説検証による事業開発フレームワーク「THRUSTER」とは

「事業の目的」とは何かを考える

広岡一実氏： Growth Hack Studioの広岡と申します。今日は僕らが会社でやっている活動をちょっと紹介させてもらいます。ただ、内容が少し抽象化されています。とくに具体例を持ってこなかったので、お話を聞いてかなり悶々とするかもしれないんですけど、そういうものだと思って聞いていただければと思います。

今日持ち帰っていただきたい内容としては、スライドに書いてある通りで「事業と組織をマネジメントして、どうやったら成果を最短で得られるのか」というところに尽きます。

まず簡単に僕の紹介です。もともと化粧品を輸入している商社にいまして、国内でいわゆるブランドマーケティングをやっていたり、GPSのハードウェアのスタートアップっぽいことをやっていたりしました。

その後はどっちかというとファイナンス畑です。前職では、このあいだイスラエルのTapticaという会社に買収されたアドイノベーションという会社でCFOをやっていました。

今の会社は、アドイノベーションの時のCTOと一緒に作ったんですけど、こういう二人が会社を作ると、とくにやりたいことってないんですよ。要はCEOにはやりたいことがあるけど、CFOとCTOってあんまりやりたいことがないんです。なので、当然のように会社として行き着いた先が、「どうやったら誰でも事業開発をできるようになるのか」といった標準化に取り組むということです。それを今やっています。

ちょっと質問なんですけども、スクラムを導入されている方っていらっしゃいます？　

（会場挙手）

多いですね。プロダクトオーナーの方はいますか？

（会場挙手）

はい、ありがとうございます。では、そもそもの事業の目的みたいなところから簡単に入っていきます。事業の目的って、結局は自分たちのビジョンの達成です。要は「起こしたい社会の変化」と「顧客の課題解決」ということです。顧客の課題解決も、言葉を変えると「顧客が期待する顧客の変化を生み出す」ということです。

事業上の制約から導かれるスクラムの課題

この2つをどうやって繋ぎあわせていくか。それは、一発で見つかるわけがないんです。（スライドを指しながら）結局この1、2、3をマネジメントして、クルクルクルクル回し続けていくっていう活動そのものが重要になります。ただこれも、当たり前なんですけど、やろうとすると非常に難しいです。

なぜかってことの1つの理由に、事業がそもそも持っている制約があります。事業って顧客から価値の要求を受けるんですけど、投資家からは利益の要求を受けるんです。ただ、今みたいに市場変化がすごく早まっていて、要求の不一致が起こりやすい中では、活動のスコープとリソースの優先順位をつけることが極めて難しくなってきています。

（スライドを指しながら）これまでは、スクラムでこのあたりにトライしてきたんですけど、（定番の）オチが1つあります。結局、投資家からは「ROIをバックキャスティングした計画を、予算でマネジメントしろ」って要求がくるわけですね。よくあるのが、計画を立ててやり始めた後に「計画は、これじゃないな」と思っても、「予算が決まっているから1年間は計画が動かせない」みたいなことです。ざらにあると思うんです。

その中でやれ「リーン」だ、「アジャイル」だって言っているのって、実は意思決定の本質からすると、かなり苦しい状態です。これはスクラムの課題だと僕は思っているんですけど、結局事業マネジメントについてはプロダクトオーナーがすべて吸収できていることを前提にしているんですよ。すなわち、実はプロダクトオーナーのビジネスセンスに相当に依存しているということです。

投資家とのコミュニケーションもそうです。ここで言っている投資家っていうのは、例えばプロダクトオーナーの立場で事業から見たら、勤務先の経営者が自分にとっての投資家だったりするということです。

そういう「お金の出し手」、つまりは「株価をあげる」「利益をあげる」ことに責務を背負っている人たちとの対峙だとか、その上での顧客との対峙だとか、そういうことのためにかなりのビジネスセンスが求められてしまうっていうことです。

「顧客の求める変化を生み出すこととはなにか」から考える

あとは、基本的にソフトウェアの開発用に閉じてしまっているというところが大きな問題かなと思います。極端なことを言うと、顧客にとってはソフトウェアであるかどうかなんて、もはや関係ないんです。

例えば最近、Amazonがリアル店舗をやっています。店の仕組みの中にはソフトウェアもたくさん散りばめられているけれど、あれはリアル店舗です。店舗っていうものに対してソフトウェアっていうのは、いわゆるECほど直接的でないこともあって、ソフトウェアであることにこだわる必要はそもそもないですよね。

じゃあ、これから必要なトライとはなんなのか。顧客が期待する「顧客の変化」、いわゆる「ドリルと穴」（注：マーケティング分野における格言「ドリルを買う人が欲しいのは『穴』である」というもの。顧客はドリルという「製品」そのものではなく、穴という「結果」を欲しているということ）の話です。

顧客が期待している「顧客の変化」を出すことからバックキャスティングして計画を立て、仮説検証でマネジメントする。予算ではなく、仮説検証の結果で変えていく。この顧客が期待する「顧客の変化」を生み出すっていうのは、登る山です。山の登り方自体は変化させていかなきゃいけない。

ポイントとしては、今の話の通りです。ROIに落とし込む時に「売上をあげるために何をすればいいのか」というよりは、どっちかっていうと「顧客が期待している顧客の変化、希望する変化を生み出せば、売上や利益がついてくる」っていうことです。もう「顧客の変化と売上に相関性があると信じ込む」ぐらいの感じですね。

顧客の変化の創出がないのに売上をあげろって言うと、結局ブラック企業的に「さあ、がんばれ！」って話になっちゃうので、このあたりが1つポイントになってくる。これを使って、投資家サイドとのコミュニケーションをうまく円滑にしたい。

2つ目のポイントとして、これはサッカークラスタの人はたぶんわかると思うんですけど、「良いアイデアが事業を進捗させる」というよりは、結局「事業が進捗したアイデアが良いアイデア」なんです。仮説検証をきっちり回していきたいということです。

なので、ファクト化させていくことが重要であって、ソフトウェアかどうかってあんまり関係がなかったりします。ここを細かく言うと、さっきのように「ヒアリングだとユーザーの課題は見つからないですよね」とかいろいろありますね。

実際は、ユーザーがたどり着きたいという「顧客の変化」を生み出すために、ユーザー自身が実際に今どんな活動をしているかとかいうことを聞いていきます。すると、ストレートに聞かなくても、「意外となんかわかる」みたいなティップス、仮説検証上のティップスは山ほどあります。

なので、ヒアリングよりも、この2つの視点をうまく意思決定に取り込むってところが極めて重要であろうと思っています。

仮説検証による事業開発マネジメントのフレームワーク「THRUSTER」

「そんな簡単に言うな」という意見もあると思うので、僕らが会社でやっている取り組みについてお話しします。こういったことをフレームワークに落とそうということで、「THRUSTER」という仮説検証による事業開発マネジメントのフレームワークを作っています。

中身はけっこうスクラムに似ているんですよ。ただ、スクラムと決定的に違うのはロールの中に「投資家管掌役」って役割を振っていることです。その意義ですが、事業オーナーが意思決定をする時に投資管掌役と合意しているというか、説明責任が存在しているってところをきちんと明確にしているということです。

それと、もともと責務が違う「顧客の課題解決に責務をもつ事業開発チーム」と「株価をあげることや利益をあげることに責務をもつ投資家管掌役」とでは、その役割や目線感が違います。「今、自分たちが何をしなきゃいけないのか」を明確にするために、事業ステージをけっこう細かく切っています。

THRUSTERの中身なのですが、成果を最短で得るためには（スライドを指しながら）このサイクルをクルクル回したいんですよ。バイアスを外してスコープを探索して、スコープを決定し、リソースを決定して仮説検証を実行する。

たいがいの場合において仮説検証はコケるので、学びや示唆を得て、またバイアスを外しにいく。重要なのは、またスコープを探索すること。そして、このスコープを探索できる環境をどうやってマネジメント上で保全するかということです。

最終的には仮説検証の期待値が上昇しない限り成果を得ることはできないので、いわゆる「確率」をあげるのか「結果の最大化を図る」のかということになり、これがまさに事業開発のそのものになってくるということです。

THRUSTERにみる諸問題の解決策とは

そこで問題点1としてあがるのは、「自分のバイアスを外せ」とは言ったものの「そんなの簡単じゃないよね」ということです。どうやるのかというと、結論から言えば「1回、抽象レイヤーにフィードバックをかければいいですよ」ということです。

ただ「抽象レイヤーにフィードバックをかけろ」って言ったって、それはそれでけっこう難しいので、THRUSTERでは事業の抽象と具体を行ったり来たりできるように、事業マネジメントのコントロールポイントを成果物として表現しています。わかりますかね？

例えば、さっきも出ていましたけどPEST（Politics、Economy、Society、Technology）分析とか3C（Customer、Competitor、Company）分析って、「PEST分析しろ」「3C分析しろ」って言われても、何を目的にやったらいいのかわかりづらいんです。

それを、「今自分たちが解こうと思っている顧客の課題がなんで発生するのか、因果を調べてごらん」って言ってやると、勝手にPEST分析をやっているんですよ。これっていわゆるマクロ分析の世界です。

ここから先はいわゆる「リーンダイアグラム」的なものもありますけど、その課題に対して代替品がいて、自分たちの課題解決のやり方があった時に、どっちの方が顧客が期待している「顧客の変化」に連れて行くことができるのか、ということになります。

連れて行ける割合が低いものだったり、連れて行くためにかかるリスクやハードルが高かったりすると、最初は響きがよくて使ってもらったとしても、結局リテンションユーザーにはなってくれない。

ここをきちんとコントロールポイントとして表現していかないと、課題が違うのか、それとも課題を背負っている顧客の制約が違うのか、はたまた顧客が期待している変化の内容が違うのか、自分たちのソリューション自体が違うのかというように、どこにフィードバックをかけていったらいいのかがわからなくなります。

「誰が」「何を」「どのように」意思決定するのかの定義

THRUSTERでは、このあたりをきちんとマネジメントできる「仮説検証のアウトプットを最大化できるような会議体」を設計しています。要は、いろんなチームのメンバーの脳みそをスループットで活用したいということですね。それをいかに活用しやすい会議ができるかというところになります。

そこで問題点2として、「意思決定をするのが大変だ」というのがあります。とくに大企業の事業なんてまさにそうなんですけど、資本政策的にぶっ壊れちゃっています。

例えばスタートアップって、株式比率を寄せることで、天才かわかんないですけど、理論上1人のプロダクトオーナーが意思決定をできるように押しつけられるというか、そういう仕組みを持っているんです。

そういう環境じゃないと、なんでもかんでも1人で決めたりするのが難しいので、組織マネジメントがなかなか有効に活用しづらい。なのでTHRUSTERでは事業ステージやロールを定義することで、「誰が」「何を」「どのように」意思決定するのかっていうのを定義づけている。そのようなものです。

最後にもう1回。THRUSTERはthruster.tokyoからダウンロードしていただけますので、もしご興味があればご利用ください。そして、やっぱり最初にマネジメント方法を関係者と合意していただければと思います。ありがとうございました。

（会場拍手）