plan-do-check-act

Plan-Do-Check-Act（PDCA）

反復的な問題解決とプロセス最適化を通じた継続的改善に、PDCA サイクルを適用します。

説明

4 段階の反復サイクルです。Plan（特定と分析）、Do（変更の実施）、Check（結果の測定）、Act（標準化または調整）で構成されます。体系的な実験と改善を可能にします。

使用方法

/plan-do-check-act [improvement_goal]

変数

• GOAL：改善対象または対処する問題（デフォルト：入力を求めます）
• CYCLE_NUMBER：PDCA の反復回数（デフォルト：1）

手順

フェーズ 1：PLAN

1. 問題または改善目標を定義する
2. 現状を分析する（ベースライン指標）
3. 根本原因を特定する（/why または /cause-and-effect を使用）
4. 仮説を立てる：「X を変更すれば、Y が改善する」
5. 実験を設計する：変更内容と成功の測定方法
6. 成功基準を設定する（測定可能な目標）

フェーズ 2：DO

1. 計画した変更を実施する（まず小規模に）
2. 実際に行ったことを記録する
3. 計画からの逸脱があれば記録する
4. 実施期間を通じてデータを収集する
5. 予期しない観察事項を記録する

フェーズ 3：CHECK

1. 成功基準に照らして結果を測定する
2. ベースラインと比較する（変更前と変更後）
3. データを分析する：仮説は裏付けられたか？
4. 効果があったことと、なかったことを特定する
5. 学びと洞察を記録する

フェーズ 4：ACT

1. 成功した場合：変更を標準化する
   • ドキュメントを更新する
   • チームをトレーニングする
   • チェックリストや自動化を作成する
   • デグレードが起きていないか監視する
2. 成功しなかった場合：学びを得て調整する
   • 失敗した理由を把握する
   • 仮説を見直す
   • 計画を調整して新しい PDCA サイクルを開始する
3. 一部成功した場合：
   • 効果があったことを標準化する
   • 残りの課題に取り組む次のサイクルを計画する

例

例 1：ビルド時間の短縮

CYCLE 1
───────
PLAN:
  Problem: Docker build takes 45 minutes
  Current State: Full rebuild every time, no layer caching
  Root Cause: Package manager cache not preserved between builds
  Hypothesis: Caching dependencies will reduce build to <10 minutes
  Change: Add layer caching for package.json + node_modules
  Success Criteria: Build time <10 minutes on unchanged dependencies

DO:
  - Restructured Dockerfile: COPY package*.json before src files
  - Added .dockerignore for node_modules
  - Configured CI cache for Docker layers
  - Tested on 3 builds

CHECK:
  Results:
    - Unchanged dependencies: 8 minutes ✓ (was 45)
    - Changed dependencies: 12 minutes (was 45)
    - Fresh builds: 45 minutes (same, expected)
  Analysis: 82% reduction on cached builds, hypothesis confirmed

ACT:
  Standardize:
    ✓ Merged Dockerfile changes
    ✓ Updated CI pipeline config
    ✓ Documented in README
    ✓ Added build time monitoring
  
  New Problem: 12 minutes still slow when deps change
  → Start CYCLE 2


CYCLE 2
───────
PLAN:
  Problem: Build still 12 min when dependencies change
  Current State: npm install rebuilds all packages
  Root Cause: Some packages compile from source
  Hypothesis: Pre-built binaries will reduce to <5 minutes
  Change: Use npm ci instead of install, configure binary mirrors
  Success Criteria: Build <5 minutes on dependency changes

DO:
  - Changed to npm ci (uses package-lock.json)
  - Added .npmrc with binary mirror configs
  - Tested across 5 dependency updates

CHECK:
  Results:
    - Dependency changes: 4.5 minutes ✓ (was 12)
    - Compilation errors reduced to 0 (was 3)
  Analysis: npm ci faster + more reliable, hypothesis confirmed

ACT:
  Standardize:
    ✓ Use npm ci everywhere (local + CI)
    ✓ Committed .npmrc
    ✓ Updated developer onboarding docs
  
  Total improvement: 45min → 4.5min (90% reduction)
  ✓ PDCA complete, monitor for 2 weeks

