Skip to content

見積もり完全ガイド

見積もりの実践的な手法を、実務で使える実装例とベストプラクティスとともに詳しく解説します。

見積もりは、プロジェクトの工数、コスト、期間、リソースを予測する活動です。

見積もりの目的
├─ 予算の計画
├─ スケジュールの計画
├─ リソースの計画
├─ リスクの評価
└─ 意思決定の支援
## 見積もりの種類
### 1. 工数見積もり
- **単位**: 人日、人時
- **用途**: 開発工数の見積もり
- ****: 10人日、80人時
### 2. コスト見積もり
- **単位**: 円、ドル
- **用途**: プロジェクトの予算見積もり
- ****: 500万円、50,000ドル
### 3. 期間見積もり
- **単位**: 日、週、月
- **用途**: プロジェクトの期間見積もり
- ****: 3ヶ月、12週間
### 4. リソース見積もり
- **単位**: 人数、サーバー台数
- **用途**: 必要なリソースの見積もり
- ****: 5名、10台

三点見積もりは、楽観値、悲観値、最頻値から期待値を計算する手法です。

## 三点見積もりの計算
### パラメータ
- **楽観値(O)**: 最良のケースでの見積もり
- **悲観値(P)**: 最悪のケースでの見積もり
- **最頻値(M)**: 最も可能性の高い見積もり
### 計算式
期待値(E) = (O + 4M + P) / 6
標準偏差(σ) = (P - O) / 6
### 例: ユーザー認証機能の実装
- **楽観値(O)**: 3日(すべてが順調に進む場合)
- **最頻値(M)**: 5日(通常の場合)
- **悲観値(P)**: 8日(問題が発生する場合)
期待値(E) = (3 + 4×5 + 8) / 6 = 5.17日
標準偏差(σ) = (8 - 3) / 6 = 0.83日
**見積もり: 6日(切り上げ)**

ストーリーポイントは、相対的な複雑さを表す見積もり手法です。

## ストーリーポイント
### フィボナッチ数列
1, 2, 3, 5, 8, 13, 21, 34, 55, 89
### ポイントの意味
- **1ポイント**: 非常に簡単(1時間程度)
- **2ポイント**: 簡単(半日程度)
- **3ポイント**: 普通(1日程度)
- **5ポイント**: やや複雑(2-3日程度)
- **8ポイント**: 複雑(1週間程度)
- **13ポイント**: 非常に複雑(2週間程度、分割を検討)
- **21ポイント以上**: 分割必須
### ベロシティの計算
ベロシティ = 1スプリントで完了したストーリーポイントの合計
例:
- スプリント1: 13ポイント完了
- スプリント2: 21ポイント完了
- スプリント3: 18ポイント完了
平均ベロシティ = (13 + 21 + 18) / 3 = 17.3ポイント/スプリント

Planning Poker(プランニングポーカー)

Section titled “Planning Poker(プランニングポーカー)”

Planning Pokerは、チームで見積もりを行う手法です。

## Planning Pokerの手順
### 1. 準備
- フィボナッチ数列のカードを準備(1, 2, 3, 5, 8, 13, 21)
- チームメンバー全員が参加
### 2. 実施
1. **ストーリーの説明**: プロダクトオーナーがストーリーを説明
2. **質問**: チームメンバーが質問
3. **見積もり**: 各自がカードを選ぶ(同時に公開)
4. **議論**: 見積もりが大きく異なる場合、理由を議論
5. **再見積もり**: 議論後、再度見積もり
6. **合意**: チームで合意するまで繰り返す
### 3. メリット
- チーム全体の知識を活用
- バイアスを減らす
- 議論を通じて理解が深まる

COCOMOは、ソフトウェア開発の工数とコストを推定するモデルです。

## COCOMOモデル
### 基本COCOMO
工数(人月) = a × (KLOC)^b
### パラメータ
- **a**: 2.4(有機的)、3.0(半分離)、3.6(埋め込み)
- **b**: 1.05(有機的)、1.12(半分離)、1.20(埋め込み)
- **KLOC**: コード行数(千行)
### 例: 10,000行のコード(有機的プロジェクト)
工数 = 2.4 × (10)^1.05 = 2.4 × 11.22 = 26.9人月
期間 = 2.5 × (工数)^0.38 = 2.5 × (26.9)^0.38 = 2.5 × 3.5 = 8.75ヶ月
必要人数 = 工数 / 期間 = 26.9 / 8.75 = 3.4人

