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
Keita
June 01, 2026
Business
130
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
AIネイティブな組織を問い直す
smiyawaki0820
15
7k
株式会社ジグザグ_新規投資家向け資料_2026年7月
zig_zag
0
1.9k
株式会社ユビレジ_採用ピッチ資料 / Ubiregi_CompanyProfile
ubiregi_saiyo
1
12k
「受託脳」から「提案脳」へ〜「一緒に悩んで、いいものつくる」を目指して
kuranuki
3
2k
透明性レポート(2026年上半期)
mercari_inc
0
44k
ときめかないミーティングはアップデートのシグナル #scrumosaka
asumikam
5
1.7k
About APPLE WORLD
appleworld
0
13k
「ユーザー価値か、事業成果か?」 そんな意思決定で悩む前に PMがやるべきこと
inagakikay
3
1.1k
もしもあなたの会社にサイバーセキュリティ攻撃予告があったなら ~フロンティアAI脅威と企業の脆弱性対策~
okdt
PRO
0
110
<DevLOVE関西>関係性が育つ前にフィードバックを届ける ~関係性が育つのを待てないとき、どう渡すのか~
emi0726
4
220
プレイド概要説明資料_2026/08
plaid
PRO
1
3.1k
開発が速く安くなった後の話 AI時代のソフトウェアエンジニアリング組織論 #devsumi
recruitengineers
PRO
82
56k
Featured
See All Featured
Templates, Plugins, & Blocks: Oh My! Creating the theme that thinks of everything
marktimemedia
31
2.9k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
232
55k
Have SEOs Ruined the Internet? - User Awareness of SEO in 2025
akashhashmi
0
440
Self-Hosted WebAssembly Runtime for Runtime-Neutral Checkpoint/Restore in Edge–Cloud Continuum
chikuwait
0
730
svc-hook: hooking system calls on ARM64 by binary rewriting
retrage
2
510
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
1
250
How GitHub (no longer) Works
holman
316
150k
The Limits of Empathy - UXLibs8
cassininazir
1
610
Optimizing for Happiness
mojombo
378
71k
Navigating the Design Leadership Dip - Product Design Week Design Leaders+ Conference 2024
apolaine
2
400
Building a Scalable Design System with Sketch
lauravandoore
463
34k
Exploring the relationship between traditional SERPs and Gen AI search
raygrieselhuber
PRO
2
4.2k
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やタスクリストを作成して、依頼者と認識をあわせる ▪ 「⾃分はこう考えたが、それであっているか︖」
⾃分はどれが⼀番苦⼿なのかを考えて みてもよさそう ▪ ①タスクの所要時間が適切か ▪ ②バッファが適切か ▪ ③タスクを適切に切り出せているか
⾒積もりが難しい理由 ▪ 締め切り(約束)になりがち – 対策は︖
前提条件を書くしかない ▪ しっかりと伝えるしかない – 「今の情報だとここまでしか出せない」とか – 「期限を約束するものではないです」とか – 逆に「どのくらいの正確性が必要ですか︖」と聞き返すのもいいか もしれない
依頼する側の問題もある ▪ そもそも要件が曖昧だったり ▪ 不確定要素が多かったり ▪ 雑に投げてきたり
まとめ ▪ ⾃分がどこに苦⼿意識があるかを考えて、対策をする – ①タスクの所要時間が適切か – ②バッファが適切か – ③タスクを適切に切り出せているか ▪
⾒積=作業時間の約束をすることではない – 相⼿に判断材料を与えること