backend-development-feature-development

要件定義から本番デプロイまでのエンドツーエンドの機能開発をオーケストレーションします:

[拡張思考: このワークフローは、専門化されたエージェントを、発見と計画から実装、テスト、デプロイに至るまでの包括的な機能開発フェーズを通じてオーケストレーションします。各フェーズは前のフェーズの出力に基づいて構築され、一貫性のある機能提供を保証します。このワークフローは、複数の開発手法(従来型、TDD/BDD、DDD)、機能の複雑度レベル、およびフィーチャーフラグ、段階的ロールアウト、オブザーバビリティファースト開発を含む最新のデプロイ戦略をサポートします。エージェントは前のフェーズから詳細なコンテキストを受け取り、開発ライフサイクル全体を通じて一貫性と品質を維持します。]

このスキルを使用する場合

• バックエンド、フロントエンド、データにまたがるエンドツーエンドの機能提供を調整する
• 要件、アーキテクチャ、テスト、ロールアウトを管理する
• デプロイと監視のニーズを伴うマルチサービス変更を計画する
• スコープ、リスク、成功指標についてチームを整合させる

このスキルを使用しない場合

• タスクが小規模で独立したバックエンド変更またはバグ修正である
• ワークフロー全体ではなく、単一の専門タスクのみが必要である
• デプロイやチーム間の調整が関与しない

手順

1. 機能のスコープ、成功指標、制約を確認します。
2. 手法を選択し、フェーズの出力を定義します。
3. 実装、テスト、セキュリティ検証をオーケストレーションします。
4. ロールアウト、監視、ドキュメントの計画を準備します。

安全性

• 承認とロールバック計画なしに本番環境の変更を行わないでください。
• データ移行とフィーチャーフラグは、まずステージング環境で検証してください。

設定オプション

開発手法

• traditional: 実装後にテストを行う順次開発
• tdd: レッド・グリーン・リファクタリングのサイクルを用いたテスト駆動開発
• bdd: シナリオベースのテストを用いたビヘイビア駆動開発
• ddd: 境界づけられたコンテキストと集約を用いたドメイン駆動設計

機能の複雑度

• simple: 単一サービス、最小限の統合(1〜2 日)
• medium: 複数サービス、中程度の統合(3〜5 日)
• complex: ドメイン横断、広範な統合(1〜2 週間)
• epic: 大規模なアーキテクチャ変更、複数チーム(2 週間以上)

デプロイ戦略

• direct: すべてのユーザーへの即時ロールアウト
• canary: トラフィックの 5% から開始する段階的ロールアウト
• feature-flag: フィーチャートグルによる制御された有効化
• blue-green: 即時ロールバックを伴うゼロダウンタイムデプロイ
• a-b-test: 実験と指標のためのトラフィック分割

フェーズ 1: ディスカバリーと要件計画

1. ビジネス分析と要件

   • subagent_type="business-analytics::business-analyst" で Task ツールを使用します
   • プロンプト: 「$ARGUMENTS の機能要件を分析してください。ユーザーストーリー、受け入れ基準、成功指標、ビジネス価値を定義してください。ステークホルダー、依存関係、リスクを特定してください。明確なスコープ境界を持つ機能仕様書を作成してください。」
   • 期待される出力: ユーザーストーリー、成功指標、リスク評価を含む要件ドキュメント
   • コンテキスト: 初期の機能リクエストとビジネスコンテキスト

2. 技術アーキテクチャ設計

   • subagent_type="comprehensive-review::architect-review" で Task ツールを使用します
   • プロンプト: 「機能 $ARGUMENTS の技術アーキテクチャを設計してください。要件: [ステップ 1 のビジネス分析を含める] を使用してください。サービス境界、API コントラクト、データモデル、統合ポイント、技術スタックを定義してください。スケーラビリティ、パフォーマンス、セキュリティ要件を考慮してください。」
   • 期待される出力: アーキテクチャ図、API 仕様、データモデルを含む技術設計ドキュメント
   • コンテキスト: ビジネス要件、既存のシステムアーキテクチャ

