memo: これは考案中のものです。
現状だとやることが重すぎる可能性があるため、最適化したいと思っています。
以下あたりがレバレッジが高いと思われる
コード影響分析
PR分割提案
仕様不明点の洗い出し
- アーキテクチャ概要
- 実践ガイド：コマンド実行フロー
- Layer 1: 設計ワークフロー
- Layer 2: 実装戦略ワークフロー
- Layer 3: 個人実装ワークフロー
- 層間インターフェース
- 運用プロセス
- ツール・コマンド詳細
┌────────────────────────────────────────────────────────┐
│ Layer 1: 設計ワークフロー │
│ 責任: プロダクトチーム全体 │
│ 成果物: 実装方針書、テスト設計書 │
│ ツール: Claude Code + 設計支援コマンド │
├────────────────────────────────────────────────────────┤
│ Layer 2: 実装戦略ワークフロー │
│ 責任: iOSエンジニアチーム │
│ 成果物: PR分割戦略、実装グループ分け │
│ ツール: Claude Code + 戦略立案コマンド │
├────────────────────────────────────────────────────────┤
│ Layer 3: 個人実装ワークフロー │
│ 責任: 各エンジニア │
│ 成果物: 実装コード、テストコード │
│ ツール: Claude Code + 既存ワークフロー │
└────────────────────────────────────────────────────────┘
.claude/
├── layer1_design/ # 設計層
│ ├── v2.0_Sprint3/ # 現在のスプリント（例）
│ │ ├── sprint_meta.md # スプリント情報
│ │ ├── pbi_1234/
│ │ │ ├── raw/ # 生データ
│ │ │ │ ├── issue.md # GitHub Issue
│ │ │ │ ├── gdrive_spec.md # Google Drive仕様
│ │ │ │ └── figma_data.json # Figmaデザインデータ
│ │ │ ├── specs/ # 生成された仕様
│ │ │ │ ├── implementation_spec.md
│ │ │ │ ├── test_design.md
│ │ │ │ └── review_log.md
│ │ │ └── status.md # ステータス管理
│ │ └── design_summary.md # 全体サマリー
│ ├── templates/ # テンプレート
│ │ ├── implementation_spec_template.md
│ │ ├── test_design_template.md
│ │ └── test_patterns/ # テストパターン集
│ └── knowledge/ # ナレッジベース
│ ├── test_design_guideline.md # テスト設計ガイドライン
│ ├── test_factors.md # 因子カタログ
│ └── common_scenarios.md # 共通シナリオ
│
├── layer2_strategy/ # 戦略層
│ ├── v2.0_Sprint3/ # 現在のスプリント
│ │ ├── pbi_1234/
│ │ │ ├── pr_strategy.md # PR分割戦略
│ │ │ ├── implementation_groups.md # 実装グループ
│ │ │ ├── dependency_graph.md # 依存関係
│ │ │ └── conflict_analysis.md # 競合分析
│ │ ├── resource_allocation.md # リソース配分
│ │ └── sprint_timeline.md # タイムライン
│ ├── patterns/ # 戦略パターン
│ │ ├── pr_split_patterns.md
│ │ └── grouping_patterns.md
│ └── metrics/ # メトリクス
│ └── velocity_history.md
│
├── layer3_workspace/ # 個人作業層（既存）
│ └── [既存のワークフロー構造]
│
└── commands/ # カスタムコマンド
├── layer1/ # 設計層コマンド
├── layer2/ # 戦略層コマンド
└── layer3/ # 実装層コマンド
# 0. スプリント準備
claude
/sprint-kickoff v2.0_Sprint3 # スプリント初期化# 1. コンテキスト読み込み
/load-context .claude/layer1_design/knowledge/test_design_guideline.md
# 2. PBI分析（各PBIに対して実行）
/analyze-pbi 1234 # 実装方針作成 + Figmaデータ取得
# → 出力: implementation_spec.md（{仕様不明}含む）
# → 人間: {仕様不明}を確認・補完
# 3. テスト設計
/test-design-assistant # テスト設計書作成
# → 出力: test_design.md（因子水準表、テストシナリオ）
# → 人間: テスト観点の確認・追加
# 4. レビュー記録
/spec-review # 仕様レビュー結果記録
# → 出力: review_log.md# 5. コード影響分析
/code-impact-analyzer # 変更影響の分析
# → 出力: 影響ファイル一覧、競合リスク評価
# 6. PR戦略立案
/pr-strategy-generator # PR分割とグループ生成
# → 出力: pr_strategy.md, implementation_groups.md
# → 出力: pr1_foundation.md, pr2_ui.md, pr3_integration.md
# 7. 競合チェック（複数PBI実装時）
/conflict-detector # PBI間の競合検出
# → 出力: conflict_matrix.md
# 8. タイムライン作成
/timeline-optimizer # 実装スケジュール最適化
# → 出力: sprint_timeline.md
# → 人間: グループA/B/Cへの担当者割り当て# 9. 実装開始準備（各担当者が実行）
# グループ別のPR仕様（pr1_foundation.md等）を
# .claude/workspace/launch.md にコピー
# 10. 実装作業開始
/launch-task # 既存のタスク開始コマンド
# → launch.mdを読み込んでtask.md生成
# → 実装計画の提示
# 11. 実装作業
# （通常のClaude Code操作）
# → コード生成、テスト実装
# → task.mdを随時更新
# 12. 進捗管理（必要時）
/onboard # compact後のコンテキスト復帰
# → task.mdから状況復帰
# 13. ペアレビュー（PR完成時）
/pair-review # 別セッションでレビュー
# → 出力: pair_feedback.md
# → 元のセッションでフィードバック対応
# 14. PR作成
/create-pr # PR文章生成
# → GitHubにPR作成# 15. 個別振り返り（各PR完了後）
/retrospect # 作業振り返り
# → 出力: retrospective_pr1.md
# 16. スプリント振り返り（全体）
/sprint-retrospect # スプリント全体振り返り
# → 出力: sprint_retrospective.md
# 17. インデックス更新（週次）
/update-index # project_index更新
/compact-index # インデックス最適化月曜AM: /sprint-kickoff
火曜AM: PBI#1234で/analyze-pbi → PBI#1235で/analyze-pbi
火曜PM: PBI#1234で/test-design-assistant
水曜AM: PBI#1235で/test-design-assistant
木曜AM: 全PBIまとめて/code-impact-analyzer
木曜PM: /pr-strategy-generator → /conflict-detector
金曜AM: /timeline-optimizer → 担当割り当て会議
翌週：
- 田中さん: pr1_foundation.mdをlaunch.mdにコピー → /launch-task (API基盤)
- 鈴木さん: pr2_ui.mdをlaunch.mdにコピー → /launch-task (UI実装)
- 山田さん: 次のPBIのLayer 1作業
-
バッチ処理の活用
# 複数PBIを一括分析 /batch-analyze 1234,1235,1236 -
テンプレート活用
# よくあるパターンは自動適用 /analyze-pbi 1234 --template=list-screen -
並行作業
- Layer 3実装中に、次スプリントのLayer 1を開始
- グループAが実装中に、グループBは設計確認
-
既存ワークフローとの統合
# Layer 3は既存の/launch-taskをそのまま活用 # PR仕様書 → launch.md → /launch-task → 実装 # これにより学習コストを最小化
PBIから実装可能な仕様とテスト設計を作成し、品質基準を定義する
graph TD
A[PBI取得] --> B[実装方針作成]
B --> C[テスト設計]
C --> D[レビュー・修正]
D --> E[承認・確定]
E --> F[Layer2へ引き継ぎ]
# PBI分析・実装方針作成コマンド
## 実行内容
1. **入力情報の取得**
- GitHub Issue（PBI）の内容
- Google Drive実装方針ドキュメント
- FigmaデザインデータのMCP取得
- 関連する既存仕様
- テスト設計ガイドラインの参照
2. **Figmaデータの分析**（新規追加）
```markdown
## デザイン情報
### Figmaリンク
[IssueからFigmaリンクを抽出]
### MCP経由でのデザインデータ取得
- 画面構成要素
- カラーパレット
- フォントサイズ
- スペーシング
- インタラクション仕様
### UI実装への反映
- {デザイン確認: アニメーション詳細を確認してください}
- {デザイン確認: エラー状態のデザインを確認してください}-
実装方針書の生成 以下の構造で
implementation_spec.mdを生成：# 実装方針書: [PBI名] ## 1. 概要 ### PBI内容 [GitHubIssueからの要約] ### ビジネス価値 [なぜこの機能が必要か] ## 2. 機能要件 ### ユーザーストーリー - As a [ユーザー種別] - I want [機能] - So that [価値] ### 受け入れ条件 1. [条件1] 2. [条件2] ## 3. 技術仕様 ### 画面変更 - [ ] ProductListViewController - 変更内容: 評価表示追加 - 影響範囲: cellForRowAtメソッド - [ ] {仕様不明: 他に影響する画面を記載してください} ### API連携 - [ ] GET /api/products - 変更: レスポンスに評価フィールド追加 - 影響: ProductモデルのJSONデコード - [ ] {仕様不明: レビュー投稿APIの詳細を記載してください} ### データモデル - [ ] Productモデル ```swift var averageRating: Double? var reviewCount: Int
- {仕様不明: レビューデータの永続化方法を記載してください}
- 評価表示: 5つ星UI（既存のRatingView使用）
- {仕様不明: タップ時の動作を記載してください}
- リスト表示: 60fps維持
- {仕様不明: API応答時間の要件を記載してください}
- {仕様不明: 認証が必要な操作を記載してください}
- 既存のProductAPIClient interfaceは変更不可
- iOS 14.0以上サポート
- ProductListViewControllerは既に1200行
- メモリ管理に注意（画像キャッシュ）
-
不明点の自動リスト化
## 要確認事項一覧 1. 画面: 他に影響する画面 2. API: レビュー投稿APIの詳細 3. データ: レビューデータの永続化方法 4. UI: タップ時の動作 5. 性能: API応答時間の要件 6. セキュリティ: 認証が必要な操作
#### 1.2 テスト設計
##### test-design-assistant.md（コマンド）
```markdown
# テスト設計支援コマンド
## 前提条件
- `.claude/layer1_design/knowledge/test_design_guideline.md`を事前に読み込む
- 組織固有のテスト観点を考慮する
## 実行内容
1. **テスト設計ガイドラインの適用**
```markdown
## ガイドライン準拠チェック
### 必須テスト観点（ガイドラインより）
- [ ] 境界値テスト
- [ ] 異常系テスト
- [ ] パフォーマンステスト
- [ ] セキュリティテスト
- [ ] アクセシビリティテスト
### PBI固有のテスト観点
- [ ] 評価表示の正確性
- [ ] レビュー数のフォーマット
-
実装方針書からのテスト観点抽出
## テスト観点分析 ### 機能テスト観点 - 評価表示の正確性 - API通信の正常性 - エラーハンドリング ### 非機能テスト観点 - パフォーマンス（スクロール） - メモリ使用量 - オフライン動作
-
因子水準表の生成
## 因子水準表 ### 基本因子 | 因子 | 説明 | 水準1 | 水準2 | 水準3 | 水準4 | |------|------|-------|-------|-------|-------| | 評価値 | 商品の評価 | なし | 1.0 | 3.5 | 5.0 | | レビュー数 | レビュー件数 | 0 | 1 | 100 | 10000 | | ネットワーク | 通信状態 | オンライン | オフライン | 低速 | タイムアウト | | データ状態 | キャッシュ | なし | 期限内 | 期限切れ | 破損 | | {因子候補: 画面サイズ} | デバイス | - | - | - | - | ### UI特有因子 | 因子 | 説明 | 水準1 | 水準2 | 水準3 | |------|------|-------|-------|-------| | スクロール位置 | リスト位置 | 最上部 | 中間 | 最下部 | | セル再利用 | 状態 | 新規 | 再利用 | - | | 画面遷移元 | 遷移パターン | 起動 | Tab切替 | Push遷移 |
-
テストシナリオ生成支援
## 推奨テストシナリオ（直交表L16から抽出） ### 優先度：高 1. 正常系基本フロー - 評価: 3.5, レビュー: 100, ネット: オンライン, キャッシュ: なし - 確認: 評価表示、レビュー数表示 2. エッジケース - 評価: なし, レビュー: 0, ネット: オンライン, キャッシュ: なし - 確認: 「未評価」表示 3. オフライン - 評価: 3.5, レビュー: 100, ネット: オフライン, キャッシュ: あり - 確認: キャッシュデータ表示 ### 優先度：中 4-8. [他の組み合わせ] ### 実装推奨テストコード構造 ```swift class ProductListTests: XCTestCase { // 因子水準の組み合わせをパラメータ化 func testRatingDisplay( rating: Double?, reviewCount: Int, networkState: NetworkState, cacheState: CacheState ) { // Given setupMockAPI(rating: rating, reviewCount: reviewCount) setupNetwork(networkState) setupCache(cacheState) // When let viewController = ProductListViewController() viewController.loadView() // Then XCTAssertEqual(viewController.ratingView.rating, rating) } }
-
モバイル特有のテスト観点
## モバイル特有テスト項目 ### デバイス関連 - [ ] iPhone SE (小画面) での表示 - [ ] iPad での表示 - [ ] ダークモード - [ ] Dynamic Type (文字サイズ) - [ ] {テスト候補: 画面回転時の挙動} ### パフォーマンス - [ ] 1000件スクロール時のFPS - [ ] メモリ使用量（画像キャッシュ） - [ ] バックグラウンド復帰 - [ ] {テスト候補: 低スペック端末での動作} ### 特殊状況 - [ ] 機内モード - [ ] 低電力モード - [ ] プッシュ通知受信中
### Layer 1 成果物
#### implementation_spec.md（実装方針書）
- 完全な機能仕様
- 技術的な実装詳細
- {仕様不明}項目のリスト
- 制約事項と注意点
- Figmaデザイン要素の技術仕様
#### test_design.md（テスト設計書）
- 因子水準表
- 推奨テストシナリオ
- テストコード構造案
- モバイル特有の確認項目
- ガイドライン準拠チェックリスト
#### figma_analysis.md（デザイン分析書）
- UI要素の技術仕様
- インタラクション定義
- アニメーション仕様
- デザイントークン一覧
---
## Layer 2: 実装戦略ワークフロー
### 目的
実装をコンフリクトフリーなグループに分割し、効率的な並行開発を可能にする
### プロセスフロー
```mermaid
graph TD
A[Layer1成果物受領] --> B[コード影響分析]
B --> C[PR分割戦略立案]
C --> D[実装グループ生成]
D --> E[依存関係整理]
E --> F[タイムライン作成]
F --> G[Layer3へ引き継ぎ]
# コード影響分析コマンド
## 実行内容
1. **実装方針書から変更ファイルを抽出**
```markdown
## 変更予定ファイル一覧
### ViewControllers
- ProductListViewController.swift
- 変更メソッド: cellForRowAt, heightForRowAt
- 追加メソッド: configureRatingView
### Models
- Product.swift
- 追加プロパティ: averageRating, reviewCount
### API
- ProductAPIClient.swift
- 変更メソッド: fetchProducts-
現在のコード状態分析
## コード分析結果 ### ProductListViewController - 現在の行数: 1234行 - 複雑度: High (Cyclomatic: 45) - 最終更新: 2024/01/10 - 他PBIでの変更予定: PBI#1235（フィルター機能） ### 依存関係マップ ProductListVC ├── ProductCell │ └── RatingView (既存) ├── ProductAPIClient │ └── NetworkManager └── ProductViewModel
-
競合リスク評価
## 競合リスク分析 ### 高リスク - ProductListViewController: PBI#1235と同時編集 ### 中リスク - Product.swift: スキーマ変更の影響大 ### 低リスク - 新規ファイル作成部分
#### 2.2 PR分割戦略とグループ生成
##### pr-strategy-generator.md（コマンド）
```markdown
# PR分割戦略・実装グループ生成
## 実行内容
1. **PR分割案の生成**
```markdown
## PR分割戦略
### 分割方針
- 総PR数: 3
- 基準: レイヤー分離、依存関係、コンフリクト回避
### PR構成
#### PR1: データ層基盤
- 優先度: 高（他が依存）
- 規模: 8ファイル、約200行
- 内容:
- Product.swift (モデル拡張)
- ProductAPIClient.swift (API対応)
- MockData更新
- Unit Tests
#### PR2: UI層実装
- 優先度: 中（PR1完了後）
- 規模: 5ファイル、約150行
- 内容:
- ProductCell.swift (評価表示)
- RatingView統合
- UI Tests
#### PR3: 統合・最適化
- 優先度: 低（PR1,2完了後）
- 規模: 3ファイル、約100行
- 内容:
- ProductListViewController統合
- パフォーマンス最適化
- Integration Tests
-
実装グループの生成
## 実装グループ分け ### Group A: API/データ基盤ライン 特徴: バックエンド寄り、他チームとの調整必要
担当PR:
- PR1: データ層基盤
必要スキル:
- API設計
- データモデリング
- ネットワーク処理
ファイル:
- Models/Product.swift
- API/ProductAPIClient.swift
- Tests/ProductAPITests.swift
依存: なし（独立実装可能）
### Group B: UI/UXライン 特徴: フロントエンド寄り、デザイナーとの調整必要担当PR:
- PR2: UI層実装
必要スキル:
- UI実装
- アニメーション
- アクセシビリティ
ファイル:
- Views/ProductCell.swift
- Views/RatingView+Extensions.swift
- Tests/UITests.swift
依存: PR1のモデル定義（インターフェースのみ）
### Group C: 統合/品質ライン 特徴: 全体統合、パフォーマンスチューニング担当PR:
- PR3: 統合・最適化
必要スキル:
- アーキテクチャ理解
- パフォーマンス最適化
- テスト設計
ファイル:
- ViewControllers/ProductListViewController.swift
- Tests/IntegrationTests.swift
依存: PR1, PR2完了必須
-
実装順序とタイムライン
Loadinggantt title 実装タイムライン dateFormat YYYY-MM-DD section Group A PR1 データ層 :a1, 2024-01-15, 2d section Group B PR2 UI層 :b1, after a1, 2d section Group C PR3 統合 :c1, after b1, 1d -
グループ間インターフェース定義
## グループ間インターフェース ### A→B インターフェース ```swift // PR1で定義、PR2で使用 protocol ProductRatingProtocol { var averageRating: Double? { get } var reviewCount: Int { get } }
// PR2で定義、PR3で使用 protocol RatingViewConfigurable { func configureRating(_ rating: Double?, count: Int) }
### Layer 2 成果物
#### pr_strategy.md（PR分割戦略）
- PR構成と依存関係
- 各PRの詳細仕様
- 実装順序
#### implementation_groups.md（実装グループ）
- グループA/B/Cの定義
- 必要スキルセット
- 担当ファイル一覧
- グループ間インターフェース
---
## Layer 3: 個人実装ワークフロー
### 目的
割り当てられたPRを高品質に実装する
### 既存ワークフローの拡張
#### 3.1 グループ別実装開始テンプレート
#### PR仕様からlaunch.mdへの変換例
Layer 2で生成されたPR仕様書（pr1_foundation.md等）から、実装に必要な情報を抽出してlaunch.mdを作成します。
##### 実装開始の手順
```bash
# 1. 担当PRの仕様書を確認
cat .claude/layer2_strategy/v2.0_Sprint3/pbi_1234/pr1_foundation.md
# 2. launch.mdに必要な部分をコピー・編集
cp .claude/layer2_strategy/v2.0_Sprint3/pbi_1234/pr1_foundation.md \
.claude/workspace/launch.md
# 3. launch.mdを実装用に編集（以下の形式に整形）
# 4. /launch-task 実行
claude
/launch-task
# launch.md（pr1_foundation.mdから作成）
## 作業内容
PR1: データモデル・API基盤実装
## 目的・背景
商品レビュー機能のバックエンド基盤を構築する。
Productモデルの拡張とAPIレスポンス対応を行う。
## 実装範囲
- Models/Product.swift（プロパティ追加）
- API/ProductAPIClient.swift（レスポンス処理）
- 関連するユニットテスト
## 技術的制約
- 既存のProductAPIClient interfaceは変更不可
- 後方互換性を維持すること
- 既存テストが全てグリーンであること
## 完了条件
- [ ] Productモデルに評価関連フィールド追加
- [ ] APIレスポンスのデコード処理実装
- [ ] 全ユニットテストがグリーン
- [ ] 既存機能への影響なし# launch.md（pr2_ui.mdから作成）
## 作業内容
PR2: UI層実装 - 商品評価表示機能
## 目的・背景
商品一覧画面に評価表示UIを追加する。
Figmaデザインに基づいた正確な実装を行う。
## 実装範囲
- Views/ProductCell.swift（評価表示追加）
- Views/RatingView+Extensions.swift（既存コンポーネント拡張）
- UIテストの追加
## デザイン仕様
- Figmaリンク: [自動取得済み]
- 評価: 5つ星表示（既存RatingView使用）
- カラー: #FF6B6B（Primary）
- スペーシング: 16ptグリッド準拠
## 技術的制約
- iOS 14.0以上対応
- ダークモード対応必須
- VoiceOver対応必須
## 完了条件
- [ ] Figmaデザインとpixel perfect一致
- [ ] iPhone SE〜iPad対応確認
- [ ] アクセシビリティ確認
- [ ] UIテスト追加# Layer 2への引き継ぎ
## 引き継ぎチェックリスト
- [ ] 実装方針書の{仕様不明}解消
- [ ] テスト設計書の完成
- [ ] プロダクトチーム承認
## 引き継ぎ情報
### PBI: #1234 商品レビュー機能
- 推定規模: 8ポイント
- 優先度: 高
- ブロッカー: なし
### 技術的特記事項
- ProductListVCの肥大化に注意
- 既存RatingViewの再利用推奨
### テスト方針
- 因子: 5個
- 推奨シナリオ: 8個
- 自動化可能: 6個# Layer 3への引き継ぎ
## 実装開始パッケージ
### Group割り当て
| Group | 推奨スキル | 推定工数 | 依存 |
|-------|----------|---------|------|
| A | API設計 | 2日 | なし |
| B | UI実装 | 2日 | A完了後 |
| C | 統合 | 1日 | A,B完了後 |
### 各Groupの詳細
- 詳細仕様書: pr1_foundation.md
- テストシナリオ: test_scenarios_pr1.md
- project_index最新版
### コンフリクト注意事項
- PBI#1235がProductListVCを変更予定
- 実装タイミングの調整必要graph LR
subgraph "Week 1"
A[月: Sprint Planning] --> B[火-水: Layer 1]
B --> C[木-金: Layer 2]
end
subgraph "Week 2"
C --> D[月-木: Layer 3]
D --> E[金: Sprint Review]
end
# 1. スプリント準備
claude
/sprint-kickoff v2.0_Sprint3
# 2. PBI一覧確認と優先順位付け
# 3. Layer 1チーム編成
# 4. テスト設計ガイドラインの確認# 各PBIに対して
claude
# テスト設計ガイドラインを事前に読み込み
/load-context .claude/layer1_design/knowledge/test_design_guideline.md
/analyze-pbi 1234
# → implementation_spec.md生成
# → Figmaデータ自動取得
/test-design-assistant
# → test_design.md生成（ガイドライン準拠）
# 人間によるレビュー・{仕様不明}解消# 各PBIに対して
claude
/code-impact-analyzer
# → 影響分析
/pr-strategy-generator
# → PR戦略とグループ生成
# チームでグループ割り当て決定# 各エンジニアが担当グループの実装
claude
/launch-task group_a
# → 既存ワークフローで実装## 振り返り項目
### Layer 1
- {仕様不明}の頻出パターン
- テスト設計の妥当性
### Layer 2
- PR分割の粒度
- グループ分けの効果
### Layer 3
- 実装速度
- 品質指標
### プロセス改善
- テンプレート更新
- ツール改善案| コマンド | 用途 | 入力 | 出力 |
|---|---|---|---|
| /analyze-pbi | PBI分析・実装方針作成 | Issue番号 | implementation_spec.md |
| /test-design-assistant | テスト設計支援 | 実装方針書 | test_design.md |
| /spec-review | 仕様レビュー補助 | 仕様書 | レビューコメント |
| /batch-analyze | 複数PBI一括分析 | PBI一覧 | 各仕様書 |
| コマンド | 用途 | 入力 | 出力 |
|---|---|---|---|
| /code-impact-analyzer | コード影響分析 | 実装方針書 | 影響分析レポート |
| /pr-strategy-generator | PR戦略・グループ生成 | 影響分析 | pr_strategy.md, groups.md |
| /conflict-detector | 競合検出 | 複数PBI | 競合マトリクス |
| /timeline-optimizer | タイムライン最適化 | グループ情報 | 実装スケジュール |
| コマンド | 用途 | 入力 | 出力 |
|---|---|---|---|
| /launch-task | タスク開始 | launch.md | task.md |
| /onboard | コンテキスト復帰 | task.md | 作業状況 |
| /pair-review | ペアレビュー | git diff | pair_feedback.md |
| /retrospect | 振り返り | 作業内容 | retrospective.md |
| /create-pr | PR作成支援 | 実装内容 | PR文章 |
## test_design_guideline.md（組織固有）
### 必須テスト観点
1. **機能テスト**
- 正常系: ハッピーパス
- 準正常系: 代替フロー
- 異常系: エラーケース
2. **非機能テスト**
- パフォーマンス: 3秒ルール
- セキュリティ: OWASP Top 10
- アクセシビリティ: WCAG 2.1 Level AA
3. **モバイル固有**
- オフライン動作
- プッシュ通知との連携
- バックグラウンド復帰
### テスト設計時の考慮点
- 全機能で最低限の境界値テストを実施
- ネットワークエラーは必須で考慮
- iPhone SEでの表示確認は必須
### 画面種別ごとのテストパターン
#### 一覧画面
- 0件、1件、大量件数（1000件以上）
- pull to refresh
- 無限スクロール
- フィルター・ソート
#### 登録画面
- 必須項目の検証
- 文字数制限（最大・最小）
- 重複チェック
- 通信エラー時の再送制御
#### 詳細画面
- データ取得エラー
- 削除済みデータへのアクセス
- 権限チェック## Figmaデータ取得と活用
### MCPコマンド例
```javascript
// FigmaファイルのデータをMCP経由で取得
const figmaData = await mcp.figma.getFile(figmaFileId);
// コンポーネント情報の抽出
const components = figmaData.document.children
.filter(page => page.name === "Components")
.flatMap(page => page.children);
// スタイル情報の抽出
const colors = figmaData.styles.colors;
const typography = figmaData.styles.typography;// Figmaから取得した値を使用
struct DesignSystem {
static let primaryColor = UIColor(hex: "#FF6B6B") // Figmaから
static let spacing = CGFloat(16) // Figmaのグリッドシステムから
static let cornerRadius = CGFloat(8) // Figmaのコンポーネントから
}## デザイン実装チェックリスト（自動生成）
- [ ] カラー: Primary (#FF6B6B) が正しく適用されているか
- [ ] スペーシング: 16ptグリッドに準拠しているか
- [ ] フォントサイズ: Title(24pt), Body(16pt), Caption(12pt)
- [ ] コーナーRadius: 8ptで統一されているか
- [ ] シャドウ: elevation1 (0 2px 4px rgba(0,0,0,0.1))
## インタラクション仕様（Figmaから抽出）
- タップフィードバック: 0.95スケール、0.1秒
- 画面遷移: push transition、0.3秒
- ローディング: スピナー表示、最小0.5秒
### テスト因子カタログ（モバイルアプリ用）
```markdown
## 基本因子
- データ状態: なし/少量/大量/異常
- ネットワーク: オンライン/オフライン/低速/不安定
- デバイス: iPhone SE/iPhone 15/iPad
- OS: iOS 14/15/16/17
- 言語: 日本語/英語/アラビア語（RTL）
## 画面系因子
- 画面サイズ: 最小/標準/最大
- 向き: 縦/横
- 表示モード: ライト/ダーク
- アクセシビリティ: 通常/VoiceOver/特大文字
## 性能系因子
- メモリ: 余裕/逼迫
- バッテリー: 通常/低電力モード
- 同時実行: なし/バックグラウンド処理あり
## パターン1: レイヤー分離型
- データ層 → UI層 → 統合層
- 利点: 明確な責任分離
- 適用: 新機能追加
## パターン2: 機能分離型
- 基本機能 → 追加機能 → 最適化
- 利点: 段階的リリース可能
- 適用: 大規模機能
## パターン3: リスク分離型
- 低リスク → 中リスク → 高リスク
- 利点: 問題の早期発見
- 適用: 既存機能の大幅変更この3層アーキテクチャにより：
-
品質の作り込み（Layer 1）
- 仕様の明確化
- テスト設計ガイドラインに基づく網羅的なテスト設計
- Figmaデザインの正確な技術仕様化
-
効率的な並行開発（Layer 2）
- コンフリクトフリーな実装
- スキルに応じた割り当て
- デザイン実装の精度向上
-
高速な実装（Layer 3）
- 既存の効率的なワークフロー（/launch-task）をそのまま活用
- Claude Codeの活用
- デザイントークンによる実装の標準化
- 学習コスト最小化
-
組織資産の活用
- テスト設計ガイドラインの適用
- Figmaデザインシステムの直接利用
- スプリント命名規則（vX.X_SprintX）の統一
が実現され、スプリント内での予測可能で高品質な開発が可能になります。