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

by keitatomozawa

Slide 1

Slide 1 text

"統合ERP"とアプリケーションアーキテクチャ友澤啓太(tomoz) 2024年6⽉1⽇

Slide 2

Slide 2 text

2 友澤啓太(tomoz)  新卒で入社したSIerでweb/モバイル等の開発に携わった後、2019年にfreeeに join。入社後は2つの新規プロダクトの立ち上げに関わり、現在は統合基盤チームというプロダクト横断で利用される共通機能を開発するチームに在籍する。  Engnieering Manager

Slide 3

Slide 3 text

早速質問新卒で⼊社したSIerでweb/モバイル等の開発に携わった後、2019年にfreeeにjoin。⼊社後は2つの新規プロダクトの⽴ち上げに関わり、現在は統合基盤チームというプロダクト横断で利⽤される共通機能を開発するチームに在籍する。

Slide 4

Slide 4 text

● 「統合基盤チームというプロダクト横断で利用される共通機能を開発するチーム」、どんなチームか想像できますか？ ○ インフラ？認証認可？DX系のなにか？どれも違います ● freeeにおけるソフトウェアアーキテクチャの概略、会社のビジョンの進化からでてくる課題に触れながら、どういう目的のためにうまれたチームなのか、どういうことをやっているのかの一例を紹介します。本日の概要

Slide 5

Slide 5 text

● freeeのビジョン ● アーキテクチャのこれまでと現状 ● “業務の分断” を起こさない為のドメイン境界の設定 ● 業務ドリブンなドメイン境界がもたらす分断 ● 分断を解消するための“繋げる”技術 agenda

Slide 6

Slide 6 text

Slide 7

Slide 7 text

　 7 だれもが⾃由に経営できる統合型経営プラットフォーム。だれもが⾃由に⾃然体で経営できる環境をつくるために、「統合型経営プラットフォーム」を開発‧提供します。バックオフィス業務を統合することで、⾃動化と業務全体の効率化。さらに経営全体を可視化することで、これまでにないスマートかつ最適なアクションまで実⾏できるプラットフォームへと進化させていきます。また外部サービスとも連携したオープンプラットフォームとして、多様なビジネスニーズに対応。ユーザーネットワークの中における相互取引の活性化も強化していきます。プラットフォームの提供のみならず、スモールビジネスに携わる⼈の環境そのものをより良くしていく取り組みを⾏うことで、世の中の変化を促します。 Vision

Slide 8

Slide 8 text

● freeeは、一つのプロダクトで他社と比較して広い範囲の業務をカバーし、統合体験を提供 ● 加えて、会計、人事労務以外の領域にもプロダクトを展開し、領域を横断した統合体験を実現 (cf. 2023年6月期第4四半期決算説明資料より) 幅広い業務・領域において統合体験を提供

Slide 9

Slide 9 text

経営を阻む3つの「分断」 1  業務の分断  例 ● 給与の⽀払額を間違えた ● 請求額を間違えた例 ● 従業員が紙で提出してくれない限り、業務が進まない ● 紙のありかがわからない 2  1  3   

Slide 10

Slide 10 text

● 例えば勤怠管理の機能があったとき、勤怠の集計にまつわる課題は解決するかもしれないが、業務はそこで終わりではなく給与計算またその先には給与振込と業務は一連の流れとして進んでいく ● 単機能をサポートするシステムの利用、またあるいは単機能をサポートするシステムの複数併用では、この前後の業務の間に発生する転記などの手作業が発生し、そこのミスは解決できない ● →関わる一連の業務を一気通貫でサポートするための “統合型” 経営を阻む三つの分断：業務の分断

Slide 11

Slide 11 text

● 年末調整、またあるいは普段の経費精算などにおいても業務を進める本人の他に登場人物がいることも多々 ● 仮にシステムがその業務をちゃんとサポートしているものであっても、結局他の人に「このデータちょっと見て！」といった直接のコミュニケーションを取る必要が出てくるのならばシステム化の恩恵は最大化できない ● →システム上で自然とコミュニケーションも繋げるための “統合型” 経営を阻む三つの分断：コミュニケーションの分断

Slide 12

Slide 12 text

● 業務や機能ごとに異なるサービスを使っている場合、「普通に業務をする」だけであれば、運用でなんとかなるかもしれない ● 数字のミスの原因を探りたい、またあるいは経営の改善のために数字をドリルダウンしたい、となった場合システムが分断されているとその境界の間を跨ぐときにトラッキングが難しくなる ● →システム/サービスを跨いでも一貫性をもってデータを蓄積するための統合型経営を阻む三つの分断：データの分断

Slide 13

Slide 13 text

● ただのシステム導入では必ずしも「業務の分断」「コミュニケーションの分断」「データの分断」を解決できない ● それらをを解決するための “統合型” ● では、そのような “統合型” のアプリケーションを作る上で、どういったポイントを意識していけば良いのか ● まずはこれまでのアーキテクチャから振り返る why 統合: 経営を阻む3つの分断

Slide 14

Slide 14 text

Slide 15

Slide 15 text

● 2013年にfreee会計リリース後、2014年にはfreee人事労務(当時は給与計算のサービス)をリリース ● その過程で、プロダクト間で共有したい基盤系の機能のマイクロサービス化が進行 ○ 認証認可・課金等、プロダクトを跨いでも共通であって欲しい機能群 ● 一方、個々のサービスはモノリスとして発展 ○ サービス・組織の発展とともにいわゆるモノリスが故の難点も見えてくる複数プロダクトの展開と基盤系サービスの発展

Slide 16

Slide 16 text

● サービス・組織の発展とともに増大したモノリスの辛さに対処すべく、モジュラモノリスを選択するプロダクトが増加 ● 新規のプロダクトはもちろん、特に大規模な既存のプロダクトについてもゆるやかにモジュラモノリスへ移行していったモジュラモノリスの広まり

Slide 17

Slide 17 text

● 大雑把な現状のアーキテクチャ ○ 外向けの “プロダクト”の単位が一つごとにモジュラモノリスのサービス ○ 基盤系の機能群についてはマイクロサービスで提供 ● モジュラモノリスであることの強みとして、プロダクトの進化に合わせてドメイン理解とともにモジュールの分割粒度を徐々に変えていくことが可能なことがあげられる ● では、今のアーキテクチャで「3つの分断」は回避できるだろうか？現状のアーキテクチャまとめ

Slide 18

Slide 18 text

Slide 19

Slide 19 text

● マイクロサービスにせよモジュラモノリスにせよ重要になるのはドメイン境界の設定 ○ ドメイン境界≠ユーザーから見たサービス境界ではあるが、間違ったドメイン境界の設定は「業務の分断」に繋がる ● 特に物理的に分割された複数のサービス間で後から重要な結びつきが必要なことがわかると大変 ○ 物理的な構成を変えるのももちろん大変だし、物理的な構成を変えないままその重要な結びつきを表現するもの大変 ● では何をもってサービスの境界を設定するか？ソフトウェアアーキテクチャにまつわる悩み

Slide 20

Slide 20 text

● BtoBの領域は多くのSaaSが出現するより前からパッケージ製品はもちろん、各企業内製のシステムを作っていたり、広く認知されているわけではないが様々な知見が存在している ● その中の一部は書籍などで触れることができる BtoBのドメインは先駆者がいる領域梅田弘之氏著「グラス片手に~ 」シリーズ販売管理システム編では、そっくりそのまま使えるわけではないが、業務の説明に加え詳細なレベルでのテーブル設計の例が紹介されている

Slide 21

Slide 21 text

● 実現したいユーザーストーリーの積み重ねで考えるのではなく、「こうなっていてほしい」データ構造から考える ○ 「こうなっていてほしい」に既知の知見が生きる ○ 先述したような共有知になっているようなものはもちろん、freeeのようにすでに成長しているプロダクトであれば、その中での運用の肌感も生かせる ● ここは絶対にjoinするであるとか、このデータとこのデータのトランザクションは絶対に必要、というようなところからドメイン分割のラインを見極める ● なぜデータから考えると良いのか？データモデリングから考える

Slide 22

Slide 22 text

● 高度に組織化された会社活動では、データを作るために人間が “業務” を行う ○ 極論どんぶり勘定で良いのならば財布のお金の増減だけ見れば十分で、管理する必要のある “業務” は存在しない ● そのため、どのようなデータを管理したいのかが業務の流れを理解するのには非常に重要 ● ドメインの境界をどこに設定するかについては、大雑把にいえば会計処理にまつわるところは経理部が勤怠や給与は労務部が、といったように実際の組織を想像した時に違う部署になるような業務領域は、物理的な結合が必要なほど強い結びつきにはならないことの方が多いデータこそが業務の核

Slide 23

Slide 23 text

● それゆえ、現状の「提供プロダクトごとの(モジュラ)モノリス」という姿が実運用上もそれなりに理にかなっている ● データ・業務を重視することで「業務の分断」が起きにくいドメイン境界の設定はできそう。では他の2つの分断はどうだろう？業務システムにおけるドメイン境界

Slide 24

Slide 24 text

Slide 25

Slide 25 text

● そもそも統合ERPであるfreeeを使うメリットは何か ● 日々の記帳をし、決算書を作るだけであれば仕訳が打てるシステムがあれば十分 ● 統合ERPではその先を提供したい。例えば... ○ 決算がよくなかった→何が原因かを理解し、対策を打ちたい ○ 営業利益が赤字になったとして、具体的にどの案件での赤字なのか？どんな経過だったか？そもそもの見積もりは？課題の一例: データの一貫性、トレーサビリティ

Slide 26

Slide 26 text

● つまり、統合ERPの強みはドメインを跨いでもデータが “繋がっている” ことが重要 ● 個別のプロダクトでただただ記録をつけているだけでは、プロダクトを跨いだ時にデータの間の関係性が記録できない（意識してそういう運用を敷く必要がある） ● → “データの分断” の一例課題の一例: データの一貫性、トレーサビリティ

Slide 27

Slide 27 text

● ワークフローにおいては「申請者」と「承認者」の二つの視点がある ● 申請者の視点 ○ 「経費精算申請」をする時は、どういう目的で何にどれだけの金額を使ったかが重要 ■ 承認された結果、自動的に経費精算の振り込みのデータも作って欲しい ○ 「有休申請」をする時は、いつ取るかや何日残ってるかなどが重要 ■ 承認されたら、勝手に勤怠の登録もして欲しい ● 申請者からの視点では、どのドメインの申請であるかは重要 ○ 申請の画面がその申請が属するドメインのサービスにあるのは自然課題の一例: ユーザーによる視点の差

Slide 28

Slide 28 text

課題の一例: ユーザーによる視点の差有休とるから申請するぞ出張したから精算するぞプロダクトの壁あちこちにあって大変だ...

Slide 29

Slide 29 text

● 承認者の視点では、それがどのドメインの申請かは重要ではない ● 承認しなければいけないものが数十も溜まっているのに、それが複数のプロダクトに分散しているとなかなか大変 ● 承認者の視点では、「全部の承認がまとめてみたい」 ● 業務ドリブンで設定した境界が、またある人にとっては “分断” に感じられる例 ● → “コミュニケーションの分断” の一例課題の一例: ユーザーによる視点の差

Slide 30

Slide 30 text

● 素朴にドメインを分割して、そのそれぞれでプロダクトを発展させていくだけでは解決できない “分断” を解決するために様々なことに取り組んでいるのが “統合基盤” チーム ● 先ほどのような課題に、具体的にどのような開発を行っているかをご紹介こうした問題を解消するための基盤が “統合基盤”

Slide 31

Slide 31 text

● freeeのビジョン ● アーキテクチャのこれまでと現状 ● “業務の分断” を起こさない為のドメイン境界の設定 ● 業務ドリブンなドメイン境界がもたらす分断 ● 分断を解消するための“繋げる”技術 ○ と、解決できていない課題も少しご紹介 agenda

Slide 32

Slide 32 text

● freee販売やfreee請求書では、もともとfreee会計で利用されている取引先マスタや、各種分析用のタグを利用するようになっている ● こうしたプロダクト外にあるマスタを利用するためのクライアントライブラリや画面で利用する際の専用コンポーネントなどが用意されている ● 単にデータの共有を各チームに任せるのではなくセントラルに面倒を見ることで「共有データの使い方」にもある程度統制を効かせ、どのプロダクトから使っていても違和感のないユーザー体験を実現トレーサビリティのための “繋げる” 技術

Slide 33

Slide 33 text

● 一方で、マスタを外部にもつとjoinができなかったり、単なる参照のために API経由でのアクセスが必要だったりと何かにつけて不便 ● たまに不便、くらいならまだよいが分析のためのタグ等はかなり使用頻度も高くこの不便さが際立って課題となる ● マスタの中央管理と、各プロダクトでの利便性向上のためにどうすればよいかはまだまだ掘り下げる必要アリトレーサビリティのための “繋げる” 技術...での課題

Slide 34

Slide 34 text

申請承認領域における “繋げる” 技術

Slide 35

Slide 35 text

● 承認者の視点ではプロダクトの境界を意識したくない ● そのために「すべての承認すべき申請」を集約し、一覧できる機能を提供 ● 幾つのプロダクトにまたがって存在する申請を束ねて一覧するために Elasticsearchを利用 ● 一覧の必要はあるが、例えばそれらの申請を束ねて承認したい、といったことはないので、結果整合でElasticsearch等の参照のためのDBに入っていれば十分 ○ 厳密にはあるかもしれないが、申請を跨いだトランザクションは不要と言えるだろう申請承認領域における “繋げる” 技術

Slide 36

Slide 36 text

まとめ

Slide 37

Slide 37 text

● これまで様々な経緯を経てたどり着いた現在のプロダクトやドメインの境界は、 “業務の分断” を起こさないための一定の妥当性があった ● これで全ての問題が解決されるわけではなく、プロダクト・ドメインの境界を跨いで解決しなければいけない課題もあり、そうした課題にアプローチするのが統合基盤チーム ● 複数のプロダクト・マイクロサービス間を解決したい課題の特性に合わせて上手く “繋ぐ” 技術が今後のfreeeでは重要になっていくまとめ

Slide 38

Slide 38 text

No content