どうする計画駆動型スクラム（スクラムフェス大阪2023 発表資料）

© 2023 NTT DATA Corporation
スクラムフェス大阪2023
どうする計画駆動型スクラム
2023年 7月 1日
技術革新統括本部システム技術本部 ADM技術部
平井翔一郎

© 2023 NTT DATA Corporation 2
はじめに
この発表は個人の経験や学びにもとづく見解であり、
所属する企業や部門を代表するものではありません。
また、計画駆動型開発そのものを否定するものでも、
計画駆動型開発の中でアジャイルのプラクティスを活用することを否定するものでもありません。
本資料における著作物の引用は、全て著作権法第32条1項における「正当な範囲内」
での引用に限定しています。

平井翔一郎/ Shoichiro Hirai
株式会社NTTデータ
技術革新統括本部システム技術本部 ADM技術部
• 2012年入社
• 入社より約7年は金融機関のお客様の情報系システムを中心にWF型の開発に従事
• 2018年よりアジャイルが中心に
• プロダクトオーナー：2年
• スクラムマスター：1年
• 2022年より金融系のお客様を担当する部署から異動、全社のアジャイル開発を支援する
現在の部署へ
自己紹介

参考書籍
• 『アジャイルと規律 ~ソフトウエア開発を成功させる2つの鍵のバランス~』(バリー・ベーム,リチャード・ターナー(著),河野正幸,
原幹,越智典子(訳),日経BP,2004)
• 『ソフトウェア見積り人月の暗黙知を解き明かす』(スティーブマコネル(著),溝口真理子,田沢恵,久手堅憲之(訳),日経
BP,2006)
• 『アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~』(Mike Cohn(著),安井力,角谷信太郎
(訳),マイナビ出版,2009)
• 『アジャイルサムライ-達人開発者への道』(Jonathan Rasmusson(著),近藤修平,角掛拓未(翻訳),西村直人,角谷
信太郎(監訳),オーム社,20011)
• 『エッセンシャルスクラム』(Kenneth S. Rubin(著),岡澤裕二,角征典,高木正弘,和智右桂(訳),翔泳社,2014)
• 『エクストリームプログラミング』(Kent Beck,Cynthia Andres(著),角征典(訳),オーム社,2015)
• 『ユーザーストーリーマッピング』(Jeff Patton(著),長尾高弘(訳),川口恭伸(監訳),オライリージャパン,2015)
• 『Clean Agile 基本に立ち戻れ』(Robert C.Martin(著),角征典,角谷信太郎(訳),ドワンゴ,2020)
• 『More Effective Agile “ソフトウェアリーダー”になるための28の道標』(Steve McConnell(著),クイープ(訳),長沢智治
(監訳),日経BP,2020)
• 『ゾンビスクラムサバイバルガイド』(Christiaan Verwijs,Johannes Schartau,Barry Overeem(著),木村卓央,高江
洲睦,水野正隆(訳),丸善出版,2022)

本日お伝えしたいこと
“見積りと計画作りがアジャイルじゃないのに
プロジェクトがアジャイルであるということはありえない”
出典：『アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~』
(Mike Cohn(著),安井力,角谷信太郎(訳),マイナビ出版,2009)

本日お伝えしたいこと
“見積りと計画作りがアジャイルじゃないのに
プロジェクトがアジャイルであるということはありえない”
スクラムでプロダクトを開発するにも関わらず、
従来型の計画駆動型開発の考えを基にスクラムを誤用した「計画駆動型スクラム」
という状況をこれまで何度か経験したので、その時何が起きて何を感じたか
また、現在計画駆動型スクラムにならないためにどうすべきと考えているかをお伝えしたい。
出典：『アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~』
(Mike Cohn(著),安井力,角谷信太郎(訳),マイナビ出版,2009)

目次
■第一部：計画駆動型スクラムとは
• 用語の確認
• 従来の計画駆動型開発の流れ
• 計画駆動型スクラムの流れ
• 計画駆動型スクラムの問題点
■幕間
■第二部：計画駆動型スクラムにならないために
• 気づき
• 計画駆動型スクラムを防止する
• それでも計画駆動型スクラムになってしまったら

第一部
計画駆動型スクラムとは

計画駆動型手法まず完全な要求分析を行い、次にそれらのすべてを設計し、そしてコーディング（構築）
を行い、最後にテストする手法。
計画と理解が適切であればあるほど、実行もうまくいく。
十分に定義され予見可能で、重大な変更がなさそうな問題に対して適用するとうまくいく。
問題は、プロダクト開発のほとんどが予見できるようなものではないということだ。初期段階
は特にそうである。
ウォーターフォールという単語はより広範な計画駆動型プロセスの一類型にすぎない。
言葉の定義
出典：『エッセンシャルスクラム』(Kenneth S. Rubin(著),岡澤裕二,角征典,高
木正弘,和智右桂(訳),翔泳社,2014)
本日の登壇における計画駆動型スクラムとは、本来計画駆動型手法ではないはずのスクラムを
計画駆動型の手法として使用（誤用）していることを指している。

開発アプローチ
また、PMBOK®ガイド第7版によると一般に開発アプローチには、予測型・ハイブリッド・適応型
の3つがあるとされている。
予測型アプローチプロジェクトの開始時にプロジェクトとプロダクトの要求事項を定義、収集、分析できるときに有効。
ウォーターフォール・アプローチとも呼ばれる。
多額の投資が行われ、リスクが高いので、頻繁なレビュー、変更管理の仕組み、開発フェーズ間の
再計画が必要なときに使われることが多い。
※以前は「計画駆動」という言葉を使用していたが、現在は「予測型」に決着した。
ハイブリッド・アプ
ローチ
予測型アプローチの要素と適応型アプローチの要素とを組み合わせたものである。
要求事項にまつわる不確かさやリスクがあるときに役立つ。
ハイブリッド・アプローチにおける適応性は、予測型アプローチよりも高くなるが、純粋な適応型アプ
ローチよりは低くなる。
適応型アプローチ要求事項の不確かさと変動性が高く、プロジェクト期間を通じて要求事項が変わる可能性が高い
時に役立つ。
反復型アプローチと漸進型アプローチを使う。しかし、適応型手法の色がより濃くなると、イテレーショ
ンがより短くなり、ステークホルダーのフィードバックに基づいてプロダクトが進化する可能性が高くなる。
アジャイル・アプローチは適応型と考えることができる。

