analyse

スマート分析

分析対象に応じて、最も適切なカイゼン分析手法をインテリジェントに選択して適用します。

説明

コンテキストを分析し、最適な手法を選択します。現場観察（コードの調査）、バリューストリームマッピング（ワークフロー／プロセス）、またはムダ分析（ムダの特定）から選び、選択した手法に沿って案内します。

使用方法

/analyse [target_description]

例：

• /analyse authentication implementation
• /analyse deployment workflow
• /analyse codebase for inefficiencies

変数

• TARGET：分析対象（デフォルトでは入力を促します）
• METHOD：自動選択を上書きします（gemba、vsm、muda）

手法選択のロジック

現場観察 → 次の分析に使用します：

• コードの実装（機能が実際にどう動作するか）
• ドキュメントと実態のギャップ
• 不慣れなコードベース領域の理解
• 実際のアーキテクチャと想定されたアーキテクチャの違い

バリューストリームマッピング → 次の分析に使用します：

• ワークフローとプロセス（CI/CD、デプロイ、開発）
• 複数段階のパイプラインにおけるボトルネック
• チーム／システム間の引き継ぎ
• 各プロセス段階に費やされる時間

ムダ（ムダ分析） → 次の分析に使用します：

• コードの品質と効率
• 技術的負債
• 過剰な設計や重複
• リソースの利用状況

手順

1. 分析対象を理解します
2. 最適な手法を判断します（または指定された手法を使用します）
3. この手法が適している理由を説明します
4. 分析を案内します
5. 実行可能な洞察とともに結果を提示します

---

手法 1：現場観察

実際のコードを「見に行き」、現実と想定の違いを理解します。

使用する場面

• 機能が実際にどう動作するかを理解するとき
• コード考古学（レガシーシステム）
• ドキュメントと実装のギャップを見つけるとき
• 変更前に不慣れな領域を調査するとき

プロセス

1. 範囲を定義する：調査するコード領域
2. 想定を述べる：どのように動作すると考えているか
3. 実態を観察する：実際のコードを読む
4. 調査結果を記録する：
   • エントリーポイント
   • 実際のデータフロー
   • 想定と異なる点
   • 隠れた依存関係
   • ドキュメントに記載されていない動作
5. ギャップを特定する：ドキュメントと実態の違い
6. 推奨事項を提示する：ドキュメントの更新、リファクタリング、または現状の受け入れ

例：認証システムの現場観察

SCOPE: User authentication flow

ASSUMPTIONS (Before):
• JWT tokens stored in localStorage
• Single sign-on via OAuth only
• Session expires after 1 hour
• Password reset via email link

GEMBA OBSERVATIONS (Actual Code):

Entry Point: /api/auth/login (routes/auth.ts:45)
├─> AuthService.authenticate() (services/auth.ts:120)
├─> UserRepository.findByEmail() (db/users.ts:67)
├─> bcrypt.compare() (services/auth.ts:145)
└─> TokenService.generate() (services/token.ts:34)

Actual Flow:
1. Login credentials → POST /api/auth/login
2. Password hashed with bcrypt (10 rounds)
3. JWT generated with 24hr expiry (NOT 1 hour!)
4. Token stored in httpOnly cookie (NOT localStorage)
5. Refresh token in separate cookie (15 days)
6. Session data in Redis (30 days TTL)

SURPRISES:
✗ OAuth not implemented (commented out code found)
✗ Password reset is manual (admin intervention)
✗ Three different session storage mechanisms:
  - Redis for session data
  - Database for "remember me"
  - Cookies for tokens
✗ Legacy endpoint /auth/legacy still active (no auth!)
✗ Admin users bypass rate limiting (security issue)

GAPS:
• Documentation says OAuth, code doesn't have it
• Session expiry inconsistent (docs: 1hr, code: 24hr)
• Legacy endpoint not documented (security risk)
• No mention of "remember me" in docs

RECOMMENDATIONS:
1. HIGH: Secure or remove /auth/legacy endpoint
2. HIGH: Document actual session expiry (24hr)
3. MEDIUM: Clean up or implement OAuth
4. MEDIUM: Consolidate session storage (choose one)
5. LOW: Add rate limiting for admin users

