Agile BA Practices

アジャイル BA プラクティススキル

目的

軽量なドキュメント作成と包括的な分析のバランスを取りながら、アジャイルおよびハイブリッド手法で BA プラクティスを適用できるよう、AI アシスタントをガイドします。

アジャイルにおける BA の役割

従来型 BA とアジャイル BA

観点	従来型 BA	アジャイル BA
ドキュメント	事前に包括的に作成	必要な分だけ、必要なときに作成
要件	開発前に確定	創発的に形成され、進化する
成果物	BRD、FRS、ユースケース	ユーザーストーリー、受け入れ基準
アプローチ	ウォーターフォール／フェーズ型	反復型／インクリメンタル型
フィードバック	プロジェクト終了時	継続的、各スプリント
変更	正式な変更管理	変更を受け入れる

スクラムにおける BA の役割

スプリント計画：

• チームとユーザーストーリーを明確にする
• 要件に関する質問に回答する
• 複雑さの見積もりを支援する
• 依存関係を特定する

スプリント中：

• 明確化のために対応できる状態にする
• 完了したストーリーを受け入れる
• 今後のストーリーを詳細化する
• 受け入れ基準を作成する

スプリントレビュー：

• PO とともに機能をデモする
• ステークホルダーからフィードバックを収集する
• 変更要求を記録する

スプリントレトロスペクティブ：

• BA プロセスを振り返る
• コラボレーションを改善する

バックログのリファインメント：

• 今後のストーリーを詳細化する
• 受け入れ基準を追加する
• 大きなストーリーを分割する
• PO と優先順位を付ける

アジャイル BA の主要な成果物

プロダクトバックログ

構成：

Epic > Feature > User Story > Task

例：

Epic: Customer Self-Service Portal
├── Feature: Account Management
│   ├── User Story: View profile
│   ├── User Story: Update profile
│   └── User Story: Change password
├── Feature: Order History
│   ├── User Story: View orders
│   └── User Story: Track shipments
└── Feature: Support
    ├── User Story: Submit ticket
    └── User Story: View FAQs

ユーザーストーリーテンプレート

**Title**: [Short, descriptive title]

As a [user role]
I want [goal]
So that [benefit]

**Acceptance Criteria**:
- Given... When... Then...
- Given... When... Then...

**Notes**: [Technical notes, wireframe links]

**Story Points**: [Estimate]

着手可能の定義（DoR）

ストーリーは、以下を満たすと Ready です：

• ユーザーストーリーが形式に沿っている（As a... I want... So that...）
• 受け入れ基準が明確で、テスト可能である
• スプリント内の他のストーリーから独立している
• スプリント内に完了できる規模である
• 技術的なアプローチをチームと話し合っている
• 依存関係を特定し、解決している
• ワイヤーフレーム／デザインが利用可能である（UI 作業の場合）

完了の定義（DoD）

ストーリーは、以下を満たすと Done です：

• すべての受け入れ基準を満たしている
• コードのピアレビューが完了している
• ユニットテストを作成し、すべて合格している
• 結合テストに合格している
• 重大なバグがない
• ドキュメントを更新している
• ステージング環境にデプロイしている
• PO が受け入れている

アジャイルのドキュメント作成アプローチ

必要な分だけのドキュメント

次の場合にドキュメントを作成します：

• コンプライアンス／監査で必要な場合
• 複数のチームが理解する必要がある場合
• ビジネスルールが複雑な場合
• 統合仕様が必要な場合
• 知識を保持する必要がある場合

簡潔に保つ場合：

• コミュニケーションが良好な小規模チーム
• 対面でのやり取りが頻繁にある
• シンプルでよく理解されたドメイン
• プロジェクト期間が短い

軽量な成果物

従来型	アジャイルでの代替
100 ページの BRD	1 ページのプロジェクト概要＋バックログ
詳細な FRS	ユーザーストーリー＋受け入れ基準
ユースケース文書	受け入れシナリオ
データディクショナリ	ストーリー内のエンティティ定義
テスト計画	自動テスト＋DoD

継続的に更新するドキュメント

• ドキュメントをバージョン管理（Git）に保存する
• 要件の進化に合わせて更新する
• Wiki（Lark、Notion、Confluence）を使用する
• 可能な限り自動化する

バックログのリファインメント

目的

• 大きなストーリーを分割する
• 今後のストーリーに詳細を追加する
• 要件を明確にする
• ストーリーを見積もる
• バックログの優先順位を付ける