図示すると
計画駆動型は予測型アプローチとも呼ばれる開発アプローチであり、ウォーターフォール・プロセス
もその中に含まれる。
一方アジャイルは適応型アプローチであり、適応型と予測型の間にはハイブリッドな領域が存在す
る。予測型→適応型に向かい徐々に反復型及び漸進型のアプローチが取られる。
予測型/計画駆動型
（ウォーターフォール）
ハイブリッド
適応型
（アジャイル）
徐々に反復型及び漸進型へ

従来の計画駆動型開発の流れ

従来の計画駆動型開発の始まり：概略図
事業会社
企画部門担当者
①新しいシステムを作りたいです。
開発費用の見積をお願いします。
要件はこんな感じです。
IT部門担当者

受託会社
事業会社
IT部門担当者
②見積りお願い
プロジェクトマネージャー

受託会社
事業会社
IT部門担当者
③承知しました！

受託会社
事業会社
IT部門担当者
開発者
XXks
規模
XX
生産性
÷

受託会社
XX人月
事業会社
IT部門担当者
開発者
見積り書
計画書
総工数
XXks
規模
XX
生産性
÷
＝
④見積りしました！

受託会社
XX人月
事業会社
IT部門担当者
決裁権者
開発者
見積り書
計画書
総工数
XXks
規模
XX
生産性
÷
＝

受託会社
XX人月
事業会社
IT部門担当者
⑤スコープ・予算・納期
について承認します。
プロジェクト開始して下さい。
決裁権者
開発者
見積り書
計画書
総工数
XXks
規模
XX
生産性
÷
＝

受託会社
XX人月
事業会社
IT部門担当者
決裁権者
開発者
見積り書
計画書
総工数
XXks
規模
XX
生産性
÷
＝
ここをもう少し深堀

従来の計画駆動型開発の見積りの流れ
規模
• アプリ規模、作業規模の見積り
生産性
• 用いる生産性指標を決める
工数
• 規模を生産性で割る
費用
• 工数に単金をかける
期間
• 規模、工数、投入要員などを加味して期間を見積る

従来の計画駆動型開発の見積り：規模の見積り
計画駆動型開発におけるソフトウェアの規模の見積りには一般的に以下の2つが使われる
• SLOC法/LOC法（Source Lines of Code）
開発するコードステップ数を見積る
• FP法（Function Point）
ファイルやデータを処理する機能の種類や数、複雑度から見積る
イメージ NO 機能名規模(step)
1 ログイン 1000
2 商品検索 2000
3 商品登録 1500
4 ユーザ登録 1300
5 決済 2700
・
・
・
合計 395000

従来の計画駆動型開発の見積り：工数の見積り
生産性指標は、各会社や各担当で過去の実績などから決められているものを用いることが多い。
例としてIPAが公開している「ソフトウェア開発分析データ集2022」より
300kSLOC以上の規模の際の中央値 0.79kstep/人月を用いて、
先ほどの規模に対して工数を算出する。

従来の計画駆動型開発の見積り：工数の見積り
生産性指標は、各会社や各担当で過去の実績などから決められているものを用いることが多い。
例としてIPAが公開している「ソフトウェア開発分析データ集2022」より
300kSLOC以上の規模の際の中央値 0.79kstep/人月を用いて、
先ほどの規模に対して工数を算出する。
NO 機能名規模(step) 工数
1 ログイン 1000 25人日
2 商品検索 2000 51人日
3 商品登録 1500 38人日
4 ユーザ登録 1300 33人日
5 決済 2700 68人日
・
・
・
合計 395000 10000人日
（500人月）
イメージ

従来の計画駆動型開発の見積り：工期の見積り
全体の工期はJUASが公開している全体工数の3乗根の2.7倍という参考値がある。
先程全体工数は500人月という数字が出たので
2.7 × ∛500

2.7 × ∛500
全体工期は21.5ヶ月

工程ごとの工期についても先ほどの生産性の指標値と同様に公開指標や各社のノウハウを元に
見積りを行う。
要件定義基本設計詳細設計 M/UT 結合試験総合試験 (受入試験)
23% 16% 14% 20% 15% 12% 12%
2.7 × ∛500
工程ごとの
工期に関する
指標（値はサンプル値）

工程ごとの工期についても先ほどの生産性の指標値と同様に公開指標や各社のノウハウを元に
見積りを行う。
23% 16% 14% 20% 15% 12% 12%
5ヶ月 3.5ヶ月 3ヶ月 4.5ヶ月 3ヶ月 2.5ヶ月 2.5ヶ月
2.7 × ∛500
工程ごとの
工期に関する
イメージ

従来の計画駆動型開発の見積り：計画の完成
工程ごとの工数についても公開指標や各社のノウハウを元に見積りを行う。
14% 16% 15% 27% 17% 11% 12%
工程ごとの
工数に関する

14% 16% 15% 27% 17% 11% 12%
70人月 80人月 75人月 135人月 85人月 55人月 60人月
工程ごとの
工数に関する
イメージ

14% 16% 15% 27% 17% 11% 12%
70人月 80人月 75人月 135人月 85人月 55人月 60人月
4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月
PM＋PMO 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
要件定義 11 11 11 11 11
基本設計 17 17 17
詳細設計 21 21 21
M/UT 27 27 27 27 27
結合試験 25 25 25
総合試験 18 18 18
受入試験 20 20
スケジュール
要件定義基本設計結合試験総合試験
M/UT
詳細設計受入試験
工程ごとの
工数に関する
イメージ

プロジェクトをマネジメントする
こうしてできたスケジュールをベースに全体の計画書や工程ごとの計画書を作成し、
プロジェクトを推進する。
各社で定められている標準的なプロジェクト管理手順や
「プロジェクトマネジメント知識体系ガイド」（PMBOK®）を参考に
工程ごとに考えるべき観点や必要な作業・アウトプットを計画し、
問題なく進んでいるかを管理するのがプロジェクトマネージャーの重要な仕事
4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月 1月 2月 3月
PM＋PMO 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3 3
要件定義 11 11 11 11 11
基本設計 17 17 17
詳細設計 21 21 21
M/UT 27 27 27 27 27
結合試験 25 25 25
総合試験 18 18 18
受入試験 20 20
スケジュール
要件定義基本設計結合試験総合試験
M/UT
詳細設計受入試験

