PMI PMP: Agile、Scrum、ハイブリッドデリバリー — 学習ガイド
こちらの一部です： PMP — 学習ガイド. 検証済みの解答で練習： PMI試験ハブ, または時間制限付き模擬試験に挑戦： ExamRoll.io.
スクラムの役割、セレモニー、作成物
スクラムは、意図的に小さな役割構造で運営されます。なぜなら、責任の拡散が複雑なデリバリーにおける主要な失敗要因の一つだからです。プロダクトオーナーは何を、なぜを所有します。彼らは価値を定義し、バックログの優先順位を付け、インクリメントを受け入れるか拒否するかの権限を持ちます。スクラムマスターはプロセスがどれだけうまく機能するかを所有します。彼らはサーバントリーダーとして、障害を取り除き、アジャイルプラクティスについてコーチングし、チームを混乱から守ります。開発者（コーダーだけでなく、デリバリーチーム全体）はどのようにを所有します。彼らは自己組織化し、各スプリントでバックログアイテムを機能するインクリメントに変換します。
これらの役割は、実際に深く関与する人々によって担われる必要があります。関与しない、あるいは不在のプロダクトオーナーは、アジャイルデリバリーにおいて最も破壊的なパターンの1つです。彼らのリアルタイムな優先順位付けと受け入れがなければ、スプリントレビューは価値を検証するイベントではなく単なる進捗報告会になり、フィードバックループは長引き、チームは間違ったものを構築する方向へと流されてしまいます。不在のPOに直面した場合、正しい行動は、スクラムマスターが恒久的に意思決定を代行するのではなく、スポンサーにエスカレーションして役割を再確立することです。
中核となるセレモニーは、クローズドなフィードバックループを形成します。
- スプリントプランニング
- 目的: スプリントゴールと予測を交渉する
- 頻度: スプリントの開始時
- 主なアウトプット: スプリントバックログ
- デイリースタンドアップ
- 目的: 同期を取り、障害を表面化させる
- 頻度: 毎日、15分にタイムボックス化
- 主なアウトプット: その日の調整済み計画
- スプリントレビュー
- 目的: ステークホルダーと共にインクリメントを検査する
- 頻度: スプリントの終了時
- 主なアウトプット: フィードバック、更新されたプロダクトバックログ
- スプリントレトロスペクティブ
- 目的: プロセスを検査する
- 頻度: スプリントの終了時
- 主なアウトプット: 具体的な改善アクション
作成物であるプロダクトバックログ、スプリントバックログ、インクリメントには、それぞれプロダクトゴール、スプリントゴール、完成の定義というコミットメントが付随します。これらのコミットメントが、スクラムが「反復型ウォーターフォール」に成り下がるのを防ぎます。
バックログ管理とユーザーストーリー
プロダクトバックログは、プロジェクト開始時に凍結された仕様書ではなく、生きた、順序付けられたリストです。プロダクトオーナーはチームと協力してこれを維持し、アイテムをリファインメントすることで、バックログのトップが小さく、よく理解され、すぐに着手できる状態（ready to pull）になるようにします。一般的なリズムとして、各スプリントでチームのキャパシティの5〜10%をバックログリファインメントに費やします。
ユーザーストーリーは、おなじみのパターンに従います：[ペルソナ]として、[利益]のために、[能力]が欲しい。利益に関する記述は、能力に関する記述と同じくらい重要です。これにより、チームは代替ソリューションを提案でき、POは優先順位が変わったときにそのストーリーをまだ実行する価値があるかどうかを判断できます。
受け入れ基準は、POがそのストーリーを受け入れる際の、観測可能でテスト可能な条件です。これらは完成の定義とは異なります。受け入れ基準はストーリー固有（例：ログイン画面は5回失敗するとロックされるか？）であるのに対し、DoDはすべてのストーリーに共通（例：コードレビュー、テスト、文書化、ステージングへのデプロイは行われたか？）です。
ステークホルダーがプロジェクトの途中で新しい要件（たとえ過去の作業に似ていても）を持ち込んできた場合、POは安易に期日を口にすべきではありません。正しい対応は、そのリクエストをバックログアイテムの候補として捉え、チームと協力してサイズを見積もり（相対見積もりのアンカーとして参照ストーリーを使用するなど）、既存のアイテムとの相対的な価値に応じてバックログに配置することです。過去の類似性はサイジングを加速させますが、優先順位付けの対話を省略するものではありません。
DoR、DoD、イテレーション計画
準備完了の定義 (DoR) は、スプリントへの入り口のゲートです。ストーリーが準備完了と見なされるのは、スプリント内で完了できるほど小さく、明確な受け入れ基準があり、既知の依存関係が特定され、チームによって理解されている場合です。DoRを徹底することで、チームが未解決の疑問によってスプリントの途中で停滞するような、中途半端な作業に着手するのを防ぎます。
完成の定義 (DoD) は、出口のゲートです。これは、「コーディングが終わった」を「これは潜在的に出荷可能なインクリメントである」に変換するための、共有された、交渉の余地のないチェックリストです。堅牢なDoDには通常、自動テストの合格、コードレビュー、セキュリティスキャンのクリア、ドキュメントの更新、そして決定的に重要なこととして、パフォーマンスや可観測性といった非機能要件への対応が含まれます。DoDの定義に運用チームやQAを関与させることが、スプリントレビューでは「動作する」ように見えても、本番環境の実際の負荷の下では崩壊するというパターンを防ぎます。スプリント後に運用チームがパフォーマンスに関する懸念を提起し、そのデータがすでにログに存在する場合、成熟した対応は、それを「スコープ外」として退けるのではなく、その懸念をリファインメントに持ち込み、DoDにパフォーマンスのしきい値を追加し、そのギャップを埋めるためのバックログアイテムを作成することです。
MVP、リリース計画、インクリメンタルデリバリー
実用最小限の製品 (MVP) は、チームが主要な仮説を実際のユーザーでテストできる、最小の一貫したスライスです。その目的は、単なるデリバリーではなく、学習です。次にリリース計画がその上に重ねられます。MVPとそれに続くインクリメンタルなリリースからなるロードマップが与えられると、チームはベロシティを大まかなガイドとして使用し、どの機能がどのリリースに含まれるかを予測します。
インクリメンタルデリバリーは、組織に選択の自由、つまり意見ではなく証拠に基づいて方向転換する能力をもたらします。ユーザーに何かを見せる前に「完全な」リリースを待つことは、アジャイルが特に防ぐために設計されたアンチパターンです。
見積もり、ストーリーポイント、ベロシティ
ストーリーポイントは、期間ではなく、相対的な労力、複雑さ、不確実性を測定するものです。5ポイントのストーリーは、その特定のチームにとって、1ポイントのストーリーの約5倍の労力がかかることを意味します。ベロシティ（スプリントごとに完了したポイント）は、数回のスプリントを経て経験的に明らかになり、カレンダー上のコミットメントを行うためではなく、予測範囲を示すために使用されます。
ストーリーポイントを固定の日数として扱うことは、いくつかの理由から深刻な落とし穴です。第一に、抽象化が破壊されます。もし1ポイント＝1日となれば、チームは単に日数で見積もり、締め切りに間に合わせるために見積もりを水増しするようになるでしょう。第二に、不確実性のシグナルが失われます。13ポイントのストーリーは単に「長い」だけでなく、リスキーであり、そのリスクはストーリーの分割を促すべきものです。第三に、マネジメントが数値を武器にすることを可能にしてしまいます（「40ポイントと言ったのに、なぜ32しか終わらなかったのか？」）。これは、チームが能力を過小に見積もる行動（サンドバッギング）を助長します。正しい使い方は、ベロシティの傾向＋バックログのサイズ→確率的なリリース予測、という流れで、範囲として伝えることです。
妨害、割り込み、フローの管理
スクラムマスターの最も具体的な仕事は、妨害の排除です。チームメンバーが静かに苦労しているとき（プライドが高すぎたり、新しすぎて問題を提起できなかったりする場合）、チームリーダーは直接関与し、妨害を理解し、解決を手伝うかエスカレーションすべきです。デイリースタンドアップの目的を無視することが、この悪しきパターンが蔓延する原因となります。一貫性のないスタンドアップへの参加は、知識のサイロ化を生み、ブロッカーを隠し、小さな問題をスケジュールのリスクに発展させます。このセレモニーの価値はステータス報告ではなく同期にあるため、参加は交渉の余地がありません。
アドホックな割り込み（バックログを迂回する「緊急」リクエスト）も同様に有害です。それらはスプリントゴールを侵食し、予測を無効にし、プロセスは迂回できるとステークホルダーに学習させてしまいます。正しい対処法は、新しいリクエストをPO（プロダクトオーナー）経由にすることです。POは、それがスプリントのキャンセルを正当化するか（まれ）、将来のスプリントに入れるべきか（通常）を判断します。
テストや他の専門分野がボトルネックになっているハイブリッドチームの場合、カンバンボードやバーンダウン/バーンアップチャートによるフローの可視化が、その制約を明らかにします。チームがテストのブロックを解除できるツールを特定した場合、プロジェクトマネージャーは一方的に承認または却下すべきではありません。共同で提案を評価し、組織のガバナンス（調達、セキュリティ）を確認し、バックログへの影響についてPOと協議した上で決定すべきです。反射的な承認はデューデリジェンスを怠り、反射的な拒否はチームの専門知識を無視することになります。
レトロスペクティブと継続的改善
レトロスペクティブは、改善のループを完結させます。良いレトロスペクティブは、不満をぶちまけるだけの場ではなく、担当者が決まった1つか2つの具体的で改善アクションを生み出します。早い段階で運用チームやQAをレトロスペクティブに参加させることで、チームが本番環境の現実ではなくスプリント終了時のデモに最適化してしまうという、典型的な引き継ぎの失敗を防ぎます。継続的改善は、ベロシティを信頼できるものに保ち、DoD（完成の定義）を意味のあるものにし、プロダクトのライフサイクル全体を通じてチームのエンゲージメントを高く維持するためのメカニズムです。
実践的な問題：ユースケースシナリオ
シナリオ： Priya Nairは、フィンテック企業のモバイルウォレットチーム「LumenPay」のスクラムマスターです。チームは6人の開発者、1人のQAエンジニア、1人のUXデザイナーで構成され、2週間のスプリントを回しています。過去3回のスプリントで、プロダクトオーナーのMarcus Reevesは、リテールパートナーシップ部門の責任者としての職務との重複を理由に、スプリントプランニングに1回しか参加せず、スプリントレビューには一度も参加していません。コンプライアンス部門や不正対策部門のステークホルダーは、相反する優先度のリクエストを開発者に直接メールし始めており、チームは過去2回のスプリントで82ストーリーポイントのうち34ポイントを持ち越しています。スポンサーであるプロダクト担当VPのAnita Chenは、チームのベロシティに疑問を抱き始めています。
課題： Priyaは、プロダクトに関する決定を自ら下すことでサーバントリーダーとしての役割を逸脱することなく、プロダクトオーナーのエンゲージメントを回復させ、バックログの断片化を止めなければなりません。
推奨されるアプローチ：
- 過去3回のスプリントにおけるPO不在の具体的な影響（持ち越しポイント、曖昧な受け入れ基準、未解決のバックログアイテム、POを迂回したステークホルダーからの直接リクエストの件数）を文書化し、事実に基づいた主張を構築します。
- まずMarcusと1on1ミーティングを行い、データを共有し、この役割に必要な週10～15時間をコミットできるか、あるいは役割を再割り当てまたは分割する必要があるかを直接尋ねます。
- 文書化された証拠とともにAnita Chenに正式にエスカレーションし、2つの選択肢を提示します。POの役割をキャパシティのある別の人に再割り当てするか、Marcusのリテールパートナーシップ業務の削減を交渉するかです。
- 開発チームに対し、ステークホルダーからのすべてのリクエストをアドホックに受け入れるのではなく、プロダクトバックログにリダイレクトするように指導し、優先順位を変更できるのはPOだけであることを徹底します。
- コミットメントのあるPOが確定したら、バックログリファインメントのワークショップを実施し、優先順位を再設定し、受け入れ基準を整理し、次のイテレーションのスプリントゴールをリセットします。
- POがプランニング、レビュー、およびスプリントごとに最低2回のリファインメントセッションに出席することを明記したワーキングアグリーメント（チームの約束事）を確立します。
このアプローチが機能する理由： （実質的な）欠員状態をスポンサーにエスカレーションすることは、役割の健全性を保ちます。スクラムマスターはプロダクトオーナー代理になってはなりません。なぜなら、それは組織的な問題を恒久的に覆い隠し、価値に基づく優先順位付けを損なうからです。エスカレーションを具体的なメトリクスに基づかせることで、会話が個人的な問題ではなくデリバリーの成果に集中し、ステークホルダーからの要求をバックログ経由にすることで、スクラムが依存する「信頼できる唯一の情報源（single-source-of-truth）」という規律を回復します。
← チームリーダーシップとリソース管理 · すべてのドメイン · スコープ、要件、変更管理 →
これらの問題を練習する → · ExamRoll.ioで時間制限付き練習 →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
試験に合格する →