ファンクションポイント法は、機能の複雑さから工数を推定する手法です。

## ファンクションポイント法
### 機能の分類
1. **外部入力(EI)**: ユーザーからの入力
2. **外部出力(EO)**: ユーザーへの出力
3. **外部問い合わせ(EQ)**: 外部からの問い合わせ
4. **内部論理ファイル(ILF)**: 内部データ
5. **外部インターフェースファイル(EIF)**: 外部データ
### 複雑さの評価
- **単純**: 1-4データ要素
- **普通**: 5-15データ要素
- **複雑**: 16以上のデータ要素
### ポイントの計算
各機能の複雑さに応じてポイントを付与し、合計を計算
## WBSの例: ECサイト開発プロジェクト
プロジェクト: ECサイト開発
├─ 1. 要件定義(5人日)
│ ├─ 1.1 ヒアリング(2人日)
│ ├─ 1.2 要件定義書作成(2人日)
│ └─ 1.3 承認(1人日)
├─ 2. 設計(15人日)
│ ├─ 2.1 システム設計(5人日)
│ ├─ 2.2 データベース設計(5人日)
│ └─ 2.3 UI/UX設計(5人日)
├─ 3. 実装(40人日)
│ ├─ 3.1 フロントエンド開発(20人日)
│ │ ├─ 3.1.1 認証機能(5人日)
│ │ ├─ 3.1.2 商品一覧(5人日)
│ │ ├─ 3.1.3 カート機能(5人日)
│ │ └─ 3.1.4 決済機能(5人日)
│ └─ 3.2 バックエンド開発(20人日)
│ ├─ 3.2.1 API開発(10人日)
│ └─ 3.2.2 データベース実装(10人日)
├─ 4. テスト(15人日)
│ ├─ 4.1 単体テスト(5人日)
│ ├─ 4.2 結合テスト(5人日)
│ └─ 4.3 システムテスト(5人日)
└─ 5. デプロイ(5人日)
├─ 5.1 本番環境構築(2人日)
├─ 5.2 デプロイ(2人日)
└─ 5.3 動作確認(1人日)
**合計: 80人日**
## ボトムアップ見積もりの手順
1. **WBSの作成**: プロジェクトを小さなタスクに分解
2. **各タスクの見積もり**: 各タスクを個別に見積もり
3. **合計の計算**: すべてのタスクの見積もりを合計
4. **バッファの追加**: リスクを考慮してバッファを追加
5. **全体の見積もり**: 最終的な見積もりを決定
## ベロシティの計算
### 過去のスプリントから計算
スプリント1: 13ポイント
スプリント2: 21ポイント
スプリント3: 18ポイント
スプリント4: 16ポイント
スプリント5: 19ポイント
平均ベロシティ = (13 + 21 + 18 + 16 + 19) / 5 = 17.4ポイント/スプリント
### 期間の見積もり
残りのストーリーポイント: 100ポイント
平均ベロシティ: 17.4ポイント/スプリント
必要スプリント数 = 100 / 17.4 = 5.7スプリント
**6スプリント(切り上げ)**
## ベロシティの調整要因
### 1. チームメンバーの変更
- 新しいメンバーが加入: ベロシティが一時的に低下
- 経験豊富なメンバーが加入: ベロシティが向上
### 2. 技術的な複雑さ
- 新しい技術の導入: ベロシティが一時的に低下
- 慣れ親しんだ技術: ベロシティが向上
### 3. 外部要因
- 休暇、病欠: ベロシティが低下
- 集中できる環境: ベロシティが向上
## リスクバッファの設定
### リスクレベルによるバッファ
- **低リスク**: 10-15%のバッファ
- **中リスク**: 20-30%のバッファ
- **高リスク**: 30-50%のバッファ
### 例: 中リスクプロジェクト
基本見積もり: 80人日
リスクバッファ(25%): 20人日
**最終見積もり: 100人日**
## リスク要因の評価
### 技術的リスク
- **新技術の使用**: +20-30%
- **既存技術の使用**: +0-10%
- **技術的負債の解消**: +10-20%
### プロジェクトリスク
- **要件の不明確さ**: +20-30%
- **要件の明確さ**: +0-10%
- **ステークホルダーの変更**: +10-20%
### チームリスク
- **新しいチーム**: +20-30%
- **経験豊富なチーム**: +0-10%
- **リモートワーク**: +5-15%
## 見積もりの精度レベル
### レベル1: 概算見積もり(-50% ~ +100%)
- **タイミング**: プロジェクト開始前
- **精度**: 低い
- **用途**: 初期の意思決定
### レベル2: 概算見積もり(-25% ~ +50%)
- **タイミング**: 要件定義後
- **精度**: 中程度
- **用途**: 予算の申請
### レベル3: 確定見積もり(-10% ~ +25%)
- **タイミング**: 設計完了後
- **精度**: 高い
- **用途**: 詳細な計画
### レベル4: 確定見積もり(-5% ~ +10%)
- **タイミング**: 実装開始前
- **精度**: 非常に高い
- **用途**: 最終的な計画
## 見積もり精度向上の方法
### 1. 過去のデータの活用
- **類似プロジェクト**: 過去の類似プロジェクトのデータを参照
- **実績データ**: 実際の工数データを蓄積
- **ベロシティ**: チームのベロシティを記録
### 2. 複数の手法の組み合わせ
- **三点見積もり + WBS**: 複数の手法で見積もり
- **複数メンバー**: 複数のメンバーで見積もり
- **平均値の使用**: 複数の見積もりの平均を使用
### 3. 定期的な見直し
- **マイルストーンごと**: マイルストーンごとに見積もりを見直し
- **スプリントごと**: スプリントごとにベロシティを更新
- **実績との比較**: 実績と見積もりを比較し、調整
## 見積もりの更新タイミング
### 1. 要件の変更
- **新機能の追加**: 見積もりを追加
- **機能の削除**: 見積もりを削減
- **要件の変更**: 見積もりを再計算
### 2. リスクの変化
- **新リスクの発生**: バッファを追加
- **リスクの解消**: バッファを削減
- **リスクの影響度の変化**: バッファを調整
### 3. 実績との乖離
- **実績が予定より遅い**: 見積もりを上方修正
- **実績が予定より早い**: 見積もりを下方修正
- **ベロシティの変化**: ベロシティを更新
## 見積もりの調整方法
### 1. スコープの調整
- **機能の優先順位**: 優先度の低い機能を削除
- **機能の簡略化**: 機能を簡略化
- **フェーズ分け**: 後続フェーズに延期
### 2. リソースの調整
- **人員の追加**: 人員を追加して期間を短縮
- **外部リソース**: 外部リソースを活用
- **スキルの向上**: スキルアップで効率化
### 3. スケジュールの調整
- **期間の延長**: 期間を延長
- **並行作業**: 並行作業を推進
- **バッファの活用**: バッファを活用

