project-sizing-guide

プロジェクト規模ガイド — ソフトウェアプロジェクトの工数見積もり

Three-Point Estimation（PERT）、T-shirt Sizing、Function Point Analysis（FPA）の3つの主要な手法に基づき、チームが科学的根拠のあるソフトウェアプロジェクトの工数見積もりを作成できるようにします。楽観値、最頻値、悲観値とともに、リスク区間を出力します。

クイックスタート

1. ユーザーが要件の説明を提示します → エージェントが機能モジュールを特定し、Work Breakdown Structure（WBS）に分解します
2. 見積もり手法を選択します → プロジェクトの段階と利用可能な情報に基づき、最適なアプローチを選択します
3. 各項目を見積もります → すべての作業パッケージにO/M/P（楽観値／最頻値／悲観値）を割り当てます
4. 集計して報告します → リスク分析と信頼区間を含む見積もりレポートを作成します

計算ヘルパーを利用できます：

python3 scripts/estimate_calculator.py --method pert --tasks '[{"name":"User Login","O":2,"M":3,"P":8}]'

---

手法選択ガイド

シナリオ	推奨手法	根拠
初期の実現可能性調査、概算予算の策定	T-shirt Sizing	利用可能な情報が少ないため、概算の規模をすばやく合意できます
スプリント計画、イテレーションの見積もり	Three-Point Estimation（PERT）	信頼区間を含む適切な粒度の見積もりができます
契約入札、大規模プロジェクトのRFP	Function Point Analysis（FPA）	最も厳密で、業界内で比較可能です
チームに過去のデータがある	PERT + 過去データによる調整	実績に基づく補正とデータを組み合わせます

---

手法1：Three-Point Estimation（PERT）

基本公式

指標	公式	意味
期待値 E	(O + 4M + P) / 6	加重平均工数
標準偏差 σ	(P − O) / 6	見積もりの不確実性
分散 V	σ²	タスク間の集計に使用
プロジェクト全体の期待値	ΣE	個々の期待値の合計
プロジェクト全体の標準偏差	√(ΣV)	分散の合計の平方根

ここで：

• O（楽観値）：すべてが順調に進むと仮定した場合の最短期間
• M（最頻値）：通常の状況での期間
• P（悲観値）：重大な困難が発生した場合の最長期間

信頼区間

信頼水準	区間	用途
68.3%	E ± 1σ	社内向けの概算見積もり
90%	E ± 1.645σ	プロジェクト計画
95%	E ± 2σ	外部向けの見積もり
99.7%	E ± 3σ	契約上のコミットメント

手順

1. WBSを作成します：要件を個別に見積もり可能な最小単位まで分解します（それぞれ5人日以下を推奨）
2. 三点見積もりを行います：各作業パッケージにO / M / Pの値を設定します（人時または人日など、単位を統一してください）
3. タスクごとの期待値と標準偏差を計算します
4. プロジェクトレベルの指標を集計します：全体の期待値 = ΣE、全体の標準偏差 = √(Σσ²)
5. 信頼区間を出力します：リスク許容度に基づいて信頼水準を選択します

O/M/P見積もりの経験則

• OはMの30%未満にしないでください（楽観的すぎる場合、必須の工程を見落としている可能性があります）
• PはMの5倍を超えないようにしてください（悲観的すぎる場合、要件が不明確で、先に明確化する必要があることを示唆しています）
• O ≈ M ≈ Pの場合、そのタスクは非常によく理解されているか、見積もり担当者がリスクを十分に検討していません
• P/O比（ばらつき比）は不確実性を表します：< 2 = 低リスク、2–4 = 中リスク、> 4 = 高リスク

---

手法2：T-shirt Sizing

サイズ参照表

サイズ	一般的な範囲（人日）	一般的なストーリーポイント	適した作業
XS	0.25 – 0.5	1	設定変更、コピーの修正、簡単なバグ修正
S	0.5 – 2	2 – 3	単一コンポーネントの開発、シンプルな API、軽微な UI の調整
M	2 – 5	5 – 8	機能モジュール全体、中程度に複雑な API
L	5 – 15	13 – 21	統合が必要なモジュール横断型の機能
XL	15 – 40	34 – 55	アーキテクチャ設計が必要なサブシステムレベルの開発
XXL	40+	89+	複数のイテレーションに分割する必要があります。単一の見積もり単位としては推奨されません

