スクラム(Scrum)

既存プロセスの体系／種別: ライフサイクルプロセス(開発の全工程)

複雑な問題に対し、固定長の反復(スプリント)ごとに「検査と適応」を繰り返して価値あるプロダクトを届ける軽量フレームワーク

ひとことで言うと: 1か月以内の固定サイクルで「作って、見せて、直す」を繰り返す進め方。承認ゲートの代わりに、毎回の検査と適応で品質と方向を保つ

全体マップ(第1階層)

各フェーズをクリックすると、フェーズ内のワークフロー(第2階層)へ移動します。

graph LR
  ph0["スプリント"]
  click ph0 "/process-compass/processes/scrum/sprint/" "スプリントの詳細へ"

目的(purpose): 複雑な問題に対応する適応型の解決策を通じて、人々・チーム・組織が価値を生み出すことを支援する(スクラムガイド2020)

成果(outcomes):

原典: Ken Schwaber / Jeff Sutherland(1995年 OOPSLA 発表)。原典はスクラムガイド(最新 2020年版)

ISO/IEC/IEEE 12207 対応: 主に「テクニカルマネジメント(軽量な反復で代替。合意プロセス群・組織プロセス群は意図的に対象外)」プロセス群をカバー

ロール	責任	日本の現場での実態
プロダクトオーナー	プロダクトの価値最大化に対する結果責任。プロダクトゴールの策定、バックログの内容・並び順の単独決定(1人の人間であり委員会ではない)	事業部門の管理職が兼務して多忙となり、イベント欠席・バックログ放置・意思決定遅延に陥る例が定番の課題
スクラムマスター	スクラム確立への結果責任を持つ「真のリーダー」。チーム・PO・組織の支援役であり管理者ではない	受託開発ではベンダー側が選任する形が IPA モデル契約でも想定される。PO との兼任は利害相反のため不適
開発者	スプリントバックログの作成、完成の定義に基づく品質の作り込み、日々の計画適応。職能横断で肩書を分けない	複数チーム・複数案件の掛け持ちによる集中の欠如が課題として指摘される

ゲート	種別	Deliverables	判定基準	判定者	判定結果
スプリントレビュー(検査) ※原典は「リリースのゲートと見なしてはならない」と明文で禁止。ただし日本の受託開発では事実上の検収イベント化が起きがち	検査と適応	インクリメント / プロダクトゴールへの進捗	経験的な検査(承認基準ではない)	スクラムチーム+ステークホルダー(協働)	プロダクトバックログの適応
完成の定義(DoD)	検査と適応	スプリント内の全作業	DoD に列挙された品質基準(組織標準があれば最低限それに従う)	開発者(自己判定)	インクリメントとして成立 / プロダクトバックログへ差し戻し
スプリント中止	決裁(Go/Kill)	スプリントゴールの現状	スプリントゴールが陳腐化したか	プロダクトオーナー(唯一の Kill 権限)	継続 / 中止
リリース判断	決裁(Go/Kill)	インクリメント	プロダクト価値(レビュー通過は条件ではない)	プロダクトオーナー(任意のタイミング)	リリース / 保留

成果物	作成者	説明
プロダクトバックログ	プロダクトオーナー	唯一の作業源。コミットメントはプロダクトゴール(一度に追うのは1つ)
スプリントバックログ	開発者	スプリントゴール+選択アイテム+実行計画。開発者による開発者のための計画
インクリメント	開発者	完成の定義(DoD)を満たした利用可能な成果。DoD を満たさない作業はインクリメントと呼べない