jpskill.com
📦 その他 コミュニティ

requirements-elicitation

ビジネス分析において、関係者へのヒアリングや機能・非機能要件の収集、要件のギャップ特定を行う際に、要求定義や引き出しのテクニックを活用して、必要な情報を効果的に集めるSkill。

📜 元の英語説明(参考)

Requirements gathering and elicitation techniques for business analysis. Use when conducting stakeholder interviews, gathering functional/non-functional requirements, or identifying gaps in requirements.

🇯🇵 日本人クリエイター向け解説

一言でいうと

ビジネス分析において、関係者へのヒアリングや機能・非機能要件の収集、要件のギャップ特定を行う際に、要求定義や引き出しのテクニックを活用して、必要な情報を効果的に集めるSkill。

※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux 
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o requirements-elicitation.zip https://jpskill.com/download/18840.zip && unzip -o requirements-elicitation.zip && rm requirements-elicitation.zip
🪟 Windows (PowerShell) 
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/18840.zip -OutFile "$d\requirements-elicitation.zip"; Expand-Archive "$d\requirements-elicitation.zip" -DestinationPath $d -Force; ri "$d\requirements-elicitation.zip"

完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。

💾 手動でダウンロードしたい(コマンドが難しい人向け)
  1. 1. 下の青いボタンを押して requirements-elicitation.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → requirements-elicitation フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動
⬇ .zip でダウンロード(推奨) ⬇ .skill 形式(上級者用) 元のソース ↗

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。

詳しい使い方ガイドを見る →
最終更新
2026-05-18
取得日時
2026-05-18
同梱ファイル
1

📖 Skill本文(日本語訳)

※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。

要件定義スキル

概要

このスキルは、ステークホルダーや既存システムからソフトウェア要件を収集、分析、文書化するための構造化された手法を提供します。

要件定義手法

1. 構造化インタビュー

カテゴリ別に整理された事前定義済みの質問セットを使用します。

  • 文脈を理解するために、自由形式の質問から始めます
  • 詳細を収集するために、具体的な質問を続けます
  • 理解を確認するために、検証の質問で締めくくります

2. 適応的質問

以下の情報に基づいて質問を動的に調整します。

  • 提供された以前の回答
  • 発見されたドメインの文脈
  • 要件で特定されたギャップ
  • ステークホルダーの役割と専門知識レベル

3. ドキュメント分析

既存の以下のドキュメントから要件を抽出します。

  • ビジネスプロセスドキュメント
  • ユーザーマニュアル
  • トレーニング資料
  • サポートチケットとフィードバック

4. 観察

以下の情報を観察することで要件を理解します。

  • 現在のシステム利用状況
  • ユーザーワークフロー
  • 課題と回避策

要件カテゴリ

機能要件 (FR)

システムが「何を」行うべきか。

  • 機能と能力
  • ビジネスルールとロジック
  • データ処理要件
  • ユーザーインタラクション

非機能要件 (NFR)

システムが「どのように」振る舞うべきか。

FURPS+ モデル

  • Functionality (機能性): セキュリティ、コンプライアンス
  • Usability (ユーザビリティ): アクセシビリティ、学習しやすさ
  • Reliability (信頼性): 可用性、耐障害性
  • Performance (性能): 応答時間、スループット
  • Supportability (サポート性): 保守性、テスト容易性
  • +Constraints (制約): 設計、実装、インターフェース

制約

ソリューションに対する制限。

  • 予算の制約
  • タイムラインの制約
  • 技術の制約
  • 規制の制約
  • リソースの制約

仮定

真であると仮定される条件。

  • ユーザーの能力
  • インフラストラクチャの可用性
  • サードパーティの依存関係
  • ビジネス条件

優先順位付け方法

MoSCoW メソッド

  • Must Have (必須): 成功に不可欠、交渉不可
  • Should Have (重要): 重要だが不可欠ではない
  • Could Have (あれば尚可): あれば良い、なくても影響は小さい
  • Won't Have (今回は見送り): 現在のリリースでは対象外

価値対労力マトリックス

High Value + Low Effort  = Do First (Quick Wins)
High Value + High Effort = Do Second (Major Projects)
Low Value + Low Effort   = Do Later (Fill-ins)
Low Value + High Effort  = Don't Do (Time Wasters)

ギャップ分析プロセス

  1. 現状 (As-Is State) の文書化: 現在の能力
  2. あるべき姿 (To-Be State) の定義: 望ましい能力
  3. ギャップの特定: 不足している能力
  4. ギャップの優先順位付け: ビジネス価値による
  5. 要件の作成: ギャップを埋めるため

検証手法

要件品質チェック

各要件は以下の条件を満たす必要があります。

  • Complete (完全): 必要な情報がすべて含まれている
  • Consistent (一貫性): 他の要件との矛盾がない
  • Unambiguous (曖昧でない): 単一の明確な解釈が可能
  • Verifiable (検証可能): テスト/測定が可能
  • Traceable (追跡可能): ビジネス目標にリンクされている

SMART 基準

  • Specific (具体的): 明確で正確
  • Measurable (測定可能): 定量的な成功基準がある
  • Achievable (達成可能): 技術的に実現可能
  • Relevant (関連性): ビジネス目標と整合している
  • Time-bound (期限付き): タイムラインの文脈がある

