RubyConf 2018で初英語LTしてきました 〜登壇の準備から当日話した英文まで全部公開します！〜

はじめに

以前もこのブログでお伝えしましたが、僕は2018年11月にロサンゼルス（LA）で開催されたRubyConf 2018に参加しました。

上記のエントリにも書いたとおり、僕は2日目に開催されたLT（ライトニングトーク）大会に参加して発表してきました。
LTではあるものの、これは僕にとって初めての英語の登壇でした。

このエントリでは、発表内容の詳細や発表に至るまでの準備、英語で発表するときのポイントなど、もしみなさんが英語で発表することになった際に役立つ情報をまとめてみます。

RubyConf 2018でLT中の僕（Photo by Kazumi Karbowski）

LTに参加しようと思ったきっかけ

RubyConf 2018への参加費用は僕が勤めているソニックガーデンに補助してもらいました。
そのときに会社のメンバーから「じゃあ、来年はRubyConfに登壇することが補助の条件ね」と冗談半分（いや、全部本気？）で言われました。

ただし、「来年のRubyConfでは登壇者になってね」と、なかなかハードルの高い条件を付けられております（ひー😂）。

RubyConf 2018に行ってきます 〜初めての海外カンファレンス参加＆海外一人旅に向けた準備について〜 - give IT a try

この話をブログに書いたところ、Rubyコミッタの笹田さんから「LTに出てみたらどう？」と提案されました。

現地でLTの募集があると思いますので、検討されてみてはいかがでしょうか

— _ko1 (@_ko1) November 7, 2018

最初は「えー、そんなの無理無理！！」と思ったんですが、RubyConfが近づくにつれ「アメリカに行く機会なんてそんなにないし、LTは現地で申し込めるみたいだし、いっちょ清水の舞台から飛び降りてみるか」と考えるようになりました。

LAに到着してから準備を開始

さて、なんとなく「LTをやってみよう」とは思っていたものの、10月〜11月はかなり多忙でまったく何も準備できないまま飛行機に飛び乗りました。
以下に登壇までの準備作業を書いていきますが、この準備はどれもLAに着いてから始めたものです。

過去の動画を見てLTの雰囲気を確認

RubyConfは毎年、すべての発表が動画としてYouTubeにアップされています。
LT大会の動画もYouTubeにアップされているので、まずこの動画をチェックしてどんな内容がLTとして発表されているのかをチェックしました。

RubyConf 2017: Lightning Talks - YouTube

この動画を見る限り結構「何を話しても自由」という印象で、中にはまったくRubyと関係ない話をしている人もいました。
なので、僕も自由にテーマを決めて問題なさそう、という確信を得ました。

登壇テーマは日本の講演内容を英語に焼き直すことに決定

英語で発表するのはいろいろハードルが高いので、ゼロからテーマを考えるよりも、過去に日本語で発表した内容を英語に直す方が簡単そうです。
また、コードがたくさん登場する発表の方が伝わりやすそうですし、LTだったら多少笑いが取れる話の方が向いてるかな〜とも思ったりしました。

そんなふうに考えた結果、今回は今年1月にRuby関西で発表した「プロを目指す人のための例外処理（再）入門 」という話がピッタリかも？と判断し、このスライドの内容をLT向けに短く再編集することにしました。

再び過去のRubyConfの動画をチェック

それからもう一度、過去のRubyConfの動画をチェックしました。
ただし今回はLT以外の動画も含めて視聴しました。

RubyConf 2017 - YouTube

目的は英語っぽい言い回しや、発表のスタイルを研究するためです。
また、日本人の発表も視聴して、日本人とネイティブの英語の話し方の違いみたいなものもチェックしてみました。

スライドを作成

インプットとして必要な情報はだいたい収集したので、次はアウトプットです。
今回は前述の日本語スライドをベースにして、英語版のスライドを作っていきました。

僕は普段スライドのテキストは少なめにして、口で話す内容を多めにする、というスタイルを取っているのですが、英語版では日本語版よりもテキストを多めに入れました。
これは発表当日に頭が真っ白になっても、スライドの内容を口に出して読めば何とか前に進めるようにするためです。
また、僕の英語の発音が悪くても、現地の人はスライドをみれば内容がわかる、という効果も狙っています。

（英語版のスライドはのちほどお見せします）

口に出して何度も練習する

スライドができたら次は練習です。
これは英語も日本語も同じですね。

