iOSDC Japan 2024 #iosdc にスポンサー企業のブーススタッフとして参加してきたら思わぬ出会いが生まれた

TL;DR

  • iOSDC の2日前に弊社マネーフォワードオフィスで前々夜祭としてiOS Engineer Meetup in Money Forward を開催したよ
  • iOSDC Japan 2024にDay0からDay2まで参加したよ
  • Day1の夜に弊社エンジニアがコミュ障ムーブを発動させたので、Pixiv さんと STORES さんを誘ってBig Boy Dining に夜ご飯食べにいったよ @mhidaka や @kiko_tw 、 @jollyjoester など懐かしいメンツだけじゃなく 10年越しくらいにリアルはじめましてをした @konifar と遭遇できたよ

ノローグじみたなにか

昨年は @achamixx がiOSDC を担当、DroidKaigiをぼくが担当していたんだけど今年はあちゃさんが育休(めでたい!)に入られたので途中から引き継ぎをしてブース展示の担当として参加してました。 毎度のことながらブーススタッフとしての参加なのでセッションは聞けないんだけど、その分エンジニアがセッション見に行って楽しんでくれてそうだったのでまあいいかな。

前々夜祭について

Go Conference のときに前夜祭をやったら結構参加した人や周りの評価がよくて、じゃあこれiOSDCでもやろうぜ!と提案して開催したわけだけど、さすがに安直すぎたのかあまり参加人数が伸びずに苦戦してしまった。

moneyforward.connpass.com

意図としては「どうせiOSDCに参加するために前日とかに東京来てるだろ?だったら一緒に勉強会で知り合い増やしてもっとiOSDCを楽しもうぜ!」くらいの気持ちでした。 ……が登壇者も参加者も集めきれず惨敗。

イベントで発表した中身とかは結構面白かったので単純にもったいなかったですね。 企画の意図は悪くなかったと思うので次回はもっと少人数に絞って開催するとか改善したいと思います。

iOSDC Japan 2024について

多分みんなブログをいっぱい書いてると思うのでさらっと書いておく。 今年は本当に多くの人にブースに立ち寄ってもらい、弊社のエンジニアと交流してもらえたので大成功だったなと思ってます。 特に8月入社のフランクさん(フランス人)がブースに来た人に「ブースの企画を案内をする練習に付き合ってもらえますか?」といったところ皆さん快く引き受けてくださってめちゃくちゃ暖かいコミュニティだな!と改めて実感しました。

今回は前述した通り、Day0の2日前から東京入りをしていたのでかなりの長期滞在になりました。

ホテルはここにしたんだけどAgodaで予約したことでインボイス制度の「適格請求書事業者番号」が発行されずチェックアウト時にちょっとトラブルになったり(ホテル側は領収書を発行できない、Agodaは適格請求書事業者番号を持っていない)、Day1の夜に洗濯物を乾燥機に入れて終了時間まで部屋に戻っていたらエレベーターが休止(どうやら機器トラブルっぽい)になり、7階から降りて洗濯物を回収して上がるという災難に遭遇したり……。 ちなみに同日お隣のブース、Forkwellさんのおみくじで凶を引き、「終業後に注意」みたいな警告を受けてましたがバッチリフラグ回収してました。すごいね。

www.hotel-livemax.com

まあ他にもちょっとこのホテルは接客時にあまりいい気持ちにならないことが多かったので来年は違うところに泊まろうかなと思っている。 安かったけど正直1000〜2000円で寝泊まりするだけのホテルで気分が害されるって相当だなという気持ちがある。

友人や知り合いと同窓会する

技術広報なんて仕事をしてるとまあ毎年いろんな人と交流するんだけどとはいえ、今年のiOSDCでは思わぬ人たちと遭遇することになってビックリした。

10年前くらいから一方的にブログ購読をしている konifar さんがブースに立ち寄ってくれたり(1度目はたまたま離席しててTwitterで業務連絡で呼びつけてました、ごめんね…… id:konifar )実はリアルでは「はじめまして」だったので挨拶をしたりしてました。 なんかオフ会みたいなだって感想を持ってしまったがまああながち間違いではない。

あとDroidKaigi や 技術書典を運営しているmhidaka( id:hdk_embedded )と談笑していた kiko さんと遭遇したり。 kikoさんはぼくがマネーフォワードで技術広報を始めた最初の年、1人だと誰に何を相談していいかわからんのでアドバイザーになってもらいたい!とラブコールをして短い期間だったけど一緒にマネーフォワードの情報発信を支えてくれた人。 お子さんが生まれたということは知ってたんだけどまさかiOSDCで遭遇するとは思わなかった。思わず記念撮影をさせてもらったがなんとも言えない感慨のようなものがある。

Day1の夜に「オフィシャルパーティーあるけど人がいっぱいであまり落ち着いて喋れないんだよな〜」という弊社エンジニアのぼやき?を聞いて「そこら辺にいるpixivさんやSTORESさんのエンジニアを誘ってみれば?」と提案したんだけど「いや知り合いがいないので……」とコミュ障ムーブをしたので「んじゃあちょっくら聞いてみるわ!」とクッソ雑コミュニケーションでpixivさん2名、STORESさん6名、弊社マネーフォワード3名の突発飲み会?を開催しました。

最終的にまあまあ盛り上がっていたので楽しんでくれてそうだったなーというお気持ちです、いい話し。 クソ雑コミュニケーションに付き合ってくれたpixivさんとSTORESさんに感謝。

今回は6泊7日だったんだけど

  • 20日(火) 前々夜祭
  • 21日(水) 月次開催している社内イベント
  • 22日(木) iOSDC Japan 2024 Day0
  • 23日(金) iOSDC Japan 2024 Day1
  • 24日(土) iOSDC Japan 2024 Day0
  • 25日(日) Helpfeel Tech Conf 2024
  • 26日(月) iOSDC Japan 2024のお片付け(仕事)

といった感じのハードモードな1週間だった。毎日なにかしらのイベントを開催したり、カンファレンスに関わっていたり、それと並行して直近で開催されるイベントやカンファレンスの問い合わせ、自社カンファレンスの集客などなどを実施するという感じでした。

久しぶりに頭は一つで体は3つくらい欲しいって切実に思ったわ……。

ともあれ、次のカンファレンスはYANSで大阪開催なのでだいぶマシ。出張がない、夜に懇親会がない(と思ってるがはたして……)とだいぶ疲労が軽減されますね。

カンファレンス、楽しい面もあるけど体力的にはしんどい面もあり、楽しいだけじゃないね!ってお気持ちです。 あと、欧州サッカーが開幕したのでぼくの睡眠時間が死んでるというのもある。

ひとまず今年の難所であるiOSDCをなんとかやり遂げられたので一息つけました。 残り、YANSとDroidKaigiとデブサミ関西と自社カンファレンスであるMoney Forward Tech Dayが終われば遅めの夏休みを取れるのでゆっくりしたいな……。 温泉とかいって何もしない時間を満喫してー。

平日の夜に #kyotorb をやって「ポートフォリオは作るものではなく育てるもの」だと思った、そんなお盆の一幕

TL;DR

かなり久しぶりに Kyoto.rb を平日夜にはてなさんのオフィスを借りて開催した。 初参加してくれた人と懇親会で話していたら「もしかするとポートフォリオはこうあるべきなのかもしれない」と思ったのでメモしておく。

イベントページはこちら。

kyotorb.connpass.com

開催時に話していた内容のメモはこちら。

scrapbox.io

前置き

前述したように久しぶりに平日夜にKyoto.rbをはてなさんのオフィスを借りて開催した。 ぼくはオフィスを出る時間が遅くなってしまって遅刻をしたりとトラブルもあったんだけどそこに初参加してくれた人と交流を通して「これってこうかもしれない」と思った点を書いていく。

思いつきを書きなぐっているのでもしかしたらあとから清書するかもしれないが、一旦ラフな状態で書かれていると思って欲しい。

背景

初参加した2人はそれぞれ別々の背景で参加をしてくれた。 共通点としてはどちらも現在プログラミングを学習中であること、就活や転職で提出できるポートフォリトや個人開発を行っていることが挙げられる。

懇親会の席で「普段ポートフォリオをどのように評価しているか?」という話題になった。 正直あまり彼ら、彼女らにとって「改善のためのフィードバック」になるような意見が言えたかどうかはわからないんだけどふとイベントが終わって家に帰ってお風呂に入っているときに「なにを作るか?ばかりを話してしまったけど、実は大事なのってどう育てていくか?ではなかろうか?」と思ったので思いつきが揮発する前にメモを取っている。

考えていたこと

まずポートフォリオがあるといい?に関しては正直どうでもいいかなと思ってる。 コードがあって、自信の課題解決力が提示できるならポートフォリオのような「見せるためのもの」でなくてもいいかなとぼくは思っている。 コードはないが普段から何かを調べたことをブログやドキュメントツールに残している、あるいは書いたコードを日常的にパブリッシュしている……などでも問題はないと思う。

飲みの席でも話したけど重要なのは「課題を解決するコミット力、継続的に課題と向き合う継続力」のようなものが重要でそれを測る指標の1つが昨今だとわかりやすくポートフォリオになっているのかなと思う。

