こんにちは！Recustomer株式会社でEMをしております、Tatsukiです。私たちの組織ではご利用いただいているお客様により多くの価値を速いスピードで提供するために、日々開発環境・開発生産性向上の施策を検討・実施しています。この記事では、2024年度の振り返り記事でも言及した「モノレポの実施」についてご紹介します。実際にモノレポ化プロジェクトを推進したCTOのShugo Manabeに話を聞きながら、モノレポを実施する前の状況や実施理由、その効果についてご紹介します！
モノレポに興味がある方や、チームの開発生産性を向上させたい方はぜひご覧ください！
モノレポ前のリポジトリ構成
以前までのリポジトリ構成では、バックエンド(BE)・フロントエンド(FE)が役割ごとで別々にリポジトリが作成されており、8個以上のリポジトリで管理されていました。もし機能追加などによってプロジェクトを新規に作成する必要があればリポジトリを新規に作成していました。
ここからは、「このような構成にどのような課題を感じていたか？」そして「その課題をどのように解決してきたか？」について、CTOのShugo Manabeにヒアリングした内容を紹介させていただきます！
複数のリポジトリに分かれていることへ弊害
たくさんのリポジトリがあった当初のRecustomerはどんな形になっていたかというと、このリポジトリには〇〇の設定が適用されているけども、〇〇にはそうではない、というものでした。
我々はこれを「Recustomer非対称性の法則」と呼び、会社として一貫性が取れていない事柄に対して良くないことだよとレッテルを貼ることにしました。
また、共通ライブラリを作って、それを利用するという行為をするにしても、手数が多くなってしまうため、結果的にあるリポジトリにだけ全社で使える便利なモジュールにも関わらず、それがこのリポジトリだけで使われるという行為が起こりがちでした。
その結果、このリポジトリではこのような書き方ができるんだけども、あのリポジトリではこのような書き方ができない、これは更なる「Recustomer非対称性の法則」を生んでいくという形になってしまっていました。
この「非対称性の法則」を打ち破るべく、モノレポ化を行うこととなります。
モノレポ化をすることを決定したが大変だったこと
デプロイフローを整えて、すべてを統合するのが実は大変でした。
過渡期 - git submodule 期
最初は共通ライブラリ用のリポジトリを作成し、それを git submodule を使って取り込む形をとりました。
しかしながら、メンバーに git submodule を浸透させるのはやはり難しく、そこそこクセが強いツールであったこともあり、メンバーが不便そうにしていて、共通ライブラリへのコミット意欲を刺激するのはやはり難しかったです。
モノレポ期
我々はtomono を使って、一つのリポジトリに全リポジトリの履歴を保持したまま以降することにします。そこでは、こちらのtomonoというリポジトリのスクリプトを参考に一部自分でこのスクリプトを改造して使用しました。
モノレポにするのに大変なのは一番なにかというと、CI/CDまわりになります。メンバーにも伝えたのですが、モノレポにして一番大変なのはエコシステムの管理なのですが、Recustomerはプラットフォームチームを作ってこの運用を乗り越えますと宣言しました。
CI/CDまわりやlinterの整備、レビューワーのアサインメント、Dockerfileやdocker compose環境などのローカル整備の再整備。これらを1週間でやり遂げて、やると宣言してから1週間ほどでやりきれたよう記憶しています。
モノレポの成果
徐々にではありますが、共通ライブラリが機能するようになり、社内でツールが流行っていく音が聞こえ初め、似たようなコードが増えてきたよう記憶しています。
また、PRの速度も上がり、業務委託で働いている方からも、この会社のPRってこんなスピードで物事進んでいるのですか？と言われ、効果を実感しました。
また、それぞれのリポジトリを見ずとも、PRをみるときに一緒に滞留したPRを見ることになり、レビュー忘れが少なくなり、どんどんPRがマージされるようになりました。
上で述べていた「Recustomer非対称性の法則」も今ではあまり聞かれない単語になったのが、今となってはうれしいことに感じます。
他にも、多くのことに挑戦してきたManabeの取り組みにご興味がある方は、ぜひ下記記事も合わせてご覧ください！
開発生産性の向上
私たちは日々のアウトプットをFindy Team +を導入し計測しています。モノレポを行うことでサイクルタイム(Pull Requestが作成されてから、マージされるまでの時間)の改善がありました！下の画像は昨年から今年までの私たちの組織のサイクルタイムの遷移になります。
グラフの中にある最も濃い青色が「コミットからオープンまでの時間」を表していますが、モノレポを実施した2024年11月ごろを目処にコミットからオープンまでの時間が減少していることがわかります。リポジトリが分割されていた際には、DraftのPull Request(PR)が放置されていることが多く、さらにリポジトリが分割されていることで管理も難しかった課題がありました。リポジトリが1つになることでPRが放置されていることに気づけるようになりました。
最近では放置されているPRについてSlackで通知される仕組みが導入され、レビューされずに放置されているPRについてレビュワーに通知されるようになりました。
これらの施策によってPRがオープンされてからマージされるまでの時間が約8時間改善されています。
終わりに
本記事では、モノレポ化を行った背景と具体的な方法、それによって得られた成果についてご紹介させていただきました。私たちはこれからも多くの価値をより多く・より早く届けるために、今回のような施策を積極的に推進していきたいと思っております！
Recustomerでは新しいメンバーを大大大募集しています！
今回の記事に関することや、Recustomerに興味を持っていただいた方はカジュアル面談でぜひお話ししましょう！
Discussion