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

クラスメソッドのReact事情大公開スペシャル#3
https://classmethod.connpass.com/event/316669/

発表資料

1. 高 案件立ち上げで使われる マッハテンプレート フロントエンド技術選定 2
2. 3 マッハチームと ？
3. ©Classmethod, Inc. 4 マッハチーム ご紹介
 プロダクト開発 「立ち上げ専門チーム」です。 ご提案からデザイン・開発・検証まで一貫してご支援します。 すでにマッハチームで 複数 お客様に開発 ご支援させていただき、価値を感じて頂いております。
4. ©Classmethod, Inc. 5 マッハチームが支援する領域
 参考：https://tumada.medium.com/product-management-triangle-job-description-d18d1855ef65 
 A マッハチームが
 支援する領域
 B マッハチームが
 お客様と共創する領域 
 C お客様が担当する領域 
 A マッハチームが支援する領域 • 体験設計（UI/UX） • ユーザーインタビュー、ユーザーテストなどプロダク ト 分析 • 開発、運用・保守 B マッハチームがお客様と共創する領域 • プロダクト 仕様策定、プロダクト 解像度を上げて いく • 開発チーム マネジメント C お客様が担当する領域 • ビジネス設計、マーケティング
5. ©Classmethod, Inc. 6 マッハチーム 目指すこと
 ① 開発 初動を最 で
 プロダクトが実際に手元で見れるまで（ 0->1）を最 で行います。それにより早い段階からフィードバックしやすい環境を作ります。 ② 機能 追加・変更に強いプロダクト
 中長期的にプロダクトを改善していく前提で考え、機能 追加・変更に強いプロダクトを作ります。 ③ ランニングコストを最適化した構成
 ランニングコストを最適化した構成をご提案します。それにより「本来リソースを費やすべき改善」に費用を充てられます。 ④ 小さく作ることを大切に
 PoCやMVPを作って価値を検証、そ 後でプロダクトを大きくするというプロセスを大切にします。
6. ©Classmethod, Inc. • 従来 開発チーム チームビルディングから必要に なることが通常で、時間 経過と共に進捗が上がるこ とが多い。 • マッハチーム チームメンバーを固定化すると共に アーキテクチャ等もチームで標準化しているため開発 初動を高 で立ち上げることが可能。 ◦ テンプレートを用意し初期構築 高 化を実現 しています。 ◦ React + Serverless + CDK + モノリポ • 早い段階から「動くも 」が見れるため、より早い段階 からフィードバックしやすい状態を作ります。 7 ① 開発 初動を最 で
 進捗 時間 従来 マッハチーム