実際にポートフォリオがこれらの埋もれていて、目立たない能力の発露になっているのなら別によいのだが多くの場合、オンラインスクールやなにかの学習サイトから「学んだ通りに作る」ことがゴールになっていて、それこそがギャップを生み出しているのではないか?と思ったからだ。

通常、業務でWebサービスを新規開発するよりも、サービス開発を持続・継続することのほうが多いように思う。 これはぼくがそうだっただけなので違う世界、業界、会社組織もあると思うが一旦この前提で進める。

であるならば、ポートフォリはこの持続・継続して開発できる能力が表現されていてほしいのではないか? id:onk さんがいう「開発をしているときの泥臭い話しがみたい」というのはまさにこの部分を表現しているような気がする。

そうすると面接や面談のときに「ポートフォリオを作ってきました!」と言われても、あまり心に刺さらないのは「開発することがゴールになっている」ということがあるからではないだろうか。 もし、そうであるならばポートフォリオが表現するべきは「どのように育ててきたのか?」の部分なのではないか?と考えた。

何かを完成しきる能力、これはとても大事だと思う。 それと同じくらい、場合によってはそれ以上に持続し続けることが大事になることもある。

転職や就活のようなケースでどちらをより重視するかは会社によると思う。 だがしかし、ぼくはなにかを作ることはスタートであり、そこからどう悪戦苦闘し、どのように試行錯誤してきたのか、そのログがみたい。

ぼくは戦記ものの小説が好きなのだけど、これはつまり歴史上のイベントが起こったことそのものよりもその裏でどのように人々が暗躍し、考え、行動してきたのか……そういったストーリーにより惹かれるからではないか?とふと思った。

転職や就活の場はある意味でアピールする場だ。 そう考えるとただポートフォリオを作ってきたというのはアピールになっていない、あるいはアピールする場に立っているだけなのかもしれない。 あるいはポートフォリオを作ったのは舞台に立つためのオーディションに受かっただけなのかもしれない。 実際に評価されるのは舞台に立った後、どのように演技をしたか?であり、これが「育てるもの」と表現した部分なのだとしたら評価されると期待するポイントがズレてしまっていることになる。

ぼくは最近エンジニアの面接などをしているわけではないので完全に予想や過去の経験から推測して話している。 なのでこのような考えは間違っているかもしれないし、あるいは真実の一端をかすめているのかもしれない。

ともあれ、飲みの席では「ユニークであること」ばかりを強調してしまった気がするが実際に重要なのは目立つことそのものではなく、あなたの「ポートフォリオの育て方」をどれだけ丁寧に、どれだけ熱意をロスなく伝えることができるか?なのかも……と思った。

いま、思いつきながら書いているので重複や一部自己否定が入っているかもしれないが、基本的に「どう育てたか?」に関するその裏側こそが面接や面談では重要で、結果としてできたものそのものの価値は実はあまり興味がないのかもしれない。 どう育てるか?は個人差がでると思う。 インタラクティブな操作が可能である、アクセシビリティがよい、とにかく描画が爆速、どこにでも展開できる、サイトのサイズがめちゃくちゃ少ない……などなど。 わかりやすい例だとログイン機能をパスキー対応するみたいな機能特化だろう。

そういったポートフォリオにこだわりをどう作るか、なぜそこにこだわりをもたせたいと考えたのか。 ぼくは面談をするならそういった背景やそこで起こった過程の苦悩や課題への向き合い方が知りたい。

こういうのもある種のストーリーテリングなのかもしれない。

あと帰っている最中にふとメモの魔力の最後の付録に書かれているチェックリストを共有したほうがお二人には有用なアドバイスだったかも……と思った。 いまだと電子書籍で買ったり、メルカリや’中古書店で安く買えると思う。 もしかすると図書館で貸出しているかもしれないので、そちらで借りてみてもいいかもしれない。

明日は大阪オフィスにいく予定でいつもより早く起きないといけないのでそろそろ寝る。 次回のKyoto.rbの開催日はまだ決まってないけど多分9月の最終週の土日のどちらかになるんじゃないかなー。

地方から情報を発信し続ける意義と意味

TL;DR

Kyoto TechtalkやKansai.go、Go Conference mini、OSS Gate、技術書典などなどここ1年ほぼいろいろと試したり失敗したりしながら発信をし続けてきたな〜と思ったのと、最近BuildersConが復活したりさまざまなカンファレンスが新たな産声やリブートをしてるんだけどみんな東京じゃん!地方もやっていこうず!!!という思いからこの記事を書いている。

1年くらい前に飲み屋で id:onkid:pinzolo と話したこと

当時はコロナ禍が収まってようやくオフラインでのイベントとかできるようになったタイミングだったんだけどあまり参加者が集まらないという悩みを抱えてました。

kyotorb.doorkeeper.jp

なんでやったか?についてははてなのonkさんが言った「企業が元気じゃないのにコミュニティが元気なわけがない。コミュニティが元気になるにはまず企業から!関西のエンジニアや技術を活性化させるにはまず関西にある企業みんなのチカラを束ねるのが大事!」というのが全て(実際にはもっと雑な発言で、記憶を掘り起こして綺麗なonk語録として書いています。訂正あったらあとで教えてくれ)

で、その時話してた仮説が以下です。飲みながら話してたので完全に妄想や各々がみえてる観点のみで話してるので客観性とか0です。 でも今見返してもまあまあいい線いってるんじゃないかと思います。

  • Ruby/Rails の若いエンジニアの関心が薄れた
  • 興味を持ってくれる熱意あるエンジニアが東京や地元に引っ越してしまった
  • 関西のWeb系企業の元気がないことがコミュニティ活動にも影響している
  • KyotoLTみたいな特定の技術によらない勉強会がもっと必要
  • 地方で単一言語のコミュニティ活動をするためのパイが少ない

kyotolt.connpass.com

当時Kyoto.rbとかを開催してもコロナ禍によってタッチポイントがありとあらゆるところから消失してしまって、新規参入する人がいなくなってしまった。 フルリモートワークをされる方やコロナ禍を契機に関西に帰ってきた人とかもいたのにコミュニティの元気は戻らなかった……。 戻らなかったと言うか徐々に先細っていっていた。

みたいな話をして「ここにいるメンバーははてな、LINE KYOTO(当時)、マネーフォワードで知名度ある会社ばかりじゃん。目的は技術を楽しむイベントで共催してお互いにとってWin-Winになるイベント企画したらいけるんじゃね!1社10名なら集まりそうだしなガハハ!」みたいなことを発言してました。

このときは「まあ半年後くらいにやれるといいよねー」くらいに思ってたんですがそうは問屋がおろさない。 まあこの話は一旦さておき。

なぜ地方で企業が発信する必要があるか?

正直なところ、東京は企業の数が多いし 馬鹿みたいに人が多いので 放って置いても勝手に活きのいい新規参入者が入ってくる。あるいは新しいコミュニティが台頭する。

ところが地方の場合、コミュニティが死滅してしまうと次に立ち上がるためのパワーがかなり必要になってしまう。 車も停止状態から動き出すまでが一番パワーが必要、これはコミュニティや勉強会も一緒。最初の一歩が億劫なのよ、動き出してしまえばあとは惰性を利用できる。

コミュニティに元気がないと企業のイベントなどに参加する人も減ってしまう、企業のイベントに人が来ないと企業はイベントをするメリットがないので差し控える。 企業がイベントを差し控えると採用のための認知度拡大ができず、地方から撤退してしまう。 特に地方拠点がある会社はこのあたりの傾向が顕著に出るだろうと思う。

究極的にいうならば京都(もしくは関西全体)の企業の元気がないと、仮にぼくがマネーフォワードを辞めることになっても就職先がないことになってしまう。 もちろんフルリモートワークができる企業もあるとは思う。ただぼくは地域に根ざさない人にはなりたくないと思っていた。 一昔前に発生した「外こもり」みたいなただそこにいるだけの人は嫌だな〜って感じで考えていて、フルリモートが出来ても住んでいる地域にコミットがしたいなと思ってました。

ただ、会社がフルリモートOKだとオフィスのイベントスペースを会場として借りることもできないし、採用の意味でもなんだか実態がよくわからない会社に見えてしまう面があると思う。 それはいい面もあるけど悪い面もある。結局どういう会社なの?とかどういうことしてるの?の腹落ちをするには体験が重要な要素を担ってるとぼくは思ってるし、感じている。 なのでそうはなりたくないなと思っていた。フルリモートであってもローカルコミュニティに対するコントリビューションが行える状態であってほしいと考えていた。 オールドタイプな考え方かもしれんけど、まあぼくはそう思うってだけなので、じゃあ自分が期待する世界になるようにできることをやりますかねってくらいの軽い気持ちで始めました。 駄目でもやり直すか、やめればいいだけなので。

  • 企業が元気にならないとコミュニティやそこで働く人の選択肢が狭まる。選択肢が狭まるとみんな東京にいってしまう。
  • 京都は特に学生が多い特徴を持つ。企業も大学も自治体も新規参入がないところから死んでいくのでこれは意識的に取り組む必要がある。
  • ぼくは京都が好きで、京都で働き続けたい。なので自分の場所を守るため、維持するためにもこれらの取り組みが大事だと思っている。

みたいなことを考えてました。

LINE KYOTO のDevRel @masayuki5160 に捕まるの巻