INVEST 基準 (ユーザーストーリー向け)

  • Independent (独立): 個別に開発可能
  • Negotiable (交渉可能): 議論の余地がある
  • Valuable (価値がある): ユーザー/ビジネス価値を提供する
  • Estimable (見積もり可能): サイズを見積もることができる
  • Small (小さい): スプリントに収まる
  • Testable (テスト可能): 明確な受け入れ基準がある

ステークホルダー分析

ステークホルダーカテゴリ

  1. エンドユーザー: システムの直接利用者
  2. ビジネスオーナー: 意思決定者
  3. 技術チーム: 開発者、アーキテクト
  4. 運用: サポート、メンテナンス
  5. 外部: 規制当局、パートナー、顧客

ステークホルダーマッピング

各ステークホルダーについて以下を特定します。

  • 役割と責任
  • 関心度 (高/中/低)
  • 影響度 (高/中/低)
  • 主要な懸念事項と優先順位
  • コミュニケーションの好み

成果物

要件リスト

| ID | Category | Description | Priority | Status |
|----|----------|-------------|----------|--------|
| FR-001 | Functional | User can login with email | Must | Confirmed |
| NFR-001 | Performance | Page load < 3 seconds | Should | Pending |

ユーザーストーリー形式

As a [role]
I want [capability]
So that [business value]

Acceptance Criteria:
- Given [context]
- When [action]
- Then [outcome]

要件トレーサビリティ

Business Objective -> Requirement -> User Story -> Test Case

構造化インタビューの質問については、question-templates.md を参照してください。

📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開

Requirements Elicitation Skill

Overview

This skill provides structured techniques for gathering, analyzing, and documenting software requirements from stakeholders and existing systems.

Elicitation Techniques

1. Structured Interviews

Use predefined question sets organized by category:

  • Start with open-ended questions to understand context
  • Follow with specific questions to gather details
  • End with validation questions to confirm understanding

2. Adaptive Questioning

Dynamically adjust questions based on:

  • Previous answers provided
  • Domain context discovered
  • Gaps identified in requirements
  • Stakeholder role and expertise level

3. Document Analysis

Extract requirements from existing:

  • Business process documents
  • User manuals
  • Training materials
  • Support tickets and feedback

4. Observation

Understand requirements by observing:

  • Current system usage
  • User workflows
  • Pain points and workarounds

Requirement Categories

Functional Requirements (FR)

What the system must DO:

  • Features and capabilities
  • Business rules and logic
  • Data processing requirements
  • User interactions

Non-Functional Requirements (NFR)

How the system must BEHAVE:

FURPS+ Model

  • Functionality: Security, compliance
  • Usability: Accessibility, learnability
  • Reliability: Availability, fault tolerance
  • Performance: Response time, throughput
  • Supportability: Maintainability, testability
  • +Constraints: Design, implementation, interface

Constraints

Limitations on the solution:

  • Budget constraints
  • Timeline constraints
  • Technology constraints
  • Regulatory constraints
  • Resource constraints

Assumptions

Conditions assumed to be true:

  • User capabilities
  • Infrastructure availability
  • Third-party dependencies
  • Business conditions

Prioritization Methods

MoSCoW Method

  • Must Have: Critical for success, non-negotiable
  • Should Have: Important but not critical
  • Could Have: Nice to have, low impact if absent
  • Won't Have: Out of scope for current release

Value vs Effort Matrix

High Value + Low Effort  = Do First (Quick Wins)
High Value + High Effort = Do Second (Major Projects)
Low Value + Low Effort   = Do Later (Fill-ins)
Low Value + High Effort  = Don't Do (Time Wasters)

Gap Analysis Process

  1. Document As-Is State: Current capabilities
  2. Define To-Be State: Desired capabilities
  3. Identify Gaps: Missing capabilities
  4. Prioritize Gaps: By business value
  5. Create Requirements: To close gaps

Validation Techniques

Requirement Quality Checks

Each requirement should be:

  • Complete: All necessary information included
  • Consistent: No conflicts with other requirements
  • Unambiguous: Single clear interpretation
  • Verifiable: Can be tested/measured
  • Traceable: Linked to business objective

SMART Criteria

  • Specific: Clear and precise
  • Measurable: Quantifiable success criteria
  • Achievable: Technically feasible
  • Relevant: Aligned with business goals
  • Time-bound: Has timeline context

INVEST Criteria (for User Stories)

  • Independent: Can be developed separately
  • Negotiable: Open to discussion
  • Valuable: Delivers user/business value
  • Estimable: Can be sized
  • Small: Fits in a sprint
  • Testable: Has clear acceptance criteria

Stakeholder Analysis

Stakeholder Categories

  1. End Users: Direct system users
  2. Business Owners: Decision makers
  3. Technical Team: Developers, architects
  4. Operations: Support, maintenance
  5. External: Regulators, partners, customers

Stakeholder Mapping

For each stakeholder identify:

  • Role and responsibilities
  • Interest level (High/Medium/Low)
  • Influence level (High/Medium/Low)
  • Key concerns and priorities
  • Communication preferences

Output Artifacts

Requirements List

| ID | Category | Description | Priority | Status |
|----|----------|-------------|----------|--------|
| FR-001 | Functional | User can login with email | Must | Confirmed |
| NFR-001 | Performance | Page load < 3 seconds | Should | Pending |

User Story Format

As a [role]
I want [capability]
So that [business value]

Acceptance Criteria:
- Given [context]
- When [action]
- Then [outcome]

Requirement Traceability

Business Objective -> Requirement -> User Story -> Test Case

See question-templates.md for structured interview questions.