= バーチャルオンラインミーティングに関するメモ＆検討 =

全体的にラフな事前検討です。

 * 2020-Jun後半に検討した内容をベースとしています（デザイン意図：「2020-Sepまでになにかできればいいんじゃないかな！」）。
 * 実際の開催が2021-Janにスリップしているのは見なかった方向で……。

== 準備に関係すること ==

基本路線

「参加する人」以外の人員は以下となる。アドリブ要素をできるだけ削るには、しゃべる人 + 3がスタッフとして必要。

 * 「しゃべる人」x N
 * 「配信する人」x 1 (2が理想)
 * 「セッションモニター」 x 1 ; 「しゃべる人」とか「配信する人」（予備）がロールスイッチして対応していくのはアリ

基本路線の内訳

 * しゃべる人：発表したりMCする人は、任意のWeb会議（ZoomなりJitsiなり）で集まる。コンテンツの事実上の生成がここ。
   * 『マイクを持っていること』以外の条件はなさそう。画面共有はそこまで強烈な回線でなくてもなんとかなる。はず。
 * 配信する人：Web会議出席者の誰かが、メイン画面をなんらかの方法で配信系に流し込む。
   * 別マシンからHDMIキャプチャしてそれをOBSなりでライブに流し込む。You``Tube Liveがたぶん安定アプローチ。メインとサブを持つのが安定的かなーどうかなー。
   * 配信系チャネルそのものを複数用意しておくか、複数方面から流し込むかはちょっと悩む余地がある。
   * 要求される回線はかなり大変。安定的に70Mbps+ を出し続けられる人が必要。
 * セッションモニター：これらのスタッフとはまた別に、いわゆるセッションモニター（Web会議に参加しつつ、ライブストリームの様子を見る観客互換の人）が居ると配信トラブルを検知しやすい。

参加者は普通にライブ配信を見る。反応とかはライブ配信システムに乗っかる。

=== COVID-19に関するラフな見積もり ===

 * 2020中に状況が改善する可能性は皆無と思っておく必要がある。
   * 利用可能な安定的なワクチンは2020の間には大量生産＆事前投与できるようにはならない。ムリ。
   * つまりfocalとgroovyは少なくともバーチャル。たぶんg+1（21.04）もバーチャルになると思っておくのが良い。
   * 「新しい生活様式」ベースでsocial distancingしながら開催！　という手を完全に否定するものではないものの、集まれる人数は80人会場で20人とかそういうレベルになるのと、『歓談とかできません』『食事の供給はできません』『しゃべる人も離れて頑張ります』という状態になる。それならもうバーチャルでいいよね！　という感じ。
 * 2021の後半になったら何とかなってるんじゃない？　とは、言えると言えば言える。つまり21.10はバーチャルではなくなるかもしれない。
   * ワクチン耐性株な新種とか出てこなければいいけどね……。
   * 新しい生活様式へのシフトが順調に進むと「人間が集まるイベントやるとか不道徳じゃありません？」という状態になる可能性もある。
   * なんか状況を見ている限りでは、2022までムリじゃね？　というか2022になってもムリじゃね？　みたいな気分になってきている。ワクチンは現状、抗体形成だけをターゲットにしていて、「インフルエンザ予防のためのワクチン」と同レベル。CoVは変異が速いのでそこまで機能する感じもしないし、そもそも抗体の持続が三ヶ月とかだっちゅーねん。
 * つまりコストをかけて考えておく価値が、おそらくある。

=== ソフトウェアとサービス ===

====  『自前で配信』というアプローチは基本的に捨てる ====

短い結論：そんなインフラも予算もない。有償サービスを使うのがベター。無償で頑張るのは止めよう。

ライブサービス使わずに全部ミーティングでGo！　という路線はどうか？

 * 基本デザインとしては、「バーチャルミーティングサービスを利用してメイン画面を作りつつ、それをライブサービスに流し込む、参加する人はTwitterなりライブサービスのコメントシステムでコメント」というアプローチ。
   * 要するにコレをなぞるコース。https://blog.cybozu.io/entry/2020/04/01/163617
 * ライブサービスへ流し込むのではなく、全てをバーチャルミーティングにするのは厳しい。
   * 100人までは参加できるので、イベント規模的にはマッチしている。
     * が、100人が同時にしゃべることができるわけではなく、10人ぐらいのしゃべる人＋90人の聞く人、みたいな構図になる。
       * 実イベントで発生するのはもう少し異なる風景になるハズ。
       * 全員がしゃべることが可能なことに意味がある！　という側面はあるにはあるが、ミュートにしてない人がいきなりヒワイな単語を叫び始めました！　みたいな事故が起きたら終了なので、参加者を制御できないイベントではまあ採用できない。
         * マイク有効にしてjoinしろ、というのはまあ、心理的なハードルもたいがい高い。ムリ。
   * イベントの意義として、「その場で質問できるのがメリット」という部分はあるにはあるが……。
   * そもそも、バーバルに質問したい人はもともと母数が少ない。
     * バーチャルにやるとさらに母数が減る。配信される状態で質問するにはけっこう心理的負荷が大きい。
     * 文字ベースの質問をセミリアルタイム（1-2分ディレイ）で拾っていければイベントとしてのインタラクティブ性は保持できる。

