4年で17倍に成長したエンジニア組織を支えるアーキテクチャの過去と未来

Slide 1

Slide 1 text

Sansan株式会社部署名前 4年で17倍に成⻑したエンジニア組織を⽀えるアーキテクチャの過去と未来 Sansan技術本部アーキテクチャ Conference2024 Sansan株式会社技術本部 Bill One Engineering Unit 加藤耕太 / 柳浦豊

Slide 2

Slide 2 text

Bill Oneアーキテクチャのこれまで

Slide 3

Slide 3 text

写真が入ります加藤耕太（Kota Kato） Sansan株式会社技術本部 Bill One Engineering Unit＠関⻄⽀店 Sansan株式会社所属のソフトウェアエンジニア。インボイス管理サービス「Bill One」のアーキテクトとして、技術選定から⽴ち上げに関わり、現在に⾄るまで開発および技術マネジメントに従事。趣味: 散歩、ゲーム、美術館

Slide 4

Slide 4 text

Bill Oneの概要

Slide 5

Slide 5 text

Bill Oneは、Sansan株式会社が提供するインボイス管理サービスです。郵送やメールといったさまざまな⽅法・形式で届く請求書をオンラインで⼀括受領し、素早く正確にデータ化。請求書をクラウド上で⼀元管理することで、アナログで⾮効率な請求書業務をデジタル化します。インボイス制度や電⼦帳簿保存法にも対応し、⽉次決算業務を効率化することで、企業経営における意思決定のスピードを加速します。 ※⽉次決算業務毎⽉の営業成績、財政状況を明らかにするために⾏われる業務。経理担当者が⾏う業務で、毎⽉の数字の締め処理作業として発⽣します。

Slide 6

Slide 6 text

請求書発⾏経費精算請求書受領⽉次決算を加速する 5

Slide 7

Slide 7 text

