こんにちは！
バクラク事業部の @ysakura_ です。バクラクビジネスカードでエンジニアをしています。ここ1年ほど、バクラクビジネスカードを中心としたプロダクト間連携の開発を担当しています。
この記事は LayerXテックアドカレ2023 の34日目の記事です。前回は id:convto さんが ID/共通管理チームは「のびしろ」だらけ！これからやりたいことを一部紹介します！という記事を書いてくれました。次回は id:yu-ya4 がML領域の課題を書いてくれるそうなので、楽しみにしていてください！
今回はのびしろウィークということで、自分が担当するプロダクト間連携について、これまでの課題と今後の伸びしろを技術・組織の両面から1つずつ紹介します。終盤では、LayerXが挑戦しているコンパウンドスタートアップとの関連性についても紹介します。

のびしろウィークとは

のびしろウィークとは、LayerXの各チームメンバーが自分たちのチームの伸びしろについて対外的に発信する期間です！過去の対外的な発信では社内でうまく行った事例などについては各種発信していましたが、どういう課題があってどういった方の協力を求めているかについての発信はあまり行なっていませんでした。
もちろん多くの企業と同じように不確実な市場で事業に向き合っているため、うまくいったこともあれば、これからもっと整備したい部分、いわば「のびしろ」もたくさんあります。
のびしろをざっと読んでみて、「その課題、一緒に取り組んでみたい！」とすこしでも思っていただけたら、ぜひ気軽にご連絡ください！

担当するプロダクト間連携の紹介

下記の様な一連の業務をバクラクシリーズとして提供しています。法人カードでの決済後に必要となる業務を、プロダクト間連携によりバクラクにしよう、というものです。

バクラクビジネスカード
- カード決済がされます
  - この段階で後続のプロダクトにデータが連携されます
バクラク申請・経費精算
- 従業員が決済した事を報告する
- 領収書等の証憑を添付する
- 事前稟議の紐づけをする
  - 例えば購買申請
バクラク請求書受取・仕訳
- 経理の方がカード明細と従業員の報告をもとに、仕訳を処理する

自分の担当範囲としては、データ連携などの基盤となる部分 / バクラク請求書受取・仕訳の機能開発を主に担当しています。
参考: https://bakuraku.jp/news/20230315/

技術面

プロダクトを跨ぐ機能である事から複雑性が生まれており、それを解決していく必要があります。

複数プロダクトのデータを元に、検索とページネーションを可能にする

仕様

下記の様な検索要件と、それを元にしたページネーションの処理があります。

バクラク申請・経費精算
- 従業員がカード明細に対して申請を作成する
- 申請の検索要件
  - 申請に関する内容(例: 証憑添付の有無・申請日)
  - カード明細に関する内容(例: 決済金額, 決済日)
バクラク請求書受取・仕訳
- 経理の方がカード明細に対して仕訳を作成する
- 仕訳の検索要件
  - 仕訳に関する内容(例: 勘定科目, 部門)
  - カード明細に関する内容(例: 決済金額, 決済日)

課題点

この際に問題になるのが、ストレージにおけるページネーションの実現方法です。検索条件でFilterした上で現在のページにおけるレコードを返す必要があります。
その為、基本的には同一のストレージにトランザクションデータ自体と検索条件となる関連データを保持する必要があります。

解決方法(これまで)

MySQLの同じ論理DBにデータを集める事で対応しました。具体的には下記の対応をしています。

バクラクビジネスカード のカード明細を専用のDBにコピーする
バクラク請求書受取・仕訳 ・ バクラク申請・経費精算 の決済後業務に関わるデータを専用のDBに保存する

のびしろ(今後)

バクラクビジネスカードのカード明細を専用のDBにコピーする

このコピーの方式として、バクラクビジネスカード から Amazon EventBridge にイベントを投げる形でカード明細を送信しています。その為、バクラクビジネスカードの機能追加・変更時にイベントのPublish漏れが起こる可能性があります。データ不整合の検知はしているのですが、仕組みとしてより安定的なものにしていきたい、という伸びしろがあります。
例えば、Transactional Outbox Patternを活用するなど、より安定的な手法を新規のプロダクト間連携では取っていきたいと考えています。
参考: https://microservices.io/patterns/data/transactional-outbox.html

組織面

プロダクト間連携は1つのプロダクトチームでは見きれない

LayerXの組織体制

LayerXではプロダクト毎に開発組織を置いています。(プロダクトカットな開発組織)
一方で、プロダクト間連携の機能はプロダクトを跨ぐ為、どのチームが管理するかという問題が起こりやすいです。
今回の決済後業務の機能については、バクラクビジネスカードのチームが担当する事にしていました。

