最近、新規事業担当者やコンサルタントの間でリーンスタートアップという言葉が流行っています。この言葉にピンときた方はご存じのように、今年4月に日本語に翻訳されたエリック・リース氏の書籍が発端となっています。私も出版早々購入しまして拝読しました。
この本の主題となっているリース氏のスタートアップ体験は、開発主導型の新規事業やベンチャー創業期を経験したことのある多くの方々にとって、既知感として映ったのではないでしょうか。自分も例外なく10年前の半導体ベンチャーでの苦い経験をはっきりと思い出しました。そうこの既知感の中にこそ、スタートアップに共通する罠が潜んでいるのです。
その罠とは事業が成功まで行き着いたかどうかに限らず、開発主導型の新規事業スタートアップでは、
に行く手を阻まれます。もし事業立ち上げを経験したあなたがこの実感していないならば、それはあなたが天才的なアントレプレナーか、既存マーケットに対する後追いのビジネスに携わっていたと言っても過言でないぐらい、高い確率で避けては通れない罠です。
ではこの事実を知ってさえいれば、回避できるか？といういうとそう簡単には行かない。それは同じ失敗が未だに世界中で繰り返されている事実によって、証明されていると言えるのではないでしょうか。では世界中を悩ませているこの罠の難しさはどこにあるのか？私はその一つを前述の言葉を”人”という切り口に変換して言い換えて、
と言えると考えています。
ここでいう価値提供者とは新しい商品・サービスの開発者であり、それを提供する企業などの組織を指しています。なぜこのずれがおこるか？の問いの答えとして非常に根深い原因の一つとして私の仮説をご紹介したいと思います。
新しい製品を生み出すプロセスには表からは見えない多くの苦労があります。目標となる性能が実現できなかったり、原価がおさえられない中、社内のプレッシャーを振り払いながらも必死で計画の遅れを取り戻して・・・などなど開発現場には想定外の問題が日々起こっています。こうした逆境を乗り越えていくためには、開発チームにとって何か意識を集中する拠り所が必要になります。そしてそれは多くの場合、ナンバーワンやオンリーワンと言えるようなやりがいのある製品性能や機能が設定されます。いわゆる製品としての目標仕様です。私はここに大きな罠があると思っています。
目標設定は決して間違いではありません。むしろこれがあるから開発プロジェクトが成立する。問題は、開発を進めていく中で、困難を乗り越えて行く中で、着手時の目標仕様がそもそもユーザーニーズの”仮説”であったことを忘れてしまうことにあります。誰が設定した値だったか？そしてその数値の根拠はどこにあったのか？は開発後半にはぼやけてしまう。そしてユーザーに本来提供すべきは、ユーザーにとっての価値であったはずが、いつの間にか自分達が最も苦労して実現した機能や性能（オンリーワンやナンバーワンなど）にすり替わってしまうのです。
新製品の多くはまだ世にないもののはずです。それがイノベーティブであればあるほど、既存のものとは大きくことなる可能性が高い。ユーザーも実物を見て、触ってみないとその価値は理解できません。そして現在は20〜30年前には想像できないほどの速度で技術開発やユーザーのニーズが変化しています。つまり、現在においてこの開発初期のユーザーニーズに対する仮説の精度はかつてより低くなっていて当然です。
そもそもはユーザーのためを思って開発に着手したにも関わらず、いつの間にか提供側の思い入れに引っ張られて製品を形にしてしまう。この傾向は現場が自ら問題を見つけ、積極的に解決しようと動く日本人にとって特に強いと感じています。
このようにスタートアップの罠は知識や経験だけで対処できる問題だけではありません。人の”行動特性や思考特性としての罠”と捉えたが正しいと考えています。だからこそ何度も繰り返されてしまう。ではこれに対処する方法に何があるか？それはずばり、
つまり提供価値の仮説検証サイクルをプロジェクト計画に盛り込むという事に尽きると思います。
なんだ当たり前？！・・・とおっしゃるかもしれませんが、それを開発初期の計画から実行している例を私は殆ど見たことがありません。しかし、この効果は間違いありません。仮説検証サイクルというコンセプトをプロジェクト計画に入れるだけで、リリース計画が変わり開発初期にコミュニケーションすべき相手も変わります。日々のタスクや試作・製品仕様までもが大きく変わるということは、つまりプロジェクトメンバーの意識や行動が変わっていきます。それぐらいこのコンセプトには大きな影響力があるわけです。
では実際のプロジェクト計画において具体的にどう盛り込んでいくかは、また次回ご紹介したいと思います。
