スタートアップは普通に進めると失敗する

今回は少し大げさに思えるタイトルをつけてみましたが、この言葉にピンと来ていただけるかどうかが今回のテーマになります。

 前回のブログではビジネスのスタートアップに共通する罠のとして”顧価値提供者とユーザー間でのコミュニケーションのずれ”の原因。そしてそれを解消するために有効な施策は”高速仮説検証プロセスをプロジェクト計画に盛り込む”ことだとご紹介しました。今回はこの続きです。

まず前提としての重要な問いは、

人が関わる事象において誰もが共通して陥る罠の裏には、
人間の特性としての原因があると仮定した方が自然だと思いませんか?

言い換えると、人が普通に行うとそうなるという事象の原因は、まさに人の本能的な判断や行動にあるということです。我々はスタートアップの難しさもまさにこの点にあると考えています。

今回のテーマである施策の本質は、この人の本能的な思考や行動特性を意図的に変えるための手法とも言えます。この点をご理解いただければ、これからの説明により深く納得いただけるはずです。

前回、メーカーとしての提供価値がユーザーニーズとずれる原因は、プロジェクトが進むにつれて初期に設定した目標仕様がそもそも仮説であるという事を忘れてしまう点にあると紹介しました。この問題を解決するために必要となる具体的なしかけとは、開発当初設定している目標仕様を、ユーザーとのコミュニケーションを通して改良、改善させていくというタスクを忘れず実行させてくれるものであれば有効ですね。

そしてプロジェクトを進める上での問題が、もう一点あります。それは人の行動は”計画”というものに引っ張られ易いという特性です。みなさまもご経験がおありかと思いますが、先が見えないようなプロジェクトにおいて初期に立てた計画の精度や納得感は往々にして低い。この事実もプロジェクトが進み、関わる人が増えていくいくうちにいつのまにやら忘れ去れてしまいます。そして、なんとなく違和感を感じつつも、プロジェクトは初期の計画通りに進められ結果火を吹き始める。つまり、一度立てた計画を途中で修正、改善するということは、想像以上にハードルが高いという点も人の本能的な行動として必然的な現象だと言えます。

この二点の問題を解決するしかけが、今回のテーマである”高速仮説検証プロセスをプロジェクト計画に盛り込む”という事になります。

つまりこれは、初期の目標仕様は仮説であり、それを検証しつづけるプロセスが必要という事をチームメンバーにリマインドし続ける”しかけ”です。さらに、そのこの仮説検証プロセスを初期計画に入れることにより、いきなり数年もしくは莫大な費用を要するような製品開発に着手することを避けることができます。つまり、開発メンバーおよび事業化メンバー双方が如何に初期の仮説を検証するためにまず何から着手すべきか?どんなレベルの製品プロトタイプを作るか?または形にするまえのコミュニケーションツールとしての提案資料を作るか?という事に頭と時間を使うようになります。この結果、提供価値とユーザーニーズのずれが低減されていきます。

そしてイノベーティブな提供価値のスタートアップのように世の中にまだ存在しないような新しい価値を生み出す場合はより難しくなります。なぜならば、まだマーケットが存在せず、ベンチマークとなる競合製品も存在しないため、初期の目標仕様および計画の精度が低くなります。そのために仮説検証の”高速性”つまりより多くの検証サイクルが必要になります。そして、提供価値を形にできない段階での、ユーザーとのコミュニケーションが不可欠になります。これは誰も進んではやりたがらない非常に不安定なコミュニケーションです。これ乗り越えていくためには、高いレベルの創造力と表現力、そして行動力が不可欠であることは容易に想像できると思います。

繰り返しになりますが、スタートアップは既存マーケットに提供価値を投入するという通常のプロジェクトの進め方では失敗します。それを回避するために有効な施策は、

高速仮説検証プロセスをプロジェクト計画に盛り込む

だということです。

この事実をベンチャーのスタートアップおよび企業内新規事業立ち上げのチームメンバーそしてあなたご自身と共有できれば、より多くの努力が実を結ぶと確信しています。そして今、私自身もこの罠にはまらないように仮説検証を繰り返しています。

続きを読む スタートアップは普通に進めると失敗する

Written by Tatsuro Tsushima on 2012-07-06

スタートアップに共通する罠

最近、新規事業担当者やコンサルタントの間でリーンスタートアップという言葉が流行っています。この言葉にピンときた方はご存じのように、今年4月に日本語に翻訳されたエリック・リース氏の書籍が発端となっています。私も出版早々購入しまして拝読しました。

