社内ベンチャー新規事業のシステム化｜コンテスト後の進め方
社内の新規事業コンテストで選ばれたアイデアを、動くシステムにするまでの進め方を整理します。審査用の資料を開発の入口に変える作業、体制の決め方、最初に作る範囲と確かめる指標、決裁者への見せ方の順に説明します。社内ベンチャーとして新規事業のシステム化に取り組むとき、どこで止まりやすいかを事前に確認できる内容です。
社内ベンチャーのコンテスト後に、アイデアが止まりやすい理由
社内ベンチャーとは、会社の中で新規事業を立ち上げる仕組みや、その担当チームのことです。入口として新規事業コンテストを設ける会社は少なくありません。ただ、コンテストで選ばれることと、事業が実際に動き出すことの間には、思いのほか距離があります。
私たちは、止まりやすい場所を大きく二つに分けて考えています。
審査用の資料は、開発の入口として足りない
コンテストの資料は、審査員に「面白い」「市場がありそうだ」と思ってもらうための資料です。課題、市場の見立て、解決策のイメージが中心になります。
一方、システムを作るには、次のような具体的な情報が必要です。
- 誰が、どの画面で、何をするのか
- システムはどんなデータを持つのか
- 利用者が増えたとき、お金はどこで発生するのか
- 最初の利用者は誰で、どこにいるのか
審査用の資料にこれらが書かれていることは多くありません。そのまま開発会社に相談すると、会話が「何を作るのか」を決める作業から始まります。悪いことではありませんが、準備なしに始めると、認識の食い違いが後から出やすくなります。要件を整理する考え方は、要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方でまとめています。
本業との兼務と、社内の決裁の速度
選ばれた担当者が、本業と兼務で進めるケースも多くあります。社内にエンジニアがいない会社もあります。その場合は、新規事業でエンジニアいない会社の進め方のように、開発の進め方そのものを先に考える必要があります。
さらに、開発に進むには社内の決裁が要ります。コンテストの審査は「アイデアの評価」ですが、決裁で問われるのは「何ができあがり、何が確かめられるのか」です。評価の軸が変わることを、受賞の時点で意識しておくと、次の動きが楽になります。
アイデアを「確かめる順番」に分解する
システム化の第一歩は、画面や機能を考えることではありません。アイデアを、確かめるべき仮説に分けることです。
事業の仮説を一枚に書き出す
仕様の議論に入る前に、次の項目を一枚にまとめてみてください。専門的な書式は要りません。箇条書きで足ります。
- 誰の、どんな困りごとを解決するのか
- その人は今、その困りごとをどうやってしのいでいるのか
- 新しい手段によって、利用者の行動はどう変わるのか
- 誰が、何に対して対価を払うのか
- 最初の利用者を、どこで見つけるのか
- 事業として続けるうえで、いちばん不確かなことは何か
最後の項目が特に重要です。新規事業でいちばん不確かなのは、多くの場合「作れるかどうか」ではなく、「使ってもらえるか」「対価を払ってもらえるか」です。何を確かめたいのかが決まれば、最初に作るシステムの範囲も自然に絞られます。確かめ方の具体的な手順は、新規事業のアイデア検証方法｜動くシステムで確かめる手順で説明しています。
システムが事業そのものなのか、事業を支える道具なのか
次に、システムの位置づけを確認します。
- システムが事業そのもの：マッチングサービス、サブスクリプション型のサービス、SaaS（インターネット経由で提供するソフトウェア）など。画面や仕組みが、そのまま顧客に届く価値になります。
- システムが事業を支える道具：既存のサービスや営業活動を補助するもの。
この記事は、前者のように、システムを軸に事業をつくる場合を主に想定しています。この場合、システム化は「事業が決まったあとの作業」ではありません。システムの設計がそのままビジネスモデルの設計になります。考え方は新規事業のシステム設計とビジネスモデルの作り方に詳しくあります。
事業の種類ごとに、最初に決めることは少しずつ違います。マッチングサービス開発の進め方、サブスク新規事業のシステム開発、SaaS新規事業の開発も参考になります。
体制を決める：誰が決め、誰が作るのか
仮説の整理と並行して、体制を決めます。ここが曖昧なまま開発に入ると、途中で判断が止まりがちです。
開発の判断をする人を、一人置く
開発が始まると、細かな判断が次々に出てきます。「この項目は必要か」「この画面の順序はこれでよいか」といった判断です。その都度、関係者全員の合意を取っていると、進みません。
そこで、発注側で「何を作るかを決める人」を一人置きます。いわゆるプロダクトオーナーです。役割と判断のしかたは、発注側のプロダクトオーナーとはで整理しています。コンテストの提案者がそのまま担うことが多いですが、決裁者との橋渡しができる人であることも大切です。
経営陣と現場のズレは、目的ではなく進め方で起きる
社内ベンチャーでは、経営陣と現場が同じ目的を見ているのに、話が噛み合わないことがあります。多くの場合、ズレているのは目的ではなく進め方です。
経営陣は、投資の判断材料を求めます。現場は、早く動いて市場の反応を見たいと考えます。判断の材料と進める速度が違うので、お互いに「慎重すぎる」「性急すぎる」と感じてしまいます。この構図は、新規事業で経営陣と現場がすれ違う原因は進め方のズレで詳しく取り上げています。
解決の方向は、判断に使える実物を早めに用意し、同じものを見ながら話すことです。両者が同じ画面を前にすると、議論が「想像」から「確認」に変わります。
内製か外注か、既存システムとの距離
開発を誰が担うかも、この段階で考えます。社内に開発体制があっても、本業のシステムの優先順位が高く、新規事業に手が回らないことがあります。判断の軸は、内製と外注どちらがいい？新規事業システムの判断軸に整理しました。
あわせて、新規事業のシステムを既存システムとどう切り離すかも検討します。既存システムと直接つなぐと、新規事業の変更のたびに本業側の調整が必要になり、速度が落ちます。切り離す理由と進め方は、新規事業は既存システムと切り離して作る理由と進め方にあります。
外部の開発会社に相談する場合は、事業アイデアの扱いも決めておきます。秘密保持の項目は、システム開発のNDA｜秘密保持で決める8つの項目で確認できます。
最初に作る範囲と、確かめる指標を決める
体制が見えてきたら、最初に何を作るかを決めます。ここでの考え方は「全部を作らない」です。
機能は、確かめたい仮説に必要なものだけにする
コンテストのアイデアには、あれもこれもという期待が詰まっています。しかし、最初から全機能を作ると、時間も判断も重くなります。
目安は、「いちばん不確かなこと」を確かめるのに必要な機能だけを作ることです。たとえば、利用者が登録して使い始めるかが不確かなら、登録から最初の利用までの流れに絞ります。管理画面や細かな設定機能は、後回しにできることが多くあります。
機能の絞り方はMVP開発の機能の絞り方｜最初に作るものと後回しの基準、管理画面の扱いは新規事業の管理画面開発｜最初に作る範囲の見極め方が参考になります。
なお、「プロトタイプ」「MVP」「モック」は混同されやすい言葉です。MVPとは、顧客に価値が届くかを確かめるための最小限の製品のことです。何を目的に、どの段階で使い分けるかは、プロトタイプとMVP・モックの違いを整理で確認できます。
判断基準は、作る前に決める
作ったあとに「結果をどう読むか」を決めると、どうしても都合のよい解釈をしがちです。そのため、検証の指標は先に決めておきます。
- 何を見れば「続ける」と言えるのか
- どの状態なら「作り直す」のか
- どの状態なら「やめる」のか
指標の作り方は、MVP検証の指標を先に決める方法で説明しています。「やめる」基準を決めておくことは後ろ向きに見えますが、むしろ次の投資判断を早く、納得感のあるものにします。基準の考え方は、新規事業の撤退判断｜プロトタイプで「やめる」と決める基準にあります。
利用者の反応を確かめる準備もしておく
動くものができたら、想定する利用者に触ってもらいます。このとき、何を聞くかで得られる情報の質が変わります。質問の作り方や進め方は、プロトタイプのユーザーテスト｜新規事業での確かめ方と質問にまとめています。
決裁者に「動く実物」で見せる
コンテストで選ばれたあとも、開発の予算や体制をめぐって、改めて社内の決裁が必要になります。ここで企画書だけに頼ると、コンテスト審査の再現になってしまいがちです。
企画書だけでは伝わりにくいこと
企画書は、考えを整理するには優れた形式です。ただ、「何ができるのか」「使うとどう感じるのか」までは、文章や図では伝えきれません。決裁者が判断に迷うのは、アイデアが悪いからではなく、判断の材料が足りないからということもあります。理由は新規事業の決裁を企画書だけで取るのが難しい理由で整理しました。
動く実物があれば、決裁者は自分で触って判断できます。稟議の場でも、「この画面でこういう操作ができる」と見せられるので、質問が具体的になります。使い方のコツは稟議を通すシステム開発｜プロトタイプの使い方にあります。
実物を見ながら話すことには、認識のズレを減らす効果もあります。言葉だけで要件を決めると、完成後に「思っていたものと違う」となりやすいからです。実物を触りながら「ここはこう」と指摘できれば、違いを早い段階で直せます。詳しくはシステム開発の認識のズレを防ぐ、実物を見ながらのすり合わせをご覧ください。
全体の流れを並べると
ここまでの内容を、順番に並べてみます。
- 審査用の資料から、事業の仮説を書き出す
- 「いちばん不確かなこと」を決める
- システムが事業そのものか、道具かを確認する
- 判断をする人と、開発を担う体制を決める
- 確かめたいことに必要な範囲だけを決める
- 検証の指標と、続ける・やめるの基準を決める
- 動くものを作り、利用者と決裁者に見せる
- 結果を見て、次の投資を判断する
この順番の目的は、大きな投資の前に、小さく作って確かめることです。考え方は新規事業の開発は小さく作って確かめる投資判断の進め方で詳しく取り上げています。
本開発に進むとき、作り直しになるのか
動くものを作って確かめたあと、「本開発では全部作り直しになるのでは」と心配する声もあります。引き継げる部分と見直す部分は、作り方によって変わります。判断のポイントはMVPから本開発は作り直し？引き継げる部分と見直す点で整理しています。
また、AIを活用した開発では、試作までの進め方が従来と変わりつつあります。何が変わり、人は何を判断するのかは、AI駆動開発で新規事業の立ち上げはどう変わるかで説明しています。
まとめ
社内の新規事業コンテストで選ばれたアイデアを、動くシステムにするまでの進め方を整理しました。要点は次のとおりです。
- 審査用の資料は、開発の入口としては情報が足りないことが多い。まず事業の仮説に分解する
- いちばん不確かなことを決めると、最初に作る範囲が絞れる
- システムが事業そのものになる場合、システム化は事業設計と切り離せない
- 判断をする人を一人置き、経営陣と現場が同じ実物を見ながら話せる形にする
- 検証の指標と、続ける・やめる基準は、作る前に決める
- 決裁は、企画書だけでなく、動く実物を使って進める
コンテストの熱量が冷める前に、最初の一歩を小さく踏み出せるかどうかが、その後を左右します。
JustFitは、株式会社LEGAREAが運営する受託開発サービスです。「先に作って、後から決める」という考え方で、構想をもとに約1ヶ月で実際に動くプロトタイプを開発します。実物を見てから、契約するかどうかを判断できます。仕様が固まっていない段階や、稟議を通す前の段階でも相談でき、システムを軸にした事業の形まで一緒に考えることができます。サービスの詳細はJustFitのサービス紹介をご覧ください。