workshop-program-design

ワークショッププログラム設計

ハンズオンワークショップやトレーニングセッションの内部の仕組みを設計します。

• 会場に何人参加できるか。
• 参加者が行き詰まったとき、誰がサポートするか。
• 参加者が席に着く前に、各自のマシンでどのような準備が整っている必要があるか。
• 参加者が何を持ち帰るか。
• 演習に必要な通信を会場のネットワークでまかなえない場合、どうするか。

次の項目は、すでに決定済みの入力として扱います。

• ワークショップデーまたはトラックを実施するかどうか、講演日程の前後どちらに置くか、チケットをどうするかは、samber/dev-event-organizer-skills@event-format-selection で決まっています。これについて再度議論しないでください。
• 採択された提案は、samber/dev-event-organizer-skills@event-talk-selection で決まっています。
• 各セッションを時間割のどこに配置するか、その前後にどれだけの余裕を設けるかは、ここで設定する定員と時間を入力として使う samber/dev-event-organizer-skills@event-schedule-design で決まります。
• 収録対象のワークショップにおける録画・配信のシグナル経路は、samber/dev-event-organizer-skills@event-production が扱います。これは、参加者のノートパソコンに依存関係をインストールできない場合とは、別の障害要因です。ここでは参加者側の環境までを扱います。

以下の各項目の順位はすべて初期設定であり、絶対的なルールではありません。状況や実行する人によって変わります。聞き取りの後、すでに把握している情報に照らして、4つのメニューすべての順位を見直してください。次のどれか1つでもあれば、初期順位を覆す理由になります。

• 同じワークショップを商用で運営した経験がある講師。
• これまでに4回利用し、ネットワークを測定したことのある会場。
• クラウド環境を提供するスポンサー。
• 会社が管理するノートパソコンを使う参加者。

聞き取り

質問は1つずつ行い、可能な場合は選択式にしてください。質問11は、各メニューで効果が出るまでの時間、持続性、労力の順位が大きく異なり、利用者に代わって順位を決められないために設けています。

1. どの範囲の運営を検討していますか。1つのセッションの進め方、ワークショップデー内のすべてのセッション、またはうまくいかなかったワークショップの振り返りですか。すでに決定済みのメニューは省いてください。
2. 終了時に、参加者が今はできないことで、できるようになっている必要があるのは何ですか。また、それは会場で実践せずに、資料を読むだけで身につけられますか。
3. 演習のために、参加者自身のマシンにソフトウェアやツールチェーンをインストールしたり、何かをダウンロードしたり、ベンダーアカウントにサインインしたりする必要はありますか。
4. セッション中、演習の一部でライブネットワークサービスへの接続が必要ですか。ホスト型コンソール、API、パッケージレジストリ、リモートラボなどが該当します。
5. 参加者全員が実行可能なマシンを持参し、そのマシンへのインストールを許可されていると見込めますか。持参を必須にすると、想定している参加者の誰かを除外することになりますか。
6. 演習では、複数のワークステーションや物理的な手順を順に使いますか。それとも、全員が自分の席で同じ作業をしますか。
7. 参加者は何人の見込みですか。また、実際に会場で使えるのはどのような設備ですか。座席、移動できる家具、各席の電源などを教えてください。
8. 発表者以外に、会場でサポートする人はいますか。その人たちは内容に詳しいですか。それとも運営面のサポートのみですか。
9. 会場は、この部屋のネットワークについて、持続的な帯域幅、対応可能なデバイス数、一般的でないプロトコルやデバイス種別をブロックするかどうかを、書面で回答していますか。
10. 主催者であるあなたが、サードパーティのプラットフォームの規約に同意し、参加者に代わって認証情報を発行することになりますか。また、参加者に未成年者はいますか。
11. すべての順位を見直すための3つの質問です。ひとまとまりで尋ねます。セットでないと意味をなさないためです。
    • いつまでに準備する必要がありますか。
    • 今回限りのセッションですか。それとも、毎回実施するカリキュラムですか。
    • 労力の上限はどの程度ですか。主催者の作業時間、会場に呼べる人数、選択をどれだけ変更可能にしておく必要があるかを教えてください。
12. 以前の開催でワークショップのネットワークに障害が発生したことはありますか。発生した場合、具体的には何が問題でしたか。帯域幅、ブロックされたプロトコル、ブロックされたデバイス種別、または会場から回答がなかった、のどれですか。

