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. ブルーグリーンのトラフィック切り替え（5 分未満）
3. CI/CD による完全なデプロイのロールバック（15 分未満）
4. 必要に応じてデータベースマイグレーションのロールバック（データチームと調整）
5. インシデントのポストモーテムと修正を実施してから再デプロイ

機能の説明: $ARGUMENTS

例

ユーザーリクエスト:

バックエンド、フロントエンド、データにわたるエンドツーエンドの機能デリバリーを調整します。

制限事項

• このスキルは、タスクが上記のスコープに明確に一致する場合にのみ使用してください。
• 出力を、環境固有の検証、テスト、または専門家によるレビューの代替として扱わないでください。
• 必要な入力、権限、安全上の境界、または成功基準が欠けている場合は、作業を停止して確認を求めてください。