バーチャルミーティングやライブサービスを自前でやる路線はどうか？

 * バーチャルミーティングをホストしつつライブ配信、というだけでも、帯域にヘビーな負荷をかけることになる（上り下りを最低20Mbps、可能なら40Mbpsぐらいで安定的に提供できる必要がある）。
   * 普通のご家庭でこの条件を満たすのは意外と厳しい。1Gbpsや10Gbps線でも下回る瞬間はあるで？
   * 少なくともライブ配信部分はなんらかのサービスを利用する必要がある。
     * You``Tube Liveとか
   * バーチャルミーティング部分も、たいていは何らかのサービスを利用する必要がある。
     * ZoomなりMS Teamsなりを使うのがおそらく妥当。
       * 宗教上の理由で使えない人もいると思うので、Zoomは止めた方がいいかもしれない。
       * MS Teamsは……妥協してくれるかな？　かな？
     * JitsiやBBBでやれば！　と一瞬思ってしまうが、参加人数 x 10Mbpsをどうやって保証するというのか？（クラウド上に立てればそこそこイケるかもしれないが、コストを考え始めるとあまり……）
       * 結局画像をライブ配信サービスに流し込むので、そこまで頑張らなくていいのでは……という結論になる。
       * FLOSSで実現したい！　という気分はあるし、わかる。わかるがしかし！　人類にはできることとできないことがあるのだ！　無茶はいけない！
 * 回線クレー、みたいな方向になるとサービスを真面目に設計する方向に突入することになる。脳みそは適切なサービスを使ってイベントをデザインする方向に使いましょう。
   * リソースは有限である。

=== ロジスティクスとハードウェア ===

ラフには以下のような感じを前提として前提と装備品を検討する。
 * なんらかのサービスを使ってバーチャルミーティングをホストする。
 * バーチャルミーティングの画面をライブサービスに流し込む。
   * バーチャルミーティング内蔵の機能でもいいし、HDMI-UVCキャプチャデバイスを経由してもOK。方法はたぶんどうでもいい（PCを複数台準備して安定させやすい側面もあるので、HDMI-UVCキャプチャコースのほうが安全かもしれない……しれないが、HDMI-UVCキャプチャも危ないのでまあ唯一解でもない）。

「しゃべる人」「参加する人」「ミーティングを配信する人」に分けて考える。ここでの「しゃべる人」は「プレゼンを提供する人」と同義。

 * 「しゃべる人」：少なくともマイクとヘッドセットとPCが必要。静かな環境か、ノイズキャンセリングのための仕組みも必要かもねん。
 * 「参加する人」：ライブサービスに接続できるデバイスさえあればOK。コメントするためのアカウントは必要かも！（なのだが、TwitterかYou``Tubeはまあ、たいていの人が持ってるよね……）
 * 「ミーティングを配信する人」：PCと、配信に対して安定的な回線と、場合によっては配信のためのキャプチャデバイスが必要になる。これは「しゃべる人」と兼ねてもいいかもしれないが、「あなたのしゃべる番です」という状態で配信エラーが起きたらパニックするのでちょっとツラい。やめてあげて！

==== からあげ ====

 * 参加者のお手元にからあげを転送するKaaS（Karaage as a Service）が誕生するまで保留。
 * BYOK（Bring your own Kraage）してもらうという手もあるが、参加のためのハードルをあげてどうするというのか。というかからあげは（たぶん）必須ではない。

=== しゃべる人のトレーニング ===

 * しゃべる側として、「反応がないところでいい感じにしゃべる」はハードルが高い。
   * 「カメラの向こうでうなずく人」すらいないので結構しんどい。
     * https://kakaku.com/item/S0000872486/ を置いておくのでは駄目ですか？　駄目ですね。
     * Facerigでもいいからうなずく係とか準備して写しておく、というのが意外と有効かもしれない。
     * セッションモニターする人への期待として、うなずく係という路線はありそう。
     * 顔出しにするとなんか、気の狂ったアホがアホアホ語の放送禁止用語でdisってくる、みたいな事故が起きうるので避けた方がいいんじゃね、という予感はある。


