Upgrade to Pro — share decks privately, control downloads, hide ads and more …

リアーキテクチャとAI活用で実現する急成長プロダクトの開発生産性向上

Avatar for Shodai Suzuki Shodai Suzuki
July 03, 2025
130

 リアーキテクチャとAI活用で実現する急成長プロダクトの開発生産性向上

2025-07-03 「開発生産性Conference 2025」の登壇資料です。

Avatar for Shodai Suzuki

Shodai Suzuki

July 03, 2025
Tweet

Transcript

  1. あの頃の私たち 低凝集・高結合なソースコード 過度なファイル分割による低凝集 不要な共通化による不要な高結合 不要なAPI 呼び出しと待機 client / server 間のAPI

    定義が不一致 信じられないOpenAPI 1 時間かかる手動デプロイは不安定 400 超Lambda のメンテナンスコスト バックエンドが突然デプロイできなくなる
  2. 生産性/ 限界生産性 生産性 “ 生産性の標準的な定義は、労働 者一人当たりの平均生産量“ 限界生産性 “ 限界生産性とは、労働者が一人 増えるおかげで、生産量が増大し

    たり、サービスを提供できる顧客 が増加したりすることでもたらさ れる追加的な寄与である。 “ 引用: 「技術革新と不平等の1000 年史 上 」 P.44, 45
  3. VibeCoding 70% Problem “ 目標の70% までは、驚くほど早く到 達できます。“ “ 最後の30% 、つまりソフトウェアを

    本番環境で使用可能で、保守性と堅 牢性を備えたものにするには、依然 として真のエンジニアリング知識が 必要です。“ 引用: 「https://addyo.substack.com/p/the-70-problem-hard-truths-about 」 「Beyond Vibe Coding 」
  4. ソフトウェアエンジニリング “ プログラミングとは、コードを生産する 即時的行動である。“ => VibeCoding の驚くほど早く到達な 70% との親和性が高い “

    ソフトウェアエンジニアリングとは、コ ードを利用しなければならない期間中に 有用に保つのに必要であり、またチーム を横断した共同作業を可能とする、ポリ シー、プラクティス、ツールのセット である。“ => 依然として真のエンジニアリング知識 が必要な最後の30% 引用: 「Google のソフトウェアエンジニアリング」 P.28, 29
  5. 制約条件の理論 スループット “ 販売を通じてお金を作り出す割 合のこと“ ボトルネック “ その処理能力が、与えられてい る仕事量と同じか、それ以下のリ ソースのこと“

    “ ボトルネックの一時間あたりの 生産能力が組織の一時間あたりの 生産能力“ => 開発量が増えても限界生産性は比例し て上がらない 引用: 「ザ・ゴール」 P.97, 217, 247
  6. フルサイクル開発 引用: 「Full Cycle Developers at Netflix — Operate What

    You Build 」 https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249
  7. 小さなチーム “ 小さなチームでは、人に仕事を振る 人間ではなく、働いてくれる人間が 必要だ。全員が何かを生み出さなけ ればならない。“ “ そこには無駄の余地はなく、創造性 が求められるのだ。“ “

    チーム全員が顧客とかかわりを持た なければならない。これこそ、チー ムが顧客の気持ちを理解する唯一の 方法だ。“ => 全員が開発に向き合い適応速度を維持 できる3~5 人の構成 引用: 「小さなチーム、大きな仕事」 P.67, 210, 230
  8. フロントエンドのアーキテクチャ ゼロベースで技術選定 Angular ベースからReact + ReactRouter へ SPA 構成 既存のバックエンドAPI

    を活用するため 旧アプリケーションとの共存のため UI コンポーネントの刷新 スキーマ駆動開発 マルチデバイス対応
  9. ReactRouter File-based ルーティングを用いた一 貫性のあるディレクトリ構成 app/routes 配下にページ単位で ディレクトリを作成 コンポーネントのCo-Location route.tsx がページコンポーネン

    トに、その他のtsx がページ内 での関心毎のコンポーネントに 分離 Feature-Sliced Design による 影響範囲の限定 各種Config のプリセット 例えば、 「/123/inquiry 」の場合
  10. UI コンポーネント shadcn-ui Headless UI を使用して最 小限のUI コンポーネント を高速に揃える 将来的にプロダクトに最適

    化できる余地を残す マルチデバイスやa11y へ の対応もカバー 自作のコンポーネントも共存
  11. スキーマ駆動開発 OpenAPI 定義からソースコードを 自動生成することにより、client ・ server 間での不整合を除去 API クライアント zod

    スキーマによるリクエス ト・レスポンス型 テスト用モックのmsw OpenAPI 定義の必須化によりAPI 設 計の円滑化・品質担保 + zod msw swr + fetch API Orval OpenAPI
  12. ページ単位 コンポーネ ント ページ単位 コンポーネ ント ページ単位 コンポーネ ント 共通の開発環境

    UI コンポーネント API 呼び出し処理 フロントエンド技術基 盤 共通基盤 UI コンポーネント 自動生成されるAPI クライ アント ReactRouter 構成に従ったペ ージ・機能単位コンポーネン ト => 影響範囲を限定し機能開発に 集中できる構成 ペ ー ジ 毎 の コ ン ポ ー ネ ン ト 共 通 基 盤
  13. ↓ 移植性の向上 lambda アーティファクト形式をzip からdocker に変更 400 超のLambda を1 つのLambda

    に 集約 FastAPI を導入してLambda 内 でAPI をルーティング 「FastAPI が動いているDocker イ メージ」状態を作り移植性を向上 明文化したOpenAPI からFastAPI の コントローラーを自動生成して型 安全に
  14. BFF

  15. OpenAPI zod msw + swr + fetch API fetch API

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

    OpenAPI zod Orval Orval Orval フロントエンド BFF リソースサーバー ( 旧バックエンド) BFF アーキテクチャ fastapi-code- generator
  17. 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