analyze-gap: Gap分析

Gap分析スキルは、既存コードベースと新規実装の差分を分析し、統合ポイントを特定します。

概要

このスキルは以下を実行します：

1. 既存コードベース分析:
   • 既存のアーキテクチャを把握
   • 既存のAPI・データモデルを確認
2. 新規実装との差分分析:
   • 新規実装が既存コードとどのように統合されるか
   • 競合する部分を特定
3. 統合ポイント特定:
   • インターフェースの統合ポイント
   • データモデルの統合ポイント
   • ワークフローの統合ポイント
4. 実装戦略提案:
   • 段階的な統合戦略
   • リスク回避策
   • ロールバック計画
5. Gap分析レポート: 分析結果と実装戦略を記載

使用方法

自動発動

以下のキーワードで自動発動します：

• 「Gap分析したい」
• 「既存コードとの統合を分析」
• 既存システムへの新機能追加時に自動提案

明示的発動

/michi analyze-gap {pj-name}

例:

/michi analyze-gap user-auth

サブエージェント活用（並列探索）

既存コードベースの探索を3つのExploreエージェントで並列実行します：

Phase 1: 並列コードベース探索

エージェント	対象	目的	出力
アーキテクチャ探索	src/, lib/, packages/	レイヤー構造、設計パターン特定	アーキテクチャ構造レポート
API探索	routes/, controllers/, api/	既存APIエンドポイント一覧	API仕様リスト
データモデル探索	models/, entities/, migrations/	DBスキーマ、リレーション	データモデルリスト

Phase 2: 統合分析（メインエージェント）

• Phase 1の結果を統合
• 新規実装との差分を分析
• Gap分析レポート生成

メリット:

• コードベース探索を大幅に高速化（並列実行により）
• 複数の観点から並行して分析
• 各エージェントが独立して動作し、結果を統合

---

実行内容

1. 既存コードベース分析

既存アーキテクチャの把握:

• レイヤー構造
• 使用技術スタック
• 設計パターン

既存API・データモデルの確認:

• REST API エンドポイント一覧
• データベーススキーマ
• 外部サービス連携

2. 新規実装との差分分析

新規実装の影響範囲:

• 新規追加されるAPI
• 新規追加されるテーブル
• 既存APIの変更

競合する部分を特定:

• 既存のユーザー認証と新規実装の認証
• 既存のデータモデルと新規実装のデータモデル
• 既存のワークフローと新規実装のワークフロー

3. 統合ポイント特定

インターフェースの統合ポイント:

• API Gateway との統合
• フロントエンドとの統合
• 外部サービスとの統合

データモデルの統合ポイント:

• 既存テーブルとの外部キー
• 共有されるマスターデータ
• データ移行が必要な部分

ワークフローの統合ポイント:

• 既存の処理フローに新機能を組み込む
• イベント駆動の統合

4. 実装戦略提案

段階的な統合戦略:

1. Phase 1: 独立した機能として実装（既存コードに影響なし）
2. Phase 2: API統合（新規APIを既存フロントエンドから呼び出し）
3. Phase 3: データ統合（既存データと新規データを連携）
4. Phase 4: ワークフロー統合（既存処理フローに組み込み）

リスク回避策:

• Feature Flagを使用して段階的にロールアウト
• Blue-Green Deployment で切り替え
• カナリアリリースで段階的に展開

ロールバック計画:

• データベース変更のロールバックスクリプト
• Feature Flagでの機能無効化
• 以前のバージョンへのデプロイ手順

5. Gap分析レポート

分析結果を以下の形式でレポートします：

# Gap分析レポート: {pj-name}

## 既存コードベース

### アーキテクチャ
- Monolithic Architecture
- Backend: Node.js + Express
- Frontend: React + Redux
- Database: PostgreSQL

### 既存API
- POST /api/session - セッション管理
- GET /api/profile - プロフィール取得

### 既存データモデル
- sessions テーブル
- profiles テーブル

## 新規実装との差分

### 新規追加
- POST /api/users - ユーザー登録
- POST /api/login - ログイン
- users テーブル

### 既存APIの変更
- なし

### 競合箇所
- 既存の sessions テーブルと新規の users テーブルの連携

## 統合ポイント

### インターフェース統合
- API Gateway: 既存エンドポイントと新規エンドポイントを統合
- フロントエンド: ログインページから新規ログインAPIを呼び出し

### データモデル統合
- sessions.user_id → users.id の外部キー追加

### ワークフロー統合
- 既存のセッション管理に新規のユーザー認証を組み込み

## 実装戦略

### Phase 1: 独立実装
- users テーブル作成
- POST /api/users, POST /api/login 実装
- 既存コードに影響なし

### Phase 2: API統合
- フロントエンドから新規ログインAPIを呼び出し
- Feature Flag で新旧ログインを切り替え

### Phase 3: データ統合
- sessions.user_id → users.id の外部キー追加
- 既存セッションデータを移行

### Phase 4: ワークフロー統合
- 既存のセッション管理に新規ユーザー認証を完全統合
- 旧ログインAPIを廃止

## リスク回避策

- Feature Flag: `use_new_auth` で新旧切り替え
- Blue-Green Deployment: 問題発生時は即座に切り戻し
- カナリアリリース: 5% → 25% → 50% → 100%

## ロールバック計画

1. Feature Flag で旧ログインに切り戻し
2. 外部キー制約を削除
3. 新規テーブルをドロップ（必要に応じて）

次のステップ

Gap分析が完了したら、次のステップに進みます：

統合戦略に基づいてタスクを分割

/michi create-tasks {pj-name}

段階的に実装

Phase 1から順番に実装し、各Phaseごとに検証します。

/michi dev {pj-name}

参照

• アーキテクチャガイド: docs/master-docs/structure.md
• ワークフロー全体: ../references/workflow-guide.md
• コマンドリファレンス: ../references/command-reference.md

---

関連スキル:

• create-tasks - タスク分割（統合戦略に基づく）
• dev - TDD実装（段階的に実装）