=== 事前準備 (2021/Jan) ===

----

[ ] しゃべる人の確保
 * 「しゃべる人」をとにかく確保する。
   * いつものような「当日までにしゃべる人をゲット」とか「最悪当日アドリブでゲット」路線は厳しい。
   * つまり、事前に「しゃべる人」を確保できない限りイベントは開催できないと思っておく必要がある。
 * --(2020 (20.04 or 20.10ウェーブ）でなにか演目がある人は以下のテーブルに名前と内容を書いてください)-- このテーブルはsplit brain防止のため一端封印しました。
  * 21.01でしゃべる場合は https://ubuntujp.connpass.com/event/199568/ で「発表したい」枠でご参加ください。

|| 名前 || 演目 || 必要な時間(min) ||
||      ||      ||            ||
|| ここにはもう何か書いてはいけません || ||  ||
||（いつもの人たち） || リリースノートをアドリブでボケながら解説する時間 || 45 ||
|| mizuno || あとでなんか考えるよ！ || 30 ||
|| ikuya || 18.04 LTSから20.04 LTSにアップグレードした話（仮題） || 30 ||
|| ここにはもう何か書いてはいけません || ||  ||


 * [[https://wiki.ubuntu.com/FocalFossa/ReleaseNotes/Ja|Ubuntu 20.04 LTSのリリースノート]]
 * [[https://wiki.ubuntu.com/GroovyGorilla/ReleaseNotes/Ja|Ubuntu 20.10のリリースノート]]
----

[済] バックエンドチャット（通称、楽屋裏）
 * -> Slackを確保した。招待は主催者経由で入手してください。
 * コアなスタッフだけが集まるためのバックエンドチャットをどこかに準備する。
   * Discordとかも手。https://discord.com/open-source

[済] バーチャルミーティングの準備
 * -> Zoomのpro版を調達した人がいるのでそれで
  * 参加上限100人、録画機能あり、You``Tube Liveへのサテライト中継機能あり(ホスト回線を圧迫しない）
 * 背景
   * 使うサービスを決めて有償プランを準備しましょう。
   * 無償プランでやる勇者コースはやめれ。お金で解決しよう。
   * Banなどのリスクコントロール可能なソリューションの利用

[ ] ライブの準備
 * 今後、動画を公開する可能性を考えるとYou``Tube以外の選択は現時点ではないといえる
 * [ ] You``Tubeのブランドチャンネルの開設（初回オンリー, 1/3までに終えていることが望ましい）
   * [済] ブランドチャンネルを新規作成する
   * [済] アカウントのVerifyを実施する
     * You``Tube Live(配信機能）を利用するためにSNS認証が必要
     * https://support.google.com/youtube/answer/171664?hl=ja
   * [ ] 管理者を追加する
     * 作成者のオーナー権限だけではSPOFになるため
     * 当然ながら十分に信頼できる人物である必要があります

 * [ ] ライブ配信を作成する
    * https://support.google.com/youtube/answer/2907883
    * 初めてのライブ配信は、最大で24時間作成を遅延させられます
    * [済] 初回
    * [ ] リハーサル用
    * [ ] 本番用

[済] ライブのプランBの準備
  * -> Zoomに接続している一般参加者
  * ライブチャネルは常にBanされる可能性を検討して、プランBを持つ必要がある。
   * AIさん頑張りすぎやで！　みたいな事故Banから、Fake DMCA侵害アタックまでいろいろな理由で事故Banは起きうる。

[ ] 装備品の確認を兼ねたテストミーティング（ぼっち方式）
 * -> 発表者がセルフチェック可能なテストミーティング(Zoom) https://support.Zoom.us/hc/ja/articles/115002262083-%E3%83%86%E3%82%B9%E3%83%88%E3%83%9F%E3%83%BC%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0%E3%81%AB%E5%8F%82%E5%8A%A0%E3%81%99%E3%82%8B%E3%81%AB%E3%81%AF
   * アカウントがなくても自分で起動できます（たぶん）。
 * リハーサル時に、しゃべる人がマイク持ってませんでした！　あるいは持ってるけどノイズまみれです！　リハーサル第一部完！　となるのを避けるためには、事前（リハーサルとは別に余裕を持ったタイミングで＋ぼっちで）テストミーティングが必要。
   * （ぼっちで）しゃべって終了ぐらいのノリでよいので、おそらく5分もかからない。

[ ] リハーサルの計画
 * [ ] 参加者の大部分がテスト（ぼっち）を終えたらリハーサルを計画する
   * 厳密に全員を待つ必要まではない。ものの、リハーサルはスピーカーから出た音がマイクに入ってハウる、あるいは複数の話者のマイクの音量が揃っていない、複数人が同時に喋るとノイズキャンセリングが暴走して音が入らない等、ぼっちでは確認できない問題をチェックするためのものです。
   * 実際に発表して頂く必要は皆無です。
   * リハーサルより前に、ぼっちでの事前音量調整が必要です（ノーマライズできるようなレコーディング機材やエンジニアは準備していない）。
     * Note: テストミーティングは自分の音を吹き込むことしかできないので、ハウリング回避・マイク音量調整・複数人同時トークによる問題を回避できないのである程度（本番で喋る人が一通り揃っている状態で）リハーサルが必要。
       * つまり、掛け合い漫才的なことをやる人はここでテストしないといけない。
       * 単独で喋る講師は必須ではない。
 * [ ] リハーサルの実施日程を決める
   * 参加者は、「しゃべる可能性がある人」＋セッションモニター
     * セッションモニターがvia Zoomとvia You``Tube Liveを一人で確認するとちょっとだけ大変かもしれないので、可能なら2名。
     * 基本的には運営メンバー1人いれば大丈夫です。
 * [ ] Zoomでスケジュール付でミーティングを作成する
   * 実際のテスト開始日時の15分前ぐらいにスケジュールをセットすること。
 * [ ] ZoomからYou``Tube Liveのリハーサル用のストリームキーの設定を行う
 * [ ] "リハーサル当日"の項目に、確認事項を追記する
 * [ ] 司会進行役を決める（リハーサルと本番はできるだけ揃える）
 * [ ] ミーティングの共同管理者 or 共同ホストを設定しておいて、アンロックが可能かを試す

リハーサル内容
 * "リハーサル内容"（このツリーそのもの）の妥当性チェックのためのacked-by欄：（OKそうな気がしたらアカウント名を入れてください）
 * [ ] Zoom: 「ミーティングを開始」する
 * [ ] Zoom: 録画を開始する
 * [ ] Zoom: ストリーミングサービスへの配信を開始する
   * ストリーミングサービスのURLを楽屋裏に提供する
 * [ ] Zoom: 配信クオリティをチェックするセッションモニターが入る
  * （↓ スケジュールがあえば協力してやるぜという人が名前を書く欄）
  * Zoom側セッションモニター： @nekomatu
  * You``Tube Live側セッションモニター:
 * [ ] Zoom: 参加者が揃うのを待つ
 * [ ] Zoom: 司会進行役がなんか喋る
 * [ ] Zoom: しゃべる可能性がある人が順番にしゃべっていく
   * 発表者さん・司会進行の運営者さんに、画面共有・発話・ミュートの実行をしてもらう。(1人5分程度を予定）
   * セッションモニターが担当分に問題がないかチェックしてOK/NGを楽屋裏に報告
     * 問題がありそうならその場で改善を試みる
   * Live配信系のレイテンシを観測する
 * [ ] Zoom: しゃべる可能性がある人がある程度同時にしゃべっていく
[ ] リハーサル後の確認
  * [ ] 各ストリーミングサービスに保存されたアーカイブを再生しクオリティチェックをする
  * [ ] Zoomに保存されたアーカイブを再生しクオリティチェックをする

[済] アナウンス
 * [済] イベントページを作成する https://ubuntujp.connpass.com/event/199568/
 * [済] ステークホルダーに連絡する
 * [済] MLのubuntujpに告知を流す <- 出版社ならびに招待客的な立ち位置の人に先に連絡する必要がありブロッキング中

その他 + tentativeな欄
 * [済] Zoom参加時に本名プレイすると配信や録画に入る可能性があるよ、という告知が必要かも？
   * -> スピーカーしかZoomに参加しないという前提のため、不要
 * [済] SPAMや公序良俗に反する方向で幸福追求権を行使する人は適宜banします、は事前に言った方がいいか？
   * -> スピーカーしかZoomに参加しないという前提のため、不要。YouTube Liveのチャットについては、YouTube Live側のガイドラインの範疇で対応可能。
 * [済] じゃんけん大会は技術的に無理、という認識でOK？
   * -> 視聴者とインタラクティブにやる手法で開催しない場合はじゃんけん大会は実施しない。
   * 一応、オフラインミーティングが開催できたときの景品はある
   * しかし輸送チャネルがない（ので今回はスルーしたい）
 * [-] https://loco.ubuntu.com/events/ にイベントを登録する
   * -> 今回はやらない（完全に忘れてたし今更だし）

=== アナウンス ===
 * イベントそのものの告知＋注意事項のアナウンスをいつものようにMLなりSNSなりに流していく。
 * 緊急時にはこのページでアナウンスします、というURLをどこかに含める（wiki上にパーミッションかけたページを作ればOK）。


== 当日検討 ==