工数見積(人月)をClaudeで書き出す手順 — 提案前の幅と前提条件

提案前の見積で後から効いてくるのは、人月の合計よりも「何を前提に、何を含めていないか」です。要件メモの段階で数字だけを先に出すと、受注後に前提のずれが工数の超過として表に出ます。

Claudeは、要件メモをタスクに分解し、タスクごとに工数の幅と前提を書き出す下書きに向いています。Excelに載せるときはClaude for Excelを使うと、前提を変えても式の関係を保ったまま合計が再計算されます。ここでは、RFPや要件メモから「幅つきの人月」と「前提・除外条件の表」を作り、見積金額へつなぐまでを順に示します。

数字を確定させるのは人です。Claudeに任せるのは、分解の抜けを減らすことと、前提を文章から表へ移す作業までに絞ります。

提案前の見積は「1つの数字」でなく「幅と前提」で持つ

受注前は、要件がまだ固まっていません。画面数もデータ量も顧客の返答待ちのことが多く、1つの人月だけを出すと、確定していない部分まで確定したように見えます。

そこで見積を3つの部品に分けて持ちます。

受注後に変更要求が出たとき、前提と除外が書かれていれば、範囲内かどうかの根拠になります。その判定の手順は変更要求がSOWの範囲内かをClaudeで判定するにあり、この記事の表はそちらの入力にもなります。

Claudeに渡す材料と、渡さないもの

渡す材料は次の4種類です。

• RFP(提案依頼書)または顧客との打合せメモ
• 自社の過去案件の工数実績(画面数・テーブル数などの規模と、実績の人日)
• 自社の標準工程(要件定義、設計、実装、テスト、移行、PMの割合)
• 1人月を何人日とするか、単価の考え方などの社内ルール

過去実績は、Claudeに相場を語らせないための根拠になります。実績が無い工程は、一般的な値で埋めさせずに「根拠なし」と書かせます。

注意点が1つあります。顧客から届いたExcelやWordには、外部ファイルとして隠れた指示が含まれている場合があります。Claude for Excelの公式ページは、外部由来のファイルでは意図しない操作に誘導される恐れがあると説明しています。信頼できる複製を作ってから開くこと、確認ダイアログを読んでから許可することが前提になります。

Claude for Excelを使う条件

ExcelでClaudeを呼ぶ場合の条件は次のとおりです。

マクロで見積を自動集計している社内テンプレートは、そのままではClaudeに触らせられません。式だけで組んだシートに作り直すか、Claudeには前提シートだけを触らせます。

手順1: 要件メモをタスクに分解する

最初にExcelを開かず、チャットで分解だけをさせます。ここで出る粒度が、その後の幅の精度を決めます。

次の指示文を、要件メモと一緒に貼ります。案件名や数値は架空の例です。

添付の要件メモから、開発タスクを分解してください。
 
- 工程は 要件定義 / 設計 / 実装 / テスト / 移行 / PM に分ける
- 1タスクは、1人が3〜10人日で終わる大きさを目安にする
- 要件メモに書かれていない作業は「推定」と明記し、
  根拠になる文を引用できないものは別表にする
- 要件メモの記述が曖昧で、工数が大きく動くものは
  「確認したい点」として一覧にする

出力は、要件メモの記述に結びついたタスク表と、「推定」の別表、確認したい点の3つになります。

見るべきは確認したい点です。顧客へ聞ける内容であれば、提案の前に質問書として出せます。聞けないまま提案する場合は、その点が前提条件の欄に入ります。RFPの要件を提案書の章立てへ対応づける作業は、ClaudeでRFPの要件を提案書の章立てに対応づける手順に分けてあります。同じ要件メモを両方で使うと、章立てとタスクの抜けを突き合わせられます。

手順2: 工数の幅を人日で出す

タスクが決まったら、タスクごとに最小・見込み・最大を出させます。ここで過去実績を渡します。

手順1のタスク表の各行に、最小・見込み・最大の人日を付けてください。
 
- 根拠は、添付の過去案件実績から類似タスクを選び、案件名と実績人日で示す
- 類似する実績が無いタスクは、人日を空欄にして「根拠なし」と書く
- 最大は、確認したい点が悪い方に転んだ場合の値とし、
  どの点が転んだ場合かを1行で書く

「最大は何が転んだ場合か」を書かせるのがこの指示文の要点です。幅の理由が文章で残るため、後で前提条件の表にそのまま移せます。

幅から期待値を出す方法として、三点見積があります。見込みの重みを4倍にして平均する式で、(最小 + 4 × 見込み + 最大) ÷ 6 と書きます。これは見積手法として広く使われる計算で、Claude固有のものではありません。使うかどうかは社内の流儀に合わせ、使う場合は式をシートに残します。

表の数値はすべて説明用の架空の値です。幅が最も広い工程(ここでは実装と移行)が、提案前に顧客へ確かめる優先順位になります。

手順3: 前提条件と除外条件を表にする

幅の理由は、そのままでは文章です。見積書に載せる前提条件と、載せない除外条件に分けて表にします。

手順2の「幅の理由」と「確認したい点」から、次の2つの表を作ってください。
 
表A 前提条件: 前提 / 影響する工程 / 前提が崩れたときの工数への影響(人日)
表B 除外条件: 含めない作業 / 顧客が含まれると誤解しうる理由
 
「前提が崩れたときの影響」は、手順2の最大と見込みの差から出し、
差が説明できない前提は載せない。

表Aの影響人日を最大と見込みの差から出させると、前提条件の数字が幅と食い違いません。説明できない前提を載せない、という縛りもここで効きます。

除外条件は、顧客が「当然含まれる」と読みそうな作業から先に挙げます。例えば次のようなものです。

• 本番環境の構築と運用保守
• 旧システムからのデータクレンジング
• 利用者向け教育とマニュアル作成
• 要件確定後に発生した追加要求への対応

挙げた項目のうち、受注後に揉めやすいものは表Aではなく契約の範囲(SOW)に書く、と分けるのが実務的です。

手順4: Excelで合計し、人月と金額へつなぐ

ここで初めてExcelを使います。シートは3枚に分けます。

前提シートの値を変えたとき、工数シートとサマリーが連動して動くことが重要です。Claude for Excelは、セルの値を更新するときに式の関係を保ち、下流のセルが再計算されるように作業すると説明されています。あとから「1人月は20人日ではなく18人日」と変わっても、式を書き換えずに済みます。

Claude for Excelには、次のような指示を出します。

前提シートに、次のセルを作ってください。
- B2: 1人月あたりの人日(初期値20)
- B3: 人月単価(円。空欄にして私が入れる)
- B4: リスク係数(初期値1.0)
 
工数シートのF列に、三点見積の期待値(最小+4×見込み+最大)÷6を式で入れ、
合計行を作ってください。
サマリーには、最小・期待・最大のそれぞれについて
人月(= 人日合計 ÷ B2)と金額(= 人月 × B3 × B4)を式で出してください。
値のベタ書きは使わないでください。

単価を空欄にしておくのは、Claudeに相場や自社の単価を推測させないためです。入れるのは人です。

リスク係数は、前提条件が複数崩れそうなときに金額へ上乗せする倍率です。係数をどう置くかは社内の判断になるため、Claudeには初期値1.0の枠だけを作らせ、根拠は人が書きます。

毎回の書式や言語の指示は、サイドバーの設定にあるInstructions欄に置けます。この欄の内容はExcelだけに適用され、PowerPointやWordの設定とは別です。「金額は千円単位で表示する」「人月は小数第1位まで」といった規則を入れておくと、毎回の指示が短くなります。

見積書や提案書に載せる前の確認

公式ページは、顧客に渡す最終成果物を人の確認なしで出すこと、監査に関わる計算を検証なしで使うことを推奨していません。見積は顧客に出る数字なので、次の点を人が確かめます。

1. 合計が、工数シートの各行の合計と一致しているか(サマリーの式の参照先が正しいか)
2. 「根拠なし」の行が空欄のまま合計に入っていないか
3. 前提条件の影響人日が、最大と見込みの差と一致しているか
4. 除外条件に、顧客が含まれると読みそうな作業が漏れていないか
5. 単価とリスク係数が、人の入力した値のままか

Excelの確認ダイアログも見ます。Claude for Excelは、既存のデータを上書きする前に警告します。過去案件の実績シートが同じブックにあるなら、別ブックに分けて、Claudeに書き込ませる範囲を前提シートと工数シートに限ります。

提案書(Word)や説明用スライド(PowerPoint)への展開は、Excelの数字を読んで別のアプリに書く使い方です。公式の説明では、Pro・Maxはクロスアプリ機能がオンで、Team・Enterpriseではオフです。Team以上の組織では、各アドインの設定でオンにするか、管理者が組織設定で許可する必要があります。

過去実績との突き合わせで、幅の精度を上げる

案件が終わったら、見積の最小・見込み・最大と実績人日を並べて残します。実績が幅の外に出たタスクは、前提条件に抜けがあったことを示します。

添付の見積ブックと、案件完了後の実績人日を比べてください。
 
- 実績が最大を超えたタスクを挙げ、そのときの前提条件の欄に
  該当する記述があったかを確かめる
- 該当する記述が無い場合は、次回の前提条件に追加すべき文面を提案する

この結果を次回の過去実績シートに足していくと、手順2で渡す根拠が厚くなります。キックオフ後の作業分解は、Claudeでキックオフ資料とWBS・体制図を起こす手順で扱っています。受注前の見積と受注後のWBSを同じタスク名で持っておくと、突き合わせが楽になります。

つまずきやすい点

もう1つ、Claudeが相場を補ってしまう点にも注意が必要です。「一般的には〜人日」といった説明が混ざる場合は、指示文に「過去実績にないものは根拠なしと書く」を再度加えます。

隣接する作業との切り分け

提案前の見積は、周辺の作業と入力・出力が重なります。

ROI試算は「顧客にとっての効果」、本記事は「自社が払う工数」を扱います。同じ顧客の前提値を共有すれば、提案書の中で費用と効果の前提が揃います。

まとめ

提案前の見積で守りたいのは、数字を1つに絞らないことです。タスクごとの幅と、その幅の理由を前提条件・除外条件の表に移しておけば、受注後の議論は「何が転んだのか」の確認に絞れます。

Claudeには、分解の抜けの洗い出しと、文章から表への整形を任せられます。単価、リスク係数、最終的な人月は人が決める部分として残し、Excelの式で連動させておくと、前提が変わっても作り直しが要りません。