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
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
Keita
June 01, 2026
Business
100
0
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
みつもりの話
Keita
June 01, 2026
More Decks by Keita
See All by Keita
転職してすぐリモートワークになった話
fmty
1
540
システム開発の契約とかお⾦の話
fmty
0
400
レガシーなコミュニケーションツール
fmty
0
1k
QRコードを読み取る
fmty
0
1.1k
Other Decks in Business
See All in Business
Algomatic | 会社紹介資料
algomatic
PRO
2
150k
FABRIC TOKYO会社紹介資料 / We are hiring(2026年06月17日更新)
yuichirom
38
400k
フルカイテン株式会社 採用資料
fullkaiten
0
97k
チームマネージャー(SV)のご紹介
rs_mitotakaya
0
380
サムコ株式会社 第47期第3四半期決算概要
tsuchihashi
0
470
コーポレートストーリー(新規投資家様向け会社説明資料)
gatechnologies
2
19k
今日から始めるセルフマネジメント/A Practical Guide to Self-Management
ikuodanaka
1
2.9k
セーフィー株式会社(Safie Inc.) 会社紹介資料
safie_recruit
7
450k
ネクストビートコーポレートガイド/corporate-guide
nextbeat
3
87k
メンバーズ会社紹介資料/Members company brochure
members_recruiting
0
38k
株式会社うるる エンジニア向け採用資料
uluru_hr
3
130k
Kasanare_Recruitng_Pitch
kyoichi_yasuda
0
320
Featured
See All Featured
RailsConf & Balkan Ruby 2019: The Past, Present, and Future of Rails at GitHub
eileencodes
141
35k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
16
2k
Future Trends and Review - Lecture 12 - Web Technologies (1019888BNR)
signer
PRO
0
3.6k
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
310
Rails Girls Zürich Keynote
gr2m
96
14k
Building AI with AI
inesmontani
PRO
1
1.1k
Bridging the Design Gap: How Collaborative Modelling removes blockers to flow between stakeholders and teams @FastFlow conf
baasie
0
590
The Cost Of JavaScript in 2023
addyosmani
55
10k
Navigating Weather and Climate Data
rabernat
0
230
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.5k
Game over? The fight for quality and originality in the time of robots
wayneb77
1
200
Jamie Indigo - Trashchat’s Guide to Black Boxes: Technical SEO Tactics for LLMs
techseoconnect
PRO
0
190
Transcript
みつもりの話 第34回 KyotoLT ⼩⻄啓太
⼩⻄ 啓太 @fmty ▪ 株式会社サブスレッド 所属 – 営業課 ⻑(おさ) ▪
営業、プロジェクトマネージャー ▪ 京都在住 – 妻と⼦供(⾼2♀、中3♂、中1♀)の5⼈暮らし ▪ 趣味 – ゲーム、読書、空⼿(松濤館流) ▪ Fate/GrandOrder が ⼤好きです ▪ ケイタくん、ケイタさんと呼んでください
今⽇は「⾒積もり」の話をします ▪ 僕はコードが書けないので皆さんのように技術的な話はできません・・・ ▪ 作業時間や⼯数の⾒積りの話をしようと思います ▪ お⾦の話はしません ▪ 久しぶりにAIをまったく使わずにスライドを作りました –
⼿作業の温かみを感じてください – 間違えてたらすみません
こんな経験ありませんか︖ この機能、どのくらいで 実装できそう︖
あるあるだと思います ▪ なんだか曖昧な要件だったり ▪ はじめて聞くような機能だったり ▪ できるかできないかもわからないような機能だったり ▪ しかも期限が急だったり
作業⾒積もり、苦⼿だなってひとー
ちょっとでも楽になるといいな ▪ アジャイル的な相対⾒積の話はしません – ストーリーポイントとかベロシティとか
どうしてこの質問が出てくるのか この機能、どのくらいで 実装できそう︖
この機能、どのくらいで実装できそう︖ ▪ 「どうしてこの質問が出てくるのか」を考えてみる – 質問した本⼈やステークホルダーがなんらかの意志決定をするため
我々は限られた「期間とコスト」の制約 の中で成果を出す必要がある ▪ 我々の仕事は「何かを作ること = プロジェクト」である – プロジェクトとは何か – プロジェクトとは「期間とコストの制約」の中で成果を出す活動である
▪ プロジェクトの機能の開発やテストにどのくらいの⾦銭的なコストがかかるか を計算し、それに⾒合う価値が得られるかを判断するためのもの – ⾒積もり = 投資判断をするためのもの
そうは⾔うけど難しいよね ▪ 「なぜ難しいのか」を深掘りしてみる
⾒積もりが難しい理由 ▪ 締め切り(約束)になりがちだから
⾒積もりが難しい理由 ▪ 締め切り(約束)になりがちだから – 「〇⽇でできるって⾔ったじゃないか」
⾒積もりが難しい理由 ▪ 締め切り(約束)になりがちだから – 「〇⽇でできるって⾔ったじゃないか」 ▪ 不確実性が多い
不確実性って︖ ▪ 何をすればいいかわからない ▪ ⾃分の考えと相⼿のゴールが違うかもしれない ▪ 予想外のことが起こるかもしれない ▪ どのくらい作業時間がかかるかわからない ▪
⾃分の予測が正しいか⾃信がもてない ▪ どれだけ追加タスク(バグとか)が出るかわからない
不確実性を3つの区分に分類してみる ▪ ①タスクの所要時間が適切か ▪ ②バッファが適切か ▪ ③タスクを適切に切り出せているか
不確実性の例をそれぞれ分類する ▪ ①タスクの所要時間が適切か – どのくらい作業時間がかかるかわからない – ⾃分の予測が正しいか⾃信がもてない ▪ ②バッファが適切か –
予想外のことが起こるかもしれない – どれだけ追加タスク(バグとか)が出るかわからない ▪ ③タスクを適切に切り出せているか – 何をすればいいかわからない – ⾃分の考えと相⼿のゴールが違うかもしれない
それぞれの対策を考えていく ▪ ①タスクの所要時間が適切か ▪ ②バッファが適切か ▪ ③タスクを適切に切り出せているか
それぞれの対策を考えていく ▪ ①タスクの所要時間が適切か ▪ ②バッファが適切か ▪ ③タスクを適切に切り出せているか
①タスクの所要時間が適切か ▪ 問題 – どのくらい作業時間がかかるかわからない – ⾃分の予測が正しいか⾃信がもてない ▪ 解決⽅法 –
勘・経験・度胸(KKD法) – アナロジー法(類推法) ▪ 過去の事例を元にする – 三点⾒積もり法(PERT法) ▪ 後述 – パラメトリック法(係数法) ▪ API 1本あたり〇⽇のように係数を計算する
①三点⾒積法(PERT法) ▪ 以下3つの値を出す – 順調に進んだ場合の最短時間(期待時間) – ハマったときの最⻑時間(悲観的時間) – おそらくこのくらいという妥当な時間(最確時間) ▪
以下の計算式に当てはめる – 期待時間 = (楽観的時間 + 4 × 最確時間 + 悲観的時間) ÷ 6 楽観 最確 悲観的 計算 タスク① 2 3 5 3.1 タスク② 1.5 2 5 3 タスク③ 1 1 3 1.3 合計 7.4
それぞれの対策を考えていきましょう ▪ ①タスクの所要時間が適切か ▪ ②バッファが適切か ▪ ③タスクを適切に切り出せているか
②バッファが適切か ▪ 問題 – どのくらい作業時間がかかるかわからない – ⾃分の予測が正しいか⾃信がもてない ▪ 解決⽅法 –
係数計算 ▪ とりあえず1.5倍しておこう – リスク別係数 ▪ 作業ごとにリスク係数を変えて計算する – 2乗和平⽅根法(SRSS法) ▪ 後述
②2乗和平⽅根法(SRSS法) ▪ 以下2つの値を出す – 順当にいったらこのくらい(スムーズに⾏ったらではない) – ハマったときはこのくらい ▪ 以下の計算式に当てはめる –
それぞれのタスクで出した最悪と平均の差を、2乗して⾜し、平⽅根を取る 平均 最悪 差 2乗 タスク① 3 5 2 4 タスク② 2 5 3 9 タスク③ 1 3 2 4 合計 17 平⽅根(バッファ⽇数) 4.1 平均の合計にバッファ⽇数を⾜す 10.1
それぞれの対策を考えていきましょう ▪ ①タスクの所要時間が適切か ▪ ②バッファが適切か ▪ ③タスクを適切に切り出せているか
③タスクを適切に切り出せているか ▪ 問題 – 何をすればいいかわからない – ⾃分の考えと相⼿のゴールが違うかもしれない ▪ 解決⽅法 –
聞く – WBSやタスクリストを作成して、依頼者と認識をあわせる ▪ 「⾃分はこう考えたが、それであっているか︖」
⾃分はどれが⼀番苦⼿なのかを考えて みてもよさそう ▪ ①タスクの所要時間が適切か ▪ ②バッファが適切か ▪ ③タスクを適切に切り出せているか
⾒積もりが難しい理由 ▪ 締め切り(約束)になりがち – 対策は︖
前提条件を書くしかない ▪ しっかりと伝えるしかない – 「今の情報だとここまでしか出せない」とか – 「期限を約束するものではないです」とか – 逆に「どのくらいの正確性が必要ですか︖」と聞き返すのもいいか もしれない
依頼する側の問題もある ▪ そもそも要件が曖昧だったり ▪ 不確定要素が多かったり ▪ 雑に投げてきたり
まとめ ▪ ⾃分がどこに苦⼿意識があるかを考えて、対策をする – ①タスクの所要時間が適切か – ②バッファが適切か – ③タスクを適切に切り出せているか ▪
⾒積=作業時間の約束をすることではない – 相⼿に判断材料を与えること