Leanに事業開発する為の4つの定義

2017年7月10日

前回「PDCAサイクルだけで新規事業をやるとカネを捨てる行為になるって話」で説明した通り、Leanに事業開発を進めるには「PDCAサイクルのみからの脱却」が必要です。事業開発サイクルそのものを「ボトルネックをモニタリングであぶりだし、そのボトルネック解消のためにPDCAを回す」というフローに変化させねばなりません。

改めてGHSが考案したサイクルはこちらになります。

しかし、サイクルの概念図があればその通りに事業を運用できるようになるのでしょうか?

概念だけで運用に落とせる人は天才です。天才は自身が持つセンスで定性と定量を脳内でコントロールしながら、先を見通し運用していきます。更に彼らはその見通しが違うとわかると、それに伴い仮説もアップデートできます。

しかし誰もが天才というわけではありません。これを天才ではない人が実施しようとするには、少し型にはめて進める必要が出てきます。

そこでGHSは、Leanに事業開発を進める為のオリジナルプラクティス「THRUSTER(スラスター)」を考案しました。

本日はこのTHRUSTERの解説記事を掲載します。

THRUSTERとは

まずは内容をご確認ください。

※ ダウンロードをご希望の方はSlideShareからお願いします。

THRUSTERとは、ロケットを衛星軌道に乗せる為に小さく軌道修正をする為のエンジンの事をさし、事業が成長軌道に乗るまでに実施する活動が同じ行為であることからこの名前をつけました。

もしロケットが衛星軌道に乗るまでに残燃料を無駄に使うとどうなるのでしょうか?事業も燃料(ヒトモノカネ)を使って成長軌道に乗せる行為なので、出来るだけ無駄なく使用したいわけです。

もちろんロケットのように途中で燃料を増やせない場合と違って、事業は資金調達による燃料補充ができる(それも大変ですが)ので、「どの規模の噴射が無駄のない噴射か?」についてはケースバイケースではあります。

しかし、それでも事業仮説の角度が高まるまでは無駄を省きたいのは変わりません。

実はこの思想はソフトウェア開発の1つであるアジャイル開発思想と同じ考え方になります。アジャイル開発思想にはスクラムという有名なプラクティスがあり、スクラムは「アジャイル開発思想を開発チームが続けられない理由」を先に解決する為に言語化されています。これにより多くの開発チームがアジャイル開発思想で開発を進められるようになりました。

Leanな事業開発にも同じように「Leanを続けられない理由」が多く存在するので、先にそれらを解決する為に、スクラムを原型にし以下4つの構成要素で考案しました。

  1. 事業ステージ
  2. ロール(役割)
  3. 成果物
  4. 会議体

1.事業ステージ


ボトルネックは事業ステージよって変化します。現状をどのステージととらえるかによりボトルネックとして設定するべき項目は変わります。

正しく事業ステージを判断するためには各々ステージにあった進捗確認方法を採用しモニタリングする必要があります。

また、組織には予算や稟議事情といった政治的条件があり、これらの条件が場合により事業やそのチームよりも外側にボトルネックを作ってしまうことがあります。よって事業ステージでは予算形態や組織についても言語化いたしました。

ポイントはProduct Market Fitよりも前か後かです。ここでROIで処理できるステージかR&Dとして処理するステージかどうかが変わります。

ROIに引きずられると真のボトルネックにたどり着く時間を無駄に取られますので、各進捗管理を実施し素直に状態を理解する必要があります。

2.ロール(役割)

会社というのはそもそも役割ごとに責務が違います。まずは下の図をご覧ください。

会社は顧客株主に挟まれます。

顧客は価値要求をし、株主は利益要求をしてきます。

この時点でお互いの目的は一致しません。その上で会社のマネージメント層は株主の矢面に立ち、事業チームは顧客の矢面に立ちます。

また、BizとDev視点でもハレーションの原因があります。

このように組織にはそもそもハレーションを起こす因子が沢山あります。各ロールを定義することによって組織に紐付くボトルネックが存在しているかどうか判断できるようにしておきます。

事業オーナーから下がチームサイドのロールになります。チームによっては殆どを兼務していることもあると思いますが、少なくともチームにはこれだけの登場人物が必要でその各々の責務があるということを認識して活動する必要があるのです。

3.成果物

チームがLeanに事業開発を進める為に必要なアウトプットです。成果物と書いてありますが「必要ドキュメント」と捉えてもらって構いません。

KPIツリーから始まり、顧客がサービス上触れることができるアクション一覧まで定義してあり、どれも1回作ったら終わりではなくメンテナンス(運用)が必要になります。
また、モニタリングの視点ではないものに、Planバックログがあります。
スクラムで言うプロダクトバックログに当たるもので、ここには主に下記3項目を記述します。

  • 「ボトルネック解消に対する仮説」
  • 「Plan内容」
  • 「それによって得たい学び」

Planは開発的なモノから広告運用、場合によっては顧客へのヒアリングまで記載されることが想定されます。

また、最初に定義した事業のステージもこれらの成果物を利用して判断することになります。


4.会議体



「目的のないMTGを減らしましょう」とはよく聞く話です。目的がない会議は無駄にチームメンバーのリソースを取ることになります。

各ロールには各ロール上知りたい内容があります。特に事業オーナーは最も事業全体が見渡せている人なので、知りたい内容やディスカッションしたいことが沢山あります。事業オーナーが出席する会議は「自分が知りたい内容だけ知る会議」「自分が導きたい結論への誘導」が発生しやすいので、各会議の目的を事前に設定してしまおうというものです。

各会議の開催間隔はそのサービスの状況によって実際はチューニングが必要です。

まとめ

THRUTSTERはチームがLeanに事業開発を実施するためにあるべきものを定めたものになります。これをもって初めて概念運用に近づきます。

また、THRUSTERに定義されているものが完璧というわけではありません。チームメンバーのスキルなど考慮するべき点は多くありますし、スタッフの出入りや外的要因の変化など状況は刻一刻と変化していくので、常にメンテナンスが必要です。

また現在THRUSTERで定義してある内容もどんどん陳腐化していくものなので、一定のタイミングで更新して行きたいと思っています。是非チームの現状とくらべて頂いて、「もっとこうした方が良い」とか、「本当はこうなのではないか?」とか「そもそもここに疑問がある」と言ったご意見を頂ければと思います。

※ THRSUTERに対するご意見はこちらまでお願いいたします。
thruster@ghs.tokyo




最後に宣伝です。

各プロダクトチームに対して「THRUSTERについての出張勉強会」を承っています。THRUSTERのロールにある「投資家役割の方」「事業オーナーの方」中心にチームでお集まり頂けるのであれば「THRUSTER説明+ワークショップ」を実施させて頂きます。

チーム単位でなく、企業単位でも構いません。ご希望の方いらっしゃいましたら、以下メールアドレスまでご連絡頂ければと思います。
thruster@ghs.tokyo

※出張勉強会は都内近郊での開催とさせて頂きます。

—————————————————————————————
ビジネスの成長スピードを速くする GHSの「ビジネスマネジメントサービス」提供中

ボトルネックの無料事業診断も随時実施中!
毎週事業成長相談会もやってます!