オンプレからクラウドへ。大規模なAWS移行を支えたリアーキテクチャプロジェクト達

CloudNative Days Summer 2025 で登壇した内容です
https://event.cloudnativedays.jp/cnds2025/talks/2590

Transcript

1. 株式会社マネーフォワード ビジネスカンパニー 内⻄ 功⼀ オンプレからクラウドへ。 ⼤規模なAWS移⾏を⽀えた リアーキテクチャプロジェクト達
2. ⾃⼰紹介 2 株式会社マネーフォワード ビジネスカンパニー 横断BizOps本部 BizOps部 Adminグループ 2018- HRS本部 2021- 横断本部 2024- 横断BizOps本部 内⻄ 功⼀ 2018年にマネーフォワードに新卒⼊社。 「マネーフォワード クラウド勤怠」の⽴ち上げに携わり、その後 「マネーフォワード クラウドパートナー」のリニューアルを担当。 「桃園脱却プロジェクト」にてビジネスカンパニーのリード担当。
4. 4 会社組織体制 ５つのビジネスドメインで構成。法⼈向けには主にバックオフィスSaaSサービスを展開。
7. 7 個⼈事業主 中⼩企業 中堅企業‧IPO準備企業 上場企業 個⼈事業主向け 中⼩企業向け 中堅企業‧IPO準備企業∕上場企業向け あらゆる企業規模に対応 主に⼠業事務所向け 主に中堅企業向け 個⼈から中⼩企業、エンタープライズ企業まで、様々な企業に対応可能なバックオフィスSaaSを展開 事業内容
8. 8 オンプレの共有DBの当時の課題
9. 9 マネーフォワードのサービスの拡⼤ 2020年から2021年にかけてサービスリリースが増加 toC toB向けで 共有データを利⽤ and more.. 推進チーム発⾜ 基盤サービス 完了 問題の顕在化 チームJOIN
10. 10 オンプレの共有DBの当時のアーキテクチャ 共有DBサーバーを複数サービスが利⽤
11. 共有DBサーバーの課題 DB変更は、複数サービスで同時にリリース
 1サービスがメンテナンスする範囲が分かりづらい
 固有サービスのデータが別サービスでも利用される 請求情報 / 勘定科目 / 従業員情報 など 全体障害の発生 11 開発スピードの鈍化 重いSQLの実行、ネットワーク機器の故障
 ビジネスカンパニーの障害が別のカンパニーに影響してしまう
 月に何度も障害が発生し、深夜にインフラが立ち会い オンプレの共有DBの当時の課題 1 2