上記のようなことを考えつつ、とはいえみんな忙しいし「そのうちやるぞ〜」くらいに考えていた1週間後くらいにLINE KYOTOでDevRel 兼 モバイルエンジニアとして働いている田中さんから「 弊社の@pinzoloさんからこういうことを考えてるとお聞きしたんですがやりませんか?」というお問い合わせをもらい、飲み屋で話した2週間後にキックオフMTGを開催してました。

いま確認したらイベントを開催したのが3月31日、キックオフMTGは4月11日。実質5営業日くらいでキックオフMTGまでの流れができてた。 気持ち的には↓にある画像「その着せ替え人形は恋をする」の五条くんの心境です。

ともあれ、以下のような点を3社で話し合いました。

  • なんのためにやるか
  • どういう点を重視するか
  • 開催するならいつ頃がいいか
  • どれくらいの周期で開催するか

Kyoto TechtalkやKMC、Go Conference miniなどの地方でイベントを起こす

正直、座学だけならオンラインイベントで十分だと思う。反面、それだけでは満足できないことも増えてきたなと感じています。 学習の5段階モデルというのがあります。

この画像は一般社団法人 日本NLP能力開発協会 公式ブログより引用させてもらいました。

NLP用語集】学習の五段階より引用

nlp-japan.net

オンラインイベントや座学で得られるレベルはここでいう「2. 知ってはいるができない(有意識・無能力)」だと思っていて、体験し自身がわからないところがわかるようになるまで苦心することで「3. 知っている・意識したときはできる(有意識・有能力)」以上になるのだと思います。

なにの書籍か忘れてしまったのですが、「納得は経験から生まれる」という言葉があり、これは学習モデルに置いても同じではないかなと感じています。 納得を深い理解、もしくは実践能力に置き換えても個人的に違和感なく受け入れられるなと思っています。 たまに経験しなくても一足飛びで有能力にジャンプできる人がいますが、そういう方はこれまでに似た経験や体験をこの概念に結びつけることができてるだけじゃないかなと思ってます。

なので、体験できる場としてのオフラインイベントの重要性は今後ますます加速するんじゃないかと思います。 LLMの登場でレベル2程度の「有意識・無能力」は機械がそれらしいことをアウトプットしてくれる世の中になりました。 だとすると今後レベル3以上の価値が比例して高まるはずで、そうなったときにオンラインイベントだけでそれが補完できるんだろうか?という疑問があります。

自分たち以外のデータからみるコミュニティの実態

go.dev

先日公開されたGoのサーベイに興味深い一文が紹介されていました。

In the last year, almost a third of respondents (32%) said they participated in the Go developer community either online or at in-person events. More experienced Go developers were more likely to have participated in a community event and were more satisfied with community events overall. Although we can’t draw causal conclusions from this data, we did see a positive correlation between community satisfaction and overall satisfaction with Go. It could be that participating in the Go community increases satisfaction through increased social interaction or technical support. In general, we also found that respondents with less experience were less likely to have participated in events in the last year. This may mean they haven’t discovered events or found opportunities yet to be involved.
過去 1 年間に、回答者のほぼ 3 分の 1 (32%) が、オンラインまたは直接参加するイベントで Go 開発者コミュニティに参加したと答えました。経験豊富な Go 開発者ほど、コミュニティ イベントに参加したことがあり、コミュニティ イベント全体に満足している傾向がありました。このデータから因果関係のある結論を導き出すことはできませんが、コミュニティの満足度と Go の全体的な満足度の間には正の相関関係が見られました。Goコミュニティに参加することで、社交的な交流や技術的なサポートが増え、満足度が高まる可能性があります。一般的に、経験の浅い回答者ほど、過去1年間にイベントに参加したことがないことがわかりました。これは、まだイベントを発見していなかったり、参加する機会を見つけていなかったりすることを意味しているのかもしれません。(Translated by DeepL)

気になったのはこの2点。

  • 経験豊富な Go 開発者ほど、コミュニティ イベントに参加したことがあり、コミュニティ イベント全体に満足している傾向がありました。
  • 一般的に、経験の浅い回答者ほど、過去1年間にイベントに参加したことがないことがわかりました。

この2点はまさしく我々が危惧したことの証左でもあります。

そして仮説として「新規参入者を企業からコミュニティへ」という取り組みを開始した理由は「これは、まだイベントを発見していなかったり、参加する機会を見つけていなかったりすることを意味しているのかもしれません。」と書かれていた内容と酷似しています。

「知らないイベントには参加できない」し、「知らない人ばかりのイベントは参加しにくい」でしょう。 これらの仮説があっているかどうかはさておき、多くの人は言語やコミュニティではなく企業からコミュニティを知るのではないか?という仮説を我々は立てていました。

結果企業からコミュニティへの人材流動性が生まれ、現在お酒を飲みながら話していた「京都のテック企業を盛り上げて、コミュニティも盛り上げていく循環を作るぞ!」と言っていたことは規模が小さいながらも成功したと言えます。 はてな、LINE KYOTO、マネーフォワードのオリジナル3(元ネタはガンソードオリジナルセブン)から始まり、いまはHelpfeelさんやfreeeさんのような企業、スタートアップやベンチャーのような企業と幅広い企業が協賛してくれています。 最近もSansanやエムスリーの方が参加してくれたり、会社としてはまだ協力できないが……といって個人で協力してくれる方も増えました。

エンジニアの「楽しい」をもっと大きくしていくと、どこかでまた新しい勢力が生まれます。 そういった新しい変化がそこで住む人の学びというベネフィットになるといいなーと思ってるので、これからも仮にぼくがマネーフォワードを辞めたとしても協力していきたいと思っています。

東京と地方では生存戦略が違うよって話

当たり前なんですが、面倒くさいことってやりたくないじゃないですか。 コミュニティ活動って一度やめてしまうと「面倒くさいこと」になりがちで、そうすると学びたいと思う人や面白い話ができる人のキャッチアップするコストが高くなっちゃうと思うんですよね。 それって個人的な損だと思ってて、東京の事例って結局東京だけの事例なんですよ。会社がいっぱい近くにあって、人もいて、勉強会が毎夜開催されている……。 そんな地方都市どこにもないので、我々にそのまま当てはめるってことはできないんですよね。

じゃあどうするか?って話なんですが、東京は数が多いので薄く広くの戦略をしても面白いトークが聞けるけど、地方都市は面白いトークを持っている人を見つける必要があるんですね。 なので、「面白いトークを発表できる場があるぞ!」と宣伝することで面白い話の種を持っている人が遊びに来てくれる、そういうところからチャレンジできるといいかなって思ってます。 イメージとしてはDevOpsライフサイクルの「デプロイ」がイベントという場、「ディスカバリー」が参加した人同士の交流とか刺激かなって思ってます。 いいもん作ったら売れるは幻想なのよ、知らないものを人は買わないので。

DevOps とは何か? | Atlassian より引用

www.atlassian.com

企画した側は「面白いトークが聞けて最高!」ってなればOKだし、参加した人は「あの人の話面白かったな、もっと話してみたい」って思ってくれたら十分ですよね。 登壇した人は「面白い話が出来た!盛り上がったしよかった〜」となったら最高なのでまあそういう体験を小さく小さく積み重ねていきたいなっておもてます。

まとめ

取り止めなく書いたんですが、基本的にぼくは「エンジニアが楽しめる環境を作りたい」と考えています。 そのためには「無理なく継続できる活動をする」ことが一番大事だと思います。 仮にぼくやonkさん、pinzoloさんがいなくなってもKyoto Tech Talkは継続できるだろうなーと思うし、そうあってほしいです。 そしてKyoto Tech Talkのような技術ならなんでもありなイベントがある一方、もっと深い話が聞きたい!と考えている人がKyoto.rbやKyoto.go、Kyoto.jsのようなコミュニティに遊びに来てくれると嬉しいですね。

今月25日に開催する第5回目となる【オフライン開催】Kyoto Tech Talk #5ではついに念願の学生登壇枠を用意できました! 我々はもっと学生の トチ狂った おもしろ発表が聞きたいのだ!と思ってたので感無量です。

lycorptech-jp.connpass.com

今回の会場はLINEヤフーさんのご厚意で大きな会場での開催となりました。 最初「60名……?2倍のキャパシティを埋めることができるのか???」と思ってましたが、実際には杞憂でしたね。 最近はフルリモートな会社に務めて、地方で働く方がイベントに参加するなどコロナ禍前では考えられない所属企業の方の参加も増えてきました。 最近だと海外から来る人もまれですがいて、無茶苦茶な英語でコミュニケーションして相手を困らせてます。英語頑張ろう……。

ともあれ、こういった交流が新たな刺激になったり、地域全体の活性化につながっていくと嬉しいなーって思ってます。 先日、運営として参加していたGo Conference 2024でも「金沢でGoのコミュニティがしたい!」という方や「福岡でGo Conference miniがしたい!」という勢いのある方とお会いすることができました。 (Fukuoka.goのメンバーに相談する前に「宣言したらやらないといけない雰囲気になるので宣言しちゃえば?」と煽ってしまいました、Fukuoka.goの皆さんごめんなさい……。でもGo Con miniを福岡でやるなら協力は惜しまないです。スタッフもやるよ!)