T シャツサイズを三点見積もりに換算する

より正確な数値が必要な場合は、T シャツサイズを三点見積もりに換算できます。

サイズ	O（人日）	M（人日）	P（人日）
XS	0.25	0.5	1
S	0.5	1	2.5
M	2	3.5	7
L	5	10	20
XL	15	25	50
XXL	40	70	150

手順

1. チーム内で認識を合わせる：各サイズの意味を確認します（上の表は参考値であり、チームごとにカスタマイズできます）
2. 個別に評価する：アンカリングバイアスを避けるため、各メンバーが個別にサイズを割り当てます
3. 差異について話し合う：見積もりに 2 サイズを超える差がある場合は、必ず話し合います
4. 合意に達する：チームで合意した値を採用します
5. 数値に換算する（任意）：上の表を使って O/M/P の値を算出します

---

方法 3：ファンクションポイント分析（FPA）

5 つの機能コンポーネントの種類

コンポーネントの種類	略称	定義	例
内部論理ファイル	ILF	アプリケーションが維持管理する論理データグループ	Users テーブル、Orders テーブル
外部インターフェースファイル	EIF	アプリケーションが参照するが、維持管理はしないデータグループ	サードパーティの為替レートデータ
外部入力	EI	外部からシステムに入力されるデータ処理	フォーム送信、API POST
外部出力	EO	生成され、システムの外部に送信されるデータ	レポート生成、エクスポート
外部照会	EQ	シンプルなデータ取得と表示	一覧の照会、詳細ページ

複雑度の重み付けマトリクス

コンポーネントの種類	低	中	高
ILF	7	10	15
EIF	5	7	10
EI	3	4	6
EO	4	5	7
EQ	3	4	6

複雑度の評価ルール

ILF / EIF の複雑度（DET：データ要素タイプ、RET：レコード要素タイプに基づく）：

	DET 1-19	DET 20-50	DET 51+
RET 1	低	低	中
RET 2-5	低	中	高
RET 6+	中	高	高

EI の複雑度（DET および FTR：参照ファイルタイプに基づく）：

	DET 1-4	DET 5-15	DET 16+
FTR 0-1	低	低	中
FTR 2	低	中	高
FTR 3+	中	高	高

EO / EQ の複雑度（DET および FTR に基づく）：

	DET 1-5	DET 6-19	DET 20+
FTR 0-1	低	低	中
FTR 2-3	低	中	高
FTR 4+	中	高	高

ファンクションポイントを工数に換算する

未調整ファンクションポイント（UFP）を算出した後：

1. 値調整係数（VAF）を算出する（任意。IFPUG 4.3 以降では非推奨ですが、現在も一部のチームで使用されています）

   • 14 個の一般システム特性（GSC）をそれぞれ 0～5 で評価します
   • VAF = 0.65 + 0.01 × Σ(GSC)
   • 調整済みファンクションポイント AFP = UFP × VAF

2. ファンクションポイントを人時に換算する

   • 業界ベンチマーク：ファンクションポイントあたり 8～15 人時（言語やチームの成熟度によって異なります）

   技術スタック	FP あたりの人時	備考
   ローコード／成熟したフレームワーク	4 – 8	再利用可能なコンポーネントが多数あります
   Python／JS／モダン Web	8 – 12	主流の開発生産性です
   Java／C# エンタープライズ	10 – 15	アーキテクチャと標準対応のオーバーヘッドを含みます
   組み込み／C／C++	15 – 25	デバッグとテストのコストが高くなります
   レガシーシステムの保守	20 – 30	理解とリグレッションにコストがかかります

手順

1. 機能コンポーネントを特定する：すべての ILF、EIF、EI、EO、EQ を列挙します
2. 複雑度を評価する：各コンポーネントを「低／中／高」で評価します
3. UFP を算出する：すべてのコンポーネントについて（件数 × 重み）を合計します
4. 換算係数を選択する：技術スタックに基づいて、FP あたりの人時を選択します
5. 総工数を算出する：UFP × 換算係数
6. バッファを追加する：管理およびリスク対応として 15～30% のバッファを推奨します

