TRACERYプロダクトマネージャーの haru です。
2025年2月18日(火)に開催された勉強会『BPStudy#210〜見積りと計画について学ぼう』の第3部では、開発の見積りをテーマにしたパネルディスカッションが行われました。その時の様子をお伝えします*1。
プロジェクト成功への鍵、開発見積りの重要論点
- その１: 内製開発と外部委託における見積りの相違点
- その２: 「高すぎる」と言わせない見積りの技術（説明責任、スコープ、タイミング、インプット）（本記事）
- その３: 見積りのトレードオフへの向き合い方（近日公開予定）
- その４: 過去の経験を見積りに活かす方法（近日公開予定）
- その５: 新規開発と既存システム改修の見積り戦略の違い（近日公開予定）
- その６: 『見積りソン』に参加して得たもの（近日公開予定）
- パネラー：
- 高崎健太郎(たかさき けんたろう) 氏：以下、高崎
- (株)アクティア COO
- 濱井 和夫 (はまい かずお) 氏：以下、濱井
- 神崎 善司 (かんざき ぜんじ) 氏：以下、神崎
- (株)バリューソース代表取締役社長、要件定義手法のRDRA（ラドラ）*2の開発者
- 藤貫 美佐 (ふじぬき みさ) 氏：以下、藤貫
- （株）NTTデータフィナンシャルテクノロジー T＆S事業部 シニア・スペシャリスト、ITシステム可視化協議会 会長、『見積りソン*3』主催
- 高崎健太郎(たかさき けんたろう) 氏：以下、高崎
- モデレータ：
- 佐藤 治夫(さとう はるお) ：以下、haru
- (株)ビープラウド代表取締役社長、この記事の筆者
- 佐藤 治夫(さとう はるお) ：以下、haru
haru：システム開発、ソフトウェア開発の見積りについて、日々のお仕事で特に大事にしていることはありますか？見積りの際に「これは重要だ」と思っていることをお聞かせください。
見積りの納得感
高崎：見積りには、どうしても経験や勘、度胸*4といった要素が求められます。時間の都合で、「えいや」で決めざるを得ない場面も、少なからずあります。
たとえ概算であっても、説明できる形に整えておくことです。
説明を求められたときに、「これこれの理由で、こうなっています」と、見積りの根拠を明確に示す必要があります。理論立てた説明ができなければ、納得を得ることはできないでしょう。
この姿勢は、外部のお客様に対してだけでなく、社内で「この工数で進めます」と説明する場面でも同じです。
常に、誰に対しても、見積りの根拠を論理的に説明できる状態を整えておくことが重要だと考えています。
haru：なるほど、納得感ですね。
高崎：はい。工数や金額に対して、納得できることが何より重要です。
加えて重要なのは、淀みなく答えられることです。その場で根拠を考えているように見えると、「この数字は本当に正しいのか？」「適当に出したのではないか？」と、不信感を招くおそれがあります。
そうならないためにも、事前に根拠を整理し、明確にしておくことが欠かせません。
濱井：PMOの立場から見ると開発の提案に進む前に、見積りの妥当性をチェックする必要があります。
なので、最初の確認項目として「どのような根拠で見積もったのですか？」と必ず尋ねます。そのときに、明確な答えがすぐに返ってこないと、「ちょっと厳しいかな」と感じてしまいます。
また、見積りは一つの方法に頼るのではなく、別の視点からも試算し、結果を照合することで、見積りの妥当性に対する確信を高められると考えています。
見積りの早い段階での提示
神崎：見積りは、できるだけ早い段階で提示することが重要だと考えています。
要件を詰める過程では、内容が際限なく広がってしまうことが少なくありません。見積りを念頭に置いておけば、それ自体が自然な制約となり、議論の脱線や不要な膨張を防ぐ助けになります。
また、早い段階である程度可視化し、納得感のある状態を作ることが大切です。
可視化したものを一緒に見ながら、「ここをこう変えれば、これだけコストが減ります」「こう運用を変えれば、システム開発そのものが不要になります」といった提案ができれば、開発を予算内に収めるための建設的な議論ができると考えています。
濱井：よくあるのは、フィットギャップ分析*5を重ねながら見積りを進め、最後に精査してみると、予算感とかけ離れてしまい、プロジェクトが頓挫してしまうケースです。
「この要求を満たすには、これだけ費用が増えます。本当に必要でしょうか？」と、その都度すり合わせが必要です。
こうした確認を重ねることで、無駄な仕様の追加を防ぎ、議論の焦点もぶらさずに済みます。
最後に「高すぎて作れません」となるのは、ビジネス側、開発側の双方にとって避けたい結末ですから。
スコープマネジメントの徹底
藤貫：私は、上流工程におけるスコープマネジメントの徹底が、プロジェクト成功の鍵だと考えています。
まずはスコープのベースラインを設定し、予算から逆算して、限られた枠内に収まるよう優先順位をつけながら要件を絞り込んでいきます。
初期段階では、スコープも予算も不透明であることが多く、いきなり細部まで詰めるのは現実的ではありません。
だからこそ、関係者とのすり合わせを重ねながら、少しずつ精度を上げていく姿勢が欠かせません。
見積りのインプットの粒度と精度
藤貫：
もう一点、私が見積りで重視しているのは、透明性に加えて、インプットの粒度と精度です。
具体的には、業務内容や前提条件、設計方針などがどこまで具体的に定義されているかという点です。
インプットが曖昧であれば、見積りも曖昧にならざるを得ません。
だからこそ、どの程度の前提に基づいた見積りなのかを明確に示し、その精度と不確実性を関係者と共有することが欠かせないと考えています。
提出物に実質的な記述がないこともあります。記述がどれくらい詰まっているかを定量化していくことも必要だと考えています。
濱井：よくありますよね。一見、よく書かれているように見えても、細かいことばかりで、整合性が取れていないようなケースです。
昔、ファンクションポイント法*6を学んだ時に、藤貫さんの本にも書いてあったかもしれませんが、ファンクションポイントが計算できないということは、要件として妥当かどうか分からないということだと思います。
『見積りソン』に参加してみて、要件がきちんとできているかを確認するためにも、RDRAを使ってざっと見積りを出してみるのは有効だと改めて感じました。
藤貫：そうなんです。文書に書かれていると、一見、検討が進んでいるように思えてしまいますが、実際には内容が伴っていないことも少なくありません。
次回は『見積りのトレードオフへの向き合い方』というテーマで話が進みます。
*1:伝わりやすくする目的で、話の流れを一部再構成しています。
*2:モデルベースのビジネスとシステムの可視化手法。To-Be用途では要件定義に使え、As-Is用途では、既存システムの可視化に使用できる。RDRA公式サイト
*3:紹介資料：見積りと提案の力を競う見積りソン
*4:頭文字を取って「KKD」と呼ぶこともある。
*5:現状の業務やシステムと、新たに導入する製品・仕組みとの適合状況（フィット）と、差異（ギャップ）を整理する分析手法。ギャップが大きい部分は、カスタマイズや運用変更などの対応策を検討する。
*6:ソフトウェア開発の規模を計測し、工数見積もりを行うための手法です。ユーザーが利用する機能に着目し、その機能数や複雑さなどを数値化して「ファンクションポイント (FP)」として算出し、開発規模を評価