KaigiEffectがさまざまなところで生まれているな〜と感じたよい一幕なので、この火を絶やすことなくドンドン加速していきたいです。 そうじゃねえんだよ、俺たちはまったりやっていきたいんだよ…というコミュニティもあると思います。 そういう立場やスタンス、考え方の違うコミュニティがたくさんあることで地方でも取れる選択肢が増やしていきたいですね。

そのためにぼくやマネーフォワードができることがあれば微力ながらご協力したいと思ってるので相談してくれればと思います。 できないこともあるので、そのときはごめんね!

直近だとKyoto Tech TalkだけじゃなくてKyoto.jsやKyoto.goもイベントあるんで少しでも興味があったら参加してみてね!

kyotojs.connpass.com

kyotogo.connpass.com

実績紹介(一部紹介)

hatena.connpass.com

kyotogo.connpass.com

kyotogo.connpass.com

kyotogo.connpass.com

kyotogo.connpass.com

kyotorb.connpass.com

[余談]意義と意味とは

辞書的な意味では以下。

意義(いぎ)とは、物事の存在・実行などにおける価値や重要性。

www.weblio.jp

意味(いみ)とは、言葉や記号、行動などが持つ内容や価値を示す概念である。これは、人間が情報を伝達し、理解し、解釈するための基本的な要素である。

www.weblio.jp

GopherDay Taiwan 2024で初海外カンファレンス参加&初海外カンファレンス登壇のダブルArchivementしてきました

TL;DR

  • GopherDay Taiwan 2024にCfPを出して登壇者として参加しました
  • 海外カンファレンス初参加&初登壇だったけどGOT KOTONAKIした
  • ちょっとしたトラブルはあったが台湾はとても良かったのでまた観光でいきたい

謝辞

まず最初に、この海外カンファレンスに応募し、それを支えてくれたマネーフォワードという会社に感謝を述べたいと思います。 昨今、円安の影響でとても渡航費が高くなってしまっているにも関わらず、費用負担をしていただき大変ありがたかったです。 この場を借りて謝辞を述べさせていただきます。

また、海外渡航に際し、さまざまな手続きが半端な状態になってしまい、結果関係各所にご迷惑をおかけしてしまいました。 海外カンファレンスは国内カンファレンスとは違い、治安や費用さまざまな面の考慮が必要ですし、協議や調整が必要である点に考えが至ってませんでした。 大変申し訳ありません。 経費を承認していただいた上司と経理部の皆さんにご迷惑をおかけしてしましました。 猛省し、次回がないようにしたいと思います。

また、資料作成の協力やレビュー、推敲をおこなってくれた同僚のCadenとTaichiさんにも改めて感謝を述べたいと思います。 ギリギリになってお願いしてごめんね……。

応募しようと考えた理由

応募をしようと思った理由はいくつかあるんですが、

  • tenntennさんから「CfPを出さないか?」と相談されたこと
  • 当時「最近自分はなにか挑戦できているだろうか?」と悩みを抱えていたこと
  • 普段楽しみに見ている「カルチョ2020」という番組で「チャレンジ&トライをしてほしい」という言葉に笑いとともに「失敗してもいいからトライしてみよう!」と前向きなエネルギーをもらったこと

上記3つが大きな要因かなと思います。 ↓の動画に「お便りコーナー」があるのですが登壇が決まってすぐにお便りを書かせてもらったところ、翌週の配信で取り上げていただきました。 まさか動画内で取り上げていただけるとは思っていなかったので、本当にびっくりしました。

GopherDay Taiwan 2024に参加する経緯を説明してる。tenntenn is crazy...!

その他に影響したこととしては弊社マネーフォワードは「グローバルテックカンパニーを目指す」という目標を掲げています。 ぼくは技術広報として、社内にいるエンジニアに「お前海外カンファレンスにいけよ!」という立場になるということです(実際にそんな言い方をするかどうかはしらんけど)。

相手に対して指示するからには自分もやる覚悟が必要ではないか?と考えていました。 というかぼくは自分ができないことを指示して、なにかさせられるほど器用でないので、「自分ができないことをお願いできない」と理解していました。

海外登壇したことがない、参加したことがない人に「やれるやれる!」と言われても言われた相手からすると根拠薄弱ですし、薄っぺらいと感じると思います。というか自分なら間違いなくそうそう思う。じゃあお前やれよって反論すると思う、マジで。

なので、自分のためでもありましたが、今後会社がどんどん国内だけでなく、海外、特に成長著しいアジア圏へと進出するときに「こうするといいよ」「ぼくはこういう戦略を立ててプロポーザルを書いたよ」を技術広報として伝えられるようにしたいと考えました。

それでも、プロポーザル提出段階では採択される確率は1割もないだろうと考えていましたし、海外カンファレンスのプロポーザルを出す挑戦ができるだけで正直満足だと考えていました。

応募するにあたって考えた戦略

以下は応募するにあたって考えていたプロポーザル提出の戦略です。

戦略の方向性を考える

実は応募する前に昨年11月にtenntennさんが企画した「【オンライン】海外カンファレンスにチャレンジしたいぞの会」というイベントに参加しており、過去に海外登壇したエンジニアの方のお話を聞く機会がありました。

gocon.connpass.com

zenn.dev

その結果、ぼくの実力や実行力、これまでの経緯では正攻法「採択攻略1: 上位15%に入る」での突破は難しいだろうと判断しました。

これは正攻法で出した場合、同じテーマや近似のテーマで登壇する台湾の方がいるのではないかと推測したからです。 そして、それらのテーマをまとめきるだけの時間の確保ができない懸念があったことも正攻法での突破が難しいと判断した一因です。 (GopherDay Taiwan 2024の1週間前にRubyKaigi 2024が開催されており、会社のお仕事で沖縄にいってブース展示をすることが決まっていたので技術的調査をするだけの時間と余裕がないことが想定されていました)

そこで変化球として長谷川さんが書かれている「採択攻略2: 単純な得票数以外で勝負する」をとる方向で基本戦略を立てました。

このスライドは応募したあとに読んだのですが、プロポーザルを出そうと考えるときのエッセンスが濃縮されています。 「いつかXXXのカンファレンスに登壇したい」と1mmでも登壇したいと思う方は今すぐに読んだほうがいいです、プロポーザルを出す出さないに関わらず「どうすればいいかわかっている」状態になるのでオススメです。 (もちろん、可能ならプロポーザルを出してほしい)

自分が採択者ならどのような話をしてほしいかを考える

正直なところ、あまり採択されると考えていなかったのでここに関しては相手の視点や立場になったつもりでシミュレーションした程度に考えてください。 台湾の事情に詳しかったわけでも、過去にGopherDay Taiwan に参加したことがあるわけでもないので、自分ならどうするか、どのように考えるか?……と想像を膨らましていました。 その上で、自分がオーガナイザーや実行委員の立場なら以下のような登壇があると嬉しいのではないか?と考えました。

  • Goエンジニアの数が増えることに寄与すること
  • GopherDay Taiwanの登壇者が増えることに寄与すること
  • 日本の環境に詳しいからこそ話せること(台湾国内にいては知ることが難しい情報を発信できること)
  • @luccafort でなければ話せないこと

上記の骨子ができたタイミングでプロポーザルを確認しました。

プロポーザルを眺めながらアイディアを捻出する

プロポーザルはGoogle Formで作成されていました。 フォーム上で運営からいくつかの推奨トピックがありました。

  • AI / Machine Learning
  • CloudNatives / Microservices
  • General Development
    • Concurrency, Best Practices, Code performance Optimization, Dependency Management, Error, Handling, Memory Management, Secure Coding, Tips and Trick for Go Beginners.
  • Software Engineering
    • Automated Testing, DevOps and CI/CD
  • Other
    • Open Source Contributions, Reading Source code, Career Trends and Opportunities.

この中で登壇する際にテーマとして良さそうだと思ったのは「Others: Career Trends and Opportunities」でした。 台湾国内のキャリアの話ができる人はいても日本でのエンジニア市場の様子や働く機会、雰囲気などは日本で働く自分だけが話せそうだと考えたからです。

プロポーザルを提出する

プロポーザルのベースとなるテーマは決まりました。

  • カテゴリーは「Others: Career Trends and Opportunities」で出すこと。
  • プロポーザルの骨子は以下を満たすこと
    • Goエンジニアの数が増えることに寄与すること
    • GopherDay Taiwanの登壇者が増えることに寄与すること
    • 日本の環境に詳しいからこそ話せること
    • @luccafort でなければ話せないこと

さっそく、上記を満たすようなプロポーザルを考えます。 GopherDay Taiwan 2024における私の強みは「日本で働いていること」「日本のコミュニティ活動に大きく関係していること」この2点だと考えました。

そこで

  • 日本のGoにおける採用市場や人気をアイスブレイクとして冒頭に持ってくること(Career Trends)
  • Goコミュニティが技術広報になる際にどのような影響を及ぼしたか?を伝えること(Opportunities)
  • どのようにしてその状況に至ったのか?を偶発的計画性理論を用いて解説する?(Conclusion)

上記3つの大きな展開で1つのストーリーにできないか?と考え、プロポーザルを提出しました。 (この時点ではもう少し盛り込んでいた要素もありましたが、実際に登壇する際は持ち時間の関係でいくつか削ぎ落としました)

結果、以下のようなAbstractionを作成し、提出をおこなったところ、無事「Your proposal has been accepted」というメッセージを受け取ることができました。

