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

by Shodai Suzuki

Slide 1

Slide 1 text

Full-Stack TS でのマルチプロダクト基盤開発 Shodai Suzuki @SoartecL TSKaigi Hokuriku 2025 2025.11.23 © MOSH Inc.

Slide 2

Slide 2 text

鈴木翔大 X @SoartecL VP of Technology Productivity チーム( 技術基盤チーム) 趣味 OSS Orval メンテナダイビング

Slide 3

Slide 3 text

アジェンダ主題の背景となるプロダクトとビジネスの説明と発生する技術課題ビジネスとプロダクトプロダクト開発の課題に技術基盤としての対応ソリューション今後の課題例について今後の課題例 1 2 3

Slide 4

Slide 4 text

MOSH のビジネス

Slide 5

Slide 5 text

クリエイターヨガ・フィットネスヘルス・ウェルネス育児・子育て養成講座・スクールオンラインサロン・コミュニティメイク・ビューティー

Slide 6

Slide 6 text

マルチプロダクト

Slide 7

Slide 7 text

マルチプロダクト開発を実現する Full-Stack TS とフルサイクル開発を行なっています

Slide 8

Slide 8 text

フルサイクル開発プロダクト仕様から開発、運用、サポートまでのライフサイクル全体を一貫して担うドメイン理解を深めて最適なソリューションを採用するチームの自律性を高めてスループットを上げるチーム外とのコミュニケーション組織全体の知見を活用する引用: 「Full Cycle Developers at Netflix — Operate What You Build 」 https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249

Slide 9

Slide 9 text

ドメイン理解 “ チーム全員が顧客とかかわりを持たなければならない。これこそ、チームが顧客の気持ちを理解する唯一の方法だ。“ “ 客の意見を聞くのは、商品の強みと弱みを知る一番の方法だ。顧客と作り手の間に人が多いほど、顧客の声は歪んだり失われたりしていく。“ 引用: 「小さなチーム、大きな仕事」 P.230

Slide 10

Slide 10 text

フルサイクルなプロダクト開発を進める中で発生する課題

Slide 11

Slide 11 text

課題① ドメイン理解への集中と同時に開発と比例する運用コスト増加によるスピード低下がフルサイクル開発のリアル

Slide 12

Slide 12 text

生涯コスト “ ソフトウェアの生涯コストの内、少なくとも60 ～75% は初期開発後に発生し、その約4 分の1 は、移行やその他の適応メンテナンスにのみ費やされてる“ 引用: 「PlatformEngineering -Chapter 1. Why Platform Engineering Is Becoming Essential- 」

Slide 13

Slide 13 text

同時開発

Slide 14

Slide 14 text

課題② 複数チームで統一したい振る舞いや機能の重複・繰り返し

Slide 15

Slide 15 text

これらの課題に向かうためアプリケーションの機能と共通基盤を Full-stack TS で同時開発

Slide 16

Slide 16 text

Slide 17

Slide 17 text

今日の主題なぜ基盤開発にTS を採用したいのか Full-stack TS での基盤開発少人数で複数の基盤を開発・運用する技術選定の背景 Full-stack TS の生産性に寄与している事例

Slide 18

Slide 18 text

なぜ基盤開発にTS を採用したいのか？

Slide 19

Slide 19 text

バックエンド共通基盤を含めたFull-stack TS フロントエンド共通基盤共通基盤機能

Slide 20

Slide 20 text

期待と懸念期待 FE/BE 開発で得たFull-Stack TS の生産性を再現したい AI との親和性静的型付け連携システム間の型定義共有同じ言語なのでコンテキストが分断されず目的単位で開発可能懸念共通基盤としての要求に応えられるか事例が少ない中でトラブルシューティング可能か

Slide 21

Slide 21 text

Full-Stack TS の生産性とエコスシステムで共通基盤の構築に挑戦

Slide 22

Slide 22 text

共通基盤とは？ ①共通サービスプラットフォーム “Integration/Shared Services Platforms” アプリケーションの共通基盤 ②コアプラットフォーム “core/infrastructure platform” 引用: 「PlatformEngineering -Chapter 3. How and When to Get Started- 」

Slide 23

