ベータテストとは?アルファテストとの違い、クローズド/オープンの選び分け、参加者の集め方と終える判断【2026年版】

「リリース前にベータ版を出しましょうと言われたのですが、誰に、何人に、どのくらいの期間出せばいいのでしょうか」——システム開発を発注している方から、こうした相談をよく受けます。趣旨は分かる。社内のテストだけでは不安も残る。それでも、未完成のものを外部に出す判断を自分の責任で下すには、根拠になる数字が何もない。上司に「なぜ100人なのか」と聞かれて答えられず、そこで検索の手が止まります。

結論から言うと、ベータテストとは、開発が一段落したソフトウェアを、開発者の関与しない場所で、実際の利用者に使ってもらう検証です。開発者の側で行うアルファテストとは、この一点で分かれます。目的は不具合を拾うことだけではありません。むしろ、社内では誰も思いつかなかった使われ方を見つけることのほうが、ベータでしか得られない情報です。

ただ、発注者にとって本当に大事なのは語義ではないと考えています。ベータを組むときに決めるのは、誰に出すか、何人に出すか、どのくらい続けるか、返ってきた声をどう並べ替えるか、どこで終えるかの5つです。とくに最後の「どこで終えるか」を開始前に文章にしていないベータは、終わらないベータになります。リリース日か、担当者の疲労のどちらかで終わることになるのが実情です。

本記事では、ベータテストの定義とアルファテストとの違い、クローズドベータとオープンベータの選び分け、参加者の集め方と人数の決め方、期間とフィードバックの優先順位づけ、参加者との取り決め(守秘義務・免責・データの扱い)、そしてベータを終える判断の順に解説します。受け入れテスト(UAT)の進め方と合格基準の決め方、テスト工程そのものを外部に委託する話、開発手法の選び方は、本記事では扱わず、それぞれ既存の記事に譲ります。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。相談のなかで意外に多いのが、「ベータで出た要望を全部直していたらリリースが延びる。どこで切ればいいのか」という声です。ベータは、テストという名前がついていますが、実態は運用です。この記事を読み終えるころには、開始前に何を文章にしておくべきかが決められるはずです。

ベータテストとは——開発者の手の届かない場所で、実際の利用者に使ってもらう検証

ベータテストとは、開発が一段落したソフトウェアを、開発者が関与しない外部の場所で、実際の利用者(あるいはその候補)に使ってもらう検証です。社内のテストが「作ったとおりに動くか」を確かめる作業だとすれば、ベータテストは「実際にどう使われるか」を見る作業にあたります。見るものが違うので、社内テストを何周しても代わりにはなりません。

ベータテストの定義——「外の場所で、実際の利用者が、実際の使い方で」

ソフトウェアテストの国際的な資格認定団体である ISTQB(International Software Testing Qualifications Board)の用語集は、ベータテストを次のように定義しています。開発者と関わりのない外部の場所で、潜在的な利用者や既存の利用者が行う運用テストであり、その目的は、対象のコンポーネントやシステムが利用者・顧客のニーズを満たし、業務プロセスに収まるかどうかを判定することである、という趣旨です(ISTQB Glossary、確認日 2026-09-15)。

定義の要点は3つに分解できます。場所が外であること、使う人が実際の利用者であること、そして見ているのが「業務や生活に収まるか」であることです。3つ目が抜け落ちている記事が多いのですが、ここがベータの核心です。不具合を拾うだけなら、社内のテストと自動テストのほうが速くて安上がりです。ベータでしか手に入らないのは、社内の誰も思いつかなかった使われ方の情報です。

なお、限られた利用者に早く出して仮説を確かめるという意味では MVP(実用最小限の製品)と似て見えますが、目的が違います。MVP は「そもそもこの機能に需要があるか」を確かめるもの、ベータは「作ったものが実際の環境で成立するか」を確かめるものです。MVP の作り方は「MVP開発」の記事で扱っています。