---

見積もり調整係数チェックリスト

見積もりの完了後、以下の要因を考慮できているか確認してください。

技術要因

• 技術スタックへの習熟度（チームに経験がありますか？ 未経験の場合は 30～50% を加算します）
• 技術的負債（レガシーコードの品質が低いですか？ 20～40% を加算します）
• サードパーティへの依存（API が不安定ですか？ ドキュメントが不足していますか？ 10～30% を加算します）
• パフォーマンス／セキュリティ要件（特別な非機能要件がありますか？ 15～25% を加算します）

チーム要因

• チームの規模（5 人を超えるとコミュニケーションのオーバーヘッドが大幅に増加します。1 人あたり約 5% を加算します）
• 人員の離職リスク（主要メンバーが離職する可能性がありますか？ 15～25% を加算します）
• 並行プロジェクト（複数のプロジェクト間でチームのコンテキスト切り替えが発生しますか？ 20～30% を加算します）
• 新メンバーのオンボーディング（新規採用者がいますか？ 最初の 2 週間は効率が約 50% 低下すると見込みます）

プロセス要因

• 要件の安定性（要件が変更される可能性は高いですか？ 20～50% を加算します）
• 承認プロセス（複数段階の承認が必要ですか？ 10～20% を加算します）
• デプロイの複雑さ（複数環境や複数リージョンへのデプロイですか？ 10～15% を加算します）
• コンプライアンス要件（監査やコンプライアンスのプロセスがありますか？ 15～30% を加算します）

過小評価されやすい作業

• コードレビュー：+10～15%
• 単体テストの作成：+15～25%
• 結合テスト／E2E テスト：+10～20%
• ドキュメント作成：+5～15%
• バグ修正とリグレッション：+10～20%
• 環境構築と DevOps：+5～10%
• 会議とコミュニケーション：+10～15%

---

見積もり出力テンプレート

エージェントが見積もりを完了した後、以下の形式で出力します。

## Estimation Report: [Project / Feature Name]

### Estimation Method: [PERT / T-shirt / FPA]

### Work Package Breakdown

| # | Work Package | O (person-days) | M (person-days) | P (person-days) | E (person-days) | σ |
|---|-------------|-----------------|-----------------|-----------------|-----------------|---|
| 1 | xxx         | x               | x               | x               | x.x             | x.x |
| 2 | xxx         | x               | x               | x               | x.x             | x.x |

### Summary

- Total expected effort: X person-days
- Total standard deviation: X person-days
- 68% confidence interval: X – X person-days
- 90% confidence interval: X – X person-days
- 95% confidence interval: X – X person-days

### Adjustment Factors
- [Factors considered and adjustments applied]

### Final Recommendation
- For internal planning: X person-days (90% confidence)
- For external quotes: X person-days (95% confidence)

### Risk Alerts
- [Key risk items and mitigation suggestions]

---

計算ツール

scripts/estimate_calculator.py スクリプトは、3 つすべての見積もり手法における数値計算をサポートします。

# Three-Point Estimation (PERT)
python3 scripts/estimate_calculator.py --method pert \
  --tasks '[{"name":"Login Module","O":2,"M":3,"P":8},{"name":"Payment Module","O":5,"M":10,"P":20}]'

# T-shirt Size Conversion
python3 scripts/estimate_calculator.py --method tshirt \
  --tasks '[{"name":"Login Module","size":"M"},{"name":"Payment Module","size":"L"}]'

# Function Point Analysis
python3 scripts/estimate_calculator.py --method fpa \
  --components '[{"type":"ILF","complexity":"medium","count":3},{"type":"EI","complexity":"low","count":5}]' \
  --hours-per-fp 10

---

参考資料

• IFPUG（International Function Point Users Group）CPM 4.3.1
• PMI PMBOK Guide — 第 6 版、第 6.4 節：アクティビティ期間の見積もり
• Steve McConnell、Software Estimation: Demystifying the Black Art
• Mike Cohn、Agile Estimating and Planning