Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
みつもりの話
Search
Keita
June 01, 2026
Business
140
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
550
システム開発の契約とかお⾦の話
fmty
0
410
レガシーなコミュニケーションツール
fmty
0
1k
QRコードを読み取る
fmty
0
1.1k
Other Decks in Business
See All in Business
Bet AI Day 2026丨LayerXの採用を支える組織AIの現在地と、Agentに任せる未来
layerx
PRO
9
13k
UNICORN株式会社2026会社説明資料
unicorn
0
1.5k
AWSのログ/アラートの調査を AIで自動化してみた話
tomomasa
0
160
Claude Design/Codex入門:創造性とデザイン品質を、同じ箱で綱引きさせない
forest8810
0
240
顧客理解レースでAIの一歩先を行く / Know customers better than AI
hirokiyamamoto14
PRO
1
450
ナカソネ住設カスタマーエンジニア紹介資料WEB公開版_2026年8月版_.pdf
nakasonejusetsu
0
130
株式会社TableCheck - 会社紹介 Company Profile
tablecheckac
0
9.6k
NEXERA inc. | Company Deck
nexera
0
25k
エスキュービズム 会社紹介資料
human_resources
2
27k
決める人と作る人を、 分けない / Deciders build. Builders decide.
hirokiyamamoto14
PRO
0
180
PdMからみた EMの役割の変化 / When EM Meets PdM
hirokiyamamoto14
PRO
1
170
個人的に感動した サクラエディタの機能2026822 ゆるweb
mikikosaka
6
6.3k
Featured
See All Featured
Impact Scores and Hybrid Strategies: The future of link building
tamaranovitovic
0
430
First, design no harm
axbom
PRO
2
1.3k
The Limits of Empathy - UXLibs8
cassininazir
1
640
HU Berlin: Industrial-Strength Natural Language Processing with spaCy and Prodigy
inesmontani
PRO
0
690
The Impact of AI in SEO - AI Overviews June 2024 Edition
aleyda
6
1.2k
The Director’s Chair: Orchestrating AI for Truly Effective Learning
tmiket
1
290
Prompt Engineering for Job Search
mfonobong
0
450
Technical Leadership for Architectural Decision Making
baasie
3
560
Writing Fast Ruby
sferik
630
63k
Building Applications with DynamoDB
mza
96
7.2k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.6k
Producing Creativity
orderedlist
PRO
348
41k
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やタスクリストを作成して、依頼者と認識をあわせる ▪ 「⾃分はこう考えたが、それであっているか︖」
⾃分はどれが⼀番苦⼿なのかを考えて みてもよさそう ▪ ①タスクの所要時間が適切か ▪ ②バッファが適切か ▪ ③タスクを適切に切り出せているか
⾒積もりが難しい理由 ▪ 締め切り(約束)になりがち – 対策は︖
前提条件を書くしかない ▪ しっかりと伝えるしかない – 「今の情報だとここまでしか出せない」とか – 「期限を約束するものではないです」とか – 逆に「どのくらいの正確性が必要ですか︖」と聞き返すのもいいか もしれない
依頼する側の問題もある ▪ そもそも要件が曖昧だったり ▪ 不確定要素が多かったり ▪ 雑に投げてきたり
まとめ ▪ ⾃分がどこに苦⼿意識があるかを考えて、対策をする – ①タスクの所要時間が適切か – ②バッファが適切か – ③タスクを適切に切り出せているか ▪
⾒積=作業時間の約束をすることではない – 相⼿に判断材料を与えること