はじめに
どもどもマネーフォワードで技術広報をしている @luccafort です。 普段ぼくは技術広報として、さまざまなカンファレンスに参加しているのですが、 会社がスポンサーを行っている関係で参加するケースが多く、カンファレンスを純粋に楽しむケースが少なくなってきました。
今回のKaigi on Railsでは残念ながらブースの抽選から外れてしまったのですが、 それを逆手に取って、久しぶりにイチ参加者として純粋に楽しんできた参加レポートを書かせてもらいました。
ブログを書くまでがカンファレンス！と教わって育ってきたのでカンファレンスの帰りに新幹線で書き始めたのですが、 アウトラインの段階で1万字を超えてしまいました。 その後、推敲や添削を行っているうちに、公開タイミングを逃してしまいました。
今まさに #kaigionrails のブログのアウトラインを書きながら「こんなことあったな」「このときこう思ったんだよな」を書き足してるんですが箇条書きの段階ですでに1万字を超えておりヤバい。
— luccafort@技術書典17（く05）まねふぉ執筆部 (@luccafort) October 27, 2024
箇条書きではなく、過剰書きになってる。
最終的に何万字書くつもりなのだ……。
もちろん、ブース展示やカンファレンスの運営を担当するのも参加者とは違った楽しさがあるんですが、 タイトルにある通り「無責任に楽しんだ」カンファレンスは久しぶりだったのでログを残しておきます。
このブログを読んだ人がもっと技術やイベントを無邪気に楽しめるきっかけになれば幸いです。 カンファレンスやイベントに参加したことがない人はまず遊びにいってみようぜ！
Kaigi on Rails とは？
About Kaigi on Rails? Kaigi on Railsのコアコンセプトは 「初学者から上級者までが楽しめるWeb系の技術カンファレンス」 です。 Kaigi on Railsは技術カンファレンスへの参加の敷居を下げることを意図して企画されています。 また、名前の通りRailsを話題の中心に据えるカンファレンスではありますが、広くWebに関すること全般（例えばフロントエンドやプロトコルなど）についても扱います。 これからも参加者の皆さんにとって、日々の開発に役立つようなカンファレンスであるべく活動していきます。
Kaigi on Railsより引用
公式サイトが説明しているようにKaigi on Railsは「初学者から上級者まで楽しめる技術カンファレンス」です。 実際、参加して「RubyやRailsに限らずWeb開発で悩んでる人にもっとこのカンファレンスに参加してもらいたい！」と思いました。
特に、「RubyやRailsを使ってそれなりに開発を一人で進められるようになり、さらなるスキルアップを目指しているがどのようによりよいコードを実装すればいいかわからない」と感じているエンジニアの方々にとって、このカンファレンスは非常に有意義なセッション・トークが提供されたのではないかと思います。
My favorite Session Talks
ここからはDay1からDay2までに聴講したセッションの感想を記載させていただきます。 資料はruby-jpのCosenseで公開されたものを参照しています。
個人的ベストスピーカー賞
Kaigi on Railsではベストスピーカー賞のような表彰はしていません。 どのセッションも素晴らしかったのですが、その中から特に感銘を受けたものをピックアップしてみました。
大事なデータを守りたい！ActiveRecord Encryptionと、より安全かつ検索可能な暗号化手法の実装例の紹介
選出理由:
ActiveRecord Encryptionの名前は聞いたことがありましたが、 「使ったことがないので少し気になる」程度の関心度というのが正直な感想でした。少なくともこのセッションを聞くまでは。
このセッションではまず自分たちが開発している証券システムの説明を行い、 なぜ暗号化が自分たちの開発に必要か？という背景を丁寧に説明していました。 その後、実際にActiveRecord Encryptionの解説、使用例、ユースケースなどを説明し、 現状の課題や使いにくい点、Railsの暗号化のこれまでを踏まえたうえで、 「暗号化されたレコードをどのようにして検索可能にしていくか？」を解説しています。
不勉強なことにぼくはこのとき初めて「決定論的暗号化」という概念を学びました。 セッションでは具体的な事例とコードを元に解説してくれているため、とてもわかりやすく、楽しく学ぶ時間を過ごせました。
以下は実際にセッションを聞きながら取っていた自分用メモの抜粋（原文ママ）です。
- まず「決定論的暗号化」という概念をぼくは知らなかったのでそれが学べたことはとても大きなインプットになった
- 概念、機能紹介、実際に利用するユースケース、既存のシステムにあとから組み込む場合などさまざまなユースケースを想定されたとてもわかりやすいセッションだった
- 個人的に最も歯ごたえがあり、かつ知らなかったことを学ぶ機会につながった
- 正直なところ、機能紹介くらいの期待値だったのでその期待を大幅に超えてきてくれた。こういう思わぬセッションとの出会いがあるのでカンファレンスに参加することの意義がある
本当はセッション終了後に登壇者の方に話しかけたい気持ちもあったのですが、 セッションに対する感想は伝えられるがセッション中に感じた疑問の整理ができず、うまく言語化できなかったこともあり、諦めてしまいました。 また次のセッションへの移動などあまり時間的な余裕がなかったことも多少影響しています。
もし、別の機会でお会いすることがあれば、感想をお伝えするとともに（事前にActiveRecord Encryptionを触ったうえで）「ここはどう実装しているのか？」「こういったケースではどのように対応するのがベストか？」などの深い議論をさせていただきたいですね。 この機会を経てぼくの中で暗号化技術についておさらいする機運が高まっているので、社内勉強会などを開いてみたいなと思いました。 エンジニアとして「明日から試してみよう！」という新鮮な気持ちを思い出させてくれる、とてもいいセッションでした。
普段、カンファレンスに参加してもカジュアル面談に進んでみようと思うことはあまりないのですが、 今回のセッションを聞いているうちに事業もそうだし、技術的にどんなことをしているのかも気になりました。 残念ながら現職を離れるつもりはないのですが、Kaigi on Rails 2024を通して、 唯一「お話を聞きにいってみたい」と思える、とても印象的なセッションでした。
セッションが終わった後に「これを超えるセッションは会期中、基調講演以外でないのではないか？」と思っていました。 結果はベストスピーカー賞として選出している通りです、それくらい自分の中で印象的なセッションでした。
いまのところ、自分の中の #kaigionrails ベストスピーカー賞は昨日の基調講演の @palkan_tula とさっきActive Record Encryption の発表をした @free_world21 さんのどちらかかな。
— luccafort@技術書典17（く05）まねふぉ執筆部 (@luccafort) October 26, 2024
他のセッションもよかったけど自分の中ではとてもクリティカルヒットだった。
Data Migration on Rails
たまたまですが、自身が運営に関わるKyoto Tech TalkでDBマイグレーションの話を聞いたばかりだったので印象に残ったセッションでした。
Kyoto Tech Talkの詳細は過去に個人ブログで執筆した記事があります。 気になる方はご一読ください。
RubyでWeb開発をしているとだいたいRailsを使うことになると思いますが、
長く続いたサービスほどデータマイグレーションで一度は苦労したことがある人もいるのではないかと思います（本章内ではデータマイグレーションは一般名称、 data migration はセッション中に定義されたものを引用しているものとします）。
それ以外にもちょっとしたスクリプトを書き、データマイグレーションを使いたいケースがたまにあります。 データマイグレーションのためだけにORMやフレームワークを導入するのは少しToo muchな気がするという悩みを過去に持ちました。
これらの過去の経験や悩みがあったこと、前述した通り直近のイベントで関心を持っていたことも影響し、セッションを楽しみにしていました。 当日のセッションは開発するときの悩みを追体験していくような発表でとても興味深く、面白く聴講できました。
スライド内で紹介されていたRails Worldのセッションは知らなかったのですが、1 ソフトウェアエンジニアの責務が複雑化、専門分野の細分化が進んでいるという話はとても納得がいくものでした。 2
このような状態を打開するために、エンジニアの責務がシンプルになるようツールを開発するというあたりがDHHっぽくていいなと思いました。 と同時に、その複雑さの原因の一つにマイグレーションがあるという話はぼくの実体験とも一致しており、この話題に対する関心度が徐々に高まっていくのを感じました。
スライド16ページ目の「 data migration で起きがちな課題」に書かれたことを経験した人も多いのではないかと思います。
その課題に対して、ユースケースごとに5つの代表的なアプローチを紹介されていたのが印象的でした。
その中でも「専用Gemの活用」はこれまで経験したことがなかったのですが、どのような条件のときに選択するとよいかがわかりやすく書かれていてイメージがしやすかったです。
特に Rails に新しく導入された maintanance_tasks は、チームがある程度の規模になったときに欲しくなるような機能だと感じました。
この知見は社内にも持ち帰ることのできる「いますぐ使える技術」だなと思って聴講していました。
以前ぼくがエンジニアとして働いていたときは rails runner や rake で実行していたように記憶しています。
こういった知識は実際にプロダクトを日々開発していないと触るモチベーションが高まりにくいのでよいインプットができました。
各アプローチの選定に関しても、ポイントをしっかりと整理してくれているので「自分たちの場合はこうではないか？」を考えやすくなっていました。
本スライドを未読の方はぜひ一読されることをおすすめします。
入門『状態』#kaigionrails / "state" for beginners with Rails
エンジニアであれば一度は苦しんだことがある「状態」をテーマにしたセッションということで参加しました。 先ほどのData Migration on Railsと同様、自身が運営に関わっている Kyoto.rb で 「担当しているサービスの状態が複雑化している」が議題の1つに挙がりました。 そこで、Kaigi on Railsに参加できなかったメンバーに共有できそうだと思い、聴講しました。 自分はある程度理解できてるつもりなので、目新しい発見はないかなと思っていたのですが、全然そんなことはなかったです。
セッションを聴講した際の感想として、「状態」の問題は複雑さを表現する層がマッチしていないのではないかと疑問を持ちました。
例えば、セッション中に紹介されたLightBulb（電球）を例に考えてみます。
もし、電球をクラスで表現するとしたら
- 明かりがついているかどうかはBoolean型で表現できる
- 必要であれば
on?()のようなメソッドで表現も可能
- 必要であれば
- 明るさの比率は
brightness_ratio()が返すInteger型で表現できる- あるいはInteger型での表現が不足な場合はFloat型にすることも可能
- 人間が理解できるメッセージは再代入を必要とするString型ではなくメソッドで表現できる
- 状態にかかわらず
message()を呼び出すことで人間に優しい文字列を返せる
- 状態にかかわらず
- 通常、初期段階の「状態」を表すときは変数なのでクラスのような構造体で表現の幅が確保できる
- 仕様が追加、変更されたとしてもメソッドに切り出すことで影響範囲を限定できる、状態に対する処理を隠蔽できる
上記のような仮説を脳内で組み立てていました。 「状態」は変化しやすいデータ構造であることを考えると、 変数と型だけでは平易な層なので表現が難しいのではないかと考えたため、 クラス in クラスのような表現が行えれば解決しそうだと思いました。
一方で正直なところ、Too muchではないかとも考えていました。
電球がついてることだけを知りたい関心というのは現実のコードであり得るケースです。 ですが、「単にオン/オフだけが知りたいケース」や「明度も知りたいケース」がありえます。 これはソフトウェアが扱おうとするふるまいや関心次第で薄くも厚くもなり得るため、 正確にはToo muchになるケースもあると感じたというべきかもしれません。
いわゆる「早すぎる最適化」問題になってしまうケースとそうでないケースを見分けるために、 「自分がコードレビュアーならどのようなアドバイスをすべきだろうか？」という観点を、セッションを通して追体験させてもらいました。
本セッション内では「状態」のつらさをどうやって制御するか？という問いに以下の観点を持つとよいと発表していました。
- 可能な限りイミュータブルであることを保つこと
- 変化幅を限定的にすること（影響範囲を最小化する）
- シンプルに保つこと
初期段階から「状態」をオブジェクトにすべきかどうかは議論が生じるところでしょう。 複雑化しやすい「状態」だが果たしてメンテナンスコストが見合うのか？というレビューが書かれそうですね。 （実装の背景にもよりますが、自分なら指摘する可能性があると予測しました）
セッションを通して、より大事なのは「状態」をいつでもリファクタリングできる（変化に強い構造）に保つことなのかもしれません。 「状態」というよくある題材がゆえに、さまざまなものへと思考を広げられ、いろいろと考えさせられる点もあり、とても興味深く面白かったです。
特に新卒1〜3年目のエンジニアが過去のコードに苦しみ、「何故こうなってしまってるのか？」と疑問を持ちやすいのではないか。 そういった人たちが「状態」のあるべき姿を夢想し、議論を通して成長するのによい題材かもしれないと感じました。 また、自分自身も「状態」というものを改めて俯瞰し、「いまなら過去に書いたコードをどう実装し直すか？」を考えるよい機会になりました。
Identifying User Identity
弊社の場合、マネーフォワード クラウド勤怠のようなサービスを利用するユーザーの中には、 まさにこのセッションで指摘されたようなメールアドレスを起点として考えてしまうと問題になるケースがあり、 Kaigi on Railsの前週に社内で話題になっていたこともあり、聴講しようと参加しました。
User モデルに id と created_at だけのシンプルな状態にしてしまえばいいのでは？という設計はかなり思い切った設計だと思いました。
個人的には「検討しきれていない要因があるのではないか？」と少し疑念を抱きましたが、前職の際にCTOと似た議論をした内容と比較しても、大枠の方向性が合っていて、セッションを聞くうちにその懐疑的な気持ちは小さくしぼんでいきました。 過去にきちんとよい議論ができていたことを再認識しました。
講演後にSNSに投稿した内容に対して、リプライで「ユーザーと認証が紐づいてるのがよくないのではないか？」と指摘を受けました。
僕は認証とユーザーが密結合なのが良くないという理解ですねー。そこをくっつけるせいで、他のケースでログインする機能を作ると同一人物として扱わないといけなくてサービスが無駄な複雑性を持つと思ってます。
— Ryo HIGASHIGAWA (@biwakonbu) October 26, 2024
この指摘をもらい考えてみましたが、認証とユーザーが分割できるのなら複雑になりすぎず、
また、それぞれの責務ごとに User を定義しやすくなりそうです。
認証基盤としての一意な値とサービス上のふるまいとして定義された User を分離することができれば、
より設計になりそうに思いました。
見落としている点もあるかもしれませんが、なかなか悪くないように思っています。
閑話休題。
サンプルコードなどでよくある User というモデルにまとめてしまうとアクセスは容易になりますが、責務ごとのふるまいやあるべき姿としての設計は歪むことがあります。
逆に設計として正しく切り分けても使いにくいモデルが生まれてしまっては開発チームから嫌厭される可能性があります。
自分たちにとってどれが最適解であるかを検討し、どうすると変更容易性が保たれるかを考えることが大事なのかもしれません。
かつて、過去に働いた会社で開発したソーシャルゲームではリセマラ 3 対策としてチュートリアルを完走したときに初めて User にデータ登録し、
それまではチュートリアル専用 User を別テーブル（正確にはRedis）に保存していましたが、あのときの設計や実装は理にかなっていたことを10年ぶりくらいに実感しました。
反省点
カンファレンスを精一杯楽しんでいたのですが、一方で反省すべき点も見つかりました。
社内の参加者を増やす活動ができていない
一番大きな反省点は、運営スタッフ2名を除けば、現地に参戦していた参加したエンジニアがぼくだけだったことです。 4 これは少し寂しい結果だと感じています。
カンファレンスやスポンサーはさまざまな外的要因、内的要因によって、急になくなることがあります。 たとえそのような状況であっても「このカンファレンスにはスポンサーする価値がある」と主張できる一番わかりやすい指標の一つは、多くの社員が参加しているという事実です。
社内の新卒1〜3年目のメンバーに声をかけてみる、イベントに興味がありそうなメンバーにアプローチしてみるなど自分がやれることがあったと後から思いました。 そういった意味では社内への呼びかけもそうですが、社内のエンジニアが何に興味を持っているのか把握できていなかったと反省しています。 あるいは後述する社内制度を知らず、参加を諦めていたメンバーがいたかもしれません。 改善すべき課題が見つかったことを次回に活かしたいと思います。
スポンサーは一度決めたらずっと協賛し続けるわけではありません。 予算の都合や自社の技術ポートフォリオの変化、エンジニア採用の潮流などさまざまな影響を受けます。 会社としてはさまざまな思惑（採用目的やエンジニアの支援など）からスポンサーすることを決定しています。 なにせ、会社のお金は有限ですからね！
個人的な考えですが、スポンサーの大きな目的の1つは「社員のワークエンゲージメントを向上させること」です。 そのためには、より多くの社員が参加しているカンファレンスに対して支援をしたいと考えています。 5
まずは社内からそういった機運を高めていかなければ！と気持ちを新たにしました。 来年のKaigi on Railsでは「マネーフォワードの人、いっぱい参加してるね」と言われるような、そんな状態にしたいと考えています。 好きな技術のカンファレンスに参加し続けるためにも、プロポーザルを出す、登壇する、カンファレンスに参加するの3点を強化していきたいと思います。
心残り
Kaigi on Rails 2024会期中に知り合った @cornpope_ajatt さんにアフターイベントにお誘いいただいたのですが、 次の予定があり、泣く泣くお断りすることになってしまったので次回どこかでお会いした際にはぜひリベンジをしたいと思います。
今回、とても心残りになってしまったのは @cornpope_ajatt さんが「今から銀座に行くんだけど行かない？」と誘ってくれたんだけど次の予定があって行けなかったので絶対にリベンジしたい。
— luccafort@技術書典17（く05）まねふぉ執筆部 (@luccafort) October 27, 2024
あと #rubyfriends し忘れてしまった。
#kaigionrails
まとめ
その他にもたくさん面白い講演がありましたが、このままでは終わりが見えそうにないので、そろそろまとめに入ろうと思います。 オススメセッションの中にあえてDay1/Day2の基調講演を含めませんでした。
これは後日公開されるアーカイブ動画とスライドをセットで見てほしいと思ったからです。 ぜひどこかのイベントで講演を見た感想をお話しさせてもらえればと思います。
今回マネーフォワードはKaigi on Rails 2024にシルバースポンサーで協賛させてもらいました。 イチ参加者としてブース展示や登壇のことを気にせず、楽しむことができました。
RubyKaigiやKaigi on Railsはマネーフォワードにとって重要なカンファレンスです。 来年、参加者が少ないことを理由にスポンサーしないことになってしまう、そのような悲しいことにならないためにも、 社内のRubyistが参加したくなるような企画を考えていきたいと思います。
マネーフォワードで働く人へ業務連絡
最後に業務連絡です。 マネーフォワードには国内カンファレンスに参加する方を支援する社内制度があります！
できるだけ多くのマネーフォワードのエンジニアに参加する機会を提供することを目的とした素敵な制度で、年に一度、エンジニアが参加するカンファレンスにかかる費用（チケット代、交通費、宿泊費）を会社が負担してくれるというものです。 マネーフォワードでは技術スキルと知識共有のため、カンファレンスの積極的な参加を推奨しています。
今回の件で「意外と知られていないかもしれない」と気付いたので、もし気になる方は社内Slackで相談してください。
社内ドキュメントに条件などをまとめているので、URLを共有させてもらいます。
宛先は @luccafort まで。
- Practical The One Person Framework↩
- Rails World 2023 Opening Keynote - David Heinemeier Hansson↩
- リセットマラソンの略。初回のガチャや無料で配布される配布アイテムが自分の期待どおりになるまでインストールとアンインストールを繰り返す行為。↩
- 認識している限りではスタッフ2名、参加者1名（自分）のはずです。オンライン参加者はもっといると思います。↩
- 一般的に社員が参加しないカンファレンスのスポンサー協賛は打ち切られる可能性が高くなります。社内にいるRubyやRailsが好きなメンバーをもっと探し、声をかけていく必要があると痛感しました。↩
