5.1さらうどん

@giginetの技術ブログ。ゲーム開発、iOS開発、その他いろいろ

実録・モバイルアプリ領域の技術顧問は何をやっているか

これまで僕は何社かのiOS領域での技術顧問を引き受けてきた。技術顧問というと、Xで怪しいアカウントが「50社歴任!週末副業で楽に稼げる!」などと喧伝していることがあったり、いかがわしいイメージを持たれている方もいるかもしれない。

過去4年以上に渡って技術顧問を務めてきて「一旦何をやっているんだ」と聞かれることは多かったが、ちゃんとまとめていなかったので、この機会に記録しておく。

これまでの技術顧問

これまで僕は3社で技術顧問をしてきた。ちなみに本記事では各社名の敬称は省略している。

  • taskey株式会社(2020/3~2023/7)

  • 株式会社マネーフォワード(2021/3~)

  • 株式会社ユビレジ(2022/8~)

それぞれ、中の人の推薦をいただき声をかけていただいた。ありがたい限り。

各社での動き方と役割

これまでご縁があった組織は、規模もフェーズも三社三様だ。最初に顧問を引き受けたtaskeyは社内の開発者も少人数の組織だったが、マネーフォワードは誰もが知るようなメガベンチャーだ。そうなると、顧問先により、当然求められている動きは変わってくる。

基本仕様として、質問応答、個別の技術相談や、SwiftやiOSの最新情報共有は変わらず行っているが、あとは求められていることや、組織のキャラクター性によって細かくカスタムしている。ちなみに、時間も限られているため、直接のプロダクト開発はお断りしている。概ね、以下のような役割を心がけて動いていた。

taskey株式会社

taskeyはWebtoonやチャット小説アプリpeepを展開するスタートアップだ。僕が顧問を引き受けた2020年当時、事業の拡大に対してエンジニアリソースが足りず、外部の開発力に頼る必要があった。その一方で、コード品質の低下やレビューが間に合わないといった成長痛ともいえる状況になっていた。また、フルタイムで働くメンバーとしてもシニアなエンジニアが少なく、適切な仕様の議論や、壁打ち相手がいないという問題もあった。

そこで、技術顧問として入り、レビュープロセスや自動化フローを整備したりメンバーのメンタリングなどの支援も行った。

一番最初に顧問を務めた組織で、手探りなことも多かったが、結果としてわりと長く続けることができた。CTOやメンバーとも信頼関係を築けていたと思う。典型的なスタートアップの課題を体感でき、大きな組織でしか働いたことがない僕には刺激的だった。

  • コーディングガイドラインの整備や委託先へのレビュー品質の向上
  • 自動化やCI、開発環境整備の支援
  • プロパーのメンバーのメンタリング、ペアプロ

株式会社マネーフォワード

対して、マネーフォワードは既に成熟した組織であり、プロダクトの開発や組織作りに直接僕が関わることはない。そのため、社内メンバーの支援を強く意識して動いており、いわゆるDeveloper Success的な活動も重視した。

転機となったのは、メンバー向けに行ったオープンソースSwiftのワークショップだ。

当時はコロナ禍で、社内メンバーが顔を合わせる機会も少なかったが、ワークショップのおかげでチームビルディングにも貢献できた。この機会が好評だったので、後にシリーズ化され、今でも半年に1度ほどのペースでオフラインワークショップを開催している。特にWWDCのrecapは、ただこちらから話すだけではなく、メンバーにまとめてきてもらう形式にした。

また、毎年入ってくる新卒やジュニアなメンバーにコミュニティとの関わりを持ってもらったり、登壇支援もしている。彼らをタレントとして輩出していくことで、本人のキャリアアップや、組織のプレゼンス向上に一役買えたと思う。

  • 個別の質問応答や設計レビュー、相談
  • 社内勉強会・ワークショップの開催による社内コミュニティ強化の支援
  • メンバーの登壇やキャリアアップの支援

株式会社ユビレジ

ユビレジはiPadのtoB利用をかなり初期から行っている老舗のレジアプリだ。一方で、老舗ゆえに、古いコードベースや技術的負債を抱えてしまっている側面もある。僕は前職でObjective-Cの破壊や、リアーキテクチャに取り組んでおり、その分野に一家言あるため、顧問を務めることになった。

かなり古くからあるアプリゆえ、最新の開発トレンドから少し取り残されてしまっていた部分があった。また、最近は古代言語ObjCに精通しているエンジニアも減っており、採用の問題もあった。

