見積りのトレードオフへの向き合い方〜プロジェクト成功への鍵、開発見積りの重要論点その3

TRACERYプロダクトマネージャーの haru です。

2025年2月18日(火)に開催された勉強会『BPStudy#210〜見積りと計画について学ぼう』の第3部では、開発の見積りをテーマにしたパネルディスカッションが行われました。その時の様子をお伝えします*1。

プロジェクト成功への鍵、開発見積りの重要論点

その１: 内製開発と外部委託における見積りの相違点
その２: 「高すぎる」と言わせない見積りの技術（説明責任、スコープ、タイミング、インプット）
その３: 見積りのトレードオフへの向き合い方（本記事）
その４: 過去の経験を見積りに活かす方法
その５: 新規開発と既存システム改修の見積もり戦略の違い
その６: 『見積りソン』に参加して得たもの

パネラー：
- 高崎健太郎(たかさきけんたろう) 氏：以下、高崎
  - (株)アクティア COO
- 濱井和夫 (はまいかずお) 氏：以下、濱井
  - NTTコムウェア(株)、IIBA日本支部理事
- 神崎善司 (かんざきぜんじ) 氏：以下、神崎
  - (株)バリューソース代表取締役社長、要件定義手法のRDRA（ラドラ）*2の開発者
- 藤貫美佐 (ふじぬきみさ) 氏：以下、藤貫
  - （株）NTTデータフィナンシャルテクノロジー T＆S事業部シニア・スペシャリスト、ITシステム可視化協議会会長、『見積りソン*3』主催
モデレータ：
- 佐藤治夫(さとうはるお) ：以下、haru
  - (株)ビープラウド代表取締役社長、この記事の筆者

予算感の認識を早めに合わせる
要件をツリー構造で整理し、相互の依存関係や優先順位を明確にする
正確性や信頼性といった品質は決して犠牲にできない

予算感の認識を早めに合わせる

haru：参加者から「見積もりにおいて、どの要素を重視・優先するのかという価値基準、いわゆるトレードオフスライダーの認識を、事前にすり合わせておくことが重要だと考えています。この点について、どのようなお考えをお持ちでしょうか？」という質問が来ています。いかがでしょうか。

高崎：見積りを行う上で予算感の把握は欠かせないため、「ご予算はどの程度をお考えですか？」といった点は、私は必ず確認するようにしています。

haru：最初の段階で、聞くんですか。

高崎：はい、私は比較的早い段階で予算感を確認するようにしています。

「ご予算の目安はどれくらいですか？」といった率直な問いかけを通じて、早めに信頼関係を築くことが重要です。

あえて初期段階で核心に触れる質問をすることは、ある意味リスクを伴う行為ですが、「遠慮なく本音で話せる相手だ」と感じてもらえることで、以降のコミュニケーションも円滑になります。

予算を超えてしまう場合は仕方ありません。その前提のもとで、実現すべき内容をどのように絞り込んでいくかがポイントになります。

そうしたとき、提供された情報をいかに構造的に整理できるかが問われます。

私はそのフェーズで、RDRAを使うことが多いです。型に沿って情報を可視化・整理することで、要素の漏れや重複に気づけるようになります。整理が進むと、「このプロジェクトではこういうものを作るのだな」という全体像が自然と浮かび上がってきます。

また、要望をヒアリングする中で、お客さまが本当に重視していること、つまりプロジェクトの目的や背景が見えてくる瞬間があります。RDRAは、そうした本質的な意図を引き出す助けにもなります。

こうした対話の積み重ねによって、お客さまの中にある「トレードオフスライダー」（何を優先し、何を後回しにするのかの基準）を、自分の中に取り込めている感覚になります。

そこまで共有できていれば、「この2つのうち、こちらを優先し、もう一方を外す方向で考えていますが、よろしいでしょうか？」と確認すれば、多くの場合スムーズに合意が得られます。

haru：まずはRDRAのようなフレームワークに当てはめてみることで、抜けや隙間に気づく。それがスタート地点になる、ということですね。

開発初期段階では予算感を共有しながら、お客様との信頼関係を築いていく必要があります。このプロセスには、豊富な経験とスキルが求められますね（笑）

高崎：やはり名人芸なのでしょうか（笑）

大切なのは「お客さまが何をやりたくてこのプロジェクトに取り組んでいるのか」といった本質的な部分を捉えることだと思います。

要件をツリー構造で整理し、相互の依存関係や優先順位を明確にする

神崎：見積もりを提示する側が、「どの要件同士がトレードオフの関係にあるのか」を明確に伝えることは、非常に重要だと思います。

たとえば高崎さんが仰っていた「何が大事で、何が最も重要なのか」という視点を出発点に、そこから派生する要件をツリー状に整理し、関係性を構造的に示すことで、「この選択肢を優先すると、こちらは削る必要があります」といった具体的な対立構造を共有できます。

こうした整理があれば、依頼側も判断しやすくなり、納得感のある意思決定につながるはずです。

haru：要求をツリー構造で整理するのは非常に有効ですね。単に箇条書きで羅列されているだけでは、重要度や関係性が見えづらく、全体像をつかむのが難しいです。

特に、「ビジネス上の目的」「業務としての実現手段」「ITやシステムとしての具体的な機能」というように、3層構造で整理すると、どの機能がどの目的に紐づいているのかが明確になります。

機能だけに注目して議論を進めてしまうと、最下層の手段だけを見てしまい、その上位にある目的や背景が見落とされがちです。

その結果、本来優先すべき要件を取りこぼしてしまい、後になって「そもそも何のために？」という根本的な問題が表面化するリスクがあります。

濱井：いまの「ツリー構造」という話は、IIBA*4のBABOKガイド*5でいう「要求アーキテクチャ」に相当します。

経営レベルの戦略的な要求である『ビジネス要求』、『ステークホルダー要求』、『ソリューション要求』といった下位の要素へと階層的に整理し、それぞれの関係性を明示しながら、優先順位をつけて取捨選択していくという考え方です。

正確性や信頼性といった品質は決して犠牲にできない

濱井： QCD（品質：Quality、費用：Cost、納期：Delivery）のトレードオフで品質を削るという話が出ることもありますが、私は動作の正確さや信頼性といったシステムの根幹を成す品質を犠牲にするという考え方には否定的です。

一方で、品質を犠牲にするというより、例えば「UIは最低限でもよい」といった見た目や使い勝手の調整などは、優先順位に応じたスコープの整理として受け入れられると考えています。

これは品質を削るのではなく、注力する領域を明確にするということです。

そのためにも、要求同士の関係や影響を構造的に把握し、バランスを取りながらお客さまと合意形成を進めていくことが、見積もりや要件定義のプロセスにおいて非常に重要だと感じています。

haru：システム開発においては、「安かろう悪かろう」という考え方は通用しません。基盤的な品質を犠牲にした低コストな開発は、結果的に大きなリスクを生むからです。

仮に「最低限でいいので安くお願いします」と依頼されたとしても、後になって「こんなはずじゃなかった」とトラブルになるケースは少なくありません。

当初はお客さまも納得していたように見えても、実際に使い始めてから不満が表面化することが多いです。

だからこそ、初期段階で品質・コスト・納期のバランスを丁寧にすり合わせておくことが不可欠です。

次回は『過去プロジェクトを活かした見積りのつくり方』というテーマで話が進みます。

tracery.jp

この記事を書いた人