Vendor Estimate Creator

ソフトウェア開発プロジェクトのプロフェッショナルなコスト見積を作成 – WBS、工数計算、コスト内訳、ROI分析、見積書テンプレート。

API不要

スキルパッケージをダウンロード (.skill) GitHubでソースを見る ワークフロー 日英バイリンガル

目次

• 概要
• 利用シーン
• 前提条件
• 仕組み
  • 4つの見積手法の比較
  • コンティンジェンシーの配分
  • フェーズ別標準工数配分
  • 役割別単価レンジ
  • 見積書ドキュメント構成
• 使用例
  • 例1: RFQからのフル見積
  • 例2: 提案用の概算見積
  • 例3: ROI分析のみ
  • 例4: 既存見積のレビューと検証
  • 例5: 未経験技術スタックのモバイルアプリ見積
• ヒントとベストプラクティス
• トラブルシューティング
  • 見積合計が市場相場より低すぎる
  • クライアントがコンティンジェンシーに異議を唱える
  • ROI分析がステークホルダーを納得させられない
• 関連スキル

---

概要

Vendor Estimate Creatorは、RFQ（提案依頼書）やプロジェクト要件から、ソフトウェア開発プロジェクトの包括的なコスト見積書を作成するスキルです。RFQ分析、作業分解、業界標準手法による工数見積、コスト計算、ROI分析、見積書ドキュメント生成までの全プロセスをカバーします。

見積手法（4手法）、工数基準（役割別生産性、タスク別ベンチマーク）、ROI分析（NPV、IRR、回収期間、感度分析）のリファレンスガイドを内蔵しています。出力は日本語がデフォルトですが、英語にも対応しています。

利用シーン

• RFQを受領し、コスト見積の回答を準備する必要がある
• ソフトウェア開発提案のプロジェクト工数とコストを算出したい
• クライアントへの投資正当化のためにROI分析を含めたい
• 組織全体で見積フォーマットを標準化したい
• 既存の見積書の網羅性をレビューしたい

前提条件

• vendor-estimate-creator スキルがインストールされたClaude Code
• RFQ文書、プロジェクト要件、または構築するシステムの説明
• 外部APIや有料サービスは不要

仕組み

6つのワークフローを順に実行します。

1. RFQ分析 – RFQからプロジェクト規模（画面数、API数、DBテーブル数、バッチ処理数、外部連携数）を抽出し、プロジェクトタイプの特定、複雑度評価、不明点のリスト化、前提条件の文書化、リスク評価（技術・要件・統合）によるコンティンジェンシー率の決定を行います。
2. WBSとタスク識別 – プロジェクトフェーズ（要件定義・設計・実装・テスト・デプロイ・PM・QA）の定義、階層的WBSの作成、PM（10-15%）・QA（7-11%）・コンティンジェンシー（10-25%）の計上を検証します。
3. 工数見積 – プロジェクトの成熟度に応じた見積手法（類推法・パラメトリック法・ボトムアップ法）の選択、タスク別標準工数ベンチマークの適用、複雑度・チーム習熟度・技術リスクによる調整係数の適用を行います。
4. コスト計算 – 役割別単価（PM・アーキテクト・シニア/ミドルエンジニア）の定義、WBSタスクへの役割割当、タスク別コスト計算、プロジェクト合計への集計を行います。
5. ROI分析 – 現状コスト（As-Is）の分析、将来状態のベネフィット（To-Be）の予測、財務指標（ROI、NPV、IRR、回収期間）の計算、楽観/標準/悲観シナリオでの感度分析を実施します。
6. 見積書ドキュメント生成 – 12セクションの見積テンプレート（エグゼクティブサマリー、前提条件、WBS詳細、スケジュール、ROI、チーム体制、リスクと対策、運用保守費用、支払条件、契約条件、承認）を使って文書化します。

4つの見積手法の比較

プロジェクトについてわかっている情報量に応じて手法を選択します。

