> ## Documentation Index
> Fetch the complete documentation index at: https://lib.findy.co.jp/llms.txt
> Use this file to discover all available pages before exploring further.

# オンラインイベントの企画・運営の進め方

> オンラインイベントの特性を整理し、企画・準備・当日運営・実施後の4フェーズに沿って、各段階で決めることと進め方を解説します。

## 概要

オンラインイベントとは、登壇者と参加者が一か所に集まらず、配信サービスやビデオ会議サービスを通じて参加するイベントです。DevRel（Developer Relations）に取り組む企業にとっては、比較的少ない費用で繰り返し開催できるため、自社主催イベントの代表的な形式になっています。

このページでは、技術をテーマにしたオンラインイベントの運営方法を扱います。まずオンラインという形式の特性を整理し、続いてイベント運営の4フェーズを定義して、フェーズごとに必要なことを順に解説します。

## オンラインイベントの特性

オンラインイベントには、オフラインのイベントと異なる性質が4つあります。いずれも、ある方向には届く範囲を広げ、別の方向には制約を生みます。イベントの録画を後日公開することをアーカイブ配信と呼びます。

| 性質 | 広がること | 制約になること |
| - | - | - |
| 到達範囲 | 場所を問わず参加でき、規模は会場の収容人数ではなく、配信サービスの定員で決まる | 参加者の画面上にある他のあらゆるものと注意を奪い合う |
| 参加のハードル | 移動がないため、当日の申し込みや途中からの参加ができる | 申し込みの負担が小さいぶん、申込者の一定数は参加しない |
| 双方向性 | 質問がチャットやQ\&Aツールで文字として届くため、発言に慣れていない参加者も質問しやすい | 登壇者は会場の空気を読めず、配信上の沈黙は数秒で長く感じられる |
| 録画 | アーカイブ配信によって、開催時刻に参加できなかった人にも内容を届けられる | 録画が後から公開されると分かっている参加者は、ライブでの参加を見送りやすい |

このページで扱う実践の多くは、これらの性質から導かれます。途中から参加する人がいるため、スライドに話す内容を書いておく必要があります。会場の空気を読めないため、ファシリテーションと質問対応に専任の担当者を置きます。

## イベント運営の4フェーズ

イベントの運営は、企画・準備・当日運営・実施後の4つのフェーズに分かれます。各フェーズで決めたことが、次のフェーズの前提になります。

```mermaid theme={null}
flowchart LR
    A["企画<br/>目的・ターゲット・<br/>指標"] --> B["準備<br/>登壇者・タイトル・<br/>集客"]
    B --> C["当日運営<br/>ファシリテーション・<br/>質問対応"]
    C --> D["実施後<br/>アンケート・<br/>振り返り"]
    D -. "次の企画へ" .-> A
```

イベントの結果の大半は、最初の企画フェーズで決まります。登壇者・タイトル・集客はいずれも企画で決めた内容に合わせて選ぶため、目的やターゲットが曖昧なままでは、準備を丁寧にしても進行が円滑でも、届けたい相手には届きません。

実施後のフェーズは企画へ戻ります。アンケートと振り返りで分かったことが次のイベントの企画の材料になるため、4つのフェーズは一直線ではなく循環になります。

> [!NOTE]
>
> 気軽なLT会やもくもく会のような軽い形式では、この一連の流れをすべて踏む必要はありません。4フェーズが効果を発揮するのは、明確なターゲットと到達したいゴールがあるイベントです。

## 企画

企画とは、イベントを何のために、誰に向けて開催し、結果をどう判断するかを仮に決めることです。それぞれを1文で言えるようになった時点で、企画は固まったと言えます。

### 目的を1つに絞る

1つのイベントには目的を1つだけ置きます。目的が複数あると、後の判断をそれぞれ別の目的で正当化できてしまいます。その結果、準備を終えてから、選んだ切り口がどの目的にも十分に合っていないと気づくことがよくあります。

### ターゲットを特定し、直接聞く

ターゲットを具体的に定めます。役割、そのテーマへの習熟度、イベントから持ち帰りたいものまで言葉にします。そのうえで、業務でその技術を使っているエンジニアなど、ターゲットに当てはまる人に直接聞いて企画を検証します。

企画が成り立つかどうかは、調べるよりも聞くほうが早く分かります。公開されている情報からは何が存在するかは分かりますが、参加したいか、何があれば時間を使う価値があるかは、ターゲット本人にしか答えられません。聞く前に、誰に来てほしいか、ゴール、相手から何を知りたいかを書き出しておきます。

### 目的を測る指標を置く

目的をどう測るかを事前に決めておきます。指標がないと、実施後のフェーズで結果を照らし合わせる基準がありません。

| 種類 | 例 |
| - | - |
| 定量 | 申込数、参加率、イベントから案内したページへの遷移数 |
| 定性 | アンケートの満足度、参加者が何を得たかを示すアンケートコメント |

### 技術の成熟度を記事の質で見極める