Webアプリケーション開発の見積もり

Section titled “Webアプリケーション開発の見積もり”
## Webアプリケーション開発の見積もり例
### プロジェクト概要
- **プロジェクト名**: ECサイト開発
- **チーム規模**: 5名(PM 1名、フロントエンド 2名、バックエンド 2名)
- **期間**: 3ヶ月
### フェーズ別見積もり
#### 1. 要件定義(10人日)
- ヒアリング: 3人日
- 要件定義書作成: 5人日
- 承認: 2人日
#### 2. 設計(20人日)
- システム設計: 8人日
- データベース設計: 6人日
- UI/UX設計: 6人日
#### 3. 実装(60人日)
- フロントエンド: 30人日
- 認証機能: 8人日
- 商品一覧: 7人日
- カート機能: 8人日
- 決済機能: 7人日
- バックエンド: 30人日
- API開発: 15人日
- データベース実装: 15人日
#### 4. テスト(20人日)
- 単体テスト: 8人日
- 結合テスト: 7人日
- システムテスト: 5人日
#### 5. デプロイ(10人日)
- 本番環境構築: 4人日
- デプロイ: 4人日
- 動作確認: 2人日
### 合計とバッファ
- **基本見積もり**: 120人日
- **リスクバッファ(25%)**: 30人日
- **最終見積もり**: 150人日
### 期間の計算
- **必要人数**: 5名
- **稼働日数**: 150人日 / 5名 = 30日
- **カレンダー日数**: 30日 / 0.8(稼働率) = 37.5日
- **最終期間**: 約2ヶ月(40営業日)
## API開発の見積もり例
### エンドポイント別見積もり
| エンドポイント | 複雑さ | 見積もり(人日) |
|---------------|--------|-----------------|
| POST /auth/login | 低 | 1 |
| POST /auth/register | 中 | 2 |
| GET /products | 低 | 1 |
| GET /products/:id | 低 | 1 |
| POST /products | 中 | 2 |
| PUT /products/:id | 中 | 2 |
| DELETE /products/:id | 低 | 1 |
| POST /orders | 高 | 3 |
| GET /orders | 中 | 2 |
| GET /orders/:id | 低 | 1 |
**合計: 16人日**
### その他の作業
- 認証ミドルウェア: 2人日
- エラーハンドリング: 2人日
- テスト: 5人日
- ドキュメント: 2人日
**追加作業: 11人日**
### 最終見積もり
- **基本見積もり**: 27人日
- **リスクバッファ(20%)**: 5.4人日
- **最終見積もり**: 33人日(切り上げ)
## よくある失敗パターン
### 1. 楽観的な見積もり
**問題**: 最良のケースのみを想定
**対策**: 三点見積もりを使用、リスクを考慮
### 2. 詳細の不足
**問題**: タスクの分解が不十分
**対策**: WBSを作成、詳細に分解
### 3. リスクの無視
**問題**: リスクを考慮しない
**対策**: リスクバッファを設定、リスク要因を評価
### 4. 過去のデータの無視
**問題**: 過去の実績を活用しない
**対策**: 実績データを蓄積、ベロシティを記録
### 5. 見積もりの更新不足
**問題**: 見積もりを更新しない
**対策**: 定期的に見積もりを見直し、実績と比較
### 6. 圧力による見積もりの歪み
**問題**: ステークホルダーの圧力で見積もりを下げる
**対策**: データに基づいた見積もり、透明性の確保

