編集部注
本稿は、CodeZineに掲載された、ソフトウェア開発者向けカンファレンス「Developers Summit 2024（デブサミ2024）」のセッションレポートを転載したものです。プロダクトづくり、プロダクトマネジメントに近しいテーマを選りすぐってお届けします。
ポリレポ開発で生じていた3つの問題点とは
バクラクシリーズは、「バクラク経費精算」「バクラク請求書受取」「バクラク請求書発行」「バクラクビジネスカード」「バクラク申請」「バクラク電子帳簿保存」の計6つのプロダクトを擁しており、プロダクト間でのなめらかな連携を強みの一つとしている。
バクラクシリーズの前身となる「LayerX インボイス」は、2020年7月から開発に着手し、2021年1月に提供を開始した。BtoB取引マーケットのセンターピンである請求書の受取業務を対象としたものである。
その後、近接領域から徐々にビジネスドメインを拡大していく。2021年4月に「LayerX ワークフロー」を、2021年11月に「LayerX 電子帳簿保存」を提供開始しており、2021年12月にはバクラクブランドへとリニューアル。さらに2022年8月に「バクラクビジネスカード」で決済事業への参入を果たし、2023年8月には「バクラク請求書発行」の提供を開始している。
「バクラクシリーズは、あらゆるデータを連携して、ハタラクをバクラクに変えていくと標榜している。そのため、個々のプロダクトがバラバラに存在しているのではなく、データを共通化して連携させることに重きを置いてきた」と中川氏は強調する。
バクラクのプロダクト開発の変遷をたどってみると、2020年の開発スタート時は、1プロダクトあたり3〜4個のレポジトリで構成されたポリレポ（※1）スタイルでの開発だった。それから2年が経ち、2022年は4プロダクトにまで増え、レポジトリ数が20を超えるようになった。バックエンドはGoに統一されていたが、APIはプロダクトによって異なり、RestやGraphQLが使われていたという。同様に、フロントエンドはTypeScriptで統一されていたが、フレームワークはVue.jsやReactなど、プロダクトによって使われるものは異なっていた。
※1：ポリレポ（Polyrepo）とは、複数のプロジェクトをそれぞれ独立したレポジトリで管理する手法。
この頃は、15〜20人のエンジニアが在籍しており、1プロダクトを2〜3人で開発しているのが一般的。DevOpsやSREの専任者をアサインしない時期もあり、プロダクトに共通する開発基盤チームもなかった。そのため共有ライブラリは一部しかなく、バクラク全体で使える資産はあまりない状態だった。
このようななか、内部通信用のAPIを通じて必要なデータを提供することで、プロダクト間の連携を実現していた。APIをたたいて他プロダクトのデータを参照したり、他プロダクトのデータと結合して検索や出力をしたり、他プロダクトからの非同期通信によるデータの作成や更新をしたりといった具合で、バックエンドシステムに依存関係が生じていた。
特に、大きなドメインを持つサービス同士では、依存関係が循環的につながることにもなりやすい。中川氏はポリレポ開発による循環参照の問題点として、次の3点を挙げた。
- サービス間でのデプロイ順序を定められなくなる。
- 全サービスの中で一貫性のある依存の流れや方向性がなくなる。
- 本来、依存関係のないサービス間にまで、サービスダウンなどの悪影響が波及する。
ポリレポでプロダクトチームが独立して開発を行い、一定の重複するコードを許容することで「他チームに影響を与えずにスピーディーに開発できる」「ライブラリの依存解決などが不要になる」「オーナー不在でメンテナンスされない状態が発生しない」といったメリットもある。ただし、これらのメリットは、上述した循環参照の問題とは別の文脈で考える必要があるという。