手法	適用タイミング	精度	概要
類推法	極めて初期段階、類似プロジェクトの実績あり	+/- 50%	類似の完了プロジェクトと比較し、差分に応じてスケーリング
パラメトリック法	企画段階、スコープ指標（画面数、API数）が判明	+/- 30%	生産性レート（例: API 1本あたり3人日）に数量を掛けて算出。迅速かつデータ駆動
ボトムアップ法	要件定義済み、WBSが利用可能	+/- 10%	WBSの各タスクを個別に見積もり、合算。最も正確だが最も工数がかかる
三点見積もり（PERT）	不確実性の範囲が把握できる任意の段階	可変	各タスクで (楽観値 + 4 x 最頻値 + 悲観値) / 6 を計算。リスク調整された見積に有用

最良の結果を得るには、ボトムアップで見積もった後、パラメトリックベンチマークでクロスチェックしてください。

コンティンジェンシーの配分

コンティンジェンシーは、正確に見積もれない不確実性をカバーします。プロジェクトのリスクレベルに応じて設定します。

リスクレベル	コンティンジェンシー率	典型的な指標
低	5-10%	既知の技術、明確な要件、経験豊富なチーム
中	10-15%	一部新技術、要件はおおむね定義済み、チーム経験にばらつきあり
高	15-25%	新技術スタック、曖昧な要件、多数の外部連携

コンティンジェンシーは実装だけでなく、PM・QAを含む全フェーズの合計工数に対して適用します。

フェーズ別標準工数配分

バランスの取れた見積は、工数がフェーズ間で適切に分配されています。以下の範囲をサニティチェックに活用してください。

フェーズ	全体工数に占める割合（目安）
要件定義	8-12%
設計	12-18%
実装	30-40%
テスト	18-25%
デプロイ・運用準備	5-8%
PM（横断）	10-15%
QA（横断）	7-11%

役割別単価レンジ

コスト計算に使用する役割別日額単価です。市場環境に応じて調整してください。

役割	単価（円/人日）
プロジェクトマネージャー	100,000 - 150,000
アーキテクト	90,000 - 140,000
シニアエンジニア	80,000 - 120,000
ミドルエンジニア	60,000 - 90,000

各WBSタスクの人日見積に単価を掛けて算出し、合算してプロジェクト合計コストを導出します。

見積書ドキュメント構成

最終出力は12セクションのテンプレートに従います。

1. エグゼクティブサマリー – 主要数値と推奨事項
2. 前提条件 – スコープ・技術・チームに関するすべての前提
3. WBS詳細 – タスク別工数を含む階層的タスク分解
4. プロジェクトスケジュール – マイルストーン付きタイムライン
5. ROI分析 – 現状 vs. 将来状態、財務指標
6. チーム体制 – 役割、人数、稼働率
7. リスクと対策 – 対応戦略付きリスク登録簿
8. 運用保守費用 – 年間運用・サポートコスト
9. 支払条件 – マイルストーンベースまたは定期支払スケジュール
10. 契約条件 – スコープ変更プロセス、瑕疵担保、SLA
11. 付録 – 詳細計算、参考データ
12. 承認 – クライアント・ベンダー双方の署名欄

使用例

例1: RFQからのフル見積

顧客管理システム構築のRFQを受領しました。
要件: 画面30、API 50本、DBテーブル15、外部システム連携3、
モバイル対応（iOS/Android）。
技術: React + Node.js + PostgreSQL。
WBS、工数、コスト内訳、ROI分析を含む
完全なコスト見積を作成してください。

例2: 提案用の概算見積

データ分析ダッシュボードプロジェクトの概算見積が必要です。
画面約10、API 20本、データソース2つへの接続。
チームは技術スタック（Python + React）に精通しています。
工数は人日、コストは円で提示してください。

例3: ROI分析のみ