プロジェクトマネジメント・プロセス群と知識エリア
例えば、PMBOK®ではプロジェクトマネジメントのプロセス群と
知識に対する要求事項によって定義された知識エリアによって分類されている。
これらのマトリクスと、そのインプット・ツールと技法・アウトプットが定義されている。
統合管理スコープ管理スケジュール管理コスト管理品質管理資源管理コミュニケーション管理リスク管理調達管理ステークホルダー管理
立ち上げプロジェクト憲章の作成ステークホルダーの特定
計画
プロジェクトマネジメント
計画書の作成
スコープ管理の計画
要求事項の収集
スコープの定義
WBSの作成
スケジュール管理の計画
アクティビティの定義
アクティビティの順序設定
アクティビティ所要期間の
見積り
スケジュールの作成
コスト管理の計画
コストの見積り
予算の設定
品質管理の計画
資源管理の計画
アクティビティ資源の見積
り
コミュニケーション管理の
計画
リスク管理の計画
リスクの特定
リスクの定性的分析
リスクの定量的分析
リスク対応の計画
調達管理の計画
ステークホルダーエンゲー
ジメントの計画
実行
プロジェクト作業の指揮・
管理
プロジェクト知識の管理
品質の管理
資源の獲得
チームの育成
チームの管理
コミュニケーションの管理リスク対応策の実行調達の実行
ジメントの管理
監視・コント
ロール
プロジェクト作業の監視・
コントロール
統合変更管理
スコープの妥当性確認
スコープのコントロール
スケジュールのコントロー
ル
コストのコントロール品質のコントロール資源のコントロールコミュニケーションの監視リスクの監視調達のコントロール
ジメントの監視
終結
プロジェクトやフェーズの
終結
知識エリア
プロ
ジェク
トマネ
ジメン
ト・プロ
セス群

いつも完全なウォーターフォールばかりではない
冒頭で「ハイブリッド・アプローチ」とした反復型や漸進型を取り入れるケースもある。

• 途中で判明した追加仕様を取り組むケース
基本設計や詳細設計で気づいた/追加となった要件について影響範囲を判断し、
結合試験の途中で合流できるように計画する進め方

• 途中で判明した追加仕様を取り組むケース
• 最初からフェーズごとに機能を分割したイテレーション開発を行うケース
前フェーズの詳細設計が終わったタイミングでそのメンバーは次のフェーズの基本設計を行い、
製造は詳細設計を元にニアショア/オフショアを活用する進め方。

計画駆動型スクラムの流れ

計画駆動型スクラムの始まり：概略図
事業会社
IT部門担当者

受託会社
事業会社
IT部門担当者

受託会社
事業会社
IT部門担当者
開発者

計画駆動型スクラムの見積りイメージ
要件はユーザーストーリーマップを使って整理しました。
リリース１の範囲のみとリリース1～3全て対応した時の
費用と期間が概算で知りたいです。
事業会社PO

承知しました、対応します。
事業会社PO
受託会社

ユーザーストーリーの形式になっていますが、現状それ以上
の情報はないので、今の情報から相対見積りをTシャツサイ
ズを使って（S/M/L）やりますね。
事業会社PO
受託会社
開発者

ユーザーストーリーの形式になっていますが、現状それ以上
の情報はないので、今の情報から相対見積りをTシャツサイ
ズを使って（S/M/L）やりますね。
見積りました。
事業会社PO
受託会社
開発者
開発者

見積りありがとう。
ポイントにするとSが3sp、Mが5sp、Lが8spぐらい？
仮に今のチームで対応するなら
2週間のスプリントでベロシティ20ぐらいかな？
受託会社

ポイントはそんなイメージです。
ベロシティもまぁそれぐらいじゃないですかね。
受託会社
開発者

ポイントはそんなイメージです。
ベロシティもまぁそれぐらいじゃないですかね。
了解。
リリースバーンダウンチャートにするとこんな感じかな。
リリース1～3の範囲全て対応してもスプリントは
10あれば作りきれそうだね。
受託会社
受託会社
開発者

受託会社
事業会社
企画部門担当者 IT部門担当者プロジェクトマネージャー
# ユーザーストーリー SP
PBI_001 XXXとしてXXXをしたい 3
・
・
・
要件はこんな感じです。 ②見積りお願い
開発者

受託会社
事業会社
決裁権者
・
・
・
開発者

受託会社
事業会社
決裁権者
・
・
・
開発者
初期の計画が変更できない
計画駆動型スクラム
が始まる！！

そして計画駆動型スクラムが始まる
こないだ見積もってもらったあのプロジェクト来月からやる
ことになりました。
先方の役員会議で承認されて、ニュースリリースもされた
みたい。スコープもリリース日も決まってるからよろしく！
受託会社

えっ。。。マジですか。。。
概算って聞いたので約束したつもりはなかったんですけど・・・
受託会社
開発者

えっ。。。マジですか。。。
概算って聞いたので約束したつもりはなかったんですけど・・・
まぁスクラムでやるって先方は言ってるから
その辺りは現場でうまいことやってよ。
私は他のプロジェクトで忙しいから打ち合わせだけ出る
よ。打ち合わせ設定しておいて。
受託会社
受託会社
開発者

荒ぶる四天王
この状況では太古の昔からプロジェクトを統治する奴らが破壊と混乱を引き起こすことになる。

荒ぶる四天王
出典：『アジャイルサムライ-達人開発者への道』(Jonathan Rasmusson(著),近藤
修平,角掛拓未(翻訳),西村直人,角谷信太郎(監訳),オーム社,20011)

荒ぶる四天王
通常アジャイルでは時間・予算・品質は固定されたものとみなし、スコープを柔軟に扱うものだが、
計画駆動型スクラムではスコープをマネジメントする余地があまりにも少ない。
出典：『アジャイルサムライ-達人開発者への道』(Jonathan Rasmusson(著),近藤
修平,角掛拓未(翻訳),西村直人,角谷信太郎(監訳),オーム社,20011)

これって、ウォータースクラムフォール？
所謂「ウォータースクラムフォール」と呼ばれているものは計画駆動型スクラムに含まれると考える。
上記はあくまで一例だが、「企画・分析」や「要件定義」を経て
作るもののスコープや期限が決まっており、スプリントごとにフィードバックのサイクルが回せていない
（その必要があまりない）という特徴がある。
Water-Scrum-Fallのイメージ図

計画駆動型スクラムの問題点

