"Lean Startup Japan"

新規事業を成功させる4つのステップ

3分でわかる「ビジネスモデル症候群」

 

2010年に当ブログを開設して「リーンスタートアップ」を紹介し、その後5年間にわたり実際に数多くの起業家や企業における新規事業開発を支援してきましたが、新規事業や起業を成功させるにはとにかく良いビジネスモデルを(仮説検証をしながら)設計できることが条件だと盲目的に認識している状態とは、「ビジネスモデル症候群」という「思い込みの病」を患っている状態だと感じるようになりました。

理由はとても単純。私が携わってきた事業開発や起業シーンにおいて良いビジネスモデルの設計と実現を真摯に追い求めるひとほど、現実的には良い結果を得られていないという現実が数多く発生したからです。そしてそのような状態に陥らせるよう、私自身が実に多くの方をミスリードしてきてしまったのです。一般的には事業成功確率と正比例の関係にあると信じられているビジネスモデルの設計・構築が、どのように事業開発や起業に悪影響を及ぼすかについて、最重要なポイントだけご紹介します。

私がこれまで経験した事業開発支援から、ビジネスモデルの設計・構築という行為には、マイナスの効果を生んでしまうデメリットが2つ存在することが確認できています。それは「シミュレーションに多大な資源を費やす」こと、そして「収益源の選択肢を狭める」ことです。この2つのデメリットは事業設計の初期段階において特にマイナス効果が大きいため、新規事業開発や起業の最初のステップとしてビジネスモデルの設計を開始することこそが、事業投資の失敗を招くという結果を生んでいるのです。2つのデメリットを説明します。

1.ビジネスモデルの設計が事業投資をシミュレーションに止まらせるというデメリット

ビジネスモデルを設計するという作業では、様々な仮説を設定し検証を行います。つまり「ビジネスモデル設計」とは、事業に実際に投資を行ったらどのような結果が得られるかを、実際に多くの経営資源を投じる前に「シミュレーション」している状態だと言えます。さてここで問題となるのは、シミュレーションから得られるデータの精度ですが、シミュレーションの精度が信用に値するかどうかは、「シミュレータ」がいかに実際の環境に近い状態にあるかによって決まります。しかし、事業開発に携わった方であればご存じの通り、「新規事業開発」とは「連続して発生する想定外への決断と対応」と同意語であり、シミュレータの精度が実際の環境とイコールになることなどありえないのです。

ということは、リーンの観点では、ある特定領域に対して事業投資を決定しているにも関わらず、半年・一年、いやそれ以上にシミュレーションに経営資源を投じるとはこそが「ムダ」だということであり、シミュレータの精度を向上させるには、実際に事業を開始する以外に手段はないということなのです。実際に事業を開始しないシミュレータの精度は著しく低いということを認識する必要があります。

2.ビジネスモデルの設計が収益源の選択肢を狭めるというデメリット

多くの場合、ビジネスモデルの設計という行為では特定の「収入モデル」を仮説化します。例えばフリーミアムモデルでプレミア会員からの月額フィーによって収益化するとか、多くのトラフィックを集めてメディア価値を向上し広告収入を得る、といった具合です。これを経営の観点から見ると、いわゆる「選択と集中」を行っていると言えるのですが、選択と集中が良い成果をもたらす唯一の条件は、数多くの選択肢の中から「最も勝算のある事業や収益源」を見いだし、そこに経営資源を集約させることです。つまり、まだどこにも勝算が見えていない状態で行う「選択と集中」は、基本的な経営の原則に逆らっている状態なのです。経営には原理原則がいくつか存在するのですが、特に財務面における原理原則に背いて成功する事業は絶対にありません。「事業の初期段階で勝算のない事業形態に経営資源を集中する」という行為は、完全にこの原理原則に反するものだと言えます。

この2つを一度理解してしまえば、ビジネスモデルの設計とは「適切なタイミングにて、勝算のある事業に対してのみ行われるべき」だということが分かります。

それでもまだみなさんは何も事業を実践していない段階で「シミュレーション」を続け、勝算のない事業に対して「誤った事業選択と集中」を続けますか?

これが2015年末までに私が見いだした、多くの方が事業立ち上げ時に最も顕著に犯す失敗のパターンです。そして今、「ビジネスモデル」という定義のハッキリしないキーワードによって、多くの人がこの失敗を繰り返しているのです。