特にLTは5分間という制限時間があるので、オーバーしないように気を付けなければいけません。
日本語に比べるとしゃべるスピードはさすがに遅くなってしまうので、かなり内容を削らないと5分に収まりませんでした。

また、英語っぽい抑揚の付け方も意識してみました。
日本人が英語を話すと、平坦でボソボソしたしゃべり方になりがちなので、できるだけ大きな声で、なおかつオーバーなくらい抑揚を付けて話す練習をしていました。

また、今回はちょっと無理でしたが、できればネイティブの友人にも聞いてもらってフィードバックをもらうのが理想的ですね。

LTに（急いで）申し込む

LAに来てから慌てて準備したものの、だいたい準備が整ったので、いよいよLTの申込みです。
聞くところによると、毎年LT大会はあっという間に定員が埋まってしまうみたいです。

申込みは2日目の基調講演が終わった後に、受付付近にあるボードに自分の名前を書き込む方式です。そして、早く名前を書き込んだ人から順に発表していきます。

LT大会の全体の時間は1時間半で、ボードに名前を書き込んでいても1時間半経ったところで打ち切られます。
何人ぐらい発表できるのか受付の人に聞いたところ、「そうねー、全部で20人ぐらいじゃないかなー」と言っていました。

せっかく準備したのに発表できずに帰るのは残念すぎるので、基調講演が終わった直後に受付へダッシュしました。
結構急いで駆けつけたつもりだったんですが、僕は14番目でした。

僕はなんとか間に合いましたが、秒速さんとkoicさんは出遅れてしまったようで（28番目と29番目）、お二人の出番が回ってきませんでした・・・。（残念😣）

ちなみに当日、最後の出番が回ってきた人は18番目の方でした。（僕も危なかった！）

こんなふうに英語で話しました

というわけで、こちらが今回作成した英語のスライドです。

実際どんな内容をしゃべったのか、以下で英語と日本語訳をスライドとともにご紹介します。

Hi everybody. My name is Junichi. I'm from Japan. Are you enjoying RubyConf? Good, me too! Today I am going to talk about unhappy exception handling. But this is my first English speech, so it will be a big challenge for me. But I give it a try.

こんにちは、みなさん。僕の名前は淳一です。日本から来ました。みなさん、RubyConfを楽しんでますか？おお、いいですね。僕も楽しんでます！さて、今日は「アンハッピーな例外処理」についてお話しします。しかし、英語で発表するのは今回が初めてです。なので、これは僕にとって大きなチャレンジになりますが、がんばってやってみます。

Let's begin. Now, I talk about the basic syntax of exception handling in Ruby. Probably, all of you understand the syntax -- begin, rescue and end. Okay?

では本題に入りましょう。まず、Rubyにおける例外処理の基本的な構文についてお話しします。おそらくここにいるみなさんは全員この構文を理解していると思います。beginとrescueとendです。大丈夫ですね？

It is very simple, but some programmers misuse exception handling. They misunderstand "If exception happens, use `rescue`. That's okay." They begin writing `rescue` everywhere -- rescue, rescue, rescue... And they believe "My program is now relialble." Is it okay? --- No!

この構文は非常にシンプルです。しかし、プログラマの中には誤った方法で例外処理を使う人もいます。彼らはこんなふうに誤解しています。「もし例外が起こったら、`rescue`を使えばいい。それで大丈夫。」そして、あちこちに`rescue`を書き始めます。rescue、rescue、rescue・・・。これでいいんですかね？ダメですよね。

But, some years ago...

ですが、何年か前に・・・

I had a trouble at a previous job. I joined a previous company as an in-house software engineer. I became the maintainer of an existing in-house web application. It was a good boy because it had been running perfectly for years. One day, I had an opportunity to talk with one of the users. He showed me his regular operation, and I was watching it. He clicked the save button, then I saw a dialog "System error minus one." "Oh, what? What's this?" He said "We see it very often. So we're clicking the save button again and again, click! click! click!"

私は前職であるトラブルに遭遇しました。私は社内ソフトウェアエンジニアとして前の会社に入社しました。私はとあるWebアプリケーションのメンテナンス担当者になりました。そのシステムはとってもよい子でした。なぜなら何年にもわたって完璧に稼働していたからです。ある日、ユーザーの一人と話をする機会がありました。彼は私に普段の運用方法を見せてくれました。そして私はそれを見ていました。彼は保存ボタンをクリックしました。すると、こんなダイアログが表示されました---"システムエラー: -1" 「ん？何ですかこれは？」彼はこんなふうに答えました。「これねえ、しょっちゅう出てくるんですよ。だから、こうやって繰り返し保存ボタンをクリックするんです。カチカチカチカチカチッ！！」

