余白を設計しフロントエンド開発を 加速させる

この資料は TECH BATON in 東京 〜うちのフロントエンド進化のツボ ！コード長持ちのための技術〜 の登壇資料になります
https://findy.connpass.com/event/380541/

Transcript

1. Copyright © LIXIL Corporation. All rights reserved. karacoro / からころ 余白を設計しフロントエンド開発を 加速させる
2. 2 自己紹介 アプリケーションエキスパートとして、 社内の基幹システム刷新のフロントエンドリーダーを務めており、 Developer Summit Summer 2025 や TSKaigi Hokuriku 2025 で 登壇するなど、幅広く活動している。 所属: 株式会社LIXIL アプリケーションエキスパート karacoro / からころ
3. フロントエンド設計の 理想を想像できますか？
4. 保守メンテが しやすいこと？ テスタブルなこと？ ドメインを 反映できていること？ AIコーディングが しやすいこと？
5. 5 どのようなフロントエンド設計を目指すべき？ • 凝集度が高い = 結合度が低い（疎結合である） ◦ 7段階の指標 <= 最近よく見る 結合の種類 概要 結合度 偶然的凝集（Coincidental） 関係のない機能が同じモジュールにま とまっている 🟥 最も高い 論理的凝集（Logical） 複数の処理が1つの関数で分岐 （if/switch文など）している 🟥 高い 時間的凝集（Temporal） 実行順序が同じ処理をまとめている （初期化・終了処理など） 🟧 やや高い 手続き的凝集（Procedural） 機能的に意味はないが同じ時間で実行 順序に意味がある 🟧 普通 通信的凝集（Communicational） 機能的に関連はないが、同じ時間で同 じ値に対して処理をする 🟨 やや低い 逐次的凝集（Sequential） 機能的に関連はないが関連する値を受 け渡して処理をする 🟩 低い 機能的凝集（Functional） 単一の機能にまとめられている 🟩 最も低い
6. 6 どのようなフロントエンド設計を目指すべき？ • パッケージ（コンポーネント）の指針となる凝集度の3つの原則 - [1] ◦ REP（Release Reuse Principle） 再利用の単位はリリースの単位と等価である ◦ CCP（Common Closure Principle） 同じ理由、同じタイミングで変更されるクラスを一つのコンポーネントにまとめる ◦ CRP（Common Reuse Principle） 不要なものに依存させるな（一緒に使われるクラスだけをまとめよ） Robert C. Martin（Uncle Bob） [1] https://www.fil.univ-lille.fr/~routier/enseignement/licence/coo/cours/Principles_and_Patterns.pdf
7. 7 どのようなフロントエンド設計を目指すべき？ • 凝集度のテンション・トライアングル ◦ 3つの要素が互いに影響し合う => 全てを満たすことは不可能 重視する原則 犠牲になる原則 結果として生じるアーキテクチャの特徴 REP & CCP CRP 「再利用性は高いが、結合が強い」 コンポーネントが肥大化しがち。不要な依存を 含んでしまい、クライアントに不要なリリース の影響を与えやすい。 CCP & CRP REP 「保守性は高いが、再利用が難しい」 特定のプロジェクト向けに最適化されすぎてお り、汎用的な再利用のためのバージョン管理や インターフェース設計が疎かになる。 REP & CRP CCP 「再利用性は高いが、変更が大変」 コンポーネントが細分化されすぎる。一つの仕 様変更のために多数のパッケージを同時に修正 ・リリースする必要が生じる。
8. 8 どのようなフロントエンド設計を目指すべき？ • 凝集度のテンション・トライアングル ◦ 3つの要素が互いに影響し合う 重視する原則 犠牲になる原則 結果として生じるアーキテクチャの特徴 REP & CCP CRP 「再利用性は高いが、結合が強い」 コンポーネントが肥大化しがち。不要な依存を 含んでしまい、クライアントに不要なリリース の影響を与えやすい。 CCP & CRP REP 「保守性は高いが、再利用が難しい」 特定のプロジェクト向けに最適化されすぎてお り、汎用的な再利用のためのバージョン管理や インターフェース設計が疎かになる。 REP & CRP CCP 「再利用性は高いが、変更が大変」 コンポーネントが細分化されすぎる。一つの仕 様変更のために多数のパッケージを同時に修正 ・リリースする必要が生じる。 プロジェクトの状態に応じて 利益を最大化する
9. 9 どのようなフロントエンド設計を目指すべき？ • 組織のスケーリングを阻害しないこと ◦ コンウェイの法則 システムを設計する組織は、その組織のコミュニケーション構造を 模倣した設計を生み出す ▪ プロダクトの状況に応じることのできる柔軟な設計に ▪ オーバーエンジニアリング・もしくはその逆にならないように etc. • AI開発に最適化できること ◦ 情報の局所性が担保されていること ▪ コンテキスト最適化による、ハルシネーションの低減や編集スコープの制限 etc.
10. 10 • 各機能の境界が明確でそれぞれ自立できる設計 ◦ 適切なモジュール分割 ◦ ディレクトリによる構造表現 ◦ 疎結合なコンポーネント設計 etc. • スケーリングを支える基盤設計 ◦ 自動化されたガードレール（Lint, CI/CD, テスト）が整備されている etc. • オーバーエンジニアリングを避ける ◦ DRY原則よりも結合を回避する ▪ 似ているからという理由で共通化しない・異なるドメイン間であれば あえてコードを重複させる etc. どのようなフロントエンド設計を目指すべき？
11. 11 • 境界防御による自由の保証 ◦ システム全体（グローバル）の秩序は、モジュール間の依存関係ルールによって 厳格に維持する ◦ その代わり防御された境界内部（ディレクトリ配下）の実装においては、 チームやAIが独自の判断でコードを記述できる「余白」を意図的に許容する • 情報の物理的凝集 ◦ 技術的な役割（Controller/Service等）による分割ではなく、機能単位で関連ファイル （UI, Logic, API, Type）を1つのディレクトリに物理的に集約する ◦ これにより人間と生成AI（LLM）の双方が、単一のディレクトリを参照するだけで必要 なコンテキスト（文脈）を理解しやすく、安全に編集可能な状態を担保する 「余白を設計する」の定義 ①
12. 12 • 可処分性の高いコードを生産できる ◦ 各機能ディレクトリは他の機能と疎結合であるため、 いつでも「ディレクトリごと削除・書き直し」が可能であるという前提に立つ ◦ この可処分性が、チームに実験的な実装（プロトタイピング）や、 AIによる大胆なリファクタリングを試みる心理的安全性を提供する • 段階的な厳格化 ◦ すべてのコードに一律の品質基準を求めない。 共通基盤のディレクトリには厳格なテストやルールを要求する一方、 features（末端機能）には柔軟な記述や「スノーフレーク（一点物）」な UIコンポーネントの作成を許可する 「余白を設計する」の定義 ②
13. 13 • 組織のスケーリングの壁への恩恵 ◦ コンウェイの法則に基づいて、チームが独立して動ける「自立領域」を コードベース上に物理的に確保できる • AI開発への最適化 ◦ LLMのコンテキストウィンドウ（Context Window）と推論能力を最大限に活かすため の、情報の局所性と自己完結性の確保、AIによる柔軟な開発が可能になる • 認知負荷の低減 ◦ 早期すぎる抽象化を避け、具体性を維持することで新規参画者のオンボーディングコスト を下げられる AI時代に余白のある設計がもたらす大きな恩恵
14. 14 • ガードレールの整備 ◦ ESLint や ls-lint（ディレクトリ用のリンタ）, フォーマッタなどの整備 ◦ テスト基盤の整備 • コロケーションの実践 ◦ 関連するソースコードは近くに配置する • AIにやさしいアーキテクチャを目指す ◦ 適切なコンテキストスコープの管理 ◦ 段階的で柔軟なガードレールの整備 etc. 余白を設計するために
15. 余白を設計することで スケーラビリティの高い フロントエンド設計を目指そう