7. 8 マッハテンプレート
8. 9 マッハテンプレートと ？ マッハテンプレートと ？ • フルスクラッチで高 にLINEミニアプリを構築するため ア セットテンプレート。こ テンプレートを使って案件 立ち上げ 高 化を実現している • 素早くMVPを作成するため 技術選定がなされてる • かつ長期メンテナンスを見据えた技術選定がなされてる
9. 10 プロジェクト 全体構成 • モノレポ • フロント SPA(React) • フロント CloudFront + S3 • API API Gateway + Lambda • DB 主にDynamo DB、複雑 な要件 場合 RDB + Fargateを採用することも
10. 11 モノリポ
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) フロントエンド
12. 13 モノレポ モノレポ 内容 • 言語 TypeScriptで統一 • CDKでフロントエンドをデプロイ
13. 14 言語 TypeScriptで統一 バックエンド、フロントエンド、インフラ全てでTypeScriptを採 用してる バックエンドとフロントエンド インターフェース(API) OpenAPIで定義し、OpenAPIを元に型生成をし、それぞれ サービスで共通 型定義が使えるようにしている ただ、フロントエンドとバックエンドで共通利用できるモジュー ル ほとんどない 型定義 共通利用と言語 習得コスト 削減が主な理由
14. 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: { … }, },
15. 16 モノレポ モノレポ 理由 • 少人数で明確にバックエンド、フロントエンドと役割を明確に分 けずに開発を進めていく で、リポジトリがまとまってる方が1つ PR 中に両方 変更をまとめやすくやりやすい　 • プロジェクト進行に必要な全て 情報をGithubに集約し、開発 効率 向上を測っている。 具体的にソースコード=> リポジトリ、タスク（ボード）=> Github Projetcts、ドキュメント=> Github Wiki と Github に集約している
16. 17 フロントエンド技術選定
17. 18 フロントエンド技術選定 マッハテンプレート フロントエンド技術選定 • Tailwind (CSSフレームワーク) • SWR • MUI(UIライブラリ) 使わない • 状態ライブラリを使わない
18. 19 CSS Tailwindを使う
19. 20 Tailwind Tailwind 選定理由 • 小回りが効く • CSS設計 スキルレベル 影響が少ない • 長期保守 際にメンテナンス性が高い • AIと相性が良い
20. 21 Tailwind - 小回りが効く 純粋なCSS クラスでスタイリングするため、小回りがききや すい。 ライブラリを使わない分、0からHTMLを書いてそれらにスタイ ルを当てる手間があるが、自由にスタイルを当てることがで き、想定外 顧客 要望に答えやすい ライブラリに依存していると、要望に答えきれないケースが 発生してしまう また、CSS 進化でスタイリングがそこまで手間 かかる作 業にならなくなってきてる
21. 22 Tailwind - CSS設計 スキルレベル 影響が少ない CSS設計 知識 差に影響されない Tailwindを使うとクラス名に構 や役割を持たせるような設 計手法 必要なくBEM等に代表されるCSS設計 知識がスタ イリング メンテナンス性に影響されにくい PRレビュー 手間が軽減される Pull Request レビュー時にPureなCSS 場合 CSS 書き方 に幅があるため、CSSとHTMLと両方指摘する必要がある が、TailwindだとHTMLを直してもらうだけでよくなり、レビュー 手間が省ける
22. 23 Tailwind - 長期運用 メンテナンス性が高い 使われないCSSが残りにくい HTML DOMを消す際にCSSが残ることがない そ ため、使われないCSSが残ってしまうことがなく、使わら ないCSSがメンテナンスされないまま残ることがない 純粋なCSSフレームワーク ReactやVueなど フレームワークに依存しない技術な で、 仮にフレーワーク トレンドが変わっても、Tailwind 使い続 けることができる可能性が高い
23. 24 Tailwind - AIと相性が良い HTMLとCSSが1つファイルに書かれるため、 Github Copilotがプロジェクト内 ソースコードを元に行う自 動補完と相性が良い
24. 25 SWR
25. 26 SWR SWR 選定理由 • 機能がシンプル • キャッシュ管理がシンプル • デフォルト設定をfetchが過剰な でカスタム
26. 27 SWR - シンプルな機能 TanStackQuery 方が高機能だが、実際に 使わない機能 も多い SWRで使えるシンプルな機能だけでもほとんど 場合 十分な で、軽量でシンプルに使えるSWRを採用
27. 28 SWR - キャッシュ管理がシンプル TanStack Queryだとキャッシュ管理が難しく、最新 情報を表 示したい場合でも、意図せずにキャッシュが残ってしまい、古 い情報が表示されてままということが何度かあった こ 点も考慮してキャッシュ管理がシンプルなSWRを採用
28. 29 SWR - デフォルト設定をfetchが過剰な でカスタム ただ、デフォルト 設定で 、fetchが過剰に走ってしま うため、カスタマイズ <SWRConfig value={{ // エラー時にリトライを行わない shouldRetryOnError: false, // ウィンドウがフォーカスされた時の自動データ取得をOFF revalidateOnFocus: false, // オンライン復帰時の自動データ取得をOFF revalidateOnReconnect: false, // アプリ全体でsuspenseはデフォルト有効 suspense: true, }}
29. 30 MUI 使わない
30. 31 MUI(UIライブラリ) MUI(UIライブラリ)を使わない理由 • デザインをMUIに寄せる必要がある • アップデート時 コストが高い
31. 32 デザインをMUIに寄せる必要がある デザインをMUIをベースに考える必要がある MUI パーツをベースに作成できるとデザインだとFigma コ ンポーネントも使えてデザイン 時間、開発 時間を短縮で きるがMUIから離れたことをしようとすると一気に工数が膨ら んでしまう
32. 33 アップデート コストが高い 破壊的変更があった場合(v5) 以降 コストが高すぎること が多かった バージョンアップに時間がかかりすぎて、開発初期に短縮で きた時間を上回る マッハチーム 運用 基本方針としてライブラリ 短いサイ クルでアップデートし続ける で、UIライブラリ アップデート コストが見合わないと判断
33. 34 状態ライブラリを使わない
34. 35 状態ライブラリ 状態ライブラリを使わない理由 • 必要なケースが減っている • どうしても必要な場合 SWRを使う
35. 36 状態ライブラリ - 必要なケースが減っている SWRやTanStack Queryなど 登場により、グローバルステー トに状態を持たす必要性が減ってる そ ため、Reduxなど 状態管理ライブラリを導入する理由 がほぼほぼなくなてきている Reduxなど 状態管理 複雑化しやすい で、必要性がな い であれ 、最初から割り切って導入しない方針としてい る
36. 37 状態ライブラリ - どうしても必要な場合 SWRを使う と いえ、一つ 案件を通して、全くグローバルステートを使 わないことも難しく、必要に応じてSWR fetch関数にnullを指 定、キャッシュ インバリデートを無効にしたグローバル キャッシュ領域をグローバルステートとして利用する方針に している 使うライブラリを最低限とすることで、シンプルなプロジェクト 構 と開発効率 向上を狙っている
37. 38 フロントエンド技術選定(まとめ) マッハテンプレート フロントエンド技術選定 • Tailwind (CSSフレームワーク) => 柔軟性と長期メンテを考慮して採用 • SWR => 機能性 シンプルさ重視 • MUI(UIライブラリ) 使わない => 柔軟性と長期メンテを考慮して使用しない • 状態ライブラリを使わない => 必要性が薄くなっており明確な理由がないと使わない
38. ©Classmethod, Inc. 39 マッハチーム ご紹介
 マッハチーム 新しい仲間を募集しています！ 少しでも興味がわいた方 こ 後気軽に話しかけてください！！！