estimation-advisor

star 0

見積方針書に基づき、工程別見積の草案作成・数値整合性チェックを行うスキル。

danishi By danishi schedule Updated 4/17/2026

name: estimation-advisor description: "見積方針書に基づき、工程別見積の草案作成・数値整合性チェックを行うスキル。" user-invocable: true argument-hint: "<チェック対象: policy|detail|tco> [モード: draft|check]" allowed-tools: Read, Grep, Glob, Write, Bash

見積アドバイザー

概要

本スキルは、見積方針書を起点として工程別見積の草案作成と数値整合性チェックを行う。 RFPが指定する費目構造に準拠しつつ、成果物間で金額の矛盾が生じないよう一貫性を担保する。

用語規約(必須)

  • 工数の単位は必ず「人月」と日本語で表記するPM / P/M / MM / M/M / man-month 等の略語は工数単位として使用禁止(英語圏の Person Month と混同するため)。
  • ロール名としての PM は使用せず、プロジェクトマネージャーを指す場合は PjM と表記する(PM/PMO費PjM/PMO費PM/PLPjM/PL 等)。
  • 見積表・工程別内訳・TCO計算・根拠コメントのいずれにおいても、工数列のヘッダは「人月」「工数(人月)」とし、数値単位の略号を用いない。

見積作成手順(4ステップ)

Step 1: RFP見積構成要件の確認

RFP本紙およびRFP別紙の見積回答シートを読み込み、以下を把握する:

  • 費目構造: RFPが指定する費目分類(イニシャル/ランニング、工程別/機能別等)
  • 回答フォーマット: 金額記入欄の構造、単位(千円/万円/百万円)、税込/税抜
  • 提出物: 見積書の他に内訳書や前提条件書が必要か
  • 見積期間: イニシャルの対象期間、ランニングの見積年数(3年/5年/10年等)
  • オプション見積: フェーズ分けする場合の各フェーズの見積要否(デフォルトは初期開発+保守でフェーズ分けしない)

Step 1.5: 組織固有データの読込

arcadia/org-data/ 配下の自社固有データを読み込み、見積の基礎情報を把握する:

  • rate-card.md: ロール別人月単価、原価率、値引基準、付帯費用の標準
  • service-catalog.md: サービス別の概算見積目安(規模別の期間・人月参考値)
  • whitepapers/index.md: コスト最適化 (cost-optimization) タグの技術資料

org-data が未整備の場合はユーザーに整備を促す。最低限 rate-card.md の標準単価テーブルが必要。

Step 2: 見積方針書の読込

見積方針書(output/plan/estimation-policy.md 等)を読み込み、以下を把握する:

  • 人月単価: 職種別(PjM/PL/SE/PG等)の月額単価(org-data/rate-card.md の標準値を初期値とする)
  • 前提条件: 作業場所、稼働率、工期等の前提
  • スコープ: 提案範囲に含むもの/含まないもの
  • 外注/ライセンス費: 製品ライセンス、クラウド利用料、外注費の見積方法
  • 値引方針: 値引率の設定方針、競合状況に応じた調整(org-data/rate-card.md の値引基準を参照)

Step 3: 工程別見積の草案生成

以下の標準工程に沿って見積草案を作成する:

工程 主な作業内容 見積の観点
要件定義 現行調査、要件整理、RFP回答 顧客調整・レビュー工数を含む
基本設計 アーキテクチャ設計、IF設計、データモデル設計 技術検証(PoC)工数を含む
詳細設計 コンポーネント設計、テーブル設計、バッチ設計 現行資産の移行設計を含む
製造・単体テスト 開発、コーディング、単体テスト 環境構築工数を含む
結合テスト 機能間テスト、IF テスト テストデータ作成工数を含む
総合テスト シナリオテスト、性能テスト、セキュリティテスト 顧客参加テストを含む
移行 データ移行、並行稼働、切替 リハーサル・切戻し計画を含む
運用・保守 定常運用、障害対応、改善 ランニング費用として計上