そのため、ユビレジでは古いコードベースの書き換えの促進や、リアーキテクチャの支援を中心に行っている。また、マネーフォワードほどの規模ではないが、ある程度の開発組織があるため、最新情報の知見共有会などもこちらから持ちかけている。

  • 採用やスクリーニングの監修
  • 技術的負債の解消の支援
  • リアーキテクチャや仕様策定のための壁打ち、技術相談

技術顧問としてパフォーマンスを出すために

こうしてまとめてみると、我ながら単なる業務委託に収まらず、わりと顧問っぽいことができていると思っている。ここからは、顧問を続けてく上で心がけていることを紹介する。

話しかけやすい環境を作る

まず、技術顧問のアンチパターンとしてありがちなのが「何かあったら聞いてください」と質問を受け付けるが、誰からもアクションがないケースだろう。結果的に「お願いすることがありませんでした」と言われ、うまく貢献できないことを心配している。

これは当然、いきなり入ってきた顧問に対してどんどん質問ができる人はそう多くない。少なからず遠慮もされていると思う。そのため、まずはメンバーとの関係構築をとても重視している。マネージャーやテックリード級の人と握るだけではなく、各メンバーにも話しかけてもらいやすいようなウェットなコミュニケーションを心がけている。1度話しておくと質問をしてもらいやすいなと感じるので、単純接触効果みたいなものは間違いなくあると思う。

これに近い話は、過去にマネーフォワードのインタビューでも述べている。

こちらからネタを提供し続ける

上記に加え、先方からアクションがない場合も、定期的にこちらから活動の提案をしている。iOS分野では、毎年WWDCや新しいOSが必ず出るため「recapをさせてくれ」というのはとてもやりやすい。自身のキャッチアップにもなり、かつ他の顧問先や外部登壇でも使い回しやすいので都合が良いという事情もある。

また「何か課題ありませんかね?」という雑なオープンクエスチョンも重要ではあるのだが、都度、トレンドに沿った質問もしている。「新しいXcode出たけど対応大丈夫ですか?」とか。

これはある種の「仕事してますアピール」でもあるのだが、何も仕事がないと不安になってしまうので、こちらからグイグイ行ってしまう。

顧問を専業にしない。本業との相乗効果を意識する

顧問は副業としてやることを心がけていて、顧問を専業にするつもりはない。一番の理由はメインの業務に責務を持っていないと、顧問として提供できるネタがなくなってしまうため。本業ではかなり特殊なことをやっているので、そこから得られる知見はとても大きい。

これは、穿った見方をすると、本業の切り売りと思われてしまうかもしれないが、決してそうではない。逆に顧問業から得ることも本業に生かし、シナジーを意識すべきだ。

本業の組織がデカすぎ、かつ業務が専門的すぎるので、どうしても普段やっていないことは一切触れずに手薄になりがちだ。顧問先で必要になり調査することで、それが本業に生きることも多い。

モバイル分野の顧問業をスケールしていくために

技術顧問としての経験は、キャリアの幅を広げる上でとても役に立っているし、何よりいろいろな人に感謝してもらえて嬉しい。できれば少しでもいろんな組織に役立ちたい。

そこで、依頼を増やすためにモバイル分野の技術顧問が必要な顧客のペルソナについて考えている。以下のようなパターンが多いだろう。

  • iOS/Androidのモバイルアプリをリリース・維持していく必要があるが、社内リソースがない
  • 人を増やそうにも、モバイル固有の技術やトレンドに知見がある人がいないので採用やスクリーニング、育成ができない

こうして考えていくと、基本的にiOSのみを主戦場としている僕ができることは結構限られている。

世の中の多くの組織が頭を悩ませる問題は、モバイルエンジニアの採用の難しさと、iOS/Androidへの二重投資だろう。1枠で兼ねられた方が都合が良いので、ネイティブアプリではなくFlutterを採用するのも頷ける。そのため、片方のプラットフォームに偏重したスキルセットは、顧問をやる上で広がりを持ちづらいように感じる。ほとんどの事業はクロスプラットフォームが前提になるので、それぞれに技術顧問を置くのは大変贅沢なことだ。

これまでの僕の顧問先は、分野毎に潤沢に技術顧問を置けるメガベンチャーのマネーフォワードや、主力製品をiOS/iPadOSのみに展開しているユビレジなど、実はかなり珍しい。今後もこういったご縁に恵まれるのが理想だが、スケールしづらいので、今後の展開のために何ができるかは少し考えている。

