要件の変更は失敗ではありません。市場は変化し、関係者はデモ後にさらに学び、法律は変わり、技術的な制約が現れます。問題は変化ではなく、制御されない変化です。
変更制御がない場合:
- 開発は古いバージョンに従ってビルドされます。
- 古い合格基準に従った QA テスト。
- 企業は、その範囲には新しいセクションが含まれると考えました。
- PO はタイムラインへの影響を認識しません。
- 発売が遅れましたが、いつ遅れたのかは誰にもわかりません。
BA は、変更が透過的に行われるように要件のライフサイクルを管理します。
1. ベースラインとは何ですか?
ベースラインは、チームが構築/テストの基礎として使用するために一度に合意された要件のバージョンです。
ベースラインは「償還不可能」という意味ではありません。つまり、変更する場合は、どこから変更するのか、変更する理由、誰が承認し、どのような影響があるのかを知らなければなりません。
たとえば:
SRS Appointment Booking v1.0
Baseline date: 2026-05-06
Approved by: Product Owner, Clinic Ops Lead, Engineering Lead, QA Lead
Scope: Search doctor, select slot, create appointment, cancel appointment
Out of scope: Payment, insurance claim, recurring appointment
2. いつサインオフする必要がありますか?
すべてのユーザー ストーリーに重い署名が必要なわけではありません。ただし、次の場合には明確な承認が必要です。
- 範囲は多くのチーム/システムに影響します。
- ベンダーまたは契約を結んでいます。
- コンプライアンス、監査、または法務を持っている。
- データ移行があります。
- 大きなビジネスプロセスの変更があります。
- 稼働リスクが高くなります。
アジャイルでは、サインオフをより簡単に行うことができます。PO がバックログ項目を承認し、関係者がデモを確認し、チームが準備完了の定義を最終決定します。決定的な証拠を掴むことが重要です。
3. 変更リクエストには何が含まれますか?
テンプレート変更リクエスト:
# Change Request
ID:
Requested by:
Date:
Current baseline:
## 1. Change summary
- What changes?
- Why now?
- Business value:
## 2. Requirement impact
- BRD/SRS:
- User stories:
- Business rules:
- Acceptance criteria:
- Wireframe:
- API/data:
- Reports:
## 3. Delivery impact
- Effort:
- Timeline:
- Dependencies:
- Test impact:
- Release impact:
- Risk:
## 4. Decision
- Approved / Rejected / Deferred:
- Decision owner:
- Decision date:
- Notes:
4. BAの影響分析
影響分析は、単に開発者に「どのくらい時間がかかりますか?」と尋ねることではありません。 BA は 6 つのレイヤーすべてを調べる必要があります。
| クラス | 質問 |
|---|---|
| ビジネスプロセス | プロセスは変わりましたか?誰が影響を受けますか? |
| 要件 | どの BRD/SRS/ユーザー ストーリー/AC が変更されましたか? |
| UX/UI | どの画面、メッセージ、空状態、エラー状態が変化しますか？ |
| API/データ | どのフィールド、検証、イベント、レポートが変更されますか? |
| QA/UAT | どのテスト ケース、回帰、UAT スクリプトの変更ですか? |
| リリース/運用 | どのトレーニング、SOP、サポート、ロールバックが変更されますか? |
変更例:
企業は、患者が 2 時間前ではなく 30 分前にキャンセルできるようにしたいと考えています。
影響:
- ビジネスルール
BR-CANCEL-001変化する。 - キャンセル API の検証が変更されました。
- UIのコピーが変更されました。
- 通知テンプレートが変更されました。
- 返金/ノーショウポリシーを見直す必要があります。
- カットオフ時間に関連するテスト ケースを更新する必要があります。
- FAQ と SOP の変更をサポートします。
5. トレーサビリティは変更の管理に役立ちます
要件にトレーサビリティがある場合、変更の影響がはるかに簡単になります。
| 要件 | ルール | ストーリー | API | テストケース |
|---|---|---|---|---|
| REQ-BOOK-010 | BR-キャンセル-001 | US-BOOK-12 | PATCH /appointments/{id}/cancel | TC-BOOK-044 |
いつ BR-CANCEL-001 変更があれば、BA はどのストーリー、API 要件、テスト ケースを更新する必要があるかを知っています。
トレーサビリティがなければ、各変更リクエストは手動の追跡になってしまいます。
6. アジャイルにおける変更管理
アジャイルとは、何かを変更したい人がスプリント内ですぐに変更できるという意味ではありません。
実行方法に関する提案:
- スプリント前: 準備完了の定義を調整して最終決定します。
- スプリント中: 小さな変更は PO/チームによって決定されます。バックログに大きな変化がもたらされました。
- デモ後: フィードバックはバックログ項目/変更リクエストとして記録されます。
- リリース前: スコープ ベースラインと UAT スコープが最終決定されています。
- リリース後のみ、変更は検出または次の反復に進みます。
BA は、チームがこれがバグなのか、説明なのか、変更要求なのか、それとも新しい範囲なのかを明確に伝えるのに役立ちます。
7. チェックリストのガバナンスが軽い
- 要件にバージョンはありますか?
- ベースラインの範囲は範囲内/範囲外ですか?
- Decision にはオーナーがいますか?
- 変更リクエストには理由やビジネス上の価値がありますか?
- 影響分析は開発/QA/UX/データ/運用にとって十分ですか?
- AC/テストケースは変更に応じて更新されますか?
- 関連する利害関係者に通知されましたか?
- リリースノート/トレーニング/SOP を更新する必要がありますか?
- 監査用の意思決定ログはありますか?
8. よくあるエラー
エラー 1: すべての変更をバグと呼ぶ
バグとは、指定された要件を満たしていないシステムのことです。ビジネスの考えが変わった場合、それは変更要求または新しい範囲です。
エラー 2: ベースラインがありません
ベースラインがなければ、「変化」が何と比較して何なのかは誰にもわかりません。
エラー 3: 開発作業のみを要求します
コードの小さな変更は、UAT、トレーニング、法務、サポートの点で大きな影響を与える可能性があります。
完全な変更リクエストの例
変更リクエスト:
| フィールド | 値 |
|---|---|
| CR ID | CR-014 |
| リクエスト | 再スケジュール/キャンセルの締め切り時間を 4 時間から 2 時間に変更しました。 |
| からのリクエストセールスマネージャー | |
| 理由 | 顧客は、1 日の中で相談スケジュールが変更されると、柔軟性が欠如すると苦情を言います。 |
| 現在のベースライン | SRS 予約 v1.0 |
| ターゲットリリース | v1.1 |
影響分析:
| エリア | 影響 |
|---|---|
| ビジネスルール | BR-004、BR-005は閾値を4hから2hに変更しました。 |
| UXコピー | エラーメッセージが「4時間前」から「2時間前」に変更されました。 |
| API の検証 | PATCH /reschedule そして PATCH /cancel カットオフルールを変更します。 |
| QA | TC-RS-004、TC-CAN-003 を更新し、正確に 2 時間の境界テストを追加します。 |
| UAT | ビジネス ユーザーは UAT-004 と UAT-005 を再実行します。 |
| 運用/SOP | カスタマー サービスは、顧客の通話時間が 2 時間未満の場合のみ手動通話に対応します。 |
| リスク | コンサルタントには空いたスロットを埋める時間がほとんどなく、アイドル時間が増加する可能性があります。 |
決定:
| 決定 | パイロットで承認されました |
|---|---|
| 範囲 | ホーチミン市のコンサルティンググループに2週間適用されます。 |
| 成功指標 | ノーショーは 3% を超えて増加しません。ホットラインの苦情は少なくとも 15% 減少しました。 |
| オーナー | PO は指標を追跡し、BA は要件を更新し、QA は回帰を更新します。 |
| ロールバック | ノーショウが 3% を超えて増加した場合は、設定を使用して 4 時間のカットオフに戻ります。 |
練習問題を練習する
あなたがかつて書いた要件を考えてみましょう。作成:
- ベースラインの概要。
- 仮定の変更リクエスト。
- 影響分析 6 層。
- トレーサビリティ マトリックスは最低 5 行。
- 決定ログ。
参照元
- IIBA BABOK ガイド: https://www.iiba.org/standards-and-resources/babok/
- IEEE/ISO/IEC 29148-2018: https://standards.ieee.org/ieee/29148/6937/
- スクラムガイド: https://scrumguides.org/scrum-guide.html
- 実務者向けの PMI ビジネス分析: https://www.pmi.org/shop/p-/book/business-analysis-for-practitioners-a-practice-guide/00101570601
結論
優れたBAは、チームをロックダウンするためにコントロールを変更しません。 BA は変更管理を行うため、すべての変更にはコンテキスト、影響、決定、追跡可能性が含まれます。そのおかげで、チームは柔軟性を保ちながらも混乱はありません。