頻度

• 週に 1～2 時間
• 1～2 スプリント先を対象にする
• 定期的なリズムで実施する

リファインメントの活動

ストーリーの分割：

• ワークフローのステップごと
• ビジネスルールごと
• データのバリエーションごと
• プラットフォームごと（iOS／Android）
• ユーザーの役割ごと

見積もり：

• プランニングポーカー
• ストーリーポイント（フィボナッチ数列）
• T シャツサイズによる見積もり
• 相対見積もり

PO と行う優先順位付け：

• ビジネス価値
• リスクの低減
• 依存関係
• 技術的負債

ストーリーマッピング

ストーリーマッピングとは？

ユーザーのジャーニーに沿ってユーザーストーリーを整理する視覚的な手法です。

構成

Activities (top row)
    ↓
Tasks (second row)
    ↓
Details/Stories (lower rows, by priority)

例：E コマースのストーリーマップ

Browse Products → Add to Cart → Checkout → Order Tracking
     ↓              ↓             ↓            ↓
View catalog     Add item      Shipping      View status
Search products  Update qty    Payment       Track shipment
Filter/sort      Save for later Review order  Get notifications

MVP ─────────────────────────────────────────────────
View catalog     Add item      Shipping      View status
Search           Update qty    Payment

Release 2 ───────────────────────────────────────────
Filter/sort      Save for later Review order Track shipment

ハイブリッド手法

ハイブリッドを使用する場合

• 大規模なエンタープライズプロジェクト
• 規制要件がある場合
• スコープが固定された契約
• 分散チーム
• 成熟度が混在している場合

ハイブリッドアプローチ

ウォーターフォールの要素：

• 初期の調査・分析フェーズ
• 承認用の正式なBRD
• 事前のアーキテクチャ設計
• 本番稼働の計画

アジャイルの要素：

• 反復的な開発
• ユーザーストーリーとスプリント
• 継続的デリバリー
• スプリントデモ

ハイブリッドの進行例

Discovery (2-4 weeks): Requirements, BRD, Architecture
    ↓
Sprint 0: Setup, detailed design, initial stories
    ↓
Sprints 1-N: Agile development
    ↓
UAT Sprint: User acceptance testing
    ↓
Go-live: Deployment, hypercare

スケールド・アジャイル（SAFeの基本）

階層

• ポートフォリオ：戦略的な取り組み
• プログラム：アジャイルリリーストレイン（ART）
• チーム：スクラムチーム

主な役割

• プロダクトマネージャー（ポートフォリオ）
• プロダクトオーナー（チーム）
• システムアーキテクト
• リリーストレインエンジニア

主なイベント

• PIプランニング（プログラムインクリメント）
• システムデモ
• インスペクト＆アダプト

アジャイルBA向けツール

バックログ管理

• Jira
• Azure DevOps
• Trello
• Lark Base

ドキュメント作成

• Lark Docs
• Notion
• Confluence

コラボレーション

• Miro/FigJam（ストーリーマッピング）
• Figma（ワイヤーフレーム）
• Lark Meetings

ベストプラクティス

コミュニケーション

✅ ドキュメントより対面でのやり取りを重視する ✅ 包括的なドキュメントより動くソフトウェアを重視する ✅ 認識を合わせるため、毎日スタンドアップを行う ✅ 早い段階から頻繁にデモを行う

要件

✅ 変化を受け入れる ✅ 必要なタイミングで詳細化する ✅ 協力して要件を具体化する ✅ テスト可能な受け入れ基準を設ける

ドキュメント作成

✅ 必要十分な内容を記述する ✅ 常に最新の状態に保つ ✅ 誰もがアクセスできるようにする ✅ 可能な限り自動化する

コラボレーション

✅ POと緊密に連携する ✅ チームが相談できる状態を保つ ✅ 指示するのではなく、進行を支援する ✅ 技術の基本を学ぶ

よくあるアンチパターン

❌ 過度な事前設計：開発前に分析しすぎる ❌ 要件の一方的な提示：協力せずにストーリーを作成する ❌ BAの不在：スプリント中に対応できない ❌ 過剰な作り込み：すべてを過剰にドキュメント化する ❌ スコープの変更拒否：変化する要件に適応しない

参考資料

• アジャイルソフトウェア開発宣言
• スクラムガイド
• ユーザーストーリーマッピング（Jeff Patton）
• SAFeフレームワーク
• BABOKアジャイルエクステンション