オンラインイベントの配信環境、会議的に作るか？放送的に作るか？「配信環境」の考え方と選び方

昨今の事情からイベントのオンライン化が進みましたが、必ずと言っていいほど話題になるのが**「配信環境ってどうしよう？」**です。

職業柄登壇が多いのですが、オンライン登壇を重ねることでわかってきたのが "配信環境" って言葉は、広い意味を持っている ということでした。
ここでは、その配信環境を分類しメリット／デメリットと、**どんな時にはどのパターンが良さそうなのか？**をまとめています。

「配信環境」は "制作" "送出" "視聴" の3つで成り立っている

「配信環境」は、以下の3つから構成されています。

• 制作: コンテンツ作成と、 "送出" へコンテンツの配給をする
• 送出: "制作" からコンテンツの配給を受けて、"視聴" へ配信をする
• 視聴: 配信されたコンテンツを見る

この辺は先輩である放送業界に学べるところです。"制作" は制作会社ですし、"送出" は放送局ですね。

「配信環境」と言ったとき、 送出から視聴までの部分を指すのか、それとも制作から視聴までのすべてを言っているのかで、意味や考慮すべきことが異なってきます。
ここが不明確だと「現場(制作)のコンテンツ配信(実は"配給")ってどうなってる？現場は新たなソフトウェアのインストール禁止だってよ！」といった問題が、最悪ケースだと配信直前に発覚しますのでお気を付けください。

オンラインイベントの「配信環境」のパターンは2つ

「配信環境」構成内容がわかったところで、オンラインイベントにおける配信環境を見てみると、「配給」と「配信」で利用するツールの組み合わせ方で**「会議パターン」と「放送パターン」**の2つに分類できます。

会議パターン: 配給と配信を同じシステムにする

"制作" からのコンテンツ配給と、"視聴" への配信を同じシステムで実現するパターンです。

例えば "制作" からのコンテンツ配給から、"視聴" への配信まで Zoom で行うといった形になります。

基本的に「会議のツール」を使うことから、 "送出" は土管(左から右へ流すだけ)ですし、"制作" と "視聴" の区別は実のところありません。ルール的に「あなたは制作ね、あなたは視聴ね(だからミュートしてね)」といった運用です。
例) 5/6の SORACOM UG 農業活用コミュニティ―は、 配給と配信を Google Meet にて行う会議パターンで行われました。

メリット

• 出欠席の確認や制御ができる
• 視聴側の顔出しや発話、チャットによる登壇者へのフィードバックや、スクリーン上での集合写真といった「盛り上がってる感」が出しやすい
• "制作" も "視聴" も含めて全員が使ったことがあれば(環境が整っていれば)、始める手間がとても低い

会議を円滑に進めることが目的であるツールを使うため、特にコミュニケーション機能による登壇者へのフィードバックが最大のメリットになるかと思います。

デメリット

会議ではメリットである機能が、放送的な使い方ではデメリットに働くことがあります。

• 接続規模
• 特に視聴(とされている人)に対してミュートやカメラの制御可否

視聴数が多くて後から来た "制作" の人が接続できなかったという泣ける話があったり、"視聴" とされた方がうるさいから他の人が音声をMuteしたのに、本人がMute解除してしまい荒らされるなど(最終的には kick-out したそうですが)と、対等であるがゆえの課題があるようです。
これらを解消するために、ホストやロールといった機能があるサービスもありますが、本質的には「サービス側の機能の有無」となります。

また "送出" は土管、すなわち編集といった機能は基本的に無いため、画作りや音作りにおいては "制作" に以下のような負担がかかります。

• アプリのインストールや更新、設定
• 音声ボリュームやノイズキャンセルといった調整
• 映像におけるクロマキー合成などの加工や調整

例としては、簡単にバーチャル背景を使いたければ Zoom を！そうでなければ無理です、、、といった事になります。
※ ソフトウェアを組み合わせればできますが、それは「負担」です。

ほかの問題としては、とあるサービスでセキュリティ上の問題が発覚したことで一時的に利用不可といった事が実際に発生しましたが、そうなるとお手上げということもあります。

放送パターン: 配給と配信を異なるシステムにする

"制作" からコンテンツ配給の(仕入れ)と、"視聴" への配信を異なるシステムで実現するパターンです。

例えば "制作:A" からは Google Meet で、"制作:B" からは Zoom でコンテンツが配給され、"視聴" への配信には YouTube Live を使うといった形になります。

基本的に「放送」であるため "制作" と "視聴" は明確に区別されます。
例) 5/26の SORACOM UG Tokyo #15は、配給を Google Meet、配信を YouTube Live という放送パターンで行われました。

メリット

• 接続規模の心配不要
• "視聴" から荒らされる心配無し
• "制作" の配給環境の負担減 (慣れたツールを使っていただける)
• 音声ボリュームやノイズキャンセルといった調整は "送出" で可能
• 映像におけるクロマキー合成などの加工や調整も "送出" で可能
• 配信サービスを変更しても "制作" や配給の影響が軽微

"視聴" への配信は、たとえば YouTube Live といった配信専用サービスの利用になるため、会議向けシステムとは桁が異なる規模で配信可能です。
また "送出" 担当が必ず存在することになるため、そこでの調整や加工も可能になります。

