企業内に数%しかいないイノベーターをどう育てるか--Relicが定義する育成手法「IRM」 - (page 2)

大丸氏：「仮説検証／リサーチ」では、「検証事項」と「未検証事項」が整理できておらず、適切な検証プランが立てられていないことが非常に多いですね。

　新規事業開発のフレームワークもいくつか生まれていますが、例えば「リーンキャンバス」や「ビジネスモデル・キャンバス」などが一般的に知られてきていると思います。フレームワーク自体が重要なわけではありませんが、これを例に上げると、顧客の課題や解決策の提供価値など、新規事業を検討するにあたり必要な項目やポイントを埋めていくことでプランを整理していきます。

　たとえば、子育て家庭で子供が病気になったとき、適切な病院を探しにくいという課題があったとします。これをリーンキャンバスに則って、最適な病院とマッチングすることで解決する、みたいな形で項目を埋めていくわけですが、そもそも子供が病気になったときに親は病院に連れて行きたいと考えるのか、というところから本来は検証していくべきなんです。

　ここで、リーンキャンバスで埋めた初期仮説と、実際に確認した検証済みの項目がごっちゃになってるケースがよくあります。もちろん最初はすべて仮説ですから、全然固まっていない仮説をどこから検証していくかという検証プランが大事です。顧客と課題のどちらも存在しないのに、解決策だけあっても誰も必要としませんから。

　正しい順番としては、顧客が存在するのか、その顧客が本当に課題を持っているのか、という流れで検証していくべきですが、特にメーカーやシステム開発に強い会社は、ここの順番が間違っていて、顧客が存在することを確認する前に、技術的にこのソリューションが実現できるのかという技術検証から入ってしまったりするんですね。もちろん、予め検証済みの技術を活用したソリューションがあったとして、それで解決できる課題を抱えている顧客を探索するというプロセスをしっかり踏むことで上手く行くこともあるのですが、ほとんどの場合、そのプロセスを行っていない。

　そうすると、R&Dが成功したところで、それを欲している顧客がいるかどうかを確かめていないので、「この開発コスト回収できなくない？」みたいなことがよく起きている。

　本来、顧客がそういうプロダクトにお金を支払うかの確認ができるまではモノづくりをしない、という仮説検証プロセスが必要なのですが、それが徹底出来ていないケースは非常に多いですね。顧客の存在と、これまで解決できなかった課題を見つけること自体がイノベーションへの第一歩となり得る要素なのに、ソリューションとしての目新しさや、新技術の有無みたいな観点を「イノベーション」と捉えてしまっていることもあります。

——それと似たことは、最近だとデジタルトランスフォーメーション（DX）でもありがちですね。

大丸氏：まさにそうですね。DXという手法自体が注目されて、必ずしもデジタル化をしなくてもいいところに無理矢理DXを持ち込んでいるケースもありますよね。新しいことをやらなければいけないという危機感があると、どうしてもそういうマーケティング目的のバズワードに引っ張られがちですが、冷静に本来の目的から考えて判断していく必要があります。ですので、我々は新規事業開発の経験者をメンターとしてアサインして、仮説検証を始める前に、検証プランの設計から支援することが大事と伝えています。

　次は「評価／ブラッシュアップ」における課題です。これは社内の新規事業プログラムを実施しているケースで多発するため、トップダウン型新規事業開発などでは当てはまらないことも多いのですが、その事業の進捗の良し悪しを判断する条件が定義されておらず、意思決定権者が恣意的に「続ける／やめる」を決めてしまうことがあるんですね。

　事務局や役員による意思決定の現場で「そもそもどういう観点で意思決定するか」が決められていないので、良くも悪くも、その場の空気や一番偉い人の言葉で評価が左右されてしまうことが非常に多いんです。これは必ず起きることなので、新規事業開発にトライする前に、どういう条件に達していたら継続で、あるいは継続しないかを、経営陣も含めて事前に合意しておくことが重要だと考えています。

——経営陣の胸三寸で続けるか、止めるかが簡単に決まってしまうというのは、よく聞く話ですね。

大丸氏：経営陣の方が新規事業開発の経験が豊富で事業の目利きや投資判断に優れている場合は、もちろんそれで上手く行くこともあります。ただ、日本企業においてその条件に当てはまる企業はそれほど多くありません。そのような前提がある中で、その事業の検証の方法がわからないとか、方法がわかっていてもリソースがないとか、リソースがあっても想定外のことが発生してストップしてしまうとか、いろいろな壁はあります。その中でも特に多いのは「相談先がない」というものです。

　相談先となる社内メンターをアサインできればいいのですが、それができず、事務局がなんとなく付き合うものの、事務局の人自身も新規事業開発を経験したことがないので適切なアドバイスができない、みたいなことがよくあります。

　こういうとき、我々のような存在も含め、社内外のプロフェッショナルと繋がっておくことはすごく重要です。社内で全部を準備しようと思わないこと。必ず外にプロフェッショナルはいるので、そういった人と繋がっておいて、適切なタイミングでそのサポートを利用できるように準備しておきましょうとご提案しています。最近は外部のプロフェッショナル人材と繋がりやすいようなネットワークやプラットフォームが各方面でだいぶ整備されつつありますしね。

社内で仮説検証の動きがしにくいなら外部に頼るべき

——ここまでの3ステップだけでも困難な高い壁があると感じましたが、4つ目以降はどうでしょうか。

