先日「Kaigi on Rails 2022」に登壇した三谷さんと大庭さんに、それぞれの登壇内容の裏話や印象に残った発表について伺いました。今回は、そのPodcastの書き起こし内容をお届けします。
↓Podcastはこちらから smartbank.co.jp
- プロフィール
- はじめに
- 7つの入金外部サービスと連携して分かった実践的な”状態管理”設計パターン3選 by 三谷さん
- Balance Security and Usability in the Field of 3D Secure by ohbarye
- Kaigi on Rails 2022で印象に残った発表内容
- あとがき
プロフィール
三谷 昌平(@shohei1913 )
サーバーサイドエンジニア。これまで、決済/入金機能等を中心に開発。 PodcastではKaigi on Rails 2022で発表した『7つの入金外部サービスと連携して分かった実践的な”状態管理”設計パターン3選』について語りました。
大庭 直人 (@ohbarye)
サーバーサイドエンジニア。これまで、月間まとめ/出金/3DS機能等を中心に開発。 PodcastではKaigi on Rails 2022で発表した『Balance Security and Usability in the Field of 3D Secure』について語りました。
堀井 雄太 (@yutadayo)
CTO兼サーバーサイドエンジニア。 Podcastではファシリテーション/聞き手を務めました。
はじめに
[雄太さん] こんにちは、スマートバンクでCTOをしております堀井雄太と申します。SmartBank.fmは、家計簿プリカ「B/43(ビーヨンサン)」を運営するスマートバンクが提供するPodcast番組です。
先日開催された「Kaigi on Rails 2022」に弊社メンバーの大庭さんと三谷さんが登壇されたので、今日は2人をゲストに招いて登壇内容やイベントを振り返る会としてポッドキャストを実施したいなと思っております。
2人はなんと2年連続でこのイベントに登壇していますが、参加されてどうでしたか？
[三谷さん] 2年連続で事前収録の開催だったので、当日は発表するドキドキよりは、うまく映るかなというドキドキとか、オンエア待ちみたいな気持ちを楽しめましたね。
7つの入金外部サービスと連携して分かった実践的な”状態管理”設計パターン3選 by 三谷さん
[雄太さん] では、個別に登壇について振り返っていければと思うのですが、最初に三谷さんから挨拶と登壇内容について説明をお願いします。
[三谷さん] スマートバンクでサーバーサイドエンジニアをしている三谷といいます。社歴は2年半くらいです。スマートバンクの3人目のサーバーエンジニアとして、入社してずっとRailsを触っています。
主に決済や入金、管理画面などを扱ってきたのですが、今回そのあたりの実装経験から、「入金外部サービスを使うときの状態管理」についてお話させてもらいました。「B/43」だと入金が7種類あって、その全てで外部サービスを使っているので、その実装で得た学びを今回話したいなと思って登壇しました。
[雄太さん] 「B/43」はかなり入金の種類がたくさんあるので、それぞれに実装の難しさや特性があって、そのあたりをうまくまとめていただいた登壇内容だったかなと思います。
テーマを選んだ理由
[雄太さん] 今回のテーマを選んだ理由はありますか？
[三谷さん] このテーマが話したくて「Kaigi on Rails」にプロポーザルを出したというより、「Kaigi on Rails」にとりあえず登壇しようと思ってテーマを考えていた形です。プロダクト開発の中でエンジニアがチームをリードする話や、30万ダウンロードを超える中で発生したインシデントの対処方法などいろいろ考える中で、一番プロポーザルを書きやすかったのが入金の話だったので、これを選びました。
入金の開発の思い出
[雄太さん] 入金方法がたくさんある中で三谷さん自身が実装した入金の開発で、特に思い出深かったことはありますか？
[三谷さん]
スマートバンクに入って一番初めて作った機能が振込入金用口座だったと思うのですが、一番初めが一番イレギュラーで完全非同期で作るパターンだったので、実装するときはいろいろ悩みました。
ただ前職のラクマでも決済チームで決済まわりを触っていて、スマートバンクでもその知識や気を付けるポイントなどを活かして実装しているので、入金機能については結構慣れてきましたね。
[雄太さん] 過去の経験からの知見も今回まとめて発表できたのですね。
[三谷さん] そうですね。パターンとしてまとめてみると、自分でも結構学びがあって。今まで感覚的にやってたけどこういうことだよねと改めて文章化できたので、すごく良かったなと思いますね。
[雄太さん] テーブル設計例も載せていたので、参考になった人もいるかもしれないですね。
発表で工夫したポイント
[雄太さん] 発表自体についても工夫したポイントがあれば聞かせてもらえますか？
[三谷さん] 一番頑張ったのは動画編集ですね。事前収録で動画編集にかける時間を取ることができたので、結構力を入れました。去年は15分間の登壇だったので一発録りでいけたのですが、今年は私は30分間だったので一発録りは失敗してしまうと思っていて。ライブであれば気にならないのですが、事前収録だと失敗したところが目に見えて分かってしまうので、うまく編集して切り貼りするのを結構頑張りましたね。
[雄太さん] 当日は全員で放送を見守る会をやりましたが、動画編集のクオリティが高くてみんな驚いてましたよね。
[三谷さん] 工夫点としては、去年は動画見たときに全然元気がないなと思ったので、今回座らずに立って話すことで元気感を出したりとか。資料があんまり動いていなくて見にくいと思ったので、資料を1回作り直してパワポに動きを持たせるとか。そのあたりで結構時間がかかりましたね。
[雄太さん] アニメーションも細かく作り込みされていたので、すごい見やすかったですし、努力が滲み出て見えましたね。
[三谷さん] YouTuberのエンジニアの解説系動画も結構見ていて、こういう感じで動画編集したら聞き手からすると分かりやすいんだろうなとか考えたりして。
あと字幕のテロップも入れようかなと思ったのですが、さすがにやりすぎだと思ってやめましたね（笑）。でも動画を撮って編集してイベントに登壇するスキル自体が結構上がってる感じはあります。
話し足りない部分や割愛した部分
[雄太さん] 30分という長い時間の登壇内容だったと思うのですが、それでも話し足りない部分や割愛した部分があれば、ぜひ聞いてみたいです。
[三谷さん] 今回は初心者向けのテーマで作ったので、状態管理をするときにステータスのカラムを持たせるべきなのか、イミュータブルのデータモデルのようにテーブルを分けるべきなのか。イベント駆動型のようにイベントだけを記録していく感じにしてアップデートをできるだけなくした方がいいのか。などの議論は立ち入ると深くなるので削りましたね。
反響
[雄太さん] なるほど。発表内容について、何か反響はありましたか？
[三谷さん] 資料がいいとか、体系的にまとまっていてよかったとTwitterにあげてくれてる方がいらっしゃって嬉しかったです。
[雄太さん]
入金サービス自体があるサービスはそんなに多くないかもしれないですけど、同じような事例として決済の部分は他のサービスでもあるかなと思うので、結構参考になった人がいたんじゃないかなと思いますね。
[三谷さん] そうですね。「B/43」だと入金という言い方ですが、普通のECサイトの決済の仕組みを作っていることとほぼ同じことをやってるので、ECサイトを作ってる人には親和性があったんじゃないかなという気はしますね。
他には、完全非同期型という「外部のサービスからいきなりリクエストが来て入金が完了する」というパターンについて、そういったWebhookのものは冪等性を保つことが結構大事なのでそのやり方をTwitterでコメントくださってる方もいらっしゃいました。そのあたりには、困っている人も結構いると分かって面白かったですね。
[雄太さん] Webhookが飛んできて処理が完了するのは、ベンダー使ったときには一般的かなと思うので、そういう方の参考になるのはいいですね。
[三谷さん] そうですね。リトライ処理どうするかは作っているときは結構抜けがちなポイントで。運用しだすとエラーが起きてリトライ処理が不十分だったということが結構あると思うので、そういう落とし穴についてもパターンとして紹介できたのはよかったかなと思います。
[雄太さん] うっかり二重でインサートの書き込み処理をしてしまって2回チャージすることなどは避けたいので、冪等性を作るところは押さえておくべきポイントとしてありますもんね。
[三谷さん] そうですね。特にお金を扱っていると、データベース書き込みが起こってしまったら戻すのがすごく面倒くさいので、いかに事前に考えていくかは大事ですね。
実装のエピソードから盛り込んだもの: リコンサイル
[雄太さん] 登壇通してそういった実装からの知見を発表しているかなと思いますが、他に実装のエピソードから盛り込んだものはありますか？
[三谷さん] リコンサイルという仕組みについて紹介しました。WebhookやAPI連携のときに、外部サービス側にデータがあるけれどこちら側で処理に失敗したときやAPIリクエスト自体が来ないときに、自社側と外部側で日時のバッチでデータ整合を確認して取り込む仕組みについてです。
[雄太さん]
実際どういう実装になっていて、どんなシーンで活用されているのでしょうか？
[三谷さん] 外部サービス側に今日の入金履歴一覧を取得するAPIがあり、そこから履歴を全件取ってきて自社側のデータベースの履歴とマッチングさせて、取り込まれていないデータがないかをチェックする形です。そこで取り込まれていないデータがあったら、その分を取り込んで不整合を解消することをやっています。
[雄太さん] 非同期でベンダーさんのデータと我々のデータベースを同期させるバッチが動いてる形ですね。
[三谷さん] そうですね。基本的にデータ不整合はあまり起きないのですが、例えば長期メンテナンスで8時間くらい止めてしまうと、一定期間受け取れていないので最終的にデータをロストしてしまうんですよね。外部サービス側のWebからリトライするとしても、最大5時間までしかできないような仕様があるとロストしてしまうので。そういうときにリコンサイルの仕組みがあると、メンテナンス終わった後にそのバッチさえ動けば自動で回復してくれるので、メンテナンスもやりやすくなりますね。
[雄太さん] なるほど。確かにこちらの都合でデータを書き込めないシーンもあると思うので、実装時点でそういうシーンを考慮に入れて設計されていて、バッチが実行されて担保できるとかなりサービスとして堅牢なのでいいですね。
他には何か頂いたコメントに対して返されたものなどありましたか？
Webhookが送られたときの冪等性
[三谷さん] Webhookが送られたときの冪等性の守り方について返しましたね。他社さんだとIDがなくて冪等性が保てないことがあるようなのですが、うちの場合は入金IDがリクエストの中に含まれるので、2回目以降はそのIDで取り込んだかどうかをチェックする仕組みにすることで冪等性を保っています、と。
[雄太さん] たしかに、ユニークなIDがないと冪等性を担保するのは結構難しいですよね。ありがとうございます。大庭さんからも何か三谷さんに聞きたいことはありますか？
スライドのきれいな見せ方やコツ
[大庭さん] 反響の中に「三谷さんのスライドがすごいきれい」というコメントがあって、僕もスマートバンク社に入ってエンジニアの皆さんのスライドがすごくきれいだなと思っているのですが、そのあたり工夫している見せ方やコツはありますか？
[三谷さん] 一つは、そもそも雄太さんが前に創業したFablicという会社も今のスマートバンクも、発表のスライドテンプレートをデザイナーが初めから作ってくれているので、ベースとしてかなりきれいなものができます。
他には、文字はできるだけ使わないようにしたり、色の使い方は結構気をつけてたりしていますね。「B/43」のアプリは、アイコンやマイカードの色、ペアカードの色があるので、それをうまくスライドの中に使えばきれいな色として見せられるのではないかなと考えて作ってみました。
お金を扱うシステム
[大庭さん] ありがとうございます。もう一点、こういった今回の発表内容のように「お金を扱う」システムは苦手な方も結構いるかなと思っているのですが、三谷さんはそういう部分は好きですか？
[三谷さん] 結構好きかもしれないですね。お金って危険そうな感じと思われるかもしれないですが、中身の実装のコードは何も特別なことはしていなくて。
基本的なWebサービスのデータを保存するステップと同じことしかやっていないんですよね。ただし少しでも狂ったら困るので、保険のためのコードをいろいろ入れます。
先ほど紹介したリコンサイルの仕組みや監視の技術を身につけながら、その周辺のところを広げて考えていくので、そういう部分を実装するのは自分は結構好きですね。
blog.smartbank.co.jp ※ 2021年度の監視をテーマにした三谷さんの登壇内容
[大庭さん] なるほど。やっていることはお金に関わる関わらないを問わないWeb開発の基本だけど、幅広く深いスキルが求められるイメージですかね。
[三谷さん] そうですね、結構総合格闘技に近いですよね。ベースのコードを書く技術と、周辺の仕様をしっかり考える技術といろいろまとめて身につけることができるので、その点でもいいかなと思います。
もう一つ言うと、入金や決済って使われたことが数字で分かりやすいじゃないですか。「何万円入金されました」とか。逆に、障害起きたときに「何十万損しました」とかも分かります。そういう意味で気持ちが張り詰めますし、やっていてやりがいを感じやすい分野でもあると思いますね。
[雄太さん] いい感じの緊張感と数字が伸びたときの達成感と両方味わえるって感じですかね。ありがとうございます。それでは、三谷さんのパートはこちらで終了して、大庭さんのパートに移っていければと思います。
Balance Security and Usability in the Field of 3D Secure by ohbarye
[雄太さん] 大庭さん、自己紹介と今回の登壇内容についてお話いただいてもいいですか？
[大庭さん] 改めて大庭と申します。インターネットではohbaryeというアカウント名で活動しています。スマートバンクに入社したのは2年ちょっと前くらいです。
2020年に前職を辞めて少し無職をしていたのですが、その時にCTOの雄太さんに声をかけてもらって入社しました。インターネットで「仕事募集しています」と公開したら、雄太さんが1番目か2番目くらいにすごい速度でメールをくれてカジュアル面談をした流れでしたね。
[雄太さん] そうでしたね、即レスした記憶はありますね。
[大庭さん] もともと以前僕が働いていた会社と、雄太さんたちの会社のFablicで一緒に勉強会をやっていて。そのときの繋がりもあって「今は別の会社をやっているんだ」と知ったので、そういう繋がりは大事だなと当時すごく思っていました。
入社してからは、サーバーサイドエンジニアとしてAPIの開発や管理画面の開発を中心にやっている形ですね。ここ2年くらいはRuby 9割、Go 1割くらいの気持ちで書いています。
今回の発表内容は3Dセキュアという、クレカ業界やカード決済に関わっている人は知っているけれど、そうじゃない人からすると名前は聞いたことあるけどよく分からないようなものを掘り下げる発表をさせてもらいました。
具体的には3DセキュアはECサイトでカード決済をするときに本人認証が求められる仕組みのことです。パスワードを入れたり、OTPを入力したりする仕組みの裏側がどうなっているのか。スマートバンクでは僕が3Dセキュアを実装したので、その過程で学んだ知見を共有しようと思って今回発表しました。
[雄太さん] 3Dセキュアって聞いたことのある人は結構いるかなと思うのですが、実際にカードを使ったときに裏側に走っている処理やどんな実装になっているかはそんなに知られていないので、発表内容としてもかなりユニークな発表になったんじゃないかなと思っています。
テーマを選んだ理由
[雄太さん] 前回から続いてプロトコルを選んでいると思いますが、いろいろなお題がある中でこれを選んだ理由はありますか？
[大庭さん] 3Dセキュア関連の開発をしたと先ほど申し上げたのですが、開発した後に「同じようなことをやってる人が国内にどれくらいいるのかな」と思ったんですよね。
カード決済に関わっている人自体がそれなりの数いるのか少ないのか分からないですけど、その中で3Dセキュアに関わっていてRuby界隈…って限定したときに、ひょっとしたら僕しかいないんじゃないかなという気持ちになりました。
Kaigi on Railsという機会で「この界隈で自分しか持ってなくて公開できる知見は何だろう」と考えたときに、3Dセキュアは面白いんじゃないかなと、ぴったりはまった感じでした。
[雄太さん] 確かにRubyistで3Dセキュアの実装をしたことがある人って、本当にいないんじゃないかと思いますね。
[大庭さん] 発表後に「自分も3Dセキュアの実装したことあります」という人が現れるかちょっとドキドキしながら見ていたんですけどいなかったので、狙い通りだったかなと思いますね。
付け加えると、カンファレンスのプロポーザルはニッチで希少性が高いものが狙いどころかなと個人的に思っていますね。Kaigi on Rails自体が、Railsに関係ない話でもウェルカムという懐の深いイベントだったので、そういうところも採用された理由の一つかもしれないです。
3Dセキュアを実装した業務
[雄太さん] 私も3DセキュアとICカードのプロジェクトで一緒に関わりながら開発させていただいたんですけども、実際3Dセキュアを実装した業務について聞いてもいいですか？
[大庭さん] あるカードで3Dセキュアが使えるかどうかは、カード発行会社の持っているBINと呼ばれる先頭N桁の番号のグループごとに決まります。2022年の6月にスマートバンクがリリースしたICカードが属するグループにて3Dセキュアを対応させるために、そのための登録を国際ブランドであるVISAに申請しました。
システムが3Dセキュアに対応するとカード決済するときにオーソリのさらに手前の段階で、本人認証のリクエストを受け取ることになります。そのとき「B/43では認証手段としてSMSとメールとプッシュ通知が使えますよ」と3択の選択肢をレスポンスで返します。ユーザーが手段を選択するとユーザーに送るべきOTPが送られてくるので、それをB/43システムからユーザーに送信する。そういった外部サービスのインテグレーションの部分を具体的に開発しました。
[雄太さん] 実際オーソリ自体は前からあって、その前段階で3Dセキュア認証のシステムを作っていただいた形ですね。
[大庭さん] そうですね。オーソリ部分も少し手を入れた部分があって、3Dセキュアで本人認証を失敗したのにも関わらずオーソリを送ってくるよくない加盟店もあって、それを弾く機能も実装しましたね。
[雄太さん] オーソリの方でもお行儀が良くないデータをちゃんと弾くところを実装されたんですね。
発表の工夫ポイント
[雄太さん] 発表の工夫ポイントは何かありましたか？
[大庭さん] そうですね。反響として触れていただきましたが、今回動画で登壇するんだったらできることをいろいろやりたいなと思って編集を頑張りました。
三谷さんがおっしゃっていたような形でなるべくアニメーション入れたりだとか、見た目の綺麗さにこだわったりだとか、あとは喋り間違いを撮り直したりとか。僕も2日間ちょっとかけていましたね。評価いただいたオープニングテーマも、4〜5時間くらいかけて作りました。
[雄太さん] 「3Dセキュア〜♪」が耳に残ります（笑）。
[大庭さん] 何かの教育番組で使われるようなジングルをイメージして作っているので、耳に残ると言われるのはすごい嬉しいですね（笑）。
[雄太さん] しかも切り替えポイントでちょいちょい流れるので、その度に笑いも起きるというか。
[大庭さん] そうですね。30分の発表を聞くのはやっぱり聞き手側も結構疲れるかなと思っていて。僕の発表内容は基本的に聞き手にとって馴染みがないものなので「どれだけ自分事として捉えてもらえるか」「前のめりの姿勢で聞いてもらえるか」を考えていました。もちろん発表の話し方や内容で工夫した部分もあるんですけど、ちょっと飛び道具的なアプローチで「この発表、もしかしたら面白いんじゃないかな」と興味を引き、最後まで発表を聞いてみたら実際に「3Dセキュアの内容が面白かった」というステップを踏んでもらえるといいなとイメージしながら作りましたね。
[雄太さん] 素晴らしいですね。実際、3Dセキュアの歴史から入って、プロトコルの紹介、実際の運用と分かれているところの繋ぎ目としてもうまく機能してたんじゃないかなと思いますね。
もっと盛り込みたかった部分: チャージバック
[雄太さん] 大庭さんも30分枠で発表いただきましたが、それでももっと盛り込みたかった部分はありましたか？
[大庭さん] そうですね。時間あればというところでいうと、先ほどもお話したような実装面の話ですね。外部サービスとインテグレーションして……という部分は入れようと最初思っていたんですが、少し時間オーバーしちゃって削りました。その他はチャージバックの話もしようかなと思っていましたね。
[雄太さん] なるほど。チャージバックについてはリスナーの方が知らないかもしれないので、少し解説いただいてもいいですか？
[大庭さん] 基本的には、不正利用が起きたときに誰が責任を取るかという話だと考えていただければと思います。例えば、自分がクレジットカードを持っていて身に覚えのない明細がある日突然現れたとします。全然知らない海外の加盟店で10万円使われていたときにカード会社に問い合わせて「自分の決済ではありません」と言います。そうすると、大抵の場合は被害者に対して不正利用の補償がなされます。そのときに、カード会社なり加盟店なりのどっちが責任を持つかという責任分担のところで、各社が3Dセキュアに対応してるかどうかが関わってくるんですよ。
どういうことかというと、基本的に不正利用額を攻撃者から取り立てたいのは山々なんですけど、現実的にはそれがすごく難しいので、カード会社か加盟店かが負担することになるんです。その時にカード会社もしくは加盟店がどれだけ不正を減らすために努力していたのかを考慮して、努力が不足していた方に支払ってもらうことを判断するわけです。その悪い方を決定するときに、3Dセキュアをちゃんと導入して、ユーザーに対して認証を行っていたかが観点の一つとして盛り込まれてきます。
なので、3Dセキュアに対応しないと加盟店もカード会社も損する可能性があるんですね。3Dセキュアに全然対応しないまま不正が起き続けてるお店があったとすると、そのお店は不正に対しての補償をし続けなければいけない。これはお店としてもビジネス的に望ましいことではないですよね。そうなると、3Dセキュアをちゃんと導入して、不正が起きたとしても自分たちがお金を払わずに済ませたい、ビジネス的な損失として計上されないようにしたいとなります。こうやって国際ブランドのVISAやMastercardはお店側もカード会社側も正式導入するように経済的なインセンティブを与えてるんです。…という話も結構面白いなと個人的には思っているんですけど、15分オーバーしていたのでやむなく削りました。
[雄太さん] 実際3Dセキュアを導入していたらチャージバックのリスクは負わなくていいというところは、カード会社では一般的に知っていることかもしれないけど、実際日々決済している皆さんからするとどこから補償されるか分からないと思うので、盛り込んでも面白い内容ですね。
反響や質問
[雄太さん] 発表のときに何かTwitterでの反響や質問はありましたか？
[大庭さん] そうですね、コメントが一番きたのは歌ですね（笑）。
[雄太さん] 歌ですか！やっぱりすごいインパクトありましたしね。
[大庭さん] 始まったときに #kaigionrails ハッシュタグの流速がちょっと速くなって「！？」みたいなコメントが流れていたのを見て「やったな」と思っていたんですけど。ただ、そのあとに「歌のインパクトで僕の導入部分の内容があまり頭に入ってこなかった」と社内でフィードバックがあって、間の作り方などもう少し研究の余地があったなと思いました（笑）。
[雄太さん] 想定通りだった部分もあれば、ちょっとインパクトが強すぎて、もうちょっと間を空けてから発表入った方がよかったかもしれないって感じですかね。
[大庭さん] そうですね。本題の3Dセキュアについては、「知らなかった」というコメントはすごく多かったんですけど「知らなかったけど面白かった」というツイートを何個か見つけることができて、それは非常に良かったですね。
[雄太さん] 確かに。知らない知見をみんなで共有できたのは大きかったかもしれないですね。
[大庭さん] 動画作ってから公開されるまで、本当にこれ面白いのか？と猜疑心に悩まされることもありました。知らないことを発表するから面白いという見方と、知らないから興味も持たれず、平日の発表だから業務と比較したときに優先して見るほどのものじゃないとスルーされちゃう、ってこともあるなと思っていて。ポジティブな反応があってよかったですね。
[雄太さん] なるほど。私もリアルタイムで一緒に見ていたんですけど、やっぱり歴史の解説があるのが一つ大きいポイントだったかなと思っていて。今まさに3Dセキュアの1.0から2.0の移行期で、そもそも1.0から知らない間に2.0に変わっている体験をしているという。前提で歴史を知っているのと知らないのとでは見方違ってくるかなと思うので、そこがかなり良かったのかなと思ってますね。
[大庭さん] ありがとうございます。あとは反響とはちょっと違うんですけれども、個人的に見て嬉しかったところがあってですね。
Kaigi on Rails運営のunasukeさんという方がブログを書いてくださっていて。そこでKaigi on Railsへの熱いモチベーションや想いが書かれていたんですが、「Kaigi on Railsを今後も広くWebに関すること全般を扱うカンファレンスにしていきたい」というお話をされていて。その中で、僕が昨年発表したIdempotency-Key Headerの発表について触れてくれていたんですよね。
今年の発表内容もまさにその意思に沿うような形になったのかなと思っていて、そこは個人的には結構追認されたというか、こういうのがあってもいいんだみたいな気持ちになれたのは非常に良かったですね。
[雄太さん] 確かにRailsやRubyの内容はそんなに多くは出てこなかったかなとは思いつつも、Web界隈の人に広く知っておいてもらいたい知識のような文脈のコーナーとしてはかなりユニークで、イベントの趣旨自体にも沿ってるのでよかった発表だったんじゃないかなと僕も思います。
[大庭さん] 他の方も、実装じゃなくて運用についてお話する人も多かったかなと思うんですけれど、そういう文脈でいろんな話が聞けるっていうのもKaigi on Railsの魅力かなと思いますね。
カンファレンスにプロポーザル出すときのモチベーション
[雄太さん] ありがとうございます。三谷くんから大庭さんに質問はありますか。
[三谷さん] そうですね。今回の発表内容というより全般的な話になってしまうんですけど、大庭さんは2年連続Kaigi on Railsに出つつ、その前もRails Developers Meetupでファクトベースの話をしていたじゃないすか。カンファレンスにプロポーザル出すときのモチベーションは、どういうときにわくのかなと個人的にちょっと気になっていて教えてほしいです。何で出たくなるのか、外に向けて発信したくなるのかとか。
[大庭さん] なるほどですね。さっき話したように、今回は自分が一番この分野に詳しいから話したいというモチベーションがあったんですけど、それは僕の中で結構特殊なほうですね。僕はテックイベントがあるときに自分でアウトプットできるものがあるかどうかを内省することが多いんです。ずっと沈黙してて自分から外に発信するものが何もないと自覚すると、自分は何か学んでいるんだっけという気持ちになってしまう。
あとは、そういった内省する部分に加えて、アウトプットするとフィードバックがたくさん来るという体験を1回やるとやめられないかなと思っていてですね。今回も良い反響をもらったりとか、面白かったと言ってもらえると、やってよかったなと思うんですよね。作っている間は何でプロポーザル出してしまったんだろうという気持ちにもなるのは、皆さん体験するかなと思うんですけど（笑）。
実際に出してみると皆さんがフィードバックをくれたりとか、より詳しい人がより有用な情報を教えてくれたりだとか。そういう形で普段の業務から得られない交流があるといいなと思って、プロポーザルを出していますね。
登壇の形式
[三谷さん] ありがとうございます。もう1つ別観点で、今回動画を事前収録する形だったんですけど、自分的にはすごくいいなと思っていて。来年以降Kaigi on Railsをリアルかハイブリッドで開催する話もありますけど、もしそのときプロポーザルを出したら、大庭さん的にはリアルで登壇したいか動画編集またやりたいかどっちがいいですか？
[大庭さん] そうですね。ここ数年リアルタイム登壇をやっていなくて勘がすごい鈍っている感じがするので、その勘を取り戻すためにリアルタイム登壇したいなっていう気持ちと、動画で見たらこの人面白かったけどリアルタイムで見たらつまらない人だなと思われる可能性が天秤にかけられてますね。やっぱり動画だからこそできる工夫はまだまだあるかなと思うので、そのときの気持ち次第かなと思います。今回は事前収録したものを会社の会議室でみんなで見ましたけど、ハイブリッドだったら当日そこに行くかどうかめっちゃ悩みますね。
[雄太さん] 確かにそうですね。動画をみんなでワイワイ見る体験は、今回の動画だからこそできた感じですもんね。ハイブリッドで自分が事前収録したものをリアル会場で見ると、どういう気持ちになるのかな（笑）。お二人ともありがとうございました。
Kaigi on Rails 2022で印象に残った発表内容
[雄太さん] 2人いろいろお話をお伺いできて良かったです。ありがとうございます。最後に、ぜひ気になった他の方の登壇について取り上げてお話できればなと思うんですけど、2人から他の方の発表を聞いていて、気になったところはありましたか？
メタプロやポリモーフィックの使いどころ
[三谷さん] そうですね、全般的に全部面白かったんですけど、テーマとして面白いと思ったのはメタプロやポリモーフィックの話ですね。うちでも管理画面のユーザーページや決済一覧のページで詳細に対してコメントを残す機能があるんですけど、そこは汎用的に作る形としてポリモーフィックで実装していて。
ただ、ポリモーフィックって入れた方がいいところと入れちゃいけないところがあるじゃないですか。そのあたりは他の方の発表を聞くことで改めて考えることができて良かったです。
メタプロも同じ話で、やりすぎるとコードが複雑になりすぎて保守できない状態になるんですけど、部分的にはあった方が実装がシンプルになる部分もあります。そのバランス感覚を知る上でも他の方の登壇を聞くと勉強になってよかったですね。
[雄太さん] クックパッドNatsuko Nadoyamaさんの「森羅万象に『いいね』するためのデータ構造」という登壇でポリモーフィックのお話ありましたね。最初はストイックにテーブルを作ったんだけど、これを1回ポリモーフィックに置き換えたというところで。サービスの成長に合わせて変えていくところが話の肝だったのかなと思っていました。
我々もそういう風に実装するパターンもあれば、逆にポリモーフィックを直していくと登壇された方も確かいらっしゃったと思うので、そのサービスの特性によってどっちにしていくかは見極めながらやっていく必要あるなと思いましたね。
[三谷さん] そうですね。Webサービスは本当に生き物なので、ユーザー数や運用する年数、コードの量によって、適切な設計が変わってくると思うので、この2つがあったのはすごいいいイベントだったなと思いますね。
[雄太さん] そうですよね。データのマイグレーションするのは大変だなと思いながら見てました。
モジュール化・アーキテクチャ
[雄太さん] 大庭さんも何かありますか。
[大庭さん] 僕いくつかあるんですけども、一個めがhiroya shimamotoさんの「モノリシックRailsアプリケーションをモジュラモノリスへ移行しているnoteの事例」です。
Shopifyのpackwerkというgemを使っている話で、gemが発表されたときに僕も見て気になっていました。実際に国内で何か使っている人はあまり見たことがなかったので、その事例が出てきたのは非常に良かったですよね。スマートバンクも数年以内に直面する課題じゃないかなと思っているんですよね。
B/43ではリリースしてから1年半強でテーブル数が300超なので、一般的なWebアプリケーションにしてはデータモデルが複雑になっています。成長に付随してモデルやモジュールがどんどん増えていくので、それをどう統治していくかという課題は結構面白いし、やりがいがあるかなと思っていて、面白い発表だなと思いながら見てました。
[雄太さん] 確かに、我々もnamespaceで切ったりしていますが、そこからさらに発展していったらモジュラモノリス化やサービスを分けることもあるかなと思うんですけど。実際に移行して試してみたという事例はなかなかなかったので参考になりましたね。
今のところ大きな弊害なく進められているけど、ただRailsのデフォルトの構成とはかなり変わっちゃうから、そこが注意ポイントだと話されていて。メンバー間で認識合わせをしながら進めるのが結構難しいのかなと思いながら聞いてました。確か最近参考書も出ていたようなので、その辺りもウォッチしてみると面白そうだなと思いましたね。
Deep Dive
[大庭さん] その他だと一番最後のikuma-tさんの「自分だけの小さなSelenium『Olenium』を作って始める、ブラウザ自動化技術の理論と実践」が心に残りました。
SeleniumやWebDriverなどRailsで使ったことある人だったらなんとなく存在を知っているみたいなものの中身がどうなってるかをちゃんと掘り下げていくところをやっているのが非常にいいなと思いました。
ブラックボックスでよく分からないことって、分解して1個1個考えてみないと分からないなと僕もよく思っていて。数年前に『コンピューターシステムの理論と実装』というNANDからコンパイラ、VM、OSまで自作のプログラム言語を作っていくような本とチュートリアルをやったんですけど、これまでなあなあでやっていたことについてよく理解することができて、知識が線になって繋がった感覚がありました。
そういうのはikumaさんがやっていたようなステップを踏まないと得られない感覚だなと。それをしっかりやって、しかも分かりやすくみんなに伝えるところもうまく工夫して発表されていたところも含めて、総合的にすごいいい発表が終わり際に来たなと思いながら見てました。
[雄太さん] 自分たちが当たり前に使っているけど実は知らないところを掘り下げていたので、改めて学び直しになってめちゃくちゃよかったですね。
[大庭さん] FJORD BOOT CAMP卒業生なんですかね、若手の方に見受けられたので結構プレッシャーというか焦りも感じましたね。
[雄太さん] スクールから出てきた方も、初心者だけど型入れる話で発表されていて。メキメキ裾野が広がって下地をしっかりと勉強した方がさらに突き詰めて発表されているのを見ると、自分ももっと勉強して発表しなきゃいけないなとプレッシャーになりますね。
キューについての基調講演
[雄太さん] 最後のNateさんの基調講演も面白かったなと思っています。40分枠の結構長い発表でもあったんですけど、具体的なキューのワーカーの設定数だったりとかPumaやUnicornのプロセスの話とか。エンジニアであれば1回聞いたことあるような話かもしれないんですけど、まとめて体系立てて話されてたのが見直しになってよかったなと思いましたね。
特に弊社でもジョブキューはバックエンドで使っていて最近SQSにリプレイスもしてて、Sidekiqは使っていないんですけど、その話詳しくされてたりとか。キューの生存期間に合わせてキューを作っていくのは目から鱗だった気がしていて。メール送るキューとか〇〇キューみたいな形で実装するパターンは結構多いかなと思うんですけど、そのキューごとに生存期間でSLAを出してそれを監視しながら実装する発想はなかったので、面白いなと思って聞いてましたね。
[大庭さん] そうですね。この数字を見るべきというメトリクスをはっきり言ってくれたのも、僕はすごいいいなと思いました。実際に弊社の中でも旧システムをリプレイスしているのですが、そのときにこういう数字をちゃんと見れるようにしないとだめだねと社内でも議論に繋がってましたね。
[雄太さん] サービス時間だけでなく、ユーザーが実際にサービスを待っている時間としてキューイングしている時間から計測しましょう、と説明されているのめちゃくちゃよかったですよね。見たときメトリクス取ろうと思いました。
静的型付け
[雄太さん] あとはRubyの型の話をされているセッションも前半と後半で2セッションくらいあって、型の盛り上がりを感じましたね。自分たちも型検査を入れたいねという話がときどき出るかなと思うんですけど、実施には至っていないので。RBSとSteepで実践されて、いいところ悪いところが発表されていたのも聞けたのが良かったなと思いましたね。
[三谷さん] 恩恵は入れてみないと分からないですよね。僕は昔Javaで今Rubyに移動した時には、Rubyに静的型付けがないことがフラストレーションだったんですけど。今はどちらかというと型を書かないことのストレスフリー感の方が好きな感じもしてて。実際入れてみて感想がどう変わるのかは見てみたいなという気がしますね。
[雄太さん] なるほど。やろうと思うと結構大変ですよね。その恩恵と作業の大変さとを鑑みた方がいいのかなと思いますね。
[三谷さん] 発表の中でも「型が全て解決するもの」ではなくて、「開発環境をちょっと良くするもの」として入れるという話があったと思います。型が本当に正しいのかどうなのかをRubyの中でどう担保していくか、どこまでそれを求めるのかは結構難しいと思うので、今後そこがどうなっていくのかはちょっと気になりますね。
多少型が間違っていたり古かったりしてもいいのか。最新の型に絶対に追従していかないと逆に副作用が多いのか。そのあたりを今後知っていきたいですね。
[大庭さん] そうですね。ランタイムで失敗してくれる方だとSteepじゃなくてSorbetの方ですよね。それだと実行時に想定しない型が来たらエラーを上げてくれる。静的解析の方向で頑張るとすると、三谷さんがおっしゃったような少しサポートして体験が良くなるとか、コード書くときに補完が走るとか。そういった部分でRubyの良さを底上げする方向に振りきっていくなど、向き合い方の選択肢がいくつかあるなと思います。自分たちの中でどういうふうに型付けを捉えるかの選択肢はいくつかあるなという印象を持ちました。
[三谷さん] そうですね。実際開発するときにどっちがいいのかは結構楽しみですね。
[大庭さん] 弊社TypeScriptを書けるサーバーサイドのエンジニアも結構多いので、型を書くことについての忌避感は全然ないと思うんですよね。
[雄太さん] そうですよね、みんなGoも普通に書いてますしね。チームやサービスの規模によって、導入する上で結構ハードルが高いという印象があると思うんですけど、その辺り弊社の場合はあんまりなさそうですよね。
みんなどういう恩恵があるかは分かっている人が多いかなと思うので、どういうやり方を進めるかは話しながら進められそうかなと思いますね。
Webブラウザでの巨大ファイルアップロード
[三谷さん] 他に学びが多かったのは、ursmさんの「大量塩基配列登録申請システムができるまで」という発表で、10GB近くファイルをうまくアップロードしてパーティションするのがブラウザ側でそこまでできるんだという学びがあってよかったですね。
[雄太さん] よかったですよね。並列処理で操作を妨げることなくいい感じでパースが実装できるんだと分かって、進化しているなと、すごく勉強になりました。
まだまだお話したいところではあるのですが、お時間がそろそろ来てしまったようなので、一旦この辺りで締めさせていただこうかなと思います。
2人は2年連続登壇されているので、ひょっとしたらまた来年もあるかもしれないですけれど、その時はまた収録したいなと思います。今日は、Kaigi on Rails 2022に登壇した三谷さんと大庭さんをゲストに招いてPodcastを収録させていただきました。ご視聴いただいた皆さんありがとうございました。
あとがき
今回は「Kaigi on Rails 2022」に登壇した三谷さんと大庭さんに、それぞれの登壇内容の裏話や印象に残った発表について伺いました。
Railsでの開発環境やスマートバンクのエンジニア組織に興味を持ってくださった方、ぜひお気軽にご連絡お待ちしています。
▼サーバーサイドエンジニア smartbank.co.jp
▼カジュアル面談 smartbank.co.jp
↓Podcastはこちらから smartbank.co.jp