Bill OneのARR（年間固定収⼊）推移リリースから約4年、T2D3※を超える成⻑速度を⾒せている ※ サービスをスタートしてからの売上額が、前年を基準として毎年3倍・3倍・2倍・2倍・2倍と上昇し、5年間で72倍の売上成⻑を⽬指すという意味。理想的なSaaSの成⻑モデルとされる。 (百万円） 237 1392 3798 7680 Bill OneのARR T2D3達成ライン

Slide 8

Slide 8 text

Bill Oneがもたらすさらなる価値｜ネットワークインボイスネットワークには、すでに数万社を超える企業が参加取引先も含めた請求書業務の加速を実現しています

Slide 9

Slide 9 text

エンジニア組織の拡⼤

Slide 10

Slide 10 text

4年間でのエンジニア組織の成⻑ 83 名 5 名 20 チーム 1 チーム 2020年9⽉ 2024年9⽉海外拠点 Sansan Global Development Center, Inc. （フィリピン）約 50 名

Slide 11

Slide 11 text

Bill Oneのアーキテクチャ

Slide 12

Slide 12 text

技術スタックフロントエンド / BFF サーバーサイドインフラデータベースドキュメント React express ツール chromatic GitHub Copilot

Slide 13

Slide 13 text

アーキテクチャ Email Cloud Load Balancing Backend Cloud Run Database Cloud SQL Static Files Cloud Storage Cloud Tasks API Gateway Cloud Load Balancing API Client User Logging Error Reporting Cloud Build Bill One Entry Management / Developer Tools Cloud Functions Monitoring Authentication Auth0 Login Screen Frontend / BFF Cloud Run Pub/Sub

Slide 14

Slide 14 text

基本的な⽅針 - 静的型付き⾔語を選択することで保守しやすくする - クラウドサービスのマネージドサービスを活⽤することで、運⽤の負荷を下げる - マイクロサービスに分割することで、チーム単位で素早く機能を開発できるようにする

Slide 15

Slide 15 text

Bill Oneのマイクロサービス

Slide 16

Slide 16 text

最初期を除いて、チーム数 >= 主要マイクロサービス数マイクロサービスの増加

Slide 17

Slide 17 text

- 初期メンバーに⼤きなモノリスのメンテナンスに苦労した経験があった - ビジネスが成功してから分割するのって、実際のところかなり⼤変では？ - プロダクトのピボットに伴い、コードを⼤きく書き換える機会があった - 最初期の実装（Python）から⾔語を変更したいモチベーションがあった - 請求書の送付側と受領側で⼤きく分けられそうな感触があった - モジュラモノリスにした上で、結合を阻⽌し続ける⾃信がなかった初期からマイクロサービスにした理由

Slide 18

Slide 18 text

- 主要マイクロサービスは業務ドメインで分割する - 細かい機能単位のマイクロサービスもある - マイクロサービスごとにデータベースを分ける - 主要マイクロサービスはなるべく同期的なAPI呼び出しを避け、⾮同期通信での連携を基本とする - フロントエンドからは、BFF (API Gatewayのようなもの) を経由してアクセスする - サービスごとの独⾃性と全体としての統⼀感のバランスをとるマイクロサービスの⽅針

Slide 19

Slide 19 text

- Kotlin - 主要なマイクロサービス - Go - 起動速度が重要なマイクロサービス - Go周辺で発達したエコシステムを活⽤したいマイクロサービス - 細かい機能単位のマイクロサービス - (TypeScript) - フロントエンド、BFF - Node.js周辺で発達したエコシステムを活⽤したいマイクロサービスマイクロサービスの言語

Slide 20

Slide 20 text

複数のサービスのソースコードを1リポジトリで管理するMonorepo構成を採⽤している Monorepoのメリット - CI/CDの仕組みを統⼀して管理しやすい - 複数のマイクロサービスにまたがる変更が容易 MonorepoのCI/CD - GitHub Actionsの dorny/paths-filter を使って、差分があるサービスのみ CI/CD を実⾏ - ディレクトリに配置された特定のファイルでマイクロサービスを発⾒し、filter を⾃動⽣成する - 差分がなくても再実⾏できるよう、manual triggerを組み合わせると便利 Monorepo

Slide 21

Slide 21 text

当初 - 共通ライブラリを作らず、サービス間でのコピペを許容する⽅針だった - 不要な結合を排除し、サービスごとの独⽴性を重視するため現在 - 1年前に共通ライブラリを導⼊ - データベース周り、Webフレームワーク周り、その他ユーティリティなど、共通で使いたいものが固まってきたので - ソースコードレベルでは結合せず、Gradleなどのライブラリとして利⽤ - ライブラリの変更を受け⼊れるタイミングをサービス側で制御できるように共通ライブラリ

Slide 22

Slide 22 text

- リリースカレンダーを抑えて、チームごとに⾃由にリリース - マイクロサービスは独⽴してリリース可能リリース 10⽉のとある5営業⽇のカレンダーアイテム (74件)

Slide 23

Slide 23 text

技術的な課題

Slide 24

Slide 24 text

技術的な課題 - トラフィック増加への対応 - マイクロサービス肥⼤化への対応 - サービス品質の向上

Slide 25

Slide 25 text

トラフィック増加への対応 - ⼀番の主要機能である請求書受領を担当するマイクロサービスへのアクセスが多い - 当該マイクロサービスのデータベースインスタンスのスケールアップが限界に近づいている - クエリのパフォーマンスチューニングなど、負荷を減らすための改善は実施している - 今後は、より抜本的な改善施策が必要現状対応

Slide 26

Slide 26 text

マイクロサービス肥⼤化への対応⼀番の主要機能である請求書受領を担当するマイクロサービスはコード規模も⼤きく、メンテナンスが困難 - コードはモジュール分割を⾏った - データベース分割までは⾏えていない現状対応

Slide 27

Slide 27 text

サービス品質の向上⼀時期、変更障害率が⾼い状況が続いていた - ポストモーテム⽂化の醸成 - QA体制を強化してきた - 複雑度が⾼いコードが存在するので、プロジェクトチームで改善中現状対応

Slide 28

Slide 28 text

- ビジネスが成⻑している - 開発組織も成⻑している - マイクロサービスの取り組みによって開発速度を維持してきた - しかし技術的課題はあるここまでのまとめ

Slide 29

Slide 29 text

Bill Oneアーキテクチャのこれから

Slide 30

Slide 30 text

写真が入ります柳浦豊 Sansan 株式会社技術本部 Bill One Engineering Unit Core Business AR グループアーキテクト 2022年に Sansanに中途⼊社し、⼊社以来 Webアプリケーション開発エンジニアとして Bill Oneの開発に従事しています。マイクロサービスや CI/CDに興味・関⼼があります。キーボード沼にハマりつつあります。 29

Slide 31

Slide 31 text

アーキテクチャの「これから」を3つの視点で考えるビジネス組織技術

Slide 32

Slide 32 text

- 潜在市場規模としては⼤きな余地がある - 現在の有料契約件数は3000件超 - 請求書受領を⾜がかりにして契約件数をさらに伸ばしていくビジネスの状況「Bill One」潜在市場規模 (1)「令和3年経済センサス活動調査」総務省統計局 (2) 有料契約件数＋無料件数＋有料・無料ユーザーに対して請求書を送付する企業数「Bill One」有料契約件数インボイスネットワーク参画企業数 (2) 請求書発行企業／「Bill One」ユーザー企業 3,033 約 200万「Bill One」潜在市場規模（日本国内の企業数 (1)）約 19.3万

Slide 33

Slide 33 text

- ⽇本国内 - Bill Oneエンジニア：約80名 - 海外拠点 - 2023年、フィリピン・セブ島にSGDC (Sansan Global Development Center, Inc) を設⽴ - Bill Oneエンジニア：約50名 - 国内・海外ともに採⽤活動を積極的に展開中 - 今後もエンジニアは継続的に増やしていきたい開発組織の状況：規模をさらに拡⼤しグローバルな組織へ SGDCのオフィス

Slide 34

Slide 34 text

技術の状況 - 技術的な課題 - トラフィック増加への対応 - サービス品質の向上 - マイクロサービス肥⼤化への対応

Slide 35

Slide 35 text

これまでのアーキテクチャを振り返るビジネス組織技術 Good 受領を中⼼に契約を伸ばしている。受領だけでなく、発⾏、経費精算の業務領域にも広げられている国内外合わせた130名体制まではスケールし、⾃律したチームを形成できているマイクロサービスアーキテクチャを採⽤することで、ビジネス規模と領域の拡⼤に適応できている More 業務領域それぞれで今以上に顧客獲得するために、顧客価値提供を加速していく必要がある開発メンバーとチームが増える中で、保守性を維持するための設計⽅針・設計ガイドが浸透しにくくなっているサービス品質とサービス肥⼤化という2つの課題を切り⼝に、アーキテクチャを⾒直したい

Slide 36

Slide 36 text

- これまでのBill One開発からの学び - ⻑期の将来予測は困難。銀⾏代理業まで⼿を広げることは当初の想定外 - これからも、ビジネス、組織、技術すべてが絶え間なく変化する中で試⾏錯誤を繰り返していくことになる - ⻑期計画に基づく先⾏投資は柔軟性を妨げるリスクにもなりえる - 使われない機能や作り込み、オーバースペックな設計は技術的負債を増⼤させる原因となるこれからのアーキテクチャをどのように考えていくか

Slide 37

Slide 37 text

- 「予測しない＝受け⾝」ではない - 変化に反応し続けるだけでは、つぎはぎされた複雑な設計となり、開発速度は緩やかに劣化していく - 変化そのものは予測できなくとも、「変化をどう受け⼊れるか」は意図的に制御できるのではないか - 意図＝何を柔軟にして何を不変にするか - システムの将来の「形」は柔軟に変えていきたいが、重要なシステムの「性質」は維持し続けたい - KotlinやCloud Runという「形」は、重要な「品質特性」を満たす限りは柔軟に変えてもよい変化を受け⼊れ適応するためのアーキテクチャ設計システムが継続的に満たすべき品質特性をアーキテクチャに組み込む

Slide 38

Slide 38 text

進化的アーキテクチャと適応度関数

Slide 39

Slide 39 text

- 進化的アーキテクチャ - ビジネスや技術の絶え間ない変化に応じられるよう、変化を⽀える仕組みを組み込んだアーキテクチャ - 「漸進的な変更」「適応度関数」「適切な結合」の3つの側⾯ - アーキテクチャ適応度関数 - 対象システムが「望ましい特性」をどの程度満たしているかを客観的あるいは主観的に評価する - アーキテクチャの品質特性 - さまざまな特性ʼ-ilitiesʼがアーキテクチャには求められる - 例: modifiability,observability, agility, accessibility, … - 特性の多くはトレードオフの関係にあり、すべてを最⼤化することは難しい進化的アーキテクチャと適応度関数

Slide 40

Slide 40 text

Bill One アーキテクチャシステムの変更 Pull Request - システムのデプロイメントパイプラインに適応度関数を組み込む - -ilityを劣化させる「望ましくない変化」からシステムを保護できる - 適応度関数を通じて、システムの変化の⽅向性にアーキテクトの意図を持たせることができる適応度関数をデプロイメントパイプラインに組み込む -ilities 適応度関数

Slide 41

Slide 41 text

- Being(どうあり続けたいか) - ビジネス要求に迅速に応えられるアーキテクチャであり続けたい - サイクルタイムに影響する品質特性を重視する - 保守性 - 劣化すると変更が困難になり、開発速度が低下する - テスト容易性 - 劣化するとリファクタリングが困難になり、保守性が劣化する - 疎結合性 - 劣化すると変更の影響範囲が広がることで複数チームでの調整が必要になり、開発速度が低下する⽬指すBeingとアーキテクチャの品質特性

Slide 42

Slide 42 text

- 現状 - コントローラ／アプリケーション／ドメイン／インフラの4層における責務と依存の⽅向性を開発⽅針として定義することで、保守性を担保している - 課題 - 開発初期は⽅針が浸透していたことで遵守できていたが、開発者組織の規模拡⼤に伴い、守れていないケースが増えてきた - ⽅針の浸透不⾜により、保守性が劣化しつつある - 適応度関数 - 依存関係チェックをビルドプロセスに統合し、違反をビルド時に検出 - Kotlinの静的解析ツール Detektのカスタムルールで独⾃のimportルールをチェックするプラグインを実装事例1: レイヤ依存のルールがすべてのサービスで維持されるようにする

Slide 43

Slide 43 text

- 現状 - 統合テストを重視し、モックを極⼒使わずすべてのレイヤを結合し、より多くのプロダクションコードをテストしている - 統合テストと単体テストのコード⾏数の⽐率は2 : 1 - 課題 - 統合テストに偏り過ぎており、テストコードの実装と保守が⾼コスト化 - 適応度関数 - レイヤごとに異なるテストカバレッジ基準値を適⽤ - コントローラレイヤ：統合テスト中⼼。ハッピーパスを通す程度のカバレッジ基準値 - ドメインレイヤ：単体テストで⾼いカバレッジ基準値事例2: テストピラミッドの⽐重を最適化する統合テスト単体テストハッピーパス中⼼に広く結合するテスト E2E 統合テスト単体テストドメインロジックや複雑なロジックをテスト E2E 参考：Vladimir Khorikov, 須⽥智之『単体テストの考え⽅/使い⽅』, マイナビ出版

Slide 44

Slide 44 text

- 今以上に業務ドメインに即したアーキテクチャであり続けたい - これまで：チームごとにモデリング⼿法が異なり、業務分析が不⾜しているケースもあった - これから：共通の開発プロセスにイベントストーミングというDDDのモデリング⼿法を組み込む - 今以上に疎結合なアーキテクチャであり続けたい - これまで：APIにスキーマがなく、API利⽤側との互換性管理が困難 - これから：Connect (gRPC互換API)を使ったスキーマ定義の導⼊を検討中これから⽬指すBeing

Slide 45

Slide 45 text

アーキテクチャとWell-being

Slide 46

Slide 46 text

- コンウェイの法則が⽰す通り、アーキテクチャと組織・⼈のあり⽅は密接に関係している - 継続的な進化にはアーキテクチャと組織・⼈がどのように相互作⽤するかを理解する視点もまた重要 - 書籍『ウェルビーイングのつくりかた「わたし」と「わたしたち」をつなぐデザインガイド』をヒントに考える Well-being: アーキテクチャと組織・⼈のあり⽅（ビー・エヌ・エヌ新社 | 渡邊淳司ワタナベジュンジ(著/文)ドミニク・チェンドミニクチェン(著/文) ）

Slide 47

Slide 47 text

Well-beingの3つの「ゆ」ゆらぎ固有の⽂脈を踏まえたうえで、適切なタイミングの変化をもたらすか適時性、固有性ゆだね⾃律性を尊重したうえで、望ましいゆだねのレベルになっているか⾃律性ゆとり⽬的だけでなく経験そのものの価値を感じ取れるか内在性

Slide 48

Slide 48 text

- ゆらぎ - 機能追加と技術的負債返済の適切なバランスは、事業領域の状況によって異なってよい。すべてのマイクロサービスが同じバランスである必要はない - ゆだね - マイクロサービスチームが⾃律的に意思決定できるよう技術⽅針を定めつつも、⽅針外の意思決定はチームに任せている - 周りに相談しつつも最後は⾃分で決める組織⽂化がある - ゆとり - ⽇々の開発の過程での学びをみんなと共有するラーニングセッション - ⾃分で改善したいことを決めて取り組むエンハンスウィーク Bill Oneにとって、マイクロサービスアーキテクチャはチームがオーナーシップを持って⾃律的に活動するためにこれからも重要 Bill Oneにおける、ゆらぎ・ゆだね・ゆとり

Slide 49

Slide 49 text

- Bill Oneアーキテクチャのこれまで - ビジネスが成⻑している - 開発組織も成⻑している - マイクロサービスの取り組みによって開発速度を維持してきた - しかし技術的課題はある - Bill Oneアーキテクチャのこれから - ⽬指すのはビジネスの変化に対して継続的に素早く適応できるアーキテクチャ - 変化を柔軟に受け⼊れつつも、望ましい状態を維持できる仕組みをアーキテクチャに組み込んでいくまとめ

Slide 50

Slide 50 text

Bill Oneエンジニア採⽤情報 https://media.sansan-engineering.com/billone-engineer サービスの成⻑とともに多くの課題が⽣まれています。この挑戦を楽しみながら⼀緒に解決していきましょう！

Slide 51

Slide 51 text

No content