アルファテストとの違いは、場所と関与者——段階の対比表

ベータテストと対になるのがアルファテストです。同じく ISTQB Glossary は、アルファテストを「開発者の側(developers' site)で行われる、潜在的な利用者・顧客または独立したテストチームによる、模擬的または実際の運用テスト。ただし開発組織の外部の人が行う」という趣旨で定義しています(確認日 2026-09-15)。

つまり、アルファとベータの分かれ目は完成度の高低ではなく、どこで、誰が使うかです。「アルファ=社内、ベータ=社外」という説明はおおむね当たっていますが、正確には「アルファ=開発者の場所で、開発組織の外の人が使う」「ベータ=開発者のいない場所で、実際の利用者が使う」です。

表のとおり、ベータだけが「参加者自身の環境」で行われます。ここが技術的にも重要で、社内では一度も再現しなかった不具合が、古い端末、遅い回線、見慣れない文字入力、業務で使っている別のソフトとの組み合わせで初めて表に出ます。環境の多様性そのものが、ベータの成果物です。

体験版・デモ版とは何が違うのか

ベータ版と紛らわしいのが体験版(トライアル版)やデモ版です。目的が逆だと考えると整理できます。体験版・デモ版は、完成した製品の一部を見せて買ってもらうための販促物です。ベータ版は、未完成のものを渡して情報をもらうための検証用です。前者は提供側が与える側、後者は提供側がもらう側にあたります。

そのため、体験版には「機能制限」や「期間制限」がつき、ベータ版には「不具合があり得る」「仕様が変わり得る」という前提と、報告の依頼がつきます。この2つを混ぜて、ベータ版を販促物のつもりで配ると、報告は返ってこないうえに品質の印象だけが残ります。これは失敗のもとです。

UATとベータテストは何が違うのか——分かれ目は「誰がテストするか」

UAT(受入テスト)とベータテストは、どちらも「開発の終盤に、作った側以外の人が使う」という点で似ていますが、誰がテストするかが違います。UAT は、発注者側の業務部門が、自社の業務で使えるかどうかを判定して合否を出す工程です。判定する人は発注者であり、その結果は検収につながります。一方、ベータテストは、実際の利用者(または候補)に使ってもらい、使われ方と不具合の情報を集める検証で、参加者は合否を判定しません。判定するのは、集まった情報を見た提供側です。したがって、両方をやる案件もあれば、社内システムのように UAT だけで完結する案件もあります。UAT の準備や合否の決め方は「UATとは」の記事で扱っているので、そちらをご覧ください。

ここまでが「ベータテストとは何か」です。ただし、外に出すといっても、参加者を限って出すのか、一般に開いて出すのかで、必要な体制も、返ってくるものもまるで別物になります。次はその選び分けです。

クローズドベータとオープンベータ——参加者を限るか、一般に開くか

ベータテストは、参加者の集め方で大きく2つに分かれます。人数や対象を限って行うクローズドベータ(CBT)と、一般に公開して誰でも参加できるようにするオープンベータ(OBT、パブリックベータとも呼びます)です。ゲーム業界の慣習から広まった呼び分けですが、業務用のソフトウェアでも同じ考え方が使えます。

2つの違いと選び分け——比較表

違いは参加人数だけではありません。運用にかかる負荷と、失敗したときの引き返しやすさが大きく変わります。

選び分けの基準は単純です。外に知られて困る状態がまだ残っているなら、クローズド。重大な不具合が落ち着き、あとは数と多様性がほしいならオープンです。投資家や社内から「オープンで利用者数の実績を作れないか」と言われることがありますが、重大な不具合が残ったまま開くと、集まるのは利用者ではなく低評価です。要注意です。

二段構えが基本——クローズドで潰してから開く

実務では、クローズドベータで大きな不具合を落としてからオープンベータへ移る二段構えが一般的です。ゲームでもこの順序が定着しており、クローズドのほうが不具合が多い状態で始まる前提で運用されます。

段階を分ける利点は、引き返す判断を2回持てることです。クローズドの結果が想定より悪ければ、オープンに進まずに修正へ戻せます。ここを一気にオープンへ飛ばすと、引き返す場所がありません。なお、社内向けの業務システムのように利用者が特定されている案件では、オープンベータという段階自体が不要です。この場合はクローズドベータを1段階だけ置き、そのまま正式版へ移します。

プラットフォームの配信枠——TestFlightとGoogle Playで公式に確認できること

スマートフォンアプリの場合、ベータ配信はプラットフォームの機能として用意されています。ここはまとめ記事の数値が古いことが多いため、公式ページで確認した内容だけを記載します(いずれも確認日 2026-09-15)。

出典: Apple「TestFlight」および「TestFlight overview(App Store Connect Help)」、Google「Set up an open, closed, or internal test」「App testing requirements」(いずれも公式ヘルプ、確認日 2026-09-15)。

発注者として押さえておきたいのは、数字そのものより「審査があるかどうか」と「期限があるかどうか」です。iOS では外部テスターに配る最初のビルドに審査が挟まるため、ベータ開始日を逆算するときに審査待ちの日数を見込む必要があります。また、ビルドの有効期間が90日と決まっているため、3か月を超えるベータでは配り直しの手間が発生します。この2点は、開発会社とスケジュールを詰めるときに必ず確認してください。なお、本番環境へどう反映するか、失敗したときにどう戻すかという作業そのものは「デプロイとは」の記事で扱っています。

ちなみに、国内の公的資料にベータテストの定義や手順を示したものがないか確認しましたが、IPA(情報処理推進機構)の公開資料には、ベータテストの定義・実施手順を示した文書は見当たりませんでした(確認日 2026-09-15)。本記事の定義部分は ISTQB の用語集を根拠にしています。

誰にテストしてもらうのか——社内・既存顧客・一般公募の3類型と、募集と選定

ベータの設計でいちばん迷うのが参加者の集め方です。ここで先に人数を決めてしまう方が多いのですが、順序が逆です。ベータで確かめたいことを1つに決めれば、どこから集めるべきかは自動的に決まります。まず3つの集め方と、それぞれ返ってくるものの違いを整理します。

3つの集め方と、返ってくるものの違い——比較表

3つは排他ではありません。実務では、社内で導線を一周確認し、既存顧客のうち関係の深い数社・数十名にクローズドで出し、そのうえで必要なら一般公募へ広げる、という順に積みます。

判断の目安はこうです。業務への当てはまりを見たいなら既存顧客、環境の多様性と負荷を見たいなら一般公募。社内は、外に出す前の最終確認として使うもので、ベータそのものの代替にはなりません。ここを取り違えて「社内50人でベータをやりました」と報告される案件がありますが、それは外に出していないので、ベータで得たかった情報は手に入っていません。

募集文に書くこと——参加者が知りたいのは「何を、いつまで、どこまで」

募集の文面で参加率が変わります。参加者が知りたいのは、自分が何を負担することになるのかです。次の6項目を入れてください。

1. 何を試すのか——対象の機能と、試してほしい操作の範囲
2. いつからいつまでか——開始日、終了日、途中で抜けられるかどうか
3. 何をお願いするのか——使うだけでよいのか、報告やアンケートの提出があるのか、頻度はどのくらいか
4. 未完成であることの明示——不具合があり得ること、仕様が変わり得ること、データが引き継がれない可能性
5. 守ってほしいこと——画面や内容を外部に公開しないなど(クローズドの場合)
6. 申込方法と締切、選定の方法——応募多数の場合は抽選か選考か

とくに3番目が抜けている募集文をよく見かけます。「ご意見をお寄せください」とだけ書かれていると、参加者は何をどのくらい書けばよいのか分からず、結果として報告が返ってきません。「週1回、5分程度のアンケートに回答してください」と負担の量まで書くほうが、参加率も報告率も上がります。

何人集めればよいのか——目的で決まる

「何人が適正か」という質問には、一般に通用する正解がありません。目的によって必要な人数が違うからです。考え方だけ示します。

• 使い勝手の問題を洗い出したい——同じ属性の人を少人数集めれば、同じ箇所で詰まる様子が繰り返し観察できます。深く見るなら二桁の前半でも十分に情報が出ます
• 環境差による不具合を拾いたい——端末・OS・回線の組み合わせの数がそのまま必要人数に効きます。多いほど有利です
• 負荷や同時接続を確かめたい——実際に想定する同時利用者数に近い規模が要ります。数十人では分かりません
• 需要があるかを見たい——これはベータではなく別の検証です(前章のとおり MVP の領域)

そして人数を決めるときは、返ってきた報告を捌ける人数から逆算してください。1日に30件の報告が来て、一次回答に1件10分かかるなら、それだけで5時間です。対応できる量を超えた瞬間、報告は情報ではなく滞留に変わります。

選定で外すべき人、入れるべき人

応募が定員を超えたら、抽選で決める方法が一般的です。ただし、目的が明確な場合は選考を混ぜたほうが結果は良くなります。

入れるべきなのは、想定している利用者像に近い人と、想定から少し外れた使い方をしそうな人です。後者を数名混ぜると、社内では出なかった経路が見つかります。逆に外すべきなのは、競合他社の関係者(クローズドで守秘義務をかける場合)、連絡が取れないことが見込まれる応募、そして報酬目当ての応募です。報酬については、プラットフォームの規約に関わるので次章で扱います。

最後に、よくある失敗を挙げておきます。人数を先に決め、目的を後から考えることです。「とりあえず100人」で始めたベータは、集まった報告の多くが重複し、対応に追われるだけで、判断に使える情報が残りません。人数は結果であって、出発点ではありません。

期間・フィードバック・不具合報告——集めた声をどう並べ替えるか

参加者が決まったら、次は運用の設計です。ベータは、テストという名前がついていますが、実態は運用にあたります。配り、質問に答え、報告を仕分け、直し、また配る。この循環を回せる形にしておかないと、人数だけ増えて情報が残らないという結果になります。

期間の決め方——「1周まわる時間」を基準にする

期間は、カレンダーの都合ではなく、そのプロダクトの利用が1周する時間で決めます。1周とは、参加者が「初めて触る→ひととおり使う→2回目以降の使い方に落ち着く」までの一巡です。

• 日常的に使うアプリ(毎日開く種類)——1周は数日。2週間あれば、初回の戸惑いと定着後の両方が観察できます
• 週次で使う業務システム——1周は1週間。最低でも2〜3週間は要ります
• 月次の締め処理を含む業務システム——1周は1か月。月末の処理を1回通さないと、いちばん重要な場面を見ずに終わります

短すぎると初回の感想しか集まらず、長すぎると参加者の熱が落ちて報告が止まります。報告の新規件数は、開始直後がピークで、そこから下がるのが通常です。新規の件数が明らかに落ち着いたら、期間の役目はおおむね終わっています。

もう一点、iOS のベータ配信ではビルドのテスト可能期間が最長90日と決まっています(前章の表を参照)。3か月を超える長期のベータを組む場合は、期間中にビルドを配り直す前提でスケジュールを引いてください。

受け口は1本にする——3経路から入ると情報ではなく滞留になる

ベータで最も壊れやすいのが、フィードバックの受け口です。専用フォーム、担当者のメール、営業経由の口頭、この3経路が並走した時点で運用は崩れます。同じ不具合が3件の別案件として数えられ、どれが対応済みなのか誰にも分からなくなるからです。

受け口は1本にしてください。窓口を1つのフォームや1つのチャットチャンネルに集約し、営業やサポートに口頭で届いたものも、必ずその1本に転記してから扱う。手間に見えますが、後から「何件出て、何件直ったか」を数えられる状態になります。この数字がないと、次章のベータ終了判断ができません。

そして、受け口には受付の返事を自動で返す仕組みを入れてください。報告したのに何の反応もない状態が2回続くと、その参加者はもう報告しません。報告の量は、対応の速さで決まります。

不具合報告のテンプレート——書いてもらう7項目

「動きません」という報告だけでは、開発チームは何もできません。報告フォームに次の7項目を用意しておくと、再現の手間が大きく減ります。

加えて、画面の写真や録画を添付できるようにしてください。6番の端末情報は、アプリ側で自動的に付与できるなら自動にしたほうが確実です。参加者に手入力させると、まず正確には集まりません。

優先順位のつけ方——重大度×発生頻度の4象限と、「仕様変更」の置き場所

報告が集まってからが本番です。全部直そうとすると、ほぼ確実にリリース日が動きます。「ベータで出た要望を全部直していたらリリースが延びる。どこで切ればいいのか」——私のところに届く相談で、最も多いのがこれです。

並べ替えの軸は2つで足ります。重大度(起きたときの影響の大きさ)と発生頻度(どのくらいの人に、どのくらいの割合で起きるか)です。

そして、報告のなかには不具合ではないものが必ず混ざります。「この機能もほしい」「ここはこうしてほしい」という要望は、不具合とは別の置き場所に移してください。同じ一覧に混ぜると、Dの要望がBの不具合より上に来ることが起き、判断の質が落ちます。要望は「正式版後の検討」として別のリストに積み、ベータ期間中に着手するかどうかは、リリース日への影響を見て個別に決めます。

当社が開発を担当している介護記録SaaS「CareViewer」では、日本語のできるブリッジSEをフロントに置き、週次で優先順位を判断しながら継続的に開発しています。ベータ期間中も同じ形で、週に一度「今週直すもの/次に回すもの/直さないもの」を決め切るリズムを作ると、判断が滞留しません。

いま、御社のベータで出た報告は、どこに集まることになっていますか。フォーム、メール、営業からの口頭、そのどれかに分かれるなら、開始前に1本へまとめてください。

参加者との取り決めと、ベータを終える判断

未完成のものを外部の人に渡す以上、渡す前に決めておくことがあります。守秘義務、免責、データの扱い、そして謝礼の可否です。ここを法務に相談するのが募集開始の直前になり、そこで止まる案件をよく見ます。参加者を集め始める前に着手してください。

守秘義務——どこまで縛るかは、ベータの種類で変わる

クローズドベータでは、画面の撮影や内容の外部公開を禁じる取り決めを置くのが一般的です。参加人数が限られ、相手が特定できるため、秘密保持契約(NDA)を個別に結ぶ形も取れます。とくに、未発表の機能や、競合に知られたくない仕様を含む場合は、ここを省かないでください。

一方、オープンベータでは事実上、守秘義務はかけられません。誰でも参加できる以上、画面はSNSに出るものとして設計します。したがって、「外に出て困るものがまだ残っているか」が、クローズドとオープンを分ける実務上の基準になります。前章の比較表で守秘義務の行を入れたのは、この理由です。

なお、参加者が法人(取引先企業)の場合は、既存の基本契約に秘密保持条項があることが多く、ベータ用に別途結ぶ必要がないこともあります。自社の契約の状況を先に確認してください。

免責とデータの扱い——「ベータ版」と書いただけでは守ってくれない

よくある誤解が、「ベータ版と表記してあれば、不具合があっても責任は問われない」というものです。表記だけでは足りません。参加時に何に同意してもらったかで決まります。少なくとも次の点を、参加者が読む形で明示してください。

• 提供するのが開発中の版であり、不具合が含まれ得ること、仕様が予告なく変わり得ること
• データが失われる可能性と、失われた場合の復旧を約束しないこと
• ベータ期間中に登録したデータを、正式版へ引き継ぐかどうか(引き継がない場合は、その旨をはっきり書く)
• ベータ期間が予告なく短縮・中止される可能性
• 参加者から寄せられた意見・報告の取り扱い(提供側が自由に製品改善へ利用できること)
• 収集する利用状況データの種類と目的

そして、運用側で必ず守るべき原則が1つあります。ベータの環境に本番の個人データを持ち込まないことです。既存顧客に参加してもらう場合、「実際の業務データで試してほしい」という要望が出がちですが、開発中の版でデータが壊れれば、それは顧客の業務データが壊れたということになります。既存データを使うなら複製した検証用の環境で、参加者が入力するデータは本人のものだけ、という線を引いてください。ここを曖昧にしたまま走るのは失敗のもとです。

機微な情報(家計、健康、人事など)を扱うプロダクトでは、ベータ期間中に誰がそのデータを見られるのかも決めておきます。開発チームが調査のために参照する可能性があるなら、その旨を参加者に伝えたうえで、参照できる人を限定し、記録を残す運用にします。外部の開発チームと組んでいる場合はとくに、この取り決めを開始前に文書化してください。

謝礼を出してよいか——プラットフォームの規約を先に読む

参加者を集めるために謝礼や特典を用意したくなりますが、配信するプラットフォームの規約を先に確認してください。Apple の App Store Review Guidelines は、2.2 Beta Testing の項で、TestFlight を使うアプリは、いかなる対価と引き換えにもテスターへ配布してはならない(クラウドファンディングの見返りとしての配布を含む)と定めています(確認日 2026-09-15)。

つまり、iOS アプリのベータでは「参加してくれたら○○円」という設計が取れません。謝礼を前提に募集計画を組んでしまうと、後から作り直すことになります。Web サービスや業務システムであればこの制約は直接には及びませんが、いずれにせよ報酬目当ての参加者からは、質の高い報告はあまり返ってこないというのが実情です。集めるべきは、そのプロダクトを実際に使いたい人です。

ベータを終える判断基準——開始前に文章にしておく3つ

終了条件を決めずに始めたベータは、終わりません。リリース日が来たか、担当者が力尽きたかのどちらかで終わることになります。開始前に、次の3つを文章にして関係者へ共有してください。

数値そのものは案件ごとに置き換えて構いません。大事なのは、開始前に書いてあることです。後から決めると、必ずその時点の都合(リリース日、社内の期待、担当者の疲労)に引っ張られます。

「ベータ版」という呼称をいつ外すか

最後に、呼称の話です。終了条件を満たしたら、原則として「ベータ版」の表記は外します。ところが実務では、外すのが怖くて何年もベータのまま提供する例があります。有名なのが Gmail で、2004年の公開から5年ほどベータ表記のまま提供されました。Googleは2009年7月7日の公式ブログ「Google Apps is out of beta (yes, really)」で、Gmailを含む Google Apps のベータ表記を外したことを告知しています。企業に採用してもらうサービスで、試作段階を思わせる表記を続けるのは得策ではない——本記事ではこの判断が働いたものとみています。

判断の軸は2つです。課金しているかと、業務に使われているか。対価を受け取っている、あるいは顧客の業務が止まると困る状態になっているのに「ベータ版だから」と言い続けるのは、提供側の責任範囲を曖昧にするだけです。逆に、無償で、明確に実験的な位置づけの機能であれば、ベータ表記を続ける合理性はあります。表記は免罪符ではなく、利用者との期待値の合わせ方だと考えてください。

外部チームで開発したものをベータに出すときの体制——当社の場合

開発を外部に委託している場合、ベータ期間は体制の弱いところがそのまま表に出ます。実装が終わってからの期間なので人を減らしたくなりますが、ベータは実装より運用の比重が高い期間です。ここで受け口が細ると、参加者の報告が止まります。

ベータ期間に体制へ求められる3つ——受け口、一次回答、修正の優先順位づけ

外部チームと組んでベータを回すとき、体制に必要なのは次の3つです。

1. 不具合の受け口が1本で、開発チームまで直通していること。発注者側の窓口 → 開発会社の営業 → 開発チームという経路を挟むと、一次回答までに1日以上かかります。前章のとおり、返事が遅いと報告そのものが止まります
2. 一次回答を出す担当が決まっていること。修正の完了ではなく、「受け取った・再現できた・いつ直す」を返す役割です。当社の推奨体制(パターンA)では、日本人PMまたはブリッジSEがここを担います
3. 修正の優先順位を、週に一度は決め切ること。重大度×発生頻度で並べ替えたうえで、「今週直す/次に回す/直さない」を明示する。介護記録SaaS「CareViewer」では、日本語のできるブリッジSE1名とフルスタックエンジニア2名の体制で、この週次の優先順位判断を継続しています

時差2時間で回す——朝の報告を、その日のうちに戻す

ベトナムと日本の時差は2時間で、日本の午前がそのまま現地の午前にあたります。ベータ期間中に朝いちばんで入った不具合報告を、現地チームが同じ日の午前から調査し、日本の夕方までに一次回答と修正方針まで戻せる。この往復が1日で閉じるかどうかで、2週間のベータの密度はかなり変わります。時差が大きい地域では、報告した翌日にようやく調査が始まることになります。

当社では品質管理として、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点を標準にしています。ベータ期間中の修正は急ぎになりがちですが、急ぎの修正ほどレビューを飛ばすと別の不具合を生みます。ここは工程として固定しておくべきところです。品質を人ではなく仕組みで担保する考え方は「オフショア開発の品質」の記事で詳しく扱っています。なお、テスト工程そのものを外部に委託する場合の線引きは「ソフトウェアテストの外注」の記事をご覧ください。

体制は1名から組めます。日本人PMをフロントに置く推奨構成なら、2〜3人月で月額約80万円からが目安です。エンジニアの公開単価は実務3年目安で1,500USD(1USD=150円換算で約22.5万円)、ブリッジSEで3,000USDです。ベータ期間だけ増員したい場合、増員は約1週間、縮小・交代は1か月単位で調整できます。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

向く案件・向かない案件

正直に書きます。向くのは、ベータ後も継続して開発と改善が続く案件です。ベータで出た要望を正式版リリース後も順に反映していく前提なら、専属チームを置く形が費用にも品質にも効きます。介護記録SaaSや決済アプリのように、リリースが終わりではなく始まりになるプロダクトが典型です。

向かないのは、ベータ期間の数週間だけスポットで人手がほしい案件です。当社の体制は最短2週間で立ち上がりますが、立ち上げにはプロダクトの理解が要ります。2週間だけの応援を目的にするなら、既存の開発会社に増員を頼むほうが速いはずです。また、ベータの運営そのもの(募集、参加者対応、アンケート設計)は当社の担当範囲ではありません。開発と修正対応が当社の役割です。

これから開発を発注する方は、見積もりを取る段階で「ベータ期間の対応がどこまで含まれるか」を必ず確認してください。実装の終了をもって契約が切れる形になっていると、いちばん人手が要る時期に誰もいない、という状態になります。ここは契約書の文面で確かめられます。

ベータテストに関するよくある質問

ベータテストについて、発注者の方から実際によく届く質問を5つ挙げます。いずれも募集を始める前に決めておくと、期間中の判断が速くなるものです。

Q1. ベータテストは必ずやるべきですか

利用者の環境や使い方が読みきれないプロダクトでは、やる価値があります。不特定多数が使うアプリやWebサービスが典型です。逆に、利用者が特定の部署に限られ、UAT(受入テスト)で業務が一通り確認できる社内システムでは、ベータを省いて問題ないことが多いです。判断の軸は「社内で再現できない使われ方が、どのくらいありそうか」です。

Q2. 何人集めれば十分ですか

目的によって変わるため、一律の正解はありません。使い勝手の問題を洗い出すだけなら、同じ属性の参加者を二桁の前半集めれば繰り返しの詰まり方が見えます。環境差を拾いたいなら、端末とOSの組み合わせの数だけ必要です。いずれの場合も、返ってきた報告を捌ける人数が上限になります。1日に対応できる件数から逆算してください。

Q3. 参加者に報酬を払ってもよいですか

配信するプラットフォームの規約を先に確認してください。Apple の App Store Review Guidelines は、TestFlight を使うアプリをいかなる対価と引き換えにもテスターへ配布してはならないと定めています(確認日 2026-09-15)。Webサービスや業務システムではこの制約は直接には及びませんが、報酬目当ての参加者から質の高い報告が返ってくることはあまりありません。

Q4. ベータ中に大きな仕様変更が必要だと分かったらどうすればよいですか

まず、それが不具合なのか要望なのかを切り分けてください。重大度と発生頻度が高い不具合ならリリース前に直します。「こうしてほしい」という要望であれば、正式版後の検討リストへ回すのが原則です。ただし、主要な導線が成立していないことが分かった場合は、リリース日を動かす判断のほうが安いことがあります。その判断は、開始前に決めた終了条件に照らして行ってください。

Q5. ベータ版のまま提供し続けてもよいですか

無償で、実験的な位置づけであることが利用者に伝わっているなら問題ありません。一方、対価を受け取っている、または顧客の業務が止まると困る状態になっているのに「ベータ版だから」と言い続けるのは、責任範囲を曖昧にするだけです。判断の軸は、課金しているかと、業務に使われているかの2点。

まとめ: ベータテストは「外の人に使ってもらう検証」——決めるのは誰に・何人に・どのくらい・どう並べ替え・どこで終えるかの5つ

ベータテストとは、開発が一段落したソフトウェアを、開発者が関与しない外部の場所で、実際の利用者に使ってもらう検証です。アルファテストとの分かれ目は完成度ではなく、どこで誰が使うか。アルファは開発者の側で開発組織の外の人が使い、ベータは参加者自身の環境で実際の利用者が使います。だからこそ、社内では一度も再現しなかった不具合が、古い端末や見慣れない入力で初めて表に出ます。環境の多様性そのものが、ベータの成果物です。体験版は売るための販促物、ベータ版は情報をもらうための検証用で、目的が逆である点も押さえてください。

参加者を限るのがクローズドベータ、一般に開くのがオープンベータで、外に知られて困る状態が残っているうちはクローズドが原則です。スマートフォンアプリでは、TestFlight が内部100人・外部10,000人、外部へ配る最初のビルドに審査があり、ビルドのテスト期間は最長90日。Google Play は内部テスト100人、クローズドテストがリスト最大200件・1リスト2,000人、オープンテストの上限指定は1,000以上(いずれも公式ヘルプ・確認日 2026-09-15)。集め方は社内・既存顧客・一般公募の3つで、人数は「返ってきた報告を捌ける数」が上限になります。期間は利用が1周まわる時間で決め、受け口は必ず1本に。報告は重大度と発生頻度の2軸で並べ替え、要望は不具合と別の置き場所へ移します。

そして、開始前に文章にしておくのが、参加時の取り決め(守秘義務・免責・データの扱い)と、終える条件の3つです。「ベータ版」と表記しただけでは守ってくれません。何に同意してもらったかで決まります。受け入れテストとの違いや合否の決め方はUATとはに、本番反映と切り戻しの実務はデプロイとはにまとめてあります。当社はホーチミンを拠点に、日本人PMをフロントに置いたラボ型の開発チームを提供しています。時差2時間なので、ベータ期間中に朝いちばんで入った報告を、その日のうちに一次回答まで戻せます。最小構成は日本人PMフロント+2〜3人月で月額約80万円から、1名・最短2週間で開始できます。現在の体制と要件をお聞かせいただければ、ベータ期間の対応体制の組み方を含めて概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。