例 2：本番環境のバグ削減

CYCLE 1
───────
PLAN:
  Problem: 8 production bugs per month
  Current State: Manual testing only, no automated tests
  Root Cause: Regressions not caught before release
  Hypothesis: Adding integration tests will reduce bugs by 50%
  Change: Implement integration test suite for critical paths
  Success Criteria: <4 bugs per month after 1 month

DO:
  Week 1-2: Wrote integration tests for:
    - User authentication flow
    - Payment processing
    - Data export
  Week 3: Set up CI to run tests
  Week 4: Team training on test writing
  Coverage: 3 critical paths (was 0)

CHECK:
  Results after 1 month:
    - Production bugs: 6 (was 8)
    - Bugs caught in CI: 4
    - Test failures (false positives): 2
  Analysis: 25% reduction, not 50% target
  Insight: Bugs are in areas without tests yet

ACT:
  Partially successful:
    ✓ Keep existing tests (prevented 4 bugs)
    ✓ Fix flaky tests
  
  Adjust for CYCLE 2:
    - Expand test coverage to all user flows
    - Add tests for bug-prone areas
    → Start CYCLE 2


CYCLE 2
───────
PLAN:
  Problem: Still 6 bugs/month, need <4
  Current State: 3 critical paths tested, 12 paths total
  Root Cause: UI interaction bugs not covered by integration tests
  Hypothesis: E2E tests for all user flows will reach <4 bugs
  Change: Add E2E tests for remaining 9 flows
  Success Criteria: <4 bugs per month, 80% coverage

DO:
  Week 1-3: Added E2E tests for all user flows
  Week 4: Set up visual regression testing
  Coverage: 12/12 user flows (was 3/12)

CHECK:
  Results after 1 month:
    - Production bugs: 3 ✓ (was 6)
    - Bugs caught in CI: 8 (was 4)
    - Test maintenance time: 3 hours/week
  Analysis: Target achieved! 62% reduction from baseline

ACT:
  Standardize:
    ✓ Made tests required for all PRs
    ✓ Added test checklist to PR template
    ✓ Scheduled weekly test review
    ✓ Created runbook for test maintenance
  
  Monitor: Track bug rate and test effectiveness monthly
  ✓ PDCA complete

例 3：コードレビューの迅速化

PLAN:
  Problem: PRs take 3 days average to merge
  Current State: Manual review, no automation
  Root Cause: Reviewers wait to see if CI passes before reviewing
  Hypothesis: Auto-review + faster CI will reduce to <1 day
  Change: Add automated checks + split long CI jobs
  Success Criteria: Average time to merge <1 day (8 hours)

DO:
  - Set up automated linter checks (fail fast)
  - Split test suite into parallel jobs
  - Added PR template with self-review checklist
  - CI time: 45min → 15min
  - Tracked PR merge time for 2 weeks

CHECK:
  Results:
    - Average time to merge: 1.5 days (was 3)
    - Time waiting for CI: 15min (was 45min)
    - Time waiting for review: 1.3 days (was 2+ days)
  Analysis: CI faster, but review still bottleneck

ACT:
  Partially successful:
    ✓ Keep fast CI improvements
  
  Insight: Real bottleneck is reviewer availability, not CI
  Adjust for new PDCA:
    - Focus on reviewer availability/notification
    - Consider rotating review assignments
  → Start new PDCA cycle with different hypothesis

注意事項

• 小規模で測定可能な変更から始めます（大規模な見直しは避けます）
• PDCA は反復的なもので、複数回のサイクルが必要になるのが一般的です
• 失敗した実験も学びの機会です
• すべてを記録します。サイクルをまたいだパターンを把握しやすくなります
• 成功基準は測定可能である必要があります（主観的な基準ではいけません）
• フェーズ 4 の「Act」で、次のサイクルに進むか完了するかを決定します
• 3 サイクル経っても行き詰まっている場合は、根本原因の分析を見直します
• PDCA は技術面とプロセス面の改善の両方に有効です
• 包括的なドキュメント作成には /analyse-problem（A3）を使用します