デメリット

会議では無いので、以下のような「人が見える」仕組みが薄くなります。

• 出欠席の確認 (リード獲得が絶望的)
• 視聴側の顔出しや発話、チャットによる登壇者へのフィードバックや、スクリーン上での「盛り上がってる感」が出しづらい
• "送出" 担当やシステムの構築

リード獲得が難しいとなると、マーケ部門は「うーん」となってしまう事、請け合いです。また "送出" 部分の構築の手間は大問題です。いわば放送局と同じ仕組みが必要ですので手間がかかります。

コラム的に: OBS Studio が話題になっている理由

昨今 OBS Studio を使った配信の話や Tips がネットでも話題となりますが、実際は様々な "制作" から配給を受けて、"視聴" へ配信できる、放送局と同じような事ができるソフトウェア(しかも無償) であるからこそ、話題となっているわけです。
Zoom などは "ミーティングのライブストリーム配信機能(Zoom で配給、YouTube Live に配信)" が搭載されるなど、サービス側が "送出" の機能を持ち始めています。

で、どっちがいいの？

「メリット・デメリットを検討して自己判断してください」という小学生並みの答えはさておき、私が注目しているポイントは 登壇者へのジャストインなフィードバックの有無 です。

登壇で欲しくなるのが視聴側からのフィードバックです。
聴講者の反応を見ながら状況に応じてその場で内容を厚くしたりスキップするしながら、時間内の学びを最大にする事を行っています¹。

会議パターンはコミュニケーションが取りやすいことから、チャットや映像、場合によっては音声で即時フィードバックを得られやすいですが、前述の通りデメリットも数多くあります。
そのことから、アンチハラスメントポリシー²が設定できる100名未満の無料イベントならば、会議パターンのメリットが効いてくると考えます。

上記の条件に当てはまらず、かつ、送出" の仕組みを作る・運営することができる場合は放送パターンとなるでしょう。
放送パターンでもリードを獲得を考えるならば、オンラインイベントに使えるチェックインシステムの紹介といった事を考える必要があるでしょう。

放送パターンでもフィードバックは欲しいよね

わかります。
ここは解決策が見いだせていないというのが現状かもしれません。

「楽屋チャンネル」で (ある程度の) 安心感

配給システムは統一しておき(たとえば Google Meetとか)、登壇中以外の方も視聴者として登壇中の方にフィードバックを送る(たとえば映像で頷くといった見えるリアクション)というのが考えられます。

要するに「配給側で "会議パターン"」を運用する形です。
このメリットは、"視聴" している方々との乖離がどの程度あるか未知数にはなりますが、精神安定には役立つ他、配給側のシステムを「ステージ裏」として利用できるため、例えば登壇中の方に対して運営からチャットで「あと～分です」といった伝達などにも使えます。（私は「楽屋チャンネル」と言っています）

登壇者の数がいる、もしくはタイムキーピング等の運営スタッフが割り当て可能な規模で使える方法です。

放送パターンにおける "視聴" からのフィードバック

YouTube Live だとチャットがありますが、Togetter 等のサービス連携ができないので「コンテンツの広がり」が無くなります。かといってチャットをOFFにし「他のサービスで！」は、リアクションや質問が減少します（要検証）。これは、特にスマホだとアプリを切り替える面倒が理由かと思います（要検証）。

いい方法をキボンヌ。

"送出" 構築のベストプラクティスは？

放送パターンは "送出" の仕組み作りが手間というデメリットを紹介しましたが、ここも知見が出てきています。

個人的には Amazon WorkSpacesで堅牢な配信を実現する は、ベストプラクティスです。
配給に Amazon Chime を使っている例になっていますが、ここを別のものにすることも可能です。(Amazon Chime なのは...筆者のお仕事柄...ですね)

放送パターンにおけるフィードバックも研究されているようなので、フォローしておくのはマストだぜ³。

あとがき

とあるイベントに参加した後、ついカっとなって書いた。後悔はしていない。
あの映画のタイトルに似てるようなそうでないような。気にしない。
「通信(CS)と放送(BS)」みたいな違い、、、というか同じだな。結局そういうことか。
そして放送業界はすごい。先人の知恵は最大限生かす主義だ。

EoT

1. だからオーバーランする。
   オフラインなら見てわかりますが、オンラインではそれが叶わないため、「このネタ、届いてるのかな？」という不安が常にあります。 ↩

2. 講演者及び参加者が自由に議論ができることを保護するためのポリシー
   仮に荒らされても強制退出させられる大義名分が存在しますし、ソフトウェア周りのサポートも「無料なんだよね、ごめん」と押し通す(?)こともできるかもしれません。
   また 、「リードの獲得」をが要件に入る場合も、会議パターンにする必要がありますが、デメリットをどうやって排除するかは思案のしどころです。 ↩

3. なんだろう、このダサいボキャブラリーは。私のボキャブラリーの限界がここにある。全然関係ありませんが、昔ザ・コンの裏手にあったソフマップの「モグリだぜ！」の看板知ってる方がいたら、仲間です。 ↩