ハンズオンの実施方針

最初に決めることですが、最も見落とされがちな点です。このセッションでは、実際にキーボードを操作しますか？優先順位（原則であり、絶対ではありません。Q2 と Q9 で順位を変更します）：

• 労力（準備、リハーサル、会場サポート、当日の対応）：フルハンズオン > デモのみ > ライブハンズオンなし
• 価値：参加者が自分で実行できるようになること：フルハンズオン > デモのみ > ライブハンズオンなし
• 価値：会場の状況に左右されず、内容を届けられること：ライブハンズオンなし > デモのみ > フルハンズオン
• 効率：ライブハンズオンなし > デモのみ > フルハンズオン

⚠️ ここでの効率は、コストが低い順です。 これをデフォルトと解釈しないでください。デフォルトは Q2 で決まり、読むだけではスキルを習得できない場合は、フルハンズオンが最適です。

• ライブハンズオンなし - 公開済みのリソースとして教材を提供するか、講演として内容を届けます。実施方法の観点では、これは ワークショップ自体を行わない ことであり、当日に失敗しうるものがないため、効率の面では文句なしの勝者です。ハッカソンの主催者はすでにこの方法を取り入れていますが、理由は別で、開発時間を確保するためです。MLH のハードウェアガイドでは、非同期で学べる仕組みを一式用意しています。「非同期リソースを使えば、学生はハッカソン開始前に、自分のスケジュールに合わせてツールや概念に慣れることができます」。同じガイドでは、主催者に「イベント中のワークショップは、貴重な開発時間を消費するため、数を制限する」よう伝えています。判断の境界に注意してください。イベントを開催するかどうかは samber/dev-event-organizer-skills@event-format-selection が決めることで、すでに決定済みです。このセッションをハンズオンにするかどうかは、あなたの判断です。
• デモのみ - 講師が操作し、会場の参加者は見学します。誰も何もインストールしません。1 台のマシンと 1 つの接続に障害が起きる可能性があり、どちらもあなたが用意します。
• フルハンズオン - 読むだけでは習得できない内容に限り、デフォルトの選択肢です。MLH のイベント前ワークショップでは、参加者が実際に使うコンポーネントを取り上げ、「基本的な配線と、必要な初期コードのアップロードを扱います」と説明しています。Q2 に基づく実施条件は、「読むだけで習得できるか」という問いへの答えが「いいえ」であることです。
• 格下げではなく、削除する： Q4 で演習にライブのネットワークサービスが必要とされ、以下のネットワークの選択肢ではその依存をなくせず、会場が準備完了日（Q11）までに Q9 への回答を書面で提示しない場合は、この選択肢から フルハンズオン を削除し、上記の優先順位の行からも取り除いてください。会場がまだ回答していないだけなら、削除ではなく、回答を催促してください。代わりにデモを実施し、教材を公開します。誰も接続できないハンズオンこそ、このスキルで防ごうとしている失敗です。削除した選択肢を最下位に残しておくと、当日に作業範囲として復活します。

ファシリテーターの配置

行き詰まった参加者をどう支援するか。優先順位（原則であり、絶対ではありません。Q6 と Q8 で順位を変更します）：

• 労力（募集、事前説明、当日の連携）：作業エリアごとの常駐ヘルパー > 巡回トラブルシューティング担当 > 構造化されたペア学習 > 講師のみ

• 価値：行き詰まった参加者が諦める前に解決できること：常駐ヘルパー > 巡回トラブルシューティング担当 > 構造化されたペア学習 > 講師のみ

• 価値：会場の規模が大きくなっても維持できる対応体制：構造化されたペア学習 > 常駐ヘルパー > 巡回トラブルシューティング担当 == 講師のみ - 常駐ヘルパーは 2 番目です。各自が 1 つの工程を受け持ち、同じ質問を繰り返し受けるほど対応が速くなるためです。異論のある同率順位です。当日は、巡回担当も講師のみの場合も、対応できる人数は募集時に固定され、会場の参加者数は増えていきます。そのため、会場の規模が 2 倍になれば、どちらの場合も各参加者が受けられる対応は半分になります。比率を保つためにヘルパーを追加するには再募集が必要です。これは、規模拡大の効果ではなく、労力の増加です。