Slide 23 text

①共通サービスプラットフォーム

Slide 24

Slide 24 text

共通サービスプラットフォームの例決済通知メッセージ配信クリエイタープラン管理権限アカウント管理

Slide 25

Slide 25 text

共通サービスプラットフォームの価値横断するドメイン知識の深化一貫したユーザー体験基盤同士のデータ連携による価値作り各プロダクト間の共通処理を集約技術的複雑性のカプセル化

Slide 26

Slide 26 text

メッセージ配信基盤顧客管理機能機能と基盤の組み合わせ契約プラン管理基盤決済基盤通知基盤共通サービスプラットフォーム機能売上管理機能

Slide 27

Slide 27 text

継続的インテグレーション “ アプリケーションを破綻させるコード変更は、そのアプリケーションのプロジェクトがある直接のコードベース内に存在している見込みは低く、ネットワーク経由の呼び出しの反対側にある疎結合したマイクロサービス内にある見込みの方が高い。“ 引用: 「Google のソフトウェアエンジニアリング」 P.555

Slide 28

Slide 28 text

OpenAPI でのスキーマ駆動開発各基盤のIF をOpenAPI で定義 client/server ソースコードを自動生成基盤同士のclient/server 間の不整合を解消使用するpackage にclient を出力し依存先を明示 API 定義変更と依存するclient の更新タイミングを強制インテグレーションと依存関係管理の問題に対応

Slide 29

Slide 29 text

OpenAPI zod msw fetch API OpenAPI zod Orval Orval Orval API サーバーメッセージ配信基盤 package 同士の通信 zod Orval 通知基盤 fetch API zod Orval プラン管理基盤 OpenAPI

Slide 30

Slide 30 text

技術的複雑性のカプセル化

Slide 31

Slide 31 text

通知基盤

Slide 32

Slide 32 text

直近3 ヶ月の1 日あたりの最高値は40,000 件全ての共通化が完了したら100,000 件想定直近3 ヶ月の最もスパイクした瞬間は秒間105 件通知基盤

Slide 33

Slide 33 text

メッセージ配信基盤

Slide 34

Slide 34 text

メッセージ配信基盤イベント駆動アーキテクチャインフラ AWS CDK lambda bun build でlambda target をnode でビルド Dockerfile aws cdk

Slide 35

Slide 35 text

横断するドメイン知識を深めて共通サービスプラットフォーム自体がプロダクト価値とユーザー体験を作る

Slide 36

Slide 36 text

②コアプラットフォーム

Slide 37

Slide 37 text

レバレッジ Platfrom Engineering の価値の中核であるレバレッジ “ ビジネス価値を作成する際の生産性を向上させることと、チーム間の重複作業を排除することでエンジニアリング組織を効率化すること“ 引用: 「PlatformEngineering -Chapter 1. Why Platform Engineering Is Becoming Essential- 」

Slide 38

Slide 38 text

増幅する運用コストの最小化依存関係の整理 ①ビジネス価値を開発する際の生産性向上設定の共有基盤の再利用による高速なプロダクト開発 ②チーム間の重複作業の排除 Platform Engineering のレバレッジ

Slide 39

Slide 39 text

フルサイクル開発の課題と複数チームの重複作業をプラットフォームエンジニアリングのレバレッジで解消

Slide 40

Slide 40 text

①ビジネス価値を作成する際の生産性向上 → 増幅する運用コストの最小化

Slide 41

Slide 41 text

メンテナンスコスト “ セキュリティパッチの適用に必要なアップグレード、ソフトウェアの再テスト、基盤となる依存関係の新しいバージョンへの移行など、ソフトウェアのメンテナンスには多くのエンジニアリング時間がかかります。 ” 引用: 「PlatformEngineering -Chapter 1. Why Platform Engineering Is Becoming Essential- 」

Slide 42

Slide 42 text

②チーム間の重複作業の排除

Slide 43

Slide 43 text

コアプラットフォームの重複作業例ライブラリのバージョンアップ Linter / Formatter / tsconfig のルール追加・変更 CI/CD AI コンテキストコードガイドライン UI コンポーネントの追加・変更

Slide 44

Slide 44 text

