give IT a try

プログラミング、リモートワーク、田舎暮らし、音楽、etc.

【動画付き・プレゼン初心者向け】忙しいITエンジニアのためのKeynote講座

はじめに

先日登壇したTama Ruby会議01で他の登壇者さんとしゃべっていると、「スライドの枚数がめちゃくちゃ多くなってしまったんですよね〜」と話されている方がいました。
詳しく話を聞いてみたところ、どうやらサンプルコードを強調表示する矢印やテキストボックスをシュパッ、シュパッと順に表示させるために、それぞれ1枚ずつスライドを用意していたようです。

f:id:JunichiIto:20190708052104g:plain:w400
たとえば、こういう効果を実現するには4ページ必要になる

ですが、こうした効果はKeynote(Mac用のプレゼンテーションソフト)のアニメーション機能を活用すると、1枚のスライドの中で矢印やテキストボックスを順番に表示させることができます。

とはいえ、ITエンジニアのみなさんはコードを書くのが仕事であって、プレゼンテーションソフトの使い方を覚えるのが仕事ではないですよね。
ですので、アニメーション機能のことを知らなくても仕方ないことだと言えます。

そこでこのエントリでは、プレゼンテーションソフトの使い方を勉強しているほど暇ではないITエンジニアのみなさんに向けて、アニメーション機能をはじめ、僕がよく使っているKeynoteの便利機能や使い方のコツをいろいろ紹介していきます。

対象バージョン

この記事ではKeynote 9.1(2019年7月時点での最新バージョン)を対象とします。

f:id:JunichiIto:20190707231901p:plain

【もくじ】

動画を見るのが一番早いから動画を見て!!

と言いながら、実は紹介したい機能は一通りYouTube動画の中で紹介しています。
このエントリは動画がメインであって、ブログの内容はオマケです。

ブログは概要を紹介するだけに留めますので、詳しい説明は以下の動画をご覧ください。

ここから下は動画の中で話している内容に簡単なまとめです。

リストを1つずつ表示させる

リストのテキストを1つずつ順番に表示させるときは、アニメーション > イン > エフェクトを追加 > 出現(またはその他のエフェクト)を選択します。
また、デフォルトだと表示形式が「一括」になっているので、これを「1件ずつ」にするとリストを1つずつ画面に表示させることができます。

f:id:JunichiIto:20190707201300p:plain

2つ以上のオブジェクトを同時に表示させたいときは「ビルドの順番」を指定する

矢印とテキストボックスを同時に表示させるときなど、2つ以上のオブジェクトを同時に表示させたいときは、「ビルドの順番」を指定します。
ドラッグアンドドロップでオブジェクトのビルドをグループ化すると、グループ化したビルドのオブジェクトを同時に表示させることができます。

f:id:JunichiIto:20190707201937p:plain

写真を丸く切り抜く

写真を丸く切り抜きたいときは、以下の手順で行います。

  1. 「図形」から丸のオブジェクトを選択してスライド内に表示させる
  2. デスクトップなどから画像ファイルを「丸オブジェクト」にドラッグアンドドロップする
  3. サイズを調整して完了ボタンをクリックする

f:id:JunichiIto:20190708053748g:plain

円の大きさを変えるときはシフトキーを押しながらドラッグする

ちなみに、きれいな円や正方形を保ったままオブジェクトの大きさを変えたい場合は、シフトキーを押しながらドラッグします。

f:id:JunichiIto:20190708054646p:plain:w400
f:id:JunichiIto:20190708054659p:plain:w400

行間を調整して情報を視覚的にグループ化する

これはKeynoteの使い方ではなく、デザイン一般の話です。
行間を狭めたり広げたりすることにより、「情報のひとかたまり」を視覚的に強調することができます。

↓ 行間を調整しないと、「情報のひとかたまり」がわかりにくい
f:id:JunichiIto:20190707203400p:plain

↓ 行間を調整すると、「情報のひとかたまり」が視覚的にわかる
f:id:JunichiIto:20190707203415p:plain

行間はフォーマット > テキスト > 間隔で調整できます。

f:id:JunichiIto:20190707203558p:plain

ソースコードのシンタックスハイライトはRubyMineからコピペで実現

今回、スライドの中で使用したソースコードはシンタックスハイライトが適用されています。

f:id:JunichiIto:20190707205210j:plain

これはどうやったのかというと、RubyMine上で作ったソースコードをKeynoteにコピペしただけです。

f:id:JunichiIto:20190707205508p:plain
RubyMine上で編集したソースコード

ブラウザやVS Code上のコードをコピペ、でも良さそう

動画の中では「RubyMineからコピペ」以外の方法を紹介しませんでしたが、今試してみたら「ブラウザのコードをコピペ」でも色情報がそのままコピーできました。

以下はQiita上のソースコードをKeynoteにコピペした例です。
f:id:JunichiIto:20190707210327p:plain

また、僕は試していませんが、「VS Codeでも色情報をコピーできた」と読者の方から情報をいただきました(@makicamelさん、情報ありがとうございます!)

選択しにくいオブジェクトは「オブジェクトリストを表示」で選択する

スライドの作り方によっては、あるオブジェクトが別のオブジェクトに重なってしまい、下側に隠れたオブジェクトを選択しづらい、ということが起きたりします。

こういう場合は画面右上の「表示」から「オブジェクトリストを表示」を選ぶと、リストの中から好きなオブジェクトを選択することができます。

f:id:JunichiIto:20190707210844p:plain
f:id:JunichiIto:20190707211003p:plain

オブジェクトのグループ化

あるオブジェクトとあるオブジェクトは常に同時に移動させたい、という場合はオブジェクトのグループ化を利用します。

たとえば以下は「四角オブジェクト」と「星オブジェクト」をグループ化する例です。
f:id:JunichiIto:20190707211909p:plain:w350

グループ化すると、常に「2つで1つのオブジェクト」として扱えるようになります。
(2つ以上のオブジェクトをグループ化することもできます)

f:id:JunichiIto:20190707212140g:plain

Commandキーを押しながらドラッグすると自由にオブジェクトを動かせる

矢印オブジェクトの先端や終端を移動させようとすると、Keynoteが勝手に矢印オブジェクトを他のオブジェクトに吸い付けてしまい、思った位置に矢印を動かせない場合があります。
そういう場合はCommandキー押しながらオブジェクト(白い四角の部分)をドラッグすると、好きな場所に矢印の先端や終端を動かすことができます。

f:id:JunichiIto:20190708055824p:plain:w350

矢印オブジェクト以外でも、Keynoteが「余計なお世話」で勝手にオブジェクトの位置を変えてくる場合は「Commandキーを押しながらドラッグ」で自由にオブジェクトを移動させることができます。

その他、スライド全般に言えるアドバイス

テキストを絶対に折り返さない

僕のスライドでは「絶対にテキストを折り返さない」というこだわりがあります。

f:id:JunichiIto:20190707213713p:plain

これは以下の理由からです。

  • スライド内のテキストが長文になるほど、聴衆はスライドの文章を読むのに必死になり、登壇者の話を聞かなくなるから
  • スライドに言いたいことを全て書いてしまうのであれば、講演として話す意味がないから(それならスライドを印刷して配ってしまえば良い)

こうした理由からスライドのテキストはシンプルにまとめて、言いたいことはできるだけ口頭で伝えるようにしています。

折り返すなら読みやすい位置で

(僕はやりませんが)折り返しが発生するぐらい長いテキストを書く時は、最低限、読みやすい場所で明示的に改行を入れるようにしましょう。


私は長いテキストをどうしても書きた
いので許してほしい

⭕️
私は長いテキストをどうしても
書きたいので許してほしい

会場のスクリーンに合わせた縦横比を選ぶ

スライドを作り始める前に、会場のスクリーンの縦横比を確認し、その縦横比に合ったスライドを作るようにしましょう。
縦横比が一致しないとスクリーンに余白ができてしまうので、貴重な表示スペースを有効活用できません。

特にソースコードを表示したりするときは、画面を目一杯使ってコードを表示しないと、後ろの席から見えにくい小さな字になってしまったりすることがあります。

文字が小さくなりすぎないように注意する

スライドを作っているときは自分がモニタの真ん前にいるので、多少字が小さくても全部読めてしまいます。
しかし、本番では前の席だけでなく、後ろの席の人もスライドを見ようとします。
その場合、字が小さすぎると後ろの席から読めません。

この問題を避けるために、スライド作成中に意図的にウインドウサイズを小さくして、後ろの席の人から見たときの状況をシミュレーションしてみるといいと思います。
f:id:JunichiIto:20201026074019p:plain

リハーサル中に一番後ろの席から自分のスライドを見てみる

もしリハーサル時間に余裕があれば、実際に何枚か自分のスライドを一番後ろの席から見て、スライドの見やすさをチェックしてみてください。
自分でチェックすると内容がわかっている(=見にくくても見えている気がしてしまう)ので、できればスタッフの人や他の登壇者を呼んで「スライドの文字、ちゃんと見えますか?」と質問するとさらに良いです。

Tama Ruby会議01では、「サンプルコードの緑色の字が見づらい」というフィードバックがあったので、講演開始までに急いで文字の色を修正しました。

↓ 修正前(文字列を表す緑色の字が見づらかった)
f:id:JunichiIto:20190707205210j:plain

↓ 修正後(会場で急いで文字色を修正した)
f:id:JunichiIto:20190707215651j:plain

海外の無料テンプレートを使うといい感じのデザインになるかも

"keynote template free"みたいなキーワードでググると、海外のKeynote用無料テンプレート集がたくさん見つかります。

Keynote標準のテンプレートやAzusaテンプレートを使うと、他の人とかぶることがあるので、他の人とちょっと差を付けたいときは海外の無料テンプレートを探してみると良いかもしれません。

ちなみに今回僕が使ったのはこちらのテンプレートです。
Free Keynote Templates - Business Strategy Pitch Deck

アニメーションはほどほどに

アニメーション機能を使い始めると面白くていろいろ遊んでしまいたくなりますが、派手なアニメーションを多用しすぎると聴衆に「ウザい」と思われてしまい逆効果になります。

僕は「原則として、表示と非表示のシンプルなアニメーションだけを使う」「それ以外の動きのあるアニメーションは、ここぞというタイミングだけに使用する」というポリシーにしています。

動画を見るのが一番早いから動画を見て!!(再)

冒頭にも書いたとおり、動画の方がより詳しい説明になっています。
実際にスライドを作ろうとしている人はこのブログだけでなく、動画の方もチェックしてみてください。


まとめ

というわけで、このエントリではITエンジニアのみなさん向けに、もしかしたら知らないかもしれないKeynoteの便利機能や使い方のコツをいろいろと紹介してみました。

Keynoteを使ってスライドを作ろうとしている人は、この記事を参考にしてカッコよく、わかりやすいスライド作りにチャレンジしてみてください!

参考図書:プレゼンの心構えや、スライドデザインを学べる書籍

このエントリはKeynoteの使い方に主にフォーカスしましたが、ツールによらない「プレゼンをする上で大事な考え方や心構え」を学ぶには「パワー・プレゼンテーション」という書籍がオススメです。
絶版になっているため新品では買えませんが、Amazon等で中古本が安く買えるので、買っておいて損はないと思います。

ちなみに、上で説明した「スライドの文字を折り返さない」という考え方もこの本の中で説明されていたものです。

また、テキストや図形の配置、マージンの取り方など、視覚的なスライドデザインについては「ノンデザイナーズ・デザインブック」の内容が参考になります。

ノンデザイナーズ・デザインブック [第4版]

ノンデザイナーズ・デザインブック [第4版]

  • 作者:Robin Williams
  • 発売日: 2016/06/30
  • メディア: 単行本(ソフトカバー)

あわせて読みたい

スライドの内容そのものについてはこちらのエントリで紹介しています。
blog.jnito.com

Tama Ruby会議01で「テストコードの役割」について発表してきました #tamarubykaigi01

はじめに

2019年7月6日、渋谷のGMO Yoursさんで開催されたTama Ruby会議01で「なぜテストを書くの?(または書かないの?) 〜テストコードの7つの役割〜」という発表をしてきました。

スライドはこちらです。

このエントリではこの発表の紹介やイベントの感想を書いていきます。

この発表テーマを選んだ経緯

スライドの9枚目にも書いたとおり、もともとは「RSpecを題材にしたテックな話を」とお願いされていました。

f:id:JunichiIto:20190707082424j:plain

しかし、ネットなどを見ていると、「テストって難しい」「RSpecがわからん」と言っているプログラミング初心者さんたちは、テストについて何か根本的な思い違いをしているんじゃないか?という漠然とした疑問や懸念を僕は持っていました。

テストにおける「土台となる考え方」を会場のみなさんと共有したかった

そういう状態でRSpecのテクニック的な話をしてもどこか歯車がかみ合わないというか、発表を聞いた直後は「なるほど、完全に理解した」と思っても、数日経つと結局めぐりめぐって「テストって難しい」「RSpecがわからん」と同じことを言い始めるような予感がしました。
なので、「魚を与えるよりも魚の釣り方を教える」ではなく、「魚の釣り方を教えるよりも、なぜ魚を釣るのか、それは魚でないといけないのか」という話をしたいなと思いました。

また、僕自身、テストを書くときは「○○○だから書く」と何か一つに理由が定まっているわけではなく、あるときはこういう目的で、またあるときはこんな目的で、と、テストを書く目的がいくつかのパターンに分かれていることをなんとなく感じていました。
ただ、これも「なんとなく自分の頭の中にある」というだけで、きれいに整理整頓したことはありませんでした。
そこで、この機会に「なんとなく自分の頭の中にあるパターン」を整理して言語化しようと思いました。

せっかくたくさんの人が集まるいい機会のなので、表面的なテクニックよりもあえて「土台となる考え方」を語って、参加者のみなさんとそれを共通認識として共有する方が価値があるんじゃないか、そして、Tama.rbというRubyコミュニティも比較的初心者向けのRubyコミュニティなので(たぶん)、参加者層を考慮してあえて「基礎の基礎」を語ることはそんなに悪くないのでは?と思い、今回はこのような発表テーマを設定してみました。

当たり前のことをあえて明文化することの価値

とはいえ、発表をする前は「簡単すぎる」「基礎的すぎる」「テック要素が薄くて物足りん」とdisられるんじゃないかと、ちょっと心配していました。
ですが、蓋を開けてみると思いのほか好評だったようで、「このテーマを選んで正解だった」と胸をなで下ろしました。

みなさんの感想はこちらのtogetterページにまとめられています。

ところで、僕は以前どこかで「テーブル設計における正規化理論は、効率良くデータを保存しようとすると誰もが行き着く当たり前の考え方だ。しかし、これをあえて言語化、明文化したことに正規化理論の価値がある」というような話を聞いたことがあります。
自画自賛するわけではないですが、今回の僕の発表も「テストを長年書いている人なら、誰でも経験則として当たり前に思えること」をあえて明文化したことに価値があったんじゃないかなーと思っています。

はじめての基調講演

今回の発表はTama Ruby会議01における基調講演(キーノート)として依頼されたものでした。
基調講演をお願いされたのは今回が初めてで、何をすればよくわかっていなかったのですが、「基調講演の役割は、参加者全員の意識を統一して、あとに続く発表へスムーズにつなげていくことなんじゃないか」と僕は考えました。

そこで、今回の発表では「普段通りの発表 + 最後にこのイベント全体について当てはまりそうな話」という構成にしてみました。
おそらくですが、「基調講演っぽい発表」にはなったんじゃないかと思います。(実際に参加されたみなさん、どうでしたか?)

自己紹介タイムはなし!

あと、これは余談ですが、今回は実験的な試みとして「自己紹介をまったく入れない発表」にチャレンジしてみました。
Twitterの反応を見る限り「で、あんた誰?」とは言われなかったようなので、これはこれで成功だったかもしれませんw

f:id:JunichiIto:20190707095356j:plain
登壇中の僕です(photo by @katsumata_ryo)

イベントの感想等

ここからあとは、Tama Ruby会議01で印象に残っている話をいくつか書いていきます。

持ち時間=10分制が意外と良かった

Tama Ruby会議01で面白いなと思ったのは基調講演の僕と五十嵐さんを除いて、各発表者の持ち時間が10分間だったことです。
最初は「LTでもないのに、持ち時間10分は短すぎるのでは?」と思いましたが、実際に聞いてみると意外とそうでもありませんでした。
持ち時間が短いぶん、いろんな人の発表が聞けるというメリットがあるので、これはこれでアリかもしれません。

人数は少ないものの、女性の方が元気そうだった

僕は「女性が参加しやすい(でも女性限定ではない)Rubyコミュニティ」である、TokyoGirls.rbの主催者なので、女性の参加率もちょっと気になっていました。
ぱっと見た感じ、女性の参加率は1割ぐらいかな、という印象です。

f:id:JunichiIto:20190707100251j:plain
当日の会場の様子です

理想は男女半々、最低でも3割ぐらいは女性に参加してほしいと考えている人なので、「やっぱりまだまだ女性は少ないなあ」という感はあります。

ただ、参加していた女性エンジニアは、みなさんアクティブで元気そうという印象を受けました。
登壇者の中に女性が2人いたのも評価したいポイントです(しかも、お二人とも短い経歴のわりに骨太な発表だった!)。

そういう意味では「女性エンジニアがもっとグイグイとRubyコミュニティを盛り上げてくれる余地は十分にある!」と感じました。

TokyoGirls.rb Meetup vol.2も開催せねば!

懇親会では女性エンジニアの方から「TokyoGirls.rb Meetupの2回目はやるんですか?1回目がすごく良かったんで、また行きたいです」と質問&リクエストも受けました。

はい、やります!(断言)

ただし、なかなか手が回らなくて開催はもう少し先になるかもしれません。
ですが、「1回やって終わり」にするつもりはありませんので、もうしばらくお待ちください!!

顔と名前とTwitterアイコンが一致しない問題

懇親会等では「伊藤さん、いつもチェリー本やQiitaでお世話になっています!」とたくさん声を掛けてもらいました。
そんなふうに声を掛けてもらうのは、ちょっと気恥ずかしい反面、大変ありがたいです。

ただ、非常に申し訳なく思うのが、ほとんどの人について「ごめんなさい、僕はあなたのことをよく知らないんです」状態になってしまうことなんですよね・・・。
でも、イベントが終わったあとにふと振り返ってみると、「あ、もしかしたら、あのとき声を掛けてくれたあの人は、もしかしたらこのTwitterアイコンの人だったのかもしれない!(でも、もはや確認するすべがない・・・)」と思うことがちらほらありました。

Twitterアイコンがわかれば、まだ何とかなるかも?

Twitterでよくいいねやリツイートをしてくれたりする人は、なんとなく「よく見かけるTwitterアイコンの人」という形で僕の記憶に残っていたりします。
なので、名札にTwitterアイコンをドカーンと大きく載せてくれていれば、僕も「あ、このアイコン見たことあります!」と、話しかけてくれた人を認識できていたかもしれません。

ですので、イベントの主催者さんは、参加者各人のTwitterアイコンシールを作って名札に貼ってもらう、みたいなことをしてくれると、懇親会での参加者同士のコミュニケーションがさらに盛り上がるかもしれません。
(僕も次回のTokyoGirls.rbとかで、ちょっと検討します)

ちなみに余談ですが、僕はこんなふうにオフラインで会ったときに「顔と名前とTwitterアイコンが一致しない問題」を極力避ける目的もあって、あえて実名と顔写真アイコンでネット活動をしております。

f:id:JunichiIto:20190707102611p:plain:w300
SNSも実名と顔写真アイコンにしておけば、覚えてもらいやすいですよ!

まとめ

というわけで、このエントリではTama Ruby会議01での僕の発表内容と、このイベントの感想をあれこれ書いてみました。

素敵なイベントを主催してくれたTama.rbのみなさん、会場や美味しい料理・飲み物を提供してくださったスポンサーのみなさん、そして参加者のみなさん、登壇者のみなさん、どうもありがとうございました!

次回は渋谷を離れて、多摩地域での開催ですかね?
僕の好きなTMネットワークが多摩出身らしいので、多摩開催も期待しています!w

参考文献

スライドの中で紹介していた、各種書籍のリンクを載せておきます。

テスト駆動開発

テスト駆動開発

はじめて学ぶソフトウェアのテスト技法

はじめて学ぶソフトウェアのテスト技法

leanpub.com

ちなみにスライドの33枚目に出てきたRGB変換プログラムのコードは、拙著「プロを目指す人のためのRuby入門」からの抜粋でした。

あと、僕の発表スタイルは「パワー・プレゼンテーション」という書籍の影響を大きく受けています。
自分も上手に発表できるようになりたい!と考えている方はチェックしてみてください。

パワー・プレゼンテーション (グロービス思考シリーズ)

パワー・プレゼンテーション (グロービス思考シリーズ)


あわせて読みたい

この発表で使ったスライドの作り方(Keynoteの便利テクニック)をこちらのエントリで紹介しています。
blog.jnito.com

恥ずかしがらずにオープンな場で積極的に質問していきましょう、という話

はじめに

先日、Teratailに以下の質問が挙がっているのを見つけました。

Ruby - irbと打つと「can't find gem irb」とエラーが出ます。どうしたらいいでしょうか|teratail

質問の内容は、「rbenvのインストール後、irbを起動しようとするとエラーが出て起動しない」というものです。
質問者の方は拙著「プロを目指す人のためのRuby入門」の学習を進めようとして、この問題に遭遇したそうです。

エラーが出てirbが起動しない、という現象は今まで聞いたことがありません。
irbはRubyが持つ基本機能の一つだからです。

原因は僕もはっきりわからなかったのですが、"rbenv-communal-gems"というあまり聞き慣れないrbenvプラグインを使っていたので、もしかしたらこれが原因ではないかと推測しました。
そこで、「もしかすると"rbenv-communal-gems"が原因ではないですか?」回答を入れたところ、予想が的中したようで、irbが正常に起動するようになったみたいです。

質問者の方は「まさかの著者様からの回答、本当に感動しています。ありがとうございます!こんな事あるんですね」と喜んでおられました。

クローズドな場所での質問よりも、オープンな場所での質問の方が嬉しい

質問者の方だけでなく、質問を受ける側(つまり僕)としても、こんなふうに「みんなから見える場所=オープンな場所」で質問してもらえる方が嬉しいです。

その反対で、ときおりTwitterのDMなどで書籍「プロを目指す人のためのRuby入門」に関する技術的な質問を受けることがあるのですが、こういうクローズドな場所で質問するのはなるべく避けてほしいなあと感じます。

また、この話はネット上の質問だけでなく、IT系勉強会や講演会などでもほぼ同じようなことが言えます。

その理由について、僕が普段考えていることを以下につらつらと書いていきます。

個人的に質問してくる人はフリーライダーだ、という意見

ちょっと前に、ネットで以下のツイートが話題になったことがありました。

上のツイートの画像に書いてあることは以下のとおりです。

  • 海外から来日したある講演者いわく、講演の最後に「質問はありますか?」と尋ねても、日本人は誰も手を挙げない。
  • 講演が終わると名刺交換の列ができ、その最中に「実は質問が・・・」と切り出す人が数名出てきた(もしくは後日メールで質問してきた)。
  • その質問をみんなの前でしていれば、会場の全員が知識を共有できた。
  • 個人的なやりとりで回答を引き出そうとするのは、知識を独占しようとしていることと同じだ。こいつらはフリーライダーだ!(怒)

このツイートを見て、「なるほどなー」と僕は思いました。
たしかに個人的なやりとりで回答を引き出すのは、その人の知識を独占しようとしていることと同じになってしまいますね。

「恥の文化」にとらわれがちな日本人

もちろん、質問する側の気持ちもわかります。
質問する側の気持ちとしてはおそらく、

  • こんな初歩的な質問をみんなの前でするのは恥ずかしい。
  • きっと周りの人はみんな理解しているのに、自分だけが理解できていないに違いない。
  • こんな質問をしたら、みんなからアホだと思われてしまう。

と、こんなふうに思っているのでしょう。

日本人の行動様式は「恥の文化」で特色づけられていると言われます(参考)。
なので、「恥をかきたくない」という気持ちが湧きあがると、その気持ちが最優先されてしまいます。

僕も日本人なのでその気持ちはわかります。
が、技術コミュニティにおいてはその気持ちは捨て去った方が良いです。

あなたがわかってないことは、周りのみんなもわかってない

そもそも、「みんな理解しているのに、自分だけが理解できていないに違いない」と思っていることは、たいてい周りの人も同じように感じています。
ですので、そこで自ら手を挙げて質問をすれば、周りの人はきっと「よく質問してくれた!ありがとう!」と思ってくれるはずです(口に出して言う人は滅多にいないので実際のところはわかりませんが)。

講演者は質問が大好物

それに、講演会のような場面では質問がたくさん挙がった方が講演者は嬉しいです。
逆に質問がまったく出てこないと、講演者は「退屈だったのかな?」「全然理解できなかったのかな?」と不安になります。

つまり、積極的に質問することは、講演者を喜ばせることにもなるのです。

オープンな場所で質問してくれた方が時間の節約になる

ネット上での質問に関していえば、Teratailやスタックオーバーフローのような場所で質問してくれると、僕のような技術書の著者にとっては「他の誰かが答えてくれるかも?」という期待ができます。
DMで質問されると自分以外に答える人がいないので、確実に自分の時間が奪われてしまいます。

加えて、TwitterのDMや、Facebookメッセンジャーのようなチャットツールはたいてい技術的なやりとりをするようには作られていないため、コードやエラーメッセージを貼り付けられても読むのがしんどい、というデメリットもあります。(下の写真を参照)

f:id:JunichiIto:20190703112509p:plain:w300
過去に届いた質問DMの例

なので、技術的な質問はMarkdownのような技術者にとって使いやすいフォーマットを使ってもらう方が、お互いやりとりしやすく、時間の節約になります。

追記その1:あなたが質問すると他の人のハードルが下がる

IT系勉強会などで周りの人が「質問したいけど、恥ずかしくて質問できない」という状況だった場合、あなたが先陣を切って質問することで、他の人がぐっと質問しやすくなることがあります。

・・・という話を以下のツイートで見かけて「たしかに!」と思いました。

追記その2:適切な質問かどうかは講演者 or 司会者の判断に任せましょう

「その場では上手に疑問点が整理できなかったので、懇親会で個人的に質問してしまった」という以下のツイートを拝見しました。

もちろん、質問の内容によっては講演者が回答に困ったり、やたら時間を食ってしまったりする可能性はあります。
ですが、もしそうなった場合は講演者が「あとで個人的にお話ししましょう」と言ってくれたり、司会者が「ちょっとその質問はまたあとで」とやりとりを中断してくれたりするはずです。

ですので、何か疑問に思った点があれば、とりあえず質問してみて、講演者や司会者の反応を見る方がよいと思います。

追記その3:運営側も参加者の心理的安全性を高める工夫を

ここまではずっと参加者に対して「恥を捨てて積極的に質問しよう」というお話をしてきました。
しかし、暗黙の了解として参加者一人一人に「恥を捨てて積極的に質問する努力」を期待するのはなかなか難しいです。

ですので、運営スタッフも勉強会のオープニングで「質問はみんなのため、講演者のためですよ」と呼びかけて、参加者の心理的安全性を高めるようにした方がいいと思います。

実際、先日主催したTokyoGirls.rb Meetupでもそのようなトピックをオープニングスライドに盛り込みました。

f:id:JunichiIto:20190702100424j:plain
TokyoGirls.rbのオープニングで使ったスライドの1コマ

その甲斐あってか、各講演のあとには参加者からたくさんの質問が挙がっていました。

追記その4:質問がなければ、代わりに感想を伝えましょう

本当に疑問点がなかった場合、そして会場の誰からも質問が挙がらなかった場合は、「これは質問ではなく、ただの感想なのですが・・・」と、感想だけでも講演者に伝えると良いです。
何かしらフィードバックを伝えることで、壇上で質問を待っている講演者の「つまらなかった?」「わかりにくかった?」という不安な気持ちを和らげることができます。

追記その5:このツイートの言うとおり

こんなツイートを見つけたので貼っておきます。まさにそのとおりですね。

まとめ

というわけで、このエントリではオープンな場所で積極的に質問していくことの重要性を書いてみました。

上で述べたように、積極的に質問をすることは自分のためではなく、周りの人や講演者を喜ばせることにもつながります。
「恥ずかしい」と感じるのはあなたが日本人だからです。「恥の文化」に染まっているからです。

「質問したい、でも恥ずかしい」と思ったときは、意識的に自分の「恥」を窓から放り投げるように心がけましょう😉