課題感

1stリリースと初期運用が安定した頃から、下記の課題が顕在化してきました。

障害対応・トラブルシューティングが難しい
- 対象が3プロダクトに渡るので、原因特定がパッとは難しい
全体像を把握している人が少ない
- 問題例) 追加の大型機能の開発時に、変更の影響範囲が分かる人が少ない
バグ改修や改善でコードに手を入れるには、対応が難しい部分がある
- 例えば、バクラクビジネスカード のエンジニアが バクラク申請・経費精算 のコードを触るのは難易度が高い

解決方法(これまで)

主な原因はドメインと実装の複雑性であったため、専用のチームを組む事で解決を図っています。具体的には、下記の方針で進めています。

今回のプロダクト間連携を1つのプロダクトとして捉え、専任のPdMを置く
各プロダクトからエンジニアを1人ずつ招集してチームを組む(進行中)
- 実装/レビュー/運用をこのチームで担当する
- 結果として、全体を見渡せる人が増えている状態を目指す

結果として、プロダクト間連携のチーム内では全体像が見える人が増えてきました。自分がいないと回らない状況でしたが、その状況は緩和する事が出来ました。

のびしろ(今後)

今後の課題として、下記のものがあります。

プロダクト間連携のチームメンバーの負荷が高い
- 担当プロダクトのコンテキストを把握する必要があり、基本的に兼務
属人性が高い
- 担当プロダクトが纏わる部分を中心に各自が見ているので、属人性が高い

今回のケースでは、下記の方針で負荷分散をする事を検討しています。

最終的にはチームを解散させ、担当チームに知識を還元する。
プロダクト間連携チームのメンバーが起点となり、組織全体でこのドメインに詳しい人を増やしていく。

さいごに

ここまで、バクラクビジネスカードを中心としたプロダクト間連携の課題と伸びしろについて紹介してきました。

他にも伸びしろが！

今回触れた伸びしろは一部であり、他にも様々な課題(伸びしろ)があります。最後に軽く触れておきます。

権限の仕様が難しい…！

プロダクト間連携では、複数のプロダクトから同じリソースにアクセスする事が多いです。その際、同じリソースへのアクセス権限をどう規定するか、という仕様面の課題があります。例えば、下記の様な選択肢がありますが、どの方針にするかはプロダクトのユースケース次第です。

アクセス可否を各プロダクトで定義する
データソース側(リソースの所有サービス)のアクセス範囲を正とする

LayerXでは、エンジニアも仕様の意思決定に関わっていくので、こういった課題もエンジニアの関心事である事が多いです。

プロダクト間連携のインターフェースが難しい…!

A → B というプロダクト間連携があった場合に、APIのInterfaceとしてA,Bどちらのドメインの形式でデータを送るか、という問題があります。これは、片方のプロダクトにもう一方のプロダクトのドメイン知識を要求する事になりがちなので、難しい問題です。
例えば、バクラクビジネスカード → バクラク請求書受取・仕訳 の連携では、カード明細を送る様にしています。バクラクビジネスカードから仕訳データを送る事も可能ですが、仕訳の知識をカード側のコードや開発チームが持ち続けるのは困難と判断しました。
他の選択肢として、データ変換のプロセスを間に挟み、各プロダクトにおけるドメイン境界をはっきりさせる手もあると思います。この変換プロセスの保守管理問題は起こりやすいですが、後続の処理における可読性向上や実装の共通化が見込めるメリットがあります。

プロダクト間連携は今後も増えていく

今後のLayerXの方向性として コンパウンドスタートアップ という考え方があります。

コンパウンドスタートアップとは
創業時から単一プロダクトではなく、複数プロダクトを意図的に提供
部署でサービスを区切るのではなく、データを中心にサービスを統合する
プロダクト間の連携の良さそのものがプロダクトである
複数のプロダクトを管理、ローンチするケイパビリティを持つ
という特徴のスタートアップです。

https://comemo.nikkei.com/n/n7332c93f50c7

このコンパウンドスタートアップの話を起点に、プロダクト数とプロダクト間連携が今後より増えていく事が想定されます。その為、将来的には今回の様な課題が増加すると予想されます。
その際、今回の例をそのまま適用するのではなく、連携するプロダクトの組み合わせや開発に関わるメンバーなど、実際の状況に適した解決策をその現場毎に選んでいく事が重要だと考えています。
さらに、これらのプロダクト間連携の課題を汎用的に解決していく仕組み作りも今後のLayerXにおける伸びしろの1つです。Enablingチームとプロダクトチームが協力しながら進めていく予定です。
参考: 開発スピードを落とさないために必要なイネーブルメント組織とは