初期の見積りは正確ではない
プロジェクトの進行に伴い見積りがどのように正確になっていくかを示した「不確実性のコーン」
にあるように初期コンセプト時点では見積りのバラつきが非常に大きい。
それにも関わらずプロジェクト開始時点の計画に従うことを強いられている。
出典：『ソフトウェア見積り人月の暗黙知を解き明かす』(スティーブマコネル(著),溝口真理子,
田沢恵,久手堅憲之(訳),日経BP,2006)
図：一般的なプロジェクトのマイルストーンに基づく不確実性のコーン

計画駆動型スクラムで起きること
先程のような形で始まった計画駆動型のスクラムでは、
以下のような事象が起きてしまう可能性がある。

1. 変えられないスコープ
2. ベロシティはPOやステークホルダーとの約束
3. 進捗が遅れたらキャッチアッププランを報告
4. 個々人をパフォーマンスで評価
5. スプリントゴールは立てられない
6. スウォーミングしない
7. ステークホルダーはスプリントレビューに興味がない
8. プロダクトバックログの優先度が決められない
9. アウトプットで評価される

※以降で紹介する事象は私が経験したものや社内で聞いたものをベースに抽象化し、
多少の脚色を加えたフィクションです。

１．変えられないスコープ
プロジェクト開始時には「機能一覧」や「画面一覧」といった設計書が作成されていてリリースまで
に作らなければならない機能が決まっている。
# 処理名予定スプリント
001 XX処理 1
002 XX処理 1
003 XX処理 2
004 XX処理 2
005 XX処理 2
006 XX処理 3
007 XX処理 3
008 XX処理 4
009 XXバッチ 3
010 XXバッチ 4
# 画面名予定スプリント
001 XX画面 1
002 XX画面 1
003 XX画面 1
004 XX画面 2
005 XX画面 2
006 XX画面 2
007 XX画面 3
008 XX画面 3
009 XX画面 3
010 XX画面 4
【機能一覧】【画面一覧】
※この事象は実際の経験をもとに抽象化し、

１．変えられないスコープ
プロジェクト開始時には「機能一覧」や「画面一覧」といった設計書が作成されていてリリースまで
に作らなければならない機能が決まっている。
ユーザーストーリーマップは作成しているが、プロジェクト開始時からほとんど更新されることはない。
ユーザーストーリーマップの一番左にある「ログイン」や「サインアップ」から作成する。
# 処理名予定スプリント
001 XX処理 1
002 XX処理 1
003 XX処理 2
004 XX処理 2
005 XX処理 2
006 XX処理 3
007 XX処理 3
008 XX処理 4
009 XXバッチ 3
010 XXバッチ 4
# 画面名予定スプリント
001 XX画面 1
002 XX画面 1
003 XX画面 1
004 XX画面 2
005 XX画面 2
006 XX画面 2
007 XX画面 3
008 XX画面 3
009 XX画面 3
010 XX画面 4
【処理一覧】【画面一覧】【ユーザーストーリーマップ】

２．ベロシティはPOやステークホルダーとの約束
当初想定のベロシティが出なければ、約束したスコープのリリースが難しくなるので何としてでもチー
ムにベロシティを守らせる。
ストーリーポイントでの見積りがインフレ化してしまうのを避けるため、POやステークホルダーはストー
リーポイントでの見積りに口を出す。
このPBIは5ポイントかな。
開発者
事業会社PO
事業会社PO
の上司

3ポイントで充分では？
開発者
事業会社PO
事業会社PO
の上司

3ポイントで充分では？
3ポイントにします…
開発者
事業会社PO
事業会社PO
の上司
開発者

３．進捗が遅れたらキャッチアッププランを報告
POやスクラムマスターはデイリースクラムでスプリントの状況をバーンダウンチャートで確認し、遅延
している場合はどのようにキャッチアップするのかを開発者に報告させる。
このPBIのこの受け入れ条件の
ロジックを実装するのに当初想
定より時間がかかっています。
事業会社PO
受託会社
スクラムマスター
開発者

事業会社PO
受託会社
このままだと全部終わらないと思
いますが
開発者

キャッチアップのため、このタス
クはBさんと交代します。
また当初予定していたリファク
タリングを後回しにします
事業会社PO
受託会社
このままだと全部終わらないと思
いますが
開発者
開発者

４．個々人をパフォーマンスで評価
スプリントごとに開発者ひとりひとりが何時間分のタスク（スプリントバックログ）を消化しているかを
集計し、パフォーマンスが低いメンバーには改善を要請。
他のメンバーと比べてEさんのパフォーマン
スが悪いようです。
改善策を検討してください。
スプリント4実績
対象者タスク消化時間
Aさん 40時間
Bさん 45時間
Cさん 42時間
Dさん 40時間
Eさん 32時間
Fさん 38時間
事業会社PO
事業会社PO
の上司

４．個々人をパフォーマンスで評価
スプリントごとに開発者ひとりひとりが何時間分のタスク（スプリントバックログ）を消化しているかを
集計し、パフォーマンスが低いメンバーには改善を要請。
他のメンバーと比べてEさんのパフォーマン
スが悪いようです。
改善策を検討してください。
はい… 検討します
スプリント4実績
対象者タスク消化時間
Aさん 40時間
Bさん 45時間
Cさん 42時間
Dさん 40時間
Eさん 32時間
Fさん 38時間
事業会社PO
事業会社PO
の上司
受託会社

５．スプリントゴールは立てられない
スプリントバックログには、透明性と集中を高める情報を提供する「確約（コミットメント）」として
スプリントゴールが存在しており、これにより進捗を測定するものとスクラムガイドに記載されている。
しかし、計画駆動型スクラムでは、最初に検討した全てのバックログを消化する必要があるため、
スプリントゴールは毎回「選択した全てのプロダクトバックログアイテムが完了すること。」になる。
今回のスプリントも「選択した全てのプロダク
トバックログアイテムが完了すること」がスプリ
ントゴールです。
事業会社PO
開発者

５．スプリントゴールは立てられない
スプリントバックログには、透明性と集中を高める情報を提供する「確約（コミットメント）」として
スプリントゴールが存在しており、これにより進捗を測定するものとスクラムガイドに記載されている。
しかし、計画駆動型スクラムでは、最初に検討した全てのバックログを消化する必要があるため、
スプリントゴールは毎回「選択した全てのプロダクトバックログアイテムが完了すること。」になる。
今回のスプリントも「選択した全てのプロダク
トバックログアイテムが完了すること」がスプリ
ントゴールです。
はい…
（スプリントゴールって何の意味があるんだ）
事業会社PO
開発者

