technical-requirements-interview

技術要件インタビュー

このスキルでは、ビジネス要件から技術要件を導き出すための、体系的なインタビューを進めます。

前提条件

• {base_directory}/requirements/business-requirements.yaml が完成していること
• 問題領域を明確に理解していること

インタビュープロセス

ルール

1. 一度に質問は1つ - 1回の発話で複数の質問をしてはいけません
2. まずビジネスコンテキストを確認 - 技術的な質問をする前に、ビジネス要件を読み込んで理解します
3. 選択肢を提示 - 各質問には、推奨する選択肢を2～5個と自由記述欄を含めます
4. 進捗を記録 - 質問と回答の組み合わせはすべて、直ちに {base_directory}/artifacts/technical-interview.jsonl に追記します
5. 再開機能 - JSONL が存在する場合は、最後の質問から続けます
6. 構造化された出力 - 完了時に {base_directory}/requirements/ に technical-requirements.yaml を生成します

インタビューのカテゴリ

インタビューでは、次の領域を順番に扱います。

1. アーキテクチャとパターン

   • 全体的なアーキテクチャスタイル
   • アプリケーション構造
   • コンポーネント構成

2. 技術スタック

   • プログラミング言語
   • フレームワークとライブラリ
   • パッケージ管理

3. データモデルとストレージ

   • データ永続化の方針
   • データベースの選定
   • スキーマ設計のアプローチ

4. API 設計

   • API スタイル（REST、GraphQL、RPC）
   • API フレームワーク
   • バージョン管理の方針

5. セキュリティと認証

   • 認証方法
   • 認可の方針
   • シークレット管理

6. テスト戦略

   • テストのアプローチ（TDD、BDD など）
   • テストの種類（単体、統合、e2e）
   • テストフレームワーク

7. 開発とツール

   • 開発ワークフロー
   • コード品質ツール
   • CI/CD の方針

8. デプロイと配布

   • デプロイ先
   • パッケージング戦略
   • リリースプロセス

質問形式

各質問は次の形式に従います。

## [Category Name]

**Question:** [Clear, specific question]

**Options:**
1. [Option 1] (Recommended) - [Brief description and rationale]
2. [Option 2] - [Brief description]
3. [Option 3] - [Brief description]
4. Type your own answer

質問例

アーキテクチャ

## Architecture & Patterns

**Question:** What architecture pattern best fits this project?

**Options:**
1. Monolithic application (Recommended) - Single deployable unit, simpler to develop and deploy initially
2. Microservices - Multiple independent services, better scaling but higher complexity
3. Serverless functions - Event-driven, scales automatically, but vendor lock-in
4. Plugin-based - Core engine with extensible plugins for flexibility
5. Type your own answer

技術スタック

## Technology Stack

**Question:** Which programming language should be used?

**Options:**
1. TypeScript (Recommended) - Type-safe JavaScript, excellent tooling, large ecosystem
2. Python - Readable, extensive libraries, good for data processing and scripting
3. Go - Fast compilation, excellent concurrency, simple deployment
4. Rust - Memory safety without garbage collection, high performance
5. Type your own answer

データストレージ

## Data Model & Storage

**Question:** What data persistence strategy is appropriate?

**Options:**
1. File-based storage (Recommended) - Simple, portable, no database dependency
2. SQLite - Embedded relational database, good for local tools
3. PostgreSQL - Full-featured relational database, better for complex queries
4. NoSQL (MongoDB, etc.) - Flexible schema, good for document-based data
5. In-memory only - Fast but no persistence, suitable for ephemeral data
6. Type your own answer

JSONL 形式

すべての質問と回答を {base_directory}/artifacts/technical-interview.jsonl に記録します。

フィールドの定義と例を含む JSONL スキーマの全文は、references/interview-jsonl-spec.md を参照してください。

出力形式

インタビューの完了時に、{base_directory}/requirements/technical-requirements.yaml を生成します。

ディレクトリが存在しない場合は作成します。

mkdir -p {base_directory}/requirements
mkdir -p {base_directory}/artifacts

出力ドキュメントには、トップレベルのセクションとして、project、version、generated、business_requirements_ref、architecture、technology_stack、project_structure、data_model、api、security、testing、development、ci_cd、deployment、monitoring、performance、scalability、constraints、trade_offs、open_questions が含まれます。

すべてのフィールド、型、検証ルールを含むドキュメント仕様の全文は、references/output-spec.md を参照してください。

全体の例は、references/example.yaml を参照してください。

使用方法

新しい技術要件インタビューを開始するには、次のようにします。

/technical-requirements-interview [base-directory]

ディレクトリが指定されていない場合は、現在のディレクトリで requirements/business-requirements.yaml を探して自動検出します。

見つからない場合は、ユーザーに「要件ドキュメントはどこにありますか？」と尋ねます。

続行する前に、ユーザーからパスが提供されるまで待ちます。これを base_directory として保存します。

このスキルでは、次の処理が自動的に行われます。

1. {base_directory}/requirements/business-requirements.yaml からビジネス要件をコンテキストとして読み込みます
2. 既存の {base_directory}/artifacts/technical-interview.jsonl を確認します
3. 見つかった場合は、最後の質問から再開します
4. 技術的な質問を適切に行います
5. 完了時に {base_directory}/requirements/ に technical-requirements.yaml を生成します
6. インタビューの記録を {base_directory}/artifacts/technical-interview.jsonl に保存します