• 効率：構造化されたペア学習 > 巡回トラブルシューティング担当 > 講師のみ > 常駐ヘルパー ⚠️ 最初の価値軸は、作業量と同じ順序になります。 復旧までの時間は実際に意味のある指標ですが、それで段階を並べても、すでに作業量が示している順序を言い換えるだけで、何も区別できません。また、それだけに基づく効率の線は、結局「最も安いものから」の順序に崩れてしまいます。成長軸では、同じ立場の参加者同士でのペアリングが最上位になります。単独作業より巡回型が上になるのは、待ち時間を短縮できるからです。内容を把握している人を1人加えるだけで、作業量をほとんど増やさずに待ち時間を減らせます。

• 巡回型のトラブルシューティング担当者 - デフォルトです。MLH はワークショップ主催者に、「遅れ始めた参加者のトラブルシューティングを支援するため、バックアップの講師を巡回させてください」と伝えています。また、リモート会場では「問題のトラブルシューティングのため、画面共有を依頼してください」と伝えています。募集するのは、運営補助のボランティアではなく、内容を把握している人です。Q8 では、どちらを確保できるかを尋ねています。The Carpentries では、公開されている基準を使ってこの段階を拡大しています。「講師2人を除き、受講者8～10人につきヘルパー1人」（講師向け研修では「少なくとも受講者10人につき1人」としています）で、オンライン授業ではさらに増やします。

• 構造化されたピアペアリング - 効率面で最も優れています。定義上、支援できる人数が会場の規模に応じて増えるため、成長軸で優位に立ちます。CS 教室でのペアプログラミング教育では、単なる人数の議論ではなく、その仕組みを示しています。ドライバー／ナビゲーターの役割を割り当て、5～10分ごとに交代することで、ナビゲーターがセッション中ずっとドライバーの画面を見守れます。重要なのは「構造化された」という点です。同じガイダンスでは、役割を設けない単純なペアリングについて、「学習者の一方または両方がすぐに集中力を失うことがよくある」方法とも述べています。これは、別の名前で呼ばれている、この段階固有の管理されていない場合の失敗です。2人とも行き詰まっていて、誰も気づかないこともあり得るため、巡回型の段階ですでに行っている頻度でペアを確認してください。

• 作業エリアごとに配置するヘルパー - 手薄な選択肢です。待ち時間も作業量も最大なので、効率の観点から選ばれることはありません。MLH のツールステーションのガイダンスでは、「近くにメンターを配置するようにしてください」「これらのステーションには経験豊富なボランティアを配置してください」としています。昇格条件は Q6 に関連します。演習が実際に、別々の作業ステーションや物理的に分かれた段階で進むため、1か所に配置したヘルパーが、そこに来るすべての参加者を支援できる場合です。

• 削除し、降格はさせない： 実践形式のメニューが「すべて実践形式」になった時点で、このメニューと上記の軸の線から単独講師を削除してください。講師が説明の途中でも、会場で演習に取り組む参加者は行き詰まります。巡回型より下のどの段階も、その状況には対処できません。

対応できる人数は、次の2段階で見積もり、両方を明記してください。

1. まず、上記の The Carpentries の基準を起点にします。この基準は、講師2人がすでに会場にいて、ツールに詳しいヘルパーがいる、科学者向けの2日間の研究計算ワークショップに由来します。引用する際は、その背景を明記してください。
2. Q6 と Q8 に基づいて調整します。失敗しやすい箇所が多い演習やリモート会場ではヘルパーを増やし、一本道の演習では減らします。デバッグできない人は人数に含めません。

ハッカソンのメンター人数を、ワークショップの比率として持ち込まないでください。「専門外の参加者がおよそ4人につき1人」というのは、数日間の制作で、各分野の専門家とプロジェクトの人数を決める基準であり、固定枠内のヘルパー数ではありません。

前提条件と環境

セッション開始前に、参加者のマシンとアカウントが満たしているべき条件です。優先順位（デフォルトであり、絶対ではありません。Q3、Q5、Q10 では順位を変更します）：

• 労力（構築、保守、サポート窓口が2つか1つか）：両方の経路を用意 > 環境のみをプロビジョニング > 前提条件を公開 > 何も公開しない

• 価値、実際に参加を開始できる人の割合：両方の経路を用意 > 環境のみをプロビジョニング > 前提条件を公開 > 何も公開しない