In this session, I would like to talk about how my career has evolved through community activities. I'll share insights into the state of community activities in Japan, as well as the impact of "A Rainbow of Gophers: Building A More Diverse Community," presented at GopherCon 2020, on my career. Additionally, I want to emphasize the importance of planned happenstance theory, which suggests that intentionally taking action creates opportunities, through my challenge to step out of my comfort zone.

Outline:
- Brief introduction to the Japanese community
    - Changes in the number of sponsors at Go Conference
- How the Go community has influenced my career
    - What does it mean to grow with the community?
    - A third career beyond engineer and manager roles
- Two essential elements for personal growth
- A certain session at GopherCon 2020 that triggered a career change
    - Reflecting on the meaning of diversity
    - When diversity emerges
    - What we can do to foster diversity
- Challenges breed new encounters, and new encounters create opportunities
    - There are broadly two approaches to career development:
        - Pursuing a planned career path
        - Embracing planned happenstance, where personal interests and actions shape one's career, as described in Constructing unexpected career opportunities [1].
    - Communities support both approaches:
        - The former offers opportunities for speaking and presenting, enhancing individual careers.
        - The latter provides opportunities for new encounters and insights, teaching about third careers.
- Conclusion

実際に提出したGoogle Formのプロポーザル概要

採択された理由の推測

ここからは提出したプロポーザルが採択された理由について推測してみようと思います。 このセクションで書かれている台湾の情報は現地で聞いた「〜らしい」という情報です。 信憑性という点では正しくない可能性があります、その点を考慮して読んでください。

多様性のある登壇者、登壇内容を求める

まず、多くの大型カンファレンスを開催するオーガナイザーは「より多くの、より幅広いトピックを取り上げたいと考えている」という前提を置きました。 これはぼく自身がGo Conferenceでプロポーザルを採択するときも考慮する点ですし、他のメンバーも程度の差はあれど考慮していることだと思います。 どの年度のGo Conferenceか忘れてしまいましたが、英語登壇の採択が0になったときがありました。 厳正に審査した結果ではありましたが、少し残念に感じたことを覚えています。 それ以降のGo Conferenceでは世界各国から「登壇したいんだけど?」とプロポーザルを提出していただく機会が増えたので、運営メンバーの誰かが海外に宣伝をしてくれたのかもしれません。

閑話休題、ともあれオーガナイザーとしてコミュニティに多様性をもたらしたいと考えるだろうと仮説を立てました。 これはより運営するカンファレンスが大きく成長することやさまざまな登壇者や聴講の機会を提供することができるからです。 (そういう意味ではGopherDay TaiwanではTinyGoの登壇がなかったのでそっち方面で攻めても面白かったかもしれません。)

日本と台湾という近くて遠い国の差異

これは応募時点では考えていなかったことですが台湾の国民の数は2300万人だそうです。 だいたい北関東一帯の人口と同じくらいだそうなのですが、これが真実であるならば当然台湾のソフトウェアエンジニアの数は日本に比べて市場がぐっと減ることになります。 そのため、より多くのチャンスや働く機会を求めて台湾国外という選択を検討するのは自然な流れなのかもしれないと考えました。

そうなったときに中国やベトナム、韓国、日本のような近隣国で探す人も決して少なくないでしょう。 なにかあればすぐに帰れる距離、言葉がある程度通じる、ローカルの生活コミュニティがある……などなど近隣国は条件が揃いやすい傾向があります。 最悪、駄目だったら戻って来るという選択肢が取りやすいということもあります。 また食生活や文化などが近いことも大きな理由になるでしょう。

当初こういった背景を知らなかったため、台湾のエンジニアが日本という市場をどのようにみているかあまりイメージできていませんでした。 そのため、登壇後のQ&Aの際に「どうすれば日本で働けますか?」という質問が来て少し意外に思いました。 あくまで選択肢の1つということなのかもしれませんが、日本という国が彼らにとって移住するに値する国だと考えてもらえているのかもしれません。 日本のアニメや漫画のようなソフトウェアコンテンツの影響が大きいのかもしれませんが、好意的に感じている方がいそうだという手応えはありました。

台湾では英語で授業をする?

これはどこまでが対象なのか定かでないのですが、先程も述べたように台湾の人口やソフトウェアエンジニアの数は日本に比べてとても少ないです。 そのため、大学などで学ぶ際に、英語で書かれたコンピューターサイエンスの本を翻訳するよりも英語のまま使うことが多いと教えてもらいました。 そのため、教科書は英語、教授の説明は中国語(台湾語?)だそうです。

「スライドが英語で意図が伝わったんだろうか?」と不安に思っていたのですが、上記の説明をされ、「英語の方が読みやすくて助かった」と言われたことはとても衝撃的でした。 弊社はエンジニア組織の英語化を進めているので、そういった意味でも台湾のエンジニアとは相性がいいのかもしれないな……とぼんやり考えていました。

エンジニアはキャリアの話を避ける傾向がある

これは私見ですが、エンジニアの方がキャリア論を発信するのは日本国内ではかなり敬遠されているように感じています。 少なくともWebメディアなどのインタビュー記事などの依頼がなければ、自ら発信しているケースは少ないように感じています。

推測ですが「自分が歩んだエンジニア人生を語っても自分と同じにはならない」と感じているからあまり語りたがらないのかなと思っています。 いわゆる、再現性が乏しいので「同じことをすれば同じになれるよ!」とはっきりと言い切れないあたりが引っかかるのではないでしょうか。 それ以外にもどうにもキャリア論というのは上から目線で語るような形になってしまうことがあるため、それを忌避しているのかもしれません。 インタビューなら応じるというのはこの上から目線を質問者がうまく躱してくれるからかもしれないですね。

この傾向は日本も台湾も同じではないかと考えました、文化が近い傾向があったため、そういった似た傾向があるのではないかと考え、恐らく誰も提出しないであろうキャリアの話を選択しました。

実際登壇してみてどうだったか?

いい面と改善すべき面がどちらもありました。 良かった面でいうと、Q&Aで質問が出てくれたこと、そしてその返答が自分なりにできたことです。

登壇者がQ&Aの時間で一番怖いのは「質問が出ないこと」です。 それはつまり、興味や疑問を持つポイントを作れなかったということです。 そういった意味ではいくつか質問が出てくれてホッとしていますし、口頭でも質問が出てくれて嬉しかったです。

改善すべき点としては質問に対してうまく回答できなかったことです。 私はあまり英語が得意ではないです。はっきりいうなら苦手です。 そのため、相手が期待したような回答を返せなかったことはやはり改善したい、せっかくの質問してくれた機会を満足いくものにできなかったという意味で登壇者として改善すべきだと感じました。

意外だったこととしては、緊張せずに登壇ができたということです。 マネーフォワードでは毎月エンジニアが参加する社内イベントがあるのですが、そこで英語でアナウンスなどをしているからかもしれません。 他にも隔週開催でGo WednesdayというGoの標準ライブラリのサマリーを調べて英語で発表する社内勉強会を企画、実施してるのですがそこでの経験もよい影響を生んでいるのかもしれません。

海外カンファレンスに登壇したらやりたかったことの1つが会場を含んだセルフィー写真

どちらのイベントでもトークスクリプトを用意して読み上げるだけですが、そうはいっても想定外の事態は発生します。 登壇者がビデオMTGに入れない、カメラやマイクがオフのまま、インターネット回線が弱く登壇直前に落ちてしまった……などなど。

そういったトラブルに何度か遭遇した結果、緊張しにくいメンタルを身につけられたのかもしれません。 発音とか文法とか以前にとりあえずなんとか伝えないと!というパッションが大事なのかもしれません。 (そうはいっても最低限の文法や単語、会話力は必要だと思いますが)

もう1つ大きな反省点として、「視線を会場の聴講者に向けることができなかったこと」があります。 今回トークスクリプトを用意し、読み上げる形で登壇しましたが、視線を上に上げることが難しかったです。。 時間的な制約、英語の発音、考えていることを言葉にする力、さまざまなものが足りていないためにトークスクリプトを読み上げることに必死になってしまい、あまり聴講者の方の反応やセッションに巻き込むアクションが行えませんでした。 これではラジオや校内放送となんら変わりません。

参加者を巻き込んでトークに没入させる、これができて本当の意味で登壇が成功したといえるのでそういった意味でもやはり準備不足な面が目立ちました。

GopherDay Taiwan 2024の雰囲気など