例：CI/CD パイプラインの現場観察

SCOPE: Build and deployment pipeline

ASSUMPTIONS:
• Automated tests run on every commit
• Deploy to staging automatic
• Production deploy requires approval

GEMBA OBSERVATIONS:

Actual Pipeline (.github/workflows/main.yml):
1. On push to main:
   ├─> Lint (2 min)
   ├─> Unit tests (5 min) [SKIPPED if "[skip-tests]" in commit]
   ├─> Build Docker image (15 min)
   └─> Deploy to staging (3 min)

2. Manual trigger for production:
   ├─> Run integration tests (20 min) [ONLY for production!]
   ├─> Security scan (10 min)
   └─> Deploy to production (5 min)

SURPRISES:
✗ Unit tests can be skipped with commit message flag
✗ Integration tests ONLY run for production deploy
✗ Staging deployed without integration tests
✗ No rollback mechanism (manual kubectl commands)
✗ Secrets loaded from .env file (not secrets manager)
✗ Old "hotfix" branch bypasses all checks

GAPS:
• Staging and production have different test coverage
• Documentation doesn't mention test skip flag
• Rollback process not documented or automated
• Security scan results not enforced (warning only)

RECOMMENDATIONS:
1. CRITICAL: Remove test skip flag capability
2. CRITICAL: Migrate secrets to secrets manager
3. HIGH: Run integration tests on staging too
4. HIGH: Delete or secure hotfix branch
5. MEDIUM: Add automated rollback capability
6. MEDIUM: Make security scan blocking

---

手法 2：バリューストリームマッピング

ワークフローの各段階をマッピングし、時間とムダを測定して、ボトルネックを特定します。

使用する場面

• プロセスの最適化（CI/CD、デプロイ、コードレビュー）
• 複数段階のワークフローの理解
• 遅延や引き継ぎの特定
• サイクルタイムの改善

プロセス

1. 開始点と終了点を特定する：プロセスの開始位置と終了位置
2. すべてのステップをマッピングする：待ち時間や引き継ぎ時間も含めます
3. 各ステップを測定する：
   • 処理時間（作業が行われている時間）
   • 待ち時間（アイドル状態、ブロックされている時間）
   • ステップを実行する担当者／対象
4. 指標を計算する：
   • リードタイムの合計
   • 付加価値のある時間とムダな時間
   • 効率（付加価値のある時間／合計時間）の割合
5. ボトルネックを特定する：最も時間のかかるステップ、待ち時間が最も長い箇所
6. 将来の状態を設計する：最適化されたフロー
7. 改善を計画する：将来の状態を実現する方法

例：機能開発のバリューストリームマップ

CURRENT STATE: Feature request → Production

Step 1: Requirements Gathering
├─ Processing: 2 days (meetings, writing spec)
├─ Waiting: 3 days (stakeholder review)
└─ Owner: Product Manager

Step 2: Design
├─ Processing: 1 day (mockups, architecture)
├─ Waiting: 2 days (design review, feedback)
└─ Owner: Designer + Architect

Step 3: Development
├─ Processing: 5 days (coding)
├─ Waiting: 2 days (PR review queue)
└─ Owner: Developer

Step 4: Code Review
├─ Processing: 0.5 days (review)
├─ Waiting: 1 day (back-and-forth changes)
└─ Owner: Senior Developer

Step 5: QA Testing
├─ Processing: 2 days (manual testing)
├─ Waiting: 1 day (bug fixes, retest)
└─ Owner: QA Engineer

Step 6: Staging Deployment
├─ Processing: 0.5 days (deploy, smoke test)
├─ Waiting: 2 days (stakeholder UAT)
└─ Owner: DevOps

Step 7: Production Deployment
├─ Processing: 0.5 days (deploy, monitor)
├─ Waiting: 0 days
└─ Owner: DevOps

───────────────────────────────────────
METRICS:
Total Lead Time: 22.5 days
Value-Add Time: 11.5 days (work)
Waste Time: 11 days (waiting)
Efficiency: 51%

