2014/07/12

IT系の勉強会でそこそこ上手く話せる3つのトピック

いわゆる勉強会というやつをやってみた。IT勉強会カレンダーに掲載するほどオープンなものではない。SlideShareにアップロードしている人が多少いたくらいか。

内容はエンジニアリング系で、JavaによるWebアプリの開発とその周辺分野が中心だった。各自がスライドを用意して順番に話し、聞き手が質問や意見を投げかける、といった形で進行する。

何人もの発表を聞き、実際に自分自身で話してみて、「この手の勉強会でそこそこのクオリティを担保するためのポイント」が少し見えてきたのでメモする。


*発表テーマ

重要なのは結局、話す内容に尽きる。スライドが見やすいとか、話し方が丁寧だとか、そういったプラス点は瑣末なもののように感じた。あるいは、内容の良さと伝え方の良さは連動しているのかもしれない。いずれにせよ、発表テーマが重要であることに異論はないと思う。

それなりに魅力的だった発表トピックは、主に「問題解決型」「手法紹介型」「原理解説型」の3つに分かれる。また、聞き手に対する影響として「既知/共感」「未知/刺激」の2種類があるように思う。これらは私の主観的な分類と命名で、他意はない。


*問題解決型

話者が実際に直面した問題とその解決策を共有する。まず「こういうことがしたい」から始まって、「とりあえずこうやってみた」が、「こういうエラーが起きた」。調べてみると「実はこうなっていたからだ」と分かった。その後、「じゃあこうすればいい」と解決策に辿り着く。

既に同じ問題と出会ったことのある人は、課題提起に共感し、解決策を聞いて「そういうことだったのか!」と感心する。少し時間を掛けて調べたり試行錯誤すれば同じことは学べたはずだ。しかし、スケジュールや優先順位の関係もあり、必ずしも学習に注力できるわけではない。だからこそ、「少しだけ頑張って1つ調べました」を複数人が持ち寄ることで、勉強会が成り立つのだと思った。

一方、その問題とまだ出会っていない人は、将来同じような問題と出会ったときのための方向性を学ぶことができる。とは言え、実感していないと理解できないことも多い。そうした聞き手にとっての意義はむしろ、いざとなったときに「誰に聞けばいいのか」「どのスライドを見返せばいいのか」というリファレンスを蓄積できることだと思う。

なお、問題を複数列挙することもある。「ついついやってしまうミス」「ツールを初めて使ってみたけど分からないことだらけだったよ」といった内容だ。この場合は主なものを3点ほどにまとめて、失敗例(アンチパターン)と成功例を順に示すと分かりやすい。


*手法紹介型

話者が新しいツールや方法を紹介する。まず「こういうことがしたい」から始まって、「でもどうしたらいいか分からない」or「すぐに思いつくやり方だと手間が掛かる」といった聞き手の状況に理解を示した上で、「こういうのがあるんですよ」と紹介する。そして「こうやって使います」と手順やサンプルコード、デモを示す。

「こういうことがしたい」と思いつつ、無知や手間が原因で行動できなかった人は、発表を歓迎するだろう。また、そのツールや手法について、言葉だけ聞いたことがあるとか、検索して調べてみたけどいまいち理解できないとか、書籍を購入したものの読んでいないとか、そういった人は、実践的でシンプルな手順・サンプルコードをすぐに活用するはずだ。

一方、手段を知らないが故に「こういうことをしよう」という発想さえ持たない人もいる。彼らは新しい手段を知ることによって、次の機会に「こういうことをしよう」と思いつくことができるようになる。「あのツールを使えば簡単にできるかもしれない」という見積もりがあるので、実行を恐れない。シンプルなデモを1つ見るだけで、素人は勇気づけられ、挑戦できるようになるのだと思う。


*原理解説型

自分たちが普段使っている技術の裏側はどうなっているのか、といった原理を解説する。「あまり知らなくてもこうすれば問題ないからOKだよね」と現状を共有した上で、「でもこういうとき迷いませんか?」と投げかける。そして「じゃあ全体像を理解して安心しましょうよ」と提案する。

ツールの仕組み・全体像を知らないまま利用している人は、潜在的な不安を抱えている。かといって、時間を掛けてドキュメントに目を通すほどの必要性は感じていない。そういう人は多い。当然ながら、「短時間でドキュメントの要約を理解したい」というニーズを抱えている。10人が1つずつツールを担当して要約すると、1の努力で10の知見を共有することができる。

そもそもツールを利用したことがない聴き手の場合、その発表を聴くことで全体像をざっくりと知ることができる。結果、効率的な自主学習に繋げることができるかもしれない。少なくとも、知らないから手を出しにくい、という状況から前進するはずだ。聞いた上でやっぱいいやとなったり、実際に使っていないから聞いても分からないかもだけど。

ちなみに、注意点としては単調でつまらない発表になりがちだということ。文献やドキュメントの要約を話すことになると思うが、そういった引用元は「脳をフル回転して主観的に読むこと」を想定している場合が多い。同じ内容を同じように話すだけでは、発表の場において、受動的な聴き手にとって苦痛な時間となる。

したがって、話したいことが10あったら1に抑えるべきだと思う。なるべくビジュアル化して、なるべくシンプルに、要点だけを紹介する。「つまりどういうこと?」「だから何が言いたいの?」と思わせないように練習・改善を繰り返すのが良いかもしれない。苦労の割に受けが良いとは限らないのでコスパは悪い。ただ、説明力は格段にレベルアップすると思う。


*最後に

スライドについて補足する。①共有・DL可能な状態にすることと、②参考サイトや推奨書籍を掲載しておくと、聴き手にとって嬉しい。①はサンプルコードを読み直すときに助かる。②はより体系的な・より深みのある学習へと繋げることができる。

時間制限のあるプレゼンテーションでは、聞きたことの10%も覚えられず、言いたいことの10%も伝わらないので、見返せるスライドだとか、分量のある本にバトンタッチするのが望ましい。

なお、偉そうなことを書いてはいるが、自分は全然上手く話せなかった。結構悔しい思いをしたので、同じ過ちを犯さないように振り返ってみた所存である。要は、反省文でした。

おしまい。