Sansan 株式会社 技術本部 Bill One Service Platform 開発部 向井 悠祐 Bill One における Service Platform 開発 Sansan Tech Talk @関西 

向井 悠祐 Sansan株式会社 技術本部 Bill One Service Platform 開発部 2021 年 Sansan に中途入社 入社してから 、Web アプリケーション開発エンジニアとして請求書受 領領域 開発と技術マネジメントに従事。 現在 Service Platform 領域 開発と技術マネジメントを担当し、 Bill One 全体 開発生産性を上げるため リアーキテクチャを推進。 前職 SIer で 、開発プロジェクトへ 技術支援や PoC 開発、社内 システムを担当。 

Sansan株式会社 働き方を変える AXサービス 生産性を向上させ、企業 AI活用を最大化するデータベースとしても貢献できる 「働き方を変える AXサービス」を提供します。 データクオリティマネジメント 請求 名刺 管理 営業 契約 名刺管理から、収益を最大化する AI契約データベースが、利益を守る 「なくせる」をつくり、全社 働き方を変える 名刺アプリ 経理AXサービ ス 取引管理サービ ス ビジネスデータベース 各サービス 活用で変わる働き方 情報を分析・活用しやすく データに基づいた判断ができる 情報 管理がしやすく すぐに共有できる 必要な情報を すぐに見つけられる 個人向け 法人向け 

Bill One｜「なくせる」をつくり、全社 働き方を変える 

特性 異なる機能があわさった プロダクト アーキテクチャ どうなっているか 

Bill One アーキテクチャ Cloud Run / Backend Service AlloyDB Cloud SQL Cloud Storage Cloud Functions Pub/Sub Cloud Tasks Cloud Load Balancing Datastore Cloud Run / BFF Cloud API Gateway Cloud Load Balancing Cloud Logging / Cloud Monitoring / Error Reporting Cloud Build 

Bill One｜「なくせる」をつくり、全社 働き方を変える 

従来 アーキテクチャ 請求書（受領） 機能 B 機能 D 機能 E 機能 F 請求書管理 領収書 機能 A’ 機能 C 機能 E’ 機能 B 領収書管理 請求書（発行） 機能 D 機能 F 機能 A 請求書管理 テナント管理 機能 E’’’ 機能 F 契約管理 機能 B 機能 D - マイクロサービスアーキテクチャを採用している - 機能領域ごとに一定 重複機能を許容することで、アジリティを確保していた - 機能が増えていく中で機能ごとに微妙な差異が発生していた - 共通であることが明らかな機能 プロダクト 初期開発時点で独立していた ユーザー管理 機能 E’’ 機能 A 機能 C 

従来 アーキテクチャ 請求書（受領） 機能 B 機能 D 機能 E 機能 F 請求書管理 領収書 機能 A’ 機能 C 機能 E’ 機能 B 領収書管理 請求書（発行） 機能 D 機能 F 機能 A 請求書管理 テナント管理 機能 E’’’ 機能 F 契約管理 機能 B 機能 D ユーザー管理 機能 E’’ 移植 過程で過去 反省を 活かしてリアーキテクチャされた 特定 領域にしかないが他 領域でも使いたい 同一 機能が散在している （あるい 共通化されているが移行されていない） 同じ機能が独自 発展をしている 機能 A 機能 C 

従来 アーキテクチャ 請求書（受領） 機能 B 機能 D 機能 E 機能 F 請求書管理 領収書 機能 A’ 機能 C 機能 E’ 機能 B 領収書管理 請求書（発行） 機能 D 機能 F 機能 A 請求書管理 テナント管理 機能 E’’’ 機能 F 契約管理 機能 B 機能 D ユーザー管理 機能 E’’ 移植 過程で過去 反省を 活かしてリアーキテクチャされた 機能 A 機能 C 

従来 アーキテクチャ 請求書（受領） 機能 B 機能 D 機能 E 機能 F 請求書管理 領収書 機能 A’ 機能 C 機能 E’ 機能 B 領収書管理 請求書（発行） 機能 D 機能 F 機能 A 請求書管理 テナント管理 機能 E’’’ 機能 F 契約管理 機能 B 機能 D ユーザー管理 機能 E’’ 特定 領域にしかないが他 領域でも使いたい 機能 A 機能 C 