BOTTLENECKS:
1. Requirements review wait (3 days)
2. Development time (5 days)
3. Stakeholder UAT wait (2 days)
4. PR review queue (2 days)

WASTE ANALYSIS:
• Waiting for reviews/approvals: 9 days (82% of waste)
• Rework due to unclear requirements: ~1 day
• Manual testing time: 2 days

FUTURE STATE DESIGN:

Changes:
1. Async requirements approval (stakeholders have 24hr SLA)
2. Split large features into smaller increments
3. Automated testing replaces manual QA
4. PR review SLA: 4 hours max
5. Continuous deployment to staging (no approval)
6. Feature flags for production rollout (no wait)

Projected Future State:
Total Lead Time: 9 days (60% reduction)
Value-Add Time: 8 days
Waste Time: 1 day
Efficiency: 89%

IMPLEMENTATION PLAN:
Week 1: Set review SLAs, add feature flags
Week 2: Automate test suite
Week 3: Enable continuous staging deployment
Week 4: Train team on incremental delivery

例：インシデント対応のバリューストリームマップ

CURRENT STATE: Incident detected → Resolution

Step 1: Detection
├─ Processing: 0 min (automated alert)
├─ Waiting: 15 min (until someone sees alert)
└─ System: Monitoring tool

Step 2: Triage
├─ Processing: 10 min (assess severity)
├─ Waiting: 20 min (find right person)
└─ Owner: On-call engineer

Step 3: Investigation
├─ Processing: 45 min (logs, debugging)
├─ Waiting: 30 min (access to production, gather context)
└─ Owner: Engineer + SRE

Step 4: Fix Development
├─ Processing: 60 min (write fix)
├─ Waiting: 15 min (code review)
└─ Owner: Engineer

Step 5: Deployment
├─ Processing: 10 min (hotfix deploy)
├─ Waiting: 5 min (verification)
└─ Owner: SRE

Step 6: Post-Incident
├─ Processing: 20 min (update status, notify)
├─ Waiting: 0 min
└─ Owner: Engineer

───────────────────────────────────────
METRICS:
Total Lead Time: 230 min (3h 50min)
Value-Add Time: 145 min
Waste Time: 85 min (37%)

BOTTLENECKS:
1. Finding right person (20 min)
2. Gaining production access (30 min)
3. Investigation time (45 min)

IMPROVEMENTS:
1. Slack integration for alerts (reduce detection wait)
2. Auto-assign by service owner (no hunt for person)
3. Pre-approved prod access for on-call (reduce wait)
4. Runbooks for common incidents (faster investigation)
5. Automated rollback for deployment incidents

Projected improvement: 230min → 120min (48% faster)

---

手法 3：ムダ（ムダ分析）

コードと開発プロセスにおける 7 種類のムダを特定します。

使用する場面

• コード品質の監査
• 技術的負債の評価
• プロセス効率の改善
• 過剰な設計の特定

（ソフトウェアに適用した）7つのムダ

1. 作りすぎ：必要以上に作ること

• 誰も使わない機能
• 過度に複雑なソリューション
• 時期尚早な最適化
• 不要な抽象化

2. 待ち：アイドル時間

• ビルド／テスト／デプロイにかかる時間
• コードレビューの遅延
• 依存関係を待つ時間
• 他のチームによる作業の停滞

3. 運搬：物をあちこちに移動すること

• 不要なデータ変換
• 付加価値のない API レイヤー
• システム間でのデータのコピー
• シリアライズ／デシリアライズの繰り返し

4. 加工のしすぎ：必要以上の作業を行うこと

• 過剰なログ出力
• 冗長な検証
• 正規化しすぎたデータベース
• 不要な計算

5. 在庫：仕掛かり作業

• マージされていないブランチ
• 未完成の機能
• トリアージされていないバグ
• デプロイされていないコード

6. 動作：不要な移動

• コンテキストの切り替え
• 目的のない会議
• 手動でのデプロイ
• 繰り返し行う作業

7. 不良：手戻りとバグ