６．スウォーミングしない
1つのSprintで優先度の高い（スプリントゴールの達成に直結する）プロダクトバックログアイテム
を確実に終わらせることよりも、定められた期間内に全てのプロダクトバックログ完了させるために、
リソース効率を優先する。

仕掛中のタスクが増えても
1スプリントで完了するバックログの数より
長期的にタスクが多く完了することを優先

７．スプリントレビューに興味がない
今回のスプリントのインクリメントは・・・
スクラムチーム
関連するステークホルダーに声をかけ、スプリントレビューに出席してもらうも、
「全部機能が揃って商用リリースが出来る状態になったらまとめて確認するから」と
インクリメントに興味を持ってもらえない。

デザイナーさんのデザイン通りだよね。
大丈夫大丈夫この調子で期限までに全部
作ってくれたら問題ないから。
事業会社PO
の上司

デザイナーさんのデザイン通りだよね。
大丈夫大丈夫この調子で期限までに全部
作ってくれたら問題ないから。
はい…
事業会社PO
の上司

８．プロダクトバックログの優先度が決められない
バックログを分割し、より優先度が高いものを先に優先度が低そうなものは後にという提案や、
技術的負債を解消するためのリファクタリングを実施したいという話しをしても、
プロダクトオーナーはすでに作られたバックログの詳細を決める権限しか持っていない。
チームとして前倒しでプロダクトバックログを消化しないと新しいプロダクトバックログは認められない。
バックログ分割してこの部分は簡易に実装できる
ので先に対応したいです。
この部分は本当にエンドユーザに重要ですか？優
先度下げてもいいと思うのですが。
開発者

こんな機能があったらエンドユーザーはもっと使いや
すくなると思うのですがどうでしょう？
開発者

こんな機能があったらエンドユーザーはもっと使いや
すくなると思うのですがどうでしょう？
決まっている部分は作らないと…
追加分は当初計画から前倒しで進まないと判
断できないので、当初計画通り進めて下さい。
開発者
事業会社PO

９．アウトプットで評価される
最終的にチームは当初計画通りにプロダクトバックログを消化できたかどうかで評価される。
プロダクトのアウトカムの測定は行われない。
計画通りにプロダクトバックログを消化できたチームは好事例として社内で共有され、
そしてまた次の計画駆動型スクラムが始まる。
当初計画より1スプリント追加で必要にはなった
が、概ねオンスケだな。
お疲れ様。A評価だ。
事業会社PO
の上司

９．アウトプットで評価される
最終的にチームは当初計画通りにプロダクトバックログを消化できたかどうかで評価される。
プロダクトのアウトカムの測定は行われない。
計画通りにプロダクトバックログを消化できたチームは好事例として社内で共有され、
そしてまた次の計画駆動型スクラムが始まる。
当初計画より1スプリント追加で必要にはなった
が、概ねオンスケだな。
お疲れ様。A評価だ。
ありがとうございます。
（いい評価を貰えたのは嬉しいけど、アジャイ
ルってこれでいいんだっけ。。。）
事業会社PO
の上司
開発者

計画駆動型スクラムのスクラムチームはどうなるか

• メンバーはどんどん疲弊していく

• チーム内での信頼関係はなく、各自が元々得意だったタスクを淡々とこなす

• 開発者はよいプロダクトとは何かを考えることをやめ、フィーチャーファクトリーになってしまう

• レトロスペクティブには価値を見出せずやらなくなる（その時間でタスクを消化する。）

• 作る範囲が決まっているのでシンプルな設計（YAGNI原則）よりも今起票されている全ての
PBIを満たす設計を考え、コードの保守性も後回しに

• 作る範囲が決まっているのでシンプルな設計（YAGNI原則）よりも今起票されている全ての
PBIを満たす設計を考え、コードの保守性も後回しに
• 最終的にはスクラムは効率が悪いので、決まっている分は全てまとめて設計/実装/テストさせ
てくれという話しになる

第一部
計画駆動型スクラムとは
ー完ー

第二部へ続く
絵：ブラックジャックによろしく佐藤秀峰

第二部へ続く
テ
イ
ラ
ー
主
義
の
ま
ま
だ

第二部へ続く
テ
イ
ラ
ー
主
義
の
ま
ま
だ
ア
ジ
ャ
イ
ル
は
・
・
・
・
柔
軟
性
が
高
く
、
コ
ミ
ュ
ニ
ケ
ー
シ
ョ
ン
と
フ
ィ
ー
ド
バ
ッ
ク
を
重
視
す
る
の
で
は
な
い
の
か
ア
ウ
ト
カ
ム
の
事
な
ん
て
考
え
て
な
い
じ
ゃ
な
い
か
・
・
・

第二部へ続く
テ
イ
ラ
ー
主
義
の
ま
ま
だ
ア
ジ
ャ
イ
ル
は
・
・
・
・
柔
軟
性
が
高
く
、
コ
ミ
ュ
ニ
ケ
ー
シ
ョ
ン
と
フ
ィ
ー
ド
バ
ッ
ク
を
重
視
す
る
の
で
は
な
い
の
か
ア
ウ
ト
カ
ム
の
事
な
ん
て
考
え
て
な
い
じ
ゃ
な
い
か
・
・
・
顧
客
へ
の
〟
価
値
〝
な
ん
て
も
の
考
え
て
ど
う
な
る
お
前
た
ち
開
発
者
は
言
わ
れ
た
も
の
を
淡
々
と
作
っ
て
い
れ
ば
そ
れ
で
い
い
ん
だ

第二部へ続く
テ
イ
ラ
ー
主
義
の
ま
ま
だ
ア
ジ
ャ
イ
ル
は
・
・
・
・
柔
軟
性
が
高
く
、
コ
ミ
ュ
ニ
ケ
ー
シ
ョ
ン
と
フ
ィ
ー
ド
バ
ッ
ク
を
重
視
す
る
の
で
は
な
い
の
か
ア
ウ
ト
カ
ム
の
事
な
ん
て
考
え
て
な
い
じ
ゃ
な
い
か
・
・
・
顧
客
へ
の
〟
価
値
〝
な
ん
て
も
の
考
え
て
ど
う
な
る
お
前
た
ち
開
発
者
は
言
わ
れ
た
も
の
を
淡
々
と
作
っ
て
い
れ
ば
そ
れ
で
い
い
ん
だ
原
理
主
義
者
の
ピ
ュ
ア
ア
ジ
ャ
イ
ル
な
や
り
方
な
ど
エ
ン
タ
ー
プ
ラ
イ
ズ
の
現
場
で
は
通
用
し
な
い
た
だ
の
理
想
論
だ

