こんにちは！株式会社estieでソフトウェア・エンジニアをやっています、t-poyoです。
2021年1月15日、弊社のestie pro開発チームでは、📕 『パーフェクト Ruby on Rails』 の著者であるigaigaさん（@igaiga555）をお招きし、Railsを用いたサーバサイドのアーキテクチャ検討会をおこないました。
今日は『パーフェクトRails』の著者でもある @igaiga555 さんをお招きし、沢山勉強させていただきました。
— 株式会社estie(エスティ) (@estie_corp) 2021年1月15日
色々と相談させていただき、濃密な時間を過ごすことができました！ありがとうございます✨
どんどん成長するチームに今後もご期待ください！😉 pic.twitter.com/FkyvyefFrG
この記事では、
- 開催にいたる経緯
- 当日の様子とまとめ
- 実施して得られた様々なアウトプット
について紹介したいと思います。
開催に至った経緯
ユーザへのハイスピードな価値提供を優先した機能開発で生まれた課題
株式会社estieは不動産テックスタートアップであり、estie proは「オフィス賃貸業務を効率化する情報プラットフォーム」です。 顧客の要望や社内で湧き出る様々なアイデアを「とにかく早く形にすること」を信条に、サービスインから8ヶ月間走り続けてきました。
当初は業務委託のエンジニアが多い体制で、チームとしてではなく、個人の力量や使える時間でユーザに届ける価値の量が決まってしまっていました。 しかしここ数ヶ月で社員エンジニアが増え、コードベースやプロセスに対しアジャイルな改善を始めることができています。 より快適な開発体験や資産としてのソフトウェア構築を目指す中、以下のような課題が浮き彫りになってきました。
- 複雑な機能要件に対して、特にサーバサイドで、必要な各モジュールをどこに配置すればいいか明確な判断基準がない
- 上記の結果、肥大化したモジュールが点在したり、同じレイヤーにあるべき機能が散らばっていたりする
estie proのサーバサイドはRuby on Railsで実装されています。(フロントエンドはVue.jsです。) レイヤーについてある程度枠組みを作っていた(Controllers, Services, Presenters, Serializer…)ものの、 前述の理由で、レイヤー間を疎結合にすることに成功していませんでした。
必要なのは規約と合意
そこで、estie pro開発チームはサーバサイドのアーキテクチャについて合意を取りつつ、それを実践するコーディング規約を策定すべく動き始めました。
チーム内にはDDDの経験者もいたため、まずクリーンアーキテクチャをそのまま取り入れるようなアーキテクチャを検討しました。 しかし、ご存知の方も多い事実ですが、Active Recordとクリーンアーキテクチャは壊滅的に相性が悪く、その制約とその恩恵に折り合いがつけられる構成にたどり着くことが出来ませんでした。
その会議の過程で、Rubyでクリーンアーキテクチャを実現するフレームワークHanamiも検討しました。 その時の記事がこちらになりますので、ご興味のある方は読んでみてください。
しかしHanamiも導入には至らず、このままで埒が明かない！ということで、VPoE に相談し、Railsの専門家を外部からお呼びして、設計方針を決めることにしました。
Railsアーキテクチャ検討会
待ちに待った検討会当日です。 一部のメンバーはオフィスに集まりホワイトボードを準備しましたが、それ以外のメンバーはリモート参加。 igaigaさんにもリモートにてご参加いただきました。
当日はこのような流れになりました。
困りごとは何？
事前の打ち合わせで、検討会のゴールは「新しく作るRailsの規約の方針を固めること」となんとなくイメージしていましたが、 当日は改めてestie pro開発チームの困りごとをigaigaさんに聴取いただきました。 実際に開発チームから挙げられた懸念事項は以下のようなものでした。(一部抜粋)
- 特定のモジュール(クラス)のインプットが複数のモデル(=Active Record)に関係しているが、それらの分離が難しい/分離してもどこに置けばいいか不明
- 特定のモジュール(クラス)のアウトプット後の整形処理に複数のパターンがあり分離しているが、それらを疎に保てていない
これらとコードベースを見ていただいた結果を踏まえ、igaigaさんに「サービス層にあるクラスの設計のコツ」を伝授していただくことになりました。
サービス層のクラスの"キャラを立たせる"
「サービス層のクラスをどういった粒度で分離すればいいかわからない」というestie proチームの課題を見抜いたigaigaさんは、 クラスを「擬人化」してみることを提案されました。
そもそもサービスという用語が人によって解釈の揺れが大きく、文脈によって様々な意味を持ってしまいがちだったのです。
- 「サービス層のクラス」を「フレンズ」と呼ぶことで「フレンズの気持ちになって設計を考える」！
- そして、「フレンズのキャラを立たせる」ことで適切なクラス設計を進められるそうなのです。
（フレンズという呼び方は皆さんご存知、アニメ「けものフレンズ」が元ネタですね。笑） 最初は「フレンズ」という呼び方に笑いがおこったものの、実際に試してみると、この考え方で驚くほど思考が整理されます。
- 「この子は○○の検索が得意なフレンズなんだね！」
- 「この子は✕✕と△△の整形を任せてるフレンズだけど、大変そう…片方は別のフレンズに任せてあげたほうがいいかも」
- 「この処理にはたくさんのフレンズが関わってて複雑だから、案内役のフレンズがいるとみんな楽になりそう」
思考が整理されるだけでなく、見解の違いによって袋小路になりがちなクラス設計に関する議論が、 ちょっとした笑いとともに進むのも「フレンズ」メソッドの良いところだと感じました。
検討会を振り返って
一部の模様をお伝えしてきましたが、他のセクションでは個人のキャリア・学習相談や、 estieの採用チームからエンジニア採用の相談をお願いしたりなど、Railsの範疇に留まらない多岐にわたる知見を共有いただきました。 igaigaさん、本当にありがとうございました。
参加者の声
estie proチームでは検討会後に振り返りを行いましたが、そこで出た参加者からのフィードバックを一部紹介します。
- igaigaさんが本当に優しい人だった。経験に基づいた後押しをして貰えたので、自信を持って設計に取り組めそう。
- 普段開発していると欠点ばかり目につくが、第三者の目線でコードベースを見てもらって、いいところも沢山指摘いただいて、すごく自信になった。
- いろいろなRailsの現場を見てきた方の意見や体験談を聞けて、シンプルに勉強になった。モチベーションが上がった。
我々のような少人数のスタートアップでも、定期的に外部のエキスパートを呼んで話を聞くことで刺激になり、 広い視野をもって開発や設計に取り組むことができるなと改めて思った次第でした。
おわりに
この検討会を踏まえて、estie pro開発チームではRailsのコーディング規約を策定中です。こちらもまた別の記事にてご紹介できればと思っています。
また、igaigaさんをお呼びする機会は第二回も予定しているので、その内容も記事化していく予定です。どうぞお楽しみに。
現在estieではサービス急拡大につきさまざまなポジションのエンジニアを募集しています！ 会社に少しでも興味を持たれた方がいらっしゃれば、気軽にお話しできればと思います。TwitterのDMよりお声がけください！ twitter.com
採用情報はこちらをご確認ください！
