1. JustFit
  2. ブログ
  3. 新規事業のクローズドβ|進め方と公開範囲の決め方

新規事業のクローズドβ|進め方と公開範囲の決め方

JustFit編集部(運営:株式会社LEGAREA)

新規事業のシステムは、完成してから一斉に公開するより、限られた相手に先に使ってもらうほうが、判断の材料を早く集められます。この記事では、クローズドβ(参加者を限定した試験公開)の進め方と、誰に・何を・どれだけの期間公開するかの決め方を整理します。業種やサービスの形によって調整が必要な点も、あわせて書きます。

クローズドβとは何か:新規事業で小さく公開する意味

クローズドβとは、招待した人など、参加者を限定してシステムを実際に使ってもらう試験公開のことです。誰でも参加できる「オープンβ」と違い、参加者の数や属性、公開する機能を運営側が決められます。

ただし、この言葉の使い方は会社やサービスによって幅があります。この記事では、実際の利用環境で、限られた相手に、期間を区切って使ってもらうことをクローズドβと呼びます。

プロトタイプの確認とクローズドβの違い

新規事業では、クローズドβの前にプロトタイプ(動く試作品)での確認を行うことが多くあります。両者は似ていますが、確かめられることが違います。

  • プロトタイプでの確認:画面や流れを見てもらい、「何ができるのか」「使い方は分かるか」を確かめる。短時間の対面やオンラインの場で行うことが多い
  • クローズドβ:参加者が自分の業務や生活の中で、日をまたいで使う。「使い続けるか」「他の手段より選ばれるか」「運営は回るか」を確かめる

プロトタイプとMVPの位置づけについては、プロトタイプとモックアップ・MVPの違い|新規事業の使い分けで整理しています。プロトタイプの見てもらい方は、プロトタイプのユーザーテスト|新規事業での確かめ方と質問が参考になります。

クローズドβでしか分からないこと

実際に使われる環境で、時間をかけて試すことで、次のような点が見えてきます。

  • 最初の数回だけでなく、継続して使われるか
  • 想定していなかった使い方や、つまずく場面はないか
  • データの入力や連絡など、運営側の手間はどれくらいか
  • 問い合わせや障害が起きたとき、現実に対応できるか
  • お金のやり取りを伴う場合、その流れが成り立つか

企画書や試作品では「良さそう」で終わることも、実際に使われる場面では違う結果になることがあります。クローズドβは、その違いを事業を広げる前に確認するための手段です。

先に決めること:目的と判断基準

クローズドβで起きやすいのは、「とりあえず公開してみたが、何を見ればよいか分からない」という状態です。公開の準備を始める前に、確かめたいことと、その結果を見てどう動くかを決めておきます。

確かめたい仮説をひとつに絞る

新規事業には確かめたいことがいくつもありますが、一度に全部は確かめられません。たとえば、次のような形で仮説を一文にします。

  • 「この業務を担当する人は、今の手作業の代わりにこのシステムを継続して使う」
  • 「利用者同士が、この仕組みで実際に取引や連絡を始める」
  • 「担当者は、週に一度はこの画面を開いて数字を確認する」

仮説が複数ある場合は、事業が成り立つかどうかに最も強く関わるものを優先します。残りは次の段階に回します。

見る指標と、続ける・変える・やめるの線引き

仮説が決まったら、それを確かめる指標を決めます。登録数のように増えやすい数字より、継続利用や、目的の行動が実際に行われたかなど、仮説に直接つながる数字のほうが判断に使えます。

そのうえで、公開前に次の三つの結果を想定しておきます。

  • 続ける:どの水準なら、範囲を広げる検討に進むか
  • 変える:どの結果なら、機能や対象を見直してもう一度試すか
  • やめる:どの結果なら、撤退を検討するか

基準を公開後に決めると、結果に合わせて解釈してしまいがちです。指標の決め方はMVP検証の指標を先に決める方法|判断基準の作り方、やめる判断の考え方は新規事業の撤退判断|プロトタイプで「やめる」と決める基準で詳しく扱っています。

公開範囲の決め方:4つの軸

公開範囲は「何人に公開するか」だけで決まるものではありません。私たちは、次の4つの軸に分けて考えると整理しやすいと考えています。

軸1:誰に使ってもらうか

最も重要なのは参加者の選び方です。人数よりも、仮説に合った人かどうかを優先します。

  • 実際にその課題を抱え、今は別の方法で対処している人
  • 将来、事業の顧客になる可能性のある属性の人
  • 率直な感想を伝えてくれる関係の人

