👻

Kaigi on Rails 2022 セッションレポート #3

株式会社TOKIUM 開発部2022/10/28に公開

株式会社TOKIUMの坂上(HN: にしこりさぶろ〜)です!この記事では、10月21日(金)-22日(土)の2日間に渡り開催されたKaigi on Rails 2022にて、聴講したセッションの中でも印象に残ったモノをいくつか紹介していきます。

僕が紹介するセッションは、以下の2つです。

7つの入金外部サービスと連携して分かった実践的な”状態管理”設計パターン3選

解説

株式会社スマートバンクのサーバーサイドエンジニア・Shohei Mitaniさんによる、入金外部サービスと連携する際の状態管理設計パターンの紹介セッションです。

プリペイドカードと家計簿が一体となったプロダクト・B/43が利用する5社の外部サービスを「リアルタイム型」「事前予約型」「完全非同期型」の3つのパターンに分け、それぞれのパターン毎に抑えるべきポイントについて解説する内容でした。参考情報として、パターン毎のテーブル設計例も具体的に紹介されており、入金・決済が関係するプロダクトに携わるエンジニアには非常に参考となるセッションだったと感じました。

感想

データ不整合が許されない入金・決済の領域において、外部サービスとの連携箇所の設計パターンが丁寧かつ分かりやすく解説されており、入金・決済周りの実装経験が浅い僕にとっても大変参考になる内容でした。

ユーザー・自社アプリ・自社サーバー・決済サービスの関係をシーケンス図に起こした上で、「DBトランザクションを適切な粒度で分離すること」「アプリ外でのイベントを意識して結果を通知すること」「エラーの種類を整理し、検知とリカバリ手段を考えること」等、実装上で気をつけるべきポイントが適切に抽象化されており、発表者の設計・実装力の高さを伺い知ることができました。制約条件を丁寧に列挙し不確実性を排除していく設計の過程は、感覚的に進めてしまったり脳内で完結させてしまったりすることも多いですが、高い品質のコードをチームでアウトプットしていく上で言語化・図式化を疎かにしてはいけないと、この発表を通して改めて感じました。

歴史あるプロジェクトのとある技術的負債を隙間プロジェクトの 210 PullRequests で倒しきった話

解説

株式会社ANDPAD所属のRubyist・makicamelさんによる、技術的負債に継続的にアプローチし続けリファクタリングを完遂させるまでの過程を紹介した発表です。

最初のリリースから7年が経過したANDPADには、開発初期を支えたCrudControllerというControllerクラスが存在しました。includeすると、アクションメソッド・スコープの定義を非常に短く記述することができ、たった2行でシンプルなCRUDのAPIを生やしてくれる、一見すると便利なクラスです。ですが、サービス・組織の成長とともに、暗黙的なメソッド定義・コールバック追加、可読性の低いメタプログラミングでの実装コード等が開発者の足かせとなり、社内でも「つらみトップランカー」として認識されるようになったそうです。

CrudControllerを参照するコントローラーは300弱にも及び、一気に書き換えることはほぼ不可能。そんな巨大な技術的負債ですが、約2年をかけて倒しきったそう。その2年の道のりの中で、以下4点のやったこと・意識したことが紹介されました。

  • スクリプト化
  • 変更リスクを減らす
  • チーム戦にする
  • モチベーションを保つ

4点の中で共通していたことは、負債の返済を長期に渡って継続できるよう、あらゆる努力を尽くすということです。一例を挙げると、「汚いと感じた箇所を残さない」ボーイスカウト・ルールを敢えて守らないという方針を立てていた、とのことです。これは、当初着目していた関心事とは異なる箇所をついでで直した結果、インシデントを発生させてしまった失敗から得た教訓をベースとしており、変更の関心事を少なく保つための方針です。リファクタリングによって生じた障害は負債の返済のモチベーションを下げてしまう原因の1つであり、安全性とコストのバランスを鑑みた上での意思決定とのことでした。

感想

弊社でもサービスの成長に伴い生じた巨大な技術的負債の返済は大きな課題の1つですが、「技術的負債の解消作業をスクリプト化し、MTGの合間10分等のスキマ時間でPRを作れるようにする」という、運用や工数確保といったマネジメントではなく、技術的負債を技術で解決する姿勢に大きな感銘を受けました。僕のような設計に関心の強いエンジニアは、技術的負債の返済タスクに取り組む時に無意識のうちに理想的な作業環境を確保することから始めがちかと思いますが、モチベーションの維持や作業量分散の観点から、スクリプト化のアプローチはいの一番に考えるべきであると気付かされました。

また、ボーイスカウト・ルールを敢えて守らず、変更の関心事を少なく保つよう強く心がける点も、忘れがちなポイントで学びになりました。弊社もtoB領域でファーストリリースからもうすぐ7年となるRails製プロダクトが主力であるため、ANDPADさんの背中を追って継続的に負債へと立ち向かっていこうと強く感じました。

全体を通して

昨年もスポンサーさせていただいたKaigi on Railsでしたが、Railsというフレームワークに縛られない、Web技術に関する広範な知識・経験をインプットすることができ、大変貴重な時間だったと強く感じています。僕個人としては、Twitterでの当日の実況・セッションレポートと貢献ができたため、来年以降は登壇というまた違う形で貢献ができればと思いました😊

カンファレンスの開催・運営にご尽力いただいた全てのみなさん、本当にありがとうございました!🙇‍♂️

株式会社TOKIUM テックブログ

『無駄な時間を省き、豊かな時間を創る』 株式会社TOKIUMの技術ブログです🕰

Discussion

ログインするとコメントできます