🐣
開発チームを立ち上げ直す（Frontend）
はじめに
こんにちわ。
フロントエンドの開発チームに対してリーダーやメンバーの入れ替えを行ったのですが、これに起因して開発課題が溜まってきたのでチーム全員で議論して共通認識を作りたいと思います。
今回はその共通認識を作るためのテーマのご紹介です。
前提と課題
前提
- 若い。平均年齢 26歳。
- ピザ🍕が食べられる人数（8人以内）。
- 日本と海外の二拠点での開発。
- メンバーはバラバラに入れ替えが発生（オンボーディングや引き継ぎの時期が異なる）。
- UI刷新PJ（Re-Architecture）を1年間実施しており、PJ自体は過渡期。PJ開始時から継続しているメンバーは1名のみ。
- React / Typescript を採用。
- Agile Scrum というよりカンバン形式。スプリントサイクルは1週間。
課題
- 品質のばらつき。プロダクト知識が必要な部分で大きな差が出ている。
- オンボーディングルールの未整備（フロントエンドとしてのもの、チームルールなど）。
- 言語の壁。
- コミュニケーションの停滞（言いたいことが言えていない、心理的安全性が見えない）。
- 役割分担をしていない
チームで共通の認識にしていく作業項目ベース
各課題を解消させるために、開発手順や言語化させていないルールの共有、ナレッジトランスファーを実施してください。
ロールプレイング形式で、徹底的に話し合ってください。
| 大分類 | 中分類 | 小分類 | 説明 | ツール（例） | アウトプット（例） |
|---|---|---|---|---|---|
| 設計フェーズ | システム設計 | システム全体のアーキテクチャ設計 | Clean Architectureに基づいたレイヤー構造の設計、コンポーネント間の依存関係の設計、状態管理の仕組みの設計 | Miro, Lucidchart | アーキテクチャ図、コンポーネント図, シーケンス図 |
| コンポーネント設計 | 画面構成を考慮したコンポーネントの分割、再利用可能なコンポーネントの設計 | Figma, Sketch, Storybook | コンポーネントデザイン, デザインシステム | ||
| 状態管理設計 | グローバル状態とローカル状態の管理方法の設計、状態管理ライブラリの選定（Redux, Zustandなど） | PlantUML | 状態遷移図 | ||
| 開発フェーズ | コンポーネント実装 | コンポーネントの実装 | 設計に基づいたコンポーネントの実装、カスタムフックの作成 | VS Code, TypeScript, React DevTools | コンポーネントコード |
| 状態管理実装 | 状態管理ライブラリを用いた状態の管理、アクションの定義、リデューサーの実装 | Redux DevTools | Reduxストアの状態 | ||
| データフェッチング実装 | APIとの連携、データのキャッシュ、エラーハンドリング | Axios, SWR, React Query | APIリクエストログ, キャッシュデータ | ||
| テスト実装 | ユニットテスト | 個々のコンポーネントのテスト | Jest, React Testing Library | テストレポート | |
| 統合テスト | 複数のコンポーネント間の連携テスト | Cypress | E2Eテストレポート | ||
| レビュー フェーズ | コードレビュー | コードレビュー | コードの品質、可読性、保守性の評価、設計との整合性の確認、バグの早期発見 | GitHub, GitLab | Pull Request, Code Reviewコメント |
| デプロイ フェーズ | ビルド | プロダクションビルド | プロダクション環境向けのビルド設定 | Webpack, Rollup | ビルドファイル |
| デプロイ | クラウドプラットフォームへのデプロイ | Vercel, Netlify, AWS Amplify | デプロイログ, 環境変数設定 |
これら以外に必要なこと
以下については、マネージャーとリーダーでサンプルを用意して、チームメンバーにカスタマイズして貰いました。
- 役割分担、体制
- スプリントルール
- 各種フォーマット
- 定量値（例えば、レビュー目安とするSTEP数、レビュー時のコメント数、ケースのカバレッジなど）
| 大分類 | 中分類 | 小分類 | 説明 | ツール（例） | アウトプット（例） |
|---|---|---|---|---|---|
| チーム文化 | コミュニケーション | ナレッジ共有 | チーム内での技術、プロセス、課題の定期的な共有 | Slack, Notion, Confluence | 共有資料、議事録 |
| 開発標準 | コーディング | コーディングガイドライン | 統一されたコーディングスタイル、命名規則 | ESLint, Prettier | スタイルガイド |
| コード品質基準 | コードの可読性、保守性の共通基準 | SonarQube, CodeClimate | 品質評価レポート | ||
| 技術スキル | スキルアップ | 技術勉強会 | 最新技術トレンド、新技術の学習 | YouTube, Udemy, 社内勉強会 | LT会、勉強会 |
| プロセス改善 | 振り返り | 定期的な改善会議 | スプリントレトロスペクティブ、継続的改善 | Miro, Trello | 改善アクションアイテム |
| ツール連携 | 開発環境 | 共通ツール設定 | 開発ツール、IDE、拡張機能の統一 | VSCode, Docker | 環境設定ドキュメント |
| 継続的インテグレーション | CI/CDパイプラインの共通理解 | GitHub Actions, Jenkins | CI/CDフロー図 | ||
| ドキュメンテーション | 技術文書 | ADR (アーキテクチャドキュメント） | システム設計、技術的意思決定の記録 | PlantUML, Mermaid | アーキテクチャダイヤグラム、決定ログ |
| 開発ガイドライン | 新規メンバー向けオンボーディング資料 | Markdown, Wiki | オンボーディングキット |
さいごに
このメモブログが皆さまの開発効率化に役立つことを願っています。
Discussion