大丸氏：「共感／チームビルティング」においては、イノベーター人材を含む初期検討メンバーに、どういう能力や性質の人を新しくチームに迎えれば事業が進捗するのかわからない、というのがよくぶつかる課題の一例ですね。

　メンバーが多くなるほどコミュニケーションコストが増えるので、我々は人数を増やすことについては大賛成という立場ではないですが、適切な能力と経験を持つ人材をこういうタイミングで入れていきましょう、というアドバイスをする必要はあると考えています。

　初期構想から一緒に考えている人は運命共同体みたいなものなので、アイデアに共感した瞬間に現業が忙しくても手伝ってくれるのですが、途中から参画する人は当事者意識が初期メンバーに比べると薄いことが多いです。本業が忙しいところで途中参画を打診してもいい顔をしないし、なかなか仲間が増えません。

　そういう場合はたとえばアイデア発表会など、参画したい社員を公募するような場を設けるのが1つの方法です。そこでアイデアの良し悪しを議論したり、発表会の参加者にそのアイデアにつながる原体験を呼び起こしてあげたりして、「繋がり」を自分たちで作れるような場を設けることを提案していますね。

——アイデアに対する熱量をもてる人かどうかが重要なんですね。

大丸氏：はい。そして次の「プロトタイプ制作／MVP」でよくある課題としては、検証に利用するプロトタイプに必要な要求仕様や要件が定義できず、適切にプロジェクトマネジメントができないといった類のものが挙がります。イノベーターの方にはいろいろな出自があります。セールスやマーケティングの経験者、長年にわたって企画をやってきた人、さらにエンジニアもいます。

　エンジニアならともかく、そうではない方だと、特にITに絡むプロダクト開発に一度も関わったことがない方もかなりいて、「お客様の反響が得られたので、次は事業性検証に足る最低限のプロダクトを作ろう」というフェーズに来ても、システム開発の前提となる要求が書けないんです。

　チーム内や社内にエンジニアがいればまだ良いのですが、外部のシステム開発会社を利用する場合は特にしっかりしたRFP（提案依頼書）を求められることが多いので、それがないとディスカッションしても「その要件だけだと見積もれません」となってしまいます。システム開発やプロトタイプ開発に明るい社内メンターや社外メンターを配置して相談できるようにしておかないと、モノが全くできなかったり、できたとしても事業性検証用のプロトタイプなのに莫大な費用がかかったり、とんでもない機能が作られてしまったりする。ですので、この場合は相談体制を事前に作っておきましょう、と提案しています。

——社内にシステム開発部門をもつ、ある程度大きな企業だとその点はクリアできそうにも思いますが……。

大丸氏：ところが、これは大企業に非常に多いケースで、会社の品質管理基準が異常に高くて、プロトタイプがローンチできないこともあるんですね。プロダクトにはどうしても会社の冠をつけてローンチすることになるので、冠を付ける限りは社内の品質管理部門の審査に回して、それを全部通過するまでリリースできない、みたいなことがよく起きています。

　せっかくお客様の反応が良かった事業アイデアがあるのに、世の中に出る前に社内でめちゃめちゃ叩かれて、やれセキュリティを高めろ、やれ顧客からの問い合わせフローが良くない、チュートリアルが不親切などと指摘されてしまい、極端に進捗が悪化したりコストが肥大化したり、最悪の場合ですと結局リリースできずに終わることさえあります。

　こういうときはプロトタイプをローンチするフェーズだけ、事業主体になってくれる協力会社や、企業ブランドを外して事業運営ができる特区を作る、といったアプローチで乗り越えるのがよく使う手段です。たとえば企業の冠をつけるとセキュリティ基準をパスできずローンチできないような事業は、我々が一時的に預かって、株式会社Relicとして仮説検証を回したりします。

　そのなかで得られたノウハウやお客様の反響に基づいて、プロダクトが企業で求められる品質を満たせそうであり、十分に事業化が見込めるのなら、それをまた元の企業に戻して、社内で大きくグロースさせていく、というやり方をすることもありますね。

——大企業が新規事業の仮説検証のために子会社を作るようなケースもありそうですね。

大丸氏：もちろんあります。戦略子会社を作って、大企業の本体だったらできないことにチャレンジするわけです。たとえば金融機関がFinTechでブロックチェーンを使ったソリューションを開発するとか、そういう競合会社に先行されると困るものを戦略子会社のなかで作って積極的にローンチして、そこでPDCAを回していく例もあります。

　そして最後の「テストマーケティング／事業性検証」は、これも大企業に多いのですが、プロトタイプが一通りの完成を迎えて製品として成立していないとテストマーケティングが開始できない、と保守的に考えて着手が遅れることですね。

　特に法人向けのソリューションだと、新規事業の場合はプロダクトのデモができるレベルじゃないとテストセールスをしてはいけない、という考え方が蔓延しています。お客様の反響があるかどうかもわからないのに、半年かけて作ったプロトタイプを顧客に提示してみたら、「全然いらないです」みたいなことが頻繁に起きています。

　そもそも法人向けのソリューションなら提案書1本で仮説検証ができます。エンジニアが1行もコードを書かなくても、「こういう課題が皆さんにあると思うから、こういうプログラムをいくらで売ろうと思っている、これは買っていただけるか？」というようなテストセールスはいくらでもできるんですね。ですから「作る前に売る」という考え方で検証していきましょうとご提案しています。

——そういうケースではクラウドファンディングの活用もできそうですね。