これは、新規事業開発を行う企業や起業家だけに発生している症状ではありません。投資家、事業支援者、教育関係者、経営学研究者の間でも広範囲に広がる世界的な病なのです。

2008年、エリック・リースは「思い込みを捨てて顧客に学ぼう」と「リーン」であることの重要性を伝えてくれました。

2015年、私は「事業開発の最初の一歩では、ビジネスモデル症候群から脱却しよう」と「リーン」を推奨します。

今日、この記事を読んでいる最中にもシミュレーションを行い、勝算のない収益モデルに経営資源を集中させているあなたは、まさに「ビジネスモデル症候群」なのかもしれません。

来年こそはリーンな事業開発ができるよう、ぜひこの年末のタイミングでご自身の状態を振り返ってみて下さい。

また、ビジネスモデル症候群からの脱却方法については、今年の取組みの中で様々な実験を継続しています。自分も、自分の会社もぜひその実験に参加してもいいとお考えの方がいらっしゃいましたら、ぜひこちらからお問い合わせ頂ければと思います。これまでに蓄積した知見はすべてお伝えしますので。

※こちらの資料は2015/12/8に開催したセミナーでご紹介した「ビジネスモデル症候群」のスライド資料です。200枚弱のボリュームある資料ですが、ビジネスモデル症候群の発生メカニズムやビジネスモデル設計が有効な場面についても合わせてご確認頂けますので、上記記事で関心を持たれたらぜひご一読下さい!(たとえばビジネスモデルというシミュレーションを行うことは、「事業投資をしない」という経営判断を行うには効果があるということなどを解説しています)

回らないフィードバックループの原因と絶対に誰でもわかる改善策

 

リーンスタートアップの基本的な考え方である「ニーズが不確かなサービスは初期段階では小さく始め、確からしさの検証を重ねて大きく育てる」は、クラウド環境の浸透やスマートフォンアプリ開発のハードル低下とともに、実に分かりやすく始めるのもカンタンです。

しかし、この分かりやすさと始めやすさとは裏腹に、リーンを実際に運用してみると「どのように育てたら良いのか分からない・・・」という困惑をよく見かけます。課題の改善を繰り返しても良い結果につながらないなど、前へ進んでいる実感を得られない状態に陥り、フィードバックループが回らなくなるのです。

今日は継続的な改善における典型的な失敗事例をご紹介して、リーンの効果が劇的に向上するあるポイントをお伝えします。
多くの方がその間違いに気づかないポイントなのですが、いったん分かってしまうと実に簡単なことなので、ぜひご一読ください。
では、すでにローンチ済みのサービスの改善を行っている場面を想定しながら、一緒に考えてみてください。

 

 

下の図は、あるサービスにおいてチームが「ユーザの滞在時間を向上させる」という改善に取り組んでいる場面を表しています。滞在時間の長いユーザがARPUが高いことをデータから読み取ったエンジニアが、滞在時間を向上させる施策としてユーザの行動履歴からレコメンドを表示するという機能を投入するという、サービス改善を行うチームではよく見かける光景です。

しかし、この改善活動にはある重大な欠点が隠されているのですが、みなさんはその間違いが分かりますでしょうか。課題があって、改善策を立てて実行したらその結果を確認する、という単純な作業なのですが、ここにはPDCAを回す上での大きなミスがあるのです。この先を読み進めて答えを見てしまう前に、ぜひ少し時間を取って考えてみてください。

 

wrong_feedback_loop

 

 

 

 
いかがでしたか?分かりましたか?

正解は「メトリクスの設定が間違えている」です。
正しくは、まず最初に「レコメンドが押下されたか?」を測定しなければならないのです。

 

vanity_metrics.001

 

???

なんで?滞在時間を向上させるために対策を打ったのだから、それが向上したかを確認するのは当たり前?

ですよね。
ではこのフィードバックループの詳細を見ていきましょう。

ここでチームが成し遂げたいことは「ユーザの滞在時間の向上」です。これが今回の作業の「目的」に相当します
次に「レコメンドを表示する」とうのは、この「目的を達成するための一案」として実行されますので、つまりは「手段」に相当します

