プログラミング素人のはてなブログ

プログラミングも電気回路も専門外の技術屋の末端が勉強したことや作品をアウトプットするブログ。コードに間違いなど見つけられたら、気軽にコメントください。 C#、Python3、ラズパイなど。

プレゼンを切り抜ける技術

TL;DR

・上司の指摘は従わざるを得ない
・人の話を聞いていないで質問する人は必ずいる
・原稿は用意しておくべき
・慣れていないならレーザーポインターは使わないでマウスを使う
・スライド一枚につき小結論を書く(口で説明するだけではなく書いておくことが重要)

事前レビューを切り抜ける

社会人でも学生でもプレゼンというのは避けて通れないものです。そして、プレゼンというものは自分が発表するとしても、自分の話したいことを話せるわけではありません。組織の「代表」として結果にコミットしなければならないのです。
そのために、事前レビューというものがあります。個人開発をしているようなケースを除けば、上司(もしくは出資者)の事前レビューを通過しないものは発表できません。
しかしながら、発表の事前確認で上司の指摘が的はずれに感じるとき…、あります。

こういうときというのは、「聞いていないし見ていない。」のです。
自分の「こういう話をしているだろう」に対して、話の流れが違うから「わからない」といっているのです。とても理不尽なことで、こういうことはもっと2段階ぐらい前、発表の内容を精査する段階ですり合わせておくべきものなのですが、こういう人は、そのときはなにも考えていないのです。
指摘自体は一見、正論ですが話を聞いていればそんな指摘は出てくるはずがない、ということばかりです。

これは「お客さんがそんな使い方するはずがない」という現象に当たってしまったときの感覚に似ている気がします。残念ながら、電子レンジで猫を乾かそうとする人がいるのが現実なのです。
電子レンジで猫を乾かす人は、食べ物が温かくなるのだから猫を乾かすことができると考えます。普通、食べ物を温める機械に猫をいれようとしませんが、「食べ物を温める機械に猫をいれようとしない」という考えが間違いなのです。これは教育の敗北ですが、教育の敗北に敗北するわけにはいかないのです。

発表のストーリー作成時の対策

猫を乾かすような人も考慮にいれておく必要があります。

固定観念を持った、こういう指摘をする上司には、ここからいくら自分の発表内容を正当化する修正をしても納得はしません。自分のストーリーと違う限り。
いいものを作りたい(提供したい)のではなく、自分の考えたものを作りたい、こういう人は多くて、実力(技術力、センス)はあるが人はついてこない、というのが一般的です。しかし、残念ながら会社組織ではこういう人も出世します(会社による)。長いものには巻かれるしかありません。

修正したいだけの上司(修正が自分の仕事だと思っている人)はまだポリシーを持っている気がしますが。
唯一勝てる方法があるとすれば、実験結果で殴ります。(だれも否定できない事実を突きつける)

原稿は紙に印刷して用意する

プレゼンではメモは持ってもいいと思います。メモより印刷した原稿がベストです。
短い原稿だとしても、手書きより印刷します。テンパると手書き文字は読みにくい場合があります。

メモを持たないことがいい、みたいな風潮はありますが、話したいことを時間以内に漏れなく話すほうがいいに決まっています。
プロンプターが使えるか、100%原稿が頭に入っている人はそうしてもいいと思いますが。

時間管理は、パワポの時間測定が利用できます。
dekiru.net

原稿は一度作ってプリントアウトして確認します。紙に印刷すると良くない言い回しがなぜか発見されるという効果があります。
一度、その原稿を見ながら必ずリハーサルをします。時間を確認することと、つまってしまう部分を確認して原稿をアップデートします。

リアルのレーザーポインタよりは、マウスを使うのがおすすめです。
最近のパワポはマウスでレーザーポインタが使えます。また、最近はSkypeで繋ぐというケースも多いので、このようにすると、接続で見ているている人にももちろん指している場所が見れます。

といったものもありますが、なれていないと、もしくは性能が悪いとページ送りや、リンククリックがもたつくことがあります。それなら、マウスを使うほうがよいです。

資料の構成の技術

ランディングページを作って、ハイパーリンクで行ったりり来たりするような、凝ったパワポを作る人もいますが、パワポでのプレゼン中のクリック操作はもたつく原因になるのでやめたほうがよいです。どうしても戻って表示する必要があるなら同じページをcopyして挟んでおきます。ページ送りのみで対応できるからです。動画を埋め込みたい場合も、クリックでスタートするより自動スタートするようにしておくほうが良いと思います。
「理科系の作文技術」という書籍でも似たようなようなことがかかれていました。このころの前提はOHPなのでちょっと違いますが、戻ったりクリックしたりのコストを削減するという意味では同じです。
f:id:s51517765:20191109124418p:plain
ハイパーリンクでのページ移動は避ける
1ページの中で「小結論」がでるように資料は構成します。
そのページで言いたいことが、実験方法の説明なのか、全体の結論なのか、問題(トラブル)の事例だったりすると思いますが、それらがわかるように記載しておきます。
何を聞いているのか?を意識してもらってから聞いてもらうと理解しやすくなります。
図や表を複数のセルときは、その図ごとに主張したいことを書いておきます。
f:id:s51517765:20191109125113p:plain
図や表にも結論を書いておくと伝わりやすい
toyokeizai.net

質疑を乗り切る

質問者は内容を理解していないから質問してきます。よって的はずれであることが多いです。的はずれな質問に答えることは非常に難しいです。
的はずれな質問者は、「質問に対して答えになっていない」と、さらに畳み掛けてきますが、きちんと聞いていた人は的はずれだと認識してくれているはずなので、諦めます。諦めていいのか?

だれか権威者に助太刀を頼む、しかない気がします。

ただ難しいだけの質問であれば、質疑の時間は限られているので、結論(そのとおりです、いいえそうではありません)だけ答えて後程個別に議論をするようにするのが良いでしょう。

まとめ

何度かのプレゼンを経験して、注意するようになったことをまとめました。

私が大学の論文発表をしたころはちょうどパワポが使われ始めた頃でした。先進的な人々が使っていたという感じでした。
所属学会ではまだパワポ対応していませんでした(OHP)。
OHPなんてそろそろ、使ったことがない世代も出てきていると思いますが、イラストレーターやワード・パワポなどをつかってスライドを作り、インクジェットプリンタで専用OHPに印刷して作っていました。

大学に入学したころ、学部の教授が進めていたのが「理科系の作文技術」です。
基本的なプレゼンの注意点が書かれていると思います。

理科系の作文技術 (中公新書 (624))

理科系の作文技術 (中公新書 (624))