イノベーションとオペレーション

イノベーションとオペレーション
新しいアイデアが普及する過程はSカーブを描きます。
Sの形を右上に登るにつれて、ユーザーの性格が変わることはご理解いただけたのではないかと思います。
(まだ完全に理解されていない方はスーパーカー消しゴムに見る普及プロセスSカーブから自分自身のポジションを知るTech-On! ものづくりと普及率の深い関係 を参照してみてください)
このユーザーの変化に伴って、製品やサービスに求められることも異なります。こちらの記事では製品の黎明期と成熟期は2つの異なるパラダイムであることを述べました。
同じように、スタートアップと成熟した事業を持つ大企業とではほとんどのすべての点で異なります。
(企業内ベンチャーや新規事業部などは、ルール以外はスタートアップに近いと思います)

スタートアップ 大企業
資金 限られている 多い
人材 限られている 多い
設備 非常に限られている 整っている
業務プロセス トライアンドエラー 定まっている
組織体制 属人的 体系化されている
社内ルール ない 整理されている
意思決定 アドホック 組織的・体系的

 

この表に示した違いを生んでいる要因を理解することで、新規事業が失敗する多くの理由が説明できます。そのために、表の左から右、つまりスタートアップが成長して大企業なる過程を考えてみよう。
例えば、介護用ロボットのベンチャーを立ち上げたとする。すると、最初は開発するにも、前例や基準がなく試作品を作っては試し、そして直すということの繰り返しになる。製品が「正常に」動くかどうかの基準すらない。既に普及している産業用のロボットであれば、どのくらいの負荷に耐え、何年間使用されるのか、どのような環境で使われるのか、想定がある程度できる。それはスペックという名の指標が開発者に分かりやすく定義されるためである。ユーザー側が学習するという側面もあり、作り手、売り手、買い手、使い手が前提とする一定の基準は徐々に定まっていく。うまくいったパターンを組織は学習していくと言い換えることができる。
このパターンには「開発」や「営業」といった役割分担も含まれる。その役割分担が機能するための社内ルールが整っていく。
スタートアップ時には、その都度都度で何を開発し、何を売るかといった意思決定はされる。しかし、成功体験や失敗体験が経験値としてたまってくると、判断を間違わないような意思決定の仕組みができたり、暗黙のコンセンサスを求めるようになる。

事業がうまく回りはじめて会社が大きくなりだすと、最初からのメンバーの多くは「昔は何でもすばやくできていたことが、いろんな人のお伺いを立てないとできなくなった」と嘆くのは上記の過程があるためである。

大企業の論理をスタートアップにあてはめてしまう

他方で、大企業の考え方そのままでスタートアップをやると、致命的な問題が起きる。資金、人材、プロセス、ルールなど内々尽くしのスタートアップ。経験上、このような環境に放り込まれると、3つの反応がある。

  1. 行動が何も取れずに思考停止してしまう
  2. 仕組みづくりの構想のための会議を繰り返す
  3. ないなら、ないなりに開き直って動き回る

もちろんスタートアップにおける正解は3なのであるが、他の選択肢を選んでしまっている例を実に多く見かける。この違いがイノベーションとオペレーションなのである。

1は正解至上主義とでも言えるだろうか。正解への道筋がないと、思考停止、いや行動停止してしまうパターンである。すでに確立されたビジネスであれば定石は多く、正解と言えるような道筋に従っていれば失敗しない可能性は高い。これはある程度確立された事業を失敗しないように運営(オペレーション)する極意である。しかし、新しいことに取り組んでいる以上、正解かどうかはやってみた結果からしか言えないということを心掛ける必要がある。

2は巻き込まれる人も多いので、スタートアップでやってしまうと弊害が大きい。仮に仕組みを作ったとしても、試してみないからには仕組みが機能するかどうかわからないからだ。ビジネスが回り、一定のパターンが見えないと、仕組みは描くことはできないのだ。「想定外」の原発事故を除くと、日本の自然災害に対する備えが海外から高く評価されている背景には、災害の多い日本列島に長年住んできた歴史がある。それに、大企業にはふんだんにリソースがある。情報もある。そのため、打てる戦略のオプションが多い。長年そのような環境で仕事をしていると、オプションの中から「最適」なものを選ぶような思考回路が強化される。経営戦略の書籍を読むと「最適化 (optimization)」というキーワードが連発されている。これらの書籍を読むと、最適化の対義語としてイノベーションが挙げられていることが多い。イノベーションの時期では選択肢の中から選ぶような余裕はなく、選択肢そのものを創造しなくてはいけない。これがオペレーションとの違いになる。オペレーションで新たなオプションを作ってしまうと混乱する。

3のように動き回っているうちにパターンは見えてくるものだ。もちろん人によって間違いから学ぶ速度には差があるかもしれない。誰かが勝ちパターンを見つけない限りは、「良い方法」など見つかるわけがない。そのパターンを見つけるためには、トライアンドエラーが必然になる。失敗は辛く、いつ正解にたどり着けるのか、果てしなく感じるかもしれない。しかし、チーム全体が学習することを前提に活動することによって発揮できる能力は計り知れない。

Written by Shingo Tsuda on 2012-10-05

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

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

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

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

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

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

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

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

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

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

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

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

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

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

だということです。

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

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

Written by Tatsuro Tsushima on 2012-07-06

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

高速仮説検証プロセス

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

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

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

Written by Tatsuro Tsushima on 2012-06-15