• 価値、セッション中に会場のネットワークに依存しない度合い：前提条件を公開 > 両方の経路を用意 > 環境のみをプロビジョニング > 何も公開しない

• コンプライアンス上のコスト（審査の発生と、取り消し可能性）：環境のみをプロビジョニング == 両方の経路を用意 > 前提条件を公開 > 何も公開しない - 同順位とする根拠：どちらの段階でも、参加者ではなくあなたが、その場にいる人たちに代わってプラットフォームの規約を受け入れ、認証情報を発行する立場になります。もう一つの経路を併設しても、署名した人が誰かは変わりません。

• 効率：前提条件を公開 > 環境のみをプロビジョニング > 何も公開しない > 両方の経路を用意

• 前提条件を公開 - デフォルトです。DevOpsDays、PyCon US、SmashingConf のワークショップページには、それぞれのセッションの前提条件欄があり、Carpentries は各ワークショップの前にインストール手順を送ります。前提条件は3つのクラスに分けられます。references/prerequisite-and-environment-sheet.md に記載されている、事前知識、マシンの状態、アカウントです。最も忘れられやすく、開始時に最も問題が起こりやすいのはアカウントです。参加者が当日より前に実行し、ツール、バージョン、OS とチップのアーキテクチャ、サインイン状態を確認できるチェックを用意し、新しいマシンで自分自身でも演習を事前に試してください。

• 両方の経路を用意 - 参加者が選べるよう、ローカルマシン または 事前設定済みの環境を用意します。あるワークショップでは、「ノートパソコンでワークショップを行うか、GitHub Codespaces と事前設定済みの環境を使うかを選べます」としています。準備度は最高ですが、労力も最大です。2つの環境を保守し、サポートする必要があるためです。

• 環境のみをプロビジョニング - 制約のある選択肢です。ハードウェアとインストール権限の障壁を完全に取り除きます。あるワークショップでは、「すべてウェブブラウザー（Chrome、Firefox）上で行うため、ノートパソコンでローカルコマンドを実行したり、ソフトウェアをインストールしたりする必要はありません」としています。参加者ごとにログインを用意し、バージョンを固定したツールチェーンを事前にインストールします。Q5 と Q10 に基づく優先条件：参加者が十分な性能のマシンを持っていると期待できない場合、持参したマシンにソフトウェアをインストールする権限がない場合、またはマシンを必須にすると想定する参加者の一部が除外される場合です。

• 削除し、格下げしない： Q3 で何かをインストール、ダウンロード、またはサインインする必要があると示された時点で、このメニューと上記の軸の行から 何も公開しない を削除します。前提条件の欄が空であることは、何も必要ないという約束です。その約束が正しい場合に限り、空欄のまま公開してください。

コンプライアンス上の懸念。 会場のために環境を立ち上げると、規約を読んだことのない人たちに代わってベンダーの規約を受け入れ、認証情報を発行して保管することになります。Q10 で未成年者が参加するとされている場合、その受諾は自分で判断できない人に代わって行われます。発生する審査を明示してください：

• サードパーティによる利用に関するプラットフォームの規約。
• 認証情報に関する、自組織のデータ管理方針。
• 参加者データについて、samber/dev-event-organizer-skills@event-accessibility-inclusion が提示するのと同じ同意に関する問い。

取り消し可能性については、段階によって実際に違いがあります。この非対称性は、公表済みの主張ではなく、このスキル独自の主張です。自分で構築した環境は自分の予定で撤去できます。一方、あなたに言われて参加者が作成したアカウントは、あなたがやめた後も残り、本人に代わって削除することはできません。

定員：3つの上限のうち、最も低いもの

ここでは、意図的に順位付けをしていません。 これらは価値の異なる選択肢ではなく、1つの数値に対する3つの上限です。どの上限が適用されるかは、効率比を考慮して選ぶものではなく、演習の内容と会場によって決まる事実です。そのため、順位付けすると不正確な精度を装うことになります。3つすべてを計算し、最も低いものを採用して、どの上限が適用されたかを明記してください。