草案生成時の留意点:

  • 各工程の人月数は、スコープの規模感(IF数、テーブル数、バッチ数等)から推定する
  • バッファ(管理予備)は10-20%を目安に設定する
  • PjM/PMO工数は全体の15-25%を目安に計上する

Step 4: 数値整合性チェック

生成した見積と既存の成果物間で以下の整合性を確認する:

4-1. イニシャル/ランニングの整合性

  • イニシャル費用の内訳合計が総額と一致するか
  • ランニング費用の内訳合計が年額と一致するか
  • イニシャルとランニングで重複計上されている項目がないか

4-2. 提案書と見積シートの数値一致

  • 提案書(費用Volなど)に記載の金額とExcel見積シートの金額が一致するか
  • 概算と詳細で異なる粒度の金額が記載されている場合、上位の合計値が一致するか
  • 値引き前/後の金額が正しく反映されているか

4-3. TCO計算の正確性

  • 指定年数(通常5年)のTCO計算が正しいか
  • 初年度と次年度以降でランニング費用に差がある場合、正しく反映されているか
  • ライセンス/利用料の年次増減(従量課金の成長率等)が考慮されているか

チェック対象の指定

引数 対象 説明
policy 見積方針書 方針書の記載内容の妥当性・網羅性をチェック
detail 工程別見積 工程別の人月数・金額の妥当性、内訳整合性をチェック
tco TCO計算 5年(または指定年数)TCO計算の正確性をチェック

モードの指定

引数 動作 説明
draft 草案生成 見積方針書を元に新規草案を生成する
check 整合性チェック 既存の見積成果物間の数値整合性を検証する

出力フォーマット

draft モード

## 見積草案

### 前提条件
- 人月単価: [職種別単価テーブル]
- 見積期間: [イニシャル期間], [ランニング期間]
- スコープ: [含む/含まない一覧]

### イニシャル費用
| 工程 | 人月 | 金額(税抜) | 備考 |
|------|------|------------|------|
| 要件定義 | xx | xx | ... |
| ... | ... | ... | ... |
| **小計** | **xx** | **xx** | |
| 管理予備(xx%) | xx | xx | |
| **合計** | **xx** | **xx** | |

### ランニング費用(年額)
| 費目 | 金額(税抜) | 備考 |
|------|------------|------|
| 運用・保守 | xx | ... |
| ライセンス/利用料 | xx | ... |
| **合計** | **xx** | |

### TCO(X年間)
| 項目 | 金額(税抜) |
|------|------------|
| イニシャル | xx |
| ランニング(X年累計) | xx |
| **TCO合計** | **xx** |

check モード

## 見積整合性チェック結果

### チェック概要
- **チェック日時**: YYYY-MM-DD
- **チェック対象ファイル**: [ファイル一覧]

### 結果サマリ
| チェック項目 | 結果 | 詳細 |
|------------|------|------|
| イニシャル内訳合計 | OK/NG | [差異の詳細] |
| ランニング内訳合計 | OK/NG | [差異の詳細] |
| 提案書-見積シート一致 | OK/NG | [差異の詳細] |
| TCO計算正確性 | OK/NG | [差異の詳細] |

### 検出された不整合
[不整合の詳細と推奨修正内容]

注意事項

  • 金額はRFPが指定する単位(千円/万円/百万円)に統一すること
  • 税込/税抜の区別を明確にすること(RFPの指定に従う)
  • 競合他社への情報漏洩を防ぐため、見積の根拠となる単価情報は提案書本体には記載しない
  • 見積方針書が存在しない場合は、まず方針書の作成を推奨する
  • ライセンス/利用料の正式見積は各ベンダーに確認が必要な旨を注記する
  • org-data/rate-card.md の単価はプロジェクトの見積方針書で上書き可能(案件固有の調整を優先する)
  • org-data/rate-card.md の原価情報(セクション4)は社外秘。提案書・見積書への転記は禁止
Install via CLI
npx skills add https://github.com/danishi/arcadia --skill estimation-advisor
Repository Details
star Stars 0
call_split Forks 0
navigation Branch main
article Path SKILL.md
More from Creator