"統合ERP"とアプリケーションアーキテクチャ

2024年 freee技術の日で使用した登壇スライドです。
session archive: https://www.youtube.com/live/Vih4vuNxPT4?si=ZCxIcz6wGu6J0Sxo&t=9300

Transcript

1. "統合ERP"と アプリケーションアーキテクチャ 友澤啓太(tomoz) 2024年6⽉1⽇
2. 2 友澤啓太(tomoz)
 新卒で入社したSIerでweb/モバイル等 の開発に携わった後、2019年にfreeeに join。入社後は2つの新規プロダクトの立 ち上げに関わり、現在は統合基盤チーム というプロダクト横断で利用される共通機 能を開発するチームに在籍する。
 Engnieering Manager
3. 早速質問 新卒で⼊社したSIerでweb/モバイル等の開発に携わっ た後、2019年にfreeeにjoin。⼊社後は2つの新規プロダ クトの⽴ち上げに関わり、現在は統合基盤チームという プロダクト横断で利⽤される共通 機能を開発するチームに在籍する。
4. • 「統合基盤チームというプロダクト横断で利用される共通機能を開発する チーム」、どんなチームか想像できますか？ ◦ インフラ？認証認可？DX系のなにか？どれも違います • freeeにおけるソフトウェアアーキテクチャの概略、会社のビジョンの進化か らでてくる課題に触れながら、どういう目的のためにうまれたチームなの か、どういうことをやっているのかの一例を紹介します。 本日の概要
5. • freeeのビジョン • アーキテクチャのこれまでと現状 • “業務の分断” を起こさない為のドメ イン境界の設定 • 業務ドリブンなドメイン境界がもたら す分断 • 分断を解消するための“繋げる”技術 agenda
6. • freeeのビジョン • アーキテクチャのこれまでと現状 • “業務の分断” を起こさない為のドメ イン境界の設定 • 業務ドリブンなドメイン境界がもたら す分断 • 分断を解消するための“繋げる”技術 agenda
7. 　 7 だれもが⾃由に経営できる 統合型経営プラットフォーム。 だれもが⾃由に⾃然体で経営できる環境をつくるために、「統合型経営プラットフォーム」を開発‧提供します。 バックオフィス業務を統合することで、⾃動化と業務全体の効率化。さらに経営全体を可視化することで、 これまでにないスマートかつ最適なアクションまで実⾏できるプラットフォームへと進化させていきます。 また外部サービスとも連携したオープンプラットフォームとして、多様なビジネスニーズに対応。 ユーザーネットワークの中における相互取引の活性化も強化していきます。 プラットフォームの提供のみならず、スモールビジネスに携わる⼈の環境そのものを より良くしていく取り組みを⾏うことで、世の中の変化を促します。 Vision
8. • freeeは、一つのプロダクトで他社と比較して広い範囲の業務をカバーし、統合体験 を提供 • 加えて、会計、人事労務以外の領域にもプロダクトを展開し、領域を横断した統合体 験を実現 (cf. 2023年6月期 第4四半期決算説明資料より) 幅広い業務・領域において統合体験を提供
9. 経営を阻む3つの「分断」 1
 業務の分断
 例 • 給与の⽀払額を間違えた • 請求額を間違えた 例 • 従業員が紙で提出してくれ ない限り、業務が進まない • 紙のありかがわからない 2
 1
 3
 

10. • 例えば勤怠管理の機能があったとき、勤怠の集計にまつわる課題は解決 するかもしれないが、業務はそこで終わりではなく給与計算またその先に は給与振込と業務は一連の流れとして進んでいく • 単機能をサポートするシステムの利用、またあるいは単機能をサポートす るシステムの複数併用では、この前後の業務の間に発生する転記などの 手作業が発生し、そこのミスは解決できない • →関わる一連の業務を一気通貫でサポートするための “統合型” 経営を阻む三つの分断：業務の分断
11. • 年末調整、またあるいは普段の経費精算などにおいても業務を進める本 人の他に登場人物がいることも多々 • 仮にシステムがその業務をちゃんとサポートしているものであっても、結局 他の人に「このデータちょっと見て！」といった直接のコミュニケーションを 取る必要が出てくるのならばシステム化の恩恵は最大化できない • →システム上で自然とコミュニケーションも繋げるための “統合型” 経営を阻む三つの分断：コミュニケーションの分断
12. • 業務や機能ごとに異なるサービスを使っている場合、「普通に業務をする」 だけであれば、運用でなんとかなるかもしれない • 数字のミスの原因を探りたい、またあるいは経営の改善のために数字をド リルダウンしたい、となった場合システムが分断されているとその境界の間 を跨ぐときにトラッキングが難しくなる • →システム/サービスを跨いでも一貫性をもってデータを蓄積するための統 合型 経営を阻む三つの分断：データの分断
13. • ただのシステム導入では必ずしも「業務の分断」「コミュニケーションの分 断」「データの分断」を解決できない • それらをを解決するための “統合型” • では、そのような “統合型” のアプリケーションを作る上で、どういったポイ ントを意識していけば良いのか • まずはこれまでのアーキテクチャから振り返る why 統合: 経営を阻む3つの分断
14. • freeeのビジョン • アーキテクチャのこれまでと現状 • “業務の分断” を起こさない為のドメ イン境界の設定 • 業務ドリブンなドメイン境界がもたら す分断 • 分断を解消するための“繋げる”技術 agenda
15. • 2013年にfreee会計リリース後、2014年にはfreee人事労務(当時は給与 計算のサービス)をリリース • その過程で、プロダクト間で共有したい基盤系の機能のマイクロサービス 化が進行 ◦ 認証認可・課金等、プロダクトを跨いでも共通であって欲しい機能群 • 一方、個々のサービスはモノリスとして発展 ◦ サービス・組織の発展とともにいわゆるモノリスが故の難点も見えてくる 複数プロダクトの展開と基盤系サービスの発展
16. • サービス・組織の発展とともに増 大したモノリスの辛さに対処すべ く、モジュラモノリスを選択するプ ロダクトが増加 • 新規のプロダクトはもちろん、特に 大規模な既存のプロダクトについ てもゆるやかにモジュラモノリスへ 移行していった モジュラモノリスの広まり
17. • 大雑把な現状のアーキテクチャ ◦ 外向けの “プロダクト”の単位が一つごとにモジュラモノリスのサービス ◦ 基盤系の機能群についてはマイクロサービスで提供 • モジュラモノリスであることの強みとして、プロダクトの進化に合わせてドメ イン理解とともにモジュールの分割粒度を徐々に変えていくことが可能なこ とがあげられる • では、今のアーキテクチャで「3つの分断」は回避できるだろうか？ 現状のアーキテクチャまとめ
18. • freeeのビジョン • アーキテクチャのこれまでと現状 • “業務の分断” を起こさない為のドメ イン境界の設定 • 業務ドリブンなドメイン境界がもたら す分断 • 分断を解消するための“繋げる”技術 agenda
19. • マイクロサービスにせよモジュラモノリスにせよ重要になるのはドメイン境 界の設定 ◦ ドメイン境界≠ユーザーから見たサービス境界ではあるが、間違ったドメイン境界の設 定は「業務の分断」に繋がる • 特に物理的に分割された複数のサービス間で後から重要な結びつきが必 要なことがわかると大変 ◦ 物理的な構成を変えるのももちろん大変だし、物理的な構成を変えないままその重要 な結びつきを表現するもの大変 • では何をもってサービスの境界を設定するか？ ソフトウェアアーキテクチャにまつわる悩み
20. • BtoBの領域は多くのSaaSが出現 するより前からパッケージ製品は もちろん、各企業内製のシステム を作っていたり、広く認知されてい るわけではないが様々な知見が 存在している • その中の一部は書籍などで触れ ることができる BtoBのドメインは先駆者がいる領域 梅田弘之氏著 「グラス片手に~ 」シリーズ 販売管理システム編では、そっくりそのまま使え るわけではないが、業務の説明に加え詳細なレ ベルでのテーブル設計の例が紹介されている
21. • 実現したいユーザーストーリーの積み重ねで考えるのではなく、「こうなって いてほしい」データ構造から考える ◦ 「こうなっていてほしい」に既知の知見が生きる ◦ 先述したような共有知になっているようなものはもちろん、freeeのようにすでに成長し ているプロダクトであれば、その中での運用の肌感も生かせる • ここは絶対にjoinするであるとか、このデータとこのデータのトランザクショ ンは絶対に必要、というようなところからドメイン分割のラインを見極める • なぜデータから考えると良いのか？ データモデリングから考える
22. • 高度に組織化された会社活動では、データを作るために人間が “業務” を 行う ◦ 極論どんぶり勘定で良いのならば財布のお金の増減だけ見れば十分で、管理する必 要のある “業務” は存在しない • そのため、どのようなデータを管理したいのかが業務の流れを理解するの には非常に重要 • ドメインの境界をどこに設定するかについては、大雑把にいえば会計処理 にまつわるところは経理部が勤怠や給与は労務部が、といったように実際 の組織を想像した時に違う部署になるような業務領域は、物理的な結合が 必要なほど強い結びつきにはならないことの方が多い データこそが業務の核
23. • それゆえ、現状の「提供プロダクトごとの(モジュラ)モノリス」という姿が実運 用上もそれなりに理にかなっている • データ・業務を重視することで「業務の分断」が起きにくいドメイン境界の設 定はできそう。では他の2つの分断はどうだろう？ 業務システムにおけるドメイン境界
24. • freeeのビジョン • アーキテクチャのこれまでと現状 • “業務の分断” を起こさない為のドメ イン境界の設定 • 業務ドリブンなドメイン境界がもたら す分断 • 分断を解消するための“繋げる”技術 agenda
25. • そもそも統合ERPであるfreeeを使うメリットは何か • 日々の記帳をし、決算書を作るだけであれば仕訳が打てるシステムがあれ ば十分 • 統合ERPではその先を提供したい。例えば... ◦ 決算がよくなかった→何が原因かを理解し、対策を打ちたい ◦ 営業利益が赤字になったとして、具体的にどの案件での赤字なのか？どんな経過だっ たか？そもそもの見積もりは？ 課題の一例: データの一貫性、トレーサビリティ
26. • つまり、統合ERPの強みはドメインを跨いでもデータが “繋がっている” こと が重要 • 個別のプロダクトでただただ記録をつけているだけでは、プロダクトを跨い だ時にデータの間の関係性が記録できない（意識してそういう運用を敷く必 要がある） • → “データの分断” の一例 課題の一例: データの一貫性、トレーサビリティ
27. • ワークフローにおいては「申請者」と「承認者」の二つの視点がある • 申請者の視点 ◦ 「経費精算申請」をする時は、どういう目的で何にどれだけの金額を使ったかが重要 ▪ 承認された結果、自動的に経費精算の振り込みのデータも作って欲しい ◦ 「有休申請」をする時は、いつ取るかや何日残ってるかなどが重要 ▪ 承認されたら、勝手に勤怠の登録もして欲しい • 申請者からの視点では、どのドメインの申請であるかは重要 ◦ 申請の画面がその申請が属するドメインのサービスにあるのは自然 課題の一例: ユーザーによる視点の差
28. 課題の一例: ユーザーによる視点の差 有休とる から申請 するぞ 出張した から精算 するぞ プロダクトの壁 あちこちに あって大 変だ...
29. • 承認者の視点では、それがどのドメインの申請かは重要ではない • 承認しなければいけないものが数十も溜まっているのに、それが複数のプ ロダクトに分散しているとなかなか大変 • 承認者の視点では、「全部の承認がまとめてみたい」 • 業務ドリブンで設定した境界が、またある人にとっては “分断” に感じられる 例 • → “コミュニケーションの分断” の一例 課題の一例: ユーザーによる視点の差
30. • 素朴にドメインを分割して、そのそれぞれでプロダクトを発展させていくだけ では解決できない “分断” を解決するために様々なことに取り組んでいるの が “統合基盤” チーム • 先ほどのような課題に、具体的にどのような開発を行っているかをご紹介 こうした問題を解消するための基盤が “統合基盤”
31. • freeeのビジョン • アーキテクチャのこれまでと現状 • “業務の分断” を起こさない為のドメ イン境界の設定 • 業務ドリブンなドメイン境界がもたら す分断 • 分断を解消するための“繋げる”技術 ◦ と、解決できていない課題も少しご紹介 agenda
32. • freee販売やfreee請求書では、もともとfreee会計で利用されている取引先 マスタや、各種分析用のタグを利用するようになっている • こうしたプロダクト外にあるマスタを利用するためのクライアントライブラリ や画面で利用する際の専用コンポーネントなどが用意されている • 単にデータの共有を各チームに任せるのではなくセントラルに面倒を見る ことで「共有データの使い方」にもある程度統制を効かせ、どのプロダクト から使っていても違和感のないユーザー体験を実現 トレーサビリティのための “繋げる” 技術
33. • 一方で、マスタを外部にもつとjoinができなかったり、単なる参照のために API経由でのアクセスが必要だったりと何かにつけて不便 • たまに不便、くらいならまだよいが分析のためのタグ等はかなり使用頻度 も高くこの不便さが際立って課題となる • マスタの中央管理と、各プロダクトでの利便性向上のためにどうすればよ いかはまだまだ掘り下げる必要アリ トレーサビリティのための “繋げる” 技術...での課題
34. 申請承認領域における “繋げる” 技術
35. • 承認者の視点ではプロダクトの境界を意識したくない • そのために「すべての承認すべき申請」を集約し、一覧できる機能を提供 • 幾つのプロダクトにまたがって存在する申請を束ねて一覧するために Elasticsearchを利用 • 一覧の必要はあるが、例えばそれらの申請を束ねて承認したい、といった ことはないので、結果整合でElasticsearch等の参照のためのDBに入って いれば十分 ◦ 厳密にはあるかもしれないが、申請を跨いだトランザクションは不要と言えるだろう 申請承認領域における “繋げる” 技術
36. まとめ
37. • これまで様々な経緯を経てたどり着いた現在のプロダクトやドメインの境界 は、 “業務の分断” を起こさないための一定の妥当性があった • これで全ての問題が解決されるわけではなく、プロダクト・ドメインの境界を 跨いで解決しなければいけない課題もあり、そうした課題にアプローチする のが統合基盤チーム • 複数のプロダクト・マイクロサービス間を解決したい課題の特性に合わせて 上手く “繋ぐ” 技術が今後のfreeeでは重要になっていく まとめ