Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
NI
Uploaded byNTT DATA Technology & Innovation
1,833 views

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

どうする計画駆動型スクラム （スクラムフェス大阪2023 発表資料） 2023年7月1日（土） NTTデータ 技術革新統括本部 システム技術本部 平井 翔一郎

Technology◦
© 2023 NTT DATA Corporation © 2023 NTT DATA Corporation スクラムフェス大阪2023 どうする計画駆動型スクラム 2023年 7月 1日 技術革新統括本部 システム技術本部 ADM技術部 平井 翔一郎
© 2023 NTT DATA Corporation 2 はじめに この発表は個人の経験や学びにもとづく見解であり、 所属する企業や部門を代表するものではありません。 また、計画駆動型開発そのものを否定するものでも、 計画駆動型開発の中でアジャイルのプラクティスを活用することを否定するものでもありません。 本資料における著作物の引用は、全て著作権法第32条1項における「正当な範囲内」 での引用に限定しています。
© 2023 NTT DATA Corporation 3 平井 翔一郎/ Shoichiro Hirai 株式会社NTTデータ 技術革新統括本部 システム技術本部 ADM技術部 • 2012年入社 • 入社より約7年は金融機関のお客様の情報系システムを中心にWF型の開発に従事 • 2018年よりアジャイルが中心に • プロダクトオーナー：2年 • スクラムマスター：1年 • 2022年より金融系のお客様を担当する部署から異動、全社のアジャイル開発を支援する 現在の部署へ 自己紹介
© 2023 NTT DATA Corporation 4 参考書籍 • 『アジャイルと規律 ~ソフトウエア開発を成功させる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)
© 2023 NTT DATA Corporation 5 本日お伝えしたいこと “見積りと計画作りがアジャイルじゃないのに プロジェクトがアジャイルであるということはありえない” 出典：『アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~』 (Mike Cohn(著),安井 力,角谷 信太郎(訳),マイナビ出版,2009)
© 2023 NTT DATA Corporation 6 本日お伝えしたいこと “見積りと計画作りがアジャイルじゃないのに プロジェクトがアジャイルであるということはありえない” スクラムでプロダクトを開発するにも関わらず、 従来型の計画駆動型開発の考えを基にスクラムを誤用した「計画駆動型スクラム」 という状況をこれまで何度か経験したので、その時何が起きて何を感じたか また、現在計画駆動型スクラムにならないためにどうすべきと考えているかをお伝えしたい。 出典：『アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~』 (Mike Cohn(著),安井 力,角谷 信太郎(訳),マイナビ出版,2009)
© 2023 NTT DATA Corporation © 2023 NTT DATA Corporation 7 目次 ■第一部：計画駆動型スクラムとは • 用語の確認 • 従来の計画駆動型開発の流れ • 計画駆動型スクラムの流れ • 計画駆動型スクラムの問題点 ■幕間 ■第二部：計画駆動型スクラムにならないために • 気づき • 計画駆動型スクラムを防止する • それでも計画駆動型スクラムになってしまったら
© 2023 NTT DATA Corporation 8 © 2023 NTT DATA Corporation 8 第一部 計画駆動型スクラムとは
© 2023 NTT DATA Corporation 9 計画駆動型手法 まず完全な要求分析を行い、次にそれらのすべてを設計し、そしてコーディング（構築） を行い、最後にテストする手法。 計画と理解が適切であればあるほど、実行もうまくいく。 十分に定義され予見可能で、重大な変更がなさそうな問題に対して適用するとうまくいく。 問題は、プロダクト開発のほとんどが予見できるようなものではないということだ。初期段階 は特にそうである。 ウォーターフォールという単語はより広範な計画駆動型プロセスの一類型にすぎない。 言葉の定義 出典：『エッセンシャル スクラム』(Kenneth S. Rubin(著),岡澤 裕二,角 征典,高 木 正弘,和智 右桂(訳),翔泳社,2014) 本日の登壇における計画駆動型スクラムとは、本来計画駆動型手法ではないはずのスクラムを 計画駆動型の手法として使用（誤用）していることを指している。
© 2023 NTT DATA Corporation 10 開発アプローチ また、PMBOK®ガイド第7版によると一般に開発アプローチには、予測型・ハイブリッド・適応型 の3つがあるとされている。 予測型アプローチ プロジェクトの開始時にプロジェクトとプロダクトの要求事項を定義、収集、分析できるときに有効。 ウォーターフォール・アプローチとも呼ばれる。 多額の投資が行われ、リスクが高いので、頻繁なレビュー、変更管理の仕組み、開発フェーズ間の 再計画が必要なときに使われることが多い。 ※以前は「計画駆動」という言葉を使用していたが、現在は「予測型」に決着した。 ハイブリッド・アプ ローチ 予測型アプローチの要素と適応型アプローチの要素とを組み合わせたものである。 要求事項にまつわる不確かさやリスクがあるときに役立つ。 ハイブリッド・アプローチにおける適応性は、予測型アプローチよりも高くなるが、純粋な適応型アプ ローチよりは低くなる。 適応型アプローチ 要求事項の不確かさと変動性が高く、プロジェクト期間を通じて要求事項が変わる可能性が高い 時に役立つ。 反復型アプローチと漸進型アプローチを使う。しかし、適応型手法の色がより濃くなると、イテレーショ ンがより短くなり、ステークホルダーのフィードバックに基づいてプロダクトが進化する可能性が高くなる。 アジャイル・アプローチは適応型と考えることができる。
© 2023 NTT DATA Corporation 11 図示すると 計画駆動型は予測型アプローチとも呼ばれる開発アプローチであり、ウォーターフォール・プロセス もその中に含まれる。 一方アジャイルは適応型アプローチであり、適応型と予測型の間にはハイブリッドな領域が存在す る。予測型→適応型に向かい徐々に反復型及び漸進型のアプローチが取られる。 予測型/計画駆動型 （ウォーターフォール） ハイブリッド 適応型 （アジャイル） 徐々に反復型及び漸進型へ
© 2023 NTT DATA Corporation 12 © 2023 NTT DATA Corporation 12 従来の計画駆動型開発の流れ
© 2023 NTT DATA Corporation 13 従来の計画駆動型開発の始まり：概略図 事業会社 企画部門担当者 ①新しいシステムを作りたいです。 開発費用の見積をお願いします。 要件はこんな感じです。 IT部門担当者
© 2023 NTT DATA Corporation 14 受託会社 従来の計画駆動型開発の始まり：概略図 事業会社 企画部門担当者 ①新しいシステムを作りたいです。 開発費用の見積をお願いします。 要件はこんな感じです。 IT部門担当者 ②見積りお願い プロジェクトマネージャー
© 2023 NTT DATA Corporation 15 受託会社 従来の計画駆動型開発の始まり：概略図 事業会社 企画部門担当者 ①新しいシステムを作りたいです。 開発費用の見積をお願いします。 要件はこんな感じです。 IT部門担当者 ②見積りお願い プロジェクトマネージャー ③承知しました！
© 2023 NTT DATA Corporation 16 受託会社 従来の計画駆動型開発の始まり：概略図 事業会社 企画部門担当者 ①新しいシステムを作りたいです。 開発費用の見積をお願いします。 要件はこんな感じです。 IT部門担当者 ②見積りお願い プロジェクトマネージャー ③承知しました！ 開発者 XXks 規模 XX 生産性 ÷
© 2023 NTT DATA Corporation 17 受託会社 XX人月 従来の計画駆動型開発の始まり：概略図 事業会社 企画部門担当者 ①新しいシステムを作りたいです。 開発費用の見積をお願いします。 要件はこんな感じです。 IT部門担当者 ②見積りお願い プロジェクトマネージャー ③承知しました！ 開発者 見積り書 計画書 総工数 XXks 規模 XX 生産性 ÷ ＝ ④見積りしました！
© 2023 NTT DATA Corporation 18 受託会社 XX人月 従来の計画駆動型開発の始まり：概略図 事業会社 企画部門担当者 ①新しいシステムを作りたいです。 開発費用の見積をお願いします。 要件はこんな感じです。 IT部門担当者 ②見積りお願い プロジェクトマネージャー ③承知しました！ ④見積りしました！ 決裁権者 開発者 見積り書 計画書 総工数 XXks 規模 XX 生産性 ÷ ＝
© 2023 NTT DATA Corporation 19 受託会社 XX人月 従来の計画駆動型開発の始まり：概略図 事業会社 企画部門担当者 ①新しいシステムを作りたいです。 開発費用の見積をお願いします。 要件はこんな感じです。 IT部門担当者 ②見積りお願い プロジェクトマネージャー ③承知しました！ ④見積りしました！ ⑤スコープ・予算・納期 について承認します。 プロジェクト開始して下さい。 決裁権者 開発者 見積り書 計画書 総工数 XXks 規模 XX 生産性 ÷ ＝
© 2023 NTT DATA Corporation 20 受託会社 XX人月 従来の計画駆動型開発の始まり：概略図 事業会社 企画部門担当者 ①新しいシステムを作りたいです。 開発費用の見積をお願いします。 要件はこんな感じです。 IT部門担当者 ②見積りお願い プロジェクトマネージャー ③承知しました！ ④見積りしました！ ⑤スコープ・予算・納期 について承認します。 プロジェクト開始して下さい。 決裁権者 開発者 見積り書 計画書 総工数 XXks 規模 XX 生産性 ÷ ＝ ここをもう少し深堀
© 2023 NTT DATA Corporation 21 従来の計画駆動型開発の見積りの流れ 規模 • アプリ規模、作業規模の見積り 生産性 • 用いる生産性指標を決める 工数 • 規模を生産性で割る 費用 • 工数に単金をかける 期間 • 規模、工数、投入要員などを加味して期間を見積る
© 2023 NTT DATA Corporation 22 従来の計画駆動型開発の見積り：規模の見積り 計画駆動型開発におけるソフトウェアの規模の見積りには一般的に以下の2つが使われる • SLOC法/LOC法（Source Lines of Code） 開発するコードステップ数を見積る • FP法（Function Point） ファイルやデータを処理する機能の種類や数、複雑度から見積る イメージ NO 機能名 規模(step) 1 ログイン 1000 2 商品検索 2000 3 商品登録 1500 4 ユーザ登録 1300 5 決済 2700 ・ ・ ・ 合計 395000
© 2023 NTT DATA Corporation 23 従来の計画駆動型開発の見積り：工数の見積り 生産性指標は、各会社や各担当で過去の実績などから決められているものを用いることが多い。 例としてIPAが公開している「ソフトウェア開発分析データ集2022」より 300kSLOC以上の規模の際の中央値 0.79kstep/人月を用いて、 先ほどの規模に対して工数を算出する。
© 2023 NTT DATA Corporation 24 従来の計画駆動型開発の見積り：工数の見積り 生産性指標は、各会社や各担当で過去の実績などから決められているものを用いることが多い。 例として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人月） イメージ
© 2023 NTT DATA Corporation 25 従来の計画駆動型開発の見積り：工期の見積り 全体の工期はJUASが公開している全体工数の3乗根の2.7倍という参考値がある。 先程全体工数は500人月という数字が出たので 2.7 × ∛500
© 2023 NTT DATA Corporation 26 従来の計画駆動型開発の見積り：工期の見積り 全体の工期はJUASが公開している全体工数の3乗根の2.7倍という参考値がある。 先程全体工数は500人月という数字が出たので 2.7 × ∛500 全体工期は21.5ヶ月
© 2023 NTT DATA Corporation 27 従来の計画駆動型開発の見積り：工期の見積り 全体の工期はJUASが公開している全体工数の3乗根の2.7倍という参考値がある。 先程全体工数は500人月という数字が出たので 工程ごとの工期についても先ほどの生産性の指標値と同様に公開指標や各社のノウハウを元に 見積りを行う。 要件定義 基本設計 詳細設計 M/UT 結合試験 総合試験 (受入試験) 23% 16% 14% 20% 15% 12% 12% 2.7 × ∛500 全体工期は21.5ヶ月 工程ごとの 工期に関する 指標（値はサンプル値）
© 2023 NTT DATA Corporation 28 従来の計画駆動型開発の見積り：工期の見積り 全体の工期はJUASが公開している全体工数の3乗根の2.7倍という参考値がある。 先程全体工数は500人月という数字が出たので 工程ごとの工期についても先ほどの生産性の指標値と同様に公開指標や各社のノウハウを元に 見積りを行う。 要件定義 基本設計 詳細設計 M/UT 結合試験 総合試験 (受入試験) 23% 16% 14% 20% 15% 12% 12% 要件定義 基本設計 詳細設計 M/UT 結合試験 総合試験 (受入試験) 5ヶ月 3.5ヶ月 3ヶ月 4.5ヶ月 3ヶ月 2.5ヶ月 2.5ヶ月 2.7 × ∛500 全体工期は21.5ヶ月 工程ごとの 工期に関する 指標（値はサンプル値） イメージ
© 2023 NTT DATA Corporation 29 従来の計画駆動型開発の見積り：計画の完成 工程ごとの工数についても公開指標や各社のノウハウを元に見積りを行う。 要件定義 基本設計 詳細設計 M/UT 結合試験 総合試験 (受入試験) 14% 16% 15% 27% 17% 11% 12% 工程ごとの 工数に関する 指標（値はサンプル値）
© 2023 NTT DATA Corporation 30 従来の計画駆動型開発の見積り：計画の完成 工程ごとの工数についても公開指標や各社のノウハウを元に見積りを行う。 要件定義 基本設計 詳細設計 M/UT 結合試験 総合試験 (受入試験) 14% 16% 15% 27% 17% 11% 12% 要件定義 基本設計 詳細設計 M/UT 結合試験 総合試験 (受入試験) 70人月 80人月 75人月 135人月 85人月 55人月 60人月 工程ごとの 工数に関する 指標（値はサンプル値） イメージ
© 2023 NTT DATA Corporation 31 従来の計画駆動型開発の見積り：計画の完成 工程ごとの工数についても公開指標や各社のノウハウを元に見積りを行う。 要件定義 基本設計 詳細設計 M/UT 結合試験 総合試験 (受入試験) 14% 16% 15% 27% 17% 11% 12% 要件定義 基本設計 詳細設計 M/UT 結合試験 総合試験 (受入試験) 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 詳細設計 受入試験 工程ごとの 工数に関する 指標（値はサンプル値） イメージ
© 2023 NTT DATA Corporation 32 プロジェクトをマネジメントする こうしてできたスケジュールをベースに全体の計画書や工程ごとの計画書を作成し、 プロジェクトを推進する。 各社で定められている標準的なプロジェクト管理手順や 「プロジェクトマネジメント知識体系ガイド」（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 詳細設計 受入試験
© 2023 NTT DATA Corporation 33 プロジェクトマネジメント・プロセス群と知識エリア 例えば、PMBOK®ではプロジェクトマネジメントのプロセス群と 知識に対する要求事項によって定義された知識エリアによって分類されている。 これらのマトリクスと、そのインプット・ツールと技法・アウトプットが定義されている。 統合管理 スコープ管理 スケジュール管理 コスト管理 品質管理 資源管理 コミュニケーション管理 リスク管理 調達管理 ステークホルダー管理 立ち上げ プロジェクト憲章の作成 ステークホルダーの特定 計画 プロジェクトマネジメント 計画書の作成 スコープ管理の計画 要求事項の収集 スコープの定義 WBSの作成 スケジュール管理の計画 アクティビティの定義 アクティビティの順序設定 アクティビティ所要期間の 見積り スケジュールの作成 コスト管理の計画 コストの見積り 予算の設定 品質管理の計画 資源管理の計画 アクティビティ資源の見積 り コミュニケーション管理の 計画 リスク管理の計画 リスクの特定 リスクの定性的分析 リスクの定量的分析 リスク対応の計画 調達管理の計画 ステークホルダーエンゲー ジメントの計画 実行 プロジェクト作業の指揮・ 管理 プロジェクト知識の管理 品質の管理 資源の獲得 チームの育成 チームの管理 コミュニケーションの管理 リスク対応策の実行 調達の実行 ステークホルダーエンゲー ジメントの管理 監視・コント ロール プロジェクト作業の監視・ コントロール 統合変更管理 スコープの妥当性確認 スコープのコントロール スケジュールのコントロー ル コストのコントロール 品質のコントロール 資源のコントロール コミュニケーションの監視 リスクの監視 調達のコントロール ステークホルダーエンゲー ジメントの監視 終結 プロジェクトやフェーズの 終結 知識エリア プロ ジェク トマネ ジメン ト・プロ セス群
© 2023 NTT DATA Corporation 34 いつも完全なウォーターフォールばかりではない 冒頭で「ハイブリッド・アプローチ」とした反復型や漸進型を取り入れるケースもある。
© 2023 NTT DATA Corporation 35 いつも完全なウォーターフォールばかりではない 冒頭で「ハイブリッド・アプローチ」とした反復型や漸進型を取り入れるケースもある。 • 途中で判明した追加仕様を取り組むケース 基本設計や詳細設計で気づいた/追加となった要件について影響範囲を判断し、 結合試験の途中で合流できるように計画する進め方
© 2023 NTT DATA Corporation 36 いつも完全なウォーターフォールばかりではない 冒頭で「ハイブリッド・アプローチ」とした反復型や漸進型を取り入れるケースもある。 • 途中で判明した追加仕様を取り組むケース • 最初からフェーズごとに機能を分割したイテレーション開発を行うケース 前フェーズの詳細設計が終わったタイミングでそのメンバーは次のフェーズの基本設計を行い、 製造は詳細設計を元にニアショア/オフショアを活用する進め方。
© 2023 NTT DATA Corporation 37 © 2023 NTT DATA Corporation 37 計画駆動型スクラムの流れ
© 2023 NTT DATA Corporation 38 計画駆動型スクラムの始まり：概略図 事業会社 企画部門担当者 ①新しいシステムを作りたいです。 開発費用の見積をお願いします。 要件はこんな感じです。 IT部門担当者
© 2023 NTT DATA Corporation 39 受託会社 計画駆動型スクラムの始まり：概略図 事業会社 企画部門担当者 ①新しいシステムを作りたいです。 開発費用の見積をお願いします。 要件はこんな感じです。 IT部門担当者 ②見積りお願い プロジェクトマネージャー
© 2023 NTT DATA Corporation 40 受託会社 計画駆動型スクラムの始まり：概略図 事業会社 企画部門担当者 ①新しいシステムを作りたいです。 開発費用の見積をお願いします。 要件はこんな感じです。 IT部門担当者 ②見積りお願い プロジェクトマネージャー ③承知しました！
© 2023 NTT DATA Corporation 41 受託会社 計画駆動型スクラムの始まり：概略図 事業会社 企画部門担当者 ①新しいシステムを作りたいです。 開発費用の見積をお願いします。 要件はこんな感じです。 IT部門担当者 ②見積りお願い プロジェクトマネージャー ③承知しました！ 開発者
© 2023 NTT DATA Corporation 42 計画駆動型スクラムの見積りイメージ 要件はユーザーストーリーマップを使って整理しました。 リリース１の範囲のみとリリース1～3全て対応した時の 費用と期間が概算で知りたいです。 事業会社PO
© 2023 NTT DATA Corporation 43 計画駆動型スクラムの見積りイメージ 要件はユーザーストーリーマップを使って整理しました。 リリース１の範囲のみとリリース1～3全て対応した時の 費用と期間が概算で知りたいです。 承知しました、対応します。 事業会社PO 受託会社 プロジェクトマネージャー
© 2023 NTT DATA Corporation 44 計画駆動型スクラムの見積りイメージ 要件はユーザーストーリーマップを使って整理しました。 リリース１の範囲のみとリリース1～3全て対応した時の 費用と期間が概算で知りたいです。 ユーザーストーリーの形式になっていますが、現状それ以上 の情報はないので、今の情報から相対見積りをTシャツサイ ズを使って（S/M/L）やりますね。 承知しました、対応します。 事業会社PO 受託会社 プロジェクトマネージャー 開発者
© 2023 NTT DATA Corporation 45 計画駆動型スクラムの見積りイメージ 要件はユーザーストーリーマップを使って整理しました。 リリース１の範囲のみとリリース1～3全て対応した時の 費用と期間が概算で知りたいです。 ユーザーストーリーの形式になっていますが、現状それ以上 の情報はないので、今の情報から相対見積りをTシャツサイ ズを使って（S/M/L）やりますね。 承知しました、対応します。 見積りました。 事業会社PO 受託会社 プロジェクトマネージャー 開発者 開発者
© 2023 NTT DATA Corporation 46 計画駆動型スクラムの見積りイメージ 見積りありがとう。 ポイントにするとSが3sp、Mが5sp、Lが8spぐらい？ 仮に今のチームで対応するなら 2週間のスプリントでベロシティ20ぐらいかな？ 受託会社 プロジェクトマネージャー
© 2023 NTT DATA Corporation 47 計画駆動型スクラムの見積りイメージ ポイントはそんなイメージです。 ベロシティもまぁそれぐらいじゃないですかね。 見積りありがとう。 ポイントにするとSが3sp、Mが5sp、Lが8spぐらい？ 仮に今のチームで対応するなら 2週間のスプリントでベロシティ20ぐらいかな？ 受託会社 プロジェクトマネージャー 開発者
© 2023 NTT DATA Corporation 48 計画駆動型スクラムの見積りイメージ ポイントはそんなイメージです。 ベロシティもまぁそれぐらいじゃないですかね。 見積りありがとう。 ポイントにするとSが3sp、Mが5sp、Lが8spぐらい？ 仮に今のチームで対応するなら 2週間のスプリントでベロシティ20ぐらいかな？ 了解。 リリースバーンダウンチャートにするとこんな感じかな。 リリース1～3の範囲全て対応してもスプリントは 10あれば作りきれそうだね。 受託会社 プロジェクトマネージャー 受託会社 プロジェクトマネージャー 開発者
© 2023 NTT DATA Corporation 49 受託会社 計画駆動型スクラムの始まり：概略図 事業会社 企画部門担当者 IT部門担当者 プロジェクトマネージャー ④見積りしました！ # ユーザーストーリー SP PBI_001 XXXとしてXXXをしたい 3 PBI_002 XXXとしてXXXをしたい 5 PBI_003 XXXとしてXXXをしたい 5 PBI_004 XXXとしてXXXをしたい 3 PBI_005 XXXとしてXXXをしたい 8 ・ ・ ・ ①新しいシステムを作りたいです。 開発費用の見積をお願いします。 要件はこんな感じです。 ②見積りお願い ③承知しました！ 開発者
© 2023 NTT DATA Corporation 50 受託会社 計画駆動型スクラムの始まり：概略図 事業会社 企画部門担当者 IT部門担当者 プロジェクトマネージャー ④見積りしました！ ⑤スコープ・予算・納期 について承認します。 プロジェクト開始して下さい。 決裁権者 # ユーザーストーリー SP PBI_001 XXXとしてXXXをしたい 3 PBI_002 XXXとしてXXXをしたい 5 PBI_003 XXXとしてXXXをしたい 5 PBI_004 XXXとしてXXXをしたい 3 PBI_005 XXXとしてXXXをしたい 8 ・ ・ ・ ①新しいシステムを作りたいです。 開発費用の見積をお願いします。 要件はこんな感じです。 ②見積りお願い ③承知しました！ 開発者
© 2023 NTT DATA Corporation 51 受託会社 計画駆動型スクラムの始まり：概略図 事業会社 企画部門担当者 IT部門担当者 プロジェクトマネージャー ④見積りしました！ ⑤スコープ・予算・納期 について承認します。 プロジェクト開始して下さい。 決裁権者 # ユーザーストーリー SP PBI_001 XXXとしてXXXをしたい 3 PBI_002 XXXとしてXXXをしたい 5 PBI_003 XXXとしてXXXをしたい 5 PBI_004 XXXとしてXXXをしたい 3 PBI_005 XXXとしてXXXをしたい 8 ・ ・ ・ ①新しいシステムを作りたいです。 開発費用の見積をお願いします。 要件はこんな感じです。 ②見積りお願い ③承知しました！ 開発者 初期の計画が変更できない 計画駆動型スクラム が始まる！！
© 2023 NTT DATA Corporation 52 そして計画駆動型スクラムが始まる こないだ見積もってもらったあのプロジェクト来月からやる ことになりました。 先方の役員会議で承認されて、ニュースリリースもされた みたい。スコープもリリース日も決まってるからよろしく！ 受託会社 プロジェクトマネージャー
© 2023 NTT DATA Corporation 53 そして計画駆動型スクラムが始まる えっ。。。マジですか。。。 概算って聞いたので約束したつもりはなかったんですけど・・・ こないだ見積もってもらったあのプロジェクト来月からやる ことになりました。 先方の役員会議で承認されて、ニュースリリースもされた みたい。スコープもリリース日も決まってるからよろしく！ 受託会社 プロジェクトマネージャー 開発者
© 2023 NTT DATA Corporation 54 そして計画駆動型スクラムが始まる えっ。。。マジですか。。。 概算って聞いたので約束したつもりはなかったんですけど・・・ まぁスクラムでやるって先方は言ってるから その辺りは現場でうまいことやってよ。 私は他のプロジェクトで忙しいから打ち合わせだけ出る よ。打ち合わせ設定しておいて。 受託会社 プロジェクトマネージャー 受託会社 プロジェクトマネージャー 開発者 こないだ見積もってもらったあのプロジェクト来月からやる ことになりました。 先方の役員会議で承認されて、ニュースリリースもされた みたい。スコープもリリース日も決まってるからよろしく！
© 2023 NTT DATA Corporation 55 荒ぶる四天王 この状況では太古の昔からプロジェクトを統治する奴らが破壊と混乱を引き起こすことになる。
© 2023 NTT DATA Corporation 56 荒ぶる四天王 この状況では太古の昔からプロジェクトを統治する奴らが破壊と混乱を引き起こすことになる。 出典：『アジャイルサムライ-達人開発者への道』(Jonathan Rasmusson(著),近藤 修平,角掛 拓未(翻訳),西村 直人,角谷 信太郎(監訳),オーム社,20011)
© 2023 NTT DATA Corporation 57 荒ぶる四天王 この状況では太古の昔からプロジェクトを統治する奴らが破壊と混乱を引き起こすことになる。 通常アジャイルでは時間・予算・品質は固定されたものとみなし、スコープを柔軟に扱うものだが、 計画駆動型スクラムではスコープをマネジメントする余地があまりにも少ない。 出典：『アジャイルサムライ-達人開発者への道』(Jonathan Rasmusson(著),近藤 修平,角掛 拓未(翻訳),西村 直人,角谷 信太郎(監訳),オーム社,20011)
© 2023 NTT DATA Corporation 58 これって、ウォータースクラムフォール？ 所謂「ウォータースクラムフォール」と呼ばれているものは計画駆動型スクラムに含まれると考える。 上記はあくまで一例だが、「企画・分析」や「要件定義」を経て 作るもののスコープや期限が決まっており、スプリントごとにフィードバックのサイクルが回せていない （その必要があまりない）という特徴がある。 Water-Scrum-Fallのイメージ図
© 2023 NTT DATA Corporation 59 © 2023 NTT DATA Corporation 59 計画駆動型スクラムの問題点
© 2023 NTT DATA Corporation 60 初期の見積りは正確ではない プロジェクトの進行に伴い見積りがどのように正確になっていくかを示した「不確実性のコーン」 にあるように初期コンセプト時点では見積りのバラつきが非常に大きい。 それにも関わらずプロジェクト開始時点の計画に従うことを強いられている。 出典：『ソフトウェア見積り 人月の暗黙知を解き明かす』(スティーブ マコネル(著),溝口 真理子, 田沢 恵,久手堅 憲之(訳),日経BP,2006) 図：一般的なプロジェクトのマイルストーンに基づく不確実性のコーン
© 2023 NTT DATA Corporation 61 計画駆動型スクラムで起きること 先程のような形で始まった計画駆動型のスクラムでは、 以下のような事象が起きてしまう可能性がある。
© 2023 NTT DATA Corporation 62 計画駆動型スクラムで起きること 先程のような形で始まった計画駆動型のスクラムでは、 以下のような事象が起きてしまう可能性がある。 1. 変えられないスコープ 2. ベロシティはPOやステークホルダーとの約束 3. 進捗が遅れたらキャッチアッププランを報告 4. 個々人をパフォーマンスで評価 5. スプリントゴールは立てられない 6. スウォーミングしない 7. ステークホルダーはスプリントレビューに興味がない 8. プロダクトバックログの優先度が決められない 9. アウトプットで評価される
© 2023 NTT DATA Corporation 63 計画駆動型スクラムで起きること 先程のような形で始まった計画駆動型のスクラムでは、 以下のような事象が起きてしまう可能性がある。 1. 変えられないスコープ 2. ベロシティはPOやステークホルダーとの約束 3. 進捗が遅れたらキャッチアッププランを報告 4. 個々人をパフォーマンスで評価 5. スプリントゴールは立てられない 6. スウォーミングしない 7. ステークホルダーはスプリントレビューに興味がない 8. プロダクトバックログの優先度が決められない 9. アウトプットで評価される ※以降で紹介する事象は私が経験したものや社内で聞いたものをベースに抽象化し、 多少の脚色を加えたフィクションです。
© 2023 NTT DATA Corporation 64 １．変えられないスコープ プロジェクト開始時には「機能一覧」や「画面一覧」といった設計書が作成されていてリリースまで に作らなければならない機能が決まっている。 # 処理名 予定スプリント 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 【機能一覧】 【画面一覧】 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。
© 2023 NTT DATA Corporation 65 １．変えられないスコープ プロジェクト開始時には「機能一覧」や「画面一覧」といった設計書が作成されていてリリースまで に作らなければならない機能が決まっている。 ユーザーストーリーマップは作成しているが、プロジェクト開始時からほとんど更新されることはない。 ユーザーストーリーマップの一番左にある「ログイン」や「サインアップ」から作成する。 # 処理名 予定スプリント 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 【処理一覧】 【画面一覧】 【ユーザーストーリーマップ】 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。
© 2023 NTT DATA Corporation 66 ２．ベロシティはPOやステークホルダーとの約束 当初想定のベロシティが出なければ、約束したスコープのリリースが難しくなるので何としてでもチー ムにベロシティを守らせる。 ストーリーポイントでの見積りがインフレ化してしまうのを避けるため、POやステークホルダーはストー リーポイントでの見積りに口を出す。 このPBIは5ポイントかな。 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。 開発者 事業会社PO 事業会社PO の上司
© 2023 NTT DATA Corporation 67 ２．ベロシティはPOやステークホルダーとの約束 当初想定のベロシティが出なければ、約束したスコープのリリースが難しくなるので何としてでもチー ムにベロシティを守らせる。 ストーリーポイントでの見積りがインフレ化してしまうのを避けるため、POやステークホルダーはストー リーポイントでの見積りに口を出す。 このPBIは5ポイントかな。 3ポイントで充分では？ ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。 開発者 事業会社PO 事業会社PO の上司
© 2023 NTT DATA Corporation 68 ２．ベロシティはPOやステークホルダーとの約束 当初想定のベロシティが出なければ、約束したスコープのリリースが難しくなるので何としてでもチー ムにベロシティを守らせる。 ストーリーポイントでの見積りがインフレ化してしまうのを避けるため、POやステークホルダーはストー リーポイントでの見積りに口を出す。 このPBIは5ポイントかな。 3ポイントで充分では？ 3ポイントにします… ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。 開発者 事業会社PO 事業会社PO の上司 開発者
© 2023 NTT DATA Corporation 69 ３．進捗が遅れたらキャッチアッププランを報告 POやスクラムマスターはデイリースクラムでスプリントの状況をバーンダウンチャートで確認し、遅延 している場合はどのようにキャッチアップするのかを開発者に報告させる。 このPBIのこの受け入れ条件の ロジックを実装するのに当初想 定より時間がかかっています。 事業会社PO 受託会社 スクラムマスター 開発者 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。
© 2023 NTT DATA Corporation 70 ３．進捗が遅れたらキャッチアッププランを報告 POやスクラムマスターはデイリースクラムでスプリントの状況をバーンダウンチャートで確認し、遅延 している場合はどのようにキャッチアップするのかを開発者に報告させる。 このPBIのこの受け入れ条件の ロジックを実装するのに当初想 定より時間がかかっています。 事業会社PO 受託会社 スクラムマスター このままだと全部終わらないと思 いますが 開発者 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。
© 2023 NTT DATA Corporation 71 ３．進捗が遅れたらキャッチアッププランを報告 POやスクラムマスターはデイリースクラムでスプリントの状況をバーンダウンチャートで確認し、遅延 している場合はどのようにキャッチアップするのかを開発者に報告させる。 このPBIのこの受け入れ条件の ロジックを実装するのに当初想 定より時間がかかっています。 キャッチアップのため、このタス クはBさんと交代します。 また当初予定していたリファク タリングを後回しにします 事業会社PO 受託会社 スクラムマスター このままだと全部終わらないと思 いますが 開発者 開発者 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。
© 2023 NTT DATA Corporation 72 ４．個々人をパフォーマンスで評価 スプリントごとに開発者ひとりひとりが何時間分のタスク（スプリントバックログ）を消化しているかを 集計し、パフォーマンスが低いメンバーには改善を要請。 他のメンバーと比べてEさんのパフォーマン スが悪いようです。 改善策を検討してください。 スプリント4実績 対象者 タスク消化時間 Aさん 40時間 Bさん 45時間 Cさん 42時間 Dさん 40時間 Eさん 32時間 Fさん 38時間 事業会社PO 事業会社PO の上司 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。
© 2023 NTT DATA Corporation 73 ４．個々人をパフォーマンスで評価 スプリントごとに開発者ひとりひとりが何時間分のタスク（スプリントバックログ）を消化しているかを 集計し、パフォーマンスが低いメンバーには改善を要請。 他のメンバーと比べてEさんのパフォーマン スが悪いようです。 改善策を検討してください。 はい… 検討します スプリント4実績 対象者 タスク消化時間 Aさん 40時間 Bさん 45時間 Cさん 42時間 Dさん 40時間 Eさん 32時間 Fさん 38時間 事業会社PO 事業会社PO の上司 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。 受託会社 スクラムマスター
© 2023 NTT DATA Corporation 74 ５．スプリントゴールは立てられない スプリントバックログには、透明性と集中を高める情報を提供する「確約（コミットメント）」として スプリントゴールが存在しており、これにより進捗を測定するものとスクラムガイドに記載されている。 しかし、計画駆動型スクラムでは、最初に検討した全てのバックログを消化する必要があるため、 スプリントゴールは毎回「選択した全てのプロダクトバックログアイテムが完了すること。」になる。 今回のスプリントも「選択した全てのプロダク トバックログアイテムが完了すること」がスプリ ントゴールです。 事業会社PO 開発者 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。
© 2023 NTT DATA Corporation 75 ５．スプリントゴールは立てられない スプリントバックログには、透明性と集中を高める情報を提供する「確約（コミットメント）」として スプリントゴールが存在しており、これにより進捗を測定するものとスクラムガイドに記載されている。 しかし、計画駆動型スクラムでは、最初に検討した全てのバックログを消化する必要があるため、 スプリントゴールは毎回「選択した全てのプロダクトバックログアイテムが完了すること。」になる。 今回のスプリントも「選択した全てのプロダク トバックログアイテムが完了すること」がスプリ ントゴールです。 はい… （スプリントゴールって何の意味があるんだ） 事業会社PO 開発者 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。
© 2023 NTT DATA Corporation 76 ６．スウォーミングしない 1つのSprintで優先度の高い（スプリントゴールの達成に直結する）プロダクトバックログアイテム を確実に終わらせることよりも、定められた期間内に全てのプロダクトバックログ完了させるために、 リソース効率を優先する。 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。
© 2023 NTT DATA Corporation 77 ６．スウォーミングしない 1つのSprintで優先度の高い（スプリントゴールの達成に直結する）プロダクトバックログアイテム を確実に終わらせることよりも、定められた期間内に全てのプロダクトバックログ完了させるために、 リソース効率を優先する。 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。
© 2023 NTT DATA Corporation 78 ６．スウォーミングしない 1つのSprintで優先度の高い（スプリントゴールの達成に直結する）プロダクトバックログアイテム を確実に終わらせることよりも、定められた期間内に全てのプロダクトバックログ完了させるために、 リソース効率を優先する。 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。
© 2023 NTT DATA Corporation 79 ６．スウォーミングしない 1つのSprintで優先度の高い（スプリントゴールの達成に直結する）プロダクトバックログアイテム を確実に終わらせることよりも、定められた期間内に全てのプロダクトバックログ完了させるために、 リソース効率を優先する。 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。
© 2023 NTT DATA Corporation 80 ６．スウォーミングしない 1つのSprintで優先度の高い（スプリントゴールの達成に直結する）プロダクトバックログアイテム を確実に終わらせることよりも、定められた期間内に全てのプロダクトバックログ完了させるために、 リソース効率を優先する。 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。
© 2023 NTT DATA Corporation 81 ６．スウォーミングしない 1つのSprintで優先度の高い（スプリントゴールの達成に直結する）プロダクトバックログアイテム を確実に終わらせることよりも、定められた期間内に全てのプロダクトバックログ完了させるために、 リソース効率を優先する。 仕掛中のタスクが増えても 1スプリントで完了するバックログの数より 長期的にタスクが多く完了することを優先 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。
© 2023 NTT DATA Corporation 82 ７．スプリントレビューに興味がない 今回のスプリントのインクリメントは・・・ スクラムチーム ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。 関連するステークホルダーに声をかけ、スプリントレビューに出席してもらうも、 「全部機能が揃って商用リリースが出来る状態になったらまとめて確認するから」と インクリメントに興味を持ってもらえない。
© 2023 NTT DATA Corporation 83 ７．スプリントレビューに興味がない 関連するステークホルダーに声をかけ、スプリントレビューに出席してもらうも、 「全部機能が揃って商用リリースが出来る状態になったらまとめて確認するから」と インクリメントに興味を持ってもらえない。 デザイナーさんのデザイン通りだよね。 大丈夫大丈夫この調子で期限までに全部 作ってくれたら問題ないから。 今回のスプリントのインクリメントは・・・ 事業会社PO の上司 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。 スクラムチーム
© 2023 NTT DATA Corporation 84 ７．スプリントレビューに興味がない デザイナーさんのデザイン通りだよね。 大丈夫大丈夫この調子で期限までに全部 作ってくれたら問題ないから。 今回のスプリントのインクリメントは・・・ はい… 事業会社PO の上司 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。 関連するステークホルダーに声をかけ、スプリントレビューに出席してもらうも、 「全部機能が揃って商用リリースが出来る状態になったらまとめて確認するから」と インクリメントに興味を持ってもらえない。 スクラムチーム スクラムチーム
© 2023 NTT DATA Corporation 85 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。 ８．プロダクトバックログの優先度が決められない バックログを分割し、より優先度が高いものを先に優先度が低そうなものは後にという提案や、 技術的負債を解消するためのリファクタリングを実施したいという話しをしても、 プロダクトオーナーはすでに作られたバックログの詳細を決める権限しか持っていない。 チームとして前倒しでプロダクトバックログを消化しないと新しいプロダクトバックログは認められない。 バックログ分割してこの部分は簡易に実装できる ので先に対応したいです。 この部分は本当にエンドユーザに重要ですか？優 先度下げてもいいと思うのですが。 開発者
© 2023 NTT DATA Corporation 86 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。 ８．プロダクトバックログの優先度が決められない こんな機能があったらエンドユーザーはもっと使いや すくなると思うのですがどうでしょう？ バックログ分割してこの部分は簡易に実装できる ので先に対応したいです。 この部分は本当にエンドユーザに重要ですか？優 先度下げてもいいと思うのですが。 開発者 バックログを分割し、より優先度が高いものを先に優先度が低そうなものは後にという提案や、 技術的負債を解消するためのリファクタリングを実施したいという話しをしても、 プロダクトオーナーはすでに作られたバックログの詳細を決める権限しか持っていない。 チームとして前倒しでプロダクトバックログを消化しないと新しいプロダクトバックログは認められない。
© 2023 NTT DATA Corporation 87 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。 ８．プロダクトバックログの優先度が決められない こんな機能があったらエンドユーザーはもっと使いや すくなると思うのですがどうでしょう？ バックログ分割してこの部分は簡易に実装できる ので先に対応したいです。 この部分は本当にエンドユーザに重要ですか？優 先度下げてもいいと思うのですが。 決まっている部分は作らないと… 追加分は当初計画から前倒しで進まないと判 断できないので、当初計画通り進めて下さい。 開発者 事業会社PO バックログを分割し、より優先度が高いものを先に優先度が低そうなものは後にという提案や、 技術的負債を解消するためのリファクタリングを実施したいという話しをしても、 プロダクトオーナーはすでに作られたバックログの詳細を決める権限しか持っていない。 チームとして前倒しでプロダクトバックログを消化しないと新しいプロダクトバックログは認められない。
© 2023 NTT DATA Corporation 88 ９．アウトプットで評価される 最終的にチームは当初計画通りにプロダクトバックログを消化できたかどうかで評価される。 プロダクトのアウトカムの測定は行われない。 計画通りにプロダクトバックログを消化できたチームは好事例として社内で共有され、 そしてまた次の計画駆動型スクラムが始まる。 当初計画より1スプリント追加で必要にはなった が、概ねオンスケだな。 お疲れ様。A評価だ。 事業会社PO の上司 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。
© 2023 NTT DATA Corporation 89 ９．アウトプットで評価される 最終的にチームは当初計画通りにプロダクトバックログを消化できたかどうかで評価される。 プロダクトのアウトカムの測定は行われない。 計画通りにプロダクトバックログを消化できたチームは好事例として社内で共有され、 そしてまた次の計画駆動型スクラムが始まる。 当初計画より1スプリント追加で必要にはなった が、概ねオンスケだな。 お疲れ様。A評価だ。 ありがとうございます。 （いい評価を貰えたのは嬉しいけど、アジャイ ルってこれでいいんだっけ。。。） 事業会社PO の上司 開発者 ※この事象は実際の経験をもとに抽象化し、 多少の脚色を加えたフィクションです。
© 2023 NTT DATA Corporation 90 計画駆動型スクラムのスクラムチームはどうなるか
© 2023 NTT DATA Corporation 91 計画駆動型スクラムのスクラムチームはどうなるか • メンバーはどんどん疲弊していく
© 2023 NTT DATA Corporation 92 計画駆動型スクラムのスクラムチームはどうなるか • メンバーはどんどん疲弊していく • チーム内での信頼関係はなく、各自が元々得意だったタスクを淡々とこなす
© 2023 NTT DATA Corporation 93 計画駆動型スクラムのスクラムチームはどうなるか • メンバーはどんどん疲弊していく • チーム内での信頼関係はなく、各自が元々得意だったタスクを淡々とこなす • 開発者はよいプロダクトとは何かを考えることをやめ、フィーチャーファクトリーになってしまう
© 2023 NTT DATA Corporation 94 計画駆動型スクラムのスクラムチームはどうなるか • メンバーはどんどん疲弊していく • チーム内での信頼関係はなく、各自が元々得意だったタスクを淡々とこなす • 開発者はよいプロダクトとは何かを考えることをやめ、フィーチャーファクトリーになってしまう • レトロスペクティブには価値を見出せずやらなくなる（その時間でタスクを消化する。）
© 2023 NTT DATA Corporation 95 計画駆動型スクラムのスクラムチームはどうなるか • メンバーはどんどん疲弊していく • チーム内での信頼関係はなく、各自が元々得意だったタスクを淡々とこなす • 開発者はよいプロダクトとは何かを考えることをやめ、フィーチャーファクトリーになってしまう • レトロスペクティブには価値を見出せずやらなくなる（その時間でタスクを消化する。） • 作る範囲が決まっているのでシンプルな設計（YAGNI原則）よりも今起票されている全ての PBIを満たす設計を考え、コードの保守性も後回しに
© 2023 NTT DATA Corporation 96 計画駆動型スクラムのスクラムチームはどうなるか • メンバーはどんどん疲弊していく • チーム内での信頼関係はなく、各自が元々得意だったタスクを淡々とこなす • 開発者はよいプロダクトとは何かを考えることをやめ、フィーチャーファクトリーになってしまう • レトロスペクティブには価値を見出せずやらなくなる（その時間でタスクを消化する。） • 作る範囲が決まっているのでシンプルな設計（YAGNI原則）よりも今起票されている全ての PBIを満たす設計を考え、コードの保守性も後回しに • 最終的にはスクラムは効率が悪いので、決まっている分は全てまとめて設計/実装/テストさせ てくれという話しになる
© 2023 NTT DATA Corporation 97 © 2023 NTT DATA Corporation 97 第一部 計画駆動型スクラムとは ー完ー
© 2023 NTT DATA Corporation 98 第二部へ続く 絵：ブラックジャックによろしく 佐藤秀峰
© 2023 NTT DATA Corporation 99 第二部へ続く テ イ ラ ー 主 義 の ま ま だ 絵：ブラックジャックによろしく 佐藤秀峰
© 2023 NTT DATA Corporation 100 第二部へ続く テ イ ラ ー 主 義 の ま ま だ ア ジ ャ イ ル は ・ ・ ・ ・ 柔 軟 性 が 高 く 、 コ ミ ュ ニ ケ ー シ ョ ン と フ ィ ー ド バ ッ ク を 重 視 す る の で は な い の か ア ウ ト カ ム の 事 な ん て 考 え て な い じ ゃ な い か ・ ・ ・ 絵：ブラックジャックによろしく 佐藤秀峰