リアーキテクチャとAI 活用で実現する 急成長プロダクトの開発生産性向上 Shodai Suzuki @SoartecL 開発生産性Conference 2025 2025.07.03 © MOSH Inc. 

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

アジェンダ 主題の背景となるプロダクト とビジネスの説明 ビジネスとプロダクト AI を含めた開発生産性の向上 とアーキテクチャによる限界 生産性 生産性と限界生産性 成果事例、現在の状況と今後 の課題例について 成果と今後の課題例 1 2 3 

MOSH のビジネス 

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

オールインワンプロダクト 

事業成長2 年連続300% 成長🚀 

個人・少人数で経済圏を作る クリエイターが続出 ①市場の活性化 生成AI をはじめとするテクノ ロジーの進化によるクリエイ ター個人の生産性と事業拡大 のポイントに ②AI の進化 外部環境の変化 

競争的優位 “ 技術の状況が移り変わる速さと予測不可 能性とを前提とすると、あらゆる製品に とって、競争的優位とは、迅速に市場へ の投入ができる能力の中に存在するもの である。“ 引用: 「Google のソフトウェアエンジニアリング」 P.585 

あの頃の私たち 低凝集・高結合なソースコード 過度なファイル分割による低凝集 不要な共通化による不要な高結合 不要なAPI 呼び出しと待機 client / server 間のAPI 定義が不一致 信じられないOpenAPI 1 時間かかる手動デプロイは不安定 400 超Lambda のメンテナンスコスト バックエンドが突然デプロイできなくなる 

課題① 外部環境の変化に対して ソフトウェアの適応速度が鈍化 

アジェンダ 主題の背景となるプロダクト とビジネスの説明 ビジネスとプロダクト AI を含めた開発生産性の向上 とアーキテクチャによる限界 生産性 生産性と限界生産性 成果事例、現在の状況と今後 の課題例について 成果と今後の課題例 1 2 3 

今日の主題 外部環境による変化 クリエイターエコノミー市場・指名経済圏の発展 事業の急成長 生成AI をはじめとするテクノロジーの進化 急速変化するソフトウェア要求 要求に適応するための開発生産性への取り組み 

生産性/ 限界生産性 生産性 “ 生産性の標準的な定義は、労働 者一人当たりの平均生産量“ 限界生産性 “ 限界生産性とは、労働者が一人 増えるおかげで、生産量が増大し たり、サービスを提供できる顧客 が増加したりすることでもたらさ れる追加的な寄与である。 “ 引用: 「技術革新と不平等の1000 年史 上 」 P.44, 45 

AI と生産性 

押し寄せるAI の波 活用事例 開発 軽微なバグ修正・文言変更 デモ・プロトタイピング ドキュメンテーション 新メンバーのオンボーディング コード移行 Angular からReact へのリプレイ ス Python リポジトリの統合 

VibeCoding 70% Problem “ 目標の70% までは、驚くほど早く到 達できます。“ “ 最後の30% 、つまりソフトウェアを 本番環境で使用可能で、保守性と堅 牢性を備えたものにするには、依然 として真のエンジニアリング知識が 必要です。“ 引用: 「https://addyo.substack.com/p/the-70-problem-hard-truths-about 」 「Beyond Vibe Coding 」 

ソフトウェアエンジニリング “ プログラミングとは、コードを生産する 即時的行動である。“ => VibeCoding の驚くほど早く到達な 70% との親和性が高い “ ソフトウェアエンジニアリングとは、コ ードを利用しなければならない期間中に 有用に保つのに必要であり、またチーム を横断した共同作業を可能とする、ポリ シー、プラクティス、ツールのセット である。“ => 依然として真のエンジニアリング知識 が必要な最後の30% 引用: 「Google のソフトウェアエンジニアリング」 P.28, 29 

AI による生産性向上についての評価 「驚くほど早く到達できる70% 」に対する開発の生産性 は劇的に向上 生産性 = 時間あたりの生産量 「依然として真のエンジニアリング知識が必要な30% 」 に該当する開発の生産性向上は実感していない 顧客への追加的な寄与である限界生産性が上がってい ない 

生産性の激増に対して限界生産性は どうなってるのか？ → 制約条件の理論で考える 

制約条件の理論 スループット “ 販売を通じてお金を作り出す割 合のこと“ ボトルネック “ その処理能力が、与えられてい る仕事量と同じか、それ以下のリ ソースのこと“ “ ボトルネックの一時間あたりの 生産能力が組織の一時間あたりの 生産能力“ => 開発量が増えても限界生産性は比例し て上がらない 引用: 「ザ・ゴール」 P.97, 217, 247 

スループットはコードをデリバリーする品質管理 ボトルネックは「依然として真のエンジニアリング知識 が必要な30% 」の開発 ドメイン理解、設計、コードレビューなど 生産量が激増した事で一つ一つの品質が低下する力学が 生まれる構造 バッチサイズの肥大化によりすり抜け 動いているからOK と言うバイアス( バイブス) 品質低下によりスループット低下 AI による生産性と限界生産性の課題 