この本の主題となっているリース氏のスタートアップ体験は、開発主導型の新規事業やベンチャー創業期を経験したことのある多くの方々にとって、既知感として映ったのではないでしょうか。自分も例外なく10年前の半導体ベンチャーでの苦い経験をはっきりと思い出しました。そうこの既知感の中にこそ、スタートアップに共通する罠が潜んでいるのです。

その罠とは事業が成功まで行き着いたかどうかに限らず、開発主導型の新規事業スタートアップでは、

提供価値とユーザーニーズのずれ

に行く手を阻まれます。もし事業立ち上げを経験したあなたがこの実感していないならば、それはあなたが天才的なアントレプレナーか、既存マーケットに対する後追いのビジネスに携わっていたと言っても過言でないぐらい、高い確率で避けては通れない罠です。

ではこの事実を知ってさえいれば、回避できるか?といういうとそう簡単には行かない。それは同じ失敗が未だに世界中で繰り返されている事実によって、証明されていると言えるのではないでしょうか。では世界中を悩ませているこの罠の難しさはどこにあるのか?私はその一つを前述の言葉を”人”という切り口に変換して言い換えて、

価値提供者とユーザー間でのコミュニケーションのずれ

と言えると考えています。

ここでいう価値提供者とは新しい商品・サービスの開発者であり、それを提供する企業などの組織を指しています。なぜこのずれがおこるか?の問いの答えとして非常に根深い原因の一つとして私の仮説をご紹介したいと思います。

新しい製品を生み出すプロセスには表からは見えない多くの苦労があります。目標となる性能が実現できなかったり、原価がおさえられない中、社内のプレッシャーを振り払いながらも必死で計画の遅れを取り戻して・・・などなど開発現場には想定外の問題が日々起こっています。こうした逆境を乗り越えていくためには、開発チームにとって何か意識を集中する拠り所が必要になります。そしてそれは多くの場合、ナンバーワンやオンリーワンと言えるようなやりがいのある製品性能や機能が設定されます。いわゆる製品としての目標仕様です。私はここに大きな罠があると思っています。

目標設定は決して間違いではありません。むしろこれがあるから開発プロジェクトが成立する。問題は、開発を進めていく中で、困難を乗り越えて行く中で、着手時の目標仕様がそもそもユーザーニーズの”仮説”であったことを忘れてしまうことにあります。誰が設定した値だったか?そしてその数値の根拠はどこにあったのか?は開発後半にはぼやけてしまう。そしてユーザーに本来提供すべきは、ユーザーにとっての価値であったはずが、いつの間にか自分達が最も苦労して実現した機能や性能(オンリーワンやナンバーワンなど)にすり替わってしまうのです。

新製品の多くはまだ世にないもののはずです。それがイノベーティブであればあるほど、既存のものとは大きくことなる可能性が高い。ユーザーも実物を見て、触ってみないとその価値は理解できません。そして現在は20〜30年前には想像できないほどの速度で技術開発やユーザーのニーズが変化しています。つまり、現在においてこの開発初期のユーザーニーズに対する仮説の精度はかつてより低くなっていて当然です。

そもそもはユーザーのためを思って開発に着手したにも関わらず、いつの間にか提供側の思い入れに引っ張られて製品を形にしてしまう。この傾向は現場が自ら問題を見つけ、積極的に解決しようと動く日本人にとって特に強いと感じています。

このようにスタートアップの罠は知識や経験だけで対処できる問題だけではありません。人の”行動特性や思考特性としての罠”と捉えたが正しいと考えています。だからこそ何度も繰り返されてしまう。ではこれに対処する方法に何があるか?それはずばり、

高速仮説検証プロセス

つまり提供価値の仮説検証サイクルをプロジェクト計画に盛り込むという事に尽きると思います。

なんだ当たり前?!・・・とおっしゃるかもしれませんが、それを開発初期の計画から実行している例を私は殆ど見たことがありません。しかし、この効果は間違いありません。仮説検証サイクルというコンセプトをプロジェクト計画に入れるだけで、リリース計画が変わり開発初期にコミュニケーションすべき相手も変わります。日々のタスクや試作・製品仕様までもが大きく変わるということは、つまりプロジェクトメンバーの意識や行動が変わっていきます。それぐらいこのコンセプトには大きな影響力があるわけです。

では実際のプロジェクト計画において具体的にどう盛り込んでいくかは、また次回ご紹介したいと思います。

Written by Tatsuro Tsushima on 2012-06-15