ビジネスパーソン向けプロジェクト

Reverse Interviewテクニック：

• • 「何を」ではなく「なぜ」と尋ねる：本当のニーズの背後にある理由を理解する
• • 「いつ」を尋ねる：使用シナリオと頻度を理解する
• • 「誰」を問う：対象ユーザーと使用者を理解する
• • 「もし...ならどうなる？」と पूछねる：境界条件と例外処理を探る

ユーザーストーリーの作成：

PRD作成：

• • 対象ユーザー：プロダクトマネージャー、ビジネスアナリスト
• • 機能要件：データ表示、フィルタリング、エクスポート
• • 非機能要件：性能（読み込み時間<2秒）、可用性（99.9%）、セキュリティ

API Spec（OpenAPI）：

UI Spec：画面レイアウト、インタラクションフロー、状態変化を詳しく説明する

タスク分割の原則：

• • 粒度制御：各タスクは2〜4時間で完了
• • 依存関係：タスク間の依存関係を明確にする
• • テスト可能性：各タスクには明確な受け入れ基準がある

WBSの例：

品質基準：

• • コード品質：ESLintチェックを通過、重大な警告なし
• • テストカバレッジ：単体テストカバレッジ>80%
• • ドキュメントが完全：API ドキュメント、ユーザーマニュアルが完全

受け入れ基準：

• • 機能受け入れ：すべての機能がSpecどおりに実装され、テストに合格する
• • 性能受入基準：ページ読み込み時間<2秒、API応答時間<500ms
• • セキュリティ検収：セキュリティスキャンを通過し、高リスクの脆弱性はない

1. Cursor Agentを使用してSpecに基づいてプロジェクト構造を生成する

2. Skill を使って一般的な機能をすばやく実装する：

• • 「データクエリSkill」を使用してAPIクエリロジックを実現する
• • 「チャートコンポーネントSkill」を使って可視化コンポーネントを作成する
• • "エラー処理Skill"を使用してエラー処理を統一する

3. Cursor Agent を使用して複雑な業務ロジックを実装する

4. コードレビューと最適化

5. テストケースを作成する

1. テストケースを実行し、バグを修正する

2. ユーザー受け入れテスト（UAT）

3. 本番環境へデプロイ

4. ユーザーマニュアルと操作ガイドを作成する

5. チーム研修とナレッジ共有

1. Windsurf を使用して古いコードベースを分析する：

• • システム全体のアーキテクチャとモジュール分割を理解する
• • コアビジネスロジックとデータフローを特定する
• • データベース構造とデータモデルを分析する
• • 技術的負債と設計上の問題を特定する

2. システム分析レポートを生成する：

• • アーキテクチャ図：システムモジュールと依存関係
• • 機能一覧：すべての機能モジュールのリスト
• • データモデル：データベーステーブルの構造と関係
• • 問題一覧：技術的負債とリスク要因

1. Cursor Agent を使用して新しいアーキテクチャを設計する：

2. データ移行計画を設計する:

• • データモデルのマッピング：PHPモデルからNode.jsモデルへ
• • データ移行スクリプト：履歴データを移行する
• • データ検証：データの完全性を保証する

1. Strangler Fig パターンを採用する：

• • 旧機能を一度に書き換えるのではなく、段階的に置き換える
• • 新旧システムを並行稼働させ、徐々にトラフィックを切り替える
• • リファクタリングのリスクを下げ、業務継続性を確保する

2. Fabric Patterns を使用してコードを最適化する：

• • アプリケーション設計パターン
• • アプリケーション性能最適化パターン
• • アプリケーションセキュリティのベストプラクティスPattern

1. まずテストを書き、それから実装を書く：

• • 各機能ごとにテストケースを作成する
• • 新機能と旧機能の動作が一致することを確認する
• • テスト駆動開発（TDD）を使用する

2. テストの種類：

• • 単体テスト：単一の関数とモジュールをテストする
• • 統合テスト：モジュール間の統合をテストする
• • E2Eテスト：完全な業務フローをテストする