はじめに

まずSession1に入る前に、「私たちが新規事業開発について講演をしている背景」の紹介がありました。

マクニカは半導体やネットワークといった事業を中心として、この10年間でリテール・スマートシティ＆モビリティ・製造DX・アグリテックなど、さまざまな新規事業を推進してきました。

その最大の理由は「2030年にビジネスモデル変革を実現し、独自価値を創出できるサービスソリューションカンパニーを目指す」というビジョンを実現するためです。すなわちマクニカは各事業においてお客様の伴走型パートナーでありつつ、新規事業開発という大きな壁に皆さまと一緒に立ち向かう、「仲間」でもあるのです。

また、2020年ごろから世界的に猛威を振るった感染症が話題に挙がりました。この感染症はさまざまな業界に大きな影響を与え、そのなかで業績を伸ばした企業もあれば、そうでない企業もありました。

いずれにしても、その機運から「企業は事業に柔軟性をもち、新しい顧客を獲得して持続的に成長する必要があるという大きな流れが生まれ、かなり矢継ぎ早に新規事業の推進組織がさまざまな企業で立ち上がった」というのが、マクニカから見た印象です。

なお本ウェビナーは数百名の方にお申し込みをいただきましたが、その職種・業界は実に多様であり、やはり多くの方が新規事業開発にチャレンジしていることがうかがえました。

新規事業開発の担当者は、えてして孤独な環境にあることも少なくないと思いますが、本村は「このウェビナーで新規事業を立ち上げることの難しさや、うまく進捗させるためのヒントを皆さまと一緒に分かち合いたい」と語り、冒頭を締めくくりました。

新規事業の酸いも甘いも10分につめこみます

「10年間の新規事業開発をジェットコースター体験！」と銘打ったSession1は、マクニカにおける新規事業開発の変遷紹介から始まりました。特筆すべきは、画像に「事業失敗の変遷」とあるように、苦い体験談も多分に含まれていることです。

まずはこの変遷について、簡潔にまとめました。

■IoTバズり期（2013年～2016年）
マクニカ社内で「新規事業をやりましょう」という動きが活発化する一方、製造業の分野で「インダストリー4.0」や「予知保全」が注目を浴びていた。マクニカはすかさずそこに着目し、大手工作機械メーカーと共同でセンシングやセンサーモジュールの受託開発などを行った。こうしてマクニカの新規事業開発は、製造業の分野から幕を開けた。

■マクニカ変革の狼煙期（2017年）
多様な新規事業の開拓をミッションとする事業部が発足。製造業IoTの探索活動を継続しつつ、約30名のデータサイエンティストを育成した。

■AIバズり期（2017年～2019年）
AIを活用したPoCの注目度が高く、多くの企業が多額の予算を投下していた。マクニカも「AIいかがでしょうか」といった謳い文句で、数百万の費用を要するPoCをあっさりと受注しつつ、300件以上のAI・デジタル分野での支援に成功。事業収益も十分でグロースフェーズまっしぐら……と思いきや、PoCだけでは収益が安定化しないうえ、肝心のシステムがなかなか社会実装されないことが、課題感として浮き彫りに。

■収益化・グロース期（2020年～）
紆余曲折を経て、「デザイン思考」「価値視点」といった概念や、その重要性の理解が進んだ。デザイナーチームの編成、データサイエンティストとシステム構築アーキテクト人材の融合など、ケイパビリティのアップデートを実行した結果、新たな価値の共創基盤サービス「Re:Alize」が誕生。ついに「PoC貧乏」から脱却し、パートナーとの共同開発や自社オリジナルプロダクト開発に挑み始めた。

ここまでが、過去の大まかな流れです。なにやら「めでたしめでたし」で終わりそうな雰囲気なのですが、この話にはまだ続きがありました。

次に問題となったのは、自社オリジナルプロダクトの開発です。

自社のアイデアによるゼロスタートの開発に不慣れだったメンバーは、市場のニーズや本質的な課題について議論を繰り返し、会議を重ねるたびに無限大に広がるロジックツリーを作っていました。さらに困ったことに、メンバーはこの状況において「課題の解像度、上がってるね！」と思っていたとか。

