business-analyst

これはレビュー時に保存された抜粋です。完全で最新の内容は外部ソースを確認してください。

---
name: business-analyst
description: 'Use this skill when gathering and documenting business requirements, mapping processes, performing gap analysis, writing business requirements documents (BRDs), or modeling stakeholder impact. Trigger phrases: ''write a business requirements document'', ''map this process'', ''gather requirements for'', ''gap analysis for'', ''AS-IS TO-BE process''. Not for writing user stories (use product-manager skill), conducting user research (use ux-researcher), or financial modeling.'
version: 1.0.0
author: community
tags:
  - business
  - analysis
  - requirements
  - process
license: MIT
keywords:
  - business requirements
  - requirements gathering
  - process mapping
  - gap analysis
  - BRD
  - business
  - analyst
  - business analyst
---

# Business Analyst

## Overview
This skill covers the structured practice of business analysis—translating business problems into clear requirements, mapping current and future-state processes, identifying gaps, managing stakeholder alignment, and producing the documentation (BRDs, use cases, process maps) that enables successful project delivery. It bridges the gap between business needs and technical or operational solutions.

## When to Use
- You need to document what a system or process must do (requirements gathering)
- You're mapping a current business process to find inefficiencies
- You need to perform a gap analysis between current and desired state
- You're building a Business Requirements Document (BRD)
- You need to identify and manage project stakeholders
- Writing use cases or functional specifications

## When NOT to Use
- Writing user stories and sprint backlog items (use product-manager skill)
- Conducting qualitative UX research (use ux-researcher skill)
- Technical architecture or system design
- Financial modeling or ROI calculations (use a finance skill)
- Project scheduling and resource planning (use a PM tool)

## Quick Reference
| Task | Technique | Output |
|------|-----------|--------|
| Elicit requirements | Interviews, workshops, observation | Requirements list |
| Document requirements | BRD template | Business Requirements Document |
| Map current state | Swimlane diagram, flowchart | AS-IS process map |
| Design future state | TO-BE process map | Process redesign |
| Find gaps | Gap analysis matrix | Gap analysis report |
| Manage stakeholders | RACI / Power-Interest grid | Stakeholder register |
| Document user interactions | Use case format | Use Case document |
| Prioritize requirements | MoSCoW method | Prioritized requirements |
| Validate requirements | Walkthrough, prototype review | Sign-off document |

## Instructions

### Step 1: Stakeholder Identification and Management

**Stakeholder register:**
| Stakeholder | Role | Interest Level | Influence Level | Stance | Engagement Strategy |
|-------------|------|---------------|-----------------|--------|---------------------|
| VP Operations | Executive sponsor | High | High | Champion | Weekly status briefing |
| IT Director | Technical owner | High | High | Neutral | Bi-weekly architecture review |
| Customer Service Mgr | Process owner | High | Medium | Skeptic | Involve in requirements workshop |
| End users | Operators | Medium | Low | Unaware | Survey + demo sessions |

**Power-Interest grid:**
- High Power + High Interest → **Manage closely** (key decision makers)
- High Power + Low Interest → **Keep satisfied** (executive sponsors)
- Low Power + High Interest → **Keep informed** (operational users)
- Low Power + Low Interest → **Monitor** (peripheral stakeholders)

**RACI matrix for project roles:**
| Activity | Business Sponsor | BA | IT Lead | Process Owner |
|----------|-----------------|-----|---------|---------------|
| Define requirements | A | R | C | C |
| Approve BRD | A | R | I | I |
| Design solution | I | C | R | C |
| Test & validate | I | C | R | A |
| Sign off to launch | A | C | C | R |
(R=Responsible, A=Accountable, C=Consulted, I=Informed)

###