依存関係の管理 “ オープンソフトウェア(OSS) モデルが新たな要因向けて発展と拡大を続け、また人気がある様々なプロジェクトの依存関係グラフが時間の経過とともに拡大を続けていくのに伴い、おそらくは依存関係の管理が、ソフトウェアエンジニアリングポリシー内における最重要問題となっていく。“ 引用: 「Google のソフトウェアエンジニアリング」 P.498

Slide 45

Slide 45 text

新たな課題💡 共通サービスプラットフォームを含めた複数プロダクトの依存解決とインテグレーション

Slide 46

Slide 46 text

モノリポ “ 単一のリポジトリー( モノリポ) を持つ大規模組織は、ソースコントロールのポリシーを用いて、別々のリポジトリーを使う場合と比べ圧倒的に先までスケールアップ可能であり、それがGoogle のアプローチである。“ 引用: 「Google のソフトウェアエンジニアリング」 P.498

Slide 47

Slide 47 text

モノレポと技術選定の背景機能開発は既にFull-Stack TS 旧システムではバックエンドがPython 、フロントエンドがTS 技術スタックを増やす事での認知負荷を上げたくない TS 周辺のモノレポ、複数プロダクト連携を支えるエコシステムが充実している

Slide 48

Slide 48 text

モノレポを支える TS エコシステム TypeScript Bun server build test package workspace Biome commitlint

Slide 49

Slide 49 text

Bun 高速なtest ランナーシングルバイナリへのビルドで実行ファイルのサイズ圧縮 workspace 内の厳格なライブラリ依存関係管理どうしても行き詰まったらNode.js に移行可能

Slide 50

Slide 50 text

具体的な構成

Slide 51

Slide 51 text

root ディレクトリ Bun workspace でのパッケージ分割 3 種類のファイル群 1.package 間で共有するファイル 2. 各package で必要に応じてカスタマイズするファイル 3. 各package で必ず用意するファイルのベースファイル package.json でのworkspaces 指定

Slide 52

Slide 52 text

各package アプリケーション共通基盤の責務ごとに分割数個の設定ファイル + src ディレクトリのミニマム構成でクイックスタート root の設定を継承する事でシンプルな設定ファイル最悪パッケージ毎リニューアルできる biome.json pacakages ディレクトリ構成 tsconfig.json

Slide 53

Slide 53 text

横断scripts package.json のscripts と workspace 横断で一括実行する処理を scripts で管理コマンド名はpackage 間で統一

Slide 54

Slide 54 text

課題対策効果 ①複数チームで統一したい振る舞いや機能の重複・繰り返し共通サービスプラットフォームプラットフォームの再利用による機能の立ち上げ速度向上共通基盤自体のプロダクト価値基盤同士のデータ連携技術的複雑性のカプセル化コアプラットフォーム設定ファイルの共有横断スクリプト ②開発と比例する運用コスト増加によるスピード低下コアプラットフォーム増幅する運用コストの最小化 ③共通サービスプラットフォームを含めた複数プロダクトの依存解決とインテグレーションコアプラットフォームモノレポによる複数プロダクトのインテグレーション OpenAPI でのスキーマ駆動開発による厳密なIF と型での依存管理課題・対策・効果の整理

Slide 55

Slide 55 text

Slide 56

Slide 56 text

docker image size Bun compile がいくつかのライブラリで失敗する Bun の理解マイナーアップグレードするとテストが落ちる調査して解消の運用負荷がある課題

Slide 57

Slide 57 text

docker image size 放っておくとすぐに肥大化する初期のサイズは700MB 翌月には2.6GB → 1.5GB まで減らすさらに翌翌月には再び2.6GB → 1.6GB まで減らす初期肥大化① 肥大化②

Slide 58

Slide 58 text

今後のプラットフォーム共通サービスプラットフォームがまだまだ足りない権限認証アカウント管理など DB 分離デプロイ分離機能側もpackage 分割を進めていく

Slide 59

Slide 59 text

フルサイクルなマルチプロダクト開発にレバレッジを効かせるコアプラットフォームと、新たな価値を作る共通サービスプラットフォームに Full-Stack TS をフル活用！！

Slide 60

Slide 60 text

おわり