Oh, really??

げえっ、マジで！？

The code was like this. Actually, it was not Rails. That was ASP.NET in C#, but the basic idea is not different. They are the same. I remember that was an update logic, and it had an unnecessary rescue clause. This is the unhappy exception handling. It just displayed an error code, so it neither notified nor logged. We never noticed even if an error occurred. Unfortunately, the users had a bad procedure, "If you get this error, keep on retry." No! Do not retry, please call us. After the investigation, we found the root cause -- it was dead lock. Dead lock was involved so frequently due to a bad table design. Have you ever seen a table without any primary keys? --- No? Okay.

そのコードはこんなふうになってました。実際にはRailsではなく、C#で書かれたASP.NETでした。ですが、基本的な考え方は変わりません。どちらも同じです。あれはたしか更新ロジックだったと思います。あのロジックには不要なrescue節が入っていました。これが「アンハッピーな例外処理」です。この例外処理は単にエラーコードを表示するだけなので、通知も来ず、ログも残されません。ですから、エラーが起きてもまったく気づけません。不運なことに、ユーザーはこんなイケてない手順書を作っていました。「もしこのエラーが起こったら、再試行を繰り返すこと。」いやいや、再試行しないで！お願いだから僕たちに連絡してください。調査の結果、この問題の根本原因がわかりました。デッドロックです。ひどいテーブル設計のせいでデッドロックが頻発していたのです。みなさんは主キーが全くないテーブルを見たことがありますか？---ない？ですよね。

Anyway, this is the conclusion. What can we learn from this story? First, the misuse of exception handling leads to terrible consequences. Second, what you can do and what you should do or you shouldn't do are different. Third, if you don't have confidence in exception handlings, please do not use `rescue` so casually. Delegate exception handlings to frameworks. For example, Rails can display 500 page or save logs. Please consider asking mentors for help about your code design. Let's do happy exception handling!

というわけで、まとめます。私たちはこの話から何を学べるのでしょうか？まず一つ目。間違った例外処理はとんでもない結果を招きます。二つ目。「できること」と「すべきこと（またはすべきでないこと）」は違います。三つ目。例外処理の書き方に自信がないなら、`resuce`を気軽に使わないでください。例外処理はフレームワークにお任せしてください。たとえば、Railsは500エラーページを表示したり、ログを残したりしてくれます。メンターをつかまえてコードの設計について相談することを検討してください。みなさん、「ハッピーな例外処理」を書きましょう！

Finally, let me introduce myself. My name is Junichi. You can call me Jun. I'm working as a software engineer at a Japanese company called SonicGarden. And I'm mainly developing Rails applications. I have Twitter and GitHub accounts.

最後に、僕の自己紹介をさせてください。僕の名前は淳一です。Junと呼んでもらって構いません。ソニックガーデンという日本の会社でソフトウェアエンジニアとして働いています。主にRailsアプリケーションを開発しています。TwitterとGitHubのアカウントもあります。

I have some personal works. I translated an ebook called Everyday Rails Testing with RSpec. Do you know this book? Great, I translated it.

個人的にやっている仕事もいくつかあります。僕は「Everyday Rails - RSpecによるRailsテスト入門」という電子書籍を翻訳しました。みなさん、この本は知っていますか？すばらしい。この本を翻訳したんです。

And I wrote a book called Introduction to Ruby Programming for Future Professionals last year. The key concept is "Learn Ruby before Rails." Matz kindly wrote the foreword message for this book. I'm looking for an English publisher, so if you know anyone, please introduce him or her to me.

それから「プロを目指す人のためのRuby入門」という本を去年書きました。キーコンセプトは「Railsをやる前に、Rubyを知ろう」です。ありがたいことにMatzさんが「本書の刊行に寄せて」のメッセージを書いてくれました。現在英語版の出版社を募集中です。もし関係者の方をご存じでしたら、その方を僕に紹介してください。

Anyway, that's all. I hope you enjoyed my talk. Thank you very much! See you.

さてさて、これで僕の発表はおしまいです。みなさんに楽しんでもらえたなら幸いです。どうもありがとうございました！またお会いしましょう。

参考: 使えそうな英語の言い回し

今回の発表では以下のような言い回しが含まれています。
こういった言い回しは今回の発表に限らず、他の発表でも使えそうなので参考にしてみてください。