課題② 激増した「驚くほど早く到達できる 70% の生産性」と「依然として真 のエンジニアリング知識が必要な 30% 」に依存する限界生産性の頭 打ちによる乖離 

激増した「驚くほど早く到達で きる70% の生産性」と「依然と して真のエンジニアリング知識 が必要な30% 」に依存する限界 生産性の頭打ちによる乖離 外部環境の変化に対して ソフトウェアの適応速度が 鈍化 ①適応速度 ②限界生産性の頭打ち 課題整理 

競争的優位としての適応速度と限界 生産性の頭打ちを 組織とシステム両面で解決する 

スループットを上げるための 自律駆動した開発チームと、 それを実現する為の横断した プロダクティビティチーム ①組織 ソフトウェアエンジニアリン グの複雑性を低減し限界生産 性を向上するシステムアーキ テクチャ ②システム 限界生産性の向上 

組織アーキテクチャ スループットを上げるための自律駆動 依然として真のエンジニアリング知識が必要な30% ドメイン理解 設計 コードレビュー 品質管理 チーム外とのコミュニケーション 組織全体の知見を活用する 

フルサイクル開発 引用: 「Full Cycle Developers at Netflix — Operate What You Build 」 https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249 

小さなチーム “ 小さなチームでは、人に仕事を振る 人間ではなく、働いてくれる人間が 必要だ。全員が何かを生み出さなけ ればならない。“ “ そこには無駄の余地はなく、創造性 が求められるのだ。“ “ チーム全員が顧客とかかわりを持た なければならない。これこそ、チー ムが顧客の気持ちを理解する唯一の 方法だ。“ => 全員が開発に向き合い適応速度を維持 できる3~5 人の構成 引用: 「小さなチーム、大きな仕事」 P.67, 210, 230 

開発ユニット + 横断チーム 

自律駆動するチームがスループット を上げ限界生産性を向上 

スループットを上げるための 自律駆動した開発チームと、 それを実現する為の横断した プロダクティビティチーム ①組織 ソフトウェアエンジニアリン グの複雑性を低減し限界生産 性を向上するシステムアーキ テクチャ ②システム 限界生産性の向上 

システムアーキテクチャ フロントエンド、バックエンドをリアーキテクチャ 段階的にアップデートして価値を作る 新旧アプリケーションの共存 フルサイクル開発実現のための抽象化・簡略化 ガードレールを作る 影響範囲の限定 AI による生成コードの質 高速な検証サイクルの実現 高い成果が見込まれるモダンな技術は積極的に採用 

新旧の共存 “ 十分な保全さえ実施しておれば、たと えその保全に費用が発生しようとも、 買い替えた方が安くつくなどという話 はありえぬことだ。“ => 旧システムをメンテナンス可能な状 態にして新機能で活用する方針 引用: 「トヨタ生産方式」 P.116 

フロントエンド 

フロントエンドのアーキテクチャ ゼロベースで技術選定 Angular ベースからReact + ReactRouter へ SPA 構成 既存のバックエンドAPI を活用するため 旧アプリケーションとの共存のため UI コンポーネントの刷新 スキーマ駆動開発 マルチデバイス対応 

ReactRouter File-based ルーティングを用いた一 貫性のあるディレクトリ構成 app/routes 配下にページ単位で ディレクトリを作成 コンポーネントのCo-Location route.tsx がページコンポーネン トに、その他のtsx がページ内 での関心毎のコンポーネントに 分離 Feature-Sliced Design による 影響範囲の限定 各種Config のプリセット 例えば、 「/123/inquiry 」の場合 

UI コンポーネント shadcn-ui Headless UI を使用して最 小限のUI コンポーネント を高速に揃える 将来的にプロダクトに最適 化できる余地を残す マルチデバイスやa11y へ の対応もカバー 自作のコンポーネントも共存 

スキーマ駆動開発 OpenAPI 定義からソースコードを 自動生成することにより、client ・ server 間での不整合を除去 API クライアント zod スキーマによるリクエス ト・レスポンス型 テスト用モックのmsw OpenAPI 定義の必須化によりAPI 設 計の円滑化・品質担保 ＋ zod msw swr + fetch API Orval OpenAPI 

ページ単位 コンポーネ ント ページ単位 コンポーネ ント ページ単位 コンポーネ ント 共通の開発環境 UI コンポーネント API 呼び出し処理 フロントエンド技術基 盤 共通基盤 UI コンポーネント 自動生成されるAPI クライ アント ReactRouter 構成に従ったペ ージ・機能単位コンポーネン ト => 影響範囲を限定し機能開発に 集中できる構成 ペ ー ジ 毎 の コ ン ポ ー ネ ン ト 共 通 基 盤 

バックエンド( 旧システム) 

