Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
オンプレからクラウドへ。大規模なAWS移行を支えたリアーキテクチャプロジェクト達
Search
4geru
May 23, 2025
0
160
オンプレからクラウドへ。大規模なAWS移行を支えたリアーキテクチャプロジェクト達
CloudNative Days Summer 2025 で登壇した内容です
https://event.cloudnativedays.jp/cnds2025/talks/2590
4geru
May 23, 2025
Tweet
Share
More Decks by 4geru
See All by 4geru
ツンデレさんと考える LINE bot MCP の使い方
4geru
0
100
アマゾンの最強の働き方 読書シェア会
4geru
1
46
LINE, Supabase MCP でバイブスを上げる
4geru
0
89
クラウドネイティブで実現する、共通DBの課題解決 ~桃園の誓いアーキテクチャ~
4geru
0
20
LINE Bot MCP の可能性
4geru
0
82
Supabase超入門: 基本から応用まで
4geru
0
14
「成果を生み出すためのSalesforce運用ガイド」 ~ 第4章 Salesforceの標準的なモデルをおさえる ~
4geru
1
160
Ruby エンジニアが Salesforce 業界に 異動して感じたこと
4geru
1
170
【2024 アドカレ振り返り】最新トレンド解説 by LINE API Expert【生成AI/Cloudflare/GAS etc】
4geru
0
23
Featured
See All Featured
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
680
Scaling GitHub
holman
459
140k
Automating Front-end Workflow
addyosmani
1370
200k
Site-Speed That Sticks
csswizardry
10
690
It's Worth the Effort
3n
185
28k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
How STYLIGHT went responsive
nonsquared
100
5.6k
Music & Morning Musume
bryan
46
6.6k
The Power of CSS Pseudo Elements
geoffreycrofte
77
5.9k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
34
3.1k
The Cult of Friendly URLs
andyhume
79
6.5k
Transcript
株式会社マネーフォワード ビジネスカンパニー 内⻄ 功⼀ オンプレからクラウドへ。 ⼤規模なAWS移⾏を⽀えた リアーキテクチャプロジェクト達
⾃⼰紹介 2 株式会社マネーフォワード ビジネスカンパニー 横断BizOps本部 BizOps部 Adminグループ 2018- HRS本部 2021-
横断本部 2024- 横断BizOps本部 内⻄ 功⼀ 2018年にマネーフォワードに新卒⼊社。 「マネーフォワード クラウド勤怠」の⽴ち上げに携わり、その後 「マネーフォワード クラウドパートナー」のリニューアルを担当。 「桃園脱却プロジェクト」にてビジネスカンパニーのリード担当。
3
4 会社組織体制 5つのビジネスドメインで構成。法⼈向けには主にバックオフィスSaaSサービスを展開。
None
6
7 個⼈事業主 中⼩企業 中堅企業‧IPO準備企業 上場企業 個⼈事業主向け 中⼩企業向け 中堅企業‧IPO準備企業∕上場企業向け あらゆる企業規模に対応 主に⼠業事務所向け
主に中堅企業向け 個⼈から中⼩企業、エンタープライズ企業まで、様々な企業に対応可能なバックオフィスSaaSを展開 事業内容
8 オンプレの共有DBの当時の課題
9 マネーフォワードのサービスの拡⼤ 2020年から2021年にかけてサービスリリースが増加 toC toB向けで 共有データを利⽤ and more.. 推進チーム発⾜ 基盤サービス
完了 問題の顕在化 チームJOIN
10 オンプレの共有DBの当時のアーキテクチャ 共有DBサーバーを複数サービスが利⽤
共有DBサーバーの課題 DB変更は、複数サービスで同時にリリース 1サービスがメンテナンスする範囲が分かりづらい 固有サービスのデータが別サービスでも利用される 請求情報 / 勘定科目 / 従業員情報 など
全体障害の発生 11 開発スピードの鈍化 重いSQLの実行、ネットワーク機器の故障 ビジネスカンパニーの障害が別のカンパニーに影響してしまう 月に何度も障害が発生し、深夜にインフラが立ち会い オンプレの共有DBの当時の課題 1 2
12 オンプレの共有DBの当時のアーキテクチャ 共有データベースサーバーに⼤きく依存している状態
ビジネスカンパニーの共有DB分割後のアーキテクチャ 13 共有データベースサーバーの依存がなくなった状態
14 共有DBの依存分離プロジェクト と AWS移⾏プロジェクト
15 共有DBの依存分離プロジェクト と AWS移⾏プロジェクト 今回話すのは
16 新しく⽣まれたサービス と 役割を終えたサービス
17 新しく⽣まれたサービス プロジェクト 1.
18 マイクロサービスの特徴 - サービスによるコンポーネント化 ⼤きなモノリス 新サービス 機能 ⼤きなモノリス 機能 新しく⽣まれたサービス
19 サービス概要:マネーフォワード クラウドパートナー • 会計⼠、社労⼠、税理⼠向けサービス(顧問先管理) ◦ 会計、確定申告、給与計算 等の代⾏業務 新しく⽣まれたサービス
20 サービス概要:マネーフォワード クラウドパートナー 着⼿前 リニューアル後 新しく⽣まれたサービス
21 3度⽬の正直 ❌ 2回⽬ ⼤きな環境変化に対応しきれなかった ❌ 1回⽬ 期待を詰め込み過ぎた 3回⽬ 体制強化とスコープ最適化
22 3回⽬:成功 - 体制強化とスコープ最適化 ⽅針 : ✅ 最低限の機能に絞って、リリース優先 リーダー エンジニア
4名 ヘルプ 2名 企画 開発 PjM 元 CS 本部⻑ PdM 営業現場 部⻑
23 不確実性を減らす - 1. スコープを⾒直す - • 必要なサービスだけに絞り込み、不要な連携を削減 ◦ 会計⼠、社労⼠、税理⼠は「経費」は利⽤しない
• 新たなニーズに応じて追加 要件はなるべく⼩さく! ユーザーの本当のニーズに応えるために、 やるべきことを明確に 会計⼠ → 会計 税理⼠ → 確定申告、new 年末調整 社労⼠ → new 社会保険
24 不確実性を減らす - 2. 認識合わせは早いうちに - たくさんのテストケース : 新プランと旧プランの混在∕閏年 TDD(テスト駆動開発)の認識合わせを先に!
なるべく細かな粒度で、早いタイミングで! テストケース テスト 実装 リリース ✅ 要件レビュー ✅ 実装レビュー
25 Q 「◦◦◦◦スキーマ駆動開発」 何が⼊ると思いますか?
26 A GraphQL スキーマ駆動開発 Open API スキーマ駆動開発
27 スキーマ駆動開発 共通のメリット お互いの責任を分解して最速で進める • 型があるので、お互いの認識ずれが少ない • 変更が発⽣した際も、お互いに型で相談できる ⾃分たちのタスクも楽になる! •
タスクが分解されることで、シンプルな実装を実現 • ⾃動⽣成機能の充実により、⼿間を削減 ◦ ドキュメント、コードの⾃動⽣成 スキーマ駆動開発
28 GraphQL スキーマ駆動開発のメリット • フロントエンドの複雑なページ ◦ e.g. サービスのトップ(顧問先⼀覧)、顧問先詳細 • フロントエンド
- バックエンドに分解できる ◦ 実装したい箇所に集中できる ◦ 得意領域で担当者を分けられる スキーマ駆動開発 ➕ ➕ 🟰
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 プロジェクト1: 新しく⽣まれたサービス のまとめ • 難易度が⾼いプロジェクトは不確実性を先に潰す 1. スコープの⾒直し 2. 認識合わせは早いうちに
• 開発を⽀えた 2 つのスキーマ駆動開発の使い⽅ ◦ GraphQL スキーマ / Open API スキーマ ◦ お互いの責任を分解して最速で進める ◦ ⾃分たちのタスクも楽になる! サービス名:マネーフォワード クラウドパートナー
31 役割を終えたサービス プロジェクト 2.
32 マイクロサービスの特徴 - 分散データ管理 サービスA 機能 社内向け 機能 サービスB 機能
サービスC 機能 サービスA 機能 サービスB 機能 サービスC 機能 役割を終えたサービス
同じデータベースを共有 → データが参照できる • 開発組織が⼩さい ◦ 管理画⾯のリソースを抑えたい • 共有DBへアクセス ◦
⼀箇所で参照できた • 1箇所で権限 ◦ データベース上で管理 各サービスのデータベース → データが参照できない • 開発組織が⼤きい ◦ 全体の合意が取りづらくなった • 各サービスに分散 ◦ サービス側で詳しい情報が確認可能 • 基盤、各サービスで権限管理が必要 ◦ Microsoft Entra ID を利⽤ 33 サービス概要:共通管理画⾯ 役割を終えたサービス 今 昔
34 共通管理画⾯が役⽬を終えるための流れ 役割を終えたサービス 共通管理画⾯の利⽤状況の確認 対応⽅針の決定 移⾏作業 各利⽤部⾨へ移⾏確認 TODOのドキュメント化 各部⾨の利⽤状況、ユースケースを確認 機能,
サービスの対応を個別に判断 機能の開発‧移⾏サポートなどを実⾏ 利⽤部⾨ごとに確認と受け⼊れを実施 現状の課題、したいことを伝えやすく
35 共通管理画⾯が役⽬を終えるため4つのコツ 1. 息の⻑いものは早く倒そう 2. 利⽤ユーザーは明確しよう 3. 協⼒したいと思わせよう 4. 上司を巻き込む!
役割を終えたサービス
36 Q 最後に残った機能はなんでしょうか?
37 A 商材系(プロダクトキー)が残った
思ってるより時間がかかる • 同様の機能を移⾏ • 運⽤変更まで待機 38 商材系の対応⽅針 • お客様への共有必須 •
期限が切れるまで廃⽌できない • 年単位での契約 共通管理画⾯が役⽬を終える4つのコツ / 1. 息の⻑いものは早く倒そう! • 問い合わせ⽤に情報を保持 • 機能のクローズ サービス側へ移⾏する場合 廃⽌する場合 どちらの場合も
39 共通管理画⾯が役⽬を終えるための4つのコツ 1. 息の⻑いものは早く倒そう 2. 利⽤ユーザーは明確しよう 3. 協⼒したいと思わせよう 4. 上司を巻き込む!
役割を終えたサービス
40 社内にはいろいろなユーザーがいる 共通管理画⾯が役⽬を終える4つのコツ / 2. 利⽤ユーザーは明確にしよう! Aさん カスタマーサポート メールを送りたい 何のためにだれがいつ使っているか
Cさん 営業 利⽤状況をみたい Bさん 営業事務 集計のために エクスポートしたい Dさん エンジニア テスト⽤に 課⾦状態にしたい
41 利⽤ユーザーに寄り添った解決策を提案 対応⽅針の決定、移⾏作業: • 利⽤ユーザーの業務フローを考慮して検討 各本部へ移⾏確認: • Slackやヒアリングで利⽤状況を確認 ◦ 定期的に利⽤,
移⾏状況をリマインド ◦ コミュニケーションの証跡を残す 共通管理画⾯が役⽬を終える4つのコツ / 2. 利⽤ユーザーは明確にしよう!
42 共通管理画⾯が役⽬を終えるための4つのコツ 1. 息の⻑いものは早く倒そう 2. 利⽤ユーザーは明確しよう 3. 協⼒したいと思わせよう 4. 上司を巻き込む!
役割を終えたサービス
43 利⽤ユーザーのモチベーション 共通管理画⾯が役⽬を終える4つのコツ / 3. 協⼒したいと思わせよう 同じ機能が劣化していたら どうしよう 今までなかった 欲しい機能があるな
44 前向きに協⼒してもらうために、信頼貯⾦を上げる 今までと変わらない操作性: • 似ている UI で移⾏ • 1ページから全サービスの管理画⾯に遷移 細かな要望も対応をする:
• 簡単にコピーできる(事業者ID, メールアドレス等) • 共通の⽤語を併記(ユーザーID, 顧客識別⼦) 共通管理画⾯が役⽬を終える4つのコツ / 3. 協⼒したいと思わせよう 移⾏モチベーションを上げる!
45 共通管理画⾯が役⽬を終えるための4つのコツ 1. 息の⻑いものは早く倒そう 2. 利⽤ユーザーは明確しよう 3. 協⼒したいと思わせよう 4. 上司を巻き込む!
役割を終えたサービス
46 Q 機能の移⾏先はスムーズに決まったの?
47 A No. とても難航した
48 機能の移⾏先の決定 → 上司と機能移⾏先のチームに相談 [上司/上司の上司] の⽬標に プロジェクトの達成 が含まれる • 評価のために、⽬標を達成することが⼤切
• ⾃分が達成すると上司の評価にもつながる 共通管理画⾯が役⽬を終える4つのコツ / 4. 上司を巻き込む! 責任外の受け⼊れは積極的になれない 受け⼊れ先のチーム
49 まとめ:プロジェクト2. 役割を終えたサービス 4つのコツ 1. 息の⻑いものは早く倒そう 2. 利⽤ユーザーは明確しよう 3. 協⼒したいと思わせよう
4. 上司を巻き込もう! サービス名:共通管理画⾯
50 共有DBの依存分離プロジェクト と AWS移⾏プロジェクト 今回話したのは
51 全体のまとめ 新しく⽣まれたサービス と 役割を終えたサービス 1 ⼤規模な移⾏には、間接的なプロジェクトもある ‧クラウドに移⾏だけじゃない ‧組織論も必要(推進、新サービス) 2
円滑にすすめるためには推進チームが必要 ‧問題を先回りする ‧全体をリードする ‧落ちてるボールを拾う 3 クラウドネイティブへの道は泥臭い ‧実際に使っている⼈の声 ‧周りの⼈の協⼒
52 ご清聴ありがとうございました