「二刀流」になるため、限られたリソースをAndroidネイティブやFlutter、Kotlin Multiplatformにステ振りしていくこともできるが、それが正解とも言えない。果たして浅く広い習熟で、実態を伴った顧問業ができるのだろうかという懸念はある。当たり前だが、なんでもは熟達できない。今ぐらい一芸に秀でている方が独自性もあるし。

ぶっちゃけ、顧問業を増やすことは主目的ではないので、そこまで環境適合していく必然性があるかは疑問がある。さしあたり、今後の戦略として、専門家にはなれずとも、AndroidやFlutterのコミュニティにも足を運ぶことはしてもいいのではないかと思っている。

技術顧問のお仕事募集中です!

この記事で「なんか技術顧問って怪しそう」というイメージが払拭できていたら幸い。そしてこの記事を書いたのは振り返りの意味もあるが、当然、僕の技術顧問業の宣伝という側面もある。

技術顧問はどんなにちゃんとやっていても、いずれは終わりが来てしまう。幸い、各社共にある程度長期に良好な関係が築けているが、それであっても顧問先の組織や事業の変化などにより、未来永劫つづけられるものではない。それゆえ、継続性を持たせるために常に新たなポジションを探し続ける必要がある。

顧問の需要自体はあるけれど「仕事を募集中かわからない」「実際ちゃんと働いているのか不明」という点でマッチングに繋がっていなかったこともあるかもしれない。大丈夫です、募集してます

この記事を読んで「怪しくなさそうだから任せても良いな〜」という方がいたら、ぜひ連絡をいただけると嬉しい。

『エンジニアチームの生産性の高め方』絶賛発売中!

この記事に書いた心構えの一部は、先日出版した『エンジニアチームの生産性の高め方』の中でも一部触れている。もしご興味を持ったらぜひお手にとって欲しい。

giginet.hateblo.jp

『エンジニアチームの生産性の高め方』という書籍で開発者生産性について執筆しました

この度、『エンジニアチームの生産性の高め方』(技術評論社)という書籍の共著に携わり、無事に先日発売されました 🎉

雑誌の特集記事などはたまに執筆したけど、ちゃんと流通に乗る書籍を書いたのはなんと10年ぶり。2014年に大学院生のときに350ページ超の単著を執筆して、その時に一生分の執筆パワーを使ってしまったみたい。

giginet.hateblo.jp

いや〜、大変だった。書きながら何度も内容に悩み、安請け合いしたことを後悔したけど、途中で原稿を落とすわけにも行かずに脱稿。なんだかんだで書ききったし、結果的に出版されて喜びも一入。ぜひお手にとっていただければ。

何を書いたの?

僕が担当したのは、第7章の「開発基盤の改善と開発者生産性の向上」*1という章。僕がこれまでのキャリアの中で、開発基盤エンジニアとして働く上で、心がけていたことや、考え方などを盛り込んだ。

また、基盤開発を通して、開発者体験の改善をどのように実行していくか、ステップ毎に紹介している。

一生PDCAを回している

後半は開発者体験の向上の評価のために、よく話題に上がる開発者生産性の評価という点にも言及している。生産性評価指標の既存研究である「SPACEフレームワーク」を用い、モバイル開発領域の開発者体験・生産性向上のための応用に挑戦している。ここでは、よくモバイル領域の生産性のメトリクスとして扱われやすいビルド時間やローカルビルドの失敗率という指標を例に挙げ、どのようにメトリクスを読み解くべきか議論している。

特にモバイルアプリ領域のDevOpsに特化した視点から執筆しつつ、なるべく話を一般化して書いているので、いろんな領域のエンジニアの参考になれば幸い。

豪華な執筆陣

「エンジニアチームの生産性の高め方」という書籍が出版されました

元々、この本は、同僚で同じチームである @mntsh*2 の推薦で筆を執ることになった。(ありがてえ)

他の執筆陣として、元メルカリGroup CTOの@kwakasaさんや、Tably CTOの@yoichiroさん、ナレッジワークCTOの@mayahさんなど、各社のCTOやVPoEを歴任した、とても厳つい著者陣の中に名を連ねることになった。非常に光栄なことです。

非常に下手くそなサインで存在感を出すことができた

正解が見えない中での執筆