海外カンファレンスに参加するのが初めてだったので、いくつか印象的だったことをメモとして残して置こうと思います。

  • 用意された紅茶が甘い!
    • 台湾ではお茶は甘いもの、ということで最初すごくびっくりしました。
    • シロップの味がする紅茶はなかなかインパクトがあります。逆に台湾の人は日本のお茶が甘くなくてビックリしたそうです。ヤックデカルチャー
  • カンファレンス中の聴講者の雰囲気は日本と同じ
    • みんな真面目に聞いているし、iPadやPCなどでメモを取っている人が多かったです。
    • 寝ている人もいなかったし、真面目な国民性なのかな?と思いました。
    • ランチタイム後のキャリアの話(それも台湾国外の登壇者の発表)なんて聞きに来る人も少ないだろうな〜と思ったら「そろそろ午後のセッションを開始するよ!」というアナウンスが入ったらすぐにみんな自席に戻ってビックリしました。
  • 台湾人はシャイらしい
    • でも日本人よりも質問してる。日本人はハイパーシャイなのかも。……というか多分シャイを通り越して引きこもり気質なんだと思う。
    • Speakerは最前列に席が用意され、そこで聴講するスタイルだったのですが、面白い発表をした人は席に戻ってきた際にさまざまな人に囲まれてAsk the Speaker状態になっていました。
    • でも、聴講中に笑ったり、声を出したりするのは恥ずかしがってた印象があるので、シャイではあるのかもしれません。
  • 台湾はハードウェアメーカーが多い影響かSREが多い(というか専門領域の幅が広い)
    • どうやら大学卒業の条件が論文を書くことではなく、アプリを作る…みたいなことがあるらしくインフラからフロントエンドまで全部やることが多いため、マルチロールになりやすいそうです。
    • COVID19のときの台湾政府の対応が早かったのはそれが原因の1つではないか?という話を台湾人エンジニアに教えてもらいました。
      • 台湾ではスクラップ&ビルドでドンドン新しいものを作る人が多いらしい
  • 台湾では女性エンジニアが多い?
    • TSMC(熊本にCPU工場を作ってるあの会社)のSREの方が登壇したり、メルペイのてんりん@tenlingpさんが登壇したりと登壇者の女性比率が高かった印象があります。
    • たまたまなのか意識してなのかはわからないのですが、ここは日本のカンファレンスも見習っていきたいなと思いました。
  • お菓子やご飯が開場と同時にセットされている
    • これは台湾の文化(中国?)らしいのですが、「お腹すいた?」が日本の挨拶に当たるようです。そういえば中国嫁日記で似たような話をみたことを思い出しました。
      • 我々も朝イチで開場と同時に入場したのですがオーガナイザーの方から「ご飯を食べたか?」と確認をされました。
      • その時点では挨拶だと思わず「資料の最終調整がしたいからまだ食べてない、終わってから食べる」と返してしまいました。これは台湾ではとてもよくないことらしく台湾の方はお腹が空いている状態の人がいるととてもやきもきするようです。
      • 懇親会でこの話を説明されて「あれってそういう意味だったのか!悪いことをしたなぁ」と話していました。
    • 休憩時間にスタッフも参加者も関係なく飲み物や軽食を手に歓談している風景はとても新鮮で面白い試みだなと感じました。

懇親会に参加してみた

After Partyを別会場で運営スタッフと登壇者のみで開催するが来るか?というメールを事前にいただいてました。 そこで現地のエンジニアと交流することも目的の1つだったのでアンケートフォームに必要事項を入力して参加しました。

日本のように誰かが音頭を取るのではなく、各自料理やお酒が出たタイミングで食べ始めるし、席を立って話し始めるしとっても自由な感じで気楽に参加できました。

そして、なによりも台湾の懇親会はとても多くの料理が出てきて圧倒されました。 台湾では食べきるのではなく、食べきれないくらい料理を出してくれたことが敬意を表す文化で食べきらなくていいよ!と言われましたがそんな量の料理じゃありませんでしたw 鍋が3つも4つも出てくるわ、食べかけの大皿が回収されたと思ったら、別の小さなお皿にまとめられたりと日本との違いを感じました。

また帰るときも親しい人にだけ「じゃあね!」という感じであっさり帰っていくので最初「あれ?なにか買いに出かけたのかな?」と思ったら「彼は帰ったよ!」と言われて「なるほど〜これ日本も真似してほしいなw」と思いました。 ぼくは下戸なので、2次会3次会にいくのは結構しんどいことがあります。 そういう意味で、ほどよく自分本位(悪い意味じゃないよ!)な感じで始まり、終わる懇親会が心地よく感じました。 これは事前に会費などでお金を回収していたか、運営費から飲食費を出していたからだろうなーとは思うけどそれでも気持ちの良い懇親会でした。

我々があまり英語が得意でない、日本語が喋れるスタッフがあまりいないということでメルペイのてんりんさんが翻訳や主な会話相手として懇親会では会話をしていました。 ただ時折、「日本だとこれはどうなの?」や「台湾で驚いたことはある?」といった質問がされたり、「明日もし時間があったら観光につきあうけどどう?」という大変親切な提案もされました。 正直、そこまで接待的なことをさせてしまうことに気が引けていたところ、てんりんさんが「日本人はそこまで気を使うと逆に困るから彼らだけで大丈夫よ!そっちのほうがいいでしょ?」と聞いてくれて助かりました。 てんりんさんの日本人の解像度が高すぎる。

そのあとは台湾のIT産業の話や大学での教育、登壇内容、台湾のおすすめのタピオカミルクティーやお土産屋さんの話など雑多な話をいろいろな方としました。 自由だけど、温かいそんな台湾での一夜でした。

本当は「懇親会のあとに夜市にいこう!」と誘われていたのですが、登壇当日の朝(というか深夜)01:30am頃に急な歯痛によって目が覚めてしまい、以降ズキズキと痛んでいたのでホテルに戻ることにしました。 tenntennさんは一度ホテルに戻ったあとで家族の方にリクエストされたお土産を買いにいっていたみたいです、元気ですごい。

登壇後の反省

今回の登壇における反省点は多いのですが、まず冒頭で書いた「経費申請の提出がギリギリ、というか間に合ってなかった」ことが大きな反省点です。 これに関しては言い訳のしようがない失態なので、本当に反省しなくてはいけないと思っています。 上司からもかなり厳し目のお言葉をいただいていますが、これは本当にその通りなので、反論の余地がないです。

2点目はRubyKaigiとこのGopherDay Taiwanの開催期間が近すぎたため、十分な準備が行えなかったことです。 どうしてもRubyKaigiではブース展示などで手が動かせない時間が長く、登壇資料を少しでも進めようと考えていましたが、最終日Day3の際にハックスペースで2時間ほど作業ができただけでした。 これは計画が破綻していたことを意味します。

1つ目の理由にも影響しますが公私のタスクが多すぎたため、全てに悪影響を出してしまいました。 優先順位付けと仕事の進め方を改めないといけないと感じました。

また今回は英語での登壇だったので、弊社の京都拠点にいる外国籍メンバーや英語が話せるメンバーに登壇内容をチェックしてもらったのですが、その依頼も急でとても迷惑をかけてしまいました。 また、迷惑をかけた割にスライドができたのが登壇前日の夜遅くだったため、実際の発声練習で聞き取りにくい発音や言い回しがないかのチェックが行えませんでした。 DQNEOさんがいっていた1ヶ月前にスライドを完成させる、あとはスクリプトを読み込み続ける、レビュアーに発音の問題を指摘してもらうという理想的な状態での発表ができませんでした。

これは参加して思ったことですが、ぼくのスライドはすぐにページを捲って忙しない印象がありました。 他の登壇者は1つのページに対する説明をじっくりおこなっており、図解を出しても「これがこうなってこう」のような一言で説明するのではなく、じっくりと背景や課題、どう変化していったのかを丁寧に説明していたように思います(説明中に出てくる2割ほどの英単語からの推測なので間違ってるかも。中国語は読めるけど発音されるとわからん)

まとめ

今回、自分自身のトライな面もありましたが、自社のエンジニアが海外登壇するときにどのようにプロポーザルを出してもらうといいのか?を考える一環として応募をしていました。 本来の想定としては半年後くらいに行われる、アジア圏かヨーロッパ圏あたりのカンファレンスに応募しようと考えていましたが、結果として練習するつもりで、提出したプロポーザルが採択されてしまいました。 次の半年後のプロポーザルが採択される保証はないため、悩みはしましたが登壇する決定をしました。この決断がいまもって良かったかどうかは悩ましいです。

結果だけみると、良かった面もあるのですが、その結果各所に迷惑をかけてしまったのでそれは深く反省したいと思います。

登壇者、エンジニアとしてはとても貴重な経験をさせてもらったことは間違いありませんし、これで今後自社のエンジニアに「XXXという海外カンファレンスがあるんだけどプロポーザルを出してみない?ぼくが過去に登壇した経緯や戦略なら多少参考にしてもらえるかもしれないので相談に乗るよ!」と言えるようになったんじゃないかと思います。 サンプル数1の意見なので、決して大きな力ではないかもしれないですが、0でないという点が大きいかなと思っています。

以上、これにてぼくのGopherDay Taiwan 2024を終えたいと思います。 初海外カンファレンス参加と初海外カンファレンス登壇のダブル初を達成したので、しばらく登壇はいいかなーという気持ちでいます。

さすがに今回はさまざまな迷惑をかけたし、ぼく自身もカロリーを消費して疲れました。 しばらくは英気を養う方向でいたいなと思います。

もちろんGo Conference 2025や会社で企画するイベントなどは別ですよ!

この記事は歯の詰め物が取れて痛すぎるので月曜朝一の新幹線で東京→京都に帰る際に書きました。 まあまあ疲れたし、歯が痛いなどの想定外のトラブルなどで大変だったので皆さんからの投げ銭をぜひお願いします。 お金があればいいわけじゃないですが、今回はRubyKaigiと技術書典、そしてGopherDay Taiwan、Go Conference 2024が1ヶ月の間にギュギュッとつまっていて大変でした。

OKIMOCHI

誰かにねぎらってほしい。

