高 案件立ち上げで使われる マッハテンプレート フロントエンド技術選定 2

3 マッハチームと ？

©Classmethod, Inc. 4 マッハチーム ご紹介
 プロダクト開発 「立ち上げ専門チーム」です。 ご提案からデザイン・開発・検証まで一貫してご支援します。 すでにマッハチームで 複数 お客様に開発 ご支援させていただき、価値を感じて頂いております。

©Classmethod, Inc. 5 マッハチームが支援する領域
 参考：https://tumada.medium.com/product-management-triangle-job-description-d18d1855ef65 
 A マッハチームが
 支援する領域
 B マッハチームが
 お客様と共創する領域 
 C お客様が担当する領域 
 A マッハチームが支援する領域 ● 体験設計（UI/UX） ● ユーザーインタビュー、ユーザーテストなどプロダク ト 分析 ● 開発、運用・保守 B マッハチームがお客様と共創する領域 ● プロダクト 仕様策定、プロダクト 解像度を上げて いく ● 開発チーム マネジメント C お客様が担当する領域 ● ビジネス設計、マーケティング

©Classmethod, Inc. 6 マッハチーム 目指すこと
 ① 開発 初動を最 で
 プロダクトが実際に手元で見れるまで（ 0->1）を最 で行います。それにより早い段階からフィードバックしやすい環境を作ります。 ② 機能 追加・変更に強いプロダクト
 中長期的にプロダクトを改善していく前提で考え、機能 追加・変更に強いプロダクトを作ります。 ③ ランニングコストを最適化した構成
 ランニングコストを最適化した構成をご提案します。それにより「本来リソースを費やすべき改善」に費用を充てられます。 ④ 小さく作ることを大切に
 PoCやMVPを作って価値を検証、そ 後でプロダクトを大きくするというプロセスを大切にします。

©Classmethod, Inc. ● 従来 開発チーム チームビルディングから必要に なることが通常で、時間 経過と共に進捗が上がるこ とが多い。 ● マッハチーム チームメンバーを固定化すると共に アーキテクチャ等もチームで標準化しているため開発 初動を高 で立ち上げることが可能。 ○ テンプレートを用意し初期構築 高 化を実現 しています。 ○ React + Serverless + CDK + モノリポ ● 早い段階から「動くも 」が見れるため、より早い段階 からフィードバックしやすい状態を作ります。 7 ① 開発 初動を最 で
 進捗 時間 従来 マッハチーム

8 マッハテンプレート

9 マッハテンプレートと ？ マッハテンプレートと ？ • フルスクラッチで高 にLINEミニアプリを構築するため ア セットテンプレート。こ テンプレートを使って案件 立ち上げ 高 化を実現している • 素早くMVPを作成するため 技術選定がなされてる • かつ長期メンテナンスを見据えた技術選定がなされてる

10 プロジェクト 全体構成 • モノレポ • フロント SPA(React) • フロント CloudFront + S3 • API API Gateway + Lambda • DB 主にDynamo DB、複雑 な要件 場合 RDB + Fargateを採用することも

11 モノリポ

12 ディレクトリ構成 ├── README.md ├── aws-accounts.json ├── cspell.json ├── e2e ├── infra ├── api.openapi.yaml ├── node_modules ├── package-lock.json ├── package.json ├── server ├── shared ├── tsconfig.json └── web E2Eテスト関連 バックエンド インフラ構成(CDK) 共通モジュール API定義(Open API) フロントエンド

13 モノレポ モノレポ 内容 • 言語 TypeScriptで統一 • CDKでフロントエンドをデプロイ

14 言語 TypeScriptで統一 バックエンド、フロントエンド、インフラ全てでTypeScriptを採 用してる バックエンドとフロントエンド インターフェース(API) OpenAPIで定義し、OpenAPIを元に型生成をし、それぞれ サービスで共通 型定義が使えるようにしている ただ、フロントエンドとバックエンドで共通利用できるモジュー ル ほとんどない 型定義 共通利用と言語 習得コスト 削減が主な理由

