アイデアから商品化の道のりが遠い
新たなコンセプトの商品を生み出すためのアイデアを募集すると、それなりの数のアイデアが出るが、ヒット商品に育てるのは簡単なことではない。アイデアから商品化まで繋げる考え方やプロセスに問題があるかもしれない。いい方法はないだろうか？
リーン開発手法の中のセットベース開発を活用して、アイデアをヒット商品に繋げるプロセスを紹介します。
本記事の内容
アイデアは技術シーズや顕在ニーズからでなく顧客価値から生み出す
アイデアを出して商品化してヒット商品を生み出すためには、まず、良いアイデアを出さなければならないのは当然ですよね。
でも、アイデアの段階でそれが良いか悪いかというのは、なかなか判断が付きません。
良く言われることですが、例えば10人の審査員がいてアイデアの良し悪しを判断するような場面を考えます。
10人全員が良いというアイデアは、実はあまり成功しないのだそうです。
しかしながら、全員がNGだというアイデアも成功しなくて、10人のうち2人か3人が良いかもしれない、というものが成功することが多いのだそうです。
つまり、万人が良いというようなアイデアは、驚きが生まれないのかもしれません。
経験上も、こんな製品は絶対成功しないと陰口を叩かれる製品が成功した事例をたくさん知っています。
アイデアの評価方法に問題があるのかもしれません。
さて、別の角度で、エンジニアのアイデア発想が陥りやすいのは、技術シーズからのプロダクトアウト的な発想だということは、比較的簡単に理解いただけると思います。
プロダクトアウトを否定するわけではありませんが、「ジョブ理論」の中でハーバードビジネススクールのクリステンセン教授も言っているように、運に任せたイノベーションにしないためには、顧客のなすべき仕事（Jobs To Be Done）からアイデア発想すべきだと思います。
ジョブ理論でいう「顧客の成すべき仕事」、つまり「ジョブ」は、ニーズとも違います。
ニーズは、すでに存在する製品に対する顧客の期待なのかもしれませんが、顕在化しているニーズでは、誰もが考えられるアイデアから飛躍することはできません。
いわゆる潜在ニーズと言われるものは、顧客ですら気づいていないものであって、この潜在ニーズ、つまり新たな顧客価値を開拓するという発想でないと、生み出すことは出来ません。
弊社の製品開発革新は、既存製品の延長線上にない、新たな顧客価値を生み出すヒット商品を生み出すことを目指します。
そのためには、技術者、エンジニアが顧客価値を起点にしたアイデア発想をすべきであると考えていて、つまり技術者、エンジニアにマーケティング思考をつけることで、イノベーションの確率を高めることを目指したいと考えています。
参考記事
弊社で活用するジョブ理論とリーン開発を組み合わせた手法では、アイデアをヒット商品に繋げるために、製品とは関係なく顧客が成すべき仕事、顧客の進化への欲求を手掛かりにしていきます。
詳しくは、上記の「ジョブ理論を実践するためのフレームワークを教えます」を参照ください。
良いアイデアが生まれないのは、課題の設定がプアであったり、絞れていなかったりするために、技術シーズや顕在ニーズに偏ったアイデア発想になってしまうのだと思います。
マーケティング思考をまずはエンジニアチームで身につけて、ヒット商品を目指しましょう。
机上で生まれたアイデアを商品に育てる学習プロセス
アイデア発想を加速させるためには、ブレーンストーミングをやったり、KJ法、NM法などを使ったりしますよね。
ここは各社のやり方があるので、手法は問いませんが、弊社ではNM法的なアナロジー思考で他領域からアイデアを借りてくる手法をお勧めしています。
アイデアは多産多死で育てるということはよく言われますね。
でも、どうやって良いアイデアを選抜して育てていくかは、あまり答えがないのかもしれません。
一つの答えは、出発点さえ間違ってなければ、あとは育てていく技術者、エンジニアにある程度はチャンスを与えて、正しい育て方で組織全体で育てていくことだと思っています。
机上でアイデアは育たない
たくさんの企業の開発プロセスを見てきて気づいたことですが、忙しすぎる組織に多い間違いは、机上で考えるだけでアイデアを取捨してしまうことだと思います。
机上の検討から、すぐにプレゼン資料を作って偉い人が審査をして、良いものだけを残すというやり方です。
アイデアは、それが解決しようとする課題こそが大きなカギを握ります。
マーケティング思考で、顧客価値を起点にして重要な課題を設定することが、非常に重要です。
良い課題設定が出来ていれば、エンジニアはそれを解く能力があるのだと思います。
なので、課題設定の質をまず見なければなりません。課題解決に価値があるのかどうかです。
そのうえで、課題解決に向けたアイデアが、
- 本当に課題を解決できるのか
- 副作用はないのか
- 実用性があるのか
を検討していくのが技術開発の本質ですよね。
１，２、３に対する解を試行錯誤しながら、つまり学習しながら、アイデアを育てていきます。
学習しながら、アイデアは場合によっては最初のものから形が変わったり、方向転換があったりします。
試行錯誤、学習を何度も繰り返しながら、うまく解が見つかったものが商品化されるわけです。
１，２，３を解決できる保証はないし、それを初期段階で予測することは出来ないのだと思います。
初期段階で上位職が審査すべきことは、
- 当人の本気度
- 当人のやる気
- 課題の大きさ
- 課題の価値
です。
アイデアを上記の価値観で選別し、あとは正しいプロセスでアイデアを育てて、商品化を目指します。
アイデア発想の当人にチャンスを与えて、かつ組織としてしっかり支援していくことが大切です。
アイデアを商品化に繋げるのは、「学習」であると考えています。
未成熟なアイデアは、未知のこと、わからないこと、チャレンジすべきことをたくさん含んでいます。
それらを一つ一つ潰して前進していくことがヒット商品に繋がっていくわけです。
イノベーションに向けた学習のネタ
アイデアを育てるときに重要なことは、イノベーションに向けた学習のネタを明確にすることです。
どんな学習をすることでヒット商品に近づけていくかの作戦を立てるわけです。
学習ネタとしては、以下の4種類があります。
- 顧客価値そのものに対する仮説検証
- 顧客価値を上げる技術課題
- 顧客価値変数間のトレードオフ
- 製品アーキテクチャの欠陥・弱点
１は、商品としてブレークスルーするための顧客の潜在ニーズ、つまり競合も顧客すらも気づいていない新たな顧客価値に対する仮説検証を行う学習です。
２は、顧客価値に関連する重要な技術課題に対する仮説検証です。
３は、現状の製品で複数の顧客価値がトレードオフ関係にある場合、顧客価値同士をどこでバランスさせるか、あるいはトレードオフをブレークスルーする手段はないかという学習です。
４は、複数の技術要素の組み合わせ、連携、相互作用によってシステムが成り立っている場合に、要素間の繋がりの欠陥や弱点についての課題を検証する学習です。
学習サイクルをプロセス化するセットベース開発
学習ネタを学習リストとして挙げておいて、一つ一つのネタを解決していくことをプロセス化したのが、リーン開発手法のひとつのツールでもあるセットベース開発です。
下図にセットベース開発を実践するためのポイントをまとめました。
セットベース開発をスムーズに進めるために一番重要なことは、学習をするための小さな実験です。
実現可能な最小の実験（Minimum Viable Experimentation : MVE)とも言われますが、学習したい部分、つまり知りたい知識だけにフォーカスした、できるだけシンプルな実験をすることで、早いサイクルで知識を積み上げていきます。
MVEが大切なのは、大がかりな実験、例えば製品に近いような大きなシステムで実験や試作をすると、学習したいこと、つまり知りたいことと他の技術要素の影響が排除しきれないからです。
また、大がかりな実験や試作でコストや時間もかけたくありません。
小さく早く回す、まさにリーンの考え方だと思います。
学習サイクルを製品開発やアイデアの具現化のプロセスに組み込むには、小さな実験を考える力を養わなければなりません。
小さな実験を考える力は、思いついたらすぐに手を動かして何かを作ってみる、という行動力に他なりません。
この文化を作ることが、アイデアを高確率で商品化に繋げる最も効果的な方法だと思います。
関連記事
多くのハードルを越えたアイデアほど高い価値を生む
チャレンジ度が大きければ、アイデアの価値も高くなるのだと言えると思います。
もちろん課題の大きさや、顧客価値として認められるかどうかも大きな要因ではありますが、ハードルが高い、ハードルが多いということは他社が真似しにくいことを意味するで、高い参入障壁を築くことで高い価値を生むことが出来ます。
セットベース開発や学習サイクルの話をすると、必ずと言っていいくらい、「要素開発/基礎研究と製品開発は別物だ。」という議論です。
学習サイクルは、要素開発や基礎研究のときに行うもので、製品開発では出来上がった技術を組み上げるだけだという理屈です。
要素開発で実用化が完了したものを、製品として仕上げるのが製品開発という考えは確かに正しいのですが、では、そのように要素開発から受け継いだ技術を製品にすることにリスクやチャレンジはないのでしょうか？
そんなことは絶対にありません。
百歩譲って要素開発段階で、要素技術の完成度以外の顧客価値検証、アーキテクチャの検証まで完全にやったとして、製品開発は本当に組み上げるだけのものだとすると、これは作業になってしまって、エンジニアとしては本当につまらない仕事になってしまいますね。
要素技術開発者だけが創造力を必要として、製品開発者はミスなく組み上げる作業者では、私は会社は発展しないだろうと思います。
要素開発と製品開発の役割分担
要素開発組織と製品開発組織をきちんと分けている会社と、そうでない会社があります。
いわゆる研究所とか先行開発部門などが要素開発を受け持ち、実用化が完了した技術を製品開発部門が引き継いで製品に仕上げていきます。
要素開発部門がない企業も実際にたくさんあります。大手以外ではなかなか２つの組織を持つのは難しいとも言えます。
要素開発部門が分かれていない、あるいは人数が少なくて仕事そのものを分けることが出来ない場合は、製品開発のプロセスの中で新しい技術を獲得していく必要があり、文句なくセットベース開発の導入が勧められます。
反対に要素技術と製品開発が役割として分かれていても、セットベースの考えは有効だと考えています。
要素開発は、技術課題を解決する「技術」の完成度に全力を尽くし、製品開発は、顧客価値の仮説検証、顧客価値変数のトレードオフのブレークスルー、そしてアーキテクチャ、つまり製品全体のユニット間、部品間での連携で顧客価値を高めるためのチャレンジをすべきなのです。
技術経営の用語で、魔の川（基礎研究の壁）、死の谷（実用化、量産化の壁）、そしてダーウィンの海（市場で勝ち残る壁）というのがあります。
要素開発では魔の川、製品開発で死の谷とダーウィンの海を越える役割分担をすべきだと思います。
イノベーションとは何かと聞いてみると、魔の川だけだと思っている人も少なからずいます。
しかし、本来イノベーションのチャンスは３つの壁に均等にあって、むしろダーウィンの海を越えることが企業として最も見返りが大きいのだと思います。
組織としてイノベーションを推進し、成功確率を高めるためには、魔の川、死の谷、ダーウィンの海を全社で役割分担しながら開発を進めるべきだと思います。
参考記事：ジョブ理論とマーケティング思考セミナー
学習プロセスを強固にする”なぜなぜ力”と”疑う力”
セットベース開発の考え方を開発現場に導入するときに最も大切なのは、エンジニアの皆さんの”疑問を持つ力”、””なぜなぜ力”です。
製品開発でイノベーションを邪魔するものは、「思い込み」です。
人間は「思い込み」の塊のようなものです。
個人の思い込み、組織の思い込みがイノベーションや変化しようとする力を阻害します。
思い込みを排除するには、ロジカルシンキング、つまり論理的な考え方が必要です。
ロジカルシンキング（論理思考力）は以下のように分解することが出来ます。
- 言い換える力 → 抽象度を変えてモノを見る力
- 比べる力 → 客観的にモノゴトを評価できる力
- たどる力 → 因果関係、必要条件などでモノゴトをつなげる力
つまり、ロジカルシンキング（論理思考力）はトレーニングによって鍛えることができると考えています。
ロジカルシンキング（論理思考力）を鍛えるセミナー
タイトル： 論理思考力強化セミナー
概要：
- 事実、仮説、意見を区別するワーク
- TOC（制約の理論）から思考プロセスを学ぶ
- TOCの対立解消図を使って問題の本質を読み解く
- 組織問題の連鎖（因果関係）を理解する
講師：賀門宏一（フューチャーシップ代表）
個人個人のロジカルシンキング（論理思考力）を強化すると、
- 組織の思い込みに異論を唱える人間が増えます。
- 技術会議などで、的確な質問や指摘が増えて組織の知恵が上がります。
- 現状に疑問を持つ人が増えて、変化を促します。
まとめ
新たなコンセプトで、既存商品とは異なるヒット商品を生みだすためにやるべきことは以下のようなことです。
- エンジニアがマーケティング思考を身につける
- 顧客起点で新たな顧客価値を目指す正しい「課題」を設定する
- 課題の価値によってアイデアを選別する
- 選別したアイデアをセットベース開発で学習サイクルに投入する
- ロジカルシンキングで思い込みを排除して学習サイクルを強化する
セットベース開発を導入することで、学習サイクルをプロセス化することが出来ます。
しかし同時に、セットベースの考え方を強化するためには、個人レベルの考える力、すなわち論理思考力を上げることも必要です。
貴社のプロセスに導入を検討される場合は、セットベース開発の導入に実績のあるフューチャーシップで支援させていただきます。
ご興味があれば、下記フォームより入力ください。
こちらからコンタクトさせていただきます。
この記事を気に入ってくれたら、下の”いいね”ボタンをお願いします！！