おまけ

  • 体調不良
    • 登壇前日に急な歯痛が発生した。登壇後に徐々に悪化してるダルい。
    • RubyKaigi帰還後の鼻詰まりと喉の痛み
  • イベント終了後にテンションがだだ下がり、tenntennさんに「明らかにテンションが下がってるけど大丈夫?」と言われる
    • 実際にはテンションを上げるアクセルが壊れてるだけで、心は虚無でした。マイナスにはなってない。
    • と思ったけど日本に帰るフライトのあたりから明らかに歯が痛くなってきてマイナスになった。本当なら東京のメンバーとランチにいこうと思っていたけどキャンセルすることになった。申し訳ない。
  • 1人だったら登壇できたか?
    • 正直難しかったと思う。誰か1人は知り合いがいないと困ったときの相談もできない
    • そう考えると海外から日本国内に参加している人と何かしらで交流してコネクションを作っておくのは海外登壇を考えている人にはいいかもしれない
    • 現地に友達がいたらいいけど、大体の場合そうではないので知り合いを作るって大事だなって思った。
  • GopherDay Taiwan 2024はどうだった?
    • オーガナイザーのMarkとGTBがとても親切で本当に助かった。
    • それ以外のオーガナイザーたちもとても親切で不便なく登壇できるようにサポートしてくれてとても助かりました。
  • なぜアジア圏で登壇したのか?
    • 例のイベントで誰かがいってたけどいきなりアメリカで登壇するよりも英語ネイティブでないヨーロッパやアジアで登壇したほうがお互いにネイティブでないのでやりやすいかも
    • 今回はまさにそれを実感した。ネイティブではないけど発音がきれいな台湾の方が多く、なにをいってるのかがわかりやすかった。
    • もちろんそれでも聞き取れないことはあったけどかなり楽だった。発音の癖が似てるのかな? ‐ イベント前日の夜に食べたご飯の量が多すぎ!
    • 餃子は主食。おかずじゃない。

日本の感覚でラーメン + 餃子を頼んだらこの量になった

その他写真置き場

メルカリがスポンサーしてた。次回はマネーフォワードのロゴを掲載したい
基調講演で話し始めていい?って確認してるtenntennさん
朝9時開始のカンファレンスなのにみんな意気軒昂。質問もバンバンしてくる
LINE 台湾のGoogle Developer Expertの方と。
日本のブースは凝りすぎかもしれんと思った。素朴で可愛い。
段ボールの中にコーヒーや紅茶が入ったビニール袋がある。もちろん紅茶は甘い。
個人的に一番面白かったセッション。TSMCのプリンシパルSREの方。資料公開してくれないかな〜。
DCardという台湾のFintech企業の方の発表。初めて登壇するっていってたけど発表がうますぎて絶対嘘だ!って思った
自然とAsk the Speakerっぽいゾーンが出てきて楽しい。
朝から無限に食べ物が供給される、お菓子だけかと思いきやちゃんとしたご飯っぽいものもあった
ジョブボードっぽいやつ。みんな思い思いのことを書いたりGopherくんを書いたりして楽しんでた。
俺たちも書くぞ!っていって書いてる図
質問に来てくれた人との交流。こういうのいいよね。
メルペイ @tenlingp さんの発表
アイコンと猫が可愛い
帰るときに「あれ?これ撮ってなくね?」と話して慌てて撮ってた電光掲示
懇親会会場。この頃にはかなり歯が痛かった。美味しかったものもあったのにあまり味わって食べられなかった。
GopherDay Taiwan 2024の運営チームの皆さん、めっちゃ親切で本当に感謝の気持でいっぱい。ありがとう!
台湾では食べ物などにちょいちょい突然日本語が登場して面白い。
多分登壇前のうまく画面が映らなくて困ってた時の写真。事前チェックではうまくいったんだけどなぁ。
もうそろそろ時間だけど始めていい?って確認してる
意外と緊張しなくて自然な走り出しができた。
何言ったときかわからないけど、この顔めっちゃムカつく表情しててお気に入り。

「これ誰得なんだろう?」と思ったら登壇チャンス

TL;DR

ブログや登壇資料を作成していたり、作成しようと思うと「これって誰得なんだろう?」と疑問を持つことがあります。 そういう悩みはだいたい無駄だし、悩んでる時間が無駄なのでやめましょう。 登壇しないのに誰かの得になるかどうかがわかるわけないだろ!!!という心の叫びです。 この発言の矛先はだいたい登壇資料を作っている自分に当てたメッセージです。

元ネタ

Twitterで「こんなの誰得だし、ブログ書くのやめようかなー」という発言をみて「とりあえず書けばいいじゃん!」と唆したあとで上記発言をしたんですが、まあまあ良いこと言ったかもしれないとあとで思ったのでログとして残しておきます。 TwitterやSlackでの発言は掘り起こすことができるとはいえ、基本的に揮発してしまうのでこうやってログに残すの大事。

発言の真意

だいたいこういう「誰得なんだこれ」という発言をするときって「これ書いたら面白いんじゃね!」という勢い駆動でブログを書き始めたり、資料を作成しているときに発生するんだけどこういう悩みってだいたい無駄なことが多いんですよね。 なぜかって「事前に誰かの得になるかどうかはわからない」というのが前提としてあります。 誰かの得になることがわかっていれば、おそらくすでに世の中に同じ情報があふれているでしょう。

でも、「これは面白いかも!」と思ったということは似たような事例が見つけられなかったはずなんです。 と考えると少なくともその情報はユニークである可能性が高いわけですよね。 それにブログでも登壇資料でもそうなんですが、誰かがそれを観測して初めて「価値」が生まれるわけですよ。

誰も観測していないのに「これは価値がないんじゃないか?」というのは当たり前の話でそもそも観測前の段階では「価値」がプラスかマイナスかすらつけられない不定の状態だといえます。Undefinedなんだから評価のしようがないのは自明ってわけですね。

そう考えると定義前に「この定義はプラスになるかマイナスになるか?」って悩むのは無駄なわけですよ(考えるのが無駄というわけではないです) 自分が世間一般を代表できるくらいその分野について詳しいのであれば別ですが、そうでないなら迷う時間の分だけ無駄なのでとりあえず書けばいいんじゃない?というのがぼくの主張です。

というのも弊社のテックブログのレビューをしていてわかったことなんですが「これは価値があるぞ!」と思うような記事でもあまりPV的には跳ねなかったり、逆に「これくらいの小ネタがあってもいいよなー」と思っていたらそれがめちゃくちゃPVが跳ねたりしたという経験があるからです。

moneyforward-dev.jp

世の中の人がなにに「価値」を感じるかがわかるなら出版社はこんなに苦労してないし、テレビも編成に苦労しないでしょう。 もちろんある一定評価されやすい型のようなものはあると思いますが、同じ型ばかり続けていればいつかは飽きられてしまうのでやはりこれもどこかで変える必要があるんじゃないかと思います。

なので、「これって誰得なんだろう?」と迷ったら「迷う暇があったら書き上げろ」と自分自身に言い聞かせましょう。 そのうえで集客ができなかった、期待したようなPVが得られなかったら「じゃあ期待値を達成するためにはどうしたらいいか?」を考えたらいいと思います。 というかそこがまず出発点です。 アウトプット(ブログや登壇)はあくまでもアウトカム(報酬や結果)を得るための途中経過なので、出発することなく諦めてたらそれこそ価値がないですよ。 まずは世の中に価値を問うためにもアウトプットしましょう。

……ということを昨年も会社のSlackに書いてた気がします。

アウトプットするとまさかりが飛んできて怖いという話があります。 これはまあわかる。対面であればお互い相手に対する敬意を示しながら批判的なフィードバックをおこなってもそこまで問題にならないのにネットやテキストにアウトプットするとコンテキストが全く違う人からクソリプやそもそも文章も読まずに批判してくる人や批評家めいたコメントを書きなぐって死体蹴りし放題みたいになりがちなのでそういうのに巻き込まれてたくないというのは自然な感情だと思います。

なので、いきなりテキストやネットに公開するのが怖いなーって人は同僚や友人なんかに考えていることを伝えてみたり、感想を求めてみるといいんじゃないかなって思います。 そこでいいフィードバックが得られたならそれには価値があるってことですよ。 自信を持ってアウトプットしていきましょう。

というようなことを考えていましたよ。 だいたいここまで書くので30分くらいです。

あとそもそもマサカリが来るほど読まれねえから!!!!!!! マジで!

マサカリが飛んできたら「メンゴメンゴ、間違ってたらからここ直したわ!」ってやればいいんじゃないですかね。 致命的な嘘や騙す意図がなければそれでいいと思うんだよなー。 ここはチラシの裏だぞ。

最後に宣伝です。 そういうアウトプットする場をGo Conferecen 2024前日に設けました。 LT枠しかないんで40分枠で応募した人は厳しいと思うんですが、よかったらプロポーザルが不採択になってしまった人や申込み忘れてしまった人は登壇リベンジをしてください。 あんまり大人数にしてしまうと大変なのでオフライン限定で最大でも50名くらいの前夜祭にしようと思ってます。

moneyforward.connpass.com

2024/1/27【オフライン】Kyoto.rb Meetup プロと読み解くRuby 3.3 NEWS をDeep Diveするぞ!を開催した #kyotorb

TL;DR

タイトルの通りだけど開催したよという話。

