はじめに
こんにちは！
ツクリンクでアソシエイトテックリードとして働いている、いわまさです。
ツクリンクは、「仕事を依頼する先を探している建設会社」と「仕事を探している建設会社」を繋ぐマッチングサービスです。
2024年12月時点で利用社10万社を突破し、ますます盛り上がっています。
ツクリンクは2013年にリリースし、今年でリリースしてから11年目になります🎉
直近の変化について
かれこれ10年来のサービスになりますので当時と今では色々と状況が変わって来ていると思います。
少なくとも、2023年に私が入社する直前まではエンジニアチームは1つだけでそこから3チームに分かれ、今では以下のチーム構成になっています。
| チーム名 | 役割 |
|---|---|
| Dev1チーム | 主に非機能要件に対する責任を持つチーム（ライブラリの更新など、縁の下の力持ち💪） |
| Dev2チーム | グロースチーム🏈（新規機能の開発、機能拡張） |
| Dev3チーム | グロースチーム🏈（新規機能の開発、機能拡張） |
| SREチーム | インフラ、セキュリティなどに責任を持つチーム🌐 |
| モバイルアプリチーム | Flutterアプリの開発📱 |
| 技術推進チーム | 組織全体の技術力向上、開発効率化に責任を持つチーム🥋 |
チーム構成もそうですが、直近でも様々な環境変化がありました。
- HerokuからAWSへの移行
- モバイルアプリのFlutter化 ※元々iOS, Androidそれぞれ分かれていた
- TypeScript導入
これらの変化はなんと、2023年から2024年12月現在にかけての変化です。
（めっちゃ変化したと思う）
そんな私は2023年7月に入社し、まさにこのビッグウェーブに乗った状態で日々の業務を行いました🌊
その中で課題を感じ、今回のリアーキテクチャの話に繋がります。
チーム編成の変更と課題感
前の項でお気づきの方もいらっしゃるかと思いますが、グロースチームであるDev2,Dev3チームの役割が重なっています。
入社して割とすぐにDev3チームのリーダーとなった私はPdMやDev2のチームリーダーと業務調整をする中で以下の課題を感じました。
→結果、以前別チームが対応した内容の追加改修をもう一方のチームが行うこともある
同じチームがそのまま対応した場合と異なり、ゼロからキャッチアップが必要になるのはもちろん、何らかの経緯で対応した内容を理解せずに壊してしまうリスクも発生するので危険があったりもします。
この辺の課題については最近はチームごとの役割分担がある程度されて来ているはずなので、だいぶ良くなっていると思いますが、明確な線引きがあるわけでは無いのでまだ課題としては残っていると思います。
また、モバイルアプリとの兼ね合いもあるので以下の課題もあると認識しています。
モバイルアプリ用にAPIが必要になるため、別途実装する必要があります。
また、関連して以下の課題もありました。
入社して割とすぐだったのですが、この辺の課題感を特に強く感じたので当時このような記事を残しています。
そして課題に立ち向かう
当時はDev3チームリーダーとしてグロースの責務があったため、まずはミニマムスタートのアプローチを取りました。
OpenAPIの導入
GraphQLという選択肢もあると思いますが、サービスの規模やエンジニアの体制を考えた時に「REST APIで行こう！」と決断しました。
ドキュメントも無ければルールも存在しないため、まずは有志を募ってルール作成と既存APIのドキュメント化を行いました。
ざっくり決めたこと
- バージョニングルール
- レスポンスの定義
- 正常系
- 異常系
- OpenAPIの書き方について
まだ導入できていないですが、実装と合わせるためにcommittee-railsの導入もこれから進める想定です。
取り組みの一環として以下の記事を投稿し、社内勉強会も開催しました。
TypeScriptの導入
Dev3チームとしての業務の傍ら、スポットで入っていただいたフロントも対応できる業務委託の方と共にTypeScriptの導入を行いました！(この記事見てくださっていたら感謝の気持ちを届けたい)
ツクリンクのフロントの大半はERB×jQueryですが、部分的にReact(TSじゃなくてJS)を使っている機能も存在します。
ERBのままで良いと判断する場合もあると思いますが、フロントに求められる動的な部分がより高度になりつつあり、折角Reactを使っている部分もあるのであればこれを機に統一しよう！と思いました。
フロントもまたルールが存在せず、部分的なReactのコードも正直結構メンテナンスが大変な状態だったので、まずはTypeScriptを導入することである程度の秩序を持たせるようにしました。
技術推進チームの立ち上げ
ツクリンクでは7月に期が変わります。
そのタイミングで私はDev3チームリーダーからアソシエイトテックリードに役割が変更となり、同時に技術推進チームのリーダーになりました。
※厳密にはDev3リーダーと掛け持ちで専任は9月から
同タイミングでフロントに強い業務委託の方にJOINしていただき、2人で現状を見つめつつ今後の方針を決めました。
※方針は全てADRにまとめることとし、こちらの記事はADRの内容を見ながら書きました。
方針１：RailsはAPIとして使用し、モジュラーモノリス構成とする
こちらの方針は、最初の方に述べた「チームの責務、役割分担」に対する課題解決の手法として選定しました。
また、それぞれのモジュールに対してチームとして責任を持つことでドメイン知識の集約が行えるメリットもあります。
マイクロサービスにする考え方もあると思いますが、ツクリンクのサービス特性と現在のチーム規模やインフラコストなどを考えた場合、コストに見合わないと判断したため、「モジュラーモノリス」という手法を取り入れることにしました。
ちなみに将来的にマイクロサービスに分離しやすいというメリットもあったりします。(モノリスと比較して)
具体的には以下のアプローチを取りました。
- packwerkの導入
- packs-railsの導入
現時点でまだ整備が整っていないので実現できていないですが、packwerkにはモジュール間の依存関係をチェックする機構が備わっているので、CI上で領域違反が発生した場合はテストで落とすことも可能です。
方針２：フロントはリポジトリを分け、RemixとMUIを採用する
フロントの実装を完全にRailsから剥がすことが可能なため、リポジトリごと分けて更にRemixを採用しました。
選定理由は以下です。
- Reactベースである
- サービスの特徴としてWeb標準が相性が良さそうと判断した
- ※シンプルは登録、検索、表示がベースとなっているため
- エンジニア全員がフロントに強いわけでは無いため、Next.jsよりは学習コストが低いと判断
- フロントエンジニアの採用に繋がる将来性を考慮
Remixの導入と共にSentryを導入し、フロントのエラー監視を行うようにしました。
※ちなみにRails側はBugSnagを使用しています。
インフラ構成についてはSREチームと議論・検証し、現行と親和性が高いAWS ECS上で動かす構成としました。
詳しい内容はトップバッターida.さんの記事をご覧ください。
フロントのスタイリングについては最初にTailwindCSSの検証を行いましたが、現状のツクリンクではバリバリのフロントエンジニアが在籍していないこと、デザインシステムの導入を進めているがそこに大きなコストを掛けながら進むことは困難であると判断してMUIを導入することにしました。
MUIの詳しい選定理由は以下です。
- デザインシステムの導入が容易に行える
- 自前でコンポーネントを作成してルールを作るコストが現在見合わないと判断
- v6から正式にSSRに対応する(丁度選定してすぐにリリースした)
- Figmaにテンプレートが存在する
- デザイナーさんとの意思疎通にめっちゃ便利
最近はTailwindCSSが流行っていて導入したい気持ちもありましたが、組織の状況を考えた時に見合わないと判断したことは後悔していません。
※今後つよつよなフロントエンジニアが入って来たら状況変わる未来もあるかも？
ついにリリース！
全てのページではなく、影響範囲の少ないページを対象に技術推進チームを中心としてリアーキを進めました。
Wappalyzerで確認するとRemixとMUIが使われているステータスになっている！
たった2人のチームなので周りのチームのご協力を仰ぎながらの作業でしたが、技術選定が完了してから約1ヶ月半くらいでリリースしました。
現在はサンプルとして他のページのリアーキテクチャを進めている状態ですが、将来的には全チームのエンジニアがこちらの技術スタックで開発を行う状態にまで持って行く想定です。
まとめ
ツクリンクアドベントカレンダー最終日、リアーキテクチャのお話は以上です。
まだまだスタート段階ではありますが、将来的に全てのページが上記の構成に変わって行くと思います。
組織構成と共にアーキテクチャも進化させて、どんどん価値提供の質と速度を高められるように日々研鑽を続けていきます。
それではみなさん、良いお年を！
Discussion