見積もりのベストプラクティス

Section titled “見積もりのベストプラクティス”
## 見積もりのベストプラクティス
### 1. 複数の手法を組み合わせる
- **三点見積もり + WBS**: 複数の手法で見積もり
- **複数メンバー**: チーム全体で見積もり
- **過去のデータ**: 実績データを活用
### 2. 詳細に分解する
- **WBSの作成**: プロジェクトを小さなタスクに分解
- **見積もり可能なサイズ**: 1-3日程度のタスクに分解
- **依存関係の明確化**: タスク間の依存関係を明確に
### 3. リスクを考慮する
- **リスクバッファ**: 適切なバッファを設定
- **リスク要因の評価**: リスク要因を評価
- **不確実性の表現**: 見積もりの範囲を表現
### 4. 定期的に見直す
- **マイルストーンごと**: マイルストーンごとに見直し
- **実績との比較**: 実績と見積もりを比較
- **ベロシティの更新**: ベロシティを定期的に更新
### 5. 透明性を確保する
- **見積もりの根拠**: 見積もりの根拠を明確に
- **前提条件**: 前提条件を明記
- **不確実性**: 不確実性を率直に伝える
## 見積もりテンプレート
### プロジェクト情報
- **プロジェクト名**:
- **見積もり日**:
- **見積もり者**:
- **見積もりバージョン**:
### 見積もり概要
- **基本見積もり**: 人日
- **リスクバッファ**: 人日(%)
- **最終見積もり**: 人日
- **期間**: 日/週/月
- **必要人数**: 名
### 前提条件
-
-
-
### リスク要因
-
-
-
### 見積もり詳細
| タスク | 見積もり(人日) | 備考 |
|--------|-----------------|------|
| | | |
| | | |
### 見積もりの精度
- **精度レベル**:
- **信頼区間**: ±%
### 更新履歴
| 日付 | バージョン | 変更内容 | 変更者 |
|------|-----------|---------|--------|
| | | | |

見積もり完全ガイドのポイント:

  • 見積もり手法: 三点見積もり、ストーリーポイント、Planning Poker、COCOMO、ファンクションポイント
  • WBS: 作業の詳細な分解とボトムアップ見積もり
  • ベロシティ: チームの生産性の測定と活用
  • リスク: リスクバッファとリスク要因の評価
  • 精度向上: 過去のデータの活用、複数手法の組み合わせ
  • 更新と調整: 定期的な見直しと実績との比較
  • 実践例: Webアプリケーション、API開発の見積もり例
  • 失敗パターン: よくある失敗と対策
  • ベストプラクティス: 実践的なベストプラクティス

適切な見積もりにより、成功するプロジェクトを構築できます。