Knowledge (ナレッジ記事)

新規事業開発を突破するPoCの勘所

導入

新規事業創出制度の起案者、そして事務局やメンターが新規事業の創出に挑む中で、多くの人が抱える悩みや課題がある。その解決のヒントを提供しているのが、新規事業開発支援を行う株式会社アルファドライブの「新規事業よろず相談室」。今回のテーマは「新規事業開発を突破するPoC(概念実証)の勘所」。新規事業の検証フェーズにおいて、事業の受容性・実効性・フィジビリティー(実現可能性)などについて、提供期間や範囲などを区切って実験的に行う「PoC」を乗り切る勘所を伝授する。

フレームワークは先に検証活動をするのが基本作法 

お悩み1:「整理」と「検証活動」のバランス

古川:ビジネスモデルキャンバス、リーンキャンバス、ジャベリンボードはいずれも新規事業開発における検証のためのフレームワークです。それら「机上での整理に時間をかけすぎると、実際の検証活動になかなか進めない」という悩みです。先に動いてから整理するという方法は有効なのでしょうか?

麻生:このお悩みの内容を読んで疑問に思うのは、リーンキャンバス一つとっても、初めから全てを埋めるものではないということをご存知なのかな、ということです。最初に埋めるのは、両サイドの課題と顧客セグメントです。そのインサイトが深くなった後で、ソリューションやUVP(独自の価値提案)に着手し、その後チャネルやコスト構造などを埋めていきます。

古川:なるほど。前半戦の課題や顧客セグメントの部分を埋めるためには、質問者の言葉を借りれば「現場での観察、ヒアリング、実証などの行動」が中心であり、事前準備やフレームワークへの落とし込みなんてしなくても、ヒアリングベースで進めていけるということですね。後半戦になるにつれて事前準備やフレームワークの機会が増えていくため、質問者が考える「先に動いてから整理」が、事業開発の基本作法ということになりますね。

麻生:挙げているようなフレームワークは、審査・投資する側と提案する側のコミュニケーションを円滑にするためのツールです。起案者は発案した事業への思いがあふれがちですから、百枚を超えるようなパワーポイントでプレゼンしようとします。コミュニケーションコストを下げる意味でも、こうした1枚文書で表すことができたらよいですよね。プロジェクトが進んでいけば、チーム間の共有事項にズレが生じることもあります。その際にも、チーム間の目線をそろえる意味で効果を発揮するでしょう。

リーンキャンバスなどのツールを活用すれば事業が進むわけではない。「先に動く」というのはその通りですが、リーンキャンバスなどがイコール「机上での整理」という前提が違っているという印象です。

社内起業家ならば、お金をかけないPoCで苦境を突破せよ 

お悩み2:PoCの必要性が理解されない

古川:「PoCの必要性が理解されない、打開策を教えてほしい」という切実なお悩みです。

麻生:おそらくこの上司は経営企画部門の管理職なのでしょう。“守り”の上司であるのに、PoCを飛ばしてつくる新規事業に投資しようとしている。

古川:こういう上司がいた場合の対処法を教えてください。

麻生:まずはペーパープロトタイピング(実体を持たない試作品づくり)の少し先にある「お金をかけないPoC」の方法を考えてみてはいかがでしょう。つくらないと分からないレベルの新規事業なら話は別かもしれませんが、仕組みでソリューションをつくるような新規事業(例えばマッチングビジネスなど)なら、世の中に出ている既存の無料サービスを組み合わせながら価値提供を行い、事業計画のもとになるデータ(根拠)を集めるという、MVP(Minimum Viable Product)の手法があります。

他にもOnly Visualという、見た目だけをつくるMVPもあります。通常、ロゴやランディングページをつくるといった作業は、社内デザイナーや制作会社を動かさなければいけないため多少の予算を必要としますが、そういう状況ならお金をかけずにデザインする方法も考えて突破してほしい。例えば、友だちや会社の若手デザイナーに「ごめん! 絶対面白い経験になるから無料でつくって」と頼み込むなど、いくつか方法はあるはずです。その後は自分で契約したレンタルサーバーに置いてみて、なんなら契約も勝ち取ってしまう。これは非常にイレギュラーな突破法なので、おそらく会社の人には怒られますが、社内起業家ならばそのくらいの覚悟を持ってほしいと思います。

古川:ある意味、正攻法で行き過ぎないことも大事なのかもしれませんね。要は、やってしまえばいいと。お金をかけられないという苦境においても、上司が怒るのが面倒なレベルまで既成事実をつくって突破していく。そんな“出る杭”でいてほしいです。

