変更要求がSOWの範囲内かをClaudeで判定する — 工数影響まで概算
SOWと見積内訳、RAIDログをClaudeのProjectsに置き、顧客の変更要求を範囲内・範囲外・要確認に仕分けて工数影響を概算させる手順です。判定を人が確かめる点も示します。
顧客から「ついでにこの画面も直せますか」と言われたとき、まず決めるのは作業の可否ではなく、それが契約の範囲内かどうかです。この判断が曖昧なまま着手すると、後から工数だけが膨らみます。
SOW(作業範囲記述書。成果物や作業内容を取り決める文書)と見積内訳、RAIDログをClaudeのProjectsに置いておくと、変更要求の文面を貼るだけで「範囲内」「範囲外」「要確認」の仕分け案と工数影響の概算が出せます。判定そのものは人が確定させる前提で、仕分けの下書きを速く揃える手順です。
判定の単位は「変更要求の1文」ではなく「成果物と前提」
変更要求は「この一覧に絞り込みを付けてほしい」のように短く届きます。これをSOWの文言と直接照らしても、うまく判定できません。SOWが範囲を定めるのは、成果物、作業内容、前提条件、除外事項の4か所だからです。
そこで、要求を次の3点に分解してから照合します。
要求を分解して照合する流れ
- 1
何を変えるのかを成果物の単位で言い直す
画面、帳票、バッチ、インターフェースのうち、どの成果物のどの部分に触れるかを特定します。
- 2
SOWの成果物・作業内容・除外事項と照らす
該当する記載があるか、除外事項に当たらないかを確かめ、根拠の条項番号を残します。
- 3
前提条件が崩れないかを確かめる
件数、対象環境、顧客側の提供物など、見積の前提を要求が超えていないかを見ます。
成果物としては範囲内の「一覧画面」でも、「絞り込み条件を顧客ごとに保存したい」となれば、前提にない永続化の設計が加わります。範囲内の成果物に、範囲外の作業が付いてくる形です。
3つの判定と、それぞれの根拠の持たせ方
仕分けの結果は3区分に固定します。区分を増やすと、担当者ごとに運用が割れます。
| 判定 | 意味 | 根拠として必要なもの |
|---|---|---|
| 範囲内 | 意味SOWの成果物・作業内容に含まれる | 根拠として必要なもの該当条項と、前提を超えない理由 |
| 範囲外 | 意味記載がない、または除外事項に当たる | 根拠として必要なもの該当しない理由、または除外条項 |
| 要確認 | 意味記載が曖昧で、どちらにも読める | 根拠として必要なもの読み方が割れる箇所と、確認すべき相手 |
区分が2つしかないと、Claudeは曖昧な要求にも白黒を付けにいき、根拠の弱い断定が混ざります。逃げ道を用意しておけば、読みが割れる箇所を割れたまま報告させられます。要確認の件数が多い案件は、SOW自体の書き方に問題があるというシグナルにもなります。
Projectsに置く4つの資料
ProjectsはClaudeの作業スペースで、チャット履歴とは別にナレッジ(資料の置き場)を持ち、プロジェクト内の全チャットから参照されます。ナレッジに入れた内容はどのチャットでも使われますが、チャット間で文脈は共有されません。後述の判定ログを毎回残す理由はここにあります。
| 置く資料 | 役割 |
|---|---|
| SOW(契約書本体と別紙) | 役割範囲判定の唯一の根拠 |
| 見積内訳 | 役割工数概算の単価と工程の根拠 |
| RAIDログ | 役割既知のリスク・前提・課題・依存関係 |
| 変更要求の判定ログ | 役割過去の判定と顧客の回答 |
RAIDは、リスク(Risks)、前提(Assumptions)、課題(Issues)、依存関係(Dependencies)の頭文字で、プロジェクト管理で広く使われる管理表の呼び方です。この4つのうち、範囲判定に直接効くのは前提です。SOWに書かれた前提と、RAIDログの前提欄を同じ場所に置くと、「その前提はいつ、誰が合意したのか」まで辿れます。
資料の量が増えて大きくなると、有料プラン(Pro、Max、Team、Enterprise)ではナレッジが上限に近づいたときにRAGモードが自動で有効になり、容量が最大で10倍まで広がります。RAGでは該当箇所を検索して取り出すため、SOWのように条項番号で厳密に引いてほしい資料では、条項単位の参照が抜けていないかを確かめる手間が増えます。仕組みの違いはClaude ProjectsのRAG検索の仕組みと全文投入との違いにまとめています。
顧客の契約書や仕様書を渡す前に、NDAとプランの設定を確かめる順番はコンサルのNDA点検表にあります。SOWには価格や人員の情報も載るため、投入の可否は先に決めておきます。
プロジェクト指示に書く判定ルール
Projectsでは「Set project instructions」から指示文を保存でき、プロジェクト内のすべてのチャットに適用されます。判定ルールはここに置きます。例えば次のような形です。
あなたはITプロジェクトのPMOを補佐します。
ナレッジのSOW・見積内訳・RAIDログだけを根拠に、
顧客の変更要求を次の手順で扱います。
1. 要求を、触れる成果物と作業に分解する。
2. SOWの成果物・作業内容・前提条件・除外事項と照合し、
根拠の条項番号を必ず併記する。
3. 判定は「範囲内」「範囲外」「要確認」のいずれか。
SOWから読み取れないものは「要確認」とし、推測で埋めない。
4. 工数は見積内訳の工程と単価に基づく概算とし、
算出の前提を式で示す。内訳にない工程は「内訳なし」と書く。
5. RAIDログの前提・リスクに触れる場合は項目番号を挙げる。
6. 出力は顧客への回答案ではなく、社内確認用の下書きとする。顧客への回答案まで一気に書かせると、判定の根拠より文面の整い方が目に入ります。6番目で社内向けの下書きに止めているのはそのためで、レビューは根拠の確認に集中できます。
変更要求を貼るときの入力の型
変更要求の文面だけを貼るより、経緯を添えたほうが判定がぶれません。次の項目を埋めた1枚を毎回貼ります。
## 変更要求
- 受領日 / 依頼者:
- 原文(メール・議事録の該当箇所をそのまま):
- 顧客が期待している納期:
- 過去の関連する合意(あれば):要約すると、顧客の言葉にあった曖昧さがその時点で消え、判定が「範囲内」に寄ります。原文は加工せずに貼ります。
出力は表で受ける
Claudeには、次の列を持つ表で返すよう頼みます。
| 項目 | 内容 |
|---|---|
| 要求の分解 | 内容触れる成果物・作業 |
| 判定 | 内容範囲内 / 範囲外 / 要確認 |
| 根拠 | 内容SOWの条項番号と該当文言 |
| 前提への影響 | 内容SOW・RAIDの前提との関係 |
| 工数概算 | 内容工程別の人日と算出式 |
| 確認事項 | 内容顧客またはPMが答えるべき点 |
工数概算は、単価と工程が見積内訳にある場合だけ出させます。内訳にない作業を、一般的な相場で補わせない運用にします。数字の根拠が社内の見積と離れた時点で、顧客との交渉に使えなくなるためです。
架空の例で見る仕分け
次は、判定の動きを示すための架空の例です(特定の案件ではありません)。SOWに「受注管理画面:一覧、詳細、登録の3画面」「帳票:納品書のPDF出力」「除外:外部システムとの連携」と書かれている案件を想定します。
3つの変更要求の仕分け例
一覧に出荷状況の列を足してほしい
範囲内の候補です。一覧画面は成果物にあり、列の追加は画面内の変更にとどまります。ただし出荷状況のデータが画面の元データにあるかが前提になるため、確認事項に挙げます。
納品書に顧客ロゴを入れたい
要確認です。納品書のPDF出力は範囲内ですが、レイアウトの確定方法がSOWに書かれていなければ、ロゴの追加を仕様変更と読むか、デザイン調整と読むかで割れます。
出荷システムと在庫を自動連携したい
範囲外です。外部システムとの連携が除外事項に当たります。この判定は、読みが割れない珍しい例です。
1件目は「範囲内」と返っても、そのまま通せません。前提(元データの有無)が確認事項に隠れているからです。表の「確認事項」列を空にして通さないことが、運用上の最小限のルールです。
工数の概算は「差分」として出す
変更要求の工数は、ゼロから積み上げるより、見積内訳の既存工程に対する差分として出すほうが精度が出ます。例えば「詳細画面の改修:既存見積4人日のうち、項目追加に相当する0.5人日」と書けば、顧客にも説明が通ります。
指示文に差分の考え方を加えます。
工数は次の形式で書く。
- 影響する工程: (見積内訳の工程名)
- 既存の見積工数:
- 追加・変更の内容:
- 追加工数の概算: (人日)と、算出の考え方を1行
- 再テスト・再レビューの範囲:実装が小さな変更でも、結合テストや受入れテストのやり直しが発生するかどうかで、工数は大きく変わります。
判定を人が確かめる5点
Claudeの仕分けは下書きです。契約の解釈は当事者の責任で決める事柄なので、提出前に次の5点を確認します。
- 根拠として挙がった条項番号が、SOWに実在し、引用文言が一致しているか
- 「範囲内」の判定に、前提条件の確認が抜けていないか
- 「範囲外」の判定が、除外事項ではなく単なる記載漏れに基づいていないか(記載漏れなら本来は要確認)
- 工数の単価と工程が、見積内訳と一致しているか
- 口頭の合意やメールのやり取りが、SOWの記載を事実上変えていないか
Claudeが見るのはナレッジに置いた文書だけなので、打合せでの口約束は判定に反映されません。判定ログに「合意の事実」を足す運用にしておくと、抜けが減ります。
契約の形で、変更の扱いが変わる
IPAが公開する「情報システム・モデル取引・契約書」には、第二版(受託開発、保守運用など)とアジャイル開発版があります。第二版の見直しのポイントには、プロジェクトマネジメント義務および協力義務が含まれ、Wordのひな型は自由にカスタマイズして使えると案内されています。
一方、アジャイル開発版は、あらかじめ特定した成果物の完成に対価を払う請負契約ではなく、専門家としての業務遂行に対価を払う準委任契約を前提とします。機能の追加・変更や優先順位の変更に柔軟に対応できる手法として設計されているためです。
この違いは、今回の判定の使い方に直結します。請負で成果物が固定されている案件なら、SOWの成果物リストと変更要求を直接照合する型がそのまま使えます。アジャイル版を前提とする案件では、「範囲内か」よりも、バックログ上の優先順位をどう入れ替えるか、体制と期間の中で何を落とすかを判断する場面が増えます。その場合は、本記事の3区分を「バックログに入れる」「入れ替えが必要」「期間・体制の見直しが必要」のように読み替えます。
どちらの契約でも、条文の解釈は契約書そのものと法務の確認に従います。IPAのページに載っているのはひな型と解説であり、個別の契約の解釈を代わりに決めるものではありません。
変更が積み重なったときの扱い
1件ずつ「軽微」と判定していった結果、全体では当初見積を大きく超えていた、という事態はよく起きます。判定ログのProjectに、累積の工数を載せる行を作ります。
| 番号 | 受領日 | 判定 | 追加工数(人日) | 累計 | 顧客の回答 |
|---|---|---|---|---|---|
| CR-001 | 10/02 | 範囲内 | 0 | 0 | - |
| CR-002 | 10/05 | 要確認→範囲外 | 3.0 | 3.0 | 見積を依頼 |月に1度、このログをClaudeに渡して「累積で当初見積の何%か」「RAIDの前提に反する変更が重なっていないか」を点検させます。累計の計算は表の数値を足すだけなので、結果を電卓で確かめられます。
運用手順書や変更管理の様式づくりは、Coworkのプラグインを使う進め方をClaudeのoperationsプラグインでrunbook・変更管理・ベンダー評価を整えるに載せています。法務の観点から契約書を標準化する進め方はClaude Projectsで法務レビューのプレイブックを標準化する方法が参考になります。
つまずきやすい点
- SOWの別紙が欠けている: 本文だけを置くと、成果物の詳細や除外事項が別紙にある場合に判定が成り立ちません。別紙まで含めて全文を置きます。
- 判定の根拠が「趣旨から見て」になっている: 条項番号を挙げられないときは、要確認に戻します。
- 共有範囲の見落とし: Team・Enterpriseではプロジェクトを共有でき、閲覧のみか編集可かを選べます。SOWや見積が載るProjectは、共有先を案件の担当者に絞ります。管理者が共有をオフにしていても既存の共有は残るため、開始時に状態を見ておきます。
- 顧客に判定をそのまま転送する: 下書きには社内向けの検討が混ざります。顧客への回答は、人が書き直したものを使います。
まとめ
この型の中心は、判定を3区分に固定し、条項番号と前提への影響を必ず併記させることにあります。Claudeに判断を任せるのではなく、根拠付きの仕分け表を速く作らせ、最後の線引きは人が決めます。
最初の一歩は、進行中の1案件のSOW、見積内訳、RAIDログを1つのProjectに入れ、過去に迷った変更要求を3件貼って仕分けさせてみることです。人の判断と食い違った箇所が、指示文やSOWの書き方を直す手がかりになります。