3. 実現可能性とリスク評価

   • subagent_type="security-scanning::security-auditor" で Task ツールを使用します
   • プロンプト: 「機能 $ARGUMENTS のセキュリティ上の影響とリスクを評価してください。アーキテクチャをレビューしてください: [ステップ 2 の技術設計を含める]。セキュリティ要件、コンプライアンス要件、データプライバシー上の懸念、潜在的な脆弱性を特定してください。」
   • 期待される出力: リスクマトリクス、コンプライアンスチェックリスト、緩和戦略を含むセキュリティ評価
   • コンテキスト: 技術設計、規制要件

フェーズ 2: 実装と開発

4. バックエンドサービスの実装

   • subagent_type="backend-architect" で Task ツールを使用します
   • プロンプト: 「$ARGUMENTS のバックエンドサービスを実装してください。技術設計に従ってください: [ステップ 2 のアーキテクチャを含める]。RESTful/GraphQL API を構築し、ビジネスロジックを実装し、データレイヤーと統合し、レジリエンスパターン（サーキットブレーカー、リトライ）を追加し、キャッシュ戦略を実装してください。段階的なロールアウトのためのフィーチャーフラグを含めてください。」
   • 期待される出力: API、ビジネスロジック、データベース統合、フィーチャーフラグを備えたバックエンドサービス
   • コンテキスト: 技術設計、API コントラクト、データモデル

5. フロントエンドの実装

   • subagent_type="frontend-mobile-development::frontend-developer" で Task ツールを使用します
   • プロンプト: 「$ARGUMENTS のフロントエンドコンポーネントを構築してください。バックエンド API と統合してください: [ステップ 4 の API エンドポイントを含める]。レスポンシブ UI、状態管理、エラーハンドリング、ローディング状態、分析トラッキングを実装してください。A/B テスト機能のためのフィーチャーフラグ統合を追加してください。」
   • 期待される出力: API 統合、状態管理、分析を備えたフロントエンドコンポーネント
   • コンテキスト: バックエンド API、UI/UX 設計、ユーザーストーリー

6. データパイプラインと統合

   • subagent_type="data-engineering::data-engineer" で Task ツールを使用します
   • プロンプト: 「$ARGUMENTS のデータパイプラインを構築してください。ETL/ELT プロセスを設計し、データ検証を実装し、分析イベントを作成し、データ品質モニタリングを設定してください。機能の利用状況トラッキングのためにプロダクト分析プラットフォームと統合してください。」
   • 期待される出力: データパイプライン、分析イベント、データ品質チェック
   • コンテキスト: データ要件、分析ニーズ、既存のデータインフラストラクチャ

フェーズ 3: テストと品質保証

7. 自動テストスイート

   • subagent_type="unit-testing::test-automator" を指定して Task ツールを使用します
   • プロンプト: 「$ARGUMENTS のための包括的なテストスイートを作成してください。バックエンド（ステップ 4 より）とフロントエンド（ステップ 5 より）の単体テストを作成してください。API エンドポイントの統合テスト、重要なユーザージャーニーの E2E テスト、スケーラビリティを検証するためのパフォーマンステストを追加してください。コードカバレッジを最低 80% 確保してください。」
   • 期待される出力: 単体テスト、統合テスト、E2E テスト、パフォーマンステストを含むテストスイート
   • コンテキスト: 実装コード、受け入れ基準、テスト要件

8. セキュリティ検証

   • subagent_type="security-scanning::security-auditor" を指定して Task ツールを使用します
   • プロンプト: 「$ARGUMENTS のセキュリティテストを実施してください。実装（ステップ 4〜5 のバックエンドとフロントエンドを含む）をレビューしてください。OWASP チェック、ペネトレーションテスト、依存関係スキャン、コンプライアンス検証を実行してください。データ暗号化、認証、認可を検証してください。」
   • 期待される出力: セキュリティテスト結果、脆弱性レポート、是正措置
   • コンテキスト: 実装コード、セキュリティ要件

9. パフォーマンス最適化

   • subagent_type="application-performance::performance-engineer" を指定して Task ツールを使用します
   • プロンプト: 「$ARGUMENTS のパフォーマンスを最適化してください。バックエンドサービス（ステップ 4 より）とフロントエンド（ステップ 5 より）を分析してください。コードをプロファイリングし、クエリを最適化し、キャッシュを実装し、バンドルサイズを削減し、読み込み時間を改善してください。パフォーマンスバジェットとモニタリングを設定してください。」
   • 期待される出力: パフォーマンスの改善、最適化レポート、パフォーマンス指標
   • コンテキスト: 実装コード、パフォーマンス要件

