maybe daily dev notes

私の開発日誌

登壇Tips: 聴講者に挙手をお願いする上で注意する5つのこと

エンジニア向けのイベントで登壇するとき、会場の人に向けて選択式の質問をし、当てはまる項目に挙手させること (以下会場アンケートと呼びます) があると思います。下図が一例です。

私が最近失敗した質問です😓 改善点はどこでしょうか?

会場アンケートはうまく使えば会場と一体感が生まれ盛り上がる方法ですが、思っていたより手が上がらず落ち込んだという登壇者もいるかもしれません (私です😇)。この記事では、失敗から得られた教訓として、会場アンケートする際に気をつけたいことをまとめます。

なお、私自身下記の内容に確証があるわけでもなく、推察が多分に含まれます。個々人の気持ちに関わる部分であり、一人で考えても仕方ないとも思うので、ぜひご意見ください(←こないやつ)!

1. 選択肢は漏れのないようにする

提示する選択肢は、会場にいる全員が一度は手を挙げられるように用意するのが良さそうです。

自分が聴講者だとして、登壇者に質問をされたのに当てはまる選択肢がなく手を挙げられなかったら、仲間外れにされたような気持ちになるかもしれません。インクルーシブネスの観点で、このような状況は避けるべきでしょう。

また、特に発表の序盤では、聴講者の全員が登壇者と何らかインタラクションすることで、両者とも緊張感がほぐれる効果が期待できそうですね。

2. 1つ目の選択肢は、多くの人が手を挙げそうなものに

ファーストペンギンという言葉がありますが、人が手を挙げてない中で自分だけが手を挙げるのは避けたいものです。

気軽に手を挙げられる雰囲気を作るため、回答の1つ目の選択肢は、会場の3〜4割以上は手が挙がると見込めるものを配置するのが良さそうです。1つ目でたくさん手が挙がれば、それ以降のよりマイナーな選択肢でも、多少手を挙げやすくなるんじゃないでしょうか。

3. ネガティブな印象を与えうる選択肢にはフォローを

その選択肢自体にネガティブなイメージが含まれる場合は、手を挙げる事自体を恥ずかしがる人がいるのはもっともです。

このような場合は、登壇者の配慮が一層必要になると思われます。例えば「意外と多いんじゃないかと思いますが」とか「私も実はこれに当たるんですが」とか前置きするのはどうでしょうか。

あるいは場合によっては、そもそも選択肢として含めない対応も必要かもしれません。「漏れのないように」という話と矛盾しますが、ケースバイケースの判断は必要ですね。

4. そもそも回答することが難しくないか検討する

回答することが難しい質問を投げかけている可能性がないか、事前に検討しましょう。

質問を受けた際、答えをはっきりとは知らない・答えが一つに定まらないなどの理由で「何とも答えられない…」と思うことはしばしばあると思います。会場アンケートにおいてこれをやってしまうと、登壇者と聴講者の間に壁が出現し、大きな距離感を生み出してしまいます。

回避するためには、資料準備の段階で周りの人に質問を素振りしておくのが良さそうです。それらの反応を見て回答が難しそうな場合は、1. 回答前に考える時間を設ける 2. 回答を確認する方法を提示する 3. 質問を変える といった対応が考えられるでしょう。

なお、2. 最初の選択肢は、多くの人が手を挙げそうなものにする を実践していれば、もし最初の選択肢であまりにも手が挙がらない場合 (想定外の事態!) に、その場で軌道修正ができそうですね。

5. 質問の意図を明らかにする

意味のないことをしたがる人は少ないです。ゆえに、聴講者は答える意義の分からない質問に何度も答えてくれるわけではないと思われます。

質問する前には意図を十分に説明し、回答が得られたらそれをその場で有効に活用すると良さそうです。

これは特に複数個の質問するときは重要だと思います。1つ目の質問の回答が有効活用されてなければ、その後の質問は答える意欲を失うのが人の心理だと思います。 私はあまり実践できてなかったように思うので、反省しています。

その場で出た結果に対して当意即妙なコメントをするのはなかなか難しいですから、想定される回答分布のいくつかのパターンについて、気の利いたコメントを先に考えておくのも必要かもしれません!

三者の意見

ちなみに、Claudeさんに聞いたらこんな感じでした。

エンジニア向けのイベントで選択式の質問をする際、登壇者が気をつけるべきことは以下のようなことが考えられます。

  1. 質問の内容:
    • 参加者にとって興味深く、関連性のある質問を用意する
    • 質問が明確で簡潔であり、誤解を招かないようにする
  2. 選択肢の設計:
    • 選択肢が適切な数(3~5個程度)になるよう設計する
    • 選択肢が互いに排他的で、重複がないようにする
    • 選択肢の表現が中立的で、バイアスがかからないようにする
  3. 参加者への呼びかけ:
    • 参加者全体に向けて明確に質問を伝える
    • 参加者が挙手しやすい環境を作る(照明、空間の使い方など)
    • 参加者の反応を適切に確認し、次の進行に活かす
  4. 回答の扱い:
    • 参加者の反応を丁寧に確認し、理解を深める
    • 回答の傾向を分析し、それを議論に活かす
    • 参加者の意見を尊重し、議論を建設的に進める
  5. 全体の流れ:
    • 質問を適切なタイミングで行い、イベントの流れを乱さない
    • 質問の目的を明確にし、参加者の理解を促す

いや、先に聞いておけば良かったな!なお > 参加者が挙手しやすい環境を作る(照明、空間の使い方など)

ゲリラ豪雨、雷鳴、うっ頭が…!*1

まとめ

この前の教訓を忘れないために、記事化してみました。割と根拠なしに書いているので、他の方の意見も聞きながら自身の感覚を較正していければと思います。登壇はエンジニアリングとは別の工夫の余地が色々あり楽しいので、引き続き頑張っていきたいです。

尺余りもなちゃん

*1:内輪ネタすみません。前回の発表会場は高層ビルの21階だったのですが、私の発表中に豪雨が降り始め、背景で雷鳴と雷光が威圧的な演出をしてくれるという事故があったのです。