• 会場の上限 - 演習に必要な家具を配置した状態での座席数です。技術系イベントの分科会室では、椅子を円形に動かせることを前提に、一般的な範囲は10～20席または20～40席です（samber/dev-event-organizer-skills@event-venue-sourcingのスペースプログラムを参照）。電源は座席数とは別の問題です。Carpentriesでは「すべての参加者用の電源コンセント」を求めており、SmithsonianのCarpentries主催者向けチェックリストでは「学習者3人につき電源タップ1つ」を見積もっています。
• サポート範囲の上限 - 講師と、ファシリテーターのメニューで確保した人員が、誰かが諦めてしまう前に実際にサポートできる人数です。上記の人数設定を逆に計算します。対応可能なヘルパーの人数に8～10を掛けます。この数値が有効なのは、講師2人で教える場合に限り、その後に独自の調整を加えます。講師が1人の場合は、演習中の講師をヘルパー1人分のサポート範囲として数え、その結果を独自設定と明記してください。どの部分が慣例に基づき、どの部分が独自の設定なのかを説明してください。
• 演習の処理能力の上限 - 実際に制約となるもの、つまりキット、参加者ごとのログイン、ライセンスの利用枠、物理的な作業場所に応じて、実践的な作業時間を確保できる人数です。これは最も見落とされやすい上限です。21人目に9台目のボードが必要になるまで、制約が見えないためです。

費用を抑えられる仕組みとして、2017年のワークショップデーでは、参加者に事前に「お気に入りのワークショップに投票して」もらい、「どの部屋に配置するかを決めるのに役立ちます」と説明しました。当日の前に集めた需要は、スケジュール作成時の推測に勝ります。また、samber/dev-event-organizer-skills@event-attendee-email-sequencesがすでに送っているイベント前のメールに追加するだけなので、手間もかかりません。

無料のセッションでは、登録者が当日来ないことを想定してください。ウェイティングリストを設け、開始時に未使用の席を開放します。過剰予約の人数は、過去の開催回で測定した欠席率に基づいて決めてください。他から借りた数値は使わないでください。

セッションの長さは、決めつけるのではなく、実例に基づいて設定します。会議内で実施された、日付の明記されたハンズオンの事例は150～180分でした。一方、公表されている時間枠の選択肢には45～120分もあります。セットアップ確認の時間も所要時間に含め、長い枠は、180分のアジェンダにある「45分のセグメント4つ」のように、休憩を挟んで分割します。各ワークショップのイベント名と所要時間を記載した一覧は、references/capacity-length-and-network-evidence.mdにあります。選択した所要時間を入力としてsamber/dev-event-organizer-skills@event-schedule-designに渡してください。複数のイベントの平均を取って枠の長さを決めないでください。

ネットワークと依存関係への備え

手遅れになる前に、会場の接続環境について何をするかを示します。優先順位（既定の順序であり、絶対ではありません。Q4 と Q9 で順位が変わります）：

• 労力（調整、会場への働きかけ、設計上の制約を受け入れること）：ライブ依存関係をなくす > 会場のネットワーク環境を書面で確認する > フォールバックを用意して依存関係を明示する > ネットワークが使えると想定する
• 価値：会場のネットワークに問題があっても、セッションを実施できること：ライブ依存関係をなくす > 会場のネットワーク環境を書面で確認する > フォールバックを用意して依存関係を明示する > ネットワークが使えると想定する
• 価値：演習でトピックを教えられること：ネットワークが使えると想定する == フォールバックを用意して依存関係を明示する == 会場のネットワーク環境を書面で確認する > ライブ依存関係をなくす - この3つは同列だと考えられます。どれを選んでも、演習で扱える内容は一切変わりません。違うのは、事前に何を把握し、何を伝えていたかだけです。教えられる内容からトピックを削るのは4つ目だけです。
• 効率：フォールバックを用意して依存関係を明示する > 会場のネットワーク環境を書面で確認する > ネットワークが使えると想定する > ライブ依存関係をなくす

⚠️ レジリエンスの軸は、労力の軸と同じ順序です。 段階の違いを分けるのは内容の軸だけです。そのため、依存関係をなくす選択肢は最初ではなく最後に置かれています。