フェーズ 4: デプロイとモニタリング

10. デプロイ戦略とパイプライン

    • subagent_type="deployment-strategies::deployment-engineer" を指定して Task ツールを使用します
    • プロンプト: 「$ARGUMENTS のデプロイを準備してください。自動テスト（ステップ 7 より）を含む CI/CD パイプラインを作成してください。段階的なロールアウトのためのフィーチャーフラグを設定し、ブルーグリーンデプロイを実装し、ロールバック手順を設定してください。デプロイ実行手順書とロールバック計画を作成してください。」
    • 期待される出力: CI/CD パイプライン、デプロイ設定、ロールバック手順
    • コンテキスト: テストスイート、インフラ要件、デプロイ戦略

11. オブザーバビリティとモニタリング

    • subagent_type="observability-monitoring::observability-engineer" を指定して Task ツールを使用します
    • プロンプト: 「$ARGUMENTS のオブザーバビリティを設定してください。分散トレーシング、カスタムメトリクス、エラートラッキング、アラートを実装してください。機能の使用状況、パフォーマンス指標、エラー率、ビジネス KPI のダッシュボードを作成してください。自動アラートを備えた SLO/SLI を設定してください。」
    • 期待される出力: モニタリングダッシュボード、アラート、SLO 定義、オブザーバビリティインフラ
    • コンテキスト: 機能実装、成功指標、運用要件

12. ドキュメントとナレッジトランスファー

    • subagent_type="documentation-generation::docs-architect" を指定して Task ツールを使用します
    • プロンプト: 「$ARGUMENTS の包括的なドキュメントを生成してください。API ドキュメント、ユーザーガイド、デプロイガイド、トラブルシューティング実行手順書を作成してください。アーキテクチャ図、データフロー図、統合ガイドを含めてください。コミットから自動チェンジログを生成してください。」
    • 期待される出力: API ドキュメント、ユーザーガイド、実行手順書、アーキテクチャドキュメント
    • コンテキスト: すべての前フェーズの出力

実行パラメータ

必須パラメータ

• --feature: 機能名と説明
• --methodology: 開発アプローチ (traditional|tdd|bdd|ddd)
• --complexity: 機能の複雑度レベル (simple|medium|complex|epic)

オプションパラメーター

• --deployment-strategy：デプロイ方法（direct|canary|feature-flag|blue-green|a-b-test）
• --test-coverage-min：テストカバレッジの最小しきい値（デフォルト：80%）
• --performance-budget：パフォーマンス要件（例：応答時間 <200ms）
• --rollout-percentage：段階的デプロイにおける初期ロールアウト率（デフォルト：5%）
• --feature-flag-service：フィーチャーフラグのプロバイダー（launchdarkly|split|unleash|custom）
• --analytics-platform：分析ツールとの連携（segment|amplitude|mixpanel|custom）
• --monitoring-stack：オブザーバビリティツール（datadog|newrelic|grafana|custom）

成功基準

• ビジネス要件に記載されたすべての受け入れ基準を満たしている
• テストカバレッジが最小しきい値（デフォルト：80%）を超えている
• セキュリティスキャンで重大な脆弱性が検出されない
• パフォーマンスが定義された予算と SLO を満たしている
• ロールアウトを制御できるよう、フィーチャーフラグが設定されている
• モニタリングとアラートが完全に稼働している
• ドキュメントが完成し、承認されている
• ロールバック機能を備えた本番環境へのデプロイが成功している
• プロダクト分析で機能の使用状況を追跡している
• A/B テストの指標が設定されている（該当する場合）

ロールバック戦略

デプロイ中またはデプロイ後に問題が発生した場合：

1. フィーチャーフラグを直ちに無効化（1 分未満）
2. Blue-Green デプロイのトラフィックを切り替え（5 分未満）
3. CI/CD を使用してデプロイ全体をロールバック（15 分未満）
4. 必要に応じてデータベースのマイグレーションをロールバック（データチームと調整）
5. 再デプロイの前に、インシデントの事後分析と修正を実施

機能の説明：$ARGUMENTS