こうしてブログ記事を書いたのだから、もう少し販促に繋がることを書くべきなのだろうけど、結果的にどうにも自信がないというのが正直なところ。

本書でも言及しているが、生産性(Developer Productivity)や開発者満足度(Developer Satisfaction)という指標はとりとめのないもので、当然ながら結論を出すことができない。世の中に生産性に関しての議論や研究が溢れているのもその証左だと思う。

前回の書籍はチュートリアル本に近いもので、事実を列挙する側面が大部分なので迷いはなかった。反面、今回は正解が見えない分、執筆している内容の説得力を少しでも出すことに苦心した。書きながらちょっとこれは論拠が弱いだろうと思う部分もあったが、コンテキストの説明や反論に対してのエクスキューズなどを盛り込んでいると一生完成しないので、ある程度は割り切った。その結果、執筆にメチャクチャ時間がかかった*3。非常に大変だったので、また向こう10年は書けないかも。

結局、最後まで悩みながら書いており、あまり殻を破りきれなかった気はする。もうちょっと色を出しても良かったという後悔はある。

月並みだが、執筆を通して言語化できたために、基盤開発や生産性について問われたときに自分なりの答えを持つことができた。というか、売り物にするために強制的に生産性について問答せざるを得ない状況になったというのが正しい。やはり締め切りやプレッシャーは重要。

執筆から解放され、満面の笑みの著者

執筆と並行して、本業でも、本書で触れているSPACEフレームワークの活用や、メトリクスの取得や生産性評価について試行錯誤しているので、また半年後ぐらいにどこかで報告できたらなと思う。

買ってね!!!

ということで、書籍は好評発売中なのでぜひお手にとっていただければ。僕の章はともかく、他の章については自信を持ってオススメなので、安心して買って欲しい。

併せて読みたい

masaytan.com

www.eisbahn.jp

*1:章タイトルの時点で冗長なのでもっと洗練させるべきだった

*2:著書に『読みやすいコードのガイドライン』(技術評論社)など

*3:非常に生産性が低い

韓国のAppleカンファレンス、KWDC24でSwiftのCLIツール開発について話してきた

めっちゃ緊張した

オーガナイザーの @unnnyong の紹介で韓国のAppleカンファレンス KWDC24にプロポーザルを出し、採択されたので参加してきた 🇰🇷

実は国外登壇(物理)は初めてだった。2年ほど前にBitriseが主催のカンファレンスで英語で話したことはあったけど、当時はCOVID下だったこともあり、オンライン開催で、ほとんどフィードバックが得られずに残念だった。今回は満を持しての物理登壇!

何を話したの?

SwiftによるCLIツールの開発手法と、ネタ探し、ツール開発の始め方を網羅的に説明する内容になっている。その他、モバイルDevOpsエンジニアのロールや、実践例、これまでのツール開発の歴史などにも言及している。

なんとなくDevOpsには興味があるけど、どうやってツール開発をすればいいかわからない、とりわけ「何を作って良いかわからない」という疑問についてのアンサーを意識した。結論をまとめると「まずチーム内の課題を解決しよう。またOSSにすることでさらに洗練されるよ」という感じ。

"Creating Intuitive Developer Tool in Swift" というタイトルになっているが、内容とあまりリンクしていない。これは単に要項の提出締め切りが早く、その時点で中身が真っ白だったので、ChatGPTで苦し紛れに出したタイトルだから。本番でタイトルを変えても良かった・・・・・・。

トークの設計と戦略

トーク内容の設計は、中身の質が担保されているのは基本線として、コミュニティ特有の環境について強く意識する必要がある。

当然、聴衆の理解力やコミュニティ全体のレベル感を掴めなければ、適切な目線で話題を絞れないし、そればかりではなくノリ、すなわち技術トレンドやミーム、コミュニティ内の有力なプレイヤーのキャラクター性などに合わせてメタを張っていく必要もある。