麻生:ここまでしてきた話が解決策の1だとすると、実は解決策2があります。それは、社内政治です。王道といえば王道ですが、こういう会社は、社内政治で動きます。上司が誰と懇意にしているかなどを調べ、社内の利害関係を把握しながら自分のスポンサーを見つける。社内政治は“戦争”ですから、中途半端にやると危険ですが、効果は絶大です。

さらに解説策2の派生形として、解決策3もあります。その新規事業や実証実験の銘柄を、既存事業文脈にしてしまう方法です。例えば、社内にある他のDX部隊の部長やマネージャーと話をして、「この新規事業・実証実験が自社のDXにとって非常に重要な位置付けにある」ということに“してしまう”のです。そうすれば既存事業の文脈でPoCの予算が下ります。そういう意味では、解決策3のためにDX部隊に異動した方がよいのかもしれません。

PoCは、数にこだわることなかれ

お悩み3:PoCにおける顧客(toC)集客手段

古川:BtoCビジネスのPoCで顧客を集める場合の参加者獲得の方法として、Facebook以外の効果的アプローチがないかというお悩みです。

麻生:まずPoCなので、数は重要ではありません。1万人集客しないとPoCが成り立たないというわけではありませんから。それよりも、少数の顧客の深いインサイトに刺さるかどうかがPoC検証の本質です。例えば、WebサービスのPoCなら、実際の対象顧客候補のところに持っていき、「触ってくれるか」「課題解決シーンにおいて機能するか」「本当に使ってもらえるか」といったことを検証しなければいけません。Facebookの投稿頼みである時点で、「toC」の集客に対する強度が弱く、例えば「ランディングページをどのくらいの人がクリックしてくれるか」程度の浅いPoCになってしまいます。

古川:それを前提として、効果的な集客手段はありますか。

麻生:PoCの集客の基本は、「連れてくる・集客する」ではなく「行く」です。例えば、ペットオーナー向けのウェブサービスを考えていたとします。その場合、ランディングページをつくり、それをFacebookのペットオーナーコミュニティに投稿して「参加してね!」と募るより、Webでそのサービスのサイトを開設して、ペットショップやドッグランに持っていった方が早い、という感覚です。

古川:集客の検証、つまりチャネルやマーケティング効率・獲得効率などが問われるPoCのケースではどうですか。ソリューション自体の価値が実証された後の、かなり後半のPoCにはなりますが。

麻生:そのときは少額でもいいから予算を付けてマーケティングするしかないですね。

古川:なるほど。この質問への回答をまとめると、ソリューションの価値を実証するような前半戦のPoCならば、数にこだわらず、課題当事者のところへ行って検証すればよい。ソリューションの価値が実証された後の集客検証・マーケティング検証ならば、数十万円でもいいから予算化してもらい、有償PoCを実施する、ということですね。的確な答えになったのではないでしょうか。

PoCパートナーの獲得は、自分から動こう

お悩み4:PoCパートナー(toB)の見つけ方

古川:事務局のお悩みです。toBサービスのPoCにおけるパートナー探しについて、事務局の方のお悩みです。

麻生:PoCまで進んでいるのなら、顧客仮説があるはず。それに該当する会社に電話すればよいと思います。あるいは、企業ホームページの問い合わせフォームから問い合わせてみましょう。

古川:確かに、1社すら引っ張ってこられないのならば、その構造自体が問題かもしれません。

麻生:質問者は「社外広報」でもあるようですが、Facebookの投稿などで募集すれば、協力者が集まってくると思っているのかもしれません。それならば「けしからん!」ですね。

古川:けしからん、いただきました(笑)。

麻生:「事業化していないものは広報不可」とも言っていますが、それは当然です。一部の先進的企業では「これは実証実験中です」などの注釈を入れてプレスリリースを出していて、それは非常に素晴らしい取り組みですが、普通の会社には難しいものです。

古川:でも、インターネットで下調べしてリスト化し、上から200社くらいに電話していけばきっと見つかりますよね。

麻生:その通りです。自社がやりたい新規事業でその事務局を務めているのなら、自分から動きましょう。それをどれだけやっても、まったく誰も話に乗ってきてくれないのなら、そのときはアルファドライブにぜひご相談ください。

業界構造的に困難な新規事業開発の正攻法

お悩み5:PoCを推進するための社内プロセス

古川:かいつまんで言うと、「堅い銀行系リース会社で新規事業に取り組むものの、これまでの新規事業は外部業者に委託することを常としてきたため、自社運営の新規事業が拒絶されてしまう。アジャイルも受け入れられない。既存の枠組みを取っ払ったPoCの制度設計があれば助言してほしい」というお悩みです。