その結果、モノは一向に完成しないまま、なんと1年が経過してしまったのです。

ちなみにその1年のあいだには、SPEEDAやビザスクなどを使った調査も行っていました。各自のインプットが多くなりすぎたことも、何を作るかの判断が鈍ってしまった原因のひとつでした。

総じて、このケースにおける最大の失敗要因は「どのタイミングで、なにをつくるのか」という意思決定とスピード感を、長いこと醸成できなかった点だったと言えます。

「このままではいかん！」と思った本村は、この状況とメンバーのマインドを変えるため、ついに「新規事業開発における最強の攻略法」を編み出します。それが今回皆さまにもっともお届けしたい、「まずつくる」です。

マクニカにおける「まずつくる」の威力は、絶大でした。なにせ以前は1年経っても何もつくれなかったのが、とあるプロダクトでは3日で動くプロトタイプをユーザーに当て、1ヶ月後にリリースし、100名以上のユーザーがついたのですから。

次の項からは「まずつくる」も含めた、新規事業創出の話に移ります。

「まずつくる」から始める、新規事業創出の3つのポイント

ここからは、新規事業創出における3つのポイントを順番にご紹介します。

まずつくる

1つ目は、「まずつくる」です。私たちがこれこそがもっとも重要だと考えており、皆さまにも繰り返しお伝えしています。

そして実際に作るべきモノについては、主に下画像の3つを挙げています。これらは3つすべてを用意するのではなく、基本的には状況に応じていずれか1つを用意できるとよいでしょう。ちなみに、それぞれの要素は下記のように言い換えることができます。

■ワイヤーフレーム付きUI
画面遷移ができるUI

■最小限動作するシステム
ファンクショナルプロトタイプ

■集客用LP
WEBページ

 

たとえば、まずは下記画像のようなワイヤーフレーム付きのUIを用意するだけでも、ユーザーとの意識合わせ（会話）は非常に円滑になります。場合によっては用意できるのがプロジェクトの発足後になるかもしれませんが、本村はプロジェクト発足前に1週間程度でこれを用意し、スムーズな合意形成に至ったこともあるそうです。

▲ワイヤーフレーム付きUIの例その1。道路のヒビ割れをドライブレコーダーのカメラから、AIで自動判別するものです。

▲ワイヤーフレーム付きUIの例その2。プラントの劣化状態をドローンで撮影し、AIが自動で識別するものです。

また「最小限動作するシステム」では、業務日報の作成に1日数時間を要していたユーザーの課題に対し、ChatGPTを活用したアプリ（のプロトタイプ）を提案したケースが紹介されました。こういったモノの場合はワイヤーフレームではなく、実際に使ってみて本当に効果があるかを検証することが重要です。そのため、やはり「まずつくる」必要があります。

▲最小限動作するシステムの例。業務日報を音声入力すると自動でテキスト化され、さらに要約してくれるというものです。

なぜ「まずつくる」が大事？①

次に取り挙げられたのは、「まずつくる」が重要な理由についてでした。

本村は「仮説検証や、そこから得る学びは確かに大切ですが、仮説を立てるばかりでは前に進みません。まずつくることが必要なのです」と、自身の経験を交えて語りました。

さらに「まずつくる」ことで想定価値の解像度を上げ、それを情報整理や事業計画のアップデートに活用することも重要だと言えます。

なぜ「まずつくる」が大事？②

また新規事業開発においては社内外を問わず、関係者（ステークホルダー）とのコミュニケーションが不可欠となります。それをクリアするためにも、「まずつくる」は有効です。

新規事業開発の担当者は、基本的に限られたリソースのなかで、価値を提供したいドメインや、使いたい技術を関係者に逐一説明しなければなりません。しかし、説明された相手は、その内容になかなかイメージがつかないのが実情です。

この点は本村も過去に苦労しており、なかなか承認が得られなかった時期もあったとか。そこで、チームメンバーと作ったプロトタイプを関係者に見せながら「こういう世界観を目指したい」と話したところ、相手の態度が一変。「そうそう、それが最初からやりたかったんだよ！」と、あっさり承認を得られたそうです。