第二部へ続く
テ
イ
ラ
ー
主
義
の
ま
ま
だ
ア
ジ
ャ
イ
ル
は
・
・
・
・
柔
軟
性
が
高
く
、
コ
ミ
ュ
ニ
ケ
ー
シ
ョ
ン
と
フ
ィ
ー
ド
バ
ッ
ク
を
重
視
す
る
の
で
は
な
い
の
か
ア
ウ
ト
カ
ム
の
事
な
ん
て
考
え
て
な
い
じ
ゃ
な
い
か
・
・
・
顧
客
へ
の
〟
価
値
〝
な
ん
て
も
の
考
え
て
ど
う
な
る
お
前
た
ち
開
発
者
は
言
わ
れ
た
も
の
を
淡
々
と
作
っ
て
い
れ
ば
そ
れ
で
い
い
ん
だ
無
計
画
で
臨
機
応
変
に
や
り
ま
す
な
ん
て
許
さ
れ
る
も
の
で
は
な
い
や
っ
て
み
な
い
と
わ
か
ら
な
い
な
ど
ふ
ざ
け
た
こ
と
を
言
う
な
原
理
主
義
者
の
ピ
ュ
ア
ア
ジ
ャ
イ
ル
な
や
り
方
な
ど
エ
ン
タ
ー
プ
ラ
イ
ズ
の
現
場
で
は
通
用
し
な
い
た
だ
の
理
想
論
だ

第二部へ続く
テ
イ
ラ
ー
主
義
の
ま
ま
だ
ア
ジ
ャ
イ
ル
は
・
・
・
・
柔
軟
性
が
高
く
、
コ
ミ
ュ
ニ
ケ
ー
シ
ョ
ン
と
フ
ィ
ー
ド
バ
ッ
ク
を
重
視
す
る
の
で
は
な
い
の
か
ア
ウ
ト
カ
ム
の
事
な
ん
て
考
え
て
な
い
じ
ゃ
な
い
か
・
・
・
顧
客
へ
の
〟
価
値
〝
な
ん
て
も
の
考
え
て
ど
う
な
る
お
前
た
ち
開
発
者
は
言
わ
れ
た
も
の
を
淡
々
と
作
っ
て
い
れ
ば
そ
れ
で
い
い
ん
だ
無
計
画
で
臨
機
応
変
に
や
り
ま
す
な
ん
て
エ
ン
タ
ー
プ
ラ
イ
ズ
の
現
場
で
は
通
用
し
な
い
た
だ
の
理
想
論
だ
許
さ
れ
る
も
の
で
は
な
い
や
っ
て
み
な
い
と
わ
か
ら
な
い
な
ど
ふ
ざ
け
た
こ
と
を
言
う
な
原
理
主
義
者
の
ピ
ュ
ア
ア
ジ
ャ
イ
ル
な
や
り
方
な
ど

第二部へ続く
テ
イ
ラ
ー
主
義
の
ま
ま
だ
ア
ジ
ャ
イ
ル
は
・
・
・
・
柔
軟
性
が
高
く
、
コ
ミ
ュ
ニ
ケ
ー
シ
ョ
ン
と
フ
ィ
ー
ド
バ
ッ
ク
を
重
視
す
る
の
で
は
な
い
の
か
ア
ウ
ト
カ
ム
の
事
な
ん
て
考
え
て
な
い
じ
ゃ
な
い
か
・
・
・
顧
客
へ
の
〟
価
値
〝
な
ん
て
も
の
考
え
て
ど
う
な
る
お
前
た
ち
開
発
者
は
言
わ
れ
た
も
の
を
淡
々
と
作
っ
て
い
れ
ば
そ
れ
で
い
い
ん
だ
無
計
画
で
臨
機
応
変
に
や
り
ま
す
な
ん
て
エ
ン
タ
ー
プ
ラ
イ
ズ
の
現
場
で
は
通
用
し
な
い
た
だ
の
理
想
論
だ
許
さ
れ
る
も
の
で
は
な
い
や
っ
て
み
な
い
と
わ
か
ら
な
い
な
ど
ふ
ざ
け
た
こ
と
を
言
う
な
学
ぶ
し
か
な
い
・
・
・
ア
ジ
ャ
イ
ル
の
人
間
中
心
の
考
え
方
が
よ
り
よ
い
ソ
フ
ト
ウ
ェ
ア
開
発
の
や
り
方
の
は
ず
だ
原
理
主
義
者
の
ピ
ュ
ア
ア
ジ
ャ
イ
ル
な
や
り
方
な
ど

第二部へ続く
テ
イ
ラ
ー
主
義
の
ま
ま
だ
ア
ジ
ャ
イ
ル
は
・
・
・
・
柔
軟
性
が
高
く
、
コ
ミ
ュ
ニ
ケ
ー
シ
ョ
ン
と
フ
ィ
ー
ド
バ
ッ
ク
を
重
視
す
る
の
で
は
な
い
の
か
ア
ウ
ト
カ
ム
の
事
な
ん
て
考
え
て
な
い
じ
ゃ
な
い
か
・
・
・
顧
客
へ
の
〟
価
値
〝
な
ん
て
も
の
考
え
て
ど
う
な
る
お
前
た
ち
開
発
者
は
言
わ
れ
た
も
の
を
淡
々
と
作
っ
て
い
れ
ば
そ
れ
で
い
い
ん
だ
無
計
画
で
臨
機
応
変
に
や
り
ま
す
な
ん
て
エ
ン
タ
ー
プ
ラ
イ
ズ
の
現
場
で
は
通
用
し
な
い
た
だ
の
理
想
論
だ
許
さ
れ
る
も
の
で
は
な
い
や
っ
て
み
な
い
と
わ
か
ら
な
い
な
ど
ふ
ざ
け
た
こ
と
を
言
う
な
学
ぶ
し
か
な
い
・
・
・
ア
ジ
ャ
イ
ル
の
人
間
中
心
の
考
え
方
が
よ
り
よ
い
ソ
フ
ト
ウ
ェ
ア
開
発
の
や
り
方
の
は
ず
だ
だ
っ
た
ら
僕
は
書
籍
や
ア
ジ
ャ
イ
ル
の
コ
ミ
ュ
ニ
テ
ィ
か
ら
と
こ
と
ん
学
ん
で
や
る
！
原
理
主
義
者
の
ピ
ュ
ア
ア
ジ
ャ
イ
ル
な
や
り
方
な
ど