特定の技術をテーマにするイベントでは、時期が重要です。早すぎると話せるほどの経験を持つ登壇者がおらず、遅すぎると入門を求めていた層はすでに離れています。その技術について公開されている記事の質が、判断の目安になります。

| 世に出ている記事 | 時期の判断 | 理由 |
| - | - | - |
| まとめ記事や発表の紹介のみ | 早すぎる | 実際に使った人がまだ少ない |
| サンプルコードやチュートリアル | 微妙 | 登壇で語れるほどの知見がまだない |
| 実装の記録やハマりどころ | 適期 | 業務で使い始めた人が出てきている |
| 本番運用の導入事例のみ | 対象が狭い | これから導入する層には響かなくなっている |

SNSでの話題性と実際の需要は一致しません。判断の基準は、ターゲットのエンジニアがその技術を使ってみたいと思えるかどうかです。

### 仮決めとリサーチを往復する

企画を1回で決め切ろうとしません。仮に決め、それが成り立つかを調べ、修正します。この往復を重ねるたびに、企画が具体的になります。

企画を言葉にできないときは、たいてい仮決めの検証が足りていません。登壇者の人選や形式など判断に迷う場面では、ターゲットとゴールという2つの軸足に立ち返り、それに適う選択肢を選びます。

### ボツを積極的に出す

企画をボツにすることは、企画の通常の結果であり、失敗ではありません。次のいずれかに当てはまる場合は、見送るか時期をずらします。

* 前提を裏付ける発信や実践者が見つからない
* 同じテーマのイベントを、ほかの主催者が最近開催している
* ターゲットまたはゴールを決め切れない

こうした兆候を押し切って進めた企画は、集客につながりにくくなります。ボツにした企画は、後の企画の材料になることが少なくありません。

最後に、運営する人自身がそのイベントを開催したいと思えているかを確認します。企画と準備には継続的な労力がかかり、運営側が関心を持てないテーマでは、その労力を保ちにくくなります。

### 企画のネタをどう見つけるか

ネタは、エンジニアが技術について語っている場所を観察することで見つかります。主な情報源は次のとおりです。

* エンジニアが仕事について発信しているSNSのアカウント
* ソーシャルブックマークサービスの技術系タグ
* 各社が公開しているテックブログ
* 技術書や技術雑誌の特集
* エンジニアが読んだものを共有している社内のチャットチャンネル
* ほかの主催者が開催しているイベント

気になったキーワードは、意味がまだ分からないものでも一覧に溜めておきます。短期間のうちに複数の情報源で見かける、あるいは名の知れた実践者が言及するなど、一定の閾値を超えたキーワードから調べ始めます。

社内のエンジニアも情報源になります。ある技術のどこに面白みを感じるかを聞きます。基本的な話で終わらないよう、先に自分で調べてから聞きます。

過去に反応が良かったイベントも、企画の出発点として使えます。登壇者・テーマ・形式のどの要素が反応につながったかを特定し、その要素を次の企画に活かします。

## 準備

準備は、企画を、ターゲットが見つけて参加できるイベントに仕上げるフェーズです。登壇者への打診、タイトルの作成、登壇者との事前すり合わせ、集客を扱います。

### 登壇者に打診する

打診の文面では、なぜその人に依頼するのかが伝わるようにします。相手の記事や登壇のうち読んだものに触れ、それが企画にどう合うかを書きます。一斉送信ではなく、調べたうえでの依頼だと相手に分かるようにするためです。自分が何者か、どんなイベントかも明記します。

文面はスマートフォンで読める長さに収めます。打診は断られたり返信がなかったりすることが多いため、1枠につき複数の候補を用意しておきます。

### タイトルを決める

ターゲットは、タイトルを見て自分に向けたイベントかどうかを判断します。ターゲットが反応するキーワードを入れ、何を扱い、参加者が何を持ち帰れるかが伝わるようにします。

次のような表現は避けます。一時的に注目を集めても、回を重ねるうちに信頼を損ないます。

* 不安を煽る表現や過度に否定的な表現（ある技術がまもなく使えなくなると断じるなど）
* 特定の技術や職種を他より優位に置く表現
* 年齢などの属性を強調し、それ以外の人を遠ざける表現
* すでに強い負のイメージが定着しているテーマ

タイトル案は、事前すり合わせで登壇者に見せます。登壇者が違和感を持つ言い回しのままだと話しにくくなり、登壇の内容と合わない期待を参加者に抱かせることになります。

### 登壇者と事前にすり合わせる

登壇者ごとに、30分程度の事前すり合わせを行います。企画の背景、その人に依頼した理由、ターゲットとゴールを説明します。同じ技術テーマでも聞き手によって話すべき内容が変わるため、登壇者が話す内容を決めるにはこの情報が必要です。

登壇テーマは、こちらから指定するのではなく、聞きながら詰めます。そのテーマのうち話せなさそうな部分と、深掘りすると面白くなりそうな部分を尋ねます。