Today I am going to talk about 〜.

今日は〜についてお話しします。

Let's begin.

それでは本題に入ります。/ では始めましょう。

Anyway

というわけで / それはさておき / とにかく

First, 〜. Second, 〜. Finally, 〜.

最初に〜。2番目に〜。最後に〜。

A called B

BというA / 例: a company called SonicGarden（ソニックガーデンという会社）

動画はこちら

今年もRubyConfの全発表はYouTubeにアップされています。
すなわち、僕のLTもアップされているということです！

自分で見返すのは少し恥ずかしいのですが、英語の登壇を考えている方の参考になるかもしれないので紹介しておきます。
僕の発表は00:55:49頃から始まります。

RubyConf 2018 - Lightning Talks

完璧な英語ではありませんが、できるだけ抑揚を付けたり声色を変えたりして、平坦でボソボソしたしゃべり方にならないように心がけたつもりです。いかがでしょうか？

発表の反応

前述の通り、今回の発表は少し笑いを取ろうとしていました（爆笑ではなく、あくまで少しです）。
英語で話してうまく伝わるかどうか不安でしたが、まあまあウケたんじゃないかと思います。

また何人かの現地のエンジニアさんから「面白かったよ」「初めてには見えなかった」といった感想をいただきました。（やった！）

LTの真の目的（？）「プロを目指す人のためのRuby入門」の英語版を出すという野望

今回の発表では、最後に「プロを目指す人のためのRuby入門の英語版を出したいので、誰か関係者を紹介して！」とお願いを入れました。
ダメもとのお願いだったんですが、現地エンジニアさんの中に1人、「知り合いがいるからちょっと聞いてみてあげる」と言ってきてくれた人がいて、ビックリしました。
ただ、その知り合いの方の会社ではIT関係の技術書は取り扱っていなかったみたいで、結局話を進めることはできませんでした。残念〜。（でも話をしてくれたのはありがたい！）

ちなみに、「プロを目指す人のためのRuby入門」は本気で英語版を出したいと思っているので、英語版の著者ページも作っています！

Introduction to Ruby Programming for Future Professionals

まとめ

というわけで、このエントリではRubyConf 2018で初めて英語でLTした話をいろいろ書いてみました。

登壇する前は英語で発表なんて自分にできるのか！？と不安に思っていましたが、実際にやってみると意外となんとかなりました。
もちろん、日本語で発表の準備をするよりも時間はかかりますが、時間さえかければLTでない普通の発表でもなんとかなるんじゃないかという気がしてきました。
（ただし、質疑応答の時間にネイティブの人から早口で質問されたりしたら、ちょっとテンパるかもしれませんが・・・）

みなさんももし、僕と同じように英語で発表する機会がやってきたら、今回のエントリを参考にしてもらえると幸いです😃

あわせて読みたい

RubyConf 2018全体の参加レポートはこちらのエントリにまとめてあります。

「伊藤さんはいったいどんな英語の勉強をしてきたの？」「僕は英語が苦手なんだけど、どんな勉強をしたらいいの？」という方は、こちらのエントリを読んでみてください。

英語っぽい抑揚の付け方（緩急の付け方や声色の高低、強弱など）については、こちらの動画が参考になるかもしれません。
（ジョーク動画として作られていますが、英語の勉強教材としてはなかなか良いですw）

ウィル・スティーヴン 「頭良さそうにTED風プレゼンをする方法」

あと、僕は普段「ジリアン・マイケルズ」のDVDを見ながらトレーニングしているので、発音や抑揚の付け方はこのDVDに出てくるジリアン先生のしゃべり方にも影響を受けています。
別にこのDVDである必要はありませんが、海外の映画やドラマなどを普段から見ておくと、いざというときの登壇や英会話に役立つかもしれません。

ジリアン・マイケルズの30日間集中ダイエット [DVD]

おまけ

登壇裏話👉過去のLTを見てたら5分を超えるLTもあって「あ、ちょっとぐらいオーバーしても大丈夫なんだ」と思ってたら当日はしっかりタイマーとブザーが設置されててビックリ！どうやら今年から厳しくなったとのこと。なので最後は予定より駆け足で自己紹介を終わらせましたwhttps://t.co/vzlV1EKsXf

— Junichi Ito (伊藤淳一) (@jnchito) December 17, 2018

自己紹介を最後に持ってきて正解だった。逆だったら結論まで達しなかったかも〜。

— Junichi Ito (伊藤淳一) (@jnchito) December 17, 2018