Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
見積もりをしない。
Search
Masato Ishigaki / 石垣雅人
July 27, 2023
Technology
4
1.3k
見積もりをしない。
2023/7/27 DMM石垣氏に聞く 見積もりをしない、コミュニケーション負荷を減らすスクラムの実践
https://offers.connpass.com/event/289979/
Masato Ishigaki / 石垣雅人
July 27, 2023
Tweet
Share
More Decks by Masato Ishigaki / 石垣雅人
See All by Masato Ishigaki / 石垣雅人
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
i35_267
1
1.1k
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
4
2.2k
「開発生産性を上げる改善」って儲かるの?に答えられるようにする / Is development productivity profitable?
i35_267
28
20k
「開発生産性」はエンジニア”だけ” のモノではなくなった? / "Development productivity" is no longer just for engineers?
i35_267
9
2.7k
開発生産性の現在地点~エンジニアリングが及ぼす多角的視点 / Current status of development productivity
i35_267
68
26k
開発生産性の低下による、事業の失敗はなぜ起こるのか / ProductivityPitfalls
i35_267
6
1.5k
開発生産性の多角的接点〜1,000名のクリエイター組織 × 開発生産性〜 / Multifaceted touchpoints of development productivity
i35_267
5
1.6k
内製化で強化させる、事業のスケーラビリティーとエンジニアの成長戦略 / insourcing
i35_267
2
400
The Metrics Key_ Connecting Product, System, Team
i35_267
4
4.5k
Other Decks in Technology
See All in Technology
室長と気ままに学ぶマイクロソフトのビジネスアプリケーションとビジネスプロセス
ryoheig0405
0
360
7日間でハッキングをはじめる本をはじめてみませんか?_ITエンジニア本大賞2025
nomizone
2
1.8k
Moved to https://speakerdeck.com/toshihue/presales-engineer-career-bridging-tech-biz-ja
toshihue
2
740
プロセス改善による品質向上事例
tomasagi
2
2.5k
オブザーバビリティの観点でみるAWS / AWS from observability perspective
ymotongpoo
8
1.5k
関東Kaggler会LT: 人狼コンペとLLM量子化について
nejumi
3
580
バックエンドエンジニアのためのフロントエンド入門 #devsumiC
panda_program
18
7.4k
抽象化をするということ - 具体と抽象の往復を身につける / Abstraction and concretization
soudai
13
2.6k
アジャイル開発とスクラム
araihara
0
170
転生CISOサバイバル・ガイド / CISO Career Transition Survival Guide
kanny
3
970
Nekko Cloud、 これまでとこれから ~学生サークルが作る、 小さなクラウド
logica0419
2
960
Goで作って学ぶWebSocket
ryuichi1208
0
120
Featured
See All Featured
The Cult of Friendly URLs
andyhume
78
6.2k
Statistics for Hackers
jakevdp
797
220k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Designing on Purpose - Digital PM Summit 2013
jponch
117
7.1k
How to Think Like a Performance Engineer
csswizardry
22
1.3k
RailsConf 2023
tenderlove
29
1k
Testing 201, or: Great Expectations
jmmastey
42
7.2k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
366
25k
Music & Morning Musume
bryan
46
6.3k
The Invisible Side of Design
smashingmag
299
50k
Build The Right Thing And Hit Your Dates
maggiecrowley
34
2.5k
Practical Orchestrator
shlominoach
186
10k
Transcript
見積もりをしない。 1 Masato Ishigaki July 27, 2023
2 About me 石垣 雅人 合同会社 DMM.com プラットフォーム事業本部 部長 /
VPoE室 / アルファ室 ・領域 : 事業戦略・予算管理・ PdM・PM・EM ・著 : 『DMMを支えるデータ駆動戦略』(マイナビ出版 ,2020) ・連載 : 『群知能から紐解く、スケールする “組織“の作り方』(NewsPicks) ・連載 : 『スモールチームが武器になる時代へ』( ProductZine) @i35_267 @i35_267 @i35_267
3 - 見積もりの目的と効果 - 3つの見積もり領域 - 見積もりがいらない状態 Outline
4 - 見積もりの目的と効果 - 3つの見積もり領域 - 見積もりがいらない状態 Outline
5 見積もりの目的と効果 見積もりをする = 何を獲得するのか、何を失うのかを問い続ける 何も得るものがなければ、見積もりはいらない by マーティンファウラー https://martinfowler.com/bliki/PurposeOfEstimation.html
6 見積もりの目的と効果 獲得するべきもの - 意思決定をするために見積もりを行う - 見積もる = ブラックボックスを解きほぐし、見える化する。相互関係や規模感 -
アイテム同士の前後関係によるプライオリティーの判定 - 信頼を積み上げていく 失うもの - 時間 - 人数 x 見積もる時間。10人 x 1h x 月4回 = 40h(月) 5人日の価値 - 信頼を失う - 不確実性コーン問題 - 各レイヤーで見ている観点が違う。正確性を求めていないのが注意
7 重み?複数チーム絡んでいるし、 ロードマップ作りたいから工数(人月)でほしい スクラムチーム ストーリーポイントで見積もっている プロダクトチーム PM・PdM 経営・ビジネス ポイントを知りたい 工数を知りたい
金額を知りたい 事業PLへの影響、 企画に対してのコスト計算をしたい 視点の違いと変換コスト
8 - 見積もりの目的と効果 - 3つの見積もり領域 - 見積もりがいらない状態 Outline
ボトムアップ 9 チーム 見積もりの種類 個 相対的 絶対的 ① ② ③
類推見積もり ストーリー ポイント 三点見積もり No-Estimates 時間見積もり 係数見積もり (パラメトリック)
1 0 3つの見積もり領域 ① ストーリーポイント見積もり - 相対比較であること(サンプル数を多く作り、暗黙知を無くしていく経験学習) - 規模を見積もること(not 作業量)
- 個のスキ単位ではなく、チーム単位であること 5 1 3 2 3 2 3 ? チームの経験値 経験値から見積もる フィボナッチ数列
1 1 3つの見積もり領域 ② 時間見積もり - 時間で見積もること - チーム単位ではなく、個が中心の考え 作業A
: 10人日 作業B : 3人日 作業C : 7人日 1人月 ・類推見積もり・・・過去プロジェクトの学習 ・係数見積もり・・・特定の係数による重み ・ボトムアップ・・・細分化したタスクの積み上げ ・三点見積もり・・・(悲観値+4 ×最可能値+楽観値)÷6 Ex. ボトムアップ見積もり
1 2 3つの見積もり領域 ③ No-Estimates - 「タスクに見積もりをつける」のではなく「見積もりにタスクを切る粒度を合わせる」 - プランニングの長時間問題の解決。成熟してくるとこのフェーズに来れる -
チームが成熟していない状態で導入しても、統一された暗黙知がないため安定せず 3 5 1 3 2 3 2 3 チームの経験値 3 PBL 3 3 3 3 粒度を決める
1 3 - 見積もりの目的と効果 - 3つの見積もり領域 - 見積もりがいらない状態 Outline
14 見積もりの考え方は、チームのフェーズに比例する - 見積もり方法は、チームの自己組織化に比例する - そもそも、自己組織化したチームは見積もり方法はどうでも良くなる。 - 自己組織化 = 暗黙知が共有され、パターン・ランゲージが作られている状態
- 一番早い見積もりは、No-Estimatesや類推モデルの2つ。 - 1.5h → 15mぐらい。前後でベロシティーが安定していることが大事 - 一方、ゴリゴリに少数精鋭で進めているスタートアップは見積もりをしていない - ただし、一歩チームの外にでれば別のことが多い。工数算出などは必要となるケースも。 - とはいえ、類推モデルでサンプル数をどんどん貯めていけばなくせるかもしれない 見積もりがいらない状態
15 見積もり移行フェーズ 見積もりがいらない状態 形成期 (forming) 混乱期 (stoming) 統一期 (norming) 機能期
(performing) ・ストーリーポイント ・時間見積もり ・No-Estimates
1 6 - 見積もりの目的と効果 - 3つの見積もり領域 - 見積もりがいらない状態 Outline