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
540
【Findy】「正しく」失敗できる チームの作り方 〜リアルな事例から紐解く失敗を恐れない組織とは〜 / A team that can fail correctly by findy
i35_267
7
1.6k
技術負債の「予兆検知」と「状況異変」のススメ / 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
29
21k
「開発生産性」はエンジニア”だけ” のモノではなくなった? / "Development productivity" is no longer just for engineers?
i35_267
11
2.8k
開発生産性の現在地点~エンジニアリングが及ぼす多角的視点 / Current status of development productivity
i35_267
69
27k
開発生産性の低下による、事業の失敗はなぜ起こるのか / 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
【5分でわかる】セーフィー エンジニア向け会社紹介
safie_recruit
0
24k
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
17k
積み上げられた技術資産と向き合いながら、プロダクトの信頼性をどう守るか
plaidtech
PRO
0
210
令和トラベルQAのAI活用
seigaitakahiro
0
480
SmartHRの複数のチームにおけるMCPサーバーの活用事例と課題
yukisnow1823
2
1.1k
他チームへ越境したら、生データ提供ソリューションのクエリ費用95%削減へ繋がった話 / Cross-Team Impact: 95% Off Raw Data Query Costs
yamamotoyuta
0
170
2025advance01
minamizaki
0
120
ローカル環境でAIを動かそう!
falken
PRO
1
150
Contract One Dev Group 紹介資料
sansan33
PRO
0
5.9k
AIの電力問題を概観する
rmaruy
1
200
超簡単!RAGアプリケーション構築術
oracle4engineer
PRO
0
110
オープンソースのハードウェアのコンテストに参加している話
iotengineer22
0
450
Featured
See All Featured
The Power of CSS Pseudo Elements
geoffreycrofte
76
5.8k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
830
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
331
21k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.8k
Designing for humans not robots
tammielis
253
25k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
45
7.3k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.2k
How to train your dragon (web standard)
notwaldorf
92
6k
Git: the NoSQL Database
bkeepers
PRO
430
65k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
26k
Bash Introduction
62gerente
614
210k
Measuring & Analyzing Core Web Vitals
bluesmoon
7
460
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