Shohei Mitani

不定期開催

Ya8 2024 - ヤパチー 令和六年最新版(仮) に参加しました

3/15-3/16で練馬で開催されたYa8 2024 - ヤパチー 令和六年最新版(仮)に参加してきたので感想ブログ書きます。

全体を通して

テックなんだけどテックだけじゃない、コミュニティの良さが全方位で感じれたイベントでした。 Perl界隈の方々と交流始めたのが去年の年末くらいからなんですが、YAPCもYa8もすごく好き。

エンジニアとして技術交流できるのも楽しいし、趣味の話とかパーソナルな部分のトークを聴けるのもの楽しいし、2日間のそれぞれでテーマが決まってて両面トラックで楽しめました!

登壇したこと

speakerdeck.com

「孤独のCTOグルメという やや奇抜な企画をやった目的と効果」というトークをさせてもらいました。

私が所属するスマートバンクという会社で技術広報に力を入れており、その一つとしてやっていた孤独企画をやっています。 一見するとお遊びっぽい企画ですが、裏側では真面目8割、遊び心2割くらいで本気で取り組んでましたよーというお話でした。

Kaigi on RailsYAPC::Hiroshimaに参加された方が聴きにきてくださったので、結構ホーム感のある会場でゆるくトークできました。 聴きにきてくださった皆様、ありがとうございました!

いくつか爆笑を取れたので満足です。

孤独の話を聞きたい方、出張してトークできますのでお声がけください。

面白かったトーク(順不同)

