Full-Stack TSでのマルチプロダクト基盤開発 / TSKaigi Hokuriku 2025

2025-11-23 「TSKaigi Hokuriku 2025」の登壇資料です。

Transcript

1. Full-Stack TS での マルチプロダクト基盤開発 Shodai Suzuki @SoartecL TSKaigi Hokuriku 2025 2025.11.23 © MOSH Inc.
2. 鈴木翔大 X @SoartecL VP of Technology Productivity チーム( 技 術基盤チーム) 趣味 OSS Orval メンテナ ダイビング
3. アジェンダ 主題の背景となるプロダクト とビジネスの説明と発生する 技術課題 ビジネスとプロダクト プロダクト開発の課題に技術 基盤としての対応 ソリューション 今後の課題例について 今後の課題例 1 2 3
4. MOSH のビジネス
5. クリエイター ヨガ・フィットネス ヘルス・ウェルネス 育児・子育て 養成講座・スクール オンラインサロン・ コミュニティ メイク・ ビューティー
6. マルチプロダクト
7. マルチプロダクト開発を実現する Full-Stack TS とフルサイクル開発 を行なっています
8. フルサイクル開発 プロダクト仕様から開発、運用、サ ポートまでのライフサイクル全体を 一貫して担う ドメイン理解を深めて最適なソリュ ーションを採用する チームの自律性を高めてスループッ トを上げる チーム外とのコミュニケーション 組織全体の知見を活用する 引用: 「Full Cycle Developers at Netflix — Operate What You Build 」 https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249
9. ドメイン理解 “ チーム全員が顧客とかかわりを持た なければならない。これこそ、チー ムが顧客の気持ちを理解する唯一の 方法だ。“ “ 客の意見を聞くのは、商品の強みと 弱みを知る一番の方法だ。顧客と作 り手の間に人が多いほど、顧客の声 は歪んだり失われたりしていく。“ 引用: 「小さなチーム、大きな仕事」 P.230
10. フルサイクルなプロダクト開発を進 める中で発生する課題
11. 課題① ドメイン理解への集中と同時に 開発と比例する運用コスト増加によ るスピード低下が フルサイクル開発のリアル
12. 生涯コスト “ ソフトウェアの生涯コストの内、少 なくとも60 ～75% は初期開発後に発 生し、その約4 分の1 は、移行やその 他の適応メンテナンスにのみ費やさ れてる“ 引用: 「PlatformEngineering -Chapter 1. Why Platform Engineering Is Becoming Essential- 」
13. 同時開発
14. 課題② 複数チームで統一したい振る舞いや 機能の重複・繰り返し
15. これらの課題に向かうためアプリケ ーションの機能と共通基盤を Full-stack TS で同時開発
16. アジェンダ 主題の背景となるプロダクト とビジネスの説明と発生する 技術課題 ビジネスとプロダクト プロダクト開発の課題に技術 基盤としての対応 ソリューション 今後の課題例について 今後の課題例 1 2 3
17. 今日の主題 なぜ基盤開発にTS を採用したいのか Full-stack TS での基盤開発 少人数で複数の基盤を開発・運用する技術選定の背景 Full-stack TS の生産性に寄与している事例
18. なぜ基盤開発にTS を 採用したいのか？
19. バックエンド 共通基盤を含めたFull-stack TS フロントエンド 共通基盤 共通基盤 機能
20. 期待と懸念 期待 FE/BE 開発で得たFull-Stack TS の 生産性を再現したい AI との親和性 静的型付け 連携システム間の型定義共有 同じ言語なのでコンテキスト が分断されず目的単位で開発 可能 懸念 共通基盤としての要求に応えられ るか 事例が少ない中でトラブルシュー ティング可能か
21. Full-Stack TS の生産性とエコスシ ステムで共通基盤の構築に挑戦
22. 共通基盤とは？ ①共通サービスプラットフォーム “Integration/Shared Services Platforms” アプリケーションの共通基盤 ②コアプラットフォーム “core/infrastructure platform” 引用: 「PlatformEngineering -Chapter 3. How and When to Get Started- 」
23. ①共通サービスプラットフォーム
24. 共通サービスプラットフォームの例 決済 通知 メッセージ配信 クリエイタープラン管理 権限 アカウント管理
25. 共通サービスプラットフォームの価値 横断するドメイン知識の深化 一貫したユーザー体験 基盤同士のデータ連携による価値作り 各プロダクト間の共通処理を集約 技術的複雑性のカプセル化
26. メッセージ 配信基盤 顧客管理機能 機能と基盤の組み合わせ 契約プラン 管理基盤 決済基盤 通知基盤 共通サービスプラットフォーム 機能 売上管理機能
27. 継続的インテグレーシ ョン “ アプリケーションを破綻させるコード変 更は、そのアプリケーションのプロジェ クトがある直接のコードベース内に存在 している見込みは低く、ネットワーク経 由の呼び出しの反対側にある疎結合した マイクロサービス内にある見込みの方が 高い。“ 引用: 「Google のソフトウェアエンジニアリング」 P.555
28. OpenAPI でのスキーマ駆動開発 各基盤のIF をOpenAPI で定義 client/server ソースコードを自動生成 基盤同士のclient/server 間の不整合を解消 使用するpackage にclient を出力し依存先を明示 API 定義変更と依存するclient の更新タイミングを強制 インテグレーションと依存関係管理の問題に対応
29. OpenAPI zod msw fetch API OpenAPI zod Orval Orval Orval API サーバー メッセージ配信基盤 package 同士の通信 zod Orval 通知基盤 fetch API zod Orval プラン管理基盤 OpenAPI
30. 技術的複雑性のカプセル化
31. 通知基盤
32. 直近3 ヶ月の1 日あたりの最高値は40,000 件 全ての共通化が完了したら100,000 件想定 直近3 ヶ月の最もスパイクした瞬間は秒間105 件 通知基盤
33. メッセージ配信基盤
34. メッセージ配信基盤 イベント駆動アーキテクチャ インフラ AWS CDK lambda bun build でlambda target をnode でビルド Dockerfile aws cdk
35. 横断するドメイン知識を深めて 共通サービスプラットフォーム自体 がプロダクト価値とユーザー体験 を作る
36. ②コアプラットフォーム
37. レバレッジ Platfrom Engineering の価値の中核 であるレバレッジ “ ビジネス価値を作成する際の生産性 を向上させることと、チーム間の重 複作業を排除することでエンジニア リング組織を効率化すること“ 引用: 「PlatformEngineering -Chapter 1. Why Platform Engineering Is Becoming Essential- 」
38. 増幅する運用コストの最小 化 依存関係の整理 ①ビジネス価値を開発 する際の生産性向上 設定の共有 基盤の再利用による高速 なプロダクト開発 ②チーム間の重複作業の排除 Platform Engineering のレバレッジ
39. フルサイクル開発の課題と複数チー ムの重複作業をプラットフォームエ ンジニアリングのレバレッジで解消
40. ①ビジネス価値を作成する際の生産 性向上 → 増幅する運用コストの最小化
41. メンテナンスコスト “ セキュリティパッチの適用に必要な アップグレード、ソフトウェアの再 テスト、基盤となる依存関係の新し いバージョンへの移行など、ソフト ウェアのメンテナンスには多くのエ ンジニアリング時間がかかります。 ” 引用: 「PlatformEngineering -Chapter 1. Why Platform Engineering Is Becoming Essential- 」
42. ②チーム間の重複作業の排除
43. コアプラットフォームの重複作業例 ライブラリのバージョンアップ Linter / Formatter / tsconfig のルール追加・変更 CI/CD AI コンテキスト コードガイドライン UI コンポーネントの追加・変更
44. 依存関係の管理 “ オープンソフトウェア(OSS) モデルが新 たな要因向けて発展と拡大を続け、また 人気がある様々なプロジェクトの依存関 係グラフが時間の経過とともに拡大を続 けていくのに伴い、おそらくは依存関係 の管理が、ソフトウェアエンジニアリン グポリシー内における最重要問題となっ ていく。“ 引用: 「Google のソフトウェアエンジニアリング」 P.498
45. 新たな課題💡 共通サービスプラットフォームを含 めた複数プロダクトの依存解決とイ ンテグレーション
46. モノリポ “ 単一のリポジトリー( モノリポ) を持つ大 規模組織は、ソースコントロールのポリ シーを用いて、別々のリポジトリーを使 う場合と比べ圧倒的に先までスケールア ップ可能であり、それがGoogle のアプロ ーチである。“ 引用: 「Google のソフトウェアエンジニアリング」 P.498
47. モノレポと技術選定の背景 機能開発は既にFull-Stack TS 旧システムではバックエンドがPython 、フロントエンド がTS 技術スタックを増やす事での認知負荷を上げたくない TS 周辺のモノレポ、複数プロダクト連携を支えるエコシ ステムが充実している
48. モノレポを支える TS エコシステム TypeScript Bun server build test package workspace Biome commitlint
49. Bun 高速なtest ランナー シングルバイナリへのビルドで実行 ファイルのサイズ圧縮 workspace 内の厳格なライブラリ依 存関係管理 どうしても行き詰まったらNode.js に 移行可能
50. 具体的な構成
51. root ディレクトリ Bun workspace でのパッケー ジ分割 3 種類のファイル群 1.package 間で共有するファイ ル 2. 各package で必要に応じてカ スタマイズするファイル 3. 各package で必ず用意するフ ァイルのベースファイル package.json でのworkspaces 指定
52. 各package アプリケーション共通基盤の 責務ごとに分割 数個の設定ファイル + src ディ レクトリのミニマム構成でク イックスタート root の設定を継承する事でシ ンプルな設定ファイル 最悪パッケージ毎リニューア ルできる biome.json pacakages ディレクトリ構成 tsconfig.json
53. 横断scripts package.json のscripts と workspace 横断で一括実行する処理を scripts で管理 コマンド名はpackage 間で統 一
54. 課題 対策 効果 ①複数チームで統一したい振 る舞いや機能の重複・繰り返 し 共通サービスプラットフォーム プラットフォームの再利用による 機能の立ち上げ速度向上 共通基盤自体のプロダクト価値 基盤同士のデータ連携 技術的複雑性のカプセル化 コアプラットフォーム 設定ファイルの共有 横断スクリプト ②開発と比例する運用コスト 増加によるスピード低下 コアプラットフォーム 増幅する運用コストの最小化 ③共通サービスプラットフォ ームを含めた複数プロダクト の依存解決とインテグレーシ ョン コアプラットフォーム モノレポによる複数プロダクト のインテグレーション OpenAPI でのスキーマ駆動開発 による厳密なIF と型での依存管理 課題・対策・効果の整理
55. アジェンダ 主題の背景となるプロダクト とビジネスの説明と発生する 技術課題 ビジネスとプロダクト プロダクト開発の課題に技術 基盤としての対応 ソリューション 今後の課題例について 今後の課題例 1 2 3
56. docker image size Bun compile がいくつかのライブラリで失敗する Bun の理解 マイナーアップグレードするとテストが落ちる 調査して解消の運用負荷がある 課題
57. docker image size 放っておくとすぐに肥大化する 初期のサイズは700MB 翌月には2.6GB → 1.5GB まで減らす さらに翌翌月には再び2.6GB → 1.6GB まで減らす 初期 肥大化① 肥大化②
58. 今後のプラットフォーム 共通サービスプラットフォームがまだまだ足りない 権限 認証 アカウント管理 など DB 分離 デプロイ分離 機能側もpackage 分割を進めていく
59. フルサイクルなマルチプロダクト開 発にレバレッジを効かせるコアプラ ットフォームと、新たな価値を作る 共通サービスプラットフォームに Full-Stack TS をフル活用！！
60. おわり