日本のiOSコミュニティには最初期から参加していて、もはや勝手知ったるという状況だが、海外登壇の難しい点はこれらの前提情報を得られづらいところだ。今回は、コミュニティオーガナイザにも軽く状況を聞き、以下の戦略にした。

  • 自己紹介やプロダクト、これまでのOSS活動の紹介を厚めにした
    • わざわざ海外に行くのは、プレゼンス向上という目的が大きいので、国内コミュニティ以上に自分を知ってもらうことに専念した
  • iOSツール開発の歴史や、業務での活用例を交えて前提共有をしっかり
    • 韓国ではネイティブアプリ(特にiOS)のDevOpsを専業としているエンジニアは希ということで、ロールについてイメージを持ってもらうことを意識した
  • エモい寄りの話は盛り込みつつも薄めに
    • あまりエモに寄りすぎると、母国語を使わずに細かいニュアンスコントロールをして抽象度の高い話をするのは難しく感じた。結果、単に「コントリビューションして盛り上げていこうぜ」ぐらいに留めた
  • 網羅性を高めて、各トピックは簡単に。浅く広く
    • これは聴衆の適切な知識量が掴めなかったという理由の他に、上記同様、単にlanguage barrierで深い話がしづらいので、単に手法を列挙するだけに留めた

正直、準備の後半は日本語・英語両方のtranscriptの準備に疲れてきたり、締め切りがシビアだったので、最終的にはクォリティアップはあきらめ「完成したらえらい」ぐらいまで妥協している。さらに同時並行で3トラックあるため、裏番組に人が吸われてしまって人が来ない可能性も考慮し、めちゃくちゃ準備に時間をかけてもな、という気持ちもあった。

結果的にあえて網羅的な流れにしているものの、ぶっちゃけ、あまり深い話はできておらず、表面的な内容に終始してしまった。渡航の大きな目的がプレゼンス向上とネットワーキング、プロダクトの宣伝というところも大きかったので、トークとしては及第点かな・・・・・・。

トーク後の反響とAsk the Speaker

心配とは裏腹に、結果的に大きな会場が埋まる程度に盛況だった (めっちゃうれしい😭)

意外と満席近かった

トーク後はAsk the Speakerもあり、ある程度の聴衆が集まってくれた。

参加者に回答する筆者

結果、GitHubで良くアイコンを見ます、と言ってもらえて、思った以上に認知されていることがわかった。ありがたすぎる。

一番印象的だったのは、僕の日頃の発表資料を読み込んでいてくれて、日本語を機械翻訳しながら韓国で展開してくれてる人が来てくれたことだ。先日のiOSDC 2024の発表内容についていろいろディスカッションできた。

fortee.jp

Live Translation(後述)の様子

その開発者も仕事で大規模アプリケーションを扱っているようで、お互い大変ですねといった話ができて良かった。国内カンファレンス向けの発表であっても意外と見られていることがわかったので、英語での発信も今後は意識していきたい。

英語でトークしてみて

国際カンファレンスはやはり言語の壁が厚いが、今回はTranslation Sponsorとして、Flittoというサービスが提供されていた。

Flittoは、AI技術を用いたカンファレンス用のLive Translationサービスで、韓国に拠点を持つ会社らしい。特に韓日の翻訳はかなり完成度が高く、今年の東京ゲームショウでも採用されていたそうだ。

これにより日本語でもトーク可能だったが、わざわざ海外まで行って、英語での登壇経験を積まないとあまり意味がない気がしたので、敢えて英語で喋った。後に翻訳ログを見たところ、ご覧の通りほぼ完璧に認識・翻訳ができていた。

元の英語発表の認識結果

自動翻訳後、綺麗に日本語訳できている

トーク前は発音がとても不安だったが、40分話通せた上に、音声認識も良好だったことから大分自信がついた 💪

KWDCへのフィードバック

今回、参加してみて、カンファレンスについては少し以下のような部分が気になった。

懇親会(パーティー)の設計

パーティーが前日のスピーカーディナーのみだった。アフターパーティーに加え、一般参加者にはランチも提供されなかったため、スピーカー以外と懇親するオフィシャルな時間がなかった。

スピーカー同士は、スピーカーディナーや、後述のツアーのようなオーガナイザ陣からのおもてなしにより密にコミュニケーションを取ることができたが、全体的に聴衆とコミュニケーションを取る機会に乏しく、またトークへのフィードバックも得づらかった。もし一般参加者だったら、ぼっちだったに違いない。

スピーカーディナーはサムギョプサルで盛り上がった

オンラインフォーラムへの誘導の弱さ

また、オンラインフォーラムの整備や誘導も足りていなかった。韓国ではあまりXが普及していない(もしくは買収後に廃れた)ようで、日本のカンファレンスと違い、リアルタイムの情報収集にとても苦戦した。公式のハッシュタグの案内もなかったし、投稿もほとんどなかった。そのため、参加者がフィードバックしたり、発表資料が共有されたり、ということがなかった。

