maybe daily dev notes

私の開発日誌

リモート会議で 「今声聞こえてますか」 の確認、いる?

問題提議

リモート会議などで良く耳にする、初めて発話する人の第一声 「今私の声聞こえてますか」、これが必要なのか考えてみた。

この一言は次のようなシチュエーションでしばしば聞かれる。

司会 「… それでは、次はXXさんどうぞ。」
XX 「はい、よろしくお願いします。今私の声聞こえてますか?」
司会 「はい、大丈夫です 🙆」
XX 「ありがとうございます。それでは、話を始めたいと思います。…」

このやり取りの欠点は、あまりにも冗長なことだ。体感的にはほとんどの場合問題なく声が聞こえるので、わざわざ確認しなくて良いのではと感じる人も多いだろう。この記事では、所要時間の観点からこの確認の要不要を検討する。

他のやり方と比べてみる

試しに、以下のダイレクトに話を始めるケースと所要時間を比較してみたい。なお、以下では↑の方を 慎重版 、 ↓の方を 直接版 と呼ぶ。

司会 「… それでは、次はXXさんどうぞ。」 
XX 「ありがとうございます。それでは、話を始めたいと思います。…」

この時、XXが話を始めるまでのパターンは以下の4つが考えられる。 なお、ここでは簡単のため以下の仮定を置く:

  • 正常系は、XXの環境に異常がなく、正常に通信できる場合とする。
  • 異常系は、XXのマイクにのみ不調がある場合とする (XXは声は通らないが司会の声は聞こえる)。それ以外の異常は考えない。
  • 司会者は10秒間XXさんの声が聞こえなければ異常とみなし、その旨をXXに伝える
  • XXは3秒返事がないかあるいは司会から伝えられたときに、自分の環境に異常があることに気づく
  • XXは環境の異常に気づいたら、10秒後に必ず修正できる
  • その他の時間は適当に仮定しているが、パターン間で一貫していれば結論に影響はない。
# パターン1: 慎重版 正常系 合計8秒
司会 「… それでは、次はXXさんどうぞ。」 (T=0)
XX 「はい、よろしくお願いします。今私の声聞こえてますか?」 (T+5秒)
司会 「はい、大丈夫です 🙆」 (T+8秒)
XX 「ありがとうございます。それでは、話を始めたいと思います。…」

# パターン2: 慎重版 異常系 合計21秒
司会 「… それでは、次はXXさんどうぞ。」 (T=0)
XX 「はい、よろしくお願いします。今私の声聞こえてますか?」 (T+5秒)
XX 返事がないため環境の異常に気づく (T+8秒)
司会 「XXさん、声が聞こえないようです🙅」 (T+10秒)
XX (環境を修正して) 「今私の声聞こえてますか?」 (T+18秒)
司会 「はい、大丈夫です 🙆」 (T+21秒)
XX 「ありがとうございます。それでは、話を始めたいと思います。…」

# パターン3: 直接版 正常系 合計0秒
司会 「… それでは、次はXXさんどうぞ。」 (T=0)
XX 「ありがとうございます。それでは、話を始めたいと思います。…」

# パターン4: 直接版 異常系 合計23秒
司会 「… それでは、次はXXさんどうぞ。」 (T=)
XX 「ありがとうございます。それでは、話を始めたいと思います。…」 (T+5秒)
司会 「XXさん、声が聞こえないようです🙅」 (T+10秒)
XX (環境を修正して) 「今私の声聞こえてますか?」 (T+20秒)
司会 「はい、大丈夫です 🙆」 (T+23秒)
XX 「ありがとうございます。それでは、話を始めたいと思います。…」

慎重版の時間的な利点は、異常系の際に発揮される (パターン2と4に注目)。慎重版ではより早期に異常に気付けるので、対応が早まるのだ。この効果はどれほどだろうか。

ここでは、異常系に遷移する確率をpとしよう。このとき慎重版と直接版それぞれで、話を始めるまでにかかる時間の期待値は下式となる:

慎重版: 8*(1-p) + 21*p = 9 + 13p
異常版: 0*(1-p) + 23*p = 23p

このため、慎重版の方が期待値が短いのは 9+13p < 23p 、つまり p > 0.9 の時となる。90%以上の確率でマイクに不調が発生する限界環境では、慎重版のやり取りを使おう!それ以外のありふれた環境では直接版の方がお得である。

ちなみにパラメータは恣意的に慎重版が有利になるように決めている。実際は司会者はXXの声が聞こえるまで10秒も待たないはず。今回の設定では、司会者が8秒以内に異常に気づける場合は、慎重版でも直接版でも異常系にかかる時間が等しくなるため、慎重版の時間的メリットはなくなる。

結論

話し始めるまでにかかる時間の期待値だけを考えると、「今聞こえていますか?」の確認をするメリットがある状況は考えづらい。確認せずに本題を話し始めよう。


こういう話ってよくあるよね

ということでこの記事は一旦結論がついたのだが、これだけで終わるのも何なので、ついでに他の話との関連性を無理やりもたせてみる。

この話の要点は、何らかの分岐処理をする際はそれぞれの分岐先に遷移する確率を考えれば最適化できるんじゃないという点。こういう状況はよくあって、例えば:

楽観ロックと悲観ロック 楽観ロックでは、基本的に処理の競合が起こることはないだろうと見積もって排他処理を行う。このためもし競合が起きた場合に解決するコストは高いが、競合が起きない状況では比較的低コストで処理することができる。悲観ロックはその逆で、競合が頻繁に起こる状況で利用する。

CPUの分岐予測 私がつい先日学んだ話。コードを書く際に if else のどちらに処理が飛びがちかをコンパイラに教えることで、CPUに処理を最適化させることができる。こちらの記事も参照。

tmokmss.hatenablog.com

シャワーを浴びながらふと思いついた題材だったが、意外と面白い話だったので記事にしてみた。おわり

P.S.

とはいえ慎重版のやり取りにも効用はあり、例えば以下が挙げられる。

  1. 定型句のやり取りをすることで、話者の緊張を和らげる
  2. 第一声として無難な発言をして、話者の喉を整える
  3. この言葉に紐付けて、マイクミュートの確認を習慣化できる

他にも比較の観点があれば、ぜひ教えて下さい。