Slide 1

Slide 1 text

Copyright © 2019- Sekai Co., Ltd. All Rights Reserved. https://daipresents.com/service/ Dai Fujihara, Agile Coach なぜ自社ではスクラムがうまくいかないのか? アジャイルコーチと考える スクラムのアンチパターン

Slide 2

Slide 2 text

Dai Fujihara ○ 2003年〜: 新卒でSIer、Javaエンジニア ○ 2008年〜: 楽天、エンジニアリングマネージャ (EM)、アジャイルコーチ ○ 2011年: 認定スクラムプロダクトオーナー取得 ○ 2013年: 『アジャイル開発とスクラム』寄稿、『リーン開 発の現場』翻訳 ○ 2017年〜: メルカリ、EM、SET ○ 2019年〜: 独立、アジャイルコーチ、アジャイル開発 導入・運用改善、アジャイルQA組織支援、テスト自動 化支援、技術顧問、CTO・EM・エンジニアのコーチン グ ○ 2022年: 国際コーチ連盟 アソシエイト認定コーチ ACC取得 ○ Web: https://daipresents.com/service/ 株式会社せかい 代表取締役 @daipresents

Slide 3

Slide 3 text

アジャイル開発の用語 ○ チーム ● 自己組織化された職能横断型チーム ○ スプリント・イテレーション(短い期間) ● これを繰り返し、終了とともにリリースしていく ○ スクラムマスター ● スクラムを推進する人

Slide 4

Slide 4 text

アジャイル開発の用語 ○ ユーザーストーリー(やること) ● やりたいこと。チケットなどで管理され、誰でも理解できる言語で書か れている。バックログアイテムと呼ばれる場合もある。 ○ バックログ(やることリスト) ● 優先順位付けされたユーザーストーリーのリスト。プロダクトバックログ からスプリントバックログを切り出して開発していく ○ ストーリーポイント ● ユーザーストーリーを相対的にポイント形式で見積もる方法。1スプリン トで消化可能なストーリーポイントをベロシティ(やれる量)と呼ぶ。

Slide 5

Slide 5 text

アジャイル開発・スクラムで 実現したいこと

Slide 6

Slide 6 text

アジャイル開発・スクラムで実現したいことを ひとことでいうと ● 顧客満足度の向上: ○ 顧客のフィードバックをはやく得る ○ そのために短いリリースを繰り返す ● 柔軟性と適応力: ○ スプリント計画で柔軟な計画づくりが可能 ○ バックログの管理で優先順位の変更に迅速に対応 ○ ふりかえりでチームを改善 ○ スプリントレビューでプロダクトを改善 ● 透明性: ○ 朝礼による共有と再計画 ○ ふりかえりやスプリントレビューで共有と改善 ● 自己組織化: ○ 作るだけではなく計画づくりやレビューにも参加してすべてを自分ごとにして意思決定する ● リスク軽減: ○ 小さなスプリントごとのリリースはリスクも小さくする

Slide 7

Slide 7 text

7 アンチパターン

Slide 8

Slide 8 text

8 そもそも アジャイル開発は ”遅い”

Slide 9

Slide 9 text

メンバーがそれぞれ並行作業 ● 複数タスクが並行で進む点は効率が良い ● サイロ化しやすいので助け合いにくい ● スクラムイベントで集まる意味が薄まる

Slide 10

Slide 10 text

「効率が良い」とは何か? Photo by shun idota and shawnanggg on Unsplash リソース効率 フロー効率

Slide 11

Slide 11 text

予算と期限がある とうまくいかない

Slide 12

Slide 12 text

予算と期限があるとうまくいかない ● 予算と期限があるというのは「見通しが立 つ(予測できる)」ということ ● 予測は従来型が得意 ● 適応が必要ならアジャイル開発が得意

Slide 13

Slide 13 text

アジャイルなスプリント計画づくり Photo by Karsten Winegeart on Unsplash

Slide 14

Slide 14 text

アジャイルなスプリント計画づくり Photo by Karsten Winegeart on Unsplash ○ アジャイルな見積もり ● タイムボックスに合わせて最 高の商品を選び見積もる ○ アジャイルな計画づくり ● タイムボックス内でできる量を もとに、積み上げたがで計画 を立てる ○ 従来型の見積もり ● 欲しい機能を選んでもらい、全機 能を見積もって合計する ○ 従来型の計画づくり ● 合計した見積もりから逆算して計 画を立てる ● アサインする人数で計画を調整で きる 機能ありきで期間を見積もる 機能と期間が重要 期間ありきで機能を見積もる 計画の柔軟性が重要

Slide 15

Slide 15 text

スクラムイベントをやるだけ ではうまくいかない

Slide 16

Slide 16 text

スクラムイベントをやるだけではうまくいかない ● スクラムはやれば成功するフレームワーク ではない ● 最低限、何のために何をしているかの理解 は必要(これがないと改善できない) ● 60点は取れるけど90点以上にするのが難 しい

Slide 17

Slide 17 text

プロマネのいるチーム はうまくいかない

Slide 18

Slide 18 text

プロマネがいるチームはうまくいかない ● 従来型 ○ 管理重視 ○ プロジェクトマネージャ ● アジャイル開発 ○ 自律性重視 ○ チームワーク

Slide 19

Slide 19 text

生産性という言葉がよく出てくる とうまくいかない

Slide 20

Slide 20 text

生産性という言葉がよくでてくる現場はうまくいかない ● 生産性も従来型とアジャイル開発にわ かれる ● 従来型は出力量が重要 ● アジャイル開発は成果量が重要

Slide 21

Slide 21 text

予備のスライド

Slide 22

Slide 22 text

スプリントごとにリリースできない

Slide 23

Slide 23 text

スプリントごとにリリースできないとうまくいかない ● アジャイル開発は変化に対応するため、と にかくフィードバックがはやくほしい ● アーキテクチャや組織構造の影響で頻繁 なリリースができない ● 適切なスプリントサイズを選べていない

Slide 24

Slide 24 text

スクラムマスターがずっとファシリテーション しているとうまくいかない

Slide 25

Slide 25 text

スクラムマスターがずっとファシリテーションしているとうまく いかない ● 従来型 ○ 管理体制 ● アジャイル開発 ○ サーバントリーダーシップと自己組織化