ハンドオフは、要件が BA の責任者から離れ、UX、開発、QA の手に渡される瞬間です。ハンドオフがあいまいな場合、スプリントは次のことを支払うことになります。
- Dev は独自の理解に従って構築します。
- QA はビジネス ルールのないテスト ケースを作成します。
- UX フロー設計は美しいが、ポリシーが間違っている。
- 利害関係者は「それは正しいアイデアではない」という理由で UAT で拒否されました。
適切な引き継ぎは読書セッションではありません。適切な引き継ぎとは、構造化された調整です。
1. ハンドオフはいつ行われますか?
アジャイルでは、引き継ぎはリファインメント時またはスプリント計画の前に行われることがよくあります。計画主導のプロジェクトでは、SRS がベースライン化された後にハンドオフが発生します。
次の場合にハンドオフが必要になります。
- ストーリーはいよいよスパートに入ります。
- SRSセクションは完全に成熟しています。
- UXデザインが始まります。
- QA がテスト ケースの作成を開始します。
- 要件に大きな変更があります。
- 重要な統合または NFR があります。
＃＃２ 誰が参加すべきでしょうか？
最小値:
-BA
- プロダクトオーナーまたはビジネスオーナー
- 開発者/技術リーダー
- QA
必要な場合:
- UXデザイナー
- 建築家
- データ エンジニア
- セキュリティ/コンプライアンス
- 運用・サポート
必要がない場合は混雑しないでください。しかし、意思決定者が欠けてはいけません。
3. 引き継ぎチェックリスト
ハンドオフの前に、BA は以下を準備します。
- 問題とビジネス価値。
- 範囲内と範囲外。
- ユーザー ストーリーまたは SRS セクション。
- 受け入れ基準。
- ビジネス ルール。
- UI がある場合はワイヤーフレームまたはフロー。
- API/データへの影響。
- 関連の NFR。
- 特殊なケース。
- 依存関係。
- 未解決の質問。
- サインオフまたは終了の決定。
不足しているアイテムが多すぎる場合は、まだ引き渡さないでください。発見/改良の話に戻りましょう。
4. アジェンダ スリー アミーゴス 45 分
3 人のアミーゴは通常、BA、Dev、QA としてストーリーを一緒にレビューします。必要に応じて PO/UX を追加できます。
0-5 phút: BA nhắc lại business value và scope
5-15 phút: Review flow chính và acceptance criteria
15-25 phút: Dev hỏi về API/data/NFR/dependency
25-35 phút: QA chuyển AC thành test scenarios, hỏi edge cases
35-40 phút: Chốt open questions, owner, deadline
40-45 phút: Quyết định story Ready hay chưa
セッション終了時の出力:
- ストーリーの準備ができています/準備ができていません。
- 未解決の質問のリスト。
- ドラフトシナリオをテストします。
- アップデートはSRS/ストーリーで行う必要があります。
5. ACをテストシナリオに変換する例
ストーリー:
顧客として、計画が変更になったときに別の空いている時間を選択できるように、予約を再スケジュールしたいと考えています。
AC:
Given khách có lịch hẹn ở trạng thái Confirmed
When khách chọn đổi lịch sang slot còn trống trước giờ hẹn ít nhất 4 tiếng
Then hệ thống cập nhật lịch hẹn sang slot mới
And gửi email xác nhận lịch mới
テストシナリオ:
| ID | シナリオ | 予想される |
|---|---|---|
| TC-001 | 4 時間前までに空いているスロットに変更 | 成功しました。メールが送信されました |
| TC-002 | すでに予約されているスロットに変更する | エラー メッセージ: スロットはもう使用できません。 |
| TC-003 | 残り 4 時間未満になったらスケジュールを変更してください | 変更を許可しません。ポリシーを表示します。 |
| TC-004 | 電子メール サービス エラー | カレンダーはまだ更新されています。メールの再試行/ログ |
| TC-005 | ユーザーはカレンダーの所有者ではありません | 403 または不正なメッセージ |
これは、BA が幸せなパスをテストするだけでなく、QA を支援する方法です。
6. 公開質問ログ
すべての疑問がすぐに解決されるわけではありません。しかし、答えのない問題は、所有者が存在する必要があるということです。
テンプレート:
| ID | 質問 | 影響 | オーナー | 期限 | ステータス |
|---|---|---|---|---|---|
| OQ-01 | 当日の日程変更は可能ですか？ | ビジネスルール、UI、AC | カスタマーサービスリード | 2026-05-12 | 開く |
| OQ-02 | 失敗したメールは予約をブロックしますか? | エラー処理 | 技術責任者 | 2026-05-12 | 開く |
ルール: 未解決の質問がブロッカーである場合、ストーリーはスプリントに入ることができません。
7. UX へのハンドオフ
UX のニーズ:
- メインペルソナ。
- ユーザーの目標。
- 主な流れ。
- エラー/空/読み込み状態。
- ビジネス ルールは UI に影響します。
- コンテンツを表示する必要があります。
- アクセシビリティ/ローカリゼーションの要件。
BA は UX の代わりに UI を設計しませんが、BA は UX がビジネス上の制約を理解していることを確認する必要があります。
8. 開発者への引き継ぎ
開発者には次のものが必要です。
- 機能的な動作。
- データモデルまたはフィールドへの影響。
- API インタラクション。
- 許可モデル。
- エラー処理。
- NFR。
- 依存性。
- 機能フラグまたはロールアウト制約。
BAは「予約画面を作れ」と言うだけではありません。 BAは「どのスロットが表示されるか、重複ルール、タイムゾーン、ステータス、監査ログ」を明確に記述する必要があります。
9. QA への引き継ぎ
QA のニーズ:
- 受け入れ基準。
- ビジネスルール。
- テストデータ。
- 役割/権限マトリックス。
- UAT シナリオ。
- 回帰スコープ。
- 既知のリスク。
QA がビジネス ルールを理解していない場合、テストのパスが間違っている可能性があります。
10. 完全なハンドオフ パックの例
機能: 顧客が相談予約を変更します。
| パート | 引き継ぎコンテンツ |
|---|---|
| ビジネス価値 | 顧客がスケジュールを変更する必要がある場合にカスタマー サービスへの電話を減らしますが、それでもコンサルタントの作業スケジュールは保護されます。 |
| 範囲 | 顧客は予約時間の少なくとも 4 時間前までにオンラインで予約を変更できます。 |
| 範囲外 | 4 時間未満のスケジュールの変更、コンサルタントの別のドメインへの変更、グループのスケジュールの変更。 |
| ビジネスルール | BR-001: オーナー マネージャーのみ変更できます。 BR-002: 予約ステータス = 確認済みの場合のみ変更します。 BR-003: 変更は予約時間の 4 時間以上前にのみ行ってください。 |
| UX に関するメモ | 変更が成功すると、新しい確認コードが表示されます。切断により失敗した場合は、ホットラインを表示します。 |
| API/データ | PATCH /appointments/{id}/reschedule、リクエストには以下が含まれます new_slot_id、 reason、 idempotency_key。 |
| NFR | 応答 p95 は 2 秒以内。監査ログ old_slot/new_slot を書き込みます。 |
テストシナリオのマトリックス:
| シナリオ | テストデータ | 期待される結果 |
|---|---|---|
| 4 時間前に空いているスロットに変更 | 予約が確認されました、24 時間以内に開始します | ステータスはまだ確認済みで、古いスロットが再度オープンされ、新しいスロットはロックされています。 |
| 4 時間以内の交換 | 予約は 3 時間 30 分に始まります | スケジュールを変更したり、ホットラインを表示したりしないでください。 |
| 配置したばかりのスロットに変更します | new_slot_id が利用できません | スケジュールを変更せず、別のスロットを提案してください。 |
| ユーザーが他の人の予定を変更する | appointment_id はユーザーの一部ではありません | 403 を返し、セキュリティ イベントを書き込みます。 |
| ダブルクリックにより 2 回送信されました | 同じ冪等性キー | 再スケジュールは1つだけです。 |
未解決の質問:
| ID | 質問 | オーナー | 締め切り |
|---|---|---|---|
| OQ-001 | SMS または電子メールのみを送信するようにスケジュールを変更しますか? | マーケティング | 2026-05-10 |
| OQ-002 | コンサルタントは変更されたスケジュールを拒否できますか? | オペレーションリード | 2026-05-10 |
| OQ-003 | 顧客が複数回変更された場合、ノーショーは発生しますか? | セールスマネージャー | 2026-05-11 |
11. よくあるエラー
エラー 1: Confluence リンクの送信によるハンドオフ
リンクは位置合わせを置き換えるものではありません。重要な要件については、チェックリストを使用してライブまたは非同期でレビューする必要があります。
エラー 2: QA を早期に招待していない
QA の到着が遅れると、エッジケースの発見も遅くなります。改良から QA を招待して、欠陥を減らすことができます。
エラー 3: 決定を記録していません
会議は良好でしたが、決定記録がなければ、数日後に全員の記憶が異なっていました。
参照元
- スクラムガイド 2020: https://scrumguides.org/scrum-guide.html
- IIBA BABOK ガイド: https://www.iiba.org/standards-and-resources/babok/
結論
ハンドオフは一方向のハンドオフではありません。ハンドオフは、BA、PO、開発、QA、および関連する役割間の共同説明セッションです。ハンドオフが良好な場合、スプリントでの質問は少なくなり、QA テストはより綿密に行われ、UAT での予期せぬ事態は少なくなり、関係者は BA をより信頼します。