見積もりがズレる根本原因は「要件定義」にあった｜現場で使える実践テクニック

こんにちは！

今日は「見積もりがズレる根本原因と、それを防ぐための要件定義のコツ」について解説します。

見積もり失敗あるある：僕の失敗談から学ぶ

僕もフロントエンジニアから制作ディレクターにキャリアチェンジした当初、見積もりでめっちゃ失敗しました。
ある案件の話なんですけど、クライアントから「コーポレートサイトをリニューアルしたい」と言われて、その場で工数を見積もってしまったんです。
「ページ数が5ページくらいだから、デザイン・コーディング・テストで約3週間ですね」と。

ところが蓋を開けてみたら、実際には「各ページに複雑なアニメーション実装が必要」「問い合わせフォームはシステム連携が必要」「既存データベースとの連携もある」という隠れた要件がてんこ盛り。
結果、予定の倍近い期間がかかってしまいました。
クライアント対応も大変やったし、チームにも迷惑をかけてしまいました。

この失敗を通じて気づいたのが、「見積もりの精度は、要件定義の質に100%依存する」ということです。
見積もりがズレるのって、実は工数の計算ミスじゃなくて、最初の要件定義が甘いせいなんですよ。

要件定義が曖昧だと、なぜ見積もりがズレるのか

現場でよく見るのが、こんなパターンです。

• クライアント：「スマートフォン対応のサイトをお願いします」
• ディレクター：「わかりました、レスポンシブ対応ですね」

一見、会話が成立してるように見えますよね。
でも実は全然噛み合ってないんです。

• クライアントの本当の要望：「iPhone 12以上でキレイに見えればいい、古いAndroidは気にしなくていい」
• ディレクターが見積もったもの：「全スマートフォン・タブレット・デスクトップすべてで完璧に対応」

このズレがあると、着手後に「あれ、思ってたのと違う」って話になっちゃう。
その結果、追加工数が発生して見積もりがオーバーしたり、クライアント満足度が下がったりするわけです。

見積もりがズレる根本原因をまとめると：

• 曖昧な言葉の使用：「キレイに」「最新的な」「使いやすい」などの主観的な表現がそのまま要件になってる
• 前提条件の不確認：「スマートフォン対応」といってもブレークポイント、サポート端末、パフォーマンス要件が明確でない
• 制約条件の見落とし：予算・期間・人員・既存システムとの連携など、現場で発見される条件がある
• スコープの不明確さ：「実装範囲」と「対象外」の線引きが曖昧になってる

これらが全部揃うと、見積もりはもう当てにならんわけです。

現場で使える「要件ヒアリングシート」の活用法

僕が今実践してるのが、ヒアリング段階で要件定義書の雛形を使うことなんです。
「その場で見積もる」じゃなくて、「一度持ち帰って、要件を整理してから見積もる」という流れにしました。

具体的には、こんなシートを使ってます：

• プロジェクト基本情報：案件名、クライアント、予算感、期間希望
• 目的・ゴール：このサイト・システムで何を達成したいのか
• ターゲット層：ユーザー属性、使用環境（デバイス・ブラウザ・ネットワーク環境）
• 具体的な機能要件：ページ数、必要な機能、外部連携、データ処理
• 非機能要件：セキュリティ、パフォーマンス、アクセシビリティ、SEO対策など
• 保守・運用の要件：更新頻度、CMS導入の必要性、保守契約
• 制約条件：予算、期間、利用可能な技術スタック、既存システムとの連携

このシートをクライアントと一緒に埋めていく過程で、こちらが「あ、この部分、クライアントの要望と僕の想像がズレてたな」ってことに気づけるんです。
早めにズレを発見できれば、そこから正確な見積もりができます。

重要なのは、質問を「オープンクエスチョン」にすることですよ。
「スマートフォン対応ですね」じゃなくて「スマートフォンではどのような使い方をしてほしいと思ってますか？」みたいに、クライアントに考えてもらう質問をするんです。
そうするとほんま、色んな本音が出てきます。

クライアントとの認識ズレを防ぐ3つの約束事

要件定義の段階で、クライアントと3つの約束を決めとくといいですよ。

1. 「スコープの枠」を明確にする

見積もり提出時に、「このサイトには以下の機能が含まれます。含まれません」という表を作って提示します。
例えば：

• 含まれるもの：トップページ、企業情報ページ、サービス紹介ページ、問い合わせフォーム、基本的なレスポンシブ対応
• 含まれないもの：ブログ機能、会員システム、複雑なアニメーション、特殊なデータベース構築

このリストを合意書に含めることで、後々「あ、ブログ機能も実装されると思ってた」なんてトラブルを防げます。

2. 「修正の範囲」を定義する

納品後に「このボタンのサイズを変えてほしい」「この文言を修正してほしい」という修正依頼が必ず来ます。
その時に「これはスコープ内か、追加費用が必要か」を判断するための基準を最初から決めとくんです。

例：「納品後30日間は、軽微な修正（文字修正、色変更、画像差し替え等）は無料。
機能追加や大幅な仕様変更は別途見積もり」みたいに。

3. 「何かあったら事前相談」という契約文化を作る

制作側が「あ、この要件だと見積もり期間では無理かもな」って気づい