• フォールバックを用意して依存関係を明示する - 既定の選択肢で、ほとんど手間がかかりません。あるワークショップでは「クラウドベースの ClickHouse インスタンスを使用するため、インターネットが必要です」と説明し、別のワークショップではリモートラボへのインターネットアクセスを求め、参加者側のフォールバックを明記しています。「（Wi-Fi またはご自身のモバイルデータをご利用ください）」。このフォールバックは費用負担を参加者に移すものであり、ローミングデータを利用できない海外参加者もいます。告知時にその点を伝えてください。こうしたセッションを妨げるのは、帯域幅よりもポリシー上の制限です。VPN、広告ブロッカー、ブロックされたプロトコルなどが原因になります。また、共有の出口回線も問題になります。会場の1つのアドレスの背後にいる40台のノート PC が、レジストリの匿名プル制限や API キーのクォータに同時に達することがあります。原因の一覧はreferences/capacity-length-and-network-evidence.mdに記載されています。
• 会場のネットワーク環境を書面で確認する - Q9 と Q4 に応じた適用条件です。演習で一般的でないプロトコル、ポート、デバイスクラスが必要な場合、または会場からまだ回答がない場合は、回答を確認してください。問題になるのは容量ではなくポリシーです。MLH は主催者に会場のインフラ担当者と連携し、「IoT などのデバイスは標準的な大学ネットワークではブロックされることが多いため、ネットワークで許可されていることを確認する」よう伝えています。また、公開されているあるワークショップの参加要件は「（RDP プロトコルが許可されていること）」が条件です。会場には、samber/dev-event-organizer-skills@event-venue-sourcing がすでに尋ねている質問を書面で送り、デバイス数とプロトコルの一覧も併せて確認してください。
• ライブ依存関係をなくす - 最も選択しにくい方法です。レジリエンスと労力の両方で最上位にあり、コンテンツを犠牲にする唯一の段階です。適用条件は、会場が Q9 への回答を拒否する場合、過去の開催回で会場のネットワークに障害があった場合（Q12 に対応）、またはトピックが本当にネットワークを必要としない場合です。併せてできる、手間のかからない対策が2つあります。
  • MLH が示す理由も添えて、参加者に事前ダウンロードを依頼してください。「イベント中のネットワーク負荷を軽減するため、ソフトウェアのドライバーや IDE を事前にダウンロードするよう、ハッカーに促してください」。
  • オフラインキットを会場に持ち込んでください。以前の Software Carpentry の講師向けヒントでは、「会場の WiFi で負荷に対応できない場合」に備えてレッスンファイルとインストーラーを入れた USB メモリを用意し、さらに「会場のネットワークが機能していない場合」に備えて WiFi ハブを用意するよう勧めています。これはセッション中に使える唯一のフォールバックです。
• 降格ではなく、削除する： Q3 または Q4 に、参加者がセッション中にダウンロード、インストール、認証を行う必要があると示されている場合は、この選択肢と上記の軸の項目からネットワークが使えると想定するを削除してください。会場全体で一斉にインストールする状況は、負荷ケースであって、単なる想定ではありません。まさにこのケースをなくすために、事前ダウンロードを依頼するのです。

会場で、そして終了後に

当日の進行に向けたワークショップ運営の仕組みについては、詳細と避けるべき例をreferences/coverage-and-room-mechanics.mdで確認してください。

• うまく収まることを期待するのではなく、立て直しの時間を計画に組み込みます。「ブレイクアウトセッション、トラブルシューティング、質問に対応する時間をスケジュールに組み込みます」。
• 前提条件を事前に案内していても、冒頭にマシンの確認を行います。Software Carpentryの以前のヒントでは「受講者のマシンを確認する時間を少なくとも20分」設けるよう推奨し、セットアップには「いずれにせよ必要になるため」30〜60分かかることもあると警告しています。事前に前提条件を満たしてもらえば、この時間枠を短縮できますが、なくすことはできません。
• 会場の規模に合わせてオープニングを調整します。「参加者が少ないワークショップでは、アイスブレイクから始めることをおすすめします」。
• 困っていることを打ち明けるハードルを下げます。MLHは、これを講師の責任として明確に示しています。「コードレビューや質問が参加者にとってどれほど威圧的に感じられるかを、講師は十分に意識してください」。
• Carpentriesのヘルプフラグとして、2色の付箋を配ります。1色はノートパソコンの画面に貼って「助けが必要」、もう1色は「完了」を示します。フラグは挙手より「目立ちにくく」、受講者は作業を続けられ、会場前方からはクラスの状況を一目で把握できます。講師向けトレーニングでは、色覚障害のある参加者に配慮し、赤と緑より青と黄色を使うよう勧めています。
• ヘルパーには「できるだけ受講者自身に入力してもらう」よう伝えます。このルールがなければ、ヘルパーがキーボードを操作してしまい、参加者は修正から何も学べません。
• 各演習にチェックポイントを用意します。ステップごとにタグ付けしたブランチやソリューションフォルダーを設け、つまずいた参加者がさらに遅れを広げることなく、次のステップから合流できるようにします。
• ディスカッションの時間は、各グループに進行役を置き、約10人ずつのグループで行います。全員で一つの部屋を使ったラウンド形式にはしません。オープンスペース形式の少人数グループ運営の詳細は、samber/dev-event-organizer-skills@event-format-selectionで確認できます。
• 終了後も教材を活用できる場所を用意します。「ワークショップの終了後も、ハッカーがワークショップのトピックについて追加の質問をできるよう、SlackやDiscordにチャンネルを用意してください」。アクセス可能な期間を公開します（期間を明示した例は2つあり、72時間と、カンファレンス終了から1か月後までです）。

