この記事の対象: サイト制作を発注する担当者、および発注側の要件整理を支援する制作者
読了時間: 約16分
「要件定義をちゃんとやりましょう」と制作会社に言われても、何をどこまで決めれば「ちゃんと」なのか、発注側には判断のしようがありません。社内で聞き取りをしても出てくるのは「今のサイトは古い」「もっとおしゃれに」といった感想ばかり。それを制作会社に持っていくと、見積もりは会社ごとにバラバラで、比較すらできない。
この記事は、その詰まりをAIで抜けるようにするための手順書です。ヒアリング内容の整理、要件の抜け漏れチェック、RFP（提案依頼書）の草案作成まで、実際に手を動かす順番で書いています。制作会社の側で要件定義を回してきた立場から、「AIに任せていい部分」と「任せると必ず事故る部分」を線引きして示します。
先に結論を書いておきます。AIは要件定義の”書記”と”検査役”としては極めて優秀ですが、”決定者”には絶対にできません。 この線を引けるかどうかで、AIを使った要件定義は工程の短縮になるか、後工程で倍の手戻りを生むかに分かれます。
要件定義でAIが効く場所、効かない場所
そもそも要件定義の何が難しいのか
要件定義が難しいのは、専門知識が要るからではありません。社内の頭の中にある情報が、言語化されていない状態で散らばっているからです。
制作会社としてキックオフに入ると、だいたい次の状態になっています。
- 経営層は「ブランドイメージを刷新したい」と言う
- 営業部は「問い合わせフォームの項目を減らしてほしい」と言う
- 情報システム部は「今のサーバーの契約がどうなっているか分からない」と言う
- 発注担当者は、この3つをどうまとめればいいか分からない
この3つは矛盾していません。ただ、粒度がバラバラなだけです。要件定義とは、粒度の違う要望を同じ階層に並べ直して、優先順位をつけ、やらないことを決める作業です。
AIが効くのは、まさにこの「並べ直す」ところです。逆に「優先順位をつける」「やらないことを決める」は、社内の政治と予算が絡むので、AIには原理的に判断できません。
工程2と3にAIを入れると、資料を突き合わせて整理する時間が目に見えて縮みます。ただし工程4を飛ばすと、要件が全部「必須」のまま制作会社に渡り、見積もりが跳ね上がります。
制作会社が本音で困っているRFPの状態
発注側にはあまり伝わっていないと思うので書いておきます。制作会社が見積もりを出しづらいRFPには、共通する特徴があります。
| よくある記述 | 制作会社が困る理由 | 見積もりへの影響 |
|---|---|---|
| 「スマホ対応」 | レスポンシブ対応か、スマホ専用デザインかで工数が大きく違う | 高いほうで見積もる |
| 「CMS化」 | 全ページ編集可能か、お知らせだけかで大差 | 高いほうで見積もる |
| 「既存コンテンツを移行」 | 何ページあるか書いていない | ページ数を多めに想定する |
| 「多言語対応」 | 機械翻訳か人力翻訳か、言語数はいくつか | 保留か、注記付きで除外 |
| 「SEO対策を含む」 | 内部施策だけか、記事制作も含むか | 内部施策のみで見積もる |
| 「デザインは一新」 | 既存のロゴ・トーンを踏襲するか、CIから作り直すか | ヒアリング後に再見積もりとなりやすい |
曖昧な要件は、見積もりでは必ず「高いほう」に倒れます。 制作会社は後から「そこまで含んでいませんでした」と言うのを避けたいので、安全側に振るからです。つまり、要件が曖昧なだけで発注側は損をしています。
ここがAIで最も費用対効果が出るところです。RFPの各項目を「この記述で、実装範囲が一意に決まるか」という観点でAIに検査させると、上の表のような曖昧さが機械的に洗い出せます。予算の考え方そのものは、こちらで整理しています。
ステップ1：ヒアリングをAIで設計する
質問票をAIに作らせる前にやること
いきなり「Webサイトのヒアリングシートを作って」とAIに投げると、一般論の質問が大量に返ってきます。これをそのまま社内に配ると、回答率が落ちて逆効果です。
先にこの3つを決めてから投げます。
- 誰に聞くか（経営層／事業部／情報システム／現場担当）
- 何分もらえるか（30分なら質問は8〜10問が限界）
- 既に分かっていること（現サイトのURL、大まかな予算感、公開希望時期）
3つ目が特に重要です。既知の情報を先に渡さないと、AIは「予算はいくらですか」のような、聞くまでもない質問を上位に置いてきます。
実際に使えるプロンプトの形
制作会社側で使っている型を、発注側でも使える形に直すとこうなります。
あなたはWeb制作のディレクターです。以下の条件でヒアリング質問票を作ってください。
【対象】製造業のBtoB企業、従業員120名、コーポレートサイトのリニューアル
【聞く相手】営業部長（30分）
【既に分かっていること】
- 現サイトは8年前に制作、全42ページ
- リニューアルの主目的は問い合わせ数の増加
- 公開希望は来年4月
【条件】
- 質問は10問以内
- 「今のサイトの不満」のような感想を聞く質問は入れない
- 回答が数値または固有名詞で返る質問を優先する
- 各質問に「この質問で何を確定させたいのか」を1行で添える
最後の2つの条件が肝です。「不満を聞かない」「数値で返る質問を優先する」と縛ると、「サイトが古いので新しくしたい」という回答が構造的に出てこなくなります。
たとえばAIが返してくる質問は、こんな形になります。
- 「昨年1年間で、Webサイト経由の問い合わせは何件ありましたか」（→ 現状値の確定）
- 「そのうち商談化したのは何件ですか」（→ 質の評価軸の確定）
- 「営業資料としてサイトのどのページを客先で見せていますか」（→ 実際に使われているページの特定）
- 「問い合わせ以外に、サイトで代替したい業務はありますか」（→ 隠れた要件の発掘）
3つ目のような質問は、社内の人間だけで作る質問票にはまず入りません。外の視点が入るのがAIの実質的な価値で、機能紹介でよく言われる「時短」は副次的なものです。
相手ごとに質問の階層を変える
同じ質問票を全部署に配ると、答えられない質問が並んで回答率が落ちます。相手ごとに、返ってくる情報の階層が違うからです。
| 聞く相手 | この人からしか取れない情報 | 聞いても答えが出ない質問 |
|---|---|---|
| 経営層 | 投資の目的、判断の期限、やらないと決めていること | ページ構成、機能の細部 |
| 事業部・営業 | 実際に使っているページ、顧客からよく聞かれること | サーバー・ドメインの契約 |
| 情報システム | 契約名義、社内規定、既存システムとの連携条件 | デザインの方向性 |
| 更新の現場担当 | 更新の頻度と手順、今つまずいている作業 | 予算、公開時期 |
右の列を混ぜないだけで、1回の打ち合わせで確定する項目が増えます。AIに質問票を作らせるときも、「聞く相手」を条件に明記していないと、この階層が混ざったものが返ってきます。
議事録の処理は「要約」させない
ヒアリングの録音や議事メモをAIに渡すとき、「要約して」と頼むのは悪手です。要約は情報を捨てる操作なので、後で効いてくる細かい発言（「そういえば工場見学の申し込みも受けてるんですよ」）が消えます。
代わりにこう指示します。
以下の議事録から、発言を次の5つに分類して全件書き出してください。要約せず、発言の趣旨を保ったまま1件1行にしてください。
1. 事実（数値・現状の仕様・既存の運用）
2. 要望（こうしたい・こうなってほしい）
3. 制約（予算・時期・社内規定・技術的制約）
4. 懸念（不安・過去の失敗・リスク）
5. 判断が必要な事項（社内で決まっていないこと）
分類に迷うものは「5」に入れ、迷った理由を添えてください。
「5」に落ちたものが、そのまま要件定義の宿題リストになります。 制作会社に投げる前に社内で潰しておくべき論点が、この時点で可視化されます。
複数回のヒアリングをまとめるときは、分類したものを部署名つきで1つのファイルに集めてから、「同じ対象について異なる発言をしている箇所を抽出してください」と追加で指示します。ここで出てくる食い違いが、後工程で仕様変更として噴き出すものの正体です。早い段階で見えていれば、決定の場を1回設けるだけで済みます。
ステップ2：要件の抜け漏れをAIに検査させる
検査の観点をこちらから指定する
「抜け漏れをチェックして」と丸投げすると、AIは一般論のチェックリストを返してきます。それも無駄ではありませんが、実務で本当に漏れるのは決まった場所です。
制作の現場で、公開直前に発覚して揉めるのはこの順です。
| 漏れやすい項目 | 発覚するタイミング | 追加費用が発生しやすいか |
|---|---|---|
| ドメイン・サーバーの管理権限の所在 | 公開作業の直前 | 移管作業費が発生することがある |
| 既存サイトからのリダイレクト設定 | 公開後、検索順位が落ちてから | 別途作業になりやすい |
| 原稿・写真を誰が用意するか | デザイン確定後 | 撮影・ライティング費が別建て |
| 公開後の更新は誰がやるか | 納品直前 | 保守契約の話が後出しになる |
| フォームの送信先・個人情報の扱い | テスト段階 | 大きな追加はないが遅延要因 |
| アクセス解析の引き継ぎ | 公開後 | 設定費が発生することがある |
この6項目は、AIに検査させるときの観点として最初から渡してしまうのが早いです。
以下の要件メモを、次の6観点で検査してください。
各観点について「記載あり／記載なし／記載はあるが曖昧」の3択で判定し、
「曖昧」と判定したものは、どう書き直せば一意になるかを例示してください。
1. ドメイン・サーバーの契約名義と管理権限
2. 既存URLからのリダイレクト方針
3. 原稿・写真素材の用意者
4. 公開後の更新作業の担当
5. フォームの送信先と個人情報の取り扱い
6. アクセス解析ツールの設定と引き継ぎ
【要件メモ】
（ここに貼る）
ドメインの名義は特に揉めます。制作会社の名義で取得されていると、後で乗り換えるときに手間がかかります。
「反対から読む」検査が効く
もう一つ、実務で効く使い方があります。要件メモをAIに渡して、制作会社の立場で読ませる方法です。
あなたはこのRFPを受け取った制作会社の見積もり担当者です。
見積もりを作るにあたって、判断に迷う箇所と、
安全側（高いほう）に見積もらざるを得ない箇所を全て挙げてください。
なぜ高く見積もることになるのかも書いてください。
これを1回通すだけで、見積もりが膨らむ原因が事前に潰せます。制作会社の中の人間として言うと、この検査を通したRFPは受け取った瞬間に分かります。 質問のラリーが少なく済むので、こちらとしても歓迎です。
「AIで対策された」と身構える制作会社はまずいません。要件が明確なほうが、作る側も見積もりを外さずに済むからです。
同じやり方は、選定基準にも使えます。「この選定基準で提案を評価したとき、どの制作会社でも似た提案になってしまう箇所はどこか」と聞くと、差がつかない項目が見えます。全社が同じ答えを書く項目に配点を割いても、比較の材料になりません。
AIが検査できないもの
一方で、AIには絶対に判定できない項目があります。
AIに任せてよい
- 記述の曖昧さ・多義性
- 項目の抜け漏れ
- 要件どうしの矛盾
- 用語の不統一
- 粒度のばらつき
人が判断するしかない
- 社内で誰が承認できるか
- 本当の優先順位
- 予算の上限と配分
- 過去の失敗の背景事情
- 現場が実際に運用できるか
右側は、社外の人間にも見えない情報です。AIは学習データの中の一般論から答えを作るので、それらしい嘘を返します。「この要件の優先順位を決めて」とは絶対に聞かないでください。
ステップ3：RFP草案をAIに書かせる
RFPに最低限入れる項目
AIに書かせる前に、器の形を決めておきます。項目が決まっていないと、AIは冗長な章立てを提案してきて、読む側の負担が増えます。
1. 前提
- 会社概要・事業内容
- 担当部署と連絡先
- 現行サイトのURL
2. 目的とゴール
- リニューアルの背景
- 達成したい数値目標
- ターゲット
3. 要件
- ページ数と構成案
- 必須機能／任意機能の区別
- CMSの範囲
- デザインの方向性
4. 制約
- 予算の範囲
- 公開希望日
- 使用中のサーバー・ドメイン
- 社内規定・セキュリティ要件
5. 提案・選定の条件
- 提出物と提出期限
- 選定基準と配点
- 質問の受付方法と期限
「必須機能／任意機能の区別」と「予算の範囲」を書くかどうかで、集まる提案の質が変わります。
予算を書くべきか、という論点
発注側でいちばん迷うのがここだと思います。「予算を書くと足元を見られるのでは」という不安は理解できます。
制作会社の側から見た実感を書きます。予算が書かれていないRFPには、そもそも提案が集まりません。 提案書を1本作るのに相応の時間がかかるので、金額の見当がつかない案件は着手の判断ができないからです。結果として、手が空いている会社だけが応募してくる状態になります。
書くなら幅で書くのが実務的です。上下を示すと、その範囲で最大限の提案が集まります。上限だけ示すと全社が上限で見積もってきます。幅の決め方が分からない場合は、「この予算では実現できない要件があれば指摘してください」と提案条件に一文入れておくと、金額の妥当性そのものを提案で検証できます。
予算の考え方が固まっていないなら、費用の内訳を先に把握してからのほうが早いです。
草案を書かせるプロンプト
ステップ1と2で整理した材料を全部渡して、こう指示します。
以下の材料からRFP（提案依頼書）の草案を作ってください。
【構成】
1. 前提 / 2. 目的とゴール / 3. 要件 / 4. 制約 / 5. 提案・選定の条件
【厳守事項】
- 材料に書かれていない情報を補完しない。
情報が足りない箇所は「【要確認：〇〇】」と明示して空欄にする
- 要件は「〜できること」の形で書き、実装方法を指定しない
- 必須要件と任意要件を明確に分ける
- 「〜など」「適宜」「柔軟に」といった、範囲が定まらない語を使わない
【材料】
（ヒアリング整理結果と、抜け漏れ検査の結果を貼る）
「材料にない情報を補完しない」という縛りが最重要です。 これを入れないと、AIは一般的なコーポレートサイトの要件を勝手に埋めてきます。それらしく仕上がるので気づきにくく、実際には社内で誰も決めていない要件が混ざったまま制作会社に渡ることになります。
制作会社の側でこれを受け取ると、キックオフで「この要件はどなたのご要望ですか」と聞いた瞬間に、全員が黙ることになります。AIを要件定義に使い始めた発注企業で、実際に起きている事故です。
出てきた草案を必ず人が読む3か所
草案が出たら、この3か所だけは必ず人が目で見ます。
- 【要確認】タグが付いた箇所 — ここが社内の宿題です。件数が多いほど、AIが正直に働いた証拠になります
- 数値が書かれている箇所 — 「月間PV」「問い合わせ件数」などは、AIが埋めた数字ではないか確認します
- 必須要件に振り分けられた項目 — AIは迷ったものを必須に倒す傾向があります。任意に落とせるものがないか見ます
3つ目は費用に直結します。必須要件が1つ減るだけで、見積もりの根拠が変わることがあります。
なお、この確認は紙に印刷するか、PDFにしてから通すほうが漏れません。画面のスクロールで読むと、それらしく整った文章は目が滑ります。AIの出力は文体が均質なので、粗が文章の見た目に出てこないという性質があります。
発注側がやる場合と、制作会社に任せる場合
要件定義を制作会社に発注するという選択肢
実は、要件定義そのものを制作会社に有償で依頼する方法があります。「要件定義フェーズ」「上流工程」といった名前で、制作本体とは別契約にする形です。
どちらを選ぶべきかは、次の基準で分かれます。
| 判断軸 | 自社でやる | 制作会社に依頼する |
|---|---|---|
| 社内の意見が割れているか | まとまっている | 部署間で対立がある |
| 現行サイトの管理情報 | 把握できている | 誰も把握していない |
| 担当者の稼働 | 週に数時間確保できる | ほぼ確保できない |
| 業務システムとの連携 | 連携なし | 基幹システムと繋ぐ |
| 制作会社の選定 | これから相見積もり | 1社に決めている |
社内の意見が割れているときは、外部に入ってもらったほうが早く進みます。 社内の人間が調整すると力関係が働きますが、外部のディレクターが「両方は予算内で入りません」と言うほうが通ります。これは制作会社が請け負う価値の中でも、実は上位に来るものです。
一方で、相見積もりを取る前提なら、要件定義は自社で持っておくべきです。1社に要件定義を任せると、その会社が作りやすい要件になるのは避けられません。依頼する場合でも、成果物の権利と持ち出しの可否を契約時に確認しておけば、この不利は緩和できます。
制作会社側もAIを使っている、という前提
もう一つ、発注側に知っておいてほしいことがあります。制作会社の側でも、要件定義の周辺工程にAIが入っているのは珍しくありません。 議事録の整理、要件の構造化、提案書の下書きは、AIが手前を引き受けている現場が増えています。
これ自体は問題ではありません。むしろ、浮いた時間が設計に回っていれば発注側の利益になります。ただ、発注側として次の2点は確認しておく価値があります。
- 機密情報の取り扱い — 未公開の事業計画や個人情報を含む資料をAIに投入していないか。契約書のNDA条項に、生成AIの利用に関する記載があるかを見ます
- 提案書の内容に責任を持つ人がいるか — AIが書いた提案書には、一般論としては正しいが自社には当てはまらない記述が混ざります。打ち合わせで具体的に掘ると、すぐ分かります
後者の見分け方は簡単です。提案書の中の一節を指して「これはなぜうちに必要なんですか」と聞くだけです。AIの出力をそのまま貼った箇所は、答えが一般論に戻ります。逆に、自社のヒアリング内容を踏まえて書かれた箇所は、「先日おっしゃっていた〇〇があるので」と、こちらが話した事実に紐づいた答えが返ってきます。この質問は、制作会社の力量を測る指標としてかなり有効です。
参考サイトを集める工程もAIに任せない
要件定義の中で「デザインの方向性」を決める工程があります。ここでAIに「参考サイトを教えて」と聞くのは、あまり機能しません。学習データが古く、実在しないURLを返すことがあるからです。
参考サイトは、実物が並んでいるギャラリーから拾うほうが確実です。Soreiine!!ギャラリーのように業種・目的で絞り込めるところで、「好き／嫌い」ではなく「この要素を採用したい／したくない」の粒度でメモを取るのが要件定義向きのやり方です。
たとえば同じ製造業のコーポレートサイトでも、トップに製品カタログを大きく置いているサイトと、技術ストーリーを前面に出しているサイトでは、必要なページ構成もCMSの設計も変わります。前者は製品情報の登録数と更新のしやすさが要件の中心になり、後者は写真と原稿の制作費が要件の中心になります。同じ「かっこいいサイト」でも、見積もりの内訳がまったく別物になるということです。
「この会社の、この見せ方がうちに合う」という一次情報は、社内の合意形成でもいちばん強い材料になります。感想の言い合いになりがちなデザインの議論を、実物を指して話す議論に変えられるからです。
集めた参考サイトは、AIに渡して整理させると使いやすくなります。
以下の参考サイトについて、それぞれのメモを
「レイアウト」「コンテンツの見せ方」「更新頻度が必要な箇所」の3観点で分類し、
共通して採用したい要素を抽出してください。
そのうえで、CMSで更新可能にすべき箇所を一覧にしてください。
「CMSで更新可能にすべき箇所」まで落とすと、そのままRFPの要件になります。 ここが曖昧なままだと、CMS範囲が見積もりの最大の変動要因になります。
AIを使った要件定義でやってはいけないこと
機密情報の投入
一般向けの生成AIサービスでは、入力内容が学習に使われる設定になっている場合があります。要件定義では未公開情報を扱うので、次のものは投入前に判断が要ります。
- 未発表の商品・サービス情報
- 顧客リスト、個人情報を含む資料
- 取引先名が入った資料
- 社内の人事に関わる記述
対応としては、学習に使われない設定のあるプラン（法人向け・API利用）を使うか、固有名詞を伏せ字にしてから投入します。社内にAI利用ルールがない場合、要件定義の前に情報システム部門に一度確認を取っておくのが安全です。 後から「あの資料を入れたのは問題では」と言われると、要件定義そのものがやり直しになりかねません。
「AIが作ったRFP」をそのまま送る
草案は草案です。人が読まずに送ると、次の3つが起きます。
- 社内で決まっていない要件が入る
- 実在しない現状値（PV数など）が入る
- 「〜など」「適宜」といった曖昧語が残り、見積もりが膨らむ
ステップ3で挙げた3か所の確認は、長い時間はかかりません。ここを飛ばして得られる時短より、後工程の手戻りのほうが圧倒的に大きくなります。
技術選定をAIに決めさせる
「WordPressとShopifyのどちらがいいか」といった判断をAIに聞くと、それらしい答えが返ってきます。ただしAIは、運用体制・更新頻度・社内のスキル・既存システムとの連携を知らないまま答えています。
技術選定は要件定義の結論であって、前提ではありません。要件を固めた結果として、選択肢が絞られるという順番です。RFPの段階でCMS名を指定してしまうと、その前提に合わない提案が来なくなり、より良い選択肢を最初から捨てることになります。判断軸を整理してから臨むと、制作会社の提案も正しく評価できます。
全工程のまとめ：3週間で回す進め方
ここまでの流れを、実際のスケジュールに落とします。社内の稼働を週に数時間と想定した場合の目安です。
| 週 | やること | AIの使いどころ |
|---|---|---|
| 1週目 | 関係部署へのヒアリング（3〜5名） | 質問票の作成、議事録の5分類 |
| 2週目 | 要件の整理と抜け漏れ検査 | 6観点の検査、制作会社視点での逆読み |
| 2週目後半 | 社内で優先順位と予算を決定 | 使わない（人が決める工程） |
| 3週目 | RFP草案作成と社内レビュー | 草案生成、曖昧語の検出 |
| 3週目末 | 制作会社へ配布（3〜5社） | 使わない |
AIを入れなければ、この工程はもっと長くかかります。短縮できているのは1週目と2週目の「整理」の部分で、社内の合意形成にかかる時間は1ミリも短くなりません。 そこは人が話し合うしかないので、スケジュールを組むときは合意形成に十分な時間を確保してください。
このスケジュールが崩れるとしたら、原因はほぼ2週目後半です。優先順位を決める場に決裁者が出てこられず、翌週送りになる。ここだけは早めに日程を押さえてください。整理の工程はAIで巻き返せますが、決裁者の予定は巻き返せません。
AIで時間を作った分を、そのまま合意形成に回すのが最も合理的な使い方です。
よくある質問
要件定義書とRFPは何が違うのですか
RFPは制作会社に提案を依頼するための文書、要件定義書は制作の内容を確定させるための文書です。順番としてはRFPが先で、制作会社が決まった後、提案内容をすり合わせて要件定義書に落とします。発注前の段階で作るのはRFPだと考えて問題ありません。
AIに社内資料をアップロードしても大丈夫ですか
サービスと契約プランによります。入力内容が学習に使われる設定のサービスに、未公開情報や個人情報を含む資料を入れるのは避けてください。法人向けプランやAPI経由では学習に使われない設定が用意されていることが多いので、契約内容を確認するか、固有名詞を伏せてから投入するのが安全です。社内にAI利用ルールがあれば、まずそれに従います。
相見積もりは何社に出すのが適切ですか
3〜5社が現実的な範囲です。それ以上に増やすと、提案内容を比較する側の負担が大きくなり、判断の質が落ちます。重要なのは社数より、全社に同一のRFPを配ることです。会社ごとに口頭で条件を変えて伝えると、見積もりの比較ができなくなります。
RFPに予算を書かないほうが安く済みますか
逆になることが多いです。予算が書かれていないと、制作会社は要件を最大限に解釈して安全側で見積もるため、金額が上がります。また、提案を作るコストに見合うか判断できず、提案自体が集まらないこともあります。上下の幅で示すのが実務的です。
要件定義を制作会社に依頼すると費用はどのくらいかかりますか
制作会社や案件規模によって幅があるため一律には言えませんが、制作本体とは別の契約として提示されるのが一般的です。見積もりを取る際は「要件定義フェーズの成果物は何か（要件定義書・サイトマップ・機能一覧など）」と「その成果物を他社に持ち込んで相見積もりを取ってよいか」の2点を必ず確認してください。後者を確認しておかないと、実質的にその会社に発注する以外の選択肢がなくなります。
AIが作ったRFPだと制作会社に嫌がられませんか
嫌がられません。受け取る側が困るのは「AIが作ったこと」ではなく「要件が曖昧なこと」です。範囲が一意に決まるRFPであれば、作り方は問われません。ただし、社内で決まっていない要件がAIの補完で紛れ込んでいると、キックオフで発注側が答えられなくなります。人が読んで潰す工程を省かないことが条件です。
まとめ
AIを使った要件定義は、道具の使い方より役割分担の設計で決まります。
- AIに任せる — ヒアリング質問票の設計、議事録の分類、要件の抜け漏れ検査、曖昧語の検出、RFP草案の生成
- 人が決める — 優先順位、予算配分、必須と任意の線引き、社内の合意形成
- 必ず人が読む — 【要確認】タグ、数値が入った箇所、必須要件に振り分けられた項目
このうち最も費用対効果が高いのは、制作会社の見積もり担当者の立場でRFPを読ませる検査です。曖昧な要件が「高いほう」で見積もられる構造を、事前に潰せます。
そして、AIで浮いた時間は社内の合意形成に回してください。要件定義で最後に効くのは、AIの精度ではなく「社内で誰がどこまで決めたか」だからです。ここが固まっているRFPは、制作会社にとっても仕事がしやすく、結果として提案の質が上がります。
要件が固まったら、次は制作会社への配布と比較です。同一条件で比較するための準備も、あわせて進めておくと詰まりません。
