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
400
【Findy】「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly by findy
i35_267
5
1.4k
技術負債の「予兆検知」と「状況異変」のススメ / Technology Dept
i35_267
2
1.2k
技術負債による事業の失敗はなぜ起こるのか / Why do business failures due to technical debt occur?
i35_267
4
2.3k
「開発生産性を上げる改善」って儲かるの?に答えられるようにする / 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.6k
開発生産性の多角的接点〜1,000名のクリエイター組織 × 開発生産性〜 / Multifaceted touchpoints of development productivity
i35_267
5
1.6k
Other Decks in Technology
See All in Technology
スケールアップ企業のQA組織のバリューを最大限に引き出すための取り組み
tarappo
4
900
初めてのPostgreSQLメジャーバージョンアップ
kkato1
0
390
パスキーでのログインを 実装してみよう!
hibiki_cube
0
590
銀行でDevOpsを進める理由と実践例 / 20250317 Masaki Iwama
shift_evolve
1
100
Road to SRE NEXT@仙台 IVRyの組織の形とSLO運用の現状
abnoumaru
0
380
ペアプログラミングにQAが加わった!職能を超えたモブプログラミングの事例と学び
tonionagauzzi
1
140
Amazon EKS Auto ModeでKubernetesの運用をシンプルにする
sshota0809
0
110
3/26 クラウド食堂LT #2 GenU案件を通して学んだ教訓 登壇資料
ymae
1
200
空が堕ち、大地が割れ、海が涸れた日~もしも愛用しているフレームワークが開発停止したら?~ #phperkaigi 2025
77web
2
990
React Server Componentは 何を解決し何を解決しないのか / What do React Server Components solve, and what do they not solve?
kaminashi
6
1.2k
Why Go?
xpmatteo
0
130
チームビルディング「脅威モデリング」ワークショップ
koheiyoshikawa
0
130
Featured
See All Featured
RailsConf 2023
tenderlove
29
1k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
31
4.7k
Rails Girls Zürich Keynote
gr2m
94
13k
How GitHub (no longer) Works
holman
314
140k
What's in a price? How to price your products and services
michaelherold
245
12k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Making the Leap to Tech Lead
cromwellryan
133
9.2k
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
135
33k
KATA
mclloyd
29
14k
Optimizing for Happiness
mojombo
377
70k
Designing for humans not robots
tammielis
250
25k
Into the Great Unknown - MozCon
thekraken
36
1.7k
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