Claudeで要件定義を整理する手順：RFPを出す前に要件を固める

結論

RFPを出す前の要件整理でClaudeが効くのは、旧システムのマニュアルや改修依頼の履歴といった長い資料を読み込ませ、今できていることを棚卸しさせる工程です。刷新で最も揉めるのは新機能ではなく、これまで当たり前に使えていた機能が消えることなので、ここを先に固めます。資料をプロジェクトに登録すれば会話を分けても同じ材料を見続けられ、要件一覧の初稿は目安として半日で形になります。必須の線引きと対象範囲は、関係部署と決めてから確定します。

Claudeに任せる作業と、外しておく判断

要件定義をAIに任せて危ないのは、社内の事情を知らないまま数値と範囲を決められることです。頼む前に線を引きます。

Claudeに任せる	人が判断する
旧システムの資料から、今ある機能を洗い出す	洗い出した機能のうち、新システムに引き継ぐもの
改修依頼の履歴から、繰り返し出ている困りごとを抽出する	どの困りごとを今回解決するか
要望を、ベンダーが見積もれる文に直す	文に入れる数値と、その根拠
必須と要望に分ける案と理由を示す	予算と期限を踏まえた最終の分類
抜けている観点を指摘する	指摘のうちRFPに載せるもの

右の列に共通するのは、社外に出す文書としての責任です。RFPに書いた要件は、ベンダーの見積もりの根拠になり、契約後は検収の基準になります。Claudeが補った数値がそこに残ると、実際には不要な性能に費用を払うか、逆に必要な条件が抜けたまま契約することになります。

この記事では、従業員600名ほどの卸売業で、15年前に作られた受発注と在庫管理の仕組みを入れ替える場面を例にします。調達部門と業務部門の担当者が要件をまとめ、複数のベンダーにRFPを出すところまでを想定します。

プロジェクトに資料を入れ、読み違いを先に潰す

この種の案件では、手元に紙とPDFが積み上がります。旧システムの操作マニュアル、10年分の改修依頼票、業務フロー図、前回の入れ替え検討で受け取った提案書。これらを案件ごとのプロジェクトに登録しておくと、会話を分けても同じ資料を見たまま続きから作業できます。

登録したら、いきなり要件を書かせず、読み違いを潰します。

このプロジェクトに登録した資料を確認してください。
この段階では要件を書かないでください。

まず、次を教えてください。

1. 登録されている資料の一覧。それぞれ作成年と、何のための文書かを一行で
2. 同じ事柄について、資料の間で記述が食い違っている箇所
3. 資料から読み取れる、受注から出荷までの業務の流れ。
   どの作業をどの部署が担当し、どこで人手の判断が入るかを含めて
4. 資料には出てくるが、意味が説明されていない社内用語の一覧
5. 読み取れなかった箇所と、埋めるために誰に聞くべきか

推測で書いた箇所は、推測だと明記してください。

4番の用語一覧が、あとで効いてきます。「仮引当」「特売枠」「センター止め」のような社内用語は、業務部門の中では通じますが、ベンダーには伝わりません。RFPにそのまま書くと、ベンダーごとに解釈が分かれ、見積もりが比べられなくなります。この一覧に説明を付けたものを、RFPの用語定義の章にそのまま使えます。

2番の食い違いも放置できません。マニュアルの版が複数あると、機能の説明が更新されていないことがあります。どちらが現在の仕様かは、現場に確認します。

プランや時期によって使える機能が異なるため、最新の仕様は公式情報で確認してください。プロジェクトが使えない環境でも、資料をその会話に読み込ませれば同じ手順で進められます。ただし会話を分けるたびに読み込ませ直す必要があります。

具体例1：旧システムでできていることを棚卸しする

刷新の失敗は、だいたい同じ形で起きます。稼働してから「前のシステムではできた処理が、新しいほうではできない」と現場から声が上がる。RFPの時点で今ある機能を出し切っておけば防げます。

登録した操作マニュアルから、旧システムが現在提供している機能を
すべて洗い出してください。

【出力の形】
表にしてください。列は次のとおりです。
・機能名。マニュアルでの呼び方をそのまま使う
・その機能で何ができるか。一行で
・誰が使う機能か
・マニュアル内の該当箇所
・その機能がないと、どの業務が止まるかの推測。推測だと明記する

【条件】
・画面の説明だけで使い道が書かれていない機能も、漏らさず拾う
・帳票の出力、CSVの取り込みと書き出し、締め処理、権限の設定は
  見落としやすいので、特に丁寧に拾ってください
・マニュアルに載っているが、現在も使われているか分からない機能には印をつける

帳票と締め処理を名指しするのには理由があります。月次の締めで出している帳票は、経理や取引先に渡っていることがあり、なくなると業務が止まります。それなのに要件の打ち合わせでは話題に上がりません。毎月自動で出ているので、誰も意識していないためです。

出てきた一覧は、そのまま現場に配って確認してもらいます。「使っていない」と印がついた機能について、本当に使っていないかを聞くのが目的です。年に一度しか使わない機能は、担当者の記憶からも抜けています。使っていないと確認できた機能を外せば、その分だけ見積もりが下がります。

具体例2：改修依頼の履歴から、現場の困りごとを拾う

要望を聞いて回るより、過去に出された改修依頼を読むほうが確かです。依頼票には、そのとき本当に困って書かれた内容が残っています。

登録した改修依頼票の一覧から、次を整理してください。

1. 依頼の内容を、業務の領域ごとに分類する
2. 似た依頼が複数回出ているものを抽出し、何回出ているかと初出の年を添える
3. 依頼されたが対応されなかったものを抜き出し、
   記録に理由が書かれていればそれも添える
4. 依頼の背景から読み取れる、現場が繰り返し困っている状態を
   5つ以内にまとめる。どの依頼を根拠にしたかを併記する

【条件】
・件数を数えた箇所は、根拠にした依頼票の番号をすべて挙げてください
・記録にない事柄を補って書かないでください

2番の繰り返し出ている依頼が、今回の刷新で解くべきものです。同じ依頼が5年にわたって3回出ているなら、運用でしのぐ限界を超えています。1回だけ出た依頼とは重みが違います。

3番からも要件が出てきます。対応されなかった依頼には、「旧システムの構造上できない」という理由が付いていることがあります。これは新システムへの要件そのものです。構造の制約でできなかったことなら、RFPに書いて各ベンダーに実現方法を答えさせる価値があります。

調達の手続きとしてRFPをどう組み立てるかは、RFPをAIで作成する方法にまとめています。

曖昧な要望を、ベンダーが見積もれる文に直す

現場の言葉のままではベンダーが見積もれません。「在庫が合わない」「入力が二度手間」を、判定できる文に書き直します。

次の要望を、ベンダーが工数を見積もれる粒度の要件文に書き直してください。

【出た要望】
・在庫数が実際と合わないことがある
・受注入力と出荷指示で同じ内容を二度入力している
・得意先ごとの特別な単価の管理が煩雑
・在庫の引き当てを手作業で調整している
・過去の出荷実績をすぐに出せない

【書き直しのルール】
・1つの要望につき、実現の幅が違う案を2つ出す。狭い案と広い案にする
・「誰が」「どの操作をしたときに」「何が成立していれば達成か」を含む文にする
・数値と期間は、私が伝えていない限り空欄にし「要確認」と記す
・その要望の裏側で実際に起きている問題を一行で推測し、推測だと明記する
・登録した資料の中に関連する記述があれば、その箇所を引用する
・この要望を満たす方式が複数ありうる場合は、方式を指定せず、
  達成すべき状態だけを書いてください

最後の条件が、RFPでは特に効きます。要件に方式を書き込むと、ベンダーが持っている良い解き方を潰してしまいます。「バーコードで読み取れること」と書けばその方式しか出てきませんが、「出荷時の数量の誤りを、出荷確定の前に検知できること」と書けば、各社が自分の製品に合った方法を提案します。比べる材料が増えます。

狭い案と広い案を並べさせるのにも狙いがあります。「在庫が合わない」を完全に解こうとすると棚卸しの仕組みまで広がり、予算を超えます。狭い案が手元にあれば、削る判断がしやすくなります。

必須と要望を分け、評価の観点に変える

要件がそろったら分類します。RFPでは、この分類がそのままベンダーの評価表になります。

整理した要件を、次の3段階に分けてください。

A：これがないと日々の受発注と出荷が回らない
B：あると業務が改善するが、運用でしのげる
C：今回は対象外とし、稼働後に検討する

【条件】
・分けた理由を、回らなくなる場面として一行で書く
・AとBのどちらとも言えるものは分類せず「要協議」として別に並べ、
  判断が分かれる理由を書く
・Aに入れた要件は、外したときに誰の作業が増えるかを添える
・分類の結果を、ベンダーの提案を比べるための評価の観点に組み替えてください。
  観点ごとに、提案書で何を書いてもらえば比較できるかを一行で示す

最後の指示で、要件一覧が評価表に変わります。RFPを出してから評価の観点を考え始めると、各社の提案書が出そろった後で「この項目は聞いていなかった」と気づきます。要件を分類した勢いのまま観点まで作っておくと、比較の軸がぶれません。ベンダーの絞り込みの進め方はベンダー評価をAIで整理する方法で扱っています。

要協議に並んだ項目は、調達部門と業務部門の責任者で決めます。ここを曖昧にしたままRFPを出すと、契約の直前に「これは必須だと思っていた」という話が出ます。

抜けを突かせ、別画面に要件一覧を出す

出し切ったつもりの要件にも穴があります。立場を変えて読ませます。

ここまでの要件一覧を、次の4者の立場で読み直してください。

1. RFPを受け取って見積もりを出すベンダーの担当者
2. 当社の情報システム部門で、稼働後の運用を担当する人
3. 出荷を担当する物流センターの現場責任者
4. 旧システムのデータを移す作業を請け負うベンダー

それぞれの立場から「これでは判断できない」「これが書かれていないと困る」
と感じる箇所を5点以内で挙げ、影響の大きい順に並べてください。

次の観点は書かれているかどうかを必ず確認し、なければ指摘してください。
・旧システムのデータをどこまで移すか。移行期間中の二重運用の有無
・取引先や物流の仕組みとのデータのやりとり
・繁忙期の処理量と、その時間帯
・停止した場合に業務を続ける手段
・操作する人数と、教育にかけられる期間
・稼働後の保守と、問い合わせの窓口

データ移行の範囲は、見積もりの金額が最も動く部分です。10年分を全部移すのか、直近3年で足りるのかを決めていないと、各社の金額が比べられません。

指摘を反映したら、要件一覧を文書の形で出させます。会話の中に長い表を出させると、修正のたびに全体が出し直されて読みにくくなります。成果物を別画面に出す機能を使うと、要件一覧が独立した文書として残り、章ごとの修正が会話の流れに埋もれません。

ここまでの内容を、RFPに添付する要件一覧として別画面の文書にまとめてください。

【構成】
1. 刷新の背景と目的
2. 対象業務の範囲と、対象外とする業務
3. 用語定義
4. 現行機能の一覧と、新システムへの引き継ぎ方針
5. 機能要件 … 表にする。列は 番号 / 要件 / 分類 / 確認方法 / 出どころ
6. 非機能要件 … 処理量、応答、稼働時間、権限、記録、保守
7. データ移行の範囲と方針
8. 外部システムとの連携
9. 提案書に記載を求める事項
10. 未決事項 … 誰にいつまでに確認するかを併記する

【条件】
・私が伝えていない数値は書かず、すべて「要確認」と記す
・5章の出どころ欄には、資料名と該当箇所か、確認した担当者の部署を入れる
・実現方式を指定する記述があれば、達成すべき状態の記述に直す

うまくいかないときの対処

資料に書かれていないことが要件として出てくる。 一般的な業務システムの知識で補われた結果です。出どころの欄が空欄のものを全部抜き出し、資料に該当箇所があるかを確かめてから残します。

旧システムの機能の洗い出しが粗い。 マニュアル全体を一度に扱わせると起こります。章ごとに区切って、受注、在庫、出荷、帳票のように領域を指定して繰り返すほうが細かく拾えます。

要件が実現方式に寄ってしまう。 現場が製品名や画面の作りで要望を語っているときに起こります。「どの製品でも答えられる形に、達成すべき状態だけで書き直してください」と指示し直します。

長い資料の一部しか参照されていないように見える。 該当箇所の引用を必ず添えさせると、どこを読んだかが分かります。引用が特定の章に偏っていたら、他の章を名指しして読ませます。

やりとりが長くなり、前半の条件が守られなくなる。 別画面に出した要件一覧を保存し、新しい会話で読み込ませて続けます。プロジェクトに資料を入れておくと、この再開が軽くなります。

分類が甘く、ほとんどが必須になる。 「予算が3割減ったとして、それでも必須に残すものを選び、外したものについて運用でどうしのぐかを書いてください」と頼むと、判断の材料が出ます。出てきた案は、そのまま採用せず責任者と見直します。

RFPに載せる前に人が確かめること

Claudeが出した要件一覧は、社内の誰も合意していない下書きです。社外に出る文書なので、確認は厚めに取ります。

現行機能の一覧を、受注、在庫、出荷、経理の各担当者に配り、使っている機能と使っていない機能に印をつけてもらいます。これが最も抜けを防ぎます。

処理量、応答時間、稼働時間、データ移行の範囲は、情報システム部門と一緒に数えて埋めます。空欄のまま出すと、ベンダーが各社の想定で見積もり、比較できない金額が並びます。

用語定義は、業務部門の責任者に読んでもらいます。社内で意味が揺れている言葉が見つかることがあり、それはRFPを出す前に揃えるべきものです。

入力する情報にも注意が必要です。改修依頼票には取引先名や担当者名が含まれます。旧システムの仕様書は、ベンダーとの契約で外部に出せない場合があります。読み込ませてよいかは、自社の生成AI利用ルールと契約条項を先に確認してください。判断がつかないときは、社名を記号に置き換えても要件の整理は進められます。

同じ作業を他のツールで進める手順は、ChatGPTで要件定義を整理する手順とCopilotで要件定義を整理する手順にまとめています。

まとめ

旧システムの操作マニュアルと、過去3年分の改修依頼票を探すところから始めてください。見つかった資料をClaudeのプロジェクトに登録し、読み違いを潰したうえで、今できていることの一覧を出させます。その一覧を現場に配って印をつけてもらえば、引き継ぐ機能と捨てる機能が決まります。要件の分類まで進んだら、そのまま評価の観点に組み替え、RFPを出す前に比較の軸を確定させてください。