マスタデータ問題、マイクロサービスでどう解くか

2025-11-30 freee技術の日2025
https://freee-tech-day.freee.co.jp/2025/

Transcript

2. マスタデータ問題 マイクロサービスでどう解くか 加藤啓輔 2025年11⽉30⽇
3. 「freee会計」という巨⼤なモノリスから、取 引先マスタをいかにして切り出したか。 モジュラモノリスを経た段階的な分離戦略、 Write機能のみを先⾏して切り出すCQRSの採 ⽤、そして複雑な分散トランザクションを回避 しつつ、データ整合性を担保するための削除の 作法まで。技術的な難所と、共通化に伴う組織 的な「合意形成の壁」をどう乗り越えてきた か。数々の困難な意思決定の中で得られた、ビ ジネスを⽌めないための「泥臭い」実践知を凝 縮してお届けします。 マスタデータ問題 マイクロサービスで どう解くか
4. 加藤啓輔 freee⼈事労務の開発の4年を経 て、現在ではマスタデータ基盤を 4年開発。プロダクトリードエン ジニアとマネージャーを務めてい ます。 統合モジュール開発部 共通マスタチーム マネージャー
5. ツリー構造や 履歴管理 企業や⽀店、部署、 ⼈など登録される 単位が様々 細かい履歴管理 SKUでの管理 私たちのチームが扱ってきた「マスタデータ」 性質の異なる多種多様なマスタが存在 商品マスタ 従業員マスタ 取引先マスタ 組織図マスタ
6. ツリー構造や 履歴管理 企業や⽀店、部署、 ⼈など登録される 単位が様々 細かい履歴管理 SKUでの管理 今回は「取引先マスタ」について話します 商品マスタ 従業員マスタ 取引先マスタ 組織図マスタ 取引先マスタがマイクロサービスに⾄るまでのトレードオフ
7. 　 01 どんなマスタを作るべきか 02 モノリスからの分離戦略 03 CQRSの実践 04 マイクロサービスにおける『削除』の作法 05 ガバナンスの壁と調整コスト 06 意思決定の学び ⽬次
8. 汎化 VS 特化 • 汎化： 「あらゆるマスタを扱えるデータベース」を⽬指す。⾃由度が⾼く、 様々なパターンに適応可能。 • 特化： freeeプロダクトのユースケースに最適化。疎結合に保ち、仕様変更の 影響を局所化する。
9. 汎化 VS 特化 • 現実には各マスタやマスタが持つ項⽬の性質が⼤きく異なるという課題に直⾯ • 汎化させることで既存のデータや仕組みの後⽅互換性へのコストの増⼤
10. 汎化 VS 特化 • 現実には各マスタやマスタが持つ項⽬の性質が⼤きく異なるという課題に直⾯ • 汎化させることで既存のデータや仕組みの後⽅互換性へのコストの増⼤ プロダクトの進化を加速させるため 特化させるアプローチを選択
11. 　 01 どんなマスタを作るべきか 02 モノリスからの分離戦略 03 CQRSの実践 04 マイクロサービスにおける『削除』の作法 05 ガバナンスの壁と調整コスト 06 意思決定の学び ⽬次
12. 取引先マスタはfreee会計という巨⼤モノリスの⼀部だった • freee会計以外の利⽤でもfreee会計のサインアップが必要 • freee会計の初期データ作成が必須となる • マスタ編集時は、freee会計画⾯への遷移が強制される • 他のプロダクトからのマスタ参照が技術的に困難 モノリスが抱える課題
13. モノリスからモジュラモノリスへ
14. モノリスからモジュラモノリスへ
15. モノリスからモジュラモノリスへ • 巨⼤なモノリスから⼀気にサービスを切り出すのはリスクが⾼い • 取引先マスタ関連のロジックを1つのモジュールに集約し、境界を明確化
16. モジュラモノリスからマイクロサービスへ
17. モジュラモノリスからマイクロサービスへ
18. モジュラモノリスからマイクロサービスへ • 開発速度の向上 デプロイタイミング、コンフリクト、コードの複雑さ、... • 責務の明確化 • 巨⼤なモノリスへの依存脱却
19. 　 01 どんなマスタを作るべきか 02 モノリスからの分離戦略 03 CQRSの実践 04 マイクロサービスにおける『削除』の作法 05 ガバナンスの壁と調整コスト 06 意思決定の学び ⽬次
20. freee会計からの取引先データアクセス CQRSの採⽤
21. freee会計からの取引先データアクセス CQRSの採⽤ DB分離コスト 700箇所の 参照置き換えコスト
22. • プロダクトデータとの結合（Join）や並び替え（Sort）が必要な要件 マイクロサービス間のJoinやSort
23. • プロダクトデータとの結合（Join）や並び替え（Sort）が必要な要件 参照⽤のレプリケーションテーブルを Read Modelとして配布 マイクロサービス間のJoinやSort
24. • 書き込み処理は厳密に制御された単⽅向フローを確⽴ • freee会計から物理的にも切り離し、共通基盤としての地位を確⽴ • 既存の700箇所の参照はあえて残し、書き込みの健全化を最優先する Writeの物理分離と、Readの戦略的先送り
25. 　 01 どんなマスタを作るべきか 02 モノリスからの分離戦略 03 CQRSの実践 04 マイクロサービスにおける『削除』の作法 05 ガバナンスの壁と調整コスト 06 意思決定の学び ⽬次
26. 物理削除のジレンマと「アーカイブ」という解 • 取引先データは電⼦帳簿保存法もあり厳格な整合性を求められる • 物理削除はトランザクション制御が難しく、データ不整合の原因となる • ⼀⽅で分散トランザクションは複雑かつ障害の要因になり得る
27. 物理削除のジレンマと「アーカイブ」という解 • 取引先データは電⼦帳簿保存法もあり厳格な整合性を求められる • 物理削除はトランザクション制御が難しく、データ不整合の原因となる • ⼀⽅で分散トランザクションは複雑かつ障害の要因になり得る 「アーカイブ」というステータスを設けて、 ユーザー⾃⾝がデータを復活できる体験を選択
28. 物理削除のジレンマと「アーカイブ」という解 • 取引先データは電⼦帳簿保存法もあり厳格な整合性を求められる • 物理削除はトランザクション制御が難しく、データ不整合の原因となる • ⼀⽅で分散トランザクションは複雑かつ障害の要因になり得る 「アーカイブ」というステータスを設けて、 ユーザー⾃⾝がデータを復活できる体験を選択 分散システムの整合性を守り、ユーザーの安⼼も守る
29. 　 01 どんなマスタを作るべきか 02 モノリスからの分離戦略 03 CQRSの実践 04 マイクロサービスにおける『削除』の作法 05 ガバナンスの壁と調整コスト 06 意思決定の学び ⽬次
30. 基盤チームとプロダクトチームのコミュニケーション 例: これまでのマスタへの項⽬追加基準 • 将来の共通利⽤の予測: 他プロダクトで共通利⽤されるか？ • ⼊⼒画⾯の選定: マスタ側/プロダクト側、どちらで⼊⼒すべきか？ • データの更新頻度: 更新頻度は⾼いか、低いか？ • 共通機能への許容度: インポートやワークフローなど共通機能を利⽤するか？
31. 基盤チームとプロダクトチームのコミュニケーション 例: これまでのマスタへの項⽬追加基準 • 将来の共通利⽤の予測: 他プロダクトで共通利⽤されるか？ 項⽬の将来的な共通利⽤の有無は、現時点では予測困難 • ⼊⼒画⾯の選定: マスタ側/プロダクト側、どちらで⼊⼒すべきか？ UIや共通化要否は、ユースケース確⽴まで判断困難 • データの更新頻度: 更新頻度は⾼いか、低いか？ 「更新頻度はどうなるか？」は初期段階ではイメージがつかず、保守的な判断になりがち • 共通機能への許容度: インポートやワークフローなど共通機能を利⽤するか？ エッジケースなどへの対応がしづらい
32. 基盤チームとプロダクトチームのコミュニケーション 例: これまでのマスタへの項⽬追加基準 • 将来の共通利⽤の予測: 他プロダクトで共通利⽤されるか？ 項⽬の将来的な共通利⽤の有無は、現時点では予測困難 • ⼊⼒画⾯の選定: マスタ側/プロダクト側、どちらで⼊⼒すべきか？ UIや共通化要否は、ユースケース確⽴まで判断困難 • データの更新頻度: 更新頻度は⾼いか、低いか？ 「更新頻度はどうなるか？」は初期段階ではイメージがつかず、保守的な判断になりがち • 共通機能への許容度: インポートやワークフローなど共通機能を利⽤するか？ エッジケースなどへの対応がしづらい 予測困難性や選択の複雑性を 内包していた
33. 意思決定の壁: コミュニケーションコストと硬直化 • ⾼頻度なコミュニケーション負荷 • 膨⼤な調整コスト • 仕様の硬直化 • 保守的な判断の連鎖
34. 新しい項⽬追加基準 • 項⽬の共通利⽤有無を問わない • 項⽬ごとにメンテナンスのオーナーシップを明確化する • 既存項⽬利⽤の簡易化 • 共通基盤の積極的な利⽤ 将来予測や事前合意の負荷を削減し、迅速な意思決定を⽬指す
35. 「⾨番」ではなく、安全な器（うつわ）の「設計者」へ • 定義する: プロセスとルールを整備する • 任せる: ユースケースは各チームに委譲する • ⽀える: 利⽤しやすい共通機能を⽤意する • 予測する: 不確実な未来の利⽤シーンを問う • ⽌める: 合意が取れるまで開発をブロックする • 守る: マスタの純度を守るために制限する
36. 　 01 どんなマスタを作るべきか 02 モノリスからの分離戦略 03 CQRSの実践 04 マイクロサービスにおける『削除』の作法 05 ガバナンスの壁と調整コスト 06 意思決定の学び ⽬次
37. 迷いを減らし、顧客への価値提供に集中するために • 汎化しすぎない： 特化の選択で、エッジケースへの対応⼒を残す • 理想を⽬指しすぎない： 戦略的な先送りで遅延リスクを抑え、着実に提供する • 制限しすぎない： 権限の委譲で、意思決定スピードを上げる プロダクトの進化を⽌めないための余白調整