注意したいのは、友人や知人だけで固めてしまうことです。好意的な評価が集まりやすく、事業としての手応えを誤って捉えるおそれがあります。顧客になり得る属性の人を、意図して入れておきます。

人数は、フィードバックを一件ずつ読んで対応できる規模が一つの目安です。数字そのものに決まりはありません。仮説に照らして、傾向が見える最小限の人数を考えます。

軸2:どの機能を公開するか

公開する機能は、仮説を確かめるために必要なものに絞ります。ほかの機能が未完成でも、仮説の確認に関係しなければ、後回しで構いません。

機能の絞り方は、MVP開発の機能の絞り方|最初に作るものと後回しの基準で扱っています。管理画面を作る場合の範囲の考え方は、新規事業の管理画面開発|最初に作る範囲の見極め方が参考になります。

絞る際は、「使い始められるまでの流れ」と「仮説に関わる中心の機能」が一通りつながっているかを確認します。途中で止まる状態だと、参加者の評価が「機能が足りない」で終わってしまい、本当に確かめたいことに届きません。

軸3:どれくらいの期間、どの規模で行うか

期間は、仮説の確認に必要な時間から逆算します。たとえば、週に一度使うことを想定した仕組みなら、数回分の利用が見られる期間が必要です。一方で期間を長くしすぎると、改善を続けるうちに検証の区切りが曖昧になります。

おすすめは、開始時に終了日と、結果を振り返る日を決めておくことです。延長する場合も、延長の理由と新しい基準を決めたうえで行います。

軸4:情報をどこまで外に出すか

限定公開でも、情報が外に出る可能性はあります。参加者にはシステムの画面や仕組み、事業のアイデアが見えるためです。

  • 招待制にして、参加者を把握できる状態にする
  • 利用規約や参加条件で、秘密保持や情報の取り扱いを明記する
  • 公開してよい情報と、見せない情報を分けておく

秘密保持の項目は、システム開発のNDA|秘密保持で決める8つの項目で整理しています。参加者の人数が多いほど個別の契約は難しくなるため、規約で整える範囲と、個別に結ぶ範囲を分けておくと運営しやすくなります。

段階的に広げる考え方

4つの軸を決めたら、一度で決め切らず、段階的に広げる前提で考えます。

  1. 関係者のみ:社内や近い関係者で、動作の大きな問題を確認する
  2. 少人数の招待制:顧客になり得る人に、中心の仮説を確かめてもらう
  3. 範囲を広げた限定公開:属性や人数を増やし、傾向が変わらないかを見る
  4. 一般公開の検討:運営体制やサポートの見通しが立ってから判断する

各段階で「次に進む条件」を決めておくと、範囲を広げるタイミングで迷いにくくなります。

クローズドβの進め方:準備から判断まで

公開範囲が決まったら、実施の流れを整えます。

手順1:最低限の準備を整える

クローズドβでも、実際に人が使う以上、最低限整えておくべきことがあります。

  • 利用規約と参加条件:試験公開であること、データの扱い、中止や変更の可能性を明記する
  • 個人情報の取り扱い:個人情報を扱う場合は、個人情報保護法に沿って、利用目的の通知や公表などを行う
  • 問い合わせの窓口:不具合や質問を受ける連絡先と、返答の担当者を決める
  • 認証と権限:参加者以外が入れないようにし、見られる情報の範囲を確認する
  • データの扱い:終了後にデータを残すか、削除するかを、参加者に伝えておく

お金を受け取る検証を行う場合は、事業の形によって、特定商取引法などの法令への対応が必要になることがあります。判断に迷う場合は、専門家に確認するのが確実です。決済まわりの作り方は、新規事業の決済システム開発|外部サービスと自作の分け方で整理しています。

データの持ち方は、後から変えにくい部分です。新規事業のデータ設計|最初に決めたい5つの持ち方も、公開前に目を通しておくと安心です。

手順2:参加者に目的と約束事を伝える

参加者には、次の点を最初に伝えます。

  • 試験公開であり、不具合や仕様変更があること
  • 期間と、終了時にどうなるか
  • 感想や要望をどこに、どのように伝えてほしいか
  • 公開してはいけない情報(画面の共有や投稿の可否など)

目的を共有すると、参加者は「完成品の評価」ではなく「事業をつくる協力者」として関わりやすくなります。フィードバックの質も上がります。

手順3:使われ方を見て、声を聞く

