不確実性と戦いながら見積もりを作成するプロセス/mitsumori-process

自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken
2026/04/02(木)

https://phper-oop.connpass.com/event/385966/

Transcript

1. 不確実性と戦いながら見積もりを作成するプロセス 〜プロジェクトを失敗させない「見積もれる状態」の作り方〜 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 2026.04.02 @hirodragon
2. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 自己紹介 株式会社ミライトデザイン CEO 林 宏勝 X: @hirodragon112 OOP/DDD/CQRS/ICONIX/Agile/RDRA/らへんが好き 上流から下流まで色々やります。 Object-Oriented Conference2021 主催 書籍「ドメイン駆動設計入門」レビュアー 2
3. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 3 勉強会 : ペチオブ https://phper-oop.connpass.com/
4. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 4 youtube : MIRAITO CHANNEL https://www.youtube.com/@miraito
5. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 5
6. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken Index 6 • 炎上するプロジェクトは何が原因なのか • よくある見積もりの種類 • 今日のお話し • 不確定要素と戦いながら見積もりを作成するプロセス ◦ 2つのゴール ◦ 7つのステップ • 正しい見積もりは存在しない • おわりに
7. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 炎上するプロジェクトは何が原因なのか 7 企業 IT 動向調査報告書 2025 (JUAS) より引用
8. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 炎上するプロジェクトは何が原因なのか 8 QCDそれぞれの観点別のトップ要因 Q … スキル不足 C … 計画時の考慮不足 D … 計画時の考慮不足
9. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 炎上するプロジェクトは何が原因なのか 業務やシステム開発の複雑さ・影響範囲が年々上昇 計画の難易度が高くなり考慮が不足している 計画時の考慮不足を少しでも防ぎたい 9 企業 IT 動向調査報告書 2025 (JUAS) より引用
10. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 10 開発ベンダーにとって一番最初の計画は見積もり • 予算の確保 • 開発ベンダー選定 • 対象範囲 • システム概要の把握 • 予算感を伝えて稟議を通してもらう • 概算見積もりでベンダー選定が行われる • 見積もり範囲を決める • システム概要の把握 炎上するプロジェクトは何が原因なのか
11. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 11 何を作るか整理 ↓ 見積もり ↓ 開発 理想 よくある現実 とりあえず見積もり ↓ 何を作るか整理 ↓ 開発 炎上するプロジェクトは何が原因なのか
12. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 12 実際の開発現場では 理想的な順序で見積もりを作成する機会は少ない 炎上するプロジェクトは何が原因なのか
13. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken よくある見積もりの種類 13 • トップダウン見積もり • 積み上げ見積もり • 類推見積もり ◦ ストーリーポイント ◦ ベロシティベース見積もり • パラメトリック見積もり ◦ ファンクションポイント法 ◦ COCOMO ◦ ユースケースポイント法 これらは基本的に 工数算出の方法
14. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken よくある見積もりの種類 14 初期コンセプト段階 Initial Concept Approved プロダクト定義確定 Product Definition 要求定義完了 Requirements Complete ユーザーインターフェース設計完了 UI Design Complete Detailed Design 実装完了 Complete Code Comple 不確実性のコーン
15. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken よくある見積もりの種類 15 初期コンセプト段階 Initial Concept Approved • 超概算見積もり • レンジ見積もり プロダクト定義確定 Product Definition • 概算見積もり • 予算確保見積もり 不確実性のコーン
16. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 今日のお話 見積もり = 工数算出 16 見積もり = 見積もれる状態を作る + 工数算出 ここが重要
17. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 17 つまり 実際の開発現場の見積もりに本当に必要 なものは 今日のお話 ※ 人類に本当に必要なもの
18. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 18 見積もれる状態を作るプロセス 今日のお話
19. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 19 ミライトデザイン流 実際の現場で必要な見積 作成プロセス 不確定要素と戦いながら見積もりを作成するプロセス
20. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 20 2つのゴール 1. 見積もり対象を明確にする ※ 人類に一番必要な繋がり • 足りない情報に対して、不明瞭なまま見積もりをしない • 不確実性とバッファで戦わない ◦ 仮定・推定で良いので、どの状態に対して見積もりをしたかを全て明確にする ◦ 仮定・推定もできない要素に対しては見積もりをしない • 見積もった内容と異なる要件になった場合は再度見積もりをする（という合意）
21. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 21 2. 関連（繋がり、Relation） を明確にする ※ 人類に一番必要な繋がり 2つのゴール
22. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 22 7つのステップ 1. 全体像の把握 2. ユースケースとフローの理解 3. 見積もり難所の特定 4. 構造化（見積もり単位へ分解） 5. 開発工数の見積もり 6. 開発以外の工数の想定 7. トップダウン視点での見直し
23. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 23 1. 全体像の把握 • 確認可能な要求・与件を構想現時点で存在する全ての情報を把握する • 必ず図に落とし込む（ホワイトボードやグラフツールなど） 全体像とは、例えば - 登場人物（ロール） - ユースケース - 業務フロー - 外部システム連携 - システムの目的 など 7つのステップ
24. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 24 不確定要素と戦いながら見積もりを作成するプロセス よくある失敗 … 工数を振りたくていきなり画面やAPIの一覧を作る 初期段階では大まかなやりたい事や、フローしか出ていない事が多い。 可能な限り具体的にアクター・画面・フローなどを図にして、矢印で繋ぐ。 不明瞭な要素も全て仮定を置く 例）一切詳細が書かれていない要求Aに対してでも • 要求を実現する為に必要なフローを想定 • フローに登場するアクターを想定 • 必要な境界（画面やUIなど）を想定 • 全てを線で繋ぎ関係を明確にする これが見積もりの前提となる。 何に対して見積もりをしているかを明確にするためにここを曖昧にしない
25. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 25 不確定要素と戦いながら見積もりを作成するプロセス 2. ユースケースとフローの理解 • 1で全体的な登場人物（人・システム・その他）をイメージできたら、その際に登場した 各ユースケースがどういうオペレーションやフローをひとまとめにして成立している かを理解する • ユースケース単位では成立しているように見えてもオペレーションとして自啓礼津 を考えるとおかしな矛盾が発生していないか等 • 重要なのは、正確さではなく不明瞭なユースケースが存在しないようにする事 • この工程を入れる事で、単なる資料上の機能と向き合うのではなく実際に使われる 現場をイメージできる
26. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 26 不確定要素と戦いながら見積もりを作成するプロセス 3. 見積もり難所の特定 • 実際には1. 2. の作業と平行して行う • 全体像・オペレーションを繋げていく際に、今回の見積もりの肝となる箇所を見出しておく • 肝となる所とは ◦ 実装難易度の高そうな機能 ◦ 複数社が絡む機能（対抗先API開発会社と連携しながら作るなど） ◦ 自社の経験値が低い作業 ◦ インシデントを起こした際の影響が大きいもの（決済系や健康などに直結するものなど） ◦ 自社起因以外の待ち期間が発生しそうな箇所（認可や申請が必要だったりなど） ◦ 現時点で見積もり不可な箇所（情報が足りな過ぎて仮定もできない）
27. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 27 不確定要素と戦いながら見積もりを作成するプロセス 見積もりは不確実性との戦いとはいえ、ある程度の経験があれば単純な要素が大きくずれる事はない 例えば、なんども似たようなシステムを作った事があれば、ログイン機能・検索機能・などは、よほど仕様が 特殊でない限り想定した見積もりと大幅にずれる事は無い ↓ つまり、この肝となる箇所が見積もりが大きくずれる要因となりやすいので、明確にあたりをつけておく
28. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 28 不確定要素と戦いながら見積もりを作成するプロセス 4. 構造化（見積もり単位へ分解） • 全体像把握し、ユースケース、オペレーションの繋がりまで確認できたので、ここで見積もり可能な単 位へ分解をしていく。 ◦ 画面, API, バッチ, 機能 など • 重要なのは独立した機能の羅列にしないこと。 • ユースケースは見積もりの単位とはしない ◦ ユースケースは見積もるには大きいのであくまで抜け漏れ確認として重要 ◦ 見積もりはあくまで実装単位 • 構造化は見積もれる単位を作る事と、その関連性を網羅するために非常に重要
29. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 29 不確定要素と戦いながら見積もりを作成するプロセス 構造化要素は見積もる単位の作成と関連の確認の為に必要 例） 画面 … 画面ID 1, 画面ID 2, 画面ID 3, 画面ID 4 ユースケース … UC-A, UC-B, UC-C アクター … アクターa, アクターb などの構造パーツがある場合 フロー1 - UC-A - アクターb - 使用画面 … 画面ID1, 画面ID3 のように、要素を独立で並べるのではなく必ずフローのどこに存在すべきかを明確にし、過不足がないよう にする
30. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 30 不確定要素と戦いながら見積もりを作成するプロセス 5. 開発工数の見積もり • 冒頭で紹介したような見積もり手法を使う場所 • 主に、類推見積もりを積み上げ方式で算出する事が多い • 超概算などの場合、ここはサイズやランクによる見積もりとする事も • 4で繋がりを確認できた中で見積もる単位を選定しそのリストに対して見積もる ◦ webシステムでは画面・バッチ・apiなどの単位となる事が多い
31. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 31 不確定要素と戦いながら見積もりを作成するプロセス 6. 開発以外の工数の想定 • 見積もり時に良く抜ける「開発以外の項目」の洗い出し • ミーティング • 仕様確認 • 進捗管理 • コードレビュー • 環境構築 • デプロイ • 技術調査 など
32. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 32 不確定要素と戦いながら見積もりを作成するプロセス 7. トップダウン視点での見直し • 最後に全体感と比較をする • これまでの工程はボトムアップで見積もりを足し上げる手法 • 規模が大きくなればなるほど、積み上げた少しの誤差が大きなずれになるがボトムアップだけだと気 づきずらい • 必ず トップダウンの視点 と比較する
33. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 33 不確定要素と戦いながら見積もりを作成するプロセス トップダウン感覚と ボトムアップでの数字の積み上げを比較し、違和感があればどの要素が特に違和感が あるかを再度見直す。
34. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 34 正しい見積もりは存在しない この7ステップを踏めば、目的とする2つの状態 「見積もり対象」・「関連」 をそれぞれ明確にできると思います。 また、単なる機能群や画面群に数字をふるのではなく関連を明確にしようとする作業により • 現時点で足りない要素 • 推定はできるがあくまで仮定な要素 • 仮定を置くことも困難な曖昧な要求（つまり要件定義後でないと見積もりできない箇所） • 要件定義の際に確認すべき要素 などが、見積もりの段階である程度目星がつく状態となります。
35. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 35 正しい見積もりは存在しない 正確な見積もりは製造完了時にしかわからない。 重要なのは 何に対して見積もりをしたか？（見積もり前提）が明確になっている事。 見積もり前提が明確になる事で、 • 今回の見積もりは何が含まれるか • 逆に何が含まれていないのか が明確になる。 前提に含まれないものが必要になった場合は再度見積もりをする論拠となる 絶対にしてはいけないのは、不明確な対象に対して見積もる事 見積もり対象が不明確な場合この見積もりでこれも入ってるはずだった。。などのトラブルになる
36. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken Q. 概算のタイミングでこれだけの工程をやるのは大変すぎるのでは？ A. 規模にもよりますが、慣れればこの7ステップは1～2日あれば十分可能です また、見積もりをただ金額で伝えるのではなく明確な見積もり論拠を伝えられる事 で、場合によっては依頼者よりもこのシステムに詳しい状態でスタートする事ができ ます。信頼感も上がり受注率も上がり、先の工程の段取りや、見積もりずれによるリ スクも大幅に現象させる事ができます。 36 おわりに
37. 自社サービス・受託開発それぞれの視点で語るプロジェクトを失敗させない工夫 with asken 冒頭にあったとおりプロジェクトを炎上させない為には、初動がとにかく重要です。 快適な開発ライフを送るためにも、初動にこそ力を入れましょう 37 おわりに ※ 人類が一番力をいれるべきもの