登壇者には、話す内容をスライドに書いてもらうよう依頼します。途中から参加した人が内容に追いつけるうえ、運営側も内容を把握して事前に質問を用意できます。

### 集客する

集客とは、イベントをターゲットに知らせ、その認知を申し込みと当日の参加につなげる活動です。最も効果があるのは登壇者からの告知です。登壇者の活動をすでに追っている人に直接届くためです。

登壇者は、自分が楽しみにしているイベントを告知します。その気持ちが生まれるのが事前すり合わせの場です。登壇者自身がやりたいと思えるイベントにし、そのうえで公開後の告知への協力をその場で依頼します。イベントの公式アカウントから登壇者をメンションして投稿すると、登壇者が共有しやすくなります。

リマインドは前日と当日に送ります。参加者が何を聞けるのかを短く具体的に伝えると、関心が保たれ、直前のキャンセルが減ります。

## 当日運営

当日の運営側の役割は、ターゲットが求めて来た内容から、イベントがそれないようにすることです。そのために、開始前の確認、明確な役割分担、ファシリテーションが必要になります。

### 開始前に確認する

開始の15〜30分前に登壇者と打ち合わせます。このイベントで参加者に何を届けるかを改めて確認し、音声・画面共有・配信の操作を確かめます。

### 役割を分担する

ファシリテーターが会話に集中できるよう、裏方の作業を担当者に割り当てます。

| 役割 | 担当すること |
| - | - |
| チャットと質問 | チャットを見守り、登壇者への質問を集めて整理する |
| SNS | イベントに関する投稿を確認し、反応する |
| タイムキープ | 進行時間を管理し、登壇者に合図する |
| 登壇者との連絡 | 配信中に登壇者と運営側のあいだで連絡を中継する |
| 次の導線 | リンクを共有し、イベント後に参加者が進む先を案内する |

必要な人数は参加者の規模に応じて増えます。目安として、参加者が30人程度までなら1人、100人程度までなら2人、それを超える場合は3人以上を置きます。

### 会話をファシリテーションする

ファシリテーションは、会話を途切れさせず、登壇者のあいだで偏りなく進めるための働きかけです。パネルディスカッション形式のセッションでは、次の点に注意します。

* **沈黙を長く作らない。** 配信では数秒の間でも問題が起きたように感じられます。セクションが早く終わったときのために、予備の質問を用意しておきます。
* **ファシリテーター自身が話しすぎない。** 参加者は登壇者の話を聞きに来ています。
* **登壇者どうしで話題を振り合えているかを見る。** ファシリテーターだけが質問するセッションは、インタビューの連続になります。
* **発言量の偏りに注意する。** 1人が話し続ける前に、発言の少ない登壇者に話を振ります。

冒頭で、本日話すことと話さないことを示します。参加者の期待値を調整でき、もともと扱う予定のない内容を期待して来た人の不満を減らせます。

### 質問にはすべて答える

時間の許す限りではなく、寄せられた質問にはその場ですべて答えることを原則にします。そのための時間を確保しておきます。90分のイベントであれば、質問に最低30分をあてます。申し込み時に質問を募り、事前に登壇者と共有しておくと、この時間を埋めやすくなります。

当日に答えきれなかった質問には、参加者へのお礼の連絡などで後日回答します。

## 実施後

実施後のフェーズでは、結果を目的と照らし合わせ、分かったことを次の企画に持ち込みます。

参加者アンケートは、鮮度の高いうちに分析します。目安は翌営業日までです。登壇者とも振り返りを行います。登壇者は、参加者からは見えない企画や進行についての意見を持っていることがよくあります。

結果は、企画で置いた指標に照らすとともに、次の点を両面から見ます。

| 観点 | 見ること |
| - | - |
| 定量 | 類似テーマの過去のイベントと比べた申込数と参加率、同じ層に向けたほかのイベントと開催日が重なっていなかったか |
| 定性 | アンケートコメントに共通する良かった点と改善点、参加者の習熟度が想定したターゲットと合っていたか |

分かったことを次の企画に反映します。次の企画への反映が成り立つのは、企画の段階で目的・ターゲット・指標を書き残し、企画から開催までに変えた点を記録している場合だけです。こうした記録がなければ、結果を何と比べればよいかが分かりません。

## 関連ページ

> [card] [DevRelの役割](https://lib.findy.co.jp/ja/devrel/engineering-culture.md)
>
> 企業がそもそもなぜイベントを開催するのか、コミュニティの役に立ち続けるための原則を扱います。

> [card] [エンジニア育成](https://lib.findy.co.jp/ja/organization/engineer-growth.md)
>
> チームの勉強会も、企画・開催・振り返りという同じ循環を小さな規模で回しています。

> [card] [開発生産性の考え方](https://lib.findy.co.jp/ja/productivity/why-measure.md)
>
> 指標の選び方と読み違えの避け方は、イベントの結果を判断するときにもそのまま当てはまります。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.