• 本番環境のバグ
• 技術的負債
• 不安定なテスト
• 未完成の機能

プロセス

1. 範囲を定義する：コードベースの領域またはプロセス
2. 各ムダの種類について調査する
3. 影響を定量化する（時間、複雑さ、コスト）
4. 影響度に基づいて優先順位を付ける
5. 排除策を提案する

例：API コードベースのムダ分析

SCOPE: REST API backend (50K LOC)

1. OVERPRODUCTION
   Found:
   • 15 API endpoints with zero usage (last 90 days)
   • Generic "framework" built for "future flexibility" (unused)
   • Premature microservices split (2 services, could be 1)
   • Feature flags for 12 features (10 fully rolled out, flags kept)
   
   Impact: 8K LOC maintained for no reason
   Recommendation: Delete unused endpoints, remove stale flags

2. WAITING
   Found:
   • CI pipeline: 45 min (slow Docker builds)
   • PR review time: avg 2 days
   • Deployment to staging: manual, takes 1 hour
   
   Impact: 2.5 days wasted per feature
   Recommendation: Cache Docker layers, PR review SLA, automate staging

3. TRANSPORTATION
   Found:
   • Data transformed 4 times between DB and API response:
     DB → ORM → Service → DTO → Serializer
   • Request/response logged 3 times (middleware, handler, service)
   • Files uploaded → S3 → CloudFront → Local cache (unnecessary)
   
   Impact: 200ms avg response time overhead
   Recommendation: Reduce transformation layers, consolidate logging

4. OVER-PROCESSING
   Found:
   • Every request validates auth token (even cached)
   • Database queries fetch all columns (SELECT *)
   • JSON responses include full object graphs (nested 5 levels)
   • Logs every database query in production (verbose)
   
   Impact: 40% higher database load, 3x log storage
   Recommendation: Cache auth checks, selective fields, trim responses

5. INVENTORY
   Found:
   • 23 open PRs (8 abandoned, 6+ months old)
   • 5 feature branches unmerged (completed but not deployed)
   • 147 open bugs (42 duplicates, 60 not reproducible)
   • 12 hotfix commits not backported to main
   
   Impact: Context overhead, merge conflicts, lost work
   Recommendation: Close stale PRs, bug triage, deploy pending features

6. MOTION
   Found:
   • Developers switch between 4 tools for one deployment
   • Manual database migrations (error-prone, slow)
   • Environment config spread across 6 files
   • Copy-paste secrets to .env files
   
   Impact: 30min per deployment, frequent mistakes
   Recommendation: Unified deployment tool, automate migrations

7. DEFECTS
   Found:
   • 12 production bugs per month
   • 15% flaky test rate (wasted retry time)
   • Technical debt in auth module (refactor needed)
   • Incomplete error handling (crashes instead of graceful)
   
   Impact: Customer complaints, rework, downtime
   Recommendation: Stabilize tests, refactor auth, add error boundaries

───────────────────────────────────────
SUMMARY

Total Waste Identified:
• Code: 8K LOC doing nothing
• Time: 2.5 days per feature
• Performance: 200ms overhead per request
• Effort: 30min per deployment

Priority Fixes (by impact):
1. HIGH: Automate deployments (reduces Motion + Waiting)
2. HIGH: Fix flaky tests (reduces Defects)
3. MEDIUM: Remove unused code (reduces Overproduction)
4. MEDIUM: Optimize data transformations (reduces Transportation)
5. LOW: Triage bug backlog (reduces Inventory)

Estimated Recovery:
• 20% faster feature delivery
• 50% fewer production issues
• 30% less operational overhead

---

注意事項

• 手法の選択は状況によって異なります。最適なものを選んでください
• 手法を組み合わせることもできます（Gemba Walk → Muda Analysis）
• 対象領域に詳しくない場合は、Gemba Walk から始めてください
• プロセスの最適化には VSM を使用してください
• 効率化と整理には Muda を使用してください
• すべての手法で、実行可能な改善につなげてください
• 組織的な学習のため、調査結果を記録してください
• 調査結果を包括的に記録するには、/analyse-problem（A3）の使用を検討してください