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.4k
見積もりをしない。
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 / 石垣雅人
【Forkwell】「正しく」失敗できるチームを作る──現場のリーダーのための恐怖と不安を乗り越える技術 - FL#83 / A team that can fail correctly by forkwell
i35_267
4
470
【Findy】「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly by findy
i35_267
6
1.5k
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
i35_267
2
1.3k
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
5
2.4k
「開発生産性を上げる改善」って儲かるの?に答えられるようにする / Is development productivity profitable?
i35_267
28
21k
「開発生産性」はエンジニア”だけ” のモノではなくなった? / "Development productivity" is no longer just for engineers?
i35_267
9
2.8k
開発生産性の現在地点~エンジニアリングが及ぼす多角的視点 / Current status of development productivity
i35_267
69
26k
開発生産性の低下による、事業の失敗はなぜ起こるのか / ProductivityPitfalls
i35_267
6
1.6k
開発生産性の多角的接点〜1,000名のクリエイター組織 × 開発生産性〜 / Multifaceted touchpoints of development productivity
i35_267
5
1.7k
Other Decks in Technology
See All in Technology
Automatically generating types by running tests
sinsoku
2
3.5k
React ABC Questions
hirotomoyamada
0
520
品質文化を支える小さいクロスファンクショナルなチーム / Cross-functional teams fostering quality culture
toma_sm
0
130
「経験の点」の位置を意識したキャリア形成 / Career development with an awareness of the “point of experience” position
pauli
4
110
Would you THINK such a demonstration interesting ?
shumpei3
1
230
YOLOv10~v12
tenten0727
4
970
Bazel for Ruby (RubyKaigi 2025)
p0deje
0
110
生成AIのユースケースをとにかく集めてまるっと学ぶ!/ all about generative ai usecases
gakumura
2
170
新卒エンジニアがCICDをモダナイズしてみた話
akashi_sn
2
250
Notion x ポストモーテムで広げる組織の学び / Notion x Postmortem
isaoshimizu
1
120
バックオフィス向け toB SaaS バクラクにおけるレコメンド技術活用 / recommender-systems-in-layerx-bakuraku
yuya4
6
560
PagerDuty×ポストモーテムで築く障害対応文化/Building a culture of incident response with PagerDuty and postmortems
aeonpeople
2
360
Featured
See All Featured
Practical Orchestrator
shlominoach
186
11k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
13
1.4k
Building an army of robots
kneath
304
45k
Writing Fast Ruby
sferik
628
61k
Fashionably flexible responsive web design (full day workshop)
malarkey
407
66k
GraphQLの誤解/rethinking-graphql
sonatard
71
10k
How To Stay Up To Date on Web Technology
chriscoyier
790
250k
KATA
mclloyd
29
14k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
23
2.6k
We Have a Design System, Now What?
morganepeng
52
7.5k
Build your cross-platform service in a week with App Engine
jlugia
229
18k
Site-Speed That Sticks
csswizardry
5
500
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