従来 アーキテクチャ 請求書（受領） 機能 B 機能 D 機能 E 機能 F 請求書管理 領収書 機能 A’ 機能 C 機能 E’ 機能 B 領収書管理 請求書（発行） 機能 D 機能 F 機能 A 請求書管理 テナント管理 機能 E’’’ 機能 F 契約管理 機能 B 機能 D ユーザー管理 機能 E’’ 同じ機能が独自 発展をしている 機能 A 機能 C 

従来 アーキテクチャ 請求書（受領） 機能 B 機能 D 機能 E 機能 F 請求書管理 領収書 機能 A’ 機能 C 機能 E’ 機能 B 領収書管理 請求書（発行） 機能 D 機能 F 機能 A 請求書管理 テナント管理 機能 E’’’ 機能 F 契約管理 機能 B 機能 D ユーザー管理 機能 E’’ 同一 機能が散在している （あるい 共通化されているが移行されていない） 機能 A 機能 C 

理想 アーキテクチャ 請求書（受領） 請求書管理 領収書 領収書管理 請求書（発行） 請求書管理 Service Platform 機能 A'’ 機能 B 機能 C 機能 D 機能 E 機能 F 契約管理 ユーザー管理 テナント管理 - 各マイクロサービスが適切な粒度と抽象度で独立している - 共通機能を利用する機能 開発が効率化されている - 機能 保守コストが下がっている 共通機能が Service Platform として、ユーザーへ 価値提供まで 時間を加速できている 

Bill One における Service Platform 開発 何をしているか 

- 各機能領域 価値を強化する共通機能を提供する - ワークフロー - 仕訳 - 通知 - 認証・認可 - 法対応 - 各機能領域を独立したプロダクトとして、効率よく開発できる状態にする - 適切な結合度や依存方向をつくる - Service Platform として 契約を提供する - 使いやすい仕組みを提供する Service Platform 役割 

ユースケース: 請求書に紐づく仕訳を作成し、仕訳 状態で請求書を検索する。 適切な結合度と依存方向 請求書に紐づく 仕訳を作成する 仕訳が確定したら 請求書 状態を更新する 請求書に紐づく 仕訳を作成する 仕訳が確定した ことを通知する 通知を購読して 請求書を更新する 請求書管理機能 API 仕訳機能 API Pub/Sub 請求書管理機能 仕訳機能 API 仕訳機能 共通機能だが、 利用側を知っている必要がある 仕訳機能 仕訳を作成する API と Pub/Sub を公開しているだけで、 利用サービス こと 知る必要がない 

ユースケース: テナント解約に伴う処理を各マイクロサービスで確実に実行する。 Service Platform として 契約 提供 処理完了を連携する 解約処理を起動する サービス A API サービス B API テナント管理サー ビス API 解約可能なことを通知する 通知を購読してサービス ごと 解約処理を実行する サービス A サービス B テナント管理サー ビス API Pub/Sub テナント管理サービス すべて サービスで 解約処理が完了したことを保証する責務を持つ テナント管理サービス 確実に解約対象を 通知することを責務とし、サービスにおける処理 責務 それぞれ サービスが持つ 

ユースケース: テナント単位で実行するバッチ処理をスケーラビリティを確保して起動する。 使いやすい仕組み 提供 サービス A Cloud Tasks テナント 数だけタスクを作成する テナント単位 バッチ処理を実行する サービス A Cloud Tasks テナント 数にかかわらず 1 度だけ API を実行する テナント単位 バッチ処理を実行する バッチ処理 サービス テナント単位 タスクを作成する バッチ処理 種類ごとに数万件 テナントを逐次的 に処理するため 工夫（ファンアウトやチャンク処理 など）が必要になる 典型的なバッチ処理 パターンであるテナント単位 実行をサービスとして提供して、重複実装が不要 な状態になる API 

- Bill One Service Platform で 機能 独立性を高めることで中長期的に機能提供が加速 する状態を目指している - 機能 独立性において 、各機能領域から見たときに SaaS/PaaS を使っているような関係性 を意識している - ユーザーに対して間接的に価値を提供するチームとして、直接的な機能を開発するチームに対 して価値を提供しなけれ ならない まとめ 

Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/ 

No content