gap-analysis-worksheet

ギャップ分析ワークシート

初期要件ドキュメントを分析し、ギャップ、曖昧さ、不足情報を特定します。gap-analysis-worksheet.md を作成します。これは、ビジネスアナリストが /business-requirements-interview に進む前に記入するための構造化されたワークシートです。

目的

ステークホルダーから提示される初期要件には、通常、次の内容が含まれています。

• 曖昧または不明確な記述
• 不足しているペルソナまたはユーザータイプ
• 定義されていないスコープの境界
• 明示されていない前提
• 不足している非機能要件
• 定義されていない成功基準

このスキルでは、そうしたギャップを具体的な質問として提示し、正式な要件インタビューが、検証済みで完全な入力情報に基づいて行われるようにします。

前提条件

• 形式を問わない初期要件ドキュメント：プレーンテキスト、Markdown、YAML、PDF の概要、会議メモ、製品概要など

使用方法

/gap-analysis-worksheet path/to/requirements [base-directory]

ベースディレクトリが指定されていない場合は、現在のディレクトリ内に requirements/ フォルダーがあるか確認し、自動検出します。

見つからない場合は、ユーザーに「ギャップ分析ワークシートをどこに作成しますか？」と尋ねます。

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

手順

ステップ 1：要件を読み込む

入力ドキュメント全体を読みます。記載されている要件、目標、ペルソナ、制約、前提をすべて特定します。

ステップ 2：カテゴリ別にギャップを分析する

以下の各カテゴリについてドキュメントを確認し、ギャップを特定します。ギャップとは、次のいずれかです。

• 不足 — 記載されているべき情報が、まったく記載されていない
• 曖昧 — 複数の解釈が可能な記述
• 不完全 — 要件の仕様が部分的にしか定義されていない
• 矛盾 — 互いに矛盾する記述
• 暗黙 — 示唆されているものの、明示されていない事項

ギャップカテゴリ（以下の11カテゴリをすべて評価します）：

1. 問題と目標 — 中核となる問題は明確に定義されていますか？目標は具体的で測定可能ですか？
2. ペルソナとユーザー — すべてのユーザータイプが特定されていますか？ニーズや課題は説明されていますか？
3. スコープ — 明確にスコープ内とされているもの、スコープ外とされているものは何ですか？境界はどこですか？
4. 機能要件 — 構築に必要な詳細さで、すべての機能が説明されていますか？例外的なケースも扱われていますか？
5. 非機能要件 — パフォーマンス、セキュリティ、スケーラビリティ、アクセシビリティ、信頼性に関する期待事項はありますか？
6. 成功基準 — 成功はどのように測定しますか？「完了」とはどのような状態ですか？
7. 前提 — 明示されていないものの、前提とされている事項は何ですか？どのような依存関係が示唆されていますか？
8. 制約 — 技術、スケジュール、予算、規制、チームに関する制約はありますか？
9. 依存関係と統合 — 外部システム、API、サードパーティサービス、またはチーム間の依存関係はありますか？
10. リスク — どのような問題が発生する可能性がありますか？軽減策が必要なものはありますか？
11. UI/UX への影響 — ユーザー向けインターフェースを伴うプロジェクトですか？すべての画面やページが特定されていますか？操作パターンは説明されていますか？アクセシビリティ要件は記載されていますか？デザインシステムまたはコンポーネントライブラリはありますか？レスポンシブ対応やモバイルに関する考慮事項は扱われていますか？ギャップが見つかった場合は、次の推奨事項を追加します：「UI 作業を検出しました — 実装計画の後にワイヤーフレームの計画を開始します（ステップ 6）。」

ギャップのないカテゴリは省略します。出力に空のセクションを含めないでください。

ステップ 3：gap-analysis-worksheet.md を作成する

{base_directory}/requirements/gap-analysis-worksheet.md に書き込みます。

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

mkdir -p {base_directory}/requirements

出力形式

{base_directory}/requirements/gap-analysis-worksheet.md に書き込みます。

出力は、ヘッダー（ドキュメントパス、生成日、ステータス、ギャップの合計数）に続いて、各ギャップカテゴリのセクションが並ぶ Markdown ドキュメントです。各ギャップには、要件の抜粋、具体的な質問、回答欄が含まれます。

すべてのカテゴリ、ギャップの構造、検証ルールを含むドキュメント仕様の全文は、references/output-spec.md を参照してください。

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

良いギャップ質問の書き方

具体的にする — 該当する要件、または不足している箇所を正確に示します。

良い例：ユーザーがアップロードできるファイルサイズの上限はいくつですか？ 悪い例：何か制限はありますか？

回答可能にする — ビジネスアナリストが具体的な回答を返せる質問にします。

良い例：未認証のユーザーは公開ワークフローを閲覧できますか？それとも、すべてのアクセスにログインが必要ですか？ 悪い例：認証についてはどうしますか？

質問1つにつきギャップ1つ — 複数のギャップを1つの質問にまとめないでください。

良い例：ワークフローのタスクが失敗した場合、どうしますか。ワークフロー全体を停止しますか、それとも残りのタスクを続行しますか？ 悪い例：エラーやタイムアウト、再試行についてはどうしますか？

重大なギャップを優先する — 中核となる機能、ペルソナ、スコープに関する質問を、あると望ましい確認事項より先に挙げます。

要件スニペットのガイドライン

• 可能な場合はドキュメントから直接引用し、15語未満にします
• ギャップがまったく記載されていない事項に関する場合は、"要件で言及されていません"を使用します
• ギャップが特定の行ではなくセクション全体に関する場合は、セクションを参照します："[Goals section]"

出力例

仕様例の入力に基づいた完全なサンプルは、references/example.yaml をご覧ください。

セルフレビュー

ワークシートを生成した後、以下の確認を行い、簡潔な要約をインラインで出力します。

確認項目

• 11カテゴリすべてを評価した（スキップしたカテゴリには記録すべきギャップがなかった）
• すべての質問が具体的で、ビジネスアナリストが回答できる
• 2つの質問が同じギャップを扱っていない
• 重大なギャップ（スコープ、ペルソナ、中核機能）が各カテゴリ内で先に挙げられている
• 要件スニペットがソースドキュメントの内容を正確に反映している
• 実際のギャップがあるカテゴリが漏れていない

インライン要約

## Worksheet Summary

**Input:** [requirements file]
**Output:** gap-analysis-worksheet.md
**Total Gaps Found:** [n]

By Category:
  Problem & Goals:              [n gaps or "✓ no gaps"]
  Personas & Users:             [n gaps or "✓ no gaps"]
  Scope:                        [n gaps or "✓ no gaps"]
  Functional Requirements:      [n gaps or "✓ no gaps"]
  Non-Functional Requirements:  [n gaps or "✓ no gaps"]
  Success Criteria:             [n gaps or "✓ no gaps"]
  Assumptions:                  [n gaps or "✓ no gaps"]
  Constraints:                  [n gaps or "✓ no gaps"]
  Dependencies & Integrations:  [n gaps or "✓ no gaps"]
  Risks:                        [n gaps or "✓ no gaps"]
  UI/UX Implications:           [n gaps or "✓ no gaps"]

Next step → Complete the worksheet, then run:
  /business-requirements-interview