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
数字で表すシリーズ 〜開発規模(工数⇔期間)の見積もり編③〜 / practice of es...
Search
Sponsored
·
Ship Features Fearlessly
Turn features on and off without deploys. Used by thousands of Ruby developers.
→
Yu Kawanami
November 21, 2024
Technology
0
14
数字で表すシリーズ 〜開発規模(工数⇔期間)の見積もり編③〜 / practice of estimate part3
Yu Kawanami
November 21, 2024
Tweet
Share
More Decks by Yu Kawanami
See All by Yu Kawanami
数字で表すシリーズ 〜開発規模(工数⇔期間)の見積もり編②〜 / practice of estimate part2
kawanamiyuu
0
140
数字で表すシリーズ 〜開発規模(工数⇔期間)の見積もり編①〜 / practice of estimate part1
kawanamiyuu
0
160
開発チームの自走力を育む「イテレーションマネージャー」という取り組み / iteration manager
kawanamiyuu
1
1.5k
スタートアップで 1 度は崩壊しかけたチームがこれからチームになっていくための第一歩 / re-startup team
kawanamiyuu
2
970
PHP でもアーキテクチャテストしたい! / #phperkaigi / PHPerKaigi 2021
kawanamiyuu
6
5.4k
3 つの “はじめて” から始まった OSS 活動。のその先で / OSS LT会 #osscontributelt / turning point of joy as a developer
kawanamiyuu
0
800
腕力と瞬発力(新年の抱負 超LT会- vol.2 #ultral)/ New Year’s Resolution 2021
kawanamiyuu
2
450
ArchUnit で始める Java アプリケーションアーキテクチャの自動テスト / 自動化大好きエンジニアLT会 / LT for Engineers who love Automation
kawanamiyuu
0
930
マイクロサービスアーキテクチャをあきらめないための、モノリスで始めるアーキテクチャテスト / #jjug_ccc_b #ccc_b8 / JJUG CCC 2020 Fall
kawanamiyuu
5
3.9k
Other Decks in Technology
See All in Technology
「活動」は激変する。「ベース」は変わらない ~ 4つの軸で捉える_AI時代ソフトウェア開発マネジメント
sentokun
0
120
イベントで大活躍する電子ペーパー名札を作る(その2) 〜 M5PaperとM5PaperS3 〜 / IoTLT @ JLCPCB オープンハードカンファレンス
you
PRO
0
210
Physical AI on AWS リファレンスアーキテクチャ / Physical AI on AWS Reference Architecture
aws_shota
1
170
Oracle Cloud Infrastructure(OCI):Onboarding Session(はじめてのOCI/Oracle Supportご利⽤ガイド)
oracle4engineer
PRO
2
17k
CREがSLOを握ると 何が変わるのか
nekomaho
0
180
Bill One 開発エンジニア 紹介資料
sansan33
PRO
5
18k
OCI技術資料 : 証明書サービス概要
ocise
1
7.1k
来期の評価で変えようと思っていること 〜AI時代に変わること・変わらないこと〜
estie
0
110
MIX AUDIO EN BROADCAST
ralpherick
0
120
RGBに陥らないために -プロダクトの価値を届けるまで-
righttouch
PRO
0
130
AWS Systems Managerのハイブリッドアクティベーションを使用したガバメントクラウド環境の統合管理
toru_kubota
1
180
【Oracle Cloud ウェビナー】データ主権はクラウドで守れるのか?NTTデータ様のOracle Alloyで実現するソブリン対応クラウドの最適解
oracle4engineer
PRO
3
120
Featured
See All Featured
Un-Boring Meetings
codingconduct
0
240
What's in a price? How to price your products and services
michaelherold
247
13k
jQuery: Nuts, Bolts and Bling
dougneiner
66
8.4k
Docker and Python
trallard
47
3.8k
Distributed Sagas: A Protocol for Coordinating Microservices
caitiem20
333
22k
ラッコキーワード サービス紹介資料
rakko
1
2.8M
Why You Should Never Use an ORM
jnunemaker
PRO
61
9.8k
Leadership Guide Workshop - DevTernity 2021
reverentgeek
1
250
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
122
21k
Cheating the UX When There Is Nothing More to Optimize - PixelPioneers
stephaniewalter
287
14k
Embracing the Ebb and Flow
colly
88
5k
Art, The Web, and Tiny UX
lynnandtonic
304
21k
Transcript
数字で表すシリーズ 〜開発規模(工数⇔期間)の見積もり編③〜 2024/11/21 BABYJOB 開発部 LT会 @kawanamiyuu
前回までのおさらい 2
おさらい①「工数」と「期間」の関係 • 「工数」と「期間」の関係は次の計算式で表すことができる 「期間(ヶ月)」 =「工数(人月)」÷「人数」÷「開発稼働率(%)」x「バッファ」 (例) 開発稼働率が 60 % の
4 人チームで、工数が 7.2 人月の開発の完了にかかる期間を求めたい。 時間バッファ係数を 1.5 とすると「7.2 人月 ÷ 4 人 ÷ 0.6 ✕ 1.5 = 4.5 ヶ月」 • 開発規模を数字で表すことができれば、定性的な営みにみえる “エン ジニアリング活動” を、観測可能な仕事として、”ビジネス活動” に接 続できる 3
おさらい②「バッファ」の正体 • 「バッファ」は先の計算式を変形して次のように表すことができる 「バッファ」=「実績工数(人月)」÷「見積工数(人月)」 • この式から「バッファ」とは “実績工数と見積工数のズレの大きさ” であり、その意味は「見積工数に対して、実績工数が何倍大きくなる と予想されるか」と解釈できる 4
今回のテーマにつながる疑問 「バッファ」自体が、未知の変数に依存している。 結局「バッファ」って何? 5 ∵ もとの関係式には 2 つの未知の変数がある 「実績期間(ヶ月)」・・・未知数 =「見積工数(人月)」÷「人数」÷「開発稼働率(%)」
✕「バッファ」・・・未知数
今回のテーマ 6
「バッファ」と 「バーンアップチャート」と 「プロジェクトマネジメント」 7
ー 見積工数 ー バッファ込み見積工数 ー 累積消化工数(楽観) ー 累積消化工数(悲観) 8 期間 工数 楽観計画での “最速”完了見込日
悲観計画での “最遅”完了見込日 不確かさの幅 完了希望日(ビジネス要件)が決まっていない場合
ー 見積工数 ー バッファ込み見積工数 ー 累積消化工数(楽観) ー 累積消化工数(悲観) 9 期間 工数 もし、完了希望日(ビジネス要件)が ここなら・・・
許容可能な 不確かさの幅 完了希望日(ビジネス要件)が決まっている場合
本シリーズのまとめ 10
バッファの正体 • バッファとは、プロジェクト(やタスク)の “不確かさ” を定量化したもの • バーンアップチャート等から、その不確かさが許容でき るのか・できないのかが分かれば、不確かさを解消する (=確からしさを増す)ためのアクション(例:より詳 細な見積もりを行う)の要否を判断できる
11
バッファの正体 • バッファとは、プロジェクト(やタスク)の “不確かさ” を定量化したもの • バーンアップチャート等から、その不確かさが許容でき るのか・できないのかが分かれば、不確かさを解消する (=確からしさを増す)ためのアクション(例:納期をずら す・スコープを削る・見積りをより詳細化する)の要否を判断で
きる 12
プロジェクトマネジメントとは • プロジェクトの不確かさを明らかにし、不確かさを低減 し、不確かさに対するステークスホルダーの期待値を調 整すること • また、その不確かさを実際に解消する活動こそが、エン ジニアリング ◦ 工数見積りの精度をあげる
◦ 不確かさを含むプロジェクトのリスクを低減する開発計画、設計・実装 13
プロジェクトマネジメントとは • プロジェクトの不確かさを明らかにし、不確かさを低減 し、不確かさに対するステークスホルダーの期待値を調 整すること • また、その不確かさを実際に解消する活動こそが、エン ジニアリング ◦ 工数見積りの精度をあげる
◦ 不確かさを含むプロジェクトのリスクを低減する開発計画、設計・実装 14