意思決定の記録

各技術的な意思決定には、以下を含めてください。

1. 決定事項 - 何を決定したか
2. 根拠 - なぜこのアプローチを選んだか
3. 検討した代替案 - ほかに何を評価したか
4. トレードオフ - 何を得て、何を失ったか
5. 変更のしやすさ - 後から変更するのがどれほど難しいか

ベストプラクティス

1. ビジネスニーズに合わせる - あらゆる技術的な選択は、ビジネス要件を満たすものである必要があります
2. 制約を考慮する - スケジュール、予算、スキルに関する制約を尊重します
3. シンプルに始める - 可能であれば、複雑なものよりシンプルなソリューションを選びます
4. 変更に備える - 可能な限り、元に戻せる決定をします
5. 根拠を記録する - 将来の自分が、今の自分に感謝するでしょう

レビューとギャップ分析

technical-requirements.yaml の生成後、ギャップ分析を自動的に実行します。

整合性の確認

ビジネスとの整合性：

• アーキテクチャがすべての機能要件をサポートしている
• 技術の選択がビジネス上の制約に沿っている
• 技術的なスコープに対してスケジュールが現実的である
• ツール／サービスの選択に予算上の制約が反映されている

完全性の確認：

アーキテクチャ：

• アーキテクチャパターンが明確に定義されている
• コンポーネントと責任が記録されている
• データフローが明確である
• 統合ポイントが特定されている

技術スタック：

• 言語とランタイムが指定されている
• フレームワークとライブラリが列挙されている
• 重要なバージョンが指定されている
• 代替案が検討され、記録されている

データモデル：

• ストレージ戦略が定義されている
• スキーマの方針が記録されている
• データベースを使用する場合、移行戦略が定義されている
• データ検証の方針が指定されている

API：

• API スタイルが選択されている（REST／GraphQL／RPC）
• フレームワークが選択されている
• バージョン管理戦略が定義されている
• ドキュメント作成の方針が指定されている

セキュリティ：

• 認証方式が定義されている
• 認可モデルが指定されている
• シークレット管理の方針が定義されている
• 入出力の検証戦略が定義されている

テスト：

• テスト戦略が定義されている（TDD／BDD など）
• テストの種類が指定されている（単体／統合／E2E）
• フレームワークが選択されている
• カバレッジ目標が設定されている

デプロイ：

• デプロイ先が特定されている
• パッケージ形式が選択されている
• CI/CD の方針が定義されている
• リリースプロセスが記録されている

一貫性の確認

• 技術的な決定間に矛盾がない
• 技術の選択同士に互換性がある
• 選択したスタックでパフォーマンス目標を達成できる
• セキュリティ対策がデータの機密性に適合している

トレードオフ分析

記録されたトレードオフを確認します。

• 各トレードオフに明確な根拠がある
• 代替案が十分に検討されている
• 結果が理解され、許容できる
• 変更のしやすさが評価されている

ギャップの特定

確認すべき一般的なギャップ：

• エラー処理戦略の不足
• エッジケースの未記録
• スケーラビリティに関する懸念への未対応
• モニタリング／オブザーバビリティ計画の不足
• データ移行経路が不明確
• セキュリティ脅威モデルの不足
• パフォーマンス予算の未記録
• 災害復旧計画の不足
• 依存関係のバージョン管理戦略が不明確
• コード品質ツールの不足

未解決の質問の確認

未解決の質問について、以下を確認します。

• 明確に記載されている
• 選択肢が特定されている
• 影響が理解されている
• 決定の期限が定義されている

レビュー結果

以下を含むギャップ分析レポートを生成します。

gap_analysis:
  business_alignment_score: [1-10]
  completeness_score: [1-10]
  consistency_score: [1-10]

  gaps_found:
    - category: [category]
      issue: [description]
      severity: [high/medium/low]
      recommendation: [how to address]
      business_impact: [what business requirement this affects]

  strong_areas:
    - [what's well-defined]

  trade_offs_review:
    - decision: [decision]
      assessment: [well-reasoned/needs-review/concerning]
      notes: [additional context]

  open_questions_assessment:
    - question: [question]
      blocking: [yes/no]
      recommendation: [resolve now/later/accept uncertainty]

  suggestions:
    - [improvement suggestions]

  ready_for_implementation: [yes/no/with-modifications]

重大なギャップ（深刻度が「高」または実装を妨げる未解決の質問）が見つかった場合は、次のように尋ねます。

「技術要件に、実装に影響する可能性のあるギャップがいくつか見つかりました。次のどれを選びますか？

1. 今すぐ対応する（追加の質問をします）
2. 実装計画に進む（開発中に対応します）
3. ギャップを確認して決定する」

次のステップ

技術要件に関するヒアリングとギャップ分析を完了した後：

1. ギャップ分析レポートを確認する
2. 重大なギャップや実装を妨げる質問に対応する
3. 技術的な選択が現実的であることを検証する
4. /implementation-planner を使用して実装計画を生成する

例

出力全体のサンプルについては、references/example.yaml をご覧ください。