バックエンドのアーキテクチャ 全てのモダン化をゴールに置かない API 単位で旧から新への移行を可能にする 主要リソースの開発は継続 主要では無いリソースはメンテナンス可能な状態にし てフリーズ とにかくメンテナンス可能にする インフラとアプリケーションの密結合解消 デプロイ速度・安定性 オブザーバビリティ 

CI/CDの改善 CIプロセスの刷新 github actionでデプロイパイプラ イン構築しデプロイ自動化 任意のfeatureブランチでデプロイ 可能に tag pushをトリガーに本番環境デ プロイする事でtag管理が徹底 ↓ 

↓ 移植性の向上 lambda アーティファクト形式をzip からdocker に変更 400 超のLambda を1 つのLambda に 集約 FastAPI を導入してLambda 内 でAPI をルーティング 「FastAPI が動いているDocker イ メージ」状態を作り移植性を向上 明文化したOpenAPI からFastAPI の コントローラーを自動生成して型 安全に 

リソースサーバの一つとして管理 

BFF 

BFF の目的 旧バックエンドはリソースサーバーとして影響範囲を限 定しながら運用 旧バックエンドAPI に対する腐敗防止層 システム間はOpenAPI による定義と自動生成で型安全 に通信 段階的なリファクタリング API を新基盤にリプレイス データソースをAPI からDB に変更 プロトタイピングのスピード・品質 

OpenAPI zod msw ＋ swr + fetch API fetch API OpenAPI zod Orval Orval Orval フロントエンド BFF リソースサーバー ( 旧バックエンド) BFF アーキテクチャ fastapi-code- generator 

OpenAPI zod msw ＋ swr + fetch API fetch API OpenAPI zod Orval Orval Orval フロントエンド BFF リソースサーバー ( 旧バックエンド) BFF アーキテクチャ fastapi-code- generator 

ソフトウェアエンジニアリングの複 雑性を低減して頭打ちになっていた 限界生産性を向上 

アジェンダ 主題の背景となるプロダクト とビジネスの説明 ビジネスとプロダクト AI を含めた開発生産性の向上 とアーキテクチャによる限界 生産性 生産性と限界生産性 成果事例、現在の状況と今後 の課題例について 成果と今後の課題例 1 2 3 

AI を含めた生産性向上 + 組織・システムのリアーキテクチャ による限界生産性の向上 

成果例① プロトタイピングの品質とスピード 

成果例② デプロイ数9 倍 

成果例③ パフォーマンスとコストの改善 

課題例: 技術の複雑性 UI コンポーネント shadcn-ui ベースなので生成AI と親和性が高いと分析 今後はプロダクトに最適化させたい コンポーネントカタログ、MCP などを中心としたデザ インシステム、周辺の基盤構築の難易度 新旧の技術スタックの乖離による複雑性 

事業の急成長に対するプロダクトの適応速度の課題 AI をはじめとする環境の変化により生産性が向上 限界生産性の向上のためにスループットを上げるソフト ウェアエンジニアリングが必要 AI を含めた生産性向上 + リアーキテクチャによる限界生 産性の向上 新しい価値を検証するプロトタイピングが高速化 迅速に市場への投入ができる能力による競争的優位の獲 得に寄与している まとめ 

おわり 

APPENDIX 割愛した引用 

ソフトウェア要求 “ ソフトウェア製品の長期的なライフサイ クルの中で必要となるのは、新しいアイ デアの高速の探求、状況の変化やユーザ の問題への高速な応答、スケールした状 態で開発者が速度を出すことの実現であ る。“ 引用: 「Google のソフトウェアエンジニアリング」 P.585 

品質管理 “ 品質を無視すれば、売り上げが上がって も、そう長続きはしない。 ボトルネックを通った後で欠陥が出ては 意味がないから、ボトルネックの作業は しっかりと管理しないといけない。“ 引用: 「ザ・ゴール」 P.245, 247 

小さなチームの制約 “ 制約は見方を変えれば武器である。資源 が制限されると、それでなんとかしなけ ればならなくなる。そこには無駄の余地 はなく、創造性が求められるのだ。“ 引用: 「小さなチーム、大きな仕事」 P.67 

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

Lambda-lith の選定 AWS のDeveloper Guide※1 では イベントドリブンのAnti-patterns として紹介 AWS Compute Blog※2 ではサー バーレスマイクロサービスの設計 アプローチの1 つとして紹介 MOSH ではECS/EKS への移行予定 のため中継地点として採用 まずは「FastAPI が動いている Docker イメージ」を目指す Lambda 上でシンプルな構成で 動かした後ECS/EKS へ移行する Anti-patterns in Lambda-based event- driven applications 「Understanding events and event-driven architectures 」※1 ※1 引用文献: https://docs.aws.amazon.com/lambda/latest/dg/concepts-event-driven-architectures.html#monolith ※2 引用文献: https://aws.amazon.com/jp/blogs/compute/comparing-design-approaches-for-building-serverless-microservices/ many development teams move in the opposite direction, aggregating all code related to an API inside the same Lambda function. 「Comparing design approaches for building serverless microservices 」※2