現在の手作業による受注処理コストは年間2,480万円
（人件費1,800万円、システム運用500万円、エラー対応180万円）。
新システムの構築費用は4,750万円、年間運用費300万円。
改善見込み: 処理時間30分→5分、エラー率5%→0.5%。
5年間のROI、NPV、回収期間を計算してください。

例4: 既存見積のレビューと検証

CRM移行プロジェクトの既存見積があります（estimate.mdとして添付）。
網羅性をレビューしてください。PM・QA工数が適切に含まれているか、
コンティンジェンシーが妥当か、見落としやすい項目がないかを
チェックしてください。

例5: 未経験技術スタックのモバイルアプリ見積

物流企業向けのクロスプラットフォームモバイルアプリ（Flutter）の
見積が必要です。画面15、リアルタイムGPSトラッキング、
オフラインモード、プッシュ通知。チームはFlutter未経験です。
学習曲線を考慮し、適切なコンティンジェンシーレベルを
推奨してください。

ヒントとベストプラクティス

• コンティンジェンシーは必ず含める。 低リスクで5-10%、中リスクで10-15%、高リスクで15-25%が目安です。コンティンジェンシーの省略は最も多い見積ミスです。
• PM・QA工数を忘れない。 プロジェクト管理は全体の10-15%、QAは7-11%が適正です。これらは頻繁に過小評価されるか、完全に漏れます。
• 複数の見積手法でクロスチェックする。 ボトムアップで見積もった後、パラメトリックベンチマークや類似プロジェクトデータで妥当性を検証しましょう。
• 前提条件をすべて明記する。 スコープ、技術、チーム構成、制約について想定していることを明記します。前提条件はベンダーとクライアント双方を保護します。
• 便益は控えめに、コストは余裕を持って。 ROI分析では、ベネフィットは現実的または若干悲観的な予測を使い、すべてのコストカテゴリを含めましょう。
• 見落としやすい項目を確認する。 データ移行、非機能要件（性能・セキュリティ）、統合テスト、トレーニング、ドキュメント作成は特に見落とされがちです。

トラブルシューティング

見積合計が市場相場より低すぎる

症状: 算出されたコストが同規模の他社見積と比較して大幅に低い。

解決策: 漏れ項目を確認します。PM工数（10-15%）、QA工数（7-11%）、コンティンジェンシー（10-25%）、データ移行、トレーニング、ドキュメント作成、非機能要件テストが含まれているか確認してください。また、労務単価が現在の市場水準を反映しているかも確認しましょう。リファレンスガイドの単価は地域や専門性に応じて調整が必要な場合があります。

クライアントがコンティンジェンシーに異議を唱える

症状: クライアントが15-25%の「上乗せ」について説明を求め、削除を要求する。

解決策: コンティンジェンシーは、現段階では正確に見積もれない特定のリスクと不確実性をカバーするものであることを説明します。リスク評価で特定した具体的要因（新技術、不明確な要件、複数の外部連携）を提示します。クライアントが正式なスコープ変更プロセスに合意する場合はコンティンジェンシーの削減を提案できます。その場合、不確実性のコストはコンティンジェンシーから変更要求に移行します。

ROI分析がステークホルダーを納得させられない

症状: 財務指標（ROI、NPV）はプラスだが、ステークホルダーが懐疑的なまま。

解決策: ベネフィットが測定可能な現状指標（実際の処理時間、実際のエラー率、実際の人件費）に基づいていることを確認します。悲観シナリオでも投資が成立することを示す感度分析を含めます。数値とともに定性的なベネフィット（コンプライアンス、スケーラビリティ、従業員満足度）も提示します。価値を証明するPhase 1でクイックウィンを提供し、全額投資に踏み切る前に成果を実証するフェーズドアプローチを提案してください。

関連スキル

• Project Plan Creator – 見積のWBSとスケジュールをプロジェクト計画に直接活用できます。
• Business Analyst – 要件分析が正確な見積のインプットを提供します。
• Strategic Planner – 戦略的コンテキストがビジネスケースでの投資正当化に役立ちます。