中国地方DB勉強会 in 東京(CFX

MySQLとPostgresSQLがキャッキャウフフする 令和最新版(1)コピー20240316のトークと合わせて、Ya8で一番学びがあった内容でした。

MySQLとPostgresSQLとOracleの専門家が集まって話を聞いたり質問できる機会なんて普段ないので贅沢すぎます。

それぞれの製品を横に並べて機能比較したり、お互いが優れているところとか思想の違いを聞けたのでより一層DBに対しての理解が深まった気がします。

yokuさんに生で質問できたのも嬉しかった。

[令和最新RADIUS!] RADIUSをRustで実装する。そして君たちはRADIUSの仕様をどう攻略するか。

moznion氏の「困る!」が印象に残ったトーク

そもそもRFC自体、実装するために細かく読んだことはなかったのでツリー構造にして理解するとか、技術的にふわっとした部分があるとか色々参考になる話でした。

多分RADIUSを使う機会は今後訪れそうにないけど、もしやってきたら https://github.com/moznion/radius-rs を使おう(違う?

10年間、派手髪を貫く技術

あすみさん、声が大きいってXで観測してたけどほんとに大きくてびっくり。

自分はずっと白髪染めしてるので派手に染めたことはないけど、酸性カラーとか知らない話ばっかりで面白かったです!

20年間、白髪を染め続けてどうでも良くなった技術の話をアンサートークしようかな(違う

移動を支える技術

papixさんの移動にかける情報量がすごい! & 修行って何!!いろんな世界に修行があってみんな修行しすぎてる気がする。

新幹線にするか飛行機にするかの境界地点が広島らしいですが、そういう話があることすら知らなかった元広島人なのでした。

自分は親が空港まで迎えに来れる時は飛行機で、そうでない時は新幹線で広島に帰る勢です。

OrbStackを布教させてください!お願いします!

OrbStack使ってるけど雰囲気でしか使ってないので好きな人の話を聞きたい!ということで聞きにいきました。

ドメインネームの機能とか知らなかったのと、トーク終わった後のみんなの雑談感がすごい楽しかったです!

Podcastを3年半続ける技術と得た物

会社のPodcastでちょっとだけホストしたりゲストとして出たりしていて、今年もうちょっと本格的にPodcastしてみたいなーと思ってたので聞きにいきました。

3年半続けてるからこそのオーラかもしれませんが、いい感じに肩の力を抜いて継続することを大事にされてるように感じ、自分もやってみたいなーと背中を押された気持ちになりました!

相方大事。

何度転職してもデザイナーになってしまうエンジニアの話

Ya8なら自分語りしてもいいよね!からスタートしたトークでしたが、ninjinkunさんのこれまでのお話聞けてすごい興味深かったです!

トーク的には、本意じゃなく気づいたらデザイナーの仕事もやることになったという印象受けましたが、参考文献とか実際にデザインしたものを見るに裏側ではすごい勉強したり真剣に取り組まれた結果なんだろうなーと推察しました。

終わりに

花粉症にやられて2日目を早退してしまったのが悔やみ。。。

uzullaさん、ありがとうございました!次回作に期待してます!!

YAPC::Hiroshima 2024 でベストトーク賞をいただきました #yapcjapan

私の故郷で開催されたYAPC::Hiroshima 2024で、大変ありがたいことにベストトーク賞をいただきました。聞いてくださった皆様、そして投票してくださった皆様、本当にありがとうございます。感無量!!

初めてのYAPCでPerlMongerでもない私にこのような賞をいただいて、改めてYAPCすごい!!!と思っています!!すごい!

続きを読む

ゴルフで100を安定的に切るために必要な "手持ちの技術"

自分はコヤマカズヒロさんの弱者のゴルフマネージメント - YouTubeが好きで、その中に『ゴルフとは「手持ちの技術を駆使して、いかに良いスコアを出せるかを競うスポーツ」という話』という会がある。今回は自分なりのゴルフで100を安定的に切るために必要な "手持ちの技術" について紹介したいと思う。

続きを読む

Kaigi on Rails 2023に登壇して感じたオフラインイベントの良さ

Kaigi on Rails 2023に登壇者として参加してきました。登壇資料はこちら。

32個のPRでリリースした依存度の高いコアなモデルの安全な弄り方 - Speaker Deck

こんな素敵なイベントを開催してくださった運営の皆様、ありがとうございました!

登壇した内容については会社のブログの方で改めてまとめようと思うので、こちらではイベント中にひしひしと感じていたオフラインイベントの良さについて個人的な感想を書き残したいと思います。

Kaigi on Rails 2021 & 2022を振り返って

ありがたいことにKaigi on Railsには3年連続でプロポーザルを採択していただきました。(2020年はサービスのローンチ直前の時期に重なってしまい参加どころではなかった)

初めて登壇した2021年は15分枠で監視についてお話しさせていただきました。 この時はkamipoさんの基調講演の直後のトップバッターということでめちゃめちゃ緊張したのを覚えてます。 この登壇は事前収録だったので、確かイベントの1ヶ月前くらいには資料を作って自宅で録画して提出したような記憶があります。 動画初心者すぎたので撮影の仕方や編集の仕方が一切わからず、四苦八苦しながら準備していました。

2022年は前回の反省を踏まえ、より喋りたいことを削らずに喋れるように30分枠で状態管理についてお話ししました。動画撮影には慣れたものでしたが、30分枠を一度も噛んだりせずにやり切るのは難しく、録画したものを見ては気に入らずに撮影し直すのを繰り返して、結局完成させるまでに2~3日を費やしていました。おかげさま?で、動画の切り貼りや映像のスピードを変えることでの時間短縮化など色々な動画編集テクニックを手に入れることができ、翌年の自身の結婚式のムービー作成に活かされることになりました。

2021年と2022年の両方とも1ヶ月前には動画を提出し終わっていたので、気持ちとしては芸能人の "オンエア待ち" 状態になっていて、発表することへの緊張感はなくどんな反応が来るのかだけにドキドキしていたような気がします。イベント当日は会社の人と一緒に自分の発表を見ていて、YouTube上の同時視聴数だったり当時のTwitter上の反応を見ながら自分の発表の出来がどうだったのかを感じていました。

オンラインイベントの動画提出型登壇は、発表内容をいくらでも撮り直したり練り直したりできたので、伝えたいことをできるだけ端的に伝えることはやり切れた一方、FBが社内の人とTwitter上のコメントしかないので、発表の出来についてはふわっとした感覚しか掴めなかったように思います。それでも自分の発表を聞いて会社に興味を持って採用に応募してくれる方々もいてくださり、そういったことを通じて登壇して良かったなと思っていました。

Kaigi on Rails 2023の熱気

2023年は初のオフラインイベントということで、ついに動画撮影と編集から解放されて生身で戦うことになりました。不思議なもので毎年登壇資料を作っていると、登壇に対しての期待値がコントロールできるようになって話し手と聞き手のちょうど良い繋ぎ目が見えてきます。「こんな自明そうなことを喋っても良いのか?」とか「こんな内容誰も興味ないのでは?」という不安を感じにくくなり、運営がプロポーザルを採択したのだからきっと誰かには響くはずと自信を持てるようになります。

一方で過去2回のような撮り直しができないので、ちゃんと時間通りに喋り終えれるか?喋る内容忘れちゃって事故らないか?みたいな不安との戦いがありました。オンラインの時はオンエア待ち状態だったので当日に向かっての緊張感の高まりが薄かったのですが、今回はまさに "対戦よろしくお願いします" 的な気持ちで1週間くらい前から徐々に緊張してました。(こういう決まっている日付に向かって徐々に緊張していく感覚は、自分の中ではバンジージャンプとかスカイダイビングをやるような気持ちに似ていると思っていて、だんだんと飛び降りる場所に向かうにつれて緊張は高まるけど、飛び降りてしまえば楽しさが上回るからその道程も楽しもうと少し引いた目線でメンタルマネジメントをしていました)

イベント当日はありがたいことにRoomBの席いっぱいに埋まって、たくさんの方に聞いてもらえることができました。今回はスポンサー&ブース出展も一緒にできたということもあり、ブースまで感想を伝えに来てくださる方もいたり、本当に感謝の気持ちでいっぱいになりました。どんな人が聞いてくれたのか、どういうところに興味を持ってもらえたのかを直接お伝えしていただけるのは、本当に登壇冥利に尽きるなと思います。過去2回ではしっかりと掴み切れなかった手応えを、今回のイベントではしっかりと掴むことができたように感じます。

また、懇親会でも色々な人とお話しすることができ、他の方の発表内容だったりそこから発展した会社での話で盛り上がり、オフラインならではのイベントの良さをひしひしと感じました。まさにコロナ禍で失われていた熱気を完全に取り戻すことができたなーと思います。

蛇足: 発表資料のデザイン

毎年、SmartBankの発表資料について、デザインだったり構成の良さを褒めていただけるので、個人的に資料を作る際に気をつけていることを紹介しようと思います。

① テンプレートが大事

発表資料を作るときにデザインに凝り出すと、資料を作っている場合ではなくなるのでテンプレートは非常に大事です。ありがたいことにSmartBankでは専用のテンプレートがあるのでそれを必ず使うようにしています。Railsエンジニアには "レールに乗る" で伝わると思いますが、"テンプレートに乗る"ことを意識しましょう。テンプレートでできないことをしたり、テンプレートにないスライドを追加したりは自分はしないようにしてます。

② サービスの色で統一する

自社で開発・運用しているサービスがある場合、例えばアプリアイコンやロゴ、サービスサイト、アプリの中で使われている色があると思います。これらの色はプロのデザイナー達が選定した色の組み合わせなので、特に意識して使わなくてもそっと使うだけでオシャレになります。メインで使われている色と補色を意識して、文字を強調したり図を入れてみると良いと思います。

スライドの先頭でサービスの紹介ページを挟む場合、スライド全体をその色で合わせていると統一感も増します。

③ 上手い人を真似る

なんやかんや良いものを真似るのが一番効く施策で、テンプレートも色も真似できる人のものを使うのが良いと思います。自分の場合は、同じ会社のアプリエンジニア(nakamuuu)のデザインをパクるところから始めました。そこから ohbarye さんがスライドの中で最初に期待値調整を入れているのが良いと思って真似たり、CEOが投資家向けに使っている資料でかっこいい部分を真似たりしています。

特に投資家向けの資料は、何度も発表を繰り返してブラッシュアップされてるもので人に伝えるエッセンスが詰まった宝庫なので、もし会社の中で見ることができるなら一度見てみると良いと思います。

来年に向けて

クロージングでの大倉さんの話にもあったように、2020年のコロナを乗り切って開催を続けてくださったことが今年の熱気につながっていると思いますし、私自身もオンラインとオフラインのイベントを両方経験することができました。改めて運営の皆様に深く感謝申し上げます。

きっと来年もプロポーザルをたくさん出すことが一番の恩返しだと思うので、来年も登壇できるように準備していきたいと思います。

終わり

1人プロジェクトで孤立しないためには工夫が必要

最近とあるPJで一人エンジニアとしてコードを書いていたところ、レビューをもらうときに特定の人にしか依頼ができずにレビュワーの負担を強めたりリリースが遅くなるといったことがあった。そのPJは社内でも新しい技術セットを使ったもので、設計から開発、テストまでほぼ一人で進めて来たこともあってレビューのタイミングでいきなりチーム外の人にお願いするのはハードルが高いものでもあった。

PJが終わってからどうすればもっと上手くレビューをお願いできたのか?と思い、社内のエンジニアに質問したところ次のようなコメントをいただいたので、次のPJの糧にしようと思い残しておく。

1. 設計レビュー会を開き、チーム外の人を巻き込む

新しい技術セットを導入するとコードレビューのハードルがグッと上がるが、なぜその技術を導入したのか?全体のアーキテクチャがどう変わるのかなどを事前に設計レビューしてもらい、事前知識を持っておいてもらうことでコードレビューがしやすくなる。

また、レビュー会に参加してもらう人には後々PRが投げられた時にレビューしてもらうようにネゴしておくことも大事。

2. PRには変更の全体像をまとめたドキュメントのリンクを貼ってPRの位置付けを説明する

Design DocなりADRなりなんでもいいけど、チーム外の人がどのような変更を加えるのかをパッと理解できたり、深く知りたいときに非同期で理解できる状況を作ることが大事。特に複数のPRを出す時には、この変更が全体のうちのどこを指すのかがわかりやすくなっているとレビューしやすい。これがないとレビュワーが過去のPRを見て、必要な情報をピックアップして理解しないといけないので負担が大きい。

どうやったらチーム外の人を上手く巻き込んで、1人PJを上手く回せるのか、これからも勉強していきたい。