事業計画やロードマップには合理性のある説明を求められることが常ですが、そこに高い壁を感じている場合、「まずつくる」を試してみる価値は十分にあるでしょう。

なぜ「まずつくる」が大事？③

「大小を問わず、とりあえず成功体験をする」ことも、「まずつくる」が重要な理由として挙げられました。

企業の事業では新規・既存を問わず、売上などの目標がつきものですが、このとき新規事業の期待値を既存事業ベースで考えるのは、あまりよいことではありません。

たとえば、とある企業が「2030年までに100兆円規模の市場参入を目指しているから、新規事業でも大きいところを狙いたい」という方針を立てたとします。その場合、市場の探索活動まではできたとしても、事業運用に求められるシステムはおそらく非常に巨大なものであり、そのぶん開発投資も膨大になります。そしてこの企業が新規事業開発に不慣れな場合、ノウハウがない状態で、とてもリスキーな賭けに出なくてはならないのです。

そうならないためには、たとえ小さい市場でもユーザーに評価をしてもらい、あわよくばそのユーザーに良質な体験を提供するなどの成功体験を積み、来たる大きなチャンスに向けて備えることが大切です。そして、その小さな成功を獲得するためには、やはり「まずつくる」が欠かせません。

マクニカの場合

ポイント1の最後には「まずつくる」のタイミングや、マクニカでの取り組みが紹介されました。なお、マクニカで使用している新規事業開発用のテンプレートはこちらからダウンロードいただけますので、ぜひご活用ください（クリックですぐにダウンロードが始まります）。

▲中段に書かれた3つの項目を用意できたら、すぐにでも動き出したいところです。

▲本村のチームで使用している、新規事業開発用のテンプレートです。ここに必要最低限の情報を入力し、アイデアをチームメンバーに共有します。

▲実際に入力したところ。これは先述した、業務日報アプリのものです。このスライドを用意してメンバーに意見を求める行為も「まずつくる」の一環だと言えます。

コアシフト

新規事業創出における2つ目のポイントでは、「コアシフト」が紹介されました。まず下の画像は、新規事業やイノベーション創出を4象限で分類したものです。

私たちは新規事業の目的を「新規顧客の獲得」と考えているため、図の左上と右上の象限を目指すことになります。しかし右上の「ゼロスタート型」では自社のコア・コンピタンスについて文字通りゼロから考える必要があるため、挑戦のハードルは高いと言えます。

そこで検討したいのが、自分たちがすでに持っている、もしくは経験のあるコア技術やコアバリューを、新規顧客に提供する左上の「コア適用型」というわけです。

そして「コア適用型」を目指す際に、自社の業務改善で得た実績・ストーリー・価値などを他の業界にも適用できるかたちに落とし込むことを、私たちは「コアシフト」と呼ぶと同時に、新規事業推進の王道パターンだと考えています。

 

「コアシフト」については、マクニカが共創させていただいた2社の事例がピックアップされました。以下は、その概要を簡潔にまとめたものです。

SOMPOリスクマネジメント社

各種リスクに関するコンサルティングサービスを、工場や物流拠点などに提供している同社。物流拠点ではフォークリフトが使われており、死亡事故も含む労災事故が年間で約2,000件起きている一方、さまざまな要因で物流の増加が見込まれていた。対策をしなければ、事故のリスクが増えるおそれも。

そこでドライブレコーダーの映像をAIで分析し、AIが危険運転と判断した箇所をコンサルタントが注意喚起するサービスを導入。従来は危険運転の確認を目視で行っていたが、必要な時間が大幅に削減されるとともに、チェックの見逃しも減少。結果、リスクアセスメントできる件数が増え、ビジネスチャンスの拡大にもつながった。

たとえば、この危険運転診断アプリをドライブレコーダーのメーカーとタイアップし、さまざまな物流拠点にライセンス販売すれば、それは自社のケイパビリティを顧客に展開するコアシフトとなる。

 

コイワイ社

同社では、鋳造の試作事業を中心に手掛けている。