一応参加者用のDiscordもあったが、ほとんどの聴衆がjoinしておらず、運営が周知に使うのみでほぼ機能していなかった。

すでに国内のコミュニティにいる人同士はMastdonやLinkedInなどで交流しているのかもしれないが、外様からはその様子をうかがい知ることができず、物理空間の人の多さとは裏腹に、実際の盛り上がりを感じ取ることができなかった。韓国もそうだし、おそらく日本も同様に、他国から見て言語の壁が高く、ドメスティックな環境に閉じてしまう傾向は強いと思う。

これらから、総じて、聴衆とのコミュニケーションの難しさや、見通しの悪さが気になった。特に知り合いの少ない海外なので尚更。わざわざ海外まで行く理由のほとんどはコミュニケーションのため、これらが改善されるとありがたい。(当然、運営には別途伝えるつもり)

また、日本のコミュニティ(iOSDC)のような、ビール飲みながらLTを聞くというノリも好きなので、こういった部分もどんどん輸出していきたい。KWDCの開催は2回目で、まだまだ洗練されていないところも感じたので、今後の更なる発展に期待。

海外カンファレンスでコミュニケーションを取るために

上述の通り、無策で海外カンファレンスに行っても、ぼっち一直線になる可能性が高い。海外でコミュニケーションを取るためには以下を用意した方が良さそう。

とにかくスピーカーになる

重ね重ね、まずトークをしないと話かけてもらいづらい。それだけではなく、会話の際に英語に自信がなくとも、スピーカーという肩書きがあるだけで、かなり心の支えになるし、相手も敬意を持って聞いてくれる。行きたいカンファレンスにはまずCFPを出すべき。

SNSとプロフィール交換

事前にGitHubで有名になっておいた方が良いのはもちろんとして、それ以外にもSNSのトレンドが国やコミュニティによって違うので対策が必要。Xは日本以外では急速に廃れている印象を受けている。

直近のWWDC渡航でもそうだったが、海外ではやたらとLinkedInのIDを聞かれる。日本ではほとんど普及していないので放置していたが、しっかり整備していった方が良いと感じた。

日本だと外資のオポSPAMが来まくるサービスというイメージしかないが、スライドの共有などもLinkedInのフィード上で行われることが多いようだ。

今回特有かもしれないが、AirDropによる連絡先交換も多用された。日本だとiMessageや連絡先情報は、かなりプライベート性が高いので、交換可能な状態にしていった方が良い。やりとりもかざすだけなのでスマート。

会社の名刺のほかに、アイコンのステッカーを配るとコミュニケーションに便利だった。名刺をもらっても誰かわからないので、SNS IDとアイコンを渡すのが一番効果的だと思う。これは日本でもそう。

また、今回は別途NFCで連絡先が交換できる電子名刺の MEET を作って行ったら、珍しさも手伝い重宝した。オススメ。

覚えてもらえビリティ

これも日本でもそうだが、派手髪なので覚えてもらいやすく有利だった気がする。「アイコンと同じだよ〜」とか言ってアイスブレイクもできて便利。髪を赤くしよう。

ソウル弾丸ツアー 🚅

カンファレンスの翌日は、オーガナイザ陣にソウルツアーに連れて行ってもらった。観光地に行ったり、ピクニックしたり、夜景を見たり。

本当に弾丸ツアーといった感じで、1日盛りだくさんで非常に疲れたが、現地のメンバーのおもてなしを強く感じた 🫶 また、1日みっちり一緒にいたため、とても仲良くなれた。本当に良くしてもらって、感謝の言葉が尽きない。

最終的に意気投合してソウルの繁華街、梨泰院(イテウォン)で2時まで飲んでいた。一時期『梨泰院クラス』にハマっていたので、現地の雰囲気を見に行けて良かった。ハロウィン時期だったのもあり、治安が崩壊していて、現地のメンバーの案内がなければ一人で行くのは厳しかったと思う。

飲酒すると、とりあえず無限に英会話できるようになるので、やはり酒は全てを解決する。

海外カンファレンスでトークしよう!

前述のように、日頃の情報発信やオープンソース活動は意外と見られていて、業界はとても狭いなあと感じた。そして、様々な人から感謝を述べられたことで、その言葉をもらうだけで行った価値はあった。プレゼンスの向上や活動範囲を広めるためにも、海外でのトークは最適なのでぜひ。

この記事で書いた、海外でトークする際の考え方や準備のポイントなどが誰かに役立つと幸いです。