公開中は、数字と声の両方を見ます。

  • 数字:利用の頻度、継続、途中でやめた場所など、仮説に関わる動き
  • 声:数字の背景を知るための短い聞き取り

数字だけでは、なぜ使われなかったのかが分かりません。反対に、声だけでは、実際の行動と言っていることが違う場合を見落とします。両方を合わせて見ることで、判断の精度が上がります。

意見が集まったら、仮説に結びつくものと、そうでないものに分けます。すべてに対応しようとすると、検証の対象がぼやけます。追加の要望をどう受け止めるかは、システム開発の仕様変更への対応|追加要望の扱い方が参考になります。

手順4:決めておいた基準で振り返る

終了日に、事前に決めた基準と結果を並べて振り返ります。

  • 仮説は確かめられたか
  • 想定と違った点は何か、その原因は何か
  • 続ける・変える・やめるのどれにするか
  • 続ける場合、次の段階の範囲と条件は何か

この場には、事業を決める立場の人と、現場で動かしている人の両方が同席するのが望ましいです。同じ数字と同じ画面を見ながら判断すると、認識のズレが生まれにくくなります。経営陣と現場の見方が分かれる背景は、新規事業で経営陣と現場がすれ違う原因は進め方のズレで書いています。

よくある失敗と防ぎ方

クローズドβで起きやすいつまずきと、その防ぎ方をまとめます。

参加者が偏り、好意的な声だけが集まる

友人・知人中心だと、否定的な意見が出にくくなります。顧客になり得る属性の人を意図して入れ、使わなくなった人にも理由を聞きます。

公開後に機能を足し続けてしまう

要望に応えるうちに、何を確かめているのか分からなくなることがあります。公開中は、仮説に関わる修正と不具合の対応を優先し、それ以外は次の段階の候補として記録しておきます。

終わりを決めずに続けてしまう

期限がないと、「もう少し様子を見る」が続きます。開始時に終了日と判断の場を決め、延長するときは理由を明文化します。

作り込みが足りず、評価できない状態になる

最低限の流れが途中で止まると、参加者が使い続けられず、仮説を確かめられません。中心の流れが最後までつながることを、公開前に確認します。逆に、作り込みすぎて時間がかかり、公開が遅れるのも避けたい点です。

既存の仕組みに影響が出る

新規事業のシステムが、既存の業務システムやデータと絡むと、試験公開で影響が出ることがあります。切り離して作る考え方は、新規事業は既存システムと切り離して作る理由と進め方で扱っています。

結果が出た後の動きが決まっていない

「続ける」と決めても、本開発をどう進めるかが決まっていないと、勢いが止まります。作ったものを引き継げる部分と見直す部分は、MVPから本開発は作り直し?引き継げる部分と見直す点で整理しています。

また、PoCのまま止まってしまう例については、PoC失敗で終わる新規事業の共通点と本開発への進み方が参考になります。

小さく試す投資判断としての位置づけ

クローズドβは、事業全体の投資判断の中の一つの検証段階です。小さく作って確かめ、結果を見て次に進むか決める全体の流れは、新規事業の開発は小さく作って確かめる投資判断の進め方にまとめています。

まとめ

新規事業のシステムを小さく公開するクローズドβは、実際に使われる環境で、事業に関わる仮説を確かめるための方法です。要点は次の通りです。

  • クローズドβは、参加者を限定し、期間を区切って実際の環境で使ってもらうもの。プロトタイプの確認では分からない「継続して使われるか」「運営が回るか」を確かめられる
  • 公開前に、確かめたい仮説をひとつに絞り、見る指標と、続ける・変える・やめるの基準を決めておく
  • 公開範囲は「誰に」「どの機能を」「どれくらいの期間・規模で」「情報をどこまで出すか」の4つの軸で決める。関係者から少人数、限定公開へと段階的に広げる
  • 利用規約、個人情報の扱い、問い合わせ窓口、認証などの最低限の準備を整えてから公開する
  • 参加者の偏り、機能の追加し続け、終わりを決めないことなどが、よくある失敗。事前の決めごとで防げる

こうした進め方を実際の開発につなげる場面では、動くものを早く用意できるかどうかが、検証の速さを左右します。JustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に開発し、実物を見てから契約を判断できる受託開発サービスです。仕様が固まっていない段階や、稟議の前の段階でも相談できます。クローズドβにつなげる範囲の考え方も含めて、JustFitのサービス紹介をご覧ください。

← ブログ一覧へ