費用・発注ガイド
見積もりが3倍ブレる原因：画面数・機能・ロール設計の整理法
開発見積もりが大幅にブレる主な原因と、画面数・機能・ロール設計を整理する方法を解説します。発注前の準備で費用を安定させる方法も紹介。
「3社に見積もりを取ったら、100万円・180万円・300万円と3倍以上の差が出た」。これはよくある話で、どこかの会社がぼったくっているわけではない。要件の解釈が違うから、見積もりがバラけるのだ。
見積もりがブレる原因は主に3つある。画面数の定義の曖昧さ、機能の状態数の未把握、権限設計の未確定。この3つを事前に整理するだけで、見積もりの幅は「100〜300万円」から「120〜150万円」程度まで絞り込める。
なぜ見積もりが3倍以上ブレるのか
「機能が同じなのになぜ金額が違うのか」と思うかもしれないが、エンジニアが見積もる際に想定する「実装の中身」が全く違う。
たとえば「ログイン画面」を実装するとき、発注者が思い浮かべるのは「メールアドレスとパスワードを入れる画面」だ。でもエンジニアが考えるのは以下の全部だ。
| 状態 | 内容 |
|---|---|
| ログインフォーム（通常状態） | メールとパスワードの入力 |
| バリデーションエラー状態 | 「パスワードが違います」の表示 |
| ローディング状態 | 送信中のスピナー表示 |
| パスワードリセット画面 | メールアドレス入力フォーム |
| パスワードリセットメール送信後 | 「メールを送りました」の確認画面 |
| 新しいパスワード設定画面 | リンクからアクセスする画面 |
| ソーシャルログイン | GoogleやGitHubのOAuth連携 |
「ログイン画面1つ」が実装上は7〜10の状態を持つ。発注者が「1画面」と数えているものが、エンジニアには「8状態」に見える。この認識のズレが見積もりをブレさせる。
ブレの原因1：画面数の定義が曖昧
画面数を「10画面のアプリです」と伝えると、エンジニアは「10種類のページがある」と解釈するが、それぞれのページに何状態あるかが分からないと工数が算定できない。
よくある「1画面」の実際の状態数
| 画面名 | 発注者が思う状態数 | 実装上の状態数 |
|---|---|---|
| ログイン画面 | 1 | 6〜8 |
| ダッシュボード | 1 | 3〜5（データあり・空・エラー） |
| リスト画面 | 1 | 4〜6（空・ローディング・ページネーション・エラー） |
| 詳細画面 | 1 | 3〜4（通常・編集モード・削除確認） |
| フォーム画面 | 1 | 4〜6（入力・バリデーション・送信中・完了） |
「10画面」と言っても、合計の状態数が30なのか80なのかで工数が2〜3倍変わる。
整理の方法
発注前に「画面一覧」を以下の形式で作る。
画面名：ユーザー一覧
- 通常表示（データあり）
- 空状態（データなし）
- ローディング中
- 検索結果表示
- 検索結果なし
- ページネーション
権限による差分：
- 管理者：編集ボタン・削除ボタンを表示
- 一般ユーザー：閲覧のみ
この形式で全画面分を書くのが理想だが、主要な5〜6画面だけでも書いておくと見積もりの精度が大幅に上がる。
ブレの原因2：機能の「中身」が見えていない
「検索機能」と言っても、実装量は全く違う。
- テキスト検索だけ：0.5日
- カテゴリ絞り込み追加：+0.5日
- 日付範囲フィルター：+1日
- 複数条件の組み合わせ：+1〜2日
- 全文検索（Supabase FTS）：+1〜2日
- 検索履歴の保存：+1日
「検索機能を実装してください」という依頼に対して、ある会社は「テキスト検索」と解釈し、別の会社は「複数条件の絞り込み込み」と解釈する。その結果、見積もりが0.5日と5日で10倍変わる。
機能ごとの中身を整理するフォーマット
機能名：通知機能
- メール通知：〇（新規登録時・パスワードリセット時）
- アプリ内通知：〇（コメントがついたとき）
- プッシュ通知：× （今回は対象外）
- Slack通知：× （今回は対象外）
メール通知の詳細：
- 使用サービス：Resend
- テンプレート数：2種類
- HTMLデザイン：〇（ブランドカラーに合わせる）
「今回は対象外」を明示することも重要だ。書かないと「含まれている」と解釈されることがある。
ブレの原因3：権限・ロール設計の未確定
「管理者と一般ユーザーの2種類があります」という説明を受けると、シンプルに聞こえる。でも実装すると、見えてくるのは以下のような複雑さだ。
「管理者」が持つ権限の例（実際には1つひとつ実装が必要）
- ユーザー一覧の閲覧
- ユーザーの無効化・有効化
- コンテンツの編集（他のユーザーのコンテンツも）
- コンテンツの削除
- 統計データの閲覧
- エクスポート機能
- 料金プランの変更
- 請求情報の確認
「一般ユーザー」との差分
- 自分のコンテンツのみ編集可能
- 他のユーザーの情報は見えない
- 管理機能にはアクセスできない
「管理者と一般ユーザー」は2種類に聞こえるが、権限チェックの実装は15〜20か所になることがある。各APIエンドポイント、各画面の表示切り替え、各ボタンの有効/無効、それぞれに権限チェックを入れる必要があるからだ。
さらに「スタッフ」「閲覧者のみ」など中間のロールが後から追加されると、既存の権限設計を大きく書き換えることになる。最初から「ロールは3種類：管理者・スタッフ・一般ユーザー」と決めておけば、実装を一度で終わらせられる。
整理前後で見積もりはどう変わるか
同じプロジェクトでも、要件の整理状況によって見積もりの幅が大きく変わる。
整理前の状況
- 「10画面くらいのWebアプリ」
- 「管理者と一般ユーザーがいる」
- 「検索と通知がある」
この状態で見積もりを取ると：80万〜280万円（3〜4社からの回答）
整理後の状況
- 全10画面の状態一覧（各画面3〜5状態）
- ロール3種類の権限マトリクス
- 機能8項目の詳細（対象外も明記）
この状態で見積もりを取ると：120万〜160万円（同じ3〜4社からの回答）
整理によって費用が下がるわけではないが、見積もりの幅が縮まる。120万〜160万なら「どこに頼むか」を判断できるが、80万〜280万では判断できない。
発注前の整理：ステップバイステップ
Step 1：画面一覧を作る（30分）
スプレッドシートに画面名を全部書き出す。Figmaがあるならそこから転記する。
Step 2：各画面の状態を書く（60分）
各画面に対して「どんな状態がありうるか」を書き出す。空状態・エラー状態・ローディング状態は必ず考える。
Step 3：機能の中身を箇条書きにする（30分）
「検索」「通知」「決済」など各機能について、「何と何が含まれるか」「何は含まれないか」を書く。
Step 4：ロールと権限を表にする（30分）
ロール（管理者・スタッフ・一般など）を横軸、機能や操作を縦軸にした表を作る。各セルに「〇（可）」「×（不可）」「閲覧のみ」を書く。
この4ステップ合計2〜3時間の作業が、見積もりの精度を大きく変える。