つまりこの両者は「目的」と「手段」の関係にあるわけです。

図のループでは手段を講じた結果として目的が達成しているかを判断しているわけですが、手段と目的の関係には常に以下のような結果が発生します。
1.手段が達成され、目的も達成された(よって目的と手段は因果関係があった、と推測できる)
2.手段が達成されず、目的も達成されなかった(同じ)
3.手段は達成されたが、目的は達成されなかった(よって目的と手段に因果関係がなかった)
4.手段は達成されなかったが、目的は達成されていた(目的と手段には因果関係がなく、かつ他の要因が目的を達成した)

この場合、手段である「レコメンドの表示」を投入した効果を測定するには、次の2段階を経る必要があります。
1.ユーザはレコメンド表示に反応したか(押下したか)
2.その結果としてレコメンド表示はユーザの滞在時間向上に貢献したか

 

2stepstovalidate.001

 

では上記の4パターン毎に、チームがその後に取るべき行動を整理しましょう。

1.手段が達成され、目的も達成された(よって目的と手段は因果関係があった、と推測できる)
→今回の測定期間においては、目的と手段に因果関係があったように推測できた。よって両者の関係性を今後も継続して定量的に観察し、その効果をウォッチする
2.手段が達成されず、目的も達成されなかった(同じ)
→まずはなぜ手段が達成されなかったのかを考察し、手段が実行されるよう修正を行う。両者の因果関係についてはその結果を持って判断する。
3.手段は達成されたが、目的は達成されなかった(よって目的と手段に因果関係がなかった)
→手段と目的に因果関係が無かったので、他の手段を検討すると共に、この手段をそのまま維持するかどうかも検討する(場合によっては、目的を達成できなかった手段は削除することも)
4.手段は達成されなかったが、目的は達成されていた(目的と手段には因果関係がなく、かつ他の要因が目的を達成した)
→手段が達成されなかった原因を考察すると共に、目的を達成した他の要因がなにかの調査を開始する

このように、目的と手段を明確に分離すると、ループの2周目でやるべきことがまったく異なる作業になることが分かります。これを単純に滞在時間が延びたら良かった、伸びなかったら他の策をまた投入するの⒉択で運用を繰り返していくと、実は手探りで運用しているのとまったく同じ状態になっていくのです。

書籍「リーン・スタートアップ」の中でエリック・リースは、自分たちのサービスがいかにイケているかを、ユーザ数や広告の視聴率などで測定することを “Vanity Metrics”と称して、やってはいけないことと論じています。本来は本当に自分たちのサービスが価値を持っているのかを測定し、自分たちの真の姿を理解しないといけないのですが、少しでもサービスの状態をよく見せようと「虚栄」の姿を見せようとする行為を「虚栄の評価基準」と呼んだのです。成功するスタートアップは「アクショナブル(対応可能な)評価基準」で事業を評価すべきだと。

これをプロセス設計の観点から解説すると、物事にはすべて「目的」と「手段」があり、これは幾重にも重なった構造を形成します。例えば企業活動の最終目標は決算において黒字化することや株価の向上に帰結してくるわけですが、この「目的」を叶えるためには、部門毎に幾重にも細分化された「手段(群)」で形成されます。こうしたひとつひとつの手段群を測定する基準として、いきなり株価で判断することはありません。それぞれの手段が個別に測定され、その集合体として「目的」が達成されたかを判断するのです。

つまり”Vanity Metrics”の正体とは、目的と手段の関係において、その構造を飛び越えたメトリクスで評価をすること全般を指すのです。
目的と手段の組み合わせが5層で構造されているとしたら、メトリクスは階層構造それぞれに存在しなければなりません。そして常にまず下位の手段が測定され、その結果として手段が上位の目的に対して効果があったかという判断を繰り返していくのです。これが「アクショナブル(対応可能な)評価基準」が設定されている状態です。

リーンスタートアップの考え方は実に単純ですが、実際の運用を設計すると実に深い考察が必要になります。今回のような「手段と目的は別々に測定し、その因果関係を考察する」といった基本を押さえていくことで、その精度は格段に向上するのです。

前回もお話ししましたが、リーンスタートアップとは事業開発を「マネジメント」することです。
マネジメントできている状態とはどのような状態であるかをぜひ考えてみてください。