顧客からは見積もりや鋳造方案（設計図からモノを作るための計画）の依頼が寄せられるのだが、それにスムーズに応対できるノウハウは、限られた社員しかもっていなかった。一方で、100万点以上の過去案件の情報は残されていたことから、3Dを活用して過去の類似案件に対する検索ができるシステムを導入。結果、社内業務の削減や属人化の排除が実現し、受注に向けた提案件数が増加した。

このケースでは、たとえば同業他社に同様のシステムを展開（販売・共有など）することがコアシフトになる。

 

仮説指向事業計画法でコミット

3つ目のポイントは、「仮説指向事業計画法」の利用です。

新規事業開発においては、関係者に売上などの数字説明をしなければならない場面も必ず出てきます。しかし、社会変化が激しく予測困難なこの時代に「10年後に必ず◯億円になります」と確約することは、極めて困難でしょう。

そこで私たちは、ペンシルバニア大学の提唱している「DDP」こと、「ディスカバリードリブンプランニング（仮説指向計画法）」の使用を推奨しています。

 

「仮説指向計画法」では、最初に到達したい利益を設定し、そこから逆算をしていきます。具体的なやり方は、下記のようになります（①～⑨は、図左下の「仮説No」とは連動していませんのでご注意ください）。

①初年度目標利益は1億円を目指す（営業利益率は20％）
②必要な売上は5億円
③②より、許容原価は4億円
④製品（サービス）の価格は月額20万円（年間で240万円）
⑤④より、ユーザー（顧客）はおおむね200集めたい
⑥市場規模としては約1,000ユーザーを見込める
⑦⑥より、自社としては20％のシェアをとっていきたい
⑧15人分のサービス提供リソースが必要で、約1億5,000万円かかる
⑨200ユーザー到達時、クラウドのインフラコストが約5,000万円かかる

 

目標利益とそれを達成するための仮説を明確にできたら、次はその仮説を、開発マイルストーンのどこで検証するのかを明らかにします。

たとえば「利益率」や「月額20万円で本当に売れるのか（もっと高くてもよいのではないか）」という仮説は、プロダクト全体の利益に大きく影響するため、あらゆる過程で常に検証し続ける必要があります。

一方で「初年度200ユーザー獲得」という仮説は、ユーザーにつくったモノを当ててみたとき・本開発始動後・サービスリリース後・損益分岐点の到達時でそれぞれユーザーの反応を見て、達成の可否を随時検証する……といった具合です。

ここで重要なのは、新規事業開発担当者が関係者に対してコミットすべきは数字ではなく、あくまでも予定に沿った円滑な計画進行ということです。なぜなら、数字はあくまで仮説であり、マイルストーンの進捗に伴って変動する可能性を多分に含んでいるからです。

そのことを関係者に正しく理解してもらい、検証マイルストーンに沿ったブラッシュアップをしながら開発を進捗させるための手段が、この仮説指向計画法なのです。

本当は教えたくない、爆速でうまれた共創プロダクト事例

ここまでにお伝えしたとおり、やりたいことを前に進めるためには「まずつくる」が何よりも重要です。

さらに言えば、世の中には「まずつくる」から始めなければ、そもそも誕生しなかったサービスも多く存在します。そして、その分野を意図的に狙うことで「まずつくる」が加速するというのが私たちの経験則であり、タイトルを「本当は教えたくない」とした理由だと、本村は語りました。

以下は、マクニカが携わった共創プロダクトの一例です。

 

このように、本来の目的遂行に長い時間がかかる場合や、アプリなどを使うユーザーの置かれている状況によっても「まずつくる」は有効です。

講演まとめ

ここまでが、Session1「10年間の新規事業開発をジェットコースター体験！」の内容となります。本村は最後に下の画像を画面に写しながら、語りました。

出典：NVIDIA Omniverse Computing Platform for Building and Operating Metaverse Applications（NVIDIA）P.14（2023年7月27日に使用）