麻生:非常に味わい深い質問です。まず前提としてリース会社の構造上、仕方ない面があると思います。リースとは「巨大なアセットをある程度長期にわたって賃貸し利益を得る」というビジネスです。そのため、既存事業とは性質の異なる新規事業においても、「運営を外部が行う」「自社では運営しない」というメンタリティーを貫こうとするのは理解できます。質問者の希望をかなえるのはかなり難しいでしょう。どうしても実現したいのであれば、転職が一つの方法かもしれません。

古川:転職を勧めてしまいました(笑)。

麻生:しかし、質問者が「この内製化は自社の経営戦略において非常に重要」と考え、第一歩として内製化に着手したいのであれば、話の立脚点は「なぜリース会社において、今までやってこなかった自前の運営母体を持たなければいけないのか」の部分でしかない。つまり戦略議論を会社側と徹底的にやらなければいけないということです。おそらくその理由は、DXなどといったものになると思います。それならば、個別の新規事業案よりも上にあるレイヤー、例えば次期中期経営計画に「DX推進をしていく上で自前の事業を持つ」ということが記されれば、新規事業は通りやすくなります。上流を攻めるのが正攻法です。

お金を出してくれない有償PoC「本当のKPIが達成されていないのかも」

お悩み6:PoCが本格商用につながらない

古川: PoCが本格商用につながらない場合、どのような解決策があるのでしょうか。

麻生: PoCになり切っていない印象です。その有償PoCに対して顧客が「お金がない」と言って二の足を踏むようなら、質問者が「達成した」と思っていたKPIが、顧客が達成したかったKPIではなかった可能性があります。

古川:PoCに付き合ってくれるレベル感ではある、だけどお金を払うほどではない。つまりお金を払ってでも手に入れたい価値・解決したい課題を捉えられていない可能性がある、ということですね。

麻生:また、あらかじめお金の話もしておくこともポイントです。全く触れてこなかった場合にこういうパターンに陥りがちです。実証実験も商売ですから、正々堂々と対価を求めればいいのです。

古川: こういうケースではいったん本格商用は諦め、とりあえずの反応を見る程度の無償PoCに切り替えた方がよいと思います。その後に商用の確認を行うのなら、そのときはそれまでの間にしっかりお金の話をしましょう。

Q&Aセッション

以下、その他に寄せられた質問に短くお答えします。

——PoCでは「費用&納期vs機能」がトレードオフの関係になります。検証したい機能を絞りながらPoCを細かく回した方がよいのでしょうか。

麻生:全くその通りです!

古川:質問者が起案者ならば、この観点は素晴らしいと思います。「費用&納期vs機能」のトピックということで、事務局の方に向けて付け加えるなら、PoCでのものづくりは「起案者チームと開発会社・制作会社だけにやらせては駄目」です。起案者チームは「これまで一生懸命検証に付き合ってくれた顧客を満足させるために、絶対に自信があるものを提供したい」から要件を盛り込み、開発会社・制作会社は「売り上げを上げたい」から機能を盛り込む。そんな両者に任せると、非常にお金がかかる方向へと転がっていきます。

——PoCは本番と同じ100%までつくり込まず、提供価値の中でもコアとなる部分のみに絞り設計するのが大事だと思います。しかしPoC実施後の審査では「本番の提供価値と乖離(かいり)があるから判断できない」という理由で審査員から棄却されました。

麻生:質問の趣旨からは少し外れますが、本番の提供価値との乖離を理由にしていますが、もしかしたら理由が他にあるのかもしれません。例えば審査員は、本当は市場規模の想定に懐疑的だったとか…。

私たちも企業の最終審査に立ち会う機会がありますが、基準のレベルに達していても事業が通らずに悔しがっている起案者チームをよく見ます。その時、最後にもう一段階頑張って「最終審査対策」に臨んでほしかったと感じます。審査員の質問を全て防衛するだけの資料をつくり込んだ上で最後の戦いに臨んでほしい。外部審査員として呼ばれることも多いため、審査会の裏側をだいぶ見てきましたが、裏側で話されている審査評と実際に伝えられる審査評が違っているケースはよくあります。少々理不尽な話ですが、それが社内起業というものです。それを踏まえて丹念な準備をしましょう。

——システム開発が一切いない会社のためソフトウェア開発のMVPを外注しているが、時間とコストがかかりすぎる。何かアドバイスはありませんか。

