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

Slide 1

Slide 1 text

エンジニアが技術登壇する時考えるべき事〜ハマコーの場合〜

Slide 2

Slide 2 text

⾃⼰紹介 • 濱⽥孝治（ハマコー） • 2017年9⽉⼊社（元独⽴系SIer） • AWS事業本部コンサルティング部 • 好きなサービス • CloudFormation • ECS、Fargate、EKS • @hamako9999 2

Slide 3

Slide 3 text

3 ⼈⽣を変えた登壇

Slide 4

Slide 4 text

4 確実にこれが⼈⽣を変えた

Slide 5

Slide 5 text

5 登壇するまでの経緯 • 2018年9⽉10⽇ • 嵩原さん「Developers.IO 2018 セッション⼀覧決まりました〜」

Slide 6

Slide 6 text

6 登壇するまでの経緯 • 2018年9⽉10⽇ • 嵩原さん「Developers.IO 2018 セッション⼀覧決まりました〜」 • ハマコー「お、えーなになに。聞いてないぞ。そもそも聞かれてないし、どういうことやねん(# ﾟДﾟ)」

Slide 7

Slide 7 text

7 登壇するまでの経緯 • 2018年9⽉10⽇ • 嵩原さん「Developers.IO 2018 セッション⼀覧決まりました〜」 • ハマコー「お、えーなになに。聞いてないぞ。そもそも聞かれてないし、どういうことやねん(# ﾟДﾟ)」 • ハマコー「てか、こんだけセッションあるのに、は︖コンテナセッションない︖このご時世に︖どういうこっちゃ︕ （●｀ε´●）」

Slide 8

Slide 8 text

8 登壇するまでの経緯 • 佐々⽊さんに凸撃

Slide 9

Slide 9 text

9 登壇するまでの経緯 • 3分後横⽥さんから

Slide 10

Slide 10 text

10 登壇当⽇めちゃくちゃ準備して最⼤限に集中してごっつ楽しんでしゃべることができた

Slide 11

Slide 11 text

11 登壇して得たこと • 登壇に対する⾃分なりのスタイルを確⽴できた • 社内外で「コンテナハマコー」的な雰囲気になった • 登壇することの怖さが全くなくなった

Slide 12

Slide 12 text

12 登壇機会の作り⽅

Slide 13

Slide 13 text

13 きっかけはそれぞれ • 気になるイベントのLT枠から挑戦する • LT枠は早いもの勝ちの場合が多い • 時間も短いし挑戦しやすい • プロポーザルを出す（CFPに応募する） • ビルダーズコン2019 → 落ちた • デベロッパーズサミット2020 → 落ちた • → 何故かパネラーでの登壇打診が • ブログ書く • Splunkミートアップは、このブログがきっかけ • 【祝】FargateでログドライバーにSplunkが利⽤可能になりました︕ • コミュニティ運営側に回る • JAWS-UG コンテナ⽀部運営に⼊った → 喋った

Slide 14

Slide 14 text

14 登壇内容のストーリーの作り⽅

Slide 15

Slide 15 text

15 ハマコーのベースはほぼ全てこれ

Slide 16

Slide 16 text

16 ストーリーの作り⽅で気をつけていること 1. 「技術の伝達」だけではなく「⾏動を促す」内容にする 2. 冒頭で「この話を聞く意味」を強く出す

Slide 17

Slide 17 text

17 １．「技術の伝達」だけではなく「⾏動を促す」内容にする

Slide 18

Slide 18 text

18 「⾏動を促す」とは︖ • 45分で得られる技術知識は限られている • 実際にプレゼンテーションという場を技術要素の羅列だけで終わらせるのはもったいない • ⾃分としては「あー、ええ話やったわぁ」で終わる登壇ではなく、「そっか、早速今の現場で試してみよ」という⾏動を促す登壇にこだわりたい

Slide 19

Slide 19 text

19 紹介タイム過去の登壇時に考えていた例

Slide 20

Slide 20 text

コンテナジャーニー明⽇から速攻始める AWSでの段階式コンテナ運⽤紹介中⾏動を促す

Slide 21

Slide 21 text

21 コンテナジャーニーひとりでDocker使ってみるチーム内でイメージを共有するサーバーにコンテナをデプロイするリポジトリから⾃動デプロイするコンテナを本番運⽤する紹介中⾏動を促す

Slide 22

Slide 22 text

22 「コンテナジャーニー」でこだわった点 • 仮定︓実際に現場でコンテナ化を検討するとき、どこから始めるかわからない⼈たちが多いのではないか︖ • 中⾝の展開︓最初のハードルが⾼いのは良くない。ミニマムなところから初めてストーリー仕⽴てで話すことで、「おー、そっか。こんな簡単に始めれるんだ」と思ってもらいたい • 全体構成︓５段階の旅形式にして、いろんなシチュエーションにある⼈達に、それぞれの観点で「次に何をするのか」を持ち帰ってもらいたいジャーニーという単語を使おう︕︕

Slide 23

Slide 23 text

23 ２．冒頭で「この話を聞く意味」を強く出す

Slide 24

Slide 24 text

24 「この話を聞く意味」とは︖ • いわゆる「デマンドの植え付け」 • 45分は⻑い。今聞いている話が「これ、ほんまに⾃分の役に⽴つのかなぁ」というところが曖昧なままだと、聴衆の集中⼒を集めるのが難しい • 結果、昼寝や内職につながる • そういう⼈が多いと喋っている⾃分のテンションもさがっていく • ⾃分がブログでリード⽂書く時に気をつけていることとまるっきり同じ • 45分枠だと、最初の7分ぐらいは⾃⼰紹介とデマンドの植え付けに使っている

Slide 25

Slide 25 text

25 紹介タイム過去の登壇でつかっていたデマンドの植え付けを紹介

Slide 26

Slide 26 text

AWSの全てをコードで管理する⽅法〜その理想と現実〜濱⽥孝治（ハマコー）紹介中デマンドの植え付け

Slide 27

Slide 27 text

27 みなさん AWSをコードで管理することにどんなイメージをお持ちでしょうか︖ 紹介中デマンドの植え付け

Slide 28

Slide 28 text

28 CloudFormation 紹介中デマンドの植え付け

Slide 29

Slide 29 text

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 紹介中デマンドの植え付け

Slide 30

Slide 30 text

30 めちゃくちゃ強⼒だけど、つかいこなしが難しい紹介中デマンドの植え付け

Slide 31

Slide 31 text

31 CloudFormationを知らないとどうなるか︖ 紹介中デマンドの植え付け

Slide 32

Slide 32 text

32 これから⻑くAWSを運⽤していく時その効率化の選択肢を捨てることになる紹介中デマンドの植え付け

Slide 33

Slide 33 text

33 なぜハマコーはここに⽴っているのか︖ Infrastructure as Codeの可能性を感じてもらいたい今のあなたの⽇常業務が劇的に効率化する可能性あり Infrastructure as Codeの危険性もしってもらいたいあまり準備せずにいきなり導⼊するとインフラが溶ける可能性あり紹介中デマンドの植え付け

Slide 34

Slide 34 text

34 40分後みなさんにこうなってもらいたい Infrastructure as Code未体験の⼈その可能性に気づきCloudFormationを書きたくてうずうずする Infrastructure as Code体験済みの⼈今の運⽤を⾒直すためのきっかけとなる紹介中デマンドの植え付け

Slide 35

Slide 35 text

35 デマンドの植え付けをやることのメリット • ⾃分のなかでメッセージが明確になる • ちゃんと集中してくれる • ストーリーをきちんと考える契機となる

Slide 36

Slide 36 text

36 秘伝のスライドテンプレート

Slide 37

Slide 37 text

37 あんまりこだわりない • クラスメソッドで⽤意されているテンプレートがすごく使いやすい • シンプルで⾊使いがはっきりしている • 接続詞やフックに使いやすい⼀枚物が最初から⽤意されている • 他の⼈との差別化はつけにくいかも • テック系だとAWSがやってるような⿊背景のほうが映えるかもね

Slide 38

Slide 38 text

38 ひとことだけ何かを⾔いたい時に使⽤します売上が30％アップしました︕ ところが、これがいいところなんですよ︕ めっちゃワクワクしてきたでしょ︖

Slide 39

Slide 39 text

39 ひとことだけ何かを⾔いたい時に使⽤します収益が10%ダウンしてしまいましたあんたごっつ損しますよほんまそれでええの︖

Slide 40

Slide 40 text

40 書籍だとこれ

Slide 41

Slide 41 text

41 聴衆をつかんではなさない話し⽅、動き⽅

Slide 42

Slide 42 text

42 話し⽅・動き⽅ 1.リハーサルをやる。というかやれ 2.可能な限り聴衆を⾒る 3.スライドではなく⾃分の喋りをメインにする

Slide 43

Slide 43 text

43 １．リハーサルをやる。というかやれ • 実際に喋って通してみることで無限のメリットがある（もちろん録⾳してやる） • 時間配分が適切か • ⾃分の喋りたいことが頭にはいっているか • ⾃分の喋りとスライドの辻褄があっているか • ⾃分の意識していない⼝癖がないか

Slide 44

Slide 44 text

44 １．リハーサルをやる。というかやれ • 実際に喋って通してみることで無限のメリットがある（もちろん録⾳してやる） • 時間配分が適切か • ⾃分の喋りたいことが頭にはいっているか • ⾃分の喋りとスライドの辻褄があっているか • ⾃分の意識していない⼝癖がないか • 他⼈に聞いてもらうのもめちゃくちゃ有効 • 独りよがりになっている説明がないか • ストーリーがわかりやすいか • 変な動きしてないか

Slide 45

Slide 45 text

45 １．リハーサルをやる。というかやれ • 実際に喋って通してみることで無限のメリットがある（もちろん録⾳してやる） • 時間配分が適切か • ⾃分の喋りたいことが頭にはいっているか • ⾃分の喋りとスライドの辻褄があっているか • ⾃分の意識していない⼝癖がないか • 他⼈に聞いてもらうのもめちゃくちゃ有効 • 独りよがりになっている説明がないか • ストーリーがわかりやすいか • 変な動きしてないかやればやるほどうまくなる︕

Slide 46

Slide 46 text

46 ２．可能な限り聴衆をみる • あなたは今誰に喋ってるかという単純なこと • 聴衆に何かを伝えたいのであれば、聴衆を⾒ない理由はない • ⽬線の流し⽅が難しく感じるかもだが慣れてくる • AWSJ⻲⽥さんは技術よりの話なのにほぼ⼿元をみていない

Slide 47

Slide 47 text

47 ２．可能な限り聴衆をみる • あなたは今誰に喋ってるかという単純なこと • 聴衆に何かを伝えたいのであれば、聴衆を⾒ない理由はない • ⽬線の流し⽅が難しく感じるかもだが慣れてくる • AWSJ⻲⽥さんは技術よりの話なのにほぼ⼿元をみていない • 実際にやろうとするとめちゃくちゃ難しい • 喋る内容が完全に頭にはいってないと⼿元をみてしまう • スピーカーモニターがある会場などほぼない • ノートPC5割、聴衆5割ぐらいであれば上出来

Slide 48

Slide 48 text

48 ２．可能な限り聴衆をみる • あなたは今誰に喋ってるかという単純なこと • 聴衆に何かを伝えたいのであれば、聴衆を⾒ない理由はない • ⽬線の流し⽅が難しく感じるかもだが慣れてくる • AWSJ⻲⽥さんは技術よりの話なのにほぼ⼿元をみていない • 実際にやろうとするとめちゃくちゃ難しい • 喋る内容が完全に頭にはいってないと⼿元をみてしまう • スピーカーモニターがある会場などほぼない • ノートPC5割、聴衆5割ぐらいであれば上出来 • ⼀番だめなのはスクリーンを⾒ながら喋ること • やりがち…だけど、きをつけよう

Slide 49

Slide 49 text

49 ⼀番重要なやつ３．⾃分の喋りをメインにする

Slide 50

Slide 50 text

50 さらに⾔うと３．スライドではなく⾃分の喋りをメインにする

Slide 51

Slide 51 text

51 ３．⾃分の喋りをメインにする • 登壇（プレゼン）において聴衆にとどける材料は２つ • 喋り • スライド

Slide 52

Slide 52 text

52 ３．⾃分の喋りをメインにする • 登壇（プレゼン）において聴衆にとどける材料は２つ • 喋り • スライド • 喋りをメインにすることで、登壇（プレゼン）に流れが⽣まれる

Slide 53

Slide 53 text

53 ３．⾃分の喋りをメインにする • 登壇（プレゼン）において聴衆にとどける材料は２つ • 喋り • スライド • 喋りをメインにすることで、登壇（プレゼン）に流れが⽣まれる聴衆がすっと内容に集中しやすくなる

Slide 54

Slide 54 text

54 ２つの喋りの構造の違いすごい重要なポイントがあるんですよ。それがこちら。 ①喋りがメインスライドさらに続けて気をつけるポイントを紹介します。スライドプレゼンの流れはい。このスライドのここらへんが重要なんですよ。スライドそうですね。こういったところに気をつけましょうスライド ②スライドがメイン

Slide 55

Slide 55 text

55 ３．⾃分の喋りをメインにする（まとめ） • プレゼンの流れが頭にはいっていなくて、スライドをみてから喋りを思い出すような場合に、スライドがメインで喋ってしまいがち • リハーサルを繰り返すことで殆どは⾃然と解消される • 今まで具体的に意識していなかった⼈は、この部分着⽬してリハーサルをしてみると全然ちがうと思います

Slide 56

Slide 56 text

56 まとめ

Slide 57

Slide 57 text

57 まとめ • 登壇機会を得るには⾏動⼒のみ • プレゼン冒頭で「聴衆が聞くことの意味」を強く訴える • スライドテンプレートはなんでもよい • 「⼀⽣使える⾒やすい資料のデザイン⼊⾨」はおすすめ • まずは下の３つをおさえておく • リハーサルを絶対やる • 可能な限り聴衆をみるように意識づける • ⾃分の喋りをメインにする • しつこいけど、⻄脇さんのエバンジェリスト養成講座はオススメ