事業化前後の検証・判断をつなぐ、新規事業制度を設計

「売れるか」を本開発前に確かめ、リリース後も売上だけで判断しない。

支援対象：大手企業・新規事業推進事務局
支援領域：制度設計・案件マネジメント
支援の到達点：制度・雛形を整備し社内説明を実施。詳細設計・運用準備へ

制度に沿って新規事業を進めても、購入や販売方法、採算を十分に確かめないまま本開発へ進んでしまう。
リリース後も、売上に問題が表れてから対応を考える。
ビジノベは、事業化前の検証段階と審査基準、事業化後の点検方法をつなぐ制度を設計しました。
雛形の整備と社内説明を経て、クライアント社内で詳細設計と運用準備を進めている事例です。

課題｜リリース前に、顧客が購入するかを検証していなかった

既存制度では、顧客課題と解決策を検討した後、ビジネスモデルが成り立つかを確かめる段階が十分に設けられていませんでした。
顧客ニーズを確した後は本開発・リリースへ進んでしまい、価格や利益の見通し、営業・マーケティングの方法は、リリース後に検証することになっていました。

顧客ニーズがあったからといっても、実際に顧客が購入するとは限りません。
顧客の実在性や購入動機、ビジネスモデルの前提を十分に確かめないまま進めるような制度になっていることが課題で、リリース後も収支計画の進捗以外に事業の状態を捉える手段が乏しく、問題への対応が後手になりがちでした。

設計の転換点｜本開発前に、ビジネスモデルの検証段階を新設する

ビジノベは、既存制度の段階区分と確認項目を見直し、顧客課題・解決策の確認に加えて、本開発前に購入・販売・採算の仮説を検証する段階を新設しました。

検証に必要な最小限の機能を持つ製品・サービスであるMVPを用い、有償PoCやテスト販売で確かめる設計です。
課題が解決されるか、従来の方法より効果が高いか、その効果が顧客にとってどのような価値になるかを検証します。

さらに、顧客が対価を支払うか、いくらで受け入れられるか、どのような顧客へどう販売すればよいかを検証します。
初期の顧客ターゲットと、営業・マーケティングの流れも仮説として確かめ、事業計画に反映する構成としました。

支援｜各段階での検証項目と、審査基準をそろえる

検証段階の追加とあわせて、審査項目と判断基準も見直しました。
課題検証の段階では誰がなぜソリューションを必要とするか、解決策検証の段階ではソリューションで課題を解決できるか、ビジネスモデル検証の段階では購入・販売・採算などビジネスモデルに関する前提を確認するようにします。

段階ごとに検証すべき内容と、次の段階へ進む判断として審査基準を整理することが狙いです。
担当者は次に何を検証すべきかが明確になり、事務局や責任者は何を確認し、どこで再検証を求めるかを考えられる。
両者が同じ観点で議論できるようにするための制度を設計しました。

リリース後｜売上に関連する先行指標から、事業状況を点検する

リリース後は、見込み顧客が商談・受注へ至る「営業ファネル」にも着目しました。リードを計画どおり獲得できているか、問題があるならば早期に把握し改善策を検討する設計です。

例えば、リード数が少ない場合と、接点はあるものの商談・受注へ進まない場合を分け、活動量の不足なのか、対象顧客や提供価値のズレなのかを点検する設計です。
リード数だけで原因を決めず、各段階の状況を案件アセスメントにつなげ、必要な見直しを検討する構成としました。

対象顧客の設定に問題があった場合は、営業を増やしても効果が弱いので、顧客ターゲットの見直しを含む検証を行います。
このように案件アセスメントの結果から、原因を分析し、次の仮説検証と支援へつなげることを、運営の仕組みに組み込みました。

到達点｜制度・雛形を整え、社内での詳細設計と運用準備へ

社内説明では、案件の評価観点が整理されたことについて、事業部の責任者から肯定的な反応がありました。
経験から感じていた問題を、担当者と共有し、具体的な検証や見直しへつなげるための手立てが整理されたためです。

売上進捗だけでなく顧客検証の根拠も確認し、案件を支援・判断するという考え方が共通の理解となりました。
制度と雛形の整備、社内説明を経て、現在はクライアントが詳細設計と運用準備を進めています。

本事例は、制度の設計・雛形整備と社内説明を終え、運用準備を進める段階の取り組みです。
事業化前の検証と事業化後の点検をつなぎ、次の仮説検証と判断へ結びつける構成を具体化しました。