初めてのチャレンジ企画を何人で始めるかは、集客目標だけで決めません。
課題の提出、質問、フィードバックをどこまで扱えるか。その中で、参加者がどこで止まり、何を変えれば次回がよくなるかを観察できる人数から始めます。
僕は、少人数開催を「小さくてよいから」と考えているわけではありません。未検証のテーマ・課題・支援を、参加者と向き合いながら確かめるために少人数から始めるのが合理的だと考えています。
この記事では、使える総時間から初回人数の上限を出し、未知数が多い場合の決め方と、超過時の戻り先まで整理します。
初回は、人数の多さより観察の質を優先する
初回で大人数を集められれば、見栄えはよくなります。
ただ、支援が追いつかず、どこで質問が増えたか、どの課題で止まったかを拾えなければ、次回の改善材料は残りません。
僕の教材でも、最初から大人数を必要とせず、フォロー体制とフィードバックの限界を踏まえ、丁寧に実施する考え方を採用しています。
チャレンジは、参加者の行動が中心の形式です。申込数だけでは、企画が機能したかを判断できません。
支援容量を見積もる4つの項目
人数を決める前に、次を出してください。
| 項目 | 確認すること |
|---|---|
| 提出回数 | 一人が何回、何を提出するか |
| 質問量 | 質問を受ける場所と、想定される頻度 |
| 確認時間 | 一件を見て、次の一手を返すまでの時間 |
| 返信期限 | 参加者へいつまでに返すと約束するか |
数字を厳密に当てることが目的ではありません。約束した支援を守れるか、人数を増やしたときに観察の精度が落ちないかを、始める前に見えるようにすることが目的です。
使える総時間から初回人数を逆算する
初回人数は、次の式で仮の上限を出せます。
参加者対応に使える総時間 ÷ 一人あたりに必要な支援時間 ＝ 初回人数の仮上限
一人あたりの支援時間には、提出確認だけでなく、質問回答と振り返りも含めます。全員が同じ回数だけ質問するとは限らないので、結果は確定値ではありません。だから「仮上限」として扱います。
1. 参加者対応に使える時間を分ける
開催期間中に使える時間から、ライブや教材準備など、参加者対応以外の時間を外します。
残った時間を、提出確認・質問・フィードバック・振り返りへ割り当てます。予定に置けない時間は、容量へ入れません。
2. 一人あたりの支援単位を出す
一人につき、何回の提出を見るのか。完了確認だけか、修正点まで返すのか。質問はどこで受け、いつまでに返すのか。
これを支援単位として書きます。
たとえば、完成物全体を毎回添削する案と、各回は完了確認だけを行い、重要な一回だけ次の修正点を返す案では、一人あたりの負荷が違います。どちらが正しいかではなく、企画の停止点に必要な方を選びます。
3. 仮上限を出し、余白を残す
総時間を一人あたりの支援時間で割ると、計算上の人数が出ます。
でも、その人数をそのまま募集上限にはしません。初回は質問量や確認時間が読めないからです。未知数が多いほど、計算上の上限より安全側に置きます。
ここでの余白は、念のための飾りではありません。同じ質問が増えた場所や、想定より確認に時間がかかった出力を観察するための時間です。
4. 人数を決めた理由を一文にする
「初回だから少人数」では、次回に増やす基準が分かりません。
「この人数なら、各提出の完了確認を期限内に行い、繰り返される質問と停止点を記録できる」と書きます。こうしておけば、次回は何が整えば人数を増やせるかを判断できます。
未知数が多い場合は、安全側を選ぶ
初回には、次のような未知数があります。
- 一件の出力を確認する時間
- 質問が集まる工程
- 課題を終えた後の修正回数
- 主催者側の準備と返信の負荷
- 参加者ごとの開始状態の差
どれも分からないのに、大人数を前提にすると、何が原因で支援が崩れたかを観察できません。
安全側に置くときは、ただ小さな人数を選ぶのではなく、今回確かめたい未知数を決めます。「最初の課題で何分かかるか」「どの質問が共通化できるか」「完了確認だけで次へ進めるか」など、一つずつ記録します。
初回の価値は、少人数であることではありません。次回の人数を根拠を持って決められることです。
初回で観察する停止点
初回の目的は、参加人数を集めることだけではありません。次のような停止点を見つけることです。
- どの課題で提出が止まったか
- 同じ質問がどこで繰り返されたか
- 課題を終えた人が、次に何をすればよいか迷ったか
- 主催者側の確認がどこで重くなったか
- 参加者が価値を感じたのは説明、課題、支援のどこか
これらが分かれば、次回は人数を増やす前に企画自体を直せます。
反対に、提出が少なかった理由を参加者の意欲だけで片づけると、テーマが広すぎたのか、課題が重かったのか、前提説明が足りなかったのかを見落とします。
人数を増やす前に直すもの
初回後、人数を増やす判断の前に、次を確認してください。
- 課題の完了条件は明確だったか
- 質問が繰り返された部分は、事前説明へ戻せるか
- フィードバックの範囲は守れたか
- 参加者が小さな出力を残せたか
- 次に何を変えるべきかを一つ選べるか
主催者の手作業が多すぎる場合、最初に増やすべきは人数ではありません。課題文、完了条件、Q&A、確認の仕方を整えることです。
僕は、手動でやれないことは自動化できない、という順番を重視しています。手動開催で何が起きるかを知らないまま人数や自動化を先に考えても、止まる理由は見えません。
仮上限を超えたときの戻り先
想定より質問や確認が増えた場合は、次の順で原因を見ます。
| 超過の原因 | 先に戻る場所 | 修正例 |
|---|---|---|
| 同じ質問が繰り返される | 説明・課題文 | 判断基準や完了条件を共通化する |
| 一件の確認に時間がかかる | 出力・確認項目 | 出力を小さくし、見る一点を決める |
| 修正の往復が続く | フィードバック範囲 | 次に直す一点だけを返す |
| 返信が期限に間に合わない | 支援範囲・人数 | 接点を減らすか初回上限を下げる |
| 参加者の前提差が大きい | 対象者・テーマ | 開始条件を揃えるか、企画を分ける |
人数を減らすのは一つの選択肢です。ただ、原因が曖昧な説明や大きすぎる出力なら、人数だけを減らしても次回に同じ負荷が残ります。
反対に、支援を削ればよいとも限りません。参加者が次へ進むために欠かせない確認を消すと、チャレンジの役割が崩れます。
迷ったら、「この支援がないと、参加者は次の工程へ進めないか」と問い、その答えが「はい」の接点を残してください。
初回人数は、支援の約束と観察余力で決める
計算上の上限が出たら、最後に「約束した支援を守れるか」と「停止点を記録できる余白があるか」を照合します。ただ少ない人数にするのではなく、次回に増やす条件を学べる人数へ戻すためです。
| 人数を増やす前の確認 | 増やしてよいサイン | 先に設計へ戻るサイン |
|---|---|---|
| 課題の完了条件 | 共通説明で理解できる | 同じ質問が繰り返される |
| フィードバックの範囲 | 次に直す一点を返せる | 完成まで往復が続く |
| 主催者の確認時間 | 約束した期限内に反応できる | 返信が次の工程を止める |
僕が少人数開催を重視するのは、見栄えのためではありません。課題・質問・支援のどこが止まるかを観察し、次回の人数に根拠を持たせるためです。開催後は停止点から次回の一変更を決める手順へ進みます。
初回の成功をどう定義するか
初回の成功は、人数の多さだけでは決められません。僕なら、少なくとも次を確認します。
- 参加者が終了時の出力を残せたか
- どの課題で止まったかを特定できたか
- 繰り返された質問を記録できたか
- 約束した支援を期限内に守れたか
- 次回に変えることを一つ選べるか
すべてがきれいに進む必要はありません。
止まった事実が見え、原因の候補をテーマ・課題・支援へ戻せるなら、初回は次の設計につながっています。何が起きたか分からないまま終わる方が、改善しにくいわけです。
開催後は、観察を次回の一変更へ変えます。
まとめ：初回は設計を確かめる場
初回規模は、集客の数字だけで決めません。
参加者の課題・質問・提出を見て、支援を守れ、停止点を観察できる範囲から始めます。
初回で得た観察をもとに、次回で変えることを一つ選んでください。人数を増やすのは、支援の約束を守りながら停止点を観察できると分かった後です。