15 フロントエンド CDK •CloudFront 基本的な 設定もコード管理 •セキュリティ系ヘッダもコー ド管理 •こ CDKを複数案件で使うこ とで初期構築 コスト削減と 品質を保証 const webDistribution = new aws_cloudfront .Distribution( this, "WebDistribution" , { defaultBehavior: { allowedMethods: aws_cloudfront .AllowedMethods .ALLOW_GET_HEAD , cachedMethods: aws_cloudfront .CachedMethods.CACHE_GET_HEAD , cachePolicy: aws_cloudfront .CachePolicy.CACHING_OPTIMIZED , viewerProtocolPolicy: aws_cloudfront .ViewerProtocolPolicy .REDIRECT_TO_HTTPS , origin: new aws_cloudfront_origins .S3Origin(webBucket, { originAccessIdentity , }), responseHeadersPolicy: new aws_cloudfront .ResponseHeadersPolicy ( this, "WebResponseHeaderPolicy" , { securityHeadersBehavior: { contentSecurityPolicy: {... }, contentTypeOptions: {... }, frameOptions: { … }, strictTransportSecurity: { … }, },

16 モノレポ モノレポ 理由 • 少人数で明確にバックエンド、フロントエンドと役割を明確に分 けずに開発を進めていく で、リポジトリがまとまってる方が1つ PR 中に両方 変更をまとめやすくやりやすい　 • プロジェクト進行に必要な全て 情報をGithubに集約し、開発 効率 向上を測っている。 具体的にソースコード=> リポジトリ、タスク（ボード）=> Github Projetcts、ドキュメント=> Github Wiki と Github に集約している

17 フロントエンド技術選定

18 フロントエンド技術選定 マッハテンプレート フロントエンド技術選定 • Tailwind (CSSフレームワーク) • SWR • MUI(UIライブラリ) 使わない • 状態ライブラリを使わない

19 CSS Tailwindを使う

20 Tailwind Tailwind 選定理由 • 小回りが効く • CSS設計 スキルレベル 影響が少ない • 長期保守 際にメンテナンス性が高い • AIと相性が良い

21 Tailwind - 小回りが効く 純粋なCSS クラスでスタイリングするため、小回りがききや すい。 ライブラリを使わない分、0からHTMLを書いてそれらにスタイ ルを当てる手間があるが、自由にスタイルを当てることがで き、想定外 顧客 要望に答えやすい ライブラリに依存していると、要望に答えきれないケースが 発生してしまう また、CSS 進化でスタイリングがそこまで手間 かかる作 業にならなくなってきてる

22 Tailwind - CSS設計 スキルレベル 影響が少ない CSS設計 知識 差に影響されない Tailwindを使うとクラス名に構 や役割を持たせるような設 計手法 必要なくBEM等に代表されるCSS設計 知識がスタ イリング メンテナンス性に影響されにくい PRレビュー 手間が軽減される Pull Request レビュー時にPureなCSS 場合 CSS 書き方 に幅があるため、CSSとHTMLと両方指摘する必要がある が、TailwindだとHTMLを直してもらうだけでよくなり、レビュー 手間が省ける

23 Tailwind - 長期運用 メンテナンス性が高い 使われないCSSが残りにくい HTML DOMを消す際にCSSが残ることがない そ ため、使われないCSSが残ってしまうことがなく、使わら ないCSSがメンテナンスされないまま残ることがない 純粋なCSSフレームワーク ReactやVueなど フレームワークに依存しない技術な で、 仮にフレーワーク トレンドが変わっても、Tailwind 使い続 けることができる可能性が高い

24 Tailwind - AIと相性が良い HTMLとCSSが1つファイルに書かれるため、 Github Copilotがプロジェクト内 ソースコードを元に行う自 動補完と相性が良い

25 SWR

26 SWR SWR 選定理由 • 機能がシンプル • キャッシュ管理がシンプル • デフォルト設定をfetchが過剰な でカスタム

27 SWR - シンプルな機能 TanStackQuery 方が高機能だが、実際に 使わない機能 も多い SWRで使えるシンプルな機能だけでもほとんど 場合 十分な で、軽量でシンプルに使えるSWRを採用

28 SWR - キャッシュ管理がシンプル TanStack Queryだとキャッシュ管理が難しく、最新 情報を表 示したい場合でも、意図せずにキャッシュが残ってしまい、古 い情報が表示されてままということが何度かあった こ 点も考慮してキャッシュ管理がシンプルなSWRを採用

29 SWR - デフォルト設定をfetchが過剰な でカスタム ただ、デフォルト 設定で 、fetchが過剰に走ってしま うため、カスタマイズ

30 MUI 使わない

31 MUI(UIライブラリ) MUI(UIライブラリ)を使わない理由 • デザインをMUIに寄せる必要がある • アップデート時 コストが高い

32 デザインをMUIに寄せる必要がある デザインをMUIをベースに考える必要がある MUI パーツをベースに作成できるとデザインだとFigma コ ンポーネントも使えてデザイン 時間、開発 時間を短縮で きるがMUIから離れたことをしようとすると一気に工数が膨ら んでしまう

33 アップデート コストが高い 破壊的変更があった場合(v5) 以降 コストが高すぎること が多かった バージョンアップに時間がかかりすぎて、開発初期に短縮で きた時間を上回る マッハチーム 運用 基本方針としてライブラリ 短いサイ クルでアップデートし続ける で、UIライブラリ アップデート コストが見合わないと判断

34 状態ライブラリを使わない

35 状態ライブラリ 状態ライブラリを使わない理由 • 必要なケースが減っている • どうしても必要な場合 SWRを使う

36 状態ライブラリ - 必要なケースが減っている SWRやTanStack Queryなど 登場により、グローバルステー トに状態を持たす必要性が減ってる そ ため、Reduxなど 状態管理ライブラリを導入する理由 がほぼほぼなくなてきている Reduxなど 状態管理 複雑化しやすい で、必要性がな い であれ 、最初から割り切って導入しない方針としてい る

37 状態ライブラリ - どうしても必要な場合 SWRを使う と いえ、一つ 案件を通して、全くグローバルステートを使 わないことも難しく、必要に応じてSWR fetch関数にnullを指 定、キャッシュ インバリデートを無効にしたグローバル キャッシュ領域をグローバルステートとして利用する方針に している 使うライブラリを最低限とすることで、シンプルなプロジェクト 構 と開発効率 向上を狙っている

38 フロントエンド技術選定(まとめ) マッハテンプレート フロントエンド技術選定 • Tailwind (CSSフレームワーク) => 柔軟性と長期メンテを考慮して採用 • SWR => 機能性 シンプルさ重視 • MUI(UIライブラリ) 使わない => 柔軟性と長期メンテを考慮して使用しない • 状態ライブラリを使わない => 必要性が薄くなっており明確な理由がないと使わない

©Classmethod, Inc. 39 マッハチーム ご紹介
 マッハチーム 新しい仲間を募集しています！ 少しでも興味がわいた方 こ 後気軽に話しかけてください！！！

40