麻生:本当につくらなければいけないかどうかが問題です。ぜひお金をかけないPoCを実践していただきたい。その上で、それでもつくらなければいけない場合は、“ありもの”のシステムで代替できるか検討する。最近は、ノーコードでできる開発ツールもあります。そこまでやっておくと、発注の勘所も分かるので、以降のコストを抑えられるようになるかもしれません。

古川:最近のノーコードは使えますね。私が見ているチームでも、ノーコードの開発ツールで検証を実践しています。ノーコードを嫌がるのはデザインに凝る人たち。「神は細部に宿る」という発想を持つ人たちです。

麻生:ずばり、宿りません! エンターテインメント事業は別としても、一般的な課題解決型の事業開発プロセスで出てくるMVPの細部には、神は宿りません。

古川:だから、PoCでの検証にそのMVPが本当に必要かということを、一段階深いレベルで考えた方がよいと思います。課題解決ができていれば、UIがいまいちでも乗り越えられるはずです。

——社内のフローが重くて遅い。検証用のランディングページをつくるにも、制作と承認に2カ月弱かかり、検証期間のタイムオーバーになりそうです。

麻生:当社で代行します。お問い合わせください。

古川:例えば、LPで何らかのサービスを紹介し、コンバージョンとしてメールアドレスを集める形式であれば良い検証サービスがあります。本コンテンツを自社の宣伝にするのは控えたいので、このくらいにしますが。

麻生:自前でやるのは諦め、当社でなくてもいいので外部のパートナーをうまく使うのがよいでしょう。

——事務局ですが、経営陣とPoCという言葉の解釈が異なり目線合わせに苦労しています。「小さく試す」という概念・意義を伝え切れません。攻略法を教えてください。

麻生:ある程度大きな会社であれば、PoCの意義をすり合わせる必要はありません。PoCの概念・意義を経営陣に理解させる目的は「会社のお金を使うため」。しかし、前半のペーパープロトタイピングやヒアリングに経営陣の承認は必要ないですし、何かをつくるにしてもランディングページやチラシをつくる程度なら、課長や部長の決裁でいける範囲です。つくるものにもよりますが、今はIoTデバイスも、ソニーの「MESH」などでつくれます。PoCは、意外とお金を使わずできるものなのです。よって、経営陣に理解してもらう必要はありません。

——OEMメーカーのため、顧客との力関係的にPoCが進めにくい。このような力関係での新規事業開発を行う際のコツを教えてください。

麻生:エンドユーザーが顧客(=ブランドメーカー)の先にいるからやりにくいというお話であれば、確かに顧客伝いでPoCをやろうとすると変なことになりそうです。そこで、顧客を飛ばしたPoCを自社主導で行い、その成果を顧客に売ればいいと思います。

古川:ものづくりが得意なOEMメーカーの新規事業開発などなら、この発想で面白そうなものが生まれそうです。

登壇者について

麻生 要一

株式会社アルファドライブ 代表取締役社長 兼 CEO

大学卒業後、リクルートへ入社。社内起業家として株式会社ニジボックスを創業し150人規模まで拡大。上場後のリクルートホールディングスにおいて新規事業開発室長として1500を超える社内起業家を輩出。2018年に起業家に転身し、アルファドライブを創業。2019年にM&Aでユーザベースグループ入りし、2024年にカーブアウトによって再び独立。アミューズ社外取締役、アシロ社外取締役等、プロ経営者として複数の上場企業の役員も務める。著書に「新規事業の実践論」。

古川 央士

株式会社アルファドライブ 取締役 兼 COO

青山学院大学卒。学生時代にベンチャーを創業経営。その後、株式会社リクルートに新卒入社。SUUMOでUI/UX組織の立ち上げや、開発プロジェクトを指揮。その後ヘッドクオーターで新規事業開発室のGMとして、複数の新規事業プロジェクトを統括。パラレルキャリアとして、2013年に株式会社ノックダイスを創業。飲食店やコミュニティースペースを複数店舗運営。一般社団法人の理事などを兼任。社内新規事業や社外での起業・経営経験を元に、2018年11月、株式会社アルファドライブ執行役員に就任。リクルート時代に1000件以上の新規事業プランに関わり、10件以上の新規事業プロジェクトの統括・育成を実施。株式会社アルファドライブ入社後も数十社の大企業の新規事業創出シーン、数千件の新規事業プランに関わる。2023年より株式会社アルファドライブ取締役兼COO。

Download

資料ダウンロード

AlphaDriveの新規事業開発支援に関する各サービスの資料です。
支援概要から事例集まで、幅広くご用意しています。

Contact

お問い合わせ

新規事業開発支援の詳細についてご不明点がございましたら、
ご遠慮なくお問い合わせくださいませ。担当者がご対応させていただきます。