CDK Day 2023 に登壇してきました。
英語でプレゼンするのは今回が初です。周囲に日本人がいない中での登壇で、自分としては相当に背伸びしたチャレンジでした。なんとかやり通すことができましたので感想・振り返りを述べたいと思います。
CDK Day
CDK の話題に特化したカンファレンスイベントです。
今年は英語とスペイン語の2言語で発表を受け付けていました。Youtube Live で開催されるオンラインイベントです。これまでのアーカイブもチャンネルで公開されています。
日本からの登壇者として、私と tmokmss さんの2名が参加しました。
CDK Day 自体のイベント内容については tmokmss さんの情報以上に提供できるものがないので、私からはビビリ散らかしたり締め切り直前まで動けない症候群を発症しつつもなんのかんので迎えた本番までのあれこれや、終わってからの振り返りなどを語ろうと思います。チャレンジしようと思うみなさんの後押しになれば。
こんなにいい加減でも（一応？）やれちゃうもんなのね、と思ってもらえるなら嬉しいです。
登壇内容
こんな感じで20分枠の CfP を出しました。
ごく短くまとめると、CDK におけるデプロイ権限の考え方を押さえつつ Bootstrap が何をやってるか理解しましょう、理解できたらクロスアカウントのデプロイが簡単に構成できることがわかりますよ、という内容です。
実際に提出した CfP の内容はこんな感じです（以下）。
Title: Configure cross-account deployment using CDK
Decsription:
The way AWS CDK handles deployment permissions is really cool. It's set up to need as few permissions as possible for deployment and to make cross-account deployment easy.
In this session, we'll show you how to do cross-account deployment with CDK.
Describe your talk in as much detail as you desire:
The talk is composed of the following three topics;
- Overview of the "CDK Security and Safety Dev Guide"
- What is created with the CDK Bootstrap command and how it is used for deployment
- The setup to actually configure cross-account deployment
If you want to configure cross-account deployment with CDK, you first need to understand how CDK is bootstrapping for deployment, and why this bootstrap is useful.
After understanding the philosophy and implementation of permission design, let's move on to the practical part. I will show a sample code. Let's learn how to configure deployment across accounts using this code.
自分ではしょっぱいネタだと思ってたので採択されたのは意外でした。私のネタは CDK ビギナー向けにそこそこ共通して重要であろう部分をピックアップしたつもりなので、それが目に留まったのかもしれません。他の方は割ときっちり応用やってるコンテンツが多い印象でした。
資料はこちらです。
自己評価
自分では 20点30点くらいの出来かなと思ってます。
最低限のマナーとして尺の範囲内で喋れたのだけはよかったですが、本番では枠の半分ちょい(10分少々)と大幅な巻きでトークが終わってしまいました。時間超過は論外だけど早すぎるのもだいぶキツいです。自分史上一番ひどいプレゼンだったかなと思っています。
実際どういう振り返りポイントがあったかはこの記事の後ろの方で述べます。
経緯
前日譚です。登壇が決まった経緯なんですが、半分は自分の意思じゃないんですよね。流れとノリに任せていたらこうなってました。
自分の手持ちの知識で喋れそうなネタから CfP を書いて応募したら通ってしまい引っ込みがつかなくなったので、しょうがないから腹を括るかと。同僚氏や後進に向けて自分のチャレンジ（玉砕）する姿でもお見せできれば本望だろうと思いやりました。
ちょっとだけ、CDK Day の前フリになる社内の話をします。
もっと社外の世界に目を向けていこうぜ！という気持ちで、私は自社の Slack ワークスペースで「社外登壇支援部」なる活動をしています。
具体的に活動内容が決まってるわけではないんですが、パブリックな場所（特にカンファレンス）での登壇に興味のある人を集めてチャレンジを後押しする何かしらをやる、という方針でゆるっと運営しています。自社の仕事に関係ありそうなカンファレンスの CfP 応募をシェアしたり、ご希望であれば CfP や資料のレビューなんかをお手伝いしたり、自分以外にも社外のオープンなイベントで発表してきた仲間を wiki などにまとめてメンバーの実績を見える化したり、登壇決まった／決まりそうな人に応援のリアクションやコメントを付けたり、そういう感じの活動をしています。
（余談）この活動を始めた経緯は個人の note で記事を出してますので、よかったらそちらもご覧ください。
チャンネルを発足してみると、嬉しいことに自分以外にもイベント情報をシェアしてくれる方がいらっしゃいます。
CDK Day 自体は以前から認知してたんですが、こうして by-name でメンションもらったことで「やるか〜〜〜」というテンションになりました。自分ひとりの意思の力ではなかなか強く踏み出せないので本当にありがたいですね。気がある風な返事を書いてみたら、応援リアクションがついてしまいました。
リアクションがついたのを見て「ああ、これはもう CfP 出すしかないな」と思いました。
応募する以上はきちんと意義あるものを出さねばなので、自分が今の知識で喋れる内容から有用そうなトピックを選んで CfP を提出しました。で、幸いにも採択されてしまったので前述したプレゼンをやるに至りました。
ここまでの流れでお分かりいただけると思いますが、みずから「よし！英語やろう！！！」と思って自主的に挑戦したわけではなく、いろんな偶然の噛み合わせの結果そうなった感じです。ゆるく繋がる仲間がいるというのはありがたいですね。自分ひとりでは中々踏み出せないようなことにきっかけを与えてもらいました。たぶん「社外登壇支援部」の理想的な流れってこういう感じなんだろうなと思いました。誰かのチャレンジにきっかけを与える場所にしたいと思い発足しましたが、結果的に自分が一番助けられちゃいました。
自分の英語力
今後チャレンジするかもしれない人への参考として自分の英語戦闘力を書いておきます。「私の英語力なんて中学生未満だよ〜〜」などと雑に宣っても読者には何の参考にもならないと思うんで（我ながらキツいなと自覚はしつつも）できるだけ具体的に書いてみようと思います。
AWS ドキュメントなどで英語見たりすることはありますが、普段の英語との接点はそのくらいです。リーディングは基本 Google などの翻訳ツールに頼っていますし、なんなら原文より日本語ドキュメントを見ていることの方が多いと思います。昔、必要に駆られて OAuth2 や HTTP (multipart/form-data 関係) の RFC 読んだりしてた時期がありました。読んだのはごく一部ですし完全に読解したわけでもありませんのでかじった程度です。こんな感じで、必要がありそうな場面なら読む...くらいの温度です。
気が向いたときに re:Invent のセッションアーカイブなどを 0.5 - 0.75 倍速の字幕付きで見たり、見ながらシャドーイングしたり、といったことを稀にやったりします。さほど手応えはありませんし舌がついていかないことの方が多いです。単語を母音→子音で接続するパターンなど、単語のつながりを聞き取れないシーンがそこそこあります。
文法力は関係代名詞とか現在完了とかそのくらいが多少分かる程度です。慣用句的に使う言い回しはよくわからないものが多いですし、長い文章になると何がどこに係っているのか分からなくなります。頭が理解を拒否してしまうような気分になることが結構あります。語彙力は自分の業界分野ならそれなりに、くらいの感じだと思います。
会話はほぼムリです。リスニングの方はネイティブが AWS 関係のトピックを喋っている場合で3割聞き取れればいい方くらいの実感値で、普通の会話内容だとそれ未満です。「何言ってるかはほぼ聞き取れないけど、使ってた単語的にたぶんこういうこと言いたいんだろうな？」と想像するくらいが限界です。向こうの言ってる内容がほぼわからないので自分も何を表現したらいいのかわからなくてテンパります。何年か前に re:Invent に行ったのですが、そのときは Google 翻訳を開いたりジェスチャーを交えて最低限必要な会話をだましだまし、というノリでした。自分から話振りに行くとかはほぼできません。
準備編
だいたいこんな感じです。
- スライド作る
- トークスクリプトを ChatGPT に組ませて、言いづらい箇所やそぐわない場所を適宜手直し
- トークスクリプト全編が完成したら発表者ノートに転記
- 通しで喋ってみる。尺は多少気にするが本番意識ではない（詰まったら言い直したりノートを修正したりする）
- 本番のつもりで喋る
4,5 を数回繰り返しながら資料の微修正を加える、という感じで進めました。
振り返り
チャレンジしたこと自体は自分でも頑張ったと思ってますが、プレゼン自体は20点30点のコンテンツだったと思います。
1 のスライド作成は日本語で発表するとの同じノリで作成していました。このスライドのここではどういうニュアンスを出したい？何が言いたい？を整理して（この時点では伝えたい意図が大事なので整った文章表現じゃなくてもOK）、それを整形して翻訳する感じです。これは日本語で喋れないことを英語で表現できるわけがないだろという意識からそうしていたのですが、この感覚は割と当たってたかなと思います。このあたりは日本語での登壇経験値が生きました。
自分はスピーキングの経験値が乏しいので、喋れる量は日本語の 25-30% くらいが最大値だろうと見積もっていました。予定していたセクションの 2/3 くらいまで到達した時点ですでに資料が 25-26 ページになっており、この調子で資料を組むと予定時間内で終われない気配を感じました。1ページあたり1分の目安を仮置きして、母国語の発表でついつい入れがちな補足や周辺の与太話などを大幅にカットしながら追記・編集しました。編集するたびに自分のスライドに味気なさ・物足りなさを感じていく時間でした。ただ、それでも尺を超過するよりはマシなのでこのへんはそんなもんだろうと思っています。準備に十分余裕があるなら、母国語の発表と同じノリでひとまず自分が言いたいこと全部詰めで資料作成して、通してみた感触をもとに削りながら調整するのが良いです。たぶん。
こんな感じでトークスクリプト込みの初稿スライドができたんですが、お試しで喋ってみた時点で明らかに尺余り状態でした。本来ならここで「準備編」のステップ 4,5 で得た感覚を 1 にフィードバックして資料の再構成も含めてブラッシュアップの周回を回せていたらよかったと思います。4,5 をやってたのが発表当日だったんで時間的にその余裕がありませんでした（これやってた時点で本番の 4,5h 前くらいです）。1週間前くらいにそのステージに立ててたら良かったです。そのへんの進捗感覚が得られたのが一応の収穫でした。
日本語の発表なら尺の調整は割と容易なんですが、英語だとそれが難しいことを非常に実感しました。 プレゼンにおける時間調整のポイントって、そもそもの資料構成以外だとトークのスピードやディテールの掘り下げ度合いで短縮するか、あるいは枝葉スライドを時間経過見ながら飛ばしたりで調整します。要するに当日のアドリブで調整する部分が結構大きいです。少なくとも私はそんな感じでやっています。使い慣れない言語だとそうしたアドリブ頼みの時間調整が難しくなります。
必然的に資料で調整するウェイトが相対的に高くなります。トークスクリプトを書き出して詰まらず喋れる状態に持ってくまでが区切りなので、単純に修正自体のコストが高くスライドの構成をいじるようなブラッシュアップがやりづらくなります。しかし、プレゼンの完成度を上げるなら資料を構成レベルで見直しつつ修正するなんてごく普通の話なので、そうした修正の選択肢が取れなくなるほど余力がない状況だと伸びしろがキツくなっちゃうわけです。今回の私がまさにそれで、反省点を言語化するとしたらそのへんかなと思います。
総評すると、反復練習の周回数が圧倒的に足りてなかったです。今回の反省点はそこに尽きます。コンテンツ密度が低く、かつ尺のコントロールも甘かったです。とはいえ、周回不足ではあったものの進め方自体はそれなりにいい線いってたかなと思います。
次回チャレンジするなら、10点20点の出来でもとにかく通しでリハできる状態に持っていくことを最優先して、そこからフィードバックループ回していく感じでやると思います。喋りでの時間調整が難しくなる分、資料のボリュームコントロールがシビアになります。その調整に注力するリソースを残すためにも、通しで喋れる状態を作って繰り返すのが最優先なのかなと。
おわりに
振り返りをこうして言葉にしてみると「反復練習が大事ってそれ日本語でも当たり前のやつでは...？」という感想しか出てきませんでした。
悪い意味で慣れが出てしまい、プレゼン準備の基本をサボってしまっていたのかもしれません。戒めですね。
tmokmss さんがレポートブログで述べている感想（下記）ですが、私も概ね同じ印象でした。
パブリックなイベントで英語登壇するのは初めてだったので緊張しました。とはいえ発表側は用意した英語を喋るだけでも完結できるので、高い英語力は必要ない印象です。また良い意味で「ちょうどよい」規模感のイベントなので、あまり気を張りすぎることもなく、とはいえ手を抜きすぎることもなく、初めての場としては適しているのではと思いました。
アドリブで喋るのは自分の実力では無理ゲーなので、カンペ読めばいいと割り切れる条件は気楽でした。翻訳ツール片手に英語でブログ書くのとハードルはそう変わらないと思います。（そう考えるとハードルが低く感じられるような気がしてきませんか？）
これで次回の英語登壇もいけるかと言われれば正直かなり自信ないですが、それでもやってみた実績が出来たことでメンタル面の大きなハードルは超えたのかなと思います。満足いくコンテンツではなかったため運営メンバーの皆さんに対する申し訳なさもありますが、チャレンジの機会をいただけて本当に感謝です。
反省点はたくさんあるものの、自分の殻を破る良いチャレンジができたことは事実なのでそこは自分でもよくやったかなと思います。
SNS でも日本の方から労いのコメントいただいたりして嬉しかったです。ありがとうございました。
おまけ
X で登壇の宣伝ポストをした際に、JAWS 界隈の仕掛け人として有名人なお方から英語登壇のアドバイスをいただいてました。
資料作成を開始した当初は「トークに自信ないから、プレゼン的にはイマイチだけど喋ること全部文字起こしするくらいの資料にしようかな・・・」などと考えていました。アドバイスを拝見してるうちにスライドの文字情報はできるだけ抑えつつ発表者ノートのカンペを使ってトークで補っていく方向で思い直し、方針を変えました。
おかげで、スライドの文字そのまま読み上げるようなプレゼンにならずに済みました（そのスタイルはプレゼンとしてあまり綺麗じゃないですしね）。
お名前隠しきれてなくてアレなんですが、御本人の登壇レポートをご紹介します。せっかく貴重な経験談をシェアいただいたことですし、今後チャレンジを考えるみなさんにもきっと参考になる内容と思いますのでぜひ一読ください。
私はここまでの準備をするだけの余力や伝手がなかったので可能な範囲内で、ではありましたが、経験者のお話しをお伺いできたのは大変ありがたかったです。この場を借りて御礼申し上げます。
橋本 拓弥(記事一覧)
プロセスエンジニアリング部
業務改善ネタ多め & 開発寄りなコーポレートエンジニアです。普段は Serverless Framework, Python, Salesforce あたりと遊んでいます