第二部
計画駆動型スクラムにならないために

気づき

計画駆動からの脱却を目指して
受託開発における限界かと諦めかけた時、沢山の気づきや勇気を与えてくれた

• アジャイルコミュニティとの出会い
• 認定スクラムマスター研修にて

• RSGT、Scrum Festや各種勉強会でのいきいきとした発表やディスカッション
1月
Regional Scrum Gathering Tokyo
6月
Scrum Fest Osaka
11月
Scrum Fest Sapporo
5月
Scrum Fest Niigata
8月
Scrum Fest Sendai
9月
Scrum Fest Mikawa
2月
Scrum Fest Fukuoka

たくさん効率よく作るのはスクラムの目指しているもの
ではない。
むしろ効率は悪く、効果的によりよいプロダクトを作
るためのフレームワークである。
研修講師の
スクラムトレーナー

書籍『ゾンビスクラムサバイバルガイド』にも同様のことが
“スクラムフレームワークは効率的であることよりも
効果的であることに重きを置いている”
出典：『ゾンビスクラムサバイバルガイド』(Christiaan Verwijs,Johannes Schartau,Barry Overeem(著),
木村卓央,高江洲睦,水野正隆(訳),丸善出版,2022)

計画駆動型と適応型の分岐点
「グラデーションとはいいつつ、もしかして・・・ハイブリッドアジャイルなんて存在しないんじゃ・・・」

ハイブリッド
適応型
徐々に反復型及び漸進型へ

ハイブリッド
適応型
↑この辺りに
ハイブリッドウォーターフォールはありそう

ハイブリッド
適応型
↑この辺りに
ハイブリッドウォーターフォールはありそう
他にもアジャイルでよく使われるプラクティスを
有効活用するやり方
例）
・デイリーをやる
・週1でふりかえりをやる
・テスト駆動開発を取り入れる
・ペアプロでコーディングする

ハイブリッド
適応型
↑ここは？🤔

ハイブリッド
適応型
最初の
計画
顧客への
価値
スライダー
最初の
計画
顧客への
価値
スライダー
最初の
計画
顧客への
価値
スライダー
トレードオフスライダーを考えてみる

ハイブリッド
適応型
最初の
計画
顧客への
価値
スライダー
最初の
計画
顧客への
価値
スライダー
最初の
計画
顧客への
価値
スライダー
↑このブレイクスルーポイントって何でしょう？🤔

私が考えたことは、
• アジャイル宣言の背後にある原則からこの2つの原則が守れること
• 「顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。」
• 「動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。」
• 2017年版のスクラムガイドに記載されているスプリントゴールが古くなった場合にスプリントの中止が行えること
ハイブリッド
適応型
最初の
計画
顧客への
価値
スライダー
最初の
計画
顧客への
価値
スライダー
最初の
計画
顧客への
価値
スライダー

でもこれはハイブリッドでも何でもなく、アジャイルと言える状態に思える。
ハイブリッド
適応型
最初の
計画
顧客への
価値
スライダー
最初の
計画
顧客への
価値
スライダー
最初の
計画
顧客への
価値
スライダー

アジャイル（スクラム）をやるなら計画より顧客への価値を重視する以外の選択肢はなさそう。
ハイブリッド
適応型
最初の
計画
顧客への
価値
スライダー
最初の
計画
顧客への
価値
スライダー
最初の
計画
顧客への
価値
スライダー

アジャイル（スクラム）をやるなら計画より顧客への価値を重視する以外の選択肢はなさそう。
適応型を目指す際の一時的な策ならまだしもずっと計画駆動型スクラムというのはよくない。
ハイブリッド
適応型
最初の
計画
顧客への
価値
スライダー
最初の
計画
顧客への
価値
スライダー
最初の
計画
顧客への
価値
スライダー

計画駆動型スクラムを防止する

受託会社
（再）計画駆動型スクラムの始まり：概略図
事業会社
IT部門担当者
開発者

受託会社
（再）計画駆動型スクラムの始まり：概略図
事業会社
IT部門担当者
決裁権者
プロジェクトが開始するまでに発生するの
コミュニケーションがとても重要
開発者

（再）計画駆動型スクラムで起きること
先程のような形で始まった計画駆動型のスクラムでは、以下のような事象が起きてしまう可能性
がある。

がある。
このような事象が起きてしまうということはそもそも
• アジャイルやスクラムに関する理解が不足している
• 組織カルチャーの問題
も原因としてあるのではないか。

がある。
アジャイルやスクラムの研修を受けていたり、書籍を読
んで学んでいることが多い。

がある。
アジャイルやスクラムの研修を受けていたり、書籍を読
んで学んでいることが多い。
実際にプロダクトマネジメントやアジャイルな計画づくり
を実践する中で理解してもらう必要がある。

計画駆動型スクラムに陥らないためのステップ
プロジェクトが開始するまでに発生するステークホルダーとのコミュニケーションがとても重要。

意思決定計画づくり

• スクラムで進めることについて
関係者全員で合意
• 解こうとしている問題につ
いて認識を合わせる
• 重要要因の分析
• リスク評価の実施
意思決定計画づくり

解こうとしている問題の認識を合わせる
クネビンフレームワークとはディビッド・スノーデンが世の中のシステムに起こる問題を分類し、
意思決定するためのフレームワークとして整理したもの。

無秩序
複雑
[調査・把握・対処]
混沌
[行動・把握・対処]
煩雑
[把握・分析・対処]
単純
[把握・分類・対処]

無秩序
複雑
混沌
煩雑
単純
問題の全体像、質問すべき内容、
答えを得る方法は分かっているが、
正しい答えは複数存在し、因果関係は入
り組んでいる。
分析して1つの正しい対処法を選択する。

無秩序
複雑
混沌
煩雑
単純
計画駆動向き

無秩序
複雑
混沌
煩雑
単純
質問すべき内容は事前に全てわ
かっていないため、調査から行う。
解決策に向かって前進するには実
験が必要。ある程度の失敗も織り込
んでおく必要がある。計画駆動向き