失敗につながる要因

• 条件を伴わない比率の流用。 Carpentries の「参加者 8～10 人につき 1 人」という目安は、ツールのデバッグができる講師とヘルパーが 2 人いることを前提としています。40 人の会場に運営ボランティアが 4 人いれば計算上は条件を満たしますが、サポート体制にはなりません。目安、その背景、調整内容をまとめて明記してください。
• アカウントを忘れ、ソフトウェアだけを列挙した前提条件。 公開されているワークショップでは、インストールと同じくらい頻繁に GitHub アカウント、ベンダーへの登録、または無料製品のアカウントが求められます。アカウントの準備には、新規登録、メール確認、場合によっては勤務先の SSO が必要です。しかも、全員が一斉に会場のネットワークを使う開始時刻に発生します。
• 環境を事前に用意することを安全な選択肢として扱う。 ローカルインストールの失敗をなくす代わりに、セッション全体を通じて会場の接続に全面的に依存することになり、さらに前述のコンプライアンス上のリスクも生じます。安全なのは、挙げた失敗に対してだけです。
• 別のイベントページからセッション時間をそのまま転用する。 各イベントの所要時間は、会場、参加者、演習内容に応じて決まっています。参考にするなら構成にとどめ、時間は転用しないでください。
• 会場の WiFi に関する回答を「問題ありません」で済ませる。 実際のネットワーク障害は、帯域幅の数値では把握できないポリシー上の制限が原因であることがよくあります。たとえば、特定のデバイス種別やプロトコルのブロック、VPN、広告ブロッカーなどです。
• 参加者が 10 人を大きく超えるワークショップで、会場全体のディスカッションを行う。 全員が順番に発言するだけでセッション時間を使い切り、発言しない人が半数を占めます。対策：各グループに進行役を 1 人置き、10 人程度のグループに分けます（「会場で、そして終了後に」）。
• 形式の決定を蒸し返す。 ワークショップ当日を開催すべきか、料金をどう設定するかという話に逸れた場合、それは samber/dev-event-organizer-skills@event-format-selection の範囲であり、すでに決定済みです。
• 参加者側の失敗と制作上の失敗を混同する。 参加者のノートパソコンで依存関係をインストールできないのは、こちらの問題です。録画でカメラ映像が途切れるのは samber/dev-event-organizer-skills@event-production の範囲です。

測定

2～3 個選びます。次回の開催内容を変更することになる結果を事前に決め、指標とその判断基準をセッション前に書き留めてください。

