SHOEISHA iD

※旧SEメンバーシップ会員の方は、同じ登録情報(メールアドレス&パスワード)でログインいただけます

ProductZine Day&オンラインセミナーは、プロダクト開発にフォーカスし、最新情報をお届けしているWebメディア「ProductZine(プロダクトジン)」が主催する読者向けイベントです。現場の最前線で活躍されているゲストの方をお招きし、日々のプロダクト開発のヒントとなるような内容を、講演とディスカッションを通してお伝えしていきます。

ProductZine Dayの第3回。オフラインとしては初開催です。

ProductZine Day 2024 Summer

ProductZine Day 2024 Summer

「Developers Summit 2024」レポート(AD)

LayerXのバクラクシリーズを支える「モノレポ開発」の裏側に迫る

【16-B-8】ビジネスドメインの拡大を実現するバクラクシリーズでのモノレポ開発

 請求書処理、経費精算、法人カードなど、企業の支出管理を一本化する「バクラクシリーズ」を提供する株式会社LayerX。複数の事業・プロダクトを同時並行で展開する「コンパウンド・スタートアップ」を志向している同社では、スピーディーなビジネスドメイン拡大のためにモノレポ開発を実践している。その取り組みについてバクラク事業部 CTO 中川佳希氏が語った。

編集部注

 本稿は、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点を挙げた。

  1. サービス間でのデプロイ順序を定められなくなる。
  2. 全サービスの中で一貫性のある依存の流れや方向性がなくなる。
  3. 本来、依存関係のないサービス間にまで、サービスダウンなどの悪影響が波及する。

 ポリレポでプロダクトチームが独立して開発を行い、一定の重複するコードを許容することで「他チームに影響を与えずにスピーディーに開発できる」「ライブラリの依存解決などが不要になる」「オーナー不在でメンテナンスされない状態が発生しない」といったメリットもある。ただし、これらのメリットは、上述した循環参照の問題とは別の文脈で考える必要があるという。

次のページ
ポリレポからモノレポへ

関連リンク

この記事は参考になりましたか?

「Developers Summit 2024」レポート連載記事一覧

もっと読む

この記事の著者

野本 纏花(ノモト マドカ)

 フリーライター。IT系企業のマーケティング担当を経て2010年8月からMarkeZine(翔泳社)にてライター業を開始。2011年1月からWriting&Marketing Company 518Lab(コトバラボ)として独立。共著に『ひとつ上のFacebookマネジメント術~情報収集・人脈づくり...

※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です

提供:株式会社LayerX

【AD】本記事の内容は記事掲載開始時点のものです 企画・制作 株式会社翔泳社

この記事は参考になりましたか?

この記事をシェア

ProductZine(プロダクトジン)
https://productzine.jp/article/detail/2516 2024/04/12 12:00

おすすめ

アクセスランキング

アクセスランキング

イベント

ProductZine Day&オンラインセミナーは、プロダクト開発にフォーカスし、最新情報をお届けしているWebメディア「ProductZine(プロダクトジン)」が主催する読者向けイベントです。現場の最前線で活躍されているゲストの方をお招きし、日々のプロダクト開発のヒントとなるような内容を、講演とディスカッションを通してお伝えしていきます。

新規会員登録無料のご案内

  • ・全ての過去記事が閲覧できます
  • ・会員限定メルマガを受信できます

メールバックナンバー

アクセスランキング

アクセスランキング