2023年10月27日、28日に開催されるKaigi on Rails 2023にスマートバンクから3名のエンジニアが登壇します！今回は、Kaigi on Rails 2023に参加される方向けに、3名の登壇者から発表の想いや見どころを紹介いたします。

返金処理を通して学ぶ、カード決済電文の沼バトル @hirotea

スケジュール

Day2 - 10.28 (Sat.)10:40-10:55 ＠Hall B kaigionrails.org

概要

ECサイトでクレジットカード決済を行い、注文をキャンセルした経験はありますか？しばらくすると返金処理が行われ、カード会社からの請求がキャンセルされます。しかし、カード会社がどのようにして返金処理を行っているのか、気になったことはありませんか？

カード会社は、決済時と返金手続き時にお店から発行される電文をもとに決済・返金処理を行いますが、実はかなり混沌とした世界であったりします。

登壇者は、プリペイドカード発行会社で新規機能開発時にこの返金処理の沼にハマり、そのケアに苦労しました。このセッションでは、決済電文をプリペイドカード発行会社（イシュアー）がどのように処理し、ユーザーの残高を変動させているのかに触れた後、登壇者が苦労した返金処理に関するケアについてカジュアルにお話しします。普段カード事業に携わることがなければ知ることができない、そして気にも留めないお話をみなさまに提供する予定です。

ひとこと

今回初登壇となり、機会をいただけて大変嬉しく思っています。今回は自分が入社後初めて担当した機能を実装している中で遭遇した沼をご紹介する予定です。自身の反省を踏まえながら、普段何気なく使っている決済システムがいかに混沌としているかをみなさまにご共有できればと思っていますのでもしご興味ある方いらっしゃれば、2日目のBホールでお待ちしております！

登壇後はブースにおりますので、フィードバックなどなどいただけると泣いて喜びます！スライドはまだできていません！！！

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

スケジュール

Day2 - 10.28 (Sat.)11:05-11:35＠Hall B kaigionrails.org

概要

新しく機能を設計する際、将来的な仕様変更の可能性を踏まえて拡張性を持たせたり、簡単に変更ができるように工夫することは、経験を積んできたエンジニアにとって常に意識しているポイントかと思います。しかし、時として思わぬ方向に機能のニーズが変化したり、予想外の事業領域へのチャレンジによって当初には意図してない形に設計を大きく変更せざるを得ないケースも生じます。

このテーブルを変更しないといけないけど参照箇所が多くて触りにくい...

新しくカラムを追加したいけどデータ量が多いからオンラインして良いのか不安...??

この仕様ってこれから先どう変わっていくんだろ... 拡張性とか考えなくてもいいかな...??

サービスが大きくなるほど既に動いている機能を障害なく変更していくことは難しくなりますし、変化の多い事業環境でどこまで拡張性や柔軟性を持たせるかの見極めは困難です。

このセッションでは、実際の事例に基づいてサービスのコアとなるモデルの仕様を大きく変え、テーブルの定義変更やモデルの機能拡張をしたお話をします。多くのモデルに依存していたり、Read/Writeが多いモデルをダウンタイムなしで変更していくための手順の決め方や具体的なテクニック、便利なgemなどについて紹介します。また、私たちのチームが将来像を考慮しながら設計する時に意識しているポイントについても紹介します。

ひとこと

3年連続で登壇できることになり、非常に嬉しく思っています。これまでは過去のPJで学んできたパターン系の話をしてきましたが、今回は抽象化をあまりせずPJで実際に採用したリリースの手順だったり、その時に調べたり考えていたことをボトムアップ的にお話ししようと思います。特にオンラインDDLの仕様や挙動について詳しく深掘りしようと思うので、興味がある方はぜひ立ち寄ってください！

過去2回はオンライン開催で登壇した後にお話しする機会も少なかったのですが、今回は会社としてブースも出していますので、みなさんとお話しできたらと思います！よろしくお願いします！

管理機能アーキテクチャパターンの考察と実践　@ohbarye

スケジュール

Day2 - 10.28 (Sat.)13:30-14:00＠Hall B kaigionrails.org

概要

Webサービスの開発・運用に携わる者なら、管理機能の重要性について深く認識していることでしょう。ユーザーアカウント管理、システム設定、トラブルシューティング、レポート機能など、管理機能はサービスを安全かつ効率的に運用するための不可欠なツールです。

しかし、新規事業やスタートアップではユーザーに迅速に価値を提供し、ビジネスを軌道に乗せることが最優先されます。その結果、管理機能の開発は後回しになり、対ユーザー向けの機能を先にリリースして運用を始めてから管理機能を追加する、という開発ロードマップが多く見られます。このようなケースはままあるものの、管理機能追加の際に選ばれるアーキテクチャパターンについては十分に語られていないと感じています。

このセッションでは、単なるgem選定を超えて、管理画面や管理機能を後から追加する際のアーキテクチャパターンを深堀りします。それぞれの選択肢のメリットとデメリットを比較し、選択の視点を提供します。また、私が運用しているRailsアプリケーションでの管理機能設計の選択とその理由に加え、運用から得られた知見―特に監視やプロセス管理などのトピック―にも焦点を当てます。このセッションを通じて、管理機能設計と運用に対する理解と視野が広がれば幸いです。