概要
オンラインイベントとは、登壇者と参加者が一か所に集まらず、配信サービスやビデオ会議サービスを通じて参加するイベントです。DevRel（Developer Relations）に取り組む企業にとっては、比較的少ない費用で繰り返し開催できるため、自社主催イベントの代表的な形式になっています。 このページでは、技術をテーマにしたオンラインイベントの運営方法を扱います。まずオンラインという形式の特性を整理し、続いてイベント運営の4フェーズを定義して、フェーズごとに必要なことを順に解説します。オンラインイベントの特性
オンラインイベントには、オフラインのイベントと異なる性質が4つあります。いずれも、ある方向には届く範囲を広げ、別の方向には制約を生みます。イベントの録画を後日公開することをアーカイブ配信と呼びます。
このページで扱う実践の多くは、これらの性質から導かれます。途中から参加する人がいるため、スライドに話す内容を書いておく必要があります。会場の空気を読めないため、ファシリテーションと質問対応に専任の担当者を置きます。
イベント運営の4フェーズ
イベントの運営は、企画・準備・当日運営・実施後の4つのフェーズに分かれます。各フェーズで決めたことが、次のフェーズの前提になります。 イベントの結果の大半は、最初の企画フェーズで決まります。登壇者・タイトル・集客はいずれも企画で決めた内容に合わせて選ぶため、目的やターゲットが曖昧なままでは、準備を丁寧にしても進行が円滑でも、届けたい相手には届きません。 実施後のフェーズは企画へ戻ります。アンケートと振り返りで分かったことが次のイベントの企画の材料になるため、4つのフェーズは一直線ではなく循環になります。気軽なLT会やもくもく会のような軽い形式では、この一連の流れをすべて踏む必要はありません。4フェーズが効果を発揮するのは、明確なターゲットと到達したいゴールがあるイベントです。
企画
企画とは、イベントを何のために、誰に向けて開催し、結果をどう判断するかを仮に決めることです。それぞれを1文で言えるようになった時点で、企画は固まったと言えます。目的を1つに絞る
1つのイベントには目的を1つだけ置きます。目的が複数あると、後の判断をそれぞれ別の目的で正当化できてしまいます。その結果、準備を終えてから、選んだ切り口がどの目的にも十分に合っていないと気づくことがよくあります。ターゲットを特定し、直接聞く
ターゲットを具体的に定めます。役割、そのテーマへの習熟度、イベントから持ち帰りたいものまで言葉にします。そのうえで、業務でその技術を使っているエンジニアなど、ターゲットに当てはまる人に直接聞いて企画を検証します。 企画が成り立つかどうかは、調べるよりも聞くほうが早く分かります。公開されている情報からは何が存在するかは分かりますが、参加したいか、何があれば時間を使う価値があるかは、ターゲット本人にしか答えられません。聞く前に、誰に来てほしいか、ゴール、相手から何を知りたいかを書き出しておきます。目的を測る指標を置く
目的をどう測るかを事前に決めておきます。指標がないと、実施後のフェーズで結果を照らし合わせる基準がありません。技術の成熟度を記事の質で見極める
特定の技術をテーマにするイベントでは、時期が重要です。早すぎると話せるほどの経験を持つ登壇者がおらず、遅すぎると入門を求めていた層はすでに離れています。その技術について公開されている記事の質が、判断の目安になります。
SNSでの話題性と実際の需要は一致しません。判断の基準は、ターゲットのエンジニアがその技術を使ってみたいと思えるかどうかです。
仮決めとリサーチを往復する
企画を1回で決め切ろうとしません。仮に決め、それが成り立つかを調べ、修正します。この往復を重ねるたびに、企画が具体的になります。 企画を言葉にできないときは、たいてい仮決めの検証が足りていません。登壇者の人選や形式など判断に迷う場面では、ターゲットとゴールという2つの軸足に立ち返り、それに適う選択肢を選びます。ボツを積極的に出す
企画をボツにすることは、企画の通常の結果であり、失敗ではありません。次のいずれかに当てはまる場合は、見送るか時期をずらします。- 前提を裏付ける発信や実践者が見つからない
- 同じテーマのイベントを、ほかの主催者が最近開催している
- ターゲットまたはゴールを決め切れない
企画のネタをどう見つけるか
ネタは、エンジニアが技術について語っている場所を観察することで見つかります。主な情報源は次のとおりです。- エンジニアが仕事について発信しているSNSのアカウント
- ソーシャルブックマークサービスの技術系タグ
- 各社が公開しているテックブログ
- 技術書や技術雑誌の特集
- エンジニアが読んだものを共有している社内のチャットチャンネル
- ほかの主催者が開催しているイベント
準備
準備は、企画を、ターゲットが見つけて参加できるイベントに仕上げるフェーズです。登壇者への打診、タイトルの作成、登壇者との事前すり合わせ、集客を扱います。登壇者に打診する
打診の文面では、なぜその人に依頼するのかが伝わるようにします。相手の記事や登壇のうち読んだものに触れ、それが企画にどう合うかを書きます。一斉送信ではなく、調べたうえでの依頼だと相手に分かるようにするためです。自分が何者か、どんなイベントかも明記します。 文面はスマートフォンで読める長さに収めます。打診は断られたり返信がなかったりすることが多いため、1枠につき複数の候補を用意しておきます。タイトルを決める
ターゲットは、タイトルを見て自分に向けたイベントかどうかを判断します。ターゲットが反応するキーワードを入れ、何を扱い、参加者が何を持ち帰れるかが伝わるようにします。 次のような表現は避けます。一時的に注目を集めても、回を重ねるうちに信頼を損ないます。- 不安を煽る表現や過度に否定的な表現（ある技術がまもなく使えなくなると断じるなど）
- 特定の技術や職種を他より優位に置く表現
- 年齢などの属性を強調し、それ以外の人を遠ざける表現
- すでに強い負のイメージが定着しているテーマ
登壇者と事前にすり合わせる
登壇者ごとに、30分程度の事前すり合わせを行います。企画の背景、その人に依頼した理由、ターゲットとゴールを説明します。同じ技術テーマでも聞き手によって話すべき内容が変わるため、登壇者が話す内容を決めるにはこの情報が必要です。 登壇テーマは、こちらから指定するのではなく、聞きながら詰めます。そのテーマのうち話せなさそうな部分と、深掘りすると面白くなりそうな部分を尋ねます。 登壇者には、話す内容をスライドに書いてもらうよう依頼します。途中から参加した人が内容に追いつけるうえ、運営側も内容を把握して事前に質問を用意できます。集客する
集客とは、イベントをターゲットに知らせ、その認知を申し込みと当日の参加につなげる活動です。最も効果があるのは登壇者からの告知です。登壇者の活動をすでに追っている人に直接届くためです。 登壇者は、自分が楽しみにしているイベントを告知します。その気持ちが生まれるのが事前すり合わせの場です。登壇者自身がやりたいと思えるイベントにし、そのうえで公開後の告知への協力をその場で依頼します。イベントの公式アカウントから登壇者をメンションして投稿すると、登壇者が共有しやすくなります。 リマインドは前日と当日に送ります。参加者が何を聞けるのかを短く具体的に伝えると、関心が保たれ、直前のキャンセルが減ります。当日運営
当日の運営側の役割は、ターゲットが求めて来た内容から、イベントがそれないようにすることです。そのために、開始前の確認、明確な役割分担、ファシリテーションが必要になります。開始前に確認する
開始の15〜30分前に登壇者と打ち合わせます。このイベントで参加者に何を届けるかを改めて確認し、音声・画面共有・配信の操作を確かめます。役割を分担する
ファシリテーターが会話に集中できるよう、裏方の作業を担当者に割り当てます。
必要な人数は参加者の規模に応じて増えます。目安として、参加者が30人程度までなら1人、100人程度までなら2人、それを超える場合は3人以上を置きます。
会話をファシリテーションする
ファシリテーションは、会話を途切れさせず、登壇者のあいだで偏りなく進めるための働きかけです。パネルディスカッション形式のセッションでは、次の点に注意します。- 沈黙を長く作らない。 配信では数秒の間でも問題が起きたように感じられます。セクションが早く終わったときのために、予備の質問を用意しておきます。
- ファシリテーター自身が話しすぎない。 参加者は登壇者の話を聞きに来ています。
- 登壇者どうしで話題を振り合えているかを見る。 ファシリテーターだけが質問するセッションは、インタビューの連続になります。
- 発言量の偏りに注意する。 1人が話し続ける前に、発言の少ない登壇者に話を振ります。
質問にはすべて答える
時間の許す限りではなく、寄せられた質問にはその場ですべて答えることを原則にします。そのための時間を確保しておきます。90分のイベントであれば、質問に最低30分をあてます。申し込み時に質問を募り、事前に登壇者と共有しておくと、この時間を埋めやすくなります。 当日に答えきれなかった質問には、参加者へのお礼の連絡などで後日回答します。実施後
実施後のフェーズでは、結果を目的と照らし合わせ、分かったことを次の企画に持ち込みます。 参加者アンケートは、鮮度の高いうちに分析します。目安は翌営業日までです。登壇者とも振り返りを行います。登壇者は、参加者からは見えない企画や進行についての意見を持っていることがよくあります。 結果は、企画で置いた指標に照らすとともに、次の点を両面から見ます。
分かったことを次の企画に反映します。次の企画への反映が成り立つのは、企画の段階で目的・ターゲット・指標を書き残し、企画から開催までに変えた点を記録している場合だけです。こうした記録がなければ、結果を何と比べればよいかが分かりません。
関連ページ
DevRelの役割
企業がそもそもなぜイベントを開催するのか、コミュニティの役に立ち続けるための原則を扱います。
エンジニア育成
チームの勉強会も、企画・開催・振り返りという同じ循環を小さな規模で回しています。
開発生産性の考え方
指標の選び方と読み違えの避け方は、イベントの結果を判断するときにもそのまま当てはまります。