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
見積もり/agile-estimation
Search
Atsushi Harada
November 07, 2019
Technology
0
72k
見積もり/agile-estimation
Atsushi Harada
November 07, 2019
Tweet
Share
More Decks by Atsushi Harada
See All by Atsushi Harada
モジャイリーンな事業開発/mojilean-business-development
harada4atsushi
0
390
スクラムとモジャイル/scrum-and-mojile
harada4atsushi
0
7.9k
リーン・スタートアップとMVP/lean-startup-mvp
harada4atsushi
0
26k
リーンキャンバスの作り方/how-to-make-lean-canvas
harada4atsushi
0
9.1k
振り返り/agile-looking-back
harada4atsushi
0
21k
インセプションデッキの作り方/how-to-make-inception-deck
harada4atsushi
0
9.8k
もふもふなエンジニアの心得/mofmofinc-engineer-knowledge
harada4atsushi
0
7.6k
mofmof inc. 会社紹介 for 採用/mofmofinc-informatioin-for-recruiting
harada4atsushi
3
55k
Other Decks in Technology
See All in Technology
Oracle Cloud Infrastructure:2025年9月度サービス・アップデート
oracle4engineer
PRO
0
320
Optuna DashboardにおけるPLaMo2連携機能の紹介 / PFN LLM セミナー
pfn
PRO
1
780
20250929_QaaS_vol20
mura_shin
0
110
非エンジニアのあなたもできる&もうやってる!コンテキストエンジニアリング
findy_eventslides
3
860
From Prompt to Product @ How to Web 2025, Bucharest, Romania
janwerner
0
110
“2件同時配達”の開発舞台裏 〜出前館PMが挑んだダブルピック実現に向けた体験設計〜
demaecan
0
170
LLMアプリケーション開発におけるセキュリティリスクと対策 / LLM Application Security
flatt_security
7
1.6k
"複雑なデータ処理 × 静的サイト" を両立させる、楽をするRails運用 / A low-effort Rails workflow that combines “Complex Data Processing × Static Sites”
hogelog
3
1.5k
Flaky Testへの現実解をGoのプロポーザルから考える | Go Conference 2025
upamune
1
340
PLaMo2シリーズのvLLM実装 / PFN LLM セミナー
pfn
PRO
2
870
What is BigQuery?
aizack_harks
0
120
[2025-09-30] Databricks Genie を利用した分析基盤とデータモデリングの IVRy の現在地
wxyzzz
0
430
Featured
See All Featured
Code Reviewing Like a Champion
maltzj
525
40k
How to Ace a Technical Interview
jacobian
280
23k
Become a Pro
speakerdeck
PRO
29
5.5k
The Cult of Friendly URLs
andyhume
79
6.6k
The World Runs on Bad Software
bkeepers
PRO
71
11k
GraphQLとの向き合い方2022年版
quramy
49
14k
Code Review Best Practice
trishagee
72
19k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3.1k
Being A Developer After 40
akosma
90
590k
Automating Front-end Workflow
addyosmani
1371
200k
実際に使うSQLの書き方 徹底解説 / pgcon21j-tutorial
soudai
PRO
188
55k
Speed Design
sergeychernyshev
32
1.1k
Transcript
ݟੵΓ mofmof inc.
ソフトウェアの納期⾒積もりは、 星占いレベルのものであると思う 引⽤:メソッド屋のブログ http://simplearchitect.hatenablog.com/entry/2016/07/07/080250
• ਫ਼ • ݟੵΓ • ෆ࣮֬ੑ
不確実性コーン
時間をかければ ⾒積もり精度は上がる
⾒積もり=設計
⾒積もり⼿法の歴史 • LOC • FP • COCOMO • CoBRA •
KKD
⾒積もり精度の推移 精度 コスト(時間) '1 ϓϥϯχϯά ϙʔΧʔ ,,%
⾒積もりのタイミング ΩοΫΦϑ ϦϦʔε εϓϦϯτ ϓϩδΣΫτ
اը࣌ ΩοΫΦϑ࣌ εϓϦϯτܭը࣌
プランニングポーカー
͜ͷػೳɺ͘Β͍ͰͰ͖ΔΑͶʁ 営業
͍͍͘Β͍͔͔ΔΑ 営業 ベテラン エンジニア
͘Β͍ඞཁͩͱࢥ͍·͢ʂ 営業 ベテラン エンジニア 若⼿ エンジニア
ҰମԿΛ৴͡ Ε͍͍ʁ
• ૬ରݟੵΓ • νʔϜݟੵΓ • ετʔϦʔϙΠϯτ
͜ͷڇͷମॏԿΩϩ ͜ͷڇͷମॏԿΩϩ
͜ͷڇΩϩʂ
なぜ相対⾒積もりか • 相対的な基準があれば、簡単に⾒積もり の精度を上げることが出来る • ⼯数で絶対⾒積もりをすると、個⼈のス キルに依存した⾒積もりになってしまう • 実際には⾒積もる⼈と担当する⼈が違う ことも多いので、⾒積もりミスにつなが
る
ストーリーポイント • 個⼈のスキルに依存させないため、相対的な ⾒積もり尺度を「ポイント」で表現する • ストーリーポイント = 時間(⼯数)ではない • 基準となるユーザーストーリーと⽐較して、
どの程度複雑か、曖昧であるか、などを評価 して⾒積もる
基準ポイントの決め⽅ • 既に出ているストーリーの中から、全員 が理解できそうな⼀つのストーリーを決 めて、1ポイント or 3ポイントとする • 基準としてふさわしいものがなければ、 全員が認識を⼀致させる実装のイメージ
を使⽤しても良い
フィボナッチ数列(もどき)を使う • 0,1,2,3,5,8,13,20を使うことが多い • 規模が⼤きくなるほど正確に⾒積もれな くなる性質と、フィボナッチ数列が相性 が良い • ⼤きい単位の数字は細かく考えても精度 が上がることはないので考えるのはムダ
• ⼩さい単位に分割して⾒積もり可能にする
͜ͷௗΩϩʂ ͜ͷͷମॏʁ
• େ͖͍ετʔϦʔׂ • ཧɿʙϙΠϯτ • ϙΠϯτʙநߴΊ
議論をする • チーム全体で⾒積もる • ⾒積もりの差異が出た場合、何か考慮漏れ、ある いは考慮しすぎである可能性がある • ズレ幅が最も⼤きい⼈同⼠で、その⾒積もりをし た理由を説明し、その情報を追加した上で再度⾒ 積もる
• 議論の最中にカードを出し直してもOK • 議論が終わってから全員でもう⼀度⾒積もりしな おすでもOK
実際にやってみよう
ςʔϚ தͷՆٳΈͷ॓
10ઌੜ ߨࢣ ϝϯόʔੜె Έͳ͞Μ
お客様の中に経験者いますか?
流れ 1. 基準の1ptとなるストーリーを決める 2. ストーリーを⼀つずつ読み、以下繰り返し 1. ストーリーの単位が⼤きすぎる場合は分割する 2. 必要であればPOに確認して、ストーリーを詳細 化する
3. 全員で専⽤カードを使って⾒積もりする 4. ⾒積もり差異について議論する 5. チームで⼀つの⾒積もりを合意して決める
ポーカーのやり⽅ • ストーリーの詳細を読んだら基準ポイン トに対してどの程度のボリュームか⾒積 もり、カードを裏返しで出す • 全員がカードを出したら⼀⻫に表にする
Appendix
ग़དྷΔͬͯ ݴͬͨΑͳʁ
τϨʔυΦϑͷؔΛ ߹ҙ͓ͯ͜͠͏
参考:プランニングポーカー https://speakerdeck.com/ryuzee/planning_poker_guide
参考 https://www.slideshare.net/taguchimasahiro/ss-44419906