先日、世界最大級（多分）の Swift カンファレンス try! Swift で発表してきました（スライドはこちら）。
過去に（まったく別の技術の）勉強会で発表したことはありましたが、
- スピーカー 33 人中 26 人が海外から参加
- 参加者 536 人中 147 人が海外から参加
- 発表および 90 分の Q&A セッションは英→日および日→英の通訳付き
- スピーカー向けの連絡は英語（参加者向けは日英併記）
- 海外勢 & スピーカーだけで行われた International Reception
- 参加費 $350 （スピーカーは当然無料です）
と、何から何まで 勉強会とはまったく異なる未知の体験 でした。個人的には、 初めて英語で発表した（持ち時間 25 分） というのも大きなチャレンジでした。
東京で行われるにも関わらず、参加費がドル建てだったり、このような行動規範が用意されていたりといったところからも、グローバル感が漂っているのがわかると思います。
結果として、 try! Swift は最高の 3 （ + 1 ）日間でした！ こんなに濃密な時間を過ごしたことが過去にあったか、すぐには思いつきません。
僕が体験したことを記録しておきたいということと、今後スピーカーになる人の役に立つかもしれないので、僕の目線で見た try! Swift について書きたいと思います。
すべてのはじまり
遡ること半年前、突然、一通のメンションツイートを受け取りました。
@koher 3/3, 4にNatashaRobotさんたちと海外のスピーカーを招待してSwiftカンファレンスを予定しています。スピーカーをお願いしたいと考えているのですが、ご都合はいかがでしょうか？
— kishikawa katsumi (@k_katsumi) 2015年10月3日
@k_katsumi お声がけありがとうこざいます。是非、お引き受けさせていただきたいと思います。
— koher (@koher) 2015年10月3日
正直、こんな大ごとになるとは夢にも思いませんでした。「海外のスピーカーを招待」とは、一人か二人くらい呼ぶくらいのことかと思って、ちょっと気合の入った勉強会のようなものかと思って気軽に返事しました。
すると @k_katsumi さんから、
ありがとうございます。ではサイトに掲載するためのプロフィール（英語）と写真をいただけますか？
と連絡が来ました。
「おや？もしかして発表も英語なのか？」と思って、確認すると、
日本語か英語はどちらでもいいですが、英語が問題ないのであれば、英語の方がメリットがあると私は思います。
オーディエンスは日本人が多数だと思いますが、スピーカーは海外の方が多数なのでその方に伝わるという意味で。予算によりますが、同日通訳を用意する予定で、英=>日を優先するので日=>英は無理かもしれないということもあります。
とのことでした。英語で発表は大変そうだけど、まだ半年あるから何とでもなるだろうと高をくくっていました。
また、僕はエンジニアコミュニティからほぼ断絶された生活をしていたので @k_katsumi さんのことも存じ上げておらず、どんなカンファレンスなのか少し不安になりました。それについては
まだいろいろ未定ですが、Swift Summit https://www.swiftsummit.com/ のようなカンファレンスを想定していただくと合ってると思います。
と返ってきました。
リンク先を見て、少し焦りました。 @chriseidhof さん等ちらほら知っている有名エンジニアがいたり、チケットが $750 だったり、なんか想像してたのと違うと思いました。
僕は東京に住んでいないので交通費のサポートがあるとうれしいと言うと、交通費もホテル代も出せると思うと、快く返事をいただきました。
2015年、秋
しばらくは連絡もなく、詳細も明らかにならず、一体あの件はどうなったんだろう？、もしかしてなくなったのかな？と思って過ごしていました。
11 月 18 日、ついに try! Swift の開催が発表されました。
try! Swiftカンファレンスの告知を開始しました。今回は特に多数の海外の著名なエンジニアの方がスピーカーとしていらっしゃいます。
— kishikawa katsumi (@k_katsumi) 2015年11月18日
もちろん日本の方の発表もあります。同時通訳も準備する予定ですので皆さん参加してくださいませ。 https://t.co/iYx3qZYVqa
が、初期の頃はスピーカー数人だけが掲載され、僕は掲載されていなかったので、本当に自分が try! Swift のスピーカーなのか確信は持てませんでした。
一応発表内容についてはあれこれ考えていました。この頃に考えていた発表テーマは Optional を中心として Swift の型システムについて話すことでした。
「 Int を Int? に代入できるのは暗黙的型変換に見えて実はサブタイプなんだよ。 Ceylon で Integer? が Integer|Null なのと対応していておもしろいね。」という話から、 Either や Result にまで触れ、「 Int|String が Either<Int, String> のシンタックスシュガーになったら、 Union Type を enum で表せて Swift っぽくておもしろいね。」っていう話や、「 Cat? は Animal? のサブタイプに見えて（ Optional は型パラメータについて共変になっているように見えて）実はこっちは暗黙的型変換なんだよ。」という話をしようと思っていました。発表タイトルは "What a Wonderful World" をもじって "What a Optional World" でした。
今度Swiftについて話すののタイトル思いついた。
— koher (@koher) 2015年11月24日
今振り返ってみると、↑のツイートに @_ishkawa さんが「いいね」してくれているのもおもしろいです。何せこの時、 @_ishkawa さんは僕がスピーカーなことを多分知っていたのです。後に明らかになるのですが @_ishkawa さんは @k_katsumi さんに僕を推薦してくれた一人だったのです。
12月
12 月 2 日、ついに @k_katsumi さんよりブログでアナウンスがあり、僕もスピーカーとして発表されました。これでようやくスピーカーだと（自分の中で）確定して本腰を入れようと思っていた矢先、事件が起こりました。
12 月 3 日、 Swift がオープンソース化されたのです。
一晩でGitHubのスター7000てすごい…。https://t.co/UXHxnqMe4T
— koher (@koher) 2015年12月4日
スター10000超えた…。https://t.co/UXHxnqMe4T
— koher (@koher) 2015年12月4日
2015 年内にオープンソース化するとは発表されていたものの音沙汰ないままだったので、年末ギリギリに発表するか延期のアナウンスだろう思っていたところ、突然オープンソース化されてびっくりしました。
オープンソース化によって、 Swift が生まれて以来僕がよく取り組んでいた、実際に色んなコードで実験して Swift の内部がどうなっているのか探るという手法は完全に陳腐化してしまいました。 Optional と型システムなんて話はコンパイラを覗けば当たり前の話なのでおもしろみがありません。
また、言語仕様に対する提案も swift-evolution で活発に議論されるようになりました。しばらく様子を見ないと発表内容がすでに議論されて棄却済みとなる危険性があり、しばらく様子見をする必要がありました。それまで考えていたことが振り出しに戻ってしまい、何を話そうか悩みました。
おまけに、 try! Swift とは関係ないですが、 1 ヶ月近く前から用意していた Qiita の Advent Calendar のネタも潰されてしまい、急遽コンパイラを改造してみたりしました。
とりあえずしばらく様子見だったので、実作業は年明け以降にすることにして、 12 月中は Qaleidospace を作ることにしました。
12 月中旬に↓の中から "Error Handling Rationale and Proposal" を発見し、少しテーマの路線を変更して、 Optional や Either, Typed throws を軸にエラーハンドリングせばいいんじゃないかと考え始めました。
今まで気付いてなかったけど、↓にこれまで秘密に包まれていた、 Swift の言語仕様がなんでそうなっているのかが書かれている？！https://t.co/8ghmsVMNaD
— koher (@koher) 2015年12月16日
まだこの頃は "Error Handling Rationale and Proposal" を論破して Typed Throws でなければならない理由を述べようと考えていました。
"Error Handling Rationale and Proposal" の英語は難しく、コードによる具体例も少なくて読むのが大変でした。年末年始もスキマ時間を見つけては iPhone で読んでいました。
確か、ジョブズのスピーチのオマージュ（僕はパロディと呼んでいたのですが、参加者の方からオマージュとツイートしていたのを見てそれをいただきました！）でいこうと決めたのも 12 月でした。英語でプレゼンするために英語に慣れておこうと思って、毎日ジョブズのスピーチと Swift Summit の @ayanonagon さんのプレゼンの動画を聞いていたのですが、あるときふと、ジョブズのスピーチのオマージュにしたらおもしろいんじゃないかと思いつきました。それからは、どういう風に三つの話に落とし込むかを考えていました。
1月
年明け早々に Qaleidospace をリリースして、その後は try! Swift に集中することにしていました。何せ、 25 分もの発表を英語で行うだけで大変です。僕の英語力では原稿を作って丸暗記するしかなかったので、早めに原稿を仕上げて練習期間を長めにとる必要がありました。
しかし、 swift-evolution での議論も刻々と変化しており、早く仕上げすぎると内容が陳腐化してしまうリスクがあります。そのあたりのバランスをとるのが難しかったです。
"Error Handling Rationale and Proposal" と swift-evolution を眺めながら反論となるユースケースを考えていたんですが、いくら考えてもなかなかいい例が思いつかないことから、「エラーの種類を網羅的に分岐して処理しなきゃいけないケースなんてほぼないんじゃないの？」という心境に至り、 Untyped Throws に宗旨替えしました（本番で話した、 Marked Propagation が Untyped Throws の欠点を補っていることにもこの辺りで気付きました）。
Swift 2のthrowが型の情報を失ってしまうことに対して、自分なりの腹落ちポイントが見つかった気がする
— ishkawa (@_ishkawa) 2015年11月23日
@_ishkawa 当時納得できなかったけど、僕もようやくその心境に至りました！是非 try! Swift のときにでもお話ししてみたいです。
— koher (@koher) 2016年1月8日
@koher ぜひ！楽しみにしています😉
— ishkawa (@_ishkawa) 2016年1月8日
結局 1 月は Qaleidospace の Twitter 対応等に結構時間をとられたりして、
- 話の流れを練る
- 発表の軸となるコードを書き出す
- 試しに原稿の出だしを英語で書いてみる
くらいで終わってしまいました。
そして 1 月 29 日、衝撃的なメールを受け取りました。
We're excited to have both English -> Japanese and Japanese -> English simultaneous translation for the conference.
To make the best translation experience possible for those attending, we ask that you submit a detailed transcript of your talk by February 15th in the language of your choice (English or Japanese).
2 月 15 日にスライドと原稿を提出って何？メールボックスを漁ると 1 月 2 日にもメールが来ていました。英語だったこともあり、見逃していました・・・。
それから、日本語→英語の翻訳用意できたの？でも、今から日本語にしたらジョブズのスピーチのオマージュとかできないし、そしたら三つの話という構成も意味ないし、全部ひっくり返っちゃうんですけど・・・。
英語でプレゼンをするのは初めてだったので、次の二つの不確定要素がありリスキーでした。
- 25 分もの英語の原稿を本当に覚えて話すことができるのか
- 練習を重ねたとして、本当に 25 分に収まるくらいすらすら話せるようになるのか
とはいえ、今更日本語にすると構想から色々作り直しです。それはそれで 2 月 15 日の原稿提出はきついです。
原稿を覚えるのは、最悪メモを見ることはできるし、メモを見ながら読み上げて 25 分に収まる分量にすれば、最低限の担保はできるだろうと考え、かなり迷いましたが、英語でのプレゼンを続行することを決めました。
ここから時間との戦いが始まりました。
2月上旬
ひたすら原稿を書きまくります。スライドはコードが主になりそうなので、とりあえずスライドは後回しにして原稿を先に書きました。コードは 1 月に大方書いていたので、 Markdown 形式で文章を挿入していきました。そうすれば、コード部分がほぼスライドに対応するのでスライドを作りやすいだろうと思ったのです。これが後で命を救いました。
原稿の執筆は、英語がネックとなって遅々として進みません。今やるべきではないとわかっていながらも細かい表現が気になっていちいち調べてしまいます。これについては、今考えてもやはり一度適当な英語でいいから書き上げて分量を調整してから表現にこだわるべきでした。
本当に 25 分におさまるのか？ということもずっと気になっていました。三つの話の一つが書き終わったころ、原稿を見ながら通し読みすると 10 分近くかかって絶望しました。ここまでは序章のはずなのに・・・。
ようやく少し形になってきた頃、 swift-evolution で衝撃の投稿を見つけます。
FWIW, I’m in favor of typed throws, but only of a single type that conforms to ErrorType. “throws” would be sugar for “throws ErrorType”. The most common case I would imagine people using is “throws SomeEnum”. I’m personally not interested in supporting “throws A,B”.
-- Chris Lattner (2016-01-28)
え？ Chris Lattner が Typed Throws を推してる！？ Untyped Throws 推しの発表なんですけど・・・。正直、勘弁してくれよと思いました。
try! Swift の発表内容に関連した議論が swift-evolution で伸びる度に、発表の内容が陳腐化してしまわないかハラハラする。。。
— koher (@koher) 2016年2月2日
Chris Lattner の案についてよく考えてみたところ、理想の型システムを追求する立場では中途半端な感じだけど、実用的には良さそうに感じました。僕は Java の時代から例外は都度包み直してメソッドごとに適切な意味付けをし直すことの支持者でしたが、 Chris Lattner の提案する方法ではそれを強制することが可能になります。
この話もするしかないと思い、ただでさえ 25 分に収まらないのに一つ話を追加することになりました（そして結局最終的にこの話は 25 分に収まらないので削ることになりました😢）。
2月中旬、スライド＆原稿提出
時間が足りない！
ということで急遽有休を 2 日もねじ込み、なんとか第一校を 2 月 14 日に仕上げました。バイリンガルなエンジニアの友人による英語のチェックも受ける予定でしたが、間に合わなかったので後回しにしました。マイナーチェンジは可能ということだったので、多分提出後でも OK だろうと。スライドは、コード貼り付けまくるだけだし、まあ 1 日あればなんとかなるだろうと思っていました。
そんなとき、ふと眺めていた try! Swift の Slack の #speakers チャネルで、次のような発言を見かけました。
i'm making my presentation in deckset. should i send over the .md file my presentation is created from?
Deckset ってなんだ？ Markdown ファイルを送る？
直感的にこれは良さそうなものだと感じました。調べてみると、 Markdown でカッコいいスライドが作れるアプリ！しかも、僕は原稿を Markdown で書いています。これを使うしかない！それまで Keynote でスライドを作るつもりでいましたが、 Deckset でいくことをほぼ即決しました。
Decksetめちゃくちゃよさそうだ。スライド作り始める直前のこのタイミングで知れてよかった。https://t.co/hWm2tCd4Yj
— koher (@koher) 2016年2月14日
有休をとった 2 月 15 日、スライド作りを始めました。原稿部分に ^ を付加して、ページを --- で区切って、適切にページの見出しを付けていくだけの簡単なお仕事です。
しかし、作り始めてもなかなか終わらない・・・。
自分のスライドに含まれたコードの量をきちんと認識していませんでした。できあがってみるとスライドは 87 枚。完成したのは深夜でした。とてもじゃないけど Keynote だったら間に合わなかったでしょう。
日付は変わってしまいましたが、なんとか深夜にスライドおよび原稿を提出しました。アメリカからの参加者もいるし、西海岸時刻ではまだ 15 日だったはず😅
2月中下旬、原稿修正
原稿を提出したものの、まだ 25 分に収まる分量になっていませんでした。通して計測するといくら時間があっても足りないので、各ページごとに声に出して読んで時間を測り、それ合計して計算していました。原稿提出時にはまだ 3 分ほどオーバーしていたので、 1 割ほど削る必要がありました。
↓は持ち時間との戦いの記録です。
3割くらいは原稿に挿入してるコードとして除外して、1単語平均5文字+空白1文字で6文字で割って、BBCのアナウンサーが1分の100単語話すらしい https://t.co/FEK8JH7FIJ のでそれで割ると41分・・・。持ち時間は25分。ヤバイ。
— koher (@koher) 2016年2月11日
原稿を削ってるんだけど、秒単位の戦いになってる。せめて1分くらいは余裕をもたせたいなぁ・・・。
— koher (@koher) 2016年2月13日
ぐぬぬ・・・、なんとか 27, 8 分まで削ったけどあと数分がキツイ。
— koher (@koher) 2016年2月13日
どれだけ練習しても原稿を見ながら読むのと同じスピードで話すことはできないだろうから、目標は 24 分に収めることでした。
友人の英語チェックを受け、原稿も削りまくってなんとか 25 分に収めました。 24 分は無理でした。このときに、前述の Chris Lattner の提案の話と、どうしても入れたいと思っていた "Keep looking. Don't settle.", "Everything else is secondary." を泣く泣く削らざるを得ませんでした。中盤からオマージュ色が消えてしまうけど、最後の "Stay Typed. Stay Practical." にすべてを任せることにしました。
2月下旬から3月1日
2 月 21 日に原稿を再提出し、そこから本格的に練習を始めました。毎朝準備をしながら、シャワーを浴びながら、車を運転しながらぶつぶつとつぶやいてました。最悪、スライドのスピーカーズノートがあるのでそれを見ればいいのですが、ずっと下を見て話すのも良くないのでできる限り暗記しようと考えていました。 2 月が 29 日までしかないことを恨めしく思いました。
しかし、ここで 2 月 27 〜 29 日の日程で、プライベートの宮崎旅行というイベントが立ちはだかります。諸事情でこの日程は動かせず・・・。
旅行直前の時点で、 First story はほぼ大丈夫、 Second story はまだあやしいけど一通りは覚えていて、 Third story は 20% くらいという感じでした。 27 日の行きの飛行機の中で機内モードにした iPhone を見ながらぶつぶつ。到着してからもホテルで待機時間があったのでぶつぶつ。ここで Second story を一通り覚えられたことで、少し気持ちに余裕が生まれました。
しかし翌日 28 日に、まさかの体調不良でダウン。前の週から喉が痛かったのですが、本格的に風邪っぽく、このタイミングはヤバすぎだろという感じでした。結局 1 日寝込みました。旅行の目的自体は果たせたのでよかったのですが・・・。
29 日にはやや回復して帰宅。この日の夜になんとか Third story の暗記を一通り終えます。翌日は東京に出発しなければなりません。ギリギリです。
3 月 1 日の朝に通しで練習をして、初めてほぼ 25 分で終えることができました。
やっと今、通し練習で5秒オーバーにおさまった。本番の緊張を考慮するとまだキツイけど…。英語で25分はやっぱ辛い。日→英の翻訳もできるとアナウンスされたときにはもう手遅れだったから仕方ない。。。
— koher (@koher) 2016年3月1日
そして昼過ぎ、いよいよ東京へ出発！この日は六本木ヒルズでスピーカーと海外勢だけの International Reception です。
昼ごはんで入った大戸屋の待ち時間でもぶつぶつ言って練習してました。新幹線の中で 5 サイクル回せるはずだったんですが、体調不良もあり眠すぎて断念。結局 1 回くらいしか通せませんでした。
東京に到着！出発がやや遅れたため Reception までの時間がギリギリです。スピーカーズホテルは品川プリンスホテルだったので交通の便は最高です。チェックインしてすぐに六本木に向かいます。
ひさしぶりの東京で、僕の英語力では外国人の中でぼっちになってしまうんじゃないか？とドキドキしながら、電車に揺られたのでした。
（本編に続く）
try! Swift のオーガナイザである @natashatherobot さんが、オーガナイザ視点での try! Swift について書いています。どのようにこの素晴らしいカンファレンスが作られていったのか、僕の駄文よりも興味深く、感動的なのでオススメします。
"Do you believe in magic? The making of try! Swift Conference Tokyo 2016"