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

■ イベント
アーキテクチャConference 2024
https://architecture-con.findy-tools.io/

■ 発表者
技術本部 Bill One Engineering Unit
加藤 耕太 / 柳浦 豊

■ Bill Oneエンジニア 採用情報
https://media.sansan-engineering.com/billone-engineer

■ Sansan Tech Blog
https://buildersbox.corp-sansan.com/

Transcript

1. Sansan株式会社 部署 名前 4年で17倍に成⻑したエンジニア 組織を⽀えるアーキテクチャの 過去と未来 Sansan技術本部 アーキテクチャ Conference2024 Sansan株式会社 技術本部 Bill One Engineering Unit 加藤 耕太 / 柳浦 豊
2. Bill Oneアーキテクチャの これまで
3. 写真が入ります 加藤 耕太（Kota Kato） Sansan株式会社 技術本部 Bill One Engineering Unit＠関⻄⽀店 Sansan株式会社所属のソフトウェアエンジニア。 インボイス管理サービス「Bill One」のアーキテク トとして、技術選定から⽴ち上げに関わり、現在に ⾄るまで開発および技術マネジメントに従事。 趣味: 散歩、ゲーム、美術館
4. Bill Oneの概要
5. Bill Oneは、Sansan株式会社が提供するインボイス管理サービスです。 郵送やメールといったさまざまな⽅法・形式で届く請求書をオンラインで⼀括受領し、素早く正確にデータ化。請求書を クラウド上で⼀元管理することで、アナログで⾮効率な請求書業務をデジタル化します。インボイス制度や電⼦帳簿保存法にも対応し、⽉次決算業務 を効率化することで、企業経営における意思決定のスピードを加速します。 ※⽉次決算業務 毎⽉の営業成績、財政状況を明らかにするために⾏われる業務。経理担当者が⾏う業務で、毎⽉の数字の締め処理作業として発⽣します。
6. 請求書 発⾏ 経費 精算 請求書 受領 ⽉次決算を加速する 5
7. Bill OneのARR（年間固定収⼊）推移 リリースから約4年、T2D3※を超える成⻑速度を⾒せている ※ サービスをスタートしてからの売上額が、前年を基準として毎年3倍・3倍・2倍・2倍・2倍と上昇し、5年間で72倍の売上成⻑を⽬指すという意味。 理想的なSaaSの成⻑モデルとされる。 (百万円） 237 1392 3798 7680 Bill OneのARR T2D3達成ライン
8. Bill Oneがもたらすさらなる価値｜ネットワーク インボイスネットワークには、すでに数万社を超える企業が参加 取引先も含めた請求書業務の加速を実現しています
9. エンジニア組織の拡⼤
10. 4年間でのエンジニア組織の成⻑ 83 名 5 名 20 チーム 1 チーム 2020年9⽉ 2024年9⽉ 海外拠点 Sansan Global Development Center, Inc. （フィリピン） 約 50 名
11. Bill Oneのアーキテクチャ
12. 技術スタック フロントエンド / BFF サーバーサイド インフラ データベース ドキュメント React express ツール chromatic GitHub Copilot
13. アーキテクチャ 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
14. 基本的な⽅針 - 静的型付き⾔語を選択することで保守しやすくする - クラウドサービスのマネージドサービスを活⽤することで、運⽤の負荷 を下げる - マイクロサービスに分割することで、チーム単位で素早く機能を開発で きるようにする
15. Bill Oneのマイクロサービス
16. 最初期を除いて、チーム数 >= 主要マイクロサービス数 マイクロサービスの増加
17. - 初期メンバーに⼤きなモノリスのメンテナンスに苦労した経験があった - ビジネスが成功してから分割するのって、実際のところかなり⼤変では？ - プロダクトのピボットに伴い、コードを⼤きく書き換える機会があった - 最初期の実装（Python）から⾔語を変更したいモチベーションがあった - 請求書の送付側と受領側で⼤きく分けられそうな感触があった - モジュラモノリスにした上で、結合を阻⽌し続ける⾃信がなかった 初期からマイクロサービスにした理由
18. - 主要マイクロサービスは業務ドメインで分割する - 細かい機能単位のマイクロサービスもある - マイクロサービスごとにデータベースを分ける - 主要マイクロサービスはなるべく同期的なAPI呼び出しを避け、 ⾮同期通信での連携を基本とする - フロントエンドからは、BFF (API Gatewayのようなもの) を経由して アクセスする - サービスごとの独⾃性と全体としての統⼀感のバランスをとる マイクロサービスの⽅針
19. - Kotlin - 主要なマイクロサービス - Go - 起動速度が重要なマイクロサービス - Go周辺で発達したエコシステムを活⽤したいマイクロサービス - 細かい機能単位のマイクロサービス - (TypeScript) - フロントエンド、BFF - Node.js周辺で発達したエコシステムを活⽤したいマイクロサービス マイクロサービスの言語
20. 複数のサービスのソースコードを1リポジトリで管理するMonorepo構成を採⽤している Monorepoのメリット - CI/CDの仕組みを統⼀して管理しやすい - 複数のマイクロサービスにまたがる変更が容易 MonorepoのCI/CD - GitHub Actionsの dorny/paths-filter を使って、差分があるサービスのみ CI/CD を実⾏ - ディレクトリに配置された特定のファイルでマイクロサービスを発⾒し、filter を⾃動⽣成する - 差分がなくても再実⾏できるよう、manual triggerを組み合わせると便利 Monorepo
21. 当初 - 共通ライブラリを作らず、サービス間でのコピペを許容する⽅針だった - 不要な結合を排除し、サービスごとの独⽴性を重視するため 現在 - 1年前に共通ライブラリを導⼊ - データベース周り、Webフレームワーク周り、その他ユーティリティなど、共通で 使いたいものが固まってきたので - ソースコードレベルでは結合せず、Gradleなどのライブラリとして利⽤ - ライブラリの変更を受け⼊れるタイミングをサービス側で制御できるように 共通ライブラリ
22. - リリースカレンダーを抑えて、チームごとに⾃由にリリース - マイクロサービスは独⽴してリリース可能 リリース 10⽉のとある5営業⽇のカレンダーアイテム (74件)
23. 技術的な課題
24. 技術的な課題 - トラフィック増加への対応 - マイクロサービス肥⼤化への対応 - サービス品質の向上
25. トラフィック増加への対応 - ⼀番の主要機能である請求書 受領を担当するマイクロ サービスへのアクセスが多い - 当該マイクロサービスの データベースインスタンスの スケールアップが限界に近づ いている - クエリのパフォーマンスチ ューニングなど、負荷を減 らすための改善は実施 している - 今後は、より抜本的な改善 施策が必要 現状 対応
26. マイクロサービス肥⼤化への対応 ⼀番の主要機能である請求書 受領を担当するマイクロ サービスはコード規模も ⼤きく、メンテナンスが困難 - コードはモジュール分割を⾏ った - データベース分割までは ⾏えていない 現状 対応
27. サービス品質の向上 ⼀時期、変更障害率が⾼ い状況が続いていた - ポストモーテム⽂化の醸成 - QA体制を強化してきた - 複雑度が⾼いコードが 存在するので、プロジェク トチームで改善中 現状 対応
28. - ビジネスが成⻑している - 開発組織も成⻑している - マイクロサービスの取り組みによって開発速度を維持してきた - しかし技術的課題はある ここまでのまとめ
29. Bill Oneアーキテクチャの これから
30. 写真が入ります 柳浦 豊 Sansan 株式会社 技術本部 Bill One Engineering Unit Core Business AR グループ アーキテクト 2022年に Sansanに中途⼊社し、⼊社以来 Webアプリケ ーション開発エンジニアとして Bill Oneの開発に従事して います。 マイクロサービスや CI/CDに興味・関⼼があります。 キーボード沼にハマりつつあります。 29
31. アーキテクチャの「これから」を3つの視点で考える ビジネス 組織 技術
32. - 潜在市場規模としては⼤きな余地がある - 現在の有料契約件数は3000件超 - 請求書受領を⾜がかりにして契約件数をさらに伸ばしていく ビジネスの状況 「Bill One」潜在市場規模 (1)「令和3年経済センサス活動調査」総務省統計局 (2) 有料契約件数＋無料件数＋有料・無料ユーザーに対して請求書を送付する企業数 「Bill One」 有料契約件数 インボイスネットワーク参画企業数 (2) 請求書発行企業 ／ 「Bill One」 ユーザー企業 3,033 約 200万 「Bill One」潜在市場規模 （日本国内の企業数 (1)） 約 19.3万
33. - ⽇本国内 - Bill Oneエンジニア：約80名 - 海外拠点 - 2023年、フィリピン・セブ島にSGDC (Sansan Global Development Center, Inc) を設⽴ - Bill Oneエンジニア：約50名 - 国内・海外ともに採⽤活動を積極的に展 開中 - 今後もエンジニアは継続的に増やしてい きたい 開発組織の状況：規模をさらに拡⼤しグローバルな組織へ SGDCのオフィス
34. 技術の状況 - 技術的な課題 - トラフィック増加への対応 - サービス品質の向上 - マイクロサービス肥⼤化への対応
35. これまでのアーキテクチャを振り返る ビジネス 組織 技術 Good 受領を中⼼に契約を伸ばして いる。受領だけでなく、発⾏、 経費精算の業務領域にも広げ られている 国内外合わせた130名体制まで はスケールし、⾃律したチーム を形成できている マイクロサービスアーキテクチャ を採⽤することで、ビジネス規模 と領域の拡⼤に適応できている More 業務領域それぞれで今以上に 顧客獲得するために、顧客価 値提供を加速していく必要が ある 開発メンバーとチームが増える 中で、保守性を維持するための 設計⽅針・設計ガイドが浸透し にくくなっている サービス品質とサービス肥⼤化と いう2つの課題を切り⼝に、アーキ テクチャを⾒直したい
36. - これまでのBill One開発からの学び - ⻑期の将来予測は困難。銀⾏代理業まで⼿を広げることは当初の想定外 - これからも、ビジネス、組織、技術すべてが絶え間なく変化する中で試⾏ 錯誤を繰り返していくことになる - ⻑期計画に基づく先⾏投資は柔軟性を妨げるリスクにもなりえる - 使われない機能や作り込み、オーバースペックな設計は技術的負債を増⼤ させる原因となる これからのアーキテクチャをどのように考えていくか
37. - 「予測しない＝受け⾝」ではない - 変化に反応し続けるだけでは、つぎはぎされた複雑な設計となり、 開発速度は緩やかに劣化していく - 変化そのものは予測できなくとも、「変化をどう受け⼊れるか」は 意図的に制御できるのではないか - 意図＝何を柔軟にして何を不変にするか - システムの将来の「形」は柔軟に変えていきたいが、重要なシステムの「性質」 は維持し続けたい - KotlinやCloud Runという「形」は、重要な「品質特性」を満たす限りは 柔軟に変えてもよい 変化を受け⼊れ適応するためのアーキテクチャ設計 システムが継続的に満たすべき品質特性をアーキテクチャに組み込む
38. 進化的アーキテクチャと適応度関数
39. - 進化的アーキテクチャ - ビジネスや技術の絶え間ない変化に応じられるよう、変化を⽀える仕組みを 組み込んだアーキテクチャ - 「漸進的な変更」「適応度関数」「適切な結合」の3つの側⾯ - アーキテクチャ適応度関数 - 対象システムが「望ましい特性」をどの程度満たしているかを客観的 あるいは主観的に評価する - アーキテクチャの品質特性 - さまざまな特性ʼ-ilitiesʼがアーキテクチャには求められる - 例: modifiability,observability, agility, accessibility, … - 特性の多くはトレードオフの関係にあり、すべてを最⼤化することは難しい 進化的アーキテクチャと適応度関数
40. Bill One アーキテクチャ システムの 変更 Pull Request - システムのデプロイメントパイプラインに適応度関数を組み込む - -ilityを劣化させる「望ましくない変化」からシステムを保護できる - 適応度関数を通じて、システムの変化の⽅向性に アーキテクトの意図を持たせることができる 適応度関数をデプロイメントパイプラインに組み込む -ilities 適応度関数
41. - Being(どうあり続けたいか) - ビジネス要求に迅速に応えられるアーキテクチャであり続けたい - サイクルタイムに影響する品質特性を重視する - 保守性 - 劣化すると変更が困難になり、開発速度が低下する - テスト容易性 - 劣化するとリファクタリングが困難になり、保守性が劣化する - 疎結合性 - 劣化すると変更の影響範囲が広がることで複数チームでの調整が必要になり、 開発速度が低下する ⽬指すBeingとアーキテクチャの品質特性
42. - 現状 - コントローラ／アプリケーション／ドメイン／インフラの4層における責務 と依存の⽅向性を開発⽅針として定義することで、保守性を担保している - 課題 - 開発初期は⽅針が浸透していたことで遵守できていたが、開発者組織の規模 拡⼤に伴い、守れていないケースが増えてきた - ⽅針の浸透不⾜により、保守性が劣化しつつある - 適応度関数 - 依存関係チェックをビルドプロセスに統合し、違反をビルド時に検出 - Kotlinの静的解析ツール Detektのカスタムルールで独⾃のimportルールを チェックするプラグインを実装 事例1: レイヤ依存のルールがすべてのサービスで維持されるようにする
43. - 現状 - 統合テストを重視し、モックを極⼒使わず すべてのレイヤを結合し、より多くの プロダクションコードをテストしている - 統合テストと単体テストのコード⾏数の⽐率は2 : 1 - 課題 - 統合テストに偏り過ぎており、 テストコードの実装と保守が⾼コスト化 - 適応度関数 - レイヤごとに異なるテストカバレッジ基準値を適⽤ - コントローラレイヤ：統合テスト中⼼。ハッピー パスを通す程度のカバレッジ基準値 - ドメインレイヤ：単体テストで⾼いカバレッジ 基準値 事例2: テストピラミッドの⽐重を最適化する 統合テスト 単体テスト ハッピーパス中⼼に広 く結合するテスト E2E 統合テスト 単体テスト ドメインロジックや 複雑なロジックをテスト E2E 参考：Vladimir Khorikov, 須⽥智之『単体テストの考え⽅/使い⽅』, マイナビ出版
44. - 今以上に業務ドメインに即したアーキテクチャであり続けたい - これまで：チームごとにモデリング⼿法が異なり、業務分析が不⾜している ケースもあった - これから：共通の開発プロセスにイベントストーミングというDDDの モデリング⼿法を組み込む - 今以上に疎結合なアーキテクチャであり続けたい - これまで：APIにスキーマがなく、API利⽤側との互換性管理が困難 - これから：Connect (gRPC互換API)を使ったスキーマ定義の導⼊を検討中 これから⽬指すBeing
45. アーキテクチャとWell-being
46. - コンウェイの法則が⽰す通り、アーキテクチャと組織・⼈のあり⽅は 密接に関係している - 継続的な進化にはアーキテクチャと組織・⼈がどのように相互作⽤する かを理解する視点もまた重要 - 書籍『ウェルビーイングのつくりかた 「わたし」と「わたしたち」を つなぐデザインガイド』をヒントに考える Well-being: アーキテクチャと組織・⼈のあり⽅ （ ビー・エヌ・エヌ新社 | 渡邊淳司ワタナベジュンジ(著/文)ドミニク・チェンドミニクチェン(著/文) ）
47. Well-beingの3つの「ゆ」 ゆらぎ 固有の⽂脈を踏まえたうえで、適切 なタイミングの変化をもたらすか 適時性、固有性 ゆだね ⾃律性を尊重したうえで、望ましい ゆだねのレベルになっているか ⾃律性 ゆとり ⽬的だけでなく経験そのものの価値 を感じ取れるか 内在性
48. - ゆらぎ - 機能追加と技術的負債返済の適切なバランスは、事業領域の状況によって 異なってよい。すべてのマイクロサービスが同じバランスである必要はない - ゆだね - マイクロサービスチームが⾃律的に意思決定できるよう技術⽅針を定めつつも、⽅ 針外の意思決定はチームに任せている - 周りに相談しつつも最後は⾃分で決める組織⽂化がある - ゆとり - ⽇々の開発の過程での学びをみんなと共有するラーニングセッション - ⾃分で改善したいことを決めて取り組むエンハンスウィーク Bill Oneにとって、マイクロサービスアーキテクチャはチームが オーナーシップを持って⾃律的に活動するためにこれからも重要 Bill Oneにおける、ゆらぎ・ゆだね・ゆとり
49. - Bill Oneアーキテクチャのこれまで - ビジネスが成⻑している - 開発組織も成⻑している - マイクロサービスの取り組みによって開発速度を維持してきた - しかし技術的課題はある - Bill Oneアーキテクチャのこれから - ⽬指すのはビジネスの変化に対して継続的に素早く適応できるアーキテクチャ - 変化を柔軟に受け⼊れつつも、望ましい状態を維持できる仕組みをアーキテク チャに組み込んでいく まとめ
50. Bill Oneエンジニア 採⽤情報 https://media.sansan-engineering.com/billone-engineer サービスの成⻑とともに 多くの課題が⽣まれてい ます。この挑戦を楽しみ ながら⼀緒に解決してい きましょう！