kyotorb.connpass.com

最初はRuby 3.3 のRelease Noteを読みながらわからないところや気になったところを深掘りしていこう……と思っていたのだけど id:onk さんが「"プロと読み解くRuby 3.3 NEWS"があるんだからそっちのほうがよくない?」と教えてくれて変更したんだけどこれがめちゃくちゃよかった。 今回のMVPを上げるなら間違いなくこれ。

product.st.inc

いつも通り、イベント中のログはscrapboxにおいてある。

scrapbox.io

宣伝

moneyforward.connpass.com

どうせ、最後に宣伝おいても読まれないと思うので最初に宣伝です。 今週の水曜に東京出張してマネーフォワードの東京オフィスを使ったイベントを開催します。

ソフトウェア開発の現場でチームとしてソフトウェアデリバリーを如何に速くするか? どのような工夫や悩み、そして未来の展望を持っているかをFindy Team+ Awardを受賞した弊社 + グループ会社共催で開催します。 採用とか認知向上とかも目的ではあるんだけど、個人的には中々相談しにくい組織のアウトプットを如何に向上させていくか?を起点に交流を加速させたいなと思ってます。 お悩み相談が一番懇親会で盛り上がるんや!!!

というわけなので参加できそうだなっと思った方はポチポチっと登録してもらえればと思います。 閑話休題

最近のKyoto.rbの嬉しい変化について

相変わらず参加者は全盛期の頃の30名には遠く及ばないのだけど最近10名以下くらいの人数で行う勉強会のほうがやりやすくていいかもしれないと感じている。 今回参加してくれた方は自分を含め全員で6名なのだけど、以前来てくれた人、新しく参加してくれた人といい形で新旧メンバーが織り混ざっている気がする。 またリピート率が比較的高いこと、ドタキャン率が異様に低いこと(参加率がほぼ100%なんだけど東京では考えられない)、一定の割合で新規参入者の方がいることなどなどポジティブなニュースが多い。 以前はonkさんとぼくの2人しかいない、というようなこともザラにあっただけにこの変化は大変うれしい。

なによりも全てのコミュニティで歓迎すべき新規参入者される方が数ヶ月に1度いるというのも大きい。 こういうと初心者の方ほど「自分は最近Ruby/Railsを学び始めた初心者(ニワカ)なので……」と申し訳なさそうに卑下されることがあるが、コミュニティにおいて参加者の技術レベルはそこまで重要じゃない。

もちろん、技術レベルが高ければ高いほど高難度の話題ができるというメリットはある。 反面、会社や個人の技術スタック、これまでのキャリアの背景、興味関心が大きく異なるメンバーが集まるのだからハイレベルな話題を提供するのは意外と難しい。 企業内のイベントであればそういったこともできると思うが、さまざまな方が参加するコミュニティではよほど大手か参加者のレベルが一定上に高くないと開催の難易度が高くなりすぎてしまうと思っている。

「プロと読み解くRuby 3.3 NEW」で特に良かったところ

正直サッと目を通したくらいしかしていなかったのだが、思いの外変更点が多かった。 イベント時間を3時間半にしていたのだけど休憩をはさみながら読み終えるのにちょうどいい時間と分量だった。

以下は個人的に気になったり、面白いなと思ったり、プロダクト開発に影響しそうだなと思った変更点

  • クラッシュレポートをファイルに保存する RUBY_CRASH_REPORT 環境変数が導入された
    • クラッシュレポートをファイルで出力したいケース、稀にあると思うんだけど環境変数で指定できるの便利。
  • Encoding#replicate が削除された
    • こんなメソッドがあると知らなかったが存在していた理由、削除された理由どちらも納得感があり、勉強になった。
  • 任意の Fiber を終了させる Fiber#kill が導入された
    • むしろいままでなかったんだ?!とビックリしたが非同期処理はいつも思うけど難しいね。
  • 匿名モジュールに仮の名前を付ける Module#set_temporary_name が追加された
    • おもしろポイントとして、クラス名っぽい名前を与えることはややこしいので禁止されています。

    • 本文中にもあるけどこの仕様は面白かった。個人的にはこっちの仕様のほうがめんどくさくない?と思わなくもないけど確かに誤解の余地があるとなると……。
  • アプリケーション初期化終了時に呼ぶ Process.warmup が導入された
    • Railsアプリケーションを開発してるだけだとあまり意識しないと思うけど、ミドルウェアやライブラリ、あとはなにかの調査を行うときに便利そうだなと思いながらみていた。
  • Range を逆順にたどる Range#reverse_each が追加された
    • メモリ上で配列に展開した上で、最後の要素からたどるもの

    • いままで意識したことがなかったけどこうやって実装されているのかーと納得し、遅いと書かれた理由にも理解した。
  • 範囲同士が重複しているかチェックする Range#overlap? が追加された
    • 範囲同士が重複しているかチェックすることはままあって、その際に重宝しそう。 Range#overlap? があると楽になる一方で余談のところは正直複雑すぎて絶対間違える人が出そうだなと思った。
  • Refinement#refined_class が #target に名前変更された
    • 名前を変更した理由が歴史的経緯なものを説明しており、学び。そういえば何かで書かれていたな……とぼんやり記憶を思い出していた。
  • String#bytesplice がコピー元の部分範囲を指定できるようになった
    • これといって使い道を思いついたわけではないが、いろいろイタズラできそうなメソッドで楽しそう。
  • Time.new の引数の制限が厳しくなった
    • これは業務に影響がでる可能性がある変更だなと注意してみていた。変更意図としては納得なので対象箇所に注意が必要そう。軽くプロダクトのコードをチェックするくらいはしておきたい。
  • 名前解決が割り込み可能になった
    • 普段関わりがないCの世界の話が多いんだけど、いろいろと難しいんだな……という気持ちになった。遠藤さん、お疲れ様でした。
  • Random::Formatter#alphanumeric が使用文字種を指定できるようになった
    • これ前職のときに出来なくて、ライブラリいれたか自作したか忘れたんだけど欲しかったやつだ!!!と個人的に盛り上がった。
  • 無引数 it が警告されるようになった
    • インターネット上でざわついた例のやつ。まあ影響がでかすぎるので何かしら大丈夫な実装をするだろうと思っていたけどその後の続報を追ってなかったのでちゃんと把握できてヨシッ!
  • NoMethodError の表示形式が変わった
    • 個人的には一番影響がありそうだと思ったポイント。
    • inspect で展開されたときはいい変更だと思ったけどログにクリティカルな情報が出てしまうことなどがあったりしたのでコレはいい改善点

まとめ

今回のKyoto.rbは成功したなーと思ってる。 普通に楽しかったし、知らないことを知れたり、雑談もそこそこ盛り上がった気がします。

次回はすでに開催が決まっていて2月24日になります。 昨年、「るりま&るびま読む会を企画するって聞いたんですがいつですか?」と言われたまま、別のイベントなどに追われてしまったので今度こそ!というリベンジマッチです。

kyotorb.connpass.com

5月にRubyKaigi 2024が開催されるので、その前後4月と6月は前夜祭や後夜祭を企画しそう……となると以前onkさんとやるぞ!といってたOSS Gateが中々開催できなくなってしまうので「じゃあ3月にやりますかー」という話をしました。 3月はOSS Gate回になるんですが、まだ日程がFixしてないので、こちらもFixしたら早めにイベントページを公開しようと思います。

Rubyに興味がなくてもOSSにコミットしてみたい人はいるんじゃないか?という仮説の元企画しています。 もし好評だったら半年おきくらいで開催してもいいかな。

OSS Gateはサポーター枠5名、参加枠(ビギナー枠)10名くらいのこじんまりした回を想定しています。 あんまり人が多いとサポートしきれないのでな……。

もし、興味がある方はお早めに。 多分サポーター枠は先着、参加枠は抽選とかにするんじゃないかな。 上限を超えるほど人が来るとは思っていないけど。

ではでは。 また来月。

[追記]

以下は最近英語を頑張ろうと思ってるが、なかなか上手くいってないので乱心してTwitterに英語で一日のサマリーを投稿する練習をしている様。 難しい表現とかはいれてないし、多分文法的にむちゃくちゃとかって面もあるんだろうけど、英語投稿→翻訳→修正→翻訳を繰り返すのが中々楽しい。 楽しいというかそれっぽい文章になってるように見えるのでちょっとした成長や表現(文法や熟語)などをただ丸暗記するよりはやる気がでる。 ……ということで今回の催しとSTORESさんのブログに感謝をしたのでした。

変えることは圧倒的に正しいではなく"変えることは無条件に正しい"だった

TL;DR

よく id: Songmu さんが「"変えることは圧倒的に正しい"といってたが出典元を忘れた」といってたが出典元を見つけたよというお話。 そして、実際には「変えることは圧倒的に正しい」ではなく「変えることは無条件に正しい」が正解だった。 間違えてたのと、今後も間違えてしまう可能性があるので調べられるように記事として出しておく。

出典元とかを正しく認識した

出典元はこちらの記事の「おわりに」に書かれている。

developer.hatenastaff.com

書かれてる内容の大筋は記憶してたけど正しく言葉を把握してなかったし、なんならはてなスターもつけてなかった……。 しかし、これもう5年前の記事なんだな。

出典元に書かれている内容はとてもよいので未読の方はどうぞ。