無秩序
複雑
混沌
煩雑
単純
計画駆動向き
質問すべき内容は事前に全てわ
かっていないため、調査から行う。
解決策に向かって前進するには実
験が必要。ある程度の失敗も織り込
んでおく必要がある。
アジャイル向き

重要要因の分析
出典：『アジャイルと規律 ~ソフトウエア開発を成功させる2つの鍵のバランス~』(バリー・ベーム,
リチャード・ターナー(著),河野正幸,原幹,越智典子(訳),日経BP,2004)
変化の度合い
（１ヶ月あたりの
要求変更の割合：%）
50
30
10
5
1

変化の度合い
文化
（明確な方針と手続きで役割が定義される文化よりも、
高い自由度の文化で反映する割合：%）
90
70
50
30
10
50
30
10
5
1

変化の度合い
文化
規模
（人数）
3
90
30
100
300
10
70
50
30
10
50
30
10
5
1

変化の度合い
文化
規模
（人数）
重要度
（欠陥があった
場合の損失）攪絆
多数の
生命 1人の
生命貴重な
資金
自由裁量の
資金快適
3
90
30
100
300
10
70
50
30
10
50
30
10
5
1

チームのソフトウェア手法の理解と利用のレベル
（レベル1B以下の割合：%）（レベル2以上の割合：%）
変化の度合い
文化
規模
（人数）
重要度
多数の
生命 1人の
生命貴重な
資金
自由裁量の
資金快適
3
90
30
100
300
10
70
50
30
10
50
30
10
5
1
15
20
25
30
35
40
30
20
10
0

変化の度合い
文化
規模
（人数）
重要度
多数の
生命 1人の
生命貴重な
資金
自由裁量の
資金快適
3
90
30
100
300
10
70
50
30
10
50
30
10
5
1
15
20
25
30
35
40
30
20
10
0
レベル特徴
3 先例のない新しい状況に適合するために（ルールを破ってでも）手
法を改訂することができる
2 先例のある新しい状況に適合するために手法をカスタマイズすることが
できる
1A トレーニングを受ければ、手法の手順のうち自由裁量の部分を遂行
することができる（例：インクリメントに合わせて開発するストーリーの
規模を調整する）
1B トレーニングを受ければ、手法の手順のうち手続き的な部分を遂行
することができる（例：単純なメソッドのコーディング簡単なリファクタリ
ング）
-1 技術的なスキルは持ち合わせているかもしれないが、協調したり共通
の手法に従ったりすることができない
表：チームのソフトウェア手法の理解と利用のレベル

変化の度合い
文化
規模
（人数）
重要度
多数の
生命 1人の
生命貴重な
資金
自由裁量の
資金快適
3
90
30
100
300
10
70
50
30
10
50
30
10
5
1
15
20
25
30
35
40
30
20
10
0
意思決定のコミュニケーションを行うためのツールとして用いる
例）
「この状況だったら、アジャイルは向いてないかもね。」
「チームメンバーのスキル向上のために勉強会とか
やったほうがいいんじゃないかな。」
「何チームかになりそうだし、Spotifyモデルのギルドやチャプター
の活動を参考に取り組んでみる？」
レベル特徴
3 先例のない新しい状況に適合するために（ルールを破ってでも）手
法を改訂することができる
2 先例のある新しい状況に適合するために手法をカスタマイズすることが
できる
1A トレーニングを受ければ、手法の手順のうち自由裁量の部分を遂行
することができる（例：インクリメントに合わせて開発するストーリーの
規模を調整する）
1B トレーニングを受ければ、手法の手順のうち手続き的な部分を遂行
することができる（例：単純なメソッドのコーディング簡単なリファクタリ
ング）
-1 技術的なスキルは持ち合わせているかもしれないが、協調したり共通
の手法に従ったりすることができない
表：チームのソフトウェア手法の理解と利用のレベル

変化の度合い
文化
規模
（人数）
重要度
多数の
生命 1人の
生命貴重な
資金
自由裁量の
資金快適
3
90
30
100
300
10
70
50
30
10
50
30
10
5
1
15
20
25
30
35
40
30
20
10
0
意思決定のコミュニケーションを行うためのツールとして
用いる
例）
「この状況だったら、アジャイルは向いてないかもね。」
「チームメンバーのスキル向上のために勉強会とか
やったほうがいいんじゃないかな。」
「何チームかになりそうだし、Spotifyモデルのギルドや
チャプターの活動を参考に取り入れてみようか？」

リスク評価の実施
リスク項目
■環境リスク
技術の不確定性
多数の利害関係者
「システムのシステム」と呼ばれる複雑なネットワーク型システム
■アジャイル手法を用いるリスク
スケーラビリティおよび重要度
シンプルな設計の採用
人員の離脱
アジャイル手法のスキルを持った要員の不足
■計画駆動型手法を用いるリスク
急激な変化
迅速な成果の必要性
創発的な要求
計画駆動型手法のスキルを持った要員の不足

リスク評価の実施
リスク項目リスク評価
■環境リスク
技術の不確定性 □□□□□
多数の利害関係者 □□□□□
「システムのシステム」と呼ばれる複雑なネットワーク型システム □□□□□
■アジャイル手法を用いるリスク
スケーラビリティおよび重要度 □□□□□
シンプルな設計の採用 □□□□□
人員の離脱 □□□□□
アジャイル手法のスキルを持った要員の不足 □□□□□
■計画駆動型手法を用いるリスク
急激な変化 □□□□□
迅速な成果の必要性 □□□□□
創発的な要求 □□□□□
計画駆動型手法のスキルを持った要員の不足 □□□□□
リスク評価の尺度
■ー最小のリスク
■■ー中程度のリスク
■■■ー深刻だが対処可能なリスク
■■■■ー非常に深刻だが対処可能なリスク
■■■■■ーショートストッパーリスク（プロジェクトが中止されかねない）

どうする計画駆動型スクラム（スクラムフェス大阪2023 発表資料）

どうする計画駆動型スクラム（スクラムフェス大阪2023 発表資料）

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to どうする計画駆動型スクラム（スクラムフェス大阪2023 発表資料）

Similar to どうする計画駆動型スクラム（スクラムフェス大阪2023 発表資料） (20)

More from NTT DATA Technology & Innovation

More from NTT DATA Technology & Innovation (20)

Recently uploaded

Recently uploaded (8)

どうする計画駆動型スクラム（スクラムフェス大阪2023 発表資料）