• 開始時点で準備ができている参加者の割合（独自設定）：到着前に前提条件を満たしていた参加者の割合です。前提条件の段階を引き上げるべきかどうかを判断する指標で、事前確認の結果を使うか、会場の入口で尋ねることで把握できます。
• 開始前後の自信度（参考となる慣例）：教える特定のスキルについて、「自分には……する能力があると自信を持っている」といった短い評価を、セッション開始前と終了時に尋ねます。ここで挙げた指標のうち、明確な先例があるのはこれだけです。Carpentries は、実践的な技術スキルを学ぶ何千ものワークショップで、まさにこの 2 回のアンケートを実施しています。2018 Data Carpentry の実施前・実施後アンケートの報告では、プログラミングを使ってデータを扱うことへの自信が「33% から 61% に」上昇したと報告されています。この先例は、開発者カンファレンスではなく、科学者向けの研究コンピューティング研修に関するものです。また、実際のタスク完了状況ではなく、自己申告の自信度を測定しています。数値ではなく慣例を参考にしてください。
• 演習の開始数と完了数（独自の目標設定）：最後の演習まで到達した参加者数です。各演習で完了の印を数え、参加者がどこで減ったかを確認します。会場が満員なのに差が大きい場合はサポート体制が原因です。参加者が少ないのに差が大きい場合は、前提条件が原因です。
• サポートを受けるまでの待ち時間（独自の目標設定）：ヘルプの合図を出してから対応されるまでの時間です。目標は独自に設定してください。待ち時間が長い場合は、サポート体制の段階を上げ、より対応力のあるヘルパーを増やす必要があります。
• セッション後の教材利用状況（独自設定）：告知した期間内における、公開教材へのアクセス数です。これは 実践演習なし の段階を正直に評価する方法でもあります。教材だけで学習が続けられるなら、会場での参加は必須ではありません。
• 別途チケットを販売するワークショップ当日のチケット販売数は、ここではなく samber/dev-event-organizer-skills@event-format-selection の範囲です。

呼び出し例

• 「40人向けに3時間の Kubernetes ワークショップを開催します。ヘルパーは何人必要で、参加者には何をインストールしてもらえばよいですか？」
• 「昨年のワークショップ当日は、セットアップ中に会場の WiFi が使えなくなり、うまくいきませんでした。今年は対策してください。」
• 「実習形式で開催すべきでしょうか。それともデモを録画してリポジトリを公開するだけにすべきでしょうか？」
• 「LLM ワークショップの前提条件のセクションを書いてください。演習にはクラウドコンソールとベンダーアカウントが必要です。」

期待される出力：セッションごとの実施シート。次の項目を含めます。

• 実習形式で実施するかどうかと、その理由。
• 定員と、上限を決める3つの要因のうちどれが制約になったか。
• ファシリテーターの配置人数と、その規模の根拠。
• 前提条件を、必要な知識、マシンの状態、アカウントに分けて記載。
• ネットワークの方針と、会場からの回答。
• 教材と、利用可能な期間。
• 次回開催時に各選択を見直すきっかけとなる条件。

ひとまとめにせず、セクションごとに提示して検証を受けてください。

ハーネスに永続メモリがある場合は、制約となった定員とその上限要因、実際に配布した前提条件シート、当日に実際に発生した問題、会場からのネットワークに関する書面での回答を記録してください。次回はそれを基に始めれば、改めてすべてを導き出す必要はありません。

参考資料

• references/coverage-and-room-mechanics.md - 4段階のサポート体制を詳しく説明し、否定例とともに、ワークショップ中および終了後の運営方法、メンター方式との違いを記載しています。
• references/prerequisite-and-environment-sheet.md - 前提条件の資料です。3つの内容分類、プロビジョニング済み環境と両方の手段を用意する段階、教材とアクセス可能期間、コンプライアンスレビューのきっかけに加え、記入例と否定例を記載しています。
• references/capacity-length-and-network-evidence.md - 3つの上限、需要投票による部屋割りの仕組み、イベントごとに公開されているセッション時間、注意点を含む密度比、発生原因が特定されているライブ障害について記載しています。

同じコレクションの関連項目：

• samber/dev-event-organizer-skills@event-format-selection - ワークショップ開催日やトラックの有無、前後の構成、チケット販売方法を決定します。このスキルでは、それらを所与のものとして扱います。
• samber/dev-event-organizer-skills@event-schedule-design - セッションを時間割に配置し、その前後のバッファを決めます。このスキルで設定した定員と時間を使用します。
• samber/dev-event-organizer-skills@event-talk-selection - さまざまな形式の提案を選定します。実習形式の提案は、講師が提示された定員で実施できるか、演習の規模を拡大できるかを基準に評価します。これらはこのスキルで扱う問いです。
• samber/dev-event-organizer-skills@event-venue-sourcing - ここで作成したワークショップ固有の部屋、電源、ネットワーク要件を、会場選定の入力として受け取ります。
• samber/dev-event-organizer-skills@event-accessibility-inclusion - 必要な配慮や、部屋に発行される認証情報を含む参加者データについて基準を定めます。
• samber/dev-event-organizer-skills@event-volunteers - ファシリテーターの構成で必要とされる人員を募集して説明を行い、このスキルが依拠するロジスティクスとコンテンツの境界を管理します。