「下側の山登りは、いまつくっているものが受注残で、5 年後にこれぐらいの売上になりますという、モノ売りの状態を示しています。上側の子どもの波乗りは、我々が新規事業開発 を推進する過程で、乗ったこともないような波に乗ろうとしていることを示しています。私 たちも、きっとこの子どものように、何度も何度も失敗を繰り返しながらチャレンジするこ とになるでしょう。しかし決してあきらめずに、皆さまと一緒に新規事業開発を推進できれ ばと思っています。」

本ウェビナーでは、アンケートで多くの方に「大変勉強になりました」「経験に基づいて話されているのがすごくよく伝わってきました」などのご意見をお寄せいただきました。なか には新規事業開発における悩みが赤裸々に書かれたものもあり、皆さまの日々の努力と苦 労が、私たちにもひしひしと伝わってきました。

マクニカはそんな皆さまと同じ境遇をたどるパートナーとして、今後もお力添えをさせて いただくべく、新規事業開発に関わるさまざまな取り組みをいっそう強化してまいります。

新規事業開発お悩みQ&A

ここからは、ウェビナーのSession2（後半）にて実施したQ&Aの内容をまとめています（ウェビナー当日に回答しきれなかった質問も含みます）。

Q1. 自社サービス開発を進めています。少数のDX推進チームで開発を進めていますが、兼務者が多いためモチベーション維持、工数確保に課題を感じています。このようなケースを切り抜けたお話があればお聞かせください。

（森）
メンバーは「具体的ではないことは取り組みたくない」「時間をかけても評価されないのはつらい」と思いがちです。つまり、どういう未来が描けるのかであったり、その仮説検証内容を社内で具体的に共有することが重要だと言えます。何がしたいのかを情熱をもって語りかけることは、対社外だけではなく、対社内においても大切です。

（本村）
メンバーが、プロジェクトをいかに自分事として捉えられるかが重要です。また新規事業開発は意外と人事評価に影響を与えるのですが、既存事業と同じ軸で評価されてしまうのはよくないと考えています。
たとえば定量面の評価であればチャレンジした数、またエンジニアの場合はMVPを作り、ユーザーに宛てた数などを評価指標にするとよいです。一方、定性面の評価であれば、アウトプットの質（成功・失敗も含め）を明文化してみてはいかがでしょうか。

Q2. 「まずつくる」ことの重要性は認識するものの、「まずつくる」にも各種リソースを割かなければならないので、社内調整・説明が大変。推進するために、社内調整・説明で重要だと考えているポイントは何でしょうか？

（岩田）
少人数の仲間を作り、小さいレベルの「まずつくる」から入るのがよいかと思います。　それをもってお客様から反応があれば、社内調整も進みやすいかと思います。所属部署や企業によっては難しいかもしれませんが、なんとかお客様へのつながりを作るのが理想です。

 （森）
「まずつくる」を小さく始めてみることです。結局は何をするにも社内調整が必要なので、たとえば自分だけで何かをやってみて、その結果として顧客フィードバックがあれば、社内調整を進めやすくなると思います。その際につくるものはPPTのアイデアシート1枚でもよく、ワイヤーフレームまでいかずとも十分です。

（本村）
アメリカの論文でも、「企業がイノベーションを起こす際に重要なポイントは根回し。説得ルートの存在を確かめる」というものがあります。「最近リリースされた、面白いサービスがある」と言って紹介し、反応を見てみるのもアリですね。

Q3. どういうチームではじめるのがいいですか？　エンジニアとか必要ですか？

（森）
まず、最小限の人数（自分だけでも）で始めてみるのがよいかと思います。そのときにアサイン可能なメンバーで「何をつくれるのか」から考える方が、スピーディに動けます。

Q4. 「まずつくる」を実践するための体制と、パーソナリティーを教えてください。弊社内は保守的な人材が多いため失敗を恐れて開発スタートに踏み切れません。

（岩田）
体制には決まった形はないと思いますが、「課題を解決したい」と強く思っている、もしくは課題を中心に本質を捉えて動ける人材を、少なくとも一人は用意したいところです。そうでないと技術やHowのことが中心になり、そもそも課題が間違っているような空回りをしてしまうことが、私たちにはありました。
成功体験があれば保守的な人材も変わってくると思うので、まずはそれを積むことが大切です。たとえば、自分たちが顧客になるような身近なことから、小さな成功事例を作ってみてはいかがでしょうか。

（本村）
パーソナリティーは、失敗を学びと捉えることのでき、仮説検証をクイックに回せるマインドセットと、その失敗や学びを受容する組織風土や評価制度にあると思います。

Q5. 「すぐつくる」開発リソースはどのように確保するのか？　また「すぐつくる」ために許容される費用はどの程度なのか？

（岩田）
たとえば自分自身の工数など、確保しやすいリソースで最低限のものをつくり、顧客候補からステークホルダーを落として、追加で予算を確保するといった流れが理想かと思います。つまり、ベンチャー企業の資金調達と似たようなかたちですね。
費用はケースバイケースだと思いますが、仮説検証に必要な費用、会社の文化×事業のTAM/SAM/SOM、事業の確度でおおよそ決まるかと思います。基本的にはソフトウェアで実現できるもののほうが、初期費用はかからないと考えています。

Q6. ワイヤーフレームは社内展開がメインでしょうか。お客様との共有がメインで生まれた内容でしょうか。

（岩田）
両方ありますが、より効果があるのはお客様との共有です。ある事例ではお客様先で直接ホワイトボードに画面デザインを書いたこともありますし、紙に書いて、「これで体験として十分か」を検証したこともあります。
そのお客様はプロダクト自体は存在しない段階でしたが、導入に非常に協力していただけました。このようにお客様からのフィードバックをもとに、社内展開を図るのが効率がよいかと思います。

Q7. まず、作るで取り組んでいるのですが、DDP的な思考を持たないステークホルダーに説明するのが難しいです。

（岩田）
「確定的な事業計画をもってこい」というステークホルダーがいる場合、私はそういう相手とは真っ向からやりあわず、裏口から仕事を進めていました。その方が、うまく事が運びます。

（本村）
たとえば貴社が創業30年、売上規模500億円の会社だったとすると、貴社の新規事業は売上が500億円に到達するのに30年かかったことになります。
仮にDDP的な思考を持たないステークホルダーがいても、上記のような事実のもと、3年で既存事業レベルに到達せよといった指示・思考は、論理が破綻していると言わざるを得ません。「既存事業で30年かかったのだから、私たちにも30年ください」と言うのは極論ですが、その事実を共通認識とし、マイルストンごとの進捗で握ることが重要だと考えております。

Q8. 「すぐつくる」に必要なスキルは何か？

（岩田）
色々とありますが、特に重要なのは「課題の検証に必要最低限な要素を見極めるスキル」と「その最低限で顧客とやり取りできるスキル」です。
「技術的な検証が済んでいないと実現できない」と二の足を踏んでしまうようなこともあるかと思いますが、顧客に必要な体験を見極めるのには、システムを組まずに人力でプロトタイプするようなWoZプロトタイプで十分な場合もあります。また、ちょっとしたコンセプト資料でも十分だったりもします。
体験に価値があれば技術に投資する価値が十分にあると証明でき、あとから開発費用を得ることもできると思います。

Q9. いくつか出た仮説を絞り込む際、どういった評価基準や方法で絞り込まれていますでしょうか？　声が大きい方の仮説で良くあるのですが、夢のような仮説はPoCすら不可能な物が多く、困ることがあります。 今回、「まず作る（つまり、作れること）」が、1つの対策になるとは思いました。

（岩田）
いくつかのアプローチがありますが、「検証できたときの価値」「検証スピード（検証する準備ができている仮説か？）」「確からしさ」あたりで絞り込んでいます。また、その仮説の前提が別の仮説だったりすることもあるので、ツリーとして分解し、ちゃんと前提がなりたっているかも考えておく必要があるかと思います。

Q10. 顧客とのコネクションがない場合はどうすればいいでしょうか？

（森）
社内の営業と協力し、通常とは別のルートでコネクションを作ってみてはいかがでしょうか。また想定ユーザーのHPから問い合わせる、関連する業界の展示会に行くなどのアクティブな活動も有効です。まずは、お客様をつかまえるためにまず動くことが重要です。

Q11. 新しいケイパビリティ獲得のため、社内で育成、中途採用、もしくは社内にケイパビリティ持たず外注あると思いますが、それぞれどう使い分けされますか？

（岩田）
コアの部分は社内、それ以外は社外を活用していきたいというのが一般的かとおもいます。私たちは最初は外注でも、その部分がコアになりえるのであれば、技術移転をするようにしています。

（本村）
社内育成＝正社員である必要はなく、目的を達成するためであれば派遣・業務委託などを問わずに育成することが重要です。中途採用は難しいですね。

Q12. 新しい技術を使う際にセキュリティ等はどのように考えますか？

（岩田）
技術的にこなれてない段階では、セキュリティ要求の低い内容から小さく回すのが望ましいと考えています。一方でセキュリティ要求が高くても、それを満たす価値がある場合には、精度や機能をある程度犠牲にしてでも、投入データに制限するなど工夫をします。

Q13. 先ず作る、は良い手法で100％同意ですが、知的財産確保との関係で外部への露出をためらいますが、プロトタイプの管理はどのように管理されていますか？

（岩田）
内部の構成や技術に関しては、できるだけ秘匿したいと考えております。提供している体験をユーザーに当て、仮説検証できれば十分だからです。ただ、もし検証に必要であれば露出もやむなしです。また露出させないつもりでも、社内にすら漏れてしまうとなかなかコントロールができないため、そのあたりは私もいまだに悩んでいます。

Q14. 製品・サービスにするところまでハードルが高すぎるため、特許等で権利確保するような考え方についてはどのようにお考えですか？

（岩田）
回避されないようにコアの部分を抑えるには、製品・サービスがどうあるべきかを回避する側の視点で考える必要もあるかと思います。そこの検証までは求められないのでたしかにハードルは低いかもしれませんが、一方で知財で会社に利益をもたらすことは、とても難しい印象があります。私個人としてはつくったものをユーザーに当てることで新たな知見を得られるので、そちらの方が楽しいです。

Q15. HW（ハードウェア）では、物を作ってUserに提示することと、自動車や航空機で始まっているデジタルエンジニアリングとの得失は？

（岩田）
「何を検証するか」また「それにふさわしいインプットになるのか」ということだと思います。具体的には、「技術的な設計試作、検証をするのか？」や「顧客体験の検証をするのか？」などの要素が挙げられます。デジタルエンジニアリングは技術検証をスピーディに行うぶんには優れているかと思いますが、顧客体験の検証を行うには、不十分なことがあります。
また完成度が高く見えることで、検証してほしい課題ではなく細部に目がいってしまうという問題もあります。もちろんデジタルでもポイントを抑え、検証する仕組みがあればそれでも使えるかもしれません。

Q16. 仮説検証に必要な最低限のデモ画面(イメージ）を実際に具体化した際の問題点が想定外であった場合の対処は？　例えばBoeingのT-7Aはデジタルエンジニアリングで設計試作を進めていたそうだが、射出座席の要件を後で拡大（小柄な女性でもパイロットに採用）したところ、想定以上に開発スケジュールが遅延しているとのこと....

（岩田）
「まずつくる」の対象は仮説検証用を行うためのものであり、つくったものをそのまま商品化するわけではないため、その点はご留意いただけますと幸いです。また今回は新規事業開発が前提となりますので、既存の開発ロードマップがかっちり決まっているような事業では、違ったかたちになるかと思います。
ただご質問のケースは、おそらく検証すべき仮説が検証しきれていなかったのではないかと考えられます。

【仮説１】パイロットは今後も大柄な男性のみである
【仮説２】大柄な男性にとってT-7Aはこうあるべきである

という状況で、【仮説１】を検証せずに具体化してしまったというケースならば、大きな投資を行って具体化する前に要件を探索するか、小型のプロトタイプで検証してみるのが適切かと思います。

こちらもおすすめ！お役立ちコンテンツ

【事前準備ナシ＆業界不問】新規事業開発の悩みを突破せよ！なんでも壁打ち無料相談会！

【お役立ち資料】 DXプロダクト開発が前に進まないあなたに

Hello！ Re:Alize ～新たな価値の共創基盤～