12. 12 オンプレの共有DBの当時のアーキテクチャ 共有データベースサーバーに⼤きく依存している状態
13. ビジネスカンパニーの共有DB分割後のアーキテクチャ 13 共有データベースサーバーの依存がなくなった状態
14. 14 共有DBの依存分離プロジェクト と AWS移⾏プロジェクト
15. 15 共有DBの依存分離プロジェクト と AWS移⾏プロジェクト 今回話すのは
16. 16 新しく⽣まれたサービス と 役割を終えたサービス
17. 17 新しく⽣まれたサービス プロジェクト 1.
18. 18 マイクロサービスの特徴 - サービスによるコンポーネント化 ⼤きなモノリス 新サービス 機能 ⼤きなモノリス 機能 新しく⽣まれたサービス
19. 19 サービス概要：マネーフォワード クラウドパートナー • 会計⼠、社労⼠、税理⼠向けサービス（顧問先管理） ◦ 会計、確定申告、給与計算 等の代⾏業務 新しく⽣まれたサービス
20. 20 サービス概要：マネーフォワード クラウドパートナー 着⼿前 リニューアル後 新しく⽣まれたサービス
21. 21 3度⽬の正直 ❌ 2回⽬ ⼤きな環境変化に対応しきれなかった ❌ 1回⽬ 期待を詰め込み過ぎた 3回⽬ 体制強化とスコープ最適化
22. 22 3回⽬：成功 - 体制強化とスコープ最適化 ⽅針 ： ✅ 最低限の機能に絞って、リリース優先 リーダー エンジニア 4名 ヘルプ 2名 企画 開発 PjM 元 CS 本部⻑ PdM 営業現場 部⻑
23. 23 不確実性を減らす - 1. スコープを⾒直す - • 必要なサービスだけに絞り込み、不要な連携を削減 ◦ 会計⼠、社労⼠、税理⼠は「経費」は利⽤しない • 新たなニーズに応じて追加 要件はなるべく⼩さく！ ユーザーの本当のニーズに応えるために、 やるべきことを明確に 会計⼠ → 会計 税理⼠ → 確定申告、new 年末調整 社労⼠ → new 社会保険
24. 24 不確実性を減らす - 2. 認識合わせは早いうちに - たくさんのテストケース ： 新プランと旧プランの混在∕閏年 TDD(テスト駆動開発)の認識合わせを先に！ なるべく細かな粒度で、早いタイミングで！ テストケース テスト 実装 リリース ✅ 要件レビュー ✅ 実装レビュー
25. 25 Q 「◦◦◦◦スキーマ駆動開発」 何が⼊ると思いますか？
26. 26 A GraphQL スキーマ駆動開発 Open API スキーマ駆動開発
27. 27 スキーマ駆動開発 共通のメリット お互いの責任を分解して最速で進める • 型があるので、お互いの認識ずれが少ない • 変更が発⽣した際も、お互いに型で相談できる ⾃分たちのタスクも楽になる！ • タスクが分解されることで、シンプルな実装を実現 • ⾃動⽣成機能の充実により、⼿間を削減 ◦ ドキュメント、コードの⾃動⽣成 スキーマ駆動開発
28. 28 GraphQL スキーマ駆動開発のメリット • フロントエンドの複雑なページ ◦ e.g. サービスのトップ（顧問先⼀覧）、顧問先詳細 • フロントエンド - バックエンドに分解できる ◦ 実装したい箇所に集中できる ◦ 得意領域で担当者を分けられる スキーマ駆動開発 ➕ ➕ 🟰
29. 29 Open API スキーマ駆動開発のメリット • 初期リリースだけで 4 サービスと連携（うち2サービスが英語チーム） ◦ サービス間の連携で Open API スキーマを利⽤ ◦ 設計、実装のコミュニケーションを最短に！ • openapi-generator を活⽤！ ◦ API Client の⾃動⽣成（Ruby, Node, Go, Python, etc... に対応） ◦ Docker だけで完結！ローカルのセットアップ不要！ ◦ なるべく標準のものを使うように！ スキーマ駆動開発 ServiceA ServiceB ServiceA API Client ServiceB API Client ServiceC
30. 30 プロジェクト1： 新しく⽣まれたサービス のまとめ • 難易度が⾼いプロジェクトは不確実性を先に潰す 1. スコープの⾒直し 2. 認識合わせは早いうちに • 開発を⽀えた 2 つのスキーマ駆動開発の使い⽅ ◦ GraphQL スキーマ / Open API スキーマ ◦ お互いの責任を分解して最速で進める ◦ ⾃分たちのタスクも楽になる！ サービス名：マネーフォワード クラウドパートナー
31. 31 役割を終えたサービス プロジェクト 2.
32. 32 マイクロサービスの特徴 - 分散データ管理 サービスA 機能 社内向け 機能 サービスB 機能 サービスC 機能 サービスA 機能 サービスB 機能 サービスC 機能 役割を終えたサービス
33.  同じデータベースを共有  → データが参照できる • 開発組織が⼩さい ◦ 管理画⾯のリソースを抑えたい • 共有DBへアクセス ◦ ⼀箇所で参照できた • 1箇所で権限 ◦ データベース上で管理  各サービスのデータベース  → データが参照できない • 開発組織が⼤きい ◦ 全体の合意が取りづらくなった • 各サービスに分散 ◦ サービス側で詳しい情報が確認可能 • 基盤、各サービスで権限管理が必要 ◦ Microsoft Entra ID を利⽤ 33 サービス概要：共通管理画⾯ 役割を終えたサービス 今 昔
34. 34 共通管理画⾯が役⽬を終えるための流れ 役割を終えたサービス 共通管理画⾯の利⽤状況の確認 対応⽅針の決定 移⾏作業 各利⽤部⾨へ移⾏確認 TODOのドキュメント化 各部⾨の利⽤状況、ユースケースを確認 機能, サービスの対応を個別に判断 機能の開発‧移⾏サポートなどを実⾏ 利⽤部⾨ごとに確認と受け⼊れを実施 現状の課題、したいことを伝えやすく
35. 35 共通管理画⾯が役⽬を終えるため4つのコツ 1. 息の⻑いものは早く倒そう 2. 利⽤ユーザーは明確しよう 3. 協⼒したいと思わせよう 4. 上司を巻き込む！ 役割を終えたサービス
36. 36 Q 最後に残った機能はなんでしょうか？
37. 37 A 商材系（プロダクトキー）が残った
38. 思ってるより時間がかかる • 同様の機能を移⾏ • 運⽤変更まで待機 38 商材系の対応⽅針 • お客様への共有必須 • 期限が切れるまで廃⽌できない • 年単位での契約 共通管理画⾯が役⽬を終える4つのコツ / 1. 息の⻑いものは早く倒そう！ • 問い合わせ⽤に情報を保持 • 機能のクローズ サービス側へ移⾏する場合 廃⽌する場合 どちらの場合も
39. 39 共通管理画⾯が役⽬を終えるための4つのコツ 1. 息の⻑いものは早く倒そう 2. 利⽤ユーザーは明確しよう 3. 協⼒したいと思わせよう 4. 上司を巻き込む！ 役割を終えたサービス
40. 40 社内にはいろいろなユーザーがいる 共通管理画⾯が役⽬を終える4つのコツ / 2. 利⽤ユーザーは明確にしよう！ Aさん カスタマーサポート メールを送りたい 何のためにだれがいつ使っているか Cさん 営業 利⽤状況をみたい Bさん 営業事務 集計のために エクスポートしたい Dさん エンジニア テスト⽤に 課⾦状態にしたい
41. 41 利⽤ユーザーに寄り添った解決策を提案 対応⽅針の決定、移⾏作業： • 利⽤ユーザーの業務フローを考慮して検討 各本部へ移⾏確認： • Slackやヒアリングで利⽤状況を確認 ◦ 定期的に利⽤, 移⾏状況をリマインド ◦ コミュニケーションの証跡を残す 共通管理画⾯が役⽬を終える4つのコツ / 2. 利⽤ユーザーは明確にしよう！
42. 42 共通管理画⾯が役⽬を終えるための4つのコツ 1. 息の⻑いものは早く倒そう 2. 利⽤ユーザーは明確しよう 3. 協⼒したいと思わせよう 4. 上司を巻き込む！ 役割を終えたサービス
43. 43 利⽤ユーザーのモチベーション 共通管理画⾯が役⽬を終える4つのコツ / 3. 協⼒したいと思わせよう 同じ機能が劣化していたら どうしよう 今までなかった 欲しい機能があるな
44. 44 前向きに協⼒してもらうために、信頼貯⾦を上げる 今までと変わらない操作性： • 似ている UI で移⾏ • 1ページから全サービスの管理画⾯に遷移 細かな要望も対応をする： • 簡単にコピーできる（事業者ID, メールアドレス等） • 共通の⽤語を併記（ユーザーID, 顧客識別⼦） 共通管理画⾯が役⽬を終える4つのコツ / 3. 協⼒したいと思わせよう 移⾏モチベーションを上げる！
45. 45 共通管理画⾯が役⽬を終えるための4つのコツ 1. 息の⻑いものは早く倒そう 2. 利⽤ユーザーは明確しよう 3. 協⼒したいと思わせよう 4. 上司を巻き込む！ 役割を終えたサービス
46. 46 Q 機能の移⾏先はスムーズに決まったの？
47. 47 A No. とても難航した
48. 48 機能の移⾏先の決定 → 上司と機能移⾏先のチームに相談 [上司/上司の上司] の⽬標に プロジェクトの達成 が含まれる • 評価のために、⽬標を達成することが⼤切 • ⾃分が達成すると上司の評価にもつながる 共通管理画⾯が役⽬を終える4つのコツ / 4. 上司を巻き込む！ 責任外の受け⼊れは積極的になれない 受け⼊れ先のチーム
49. 49 まとめ：プロジェクト2. 役割を終えたサービス 4つのコツ 1. 息の⻑いものは早く倒そう 2. 利⽤ユーザーは明確しよう 3. 協⼒したいと思わせよう 4. 上司を巻き込もう！ サービス名：共通管理画⾯
50. 50 共有DBの依存分離プロジェクト と AWS移⾏プロジェクト 今回話したのは
51. 51 全体のまとめ 新しく⽣まれたサービス と 役割を終えたサービス １ ⼤規模な移⾏には、間接的なプロジェクトもある  ‧クラウドに移⾏だけじゃない  ‧組織論も必要(推進、新サービス) ２ 円滑にすすめるためには推進チームが必要  ‧問題を先回りする  ‧全体をリードする  ‧落ちてるボールを拾う ３ クラウドネイティブへの道は泥臭い  ‧実際に使っている⼈の声  ‧周りの⼈の協⼒
52. 52 ご清聴ありがとうございました