エンジニアが技術登壇する時に考えるべき事

エンジニアのアウトプットにおいて、登壇（プレゼン）は究極のアウトプットと言って良いでしょう。準備にも時間がかかりますし、実際に聴衆を前に喋る時間をもらうということで、ブログの数倍ハードルが高いと言えます。

だからこそ、登壇にはメリットが沢山あります。

このスライドでは、登壇において気をつけておいたほうが良いことについて、ベーシックな点を中心にまとめてみました。これから登壇を始めてみようかなという方の参考になれば幸いです。

Transcript

1. エンジニアが技術登壇する時 考えるべき事 〜ハマコーの場合〜
2. ⾃⼰紹介 • 濱⽥孝治（ハマコー） • 2017年9⽉⼊社（元独⽴系SIer） • AWS事業本部コンサルティング部 • 好きなサービス • CloudFormation • ECS、Fargate、EKS • @hamako9999 2
3. 3 ⼈⽣を変えた登壇
4. 4 確実にこれが⼈⽣を変えた
5. 5 登壇するまでの経緯 • 2018年9⽉10⽇ • 嵩原さん「Developers.IO 2018 セッション⼀覧決まりま した〜」
6. 6 登壇するまでの経緯 • 2018年9⽉10⽇ • 嵩原さん「Developers.IO 2018 セッション⼀覧決まりま した〜」 • ハマコー「お、えーなになに。聞いてないぞ。そもそも聞 かれてないし、どういうことやねん(# ﾟДﾟ)」
7. 7 登壇するまでの経緯 • 2018年9⽉10⽇ • 嵩原さん「Developers.IO 2018 セッション⼀覧決まりま した〜」 • ハマコー「お、えーなになに。聞いてないぞ。そもそも聞 かれてないし、どういうことやねん(# ﾟДﾟ)」 • ハマコー「てか、こんだけセッションあるのに、は︖コン テナセッションない︖このご時世に︖どういうこっちゃ︕ （•｀ε´•）」
8. 8 登壇するまでの経緯 • 佐々⽊さんに凸撃
9. 9 登壇するまでの経緯 • 3分後横⽥さんから
10. 10 登壇当⽇ めちゃくちゃ準備して 最⼤限に集中して ごっつ楽しんで しゃべることができた
11. 11 登壇して得たこと • 登壇に対する⾃分なりのスタイルを確⽴できた • 社内外で「コンテナハマコー」的な雰囲気になった • 登壇することの怖さが全くなくなった
12. 12 登壇機会の作り⽅
13. 13 きっかけはそれぞれ • 気になるイベントのLT枠から挑戦する • LT枠は早いもの勝ちの場合が多い • 時間も短いし挑戦しやすい • プロポーザルを出す（CFPに応募する） • ビルダーズコン2019 → 落ちた • デベロッパーズサミット2020 → 落ちた • → 何故かパネラーでの登壇打診が • ブログ書く • Splunkミートアップは、このブログがきっかけ • 【祝】FargateでログドライバーにSplunkが利⽤可能になりました︕ • コミュニティ運営側に回る • JAWS-UG コンテナ⽀部運営に⼊った → 喋った
14. 14 登壇内容のストーリーの作り⽅
15. 15 ハマコーのベースはほぼ全てこれ
16. 16 ストーリーの作り⽅で気をつけていること 1. 「技術の伝達」だけではなく「⾏動を促す」内容に する 2. 冒頭で「この話を聞く意味」を強く出す
17. 17 １．「技術の伝達」だけではなく 「⾏動を促す」内容にする
18. 18 「⾏動を促す」とは︖ • 45分で得られる技術知識は限られている • 実際にプレゼンテーションという場を技術要素の羅列だけで終わらせ るのはもったいない • ⾃分としては「あー、ええ話やったわぁ」で終わる登壇ではなく、 「そっか、早速今の現場で試してみよ」という⾏動を促す登壇にこだ わりたい
19. 19 紹介タイム 過去の登壇時に考えていた例
20. コンテナジャーニー 明⽇から速攻始める AWSでの段階式コンテナ運⽤ 紹介中 ⾏動を促す
21. 21 コンテナジャーニー ひとりでDocker使ってみる チーム内でイメージを共有する サーバーにコンテナをデプロイする リポジトリから⾃動デプロイする コンテナを本番運⽤する 紹介中 ⾏動を促す
22. 22 「コンテナジャーニー」でこだわった点 • 仮定︓実際に現場でコンテナ化を検討するとき、どこから始めるかわ からない⼈たちが多いのではないか︖ • 中⾝の展開︓最初のハードルが⾼いのは良くない。ミニマムなところ から初めてストーリー仕⽴てで話すことで、「おー、そっか。こんな 簡単に始めれるんだ」と思ってもらいたい • 全体構成︓５段階の旅形式にして、いろんなシチュエーションにある ⼈達に、それぞれの観点で「次に何をするのか」を持ち帰ってもらい たい ジャーニーという単語を使おう︕︕
23. 23 ２．冒頭で「この話を聞く意味」を 強く出す
24. 24 「この話を聞く意味」とは︖ • いわゆる「デマンドの植え付け」 • 45分は⻑い。今聞いている話が「これ、ほんまに⾃分の役に⽴つの かなぁ」というところが曖昧なままだと、聴衆の集中⼒を集めるのが 難しい • 結果、昼寝や内職につながる • そういう⼈が多いと喋っている⾃分のテンションもさがっていく • ⾃分がブログでリード⽂書く時に気をつけていることとまるっきり同 じ • 45分枠だと、最初の7分ぐらいは⾃⼰紹介とデマンドの植え付けに 使っている
25. 25 紹介タイム 過去の登壇でつかっていた デマンドの植え付けを 紹介
26. AWSの全てを コードで管理する⽅法 〜その理想と現実〜 濱⽥孝治（ハマコー） 紹介中 デマンドの植え付け
27. 27 みなさん AWSをコードで管理することに どんなイメージをお持ちでしょうか︖ 紹介中 デマンドの植え付け
28. 28 CloudFormation 紹介中 デマンドの植え付け
29. 29 CloudFormationの位置付け CloudFormation VPC Public subnet Amazon EMR Amazon Kinesis Data Firehose Amazon Athena Amazon Simple Notification Service Amazon Simple Queue Service Amazon EC2 Amazon Elastic Container Service AWS Lambda AWS Fargate Amazon WorkSpaces AWS IoT Core Amazon Personalize Amazon CloudWatch Amazon Simple Storage Service (S3) Amazon RDS 紹介中 デマンドの植え付け
30. 30 めちゃくちゃ強⼒ だけど、つかいこなしが難しい 紹介中 デマンドの植え付け
31. 31 CloudFormationを 知らないとどうなるか︖ 紹介中 デマンドの植え付け
32. 32 これから⻑くAWSを運⽤していく時 その効率化の選択肢を捨てることになる 紹介中 デマンドの植え付け
33. 33 なぜハマコーはここに⽴っているのか︖ Infrastructure as Codeの可能性を感じてもらいたい 今のあなたの⽇常業務が劇的に効率化する可能性あり Infrastructure as Codeの危険性もしってもらいたい あまり準備せずにいきなり導⼊するとインフラが溶ける可能 性あり 紹介中 デマンドの植え付け
34. 34 40分後みなさんにこうなってもらいたい Infrastructure as Code未体験の⼈ その可能性に気づきCloudFormationを書きたくてうずうず する Infrastructure as Code体験済みの⼈ 今の運⽤を⾒直すためのきっかけとなる 紹介中 デマンドの植え付け
35. 35 デマンドの植え付けをやることのメリット • ⾃分のなかでメッセージが明確になる • ちゃんと集中してくれる • ストーリーをきちんと考える契機となる
36. 36 秘伝のスライドテンプレート
37. 37 あんまりこだわりない • クラスメソッドで⽤意されているテンプレートがすごく使いやすい • シンプルで⾊使いがはっきりしている • 接続詞やフックに使いやすい⼀枚物が最初から⽤意されている • 他の⼈との差別化はつけにくいかも • テック系だとAWSがやってるような⿊背景のほうが映えるかもね
38. 38 ひとことだけ何かを⾔いたい時に使⽤します 売上が30％アップしました︕ ところが、これがいいところなんですよ︕ めっちゃワクワクしてきたでしょ︖
39. 39 ひとことだけ何かを⾔いたい時に使⽤します 収益が10%ダウンしてしまいました あんたごっつ損しますよ ほんまそれでええの︖
40. 40 書籍だとこれ
41. 41 聴衆をつかんではなさない話し⽅、動き⽅
42. 42 話し⽅・動き⽅ 1.リハーサルをやる。というかやれ 2.可能な限り聴衆を⾒る 3.スライドではなく⾃分の喋りをメインにする
43. 43 １．リハーサルをやる。というかやれ • 実際に喋って通してみることで無限のメリットがある（もちろん録 ⾳してやる） • 時間配分が適切か • ⾃分の喋りたいことが頭にはいっているか • ⾃分の喋りとスライドの辻褄があっているか • ⾃分の意識していない⼝癖がないか
44. 44 １．リハーサルをやる。というかやれ • 実際に喋って通してみることで無限のメリットがある（もちろん録 ⾳してやる） • 時間配分が適切か • ⾃分の喋りたいことが頭にはいっているか • ⾃分の喋りとスライドの辻褄があっているか • ⾃分の意識していない⼝癖がないか • 他⼈に聞いてもらうのもめちゃくちゃ有効 • 独りよがりになっている説明がないか • ストーリーがわかりやすいか • 変な動きしてないか
45. 45 １．リハーサルをやる。というかやれ • 実際に喋って通してみることで無限のメリットがある（もちろん録 ⾳してやる） • 時間配分が適切か • ⾃分の喋りたいことが頭にはいっているか • ⾃分の喋りとスライドの辻褄があっているか • ⾃分の意識していない⼝癖がないか • 他⼈に聞いてもらうのもめちゃくちゃ有効 • 独りよがりになっている説明がないか • ストーリーがわかりやすいか • 変な動きしてないか やればやるほど うまくなる︕
46. 46 ２．可能な限り聴衆をみる • あなたは今誰に喋ってるかという単純なこと • 聴衆に何かを伝えたいのであれば、聴衆を⾒ない理由はない • ⽬線の流し⽅が難しく感じるかもだが慣れてくる • AWSJ⻲⽥さんは技術よりの話なのにほぼ⼿元をみていない
47. 47 ２．可能な限り聴衆をみる • あなたは今誰に喋ってるかという単純なこと • 聴衆に何かを伝えたいのであれば、聴衆を⾒ない理由はない • ⽬線の流し⽅が難しく感じるかもだが慣れてくる • AWSJ⻲⽥さんは技術よりの話なのにほぼ⼿元をみていない • 実際にやろうとするとめちゃくちゃ難しい • 喋る内容が完全に頭にはいってないと⼿元をみてしまう • スピーカーモニターがある会場などほぼない • ノートPC5割、聴衆5割ぐらいであれば上出来
48. 48 ２．可能な限り聴衆をみる • あなたは今誰に喋ってるかという単純なこと • 聴衆に何かを伝えたいのであれば、聴衆を⾒ない理由はない • ⽬線の流し⽅が難しく感じるかもだが慣れてくる • AWSJ⻲⽥さんは技術よりの話なのにほぼ⼿元をみていない • 実際にやろうとするとめちゃくちゃ難しい • 喋る内容が完全に頭にはいってないと⼿元をみてしまう • スピーカーモニターがある会場などほぼない • ノートPC5割、聴衆5割ぐらいであれば上出来 • ⼀番だめなのはスクリーンを⾒ながら喋ること • やりがち…だけど、きをつけよう
49. 49 ⼀番重要なやつ ３．⾃分の喋りをメインにする
50. 50 さらに⾔うと ３．スライドではなく ⾃分の喋りをメインにする
51. 51 ３．⾃分の喋りをメインにする • 登壇（プレゼン）において聴衆にとどける材料は２つ • 喋り • スライド
52. 52 ３．⾃分の喋りをメインにする • 登壇（プレゼン）において聴衆にとどける材料は２つ • 喋り • スライド • 喋りをメインにすることで、登壇（プレゼン）に流れが⽣まれる
53. 53 ３．⾃分の喋りをメインにする • 登壇（プレゼン）において聴衆にとどける材料は２つ • 喋り • スライド • 喋りをメインにすることで、登壇（プレゼン）に流れが⽣まれる 聴衆がすっと内容に集中しやすくなる
54. 54 ２つの喋りの構造の違い すごい重要なポイ ントがあるんです よ。それがこちら。 ①喋りがメイン スライド さらに続けて気を つけるポイントを 紹介します。 スライド プ レ ゼ ン の 流 れ はい。このスライ ドのここらへんが 重要なんですよ。 スライド そうですね。こう いったところに気 をつけましょう スライド ②スライドがメイン
55. 55 ３．⾃分の喋りをメインにする（まとめ） • プレゼンの流れが頭にはいっていなくて、スライドをみてから喋り を思い出すような場合に、スライドがメインで喋ってしまいがち • リハーサルを繰り返すことで殆どは⾃然と解消される • 今まで具体的に意識していなかった⼈は、この部分着⽬してリハー サルをしてみると全然ちがうと思います
56. 56 まとめ
57. 57 まとめ • 登壇機会を得るには⾏動⼒のみ • プレゼン冒頭で「聴衆が聞くことの意味」を強く訴える • スライドテンプレートはなんでもよい • 「⼀⽣使える⾒やすい資料のデザイン⼊⾨」はおすすめ • まずは下の３つをおさえておく • リハーサルを絶対やる • 可能な限り聴衆をみるように意識づける • ⾃分の喋りをメインにする • しつこいけど、⻄脇さんのエバンジェリスト養成講座はオススメ