ChatGPTで要件定義を整理する手順:曖昧な要望を発注できる形に
この記事の要点
ChatGPTで要件定義を整理するには、ヒアリング項目の洗い出し、曖昧な要望を測れる言葉に直す書き換え、必須と要望の切り分け、抜けの指摘の4つを頼みます。問い合わせ管理システムの刷新を例に、プロンプトと確認の手順を解説します。
結論
ChatGPTに要件定義を頼むときは、決めることではなく整理することを任せます。ヒアリングで聞くべき項目の洗い出し、「使いやすくしたい」のような要望を測れる言葉に直す書き換え、必須と要望の切り分け、抜けている観点の指摘の4つなら、初稿は目安として30分ほどで手元に届きます。何を必須にするか、いくらまで出すか、いつまでに動かすかは、現場と関係者に確かめたうえで人が決めます。
ChatGPTに任せてよいことと、決めさせてはいけないこと
要件定義でAIを使って失敗するのは、たいてい切り分けを曖昧にしたときです。線はこう引きます。
| 任せてよい作業 | 人が決めること |
|---|---|
| ヒアリングで聞くべき項目を並べる | 誰に何を聞きに行くか |
| 曖昧な要望を、測れる条件に書き換える案を出す | その条件の数値をいくつにするか |
| 必須と要望を分ける案と、その理由を示す | 最終的にどれを必須にするか |
| 抜けている観点を指摘する | 指摘のうち、今回対応するもの |
| 要件を文書の形に組み立てる | 各要件が現場の運用に合っているか |
右の列に共通するのは、社内の事情を知らなければ決められないという点です。予算の上限、部署間の力関係、過去に失敗した経緯、来期の組織変更。ChatGPTはどれも知りません。知らないまま書かせると、もっともらしい数値が入った要件定義書ができあがり、それが独り歩きします。
この記事では、従業員400名ほどの製造業で、顧客からの問い合わせを管理する仕組みを入れ替える場面を例にします。今はExcelの台帳と共有メールボックスで回していて、担当者が休むと過去のやりとりが追えなくなる。この状態から、開発会社に見積もりを頼めるところまで要件を整理します。
前提を固定してから始める
同じ内容を毎回説明し直す時間がもったいないので、会話を始める前に前提を置きます。ChatGPTにはプロジェクトという入れ物と、すべての会話に効くカスタム指示があり、どちらに書いても構いません。要件定義のように何日もかけて進める仕事では、案件ごとのプロジェクトを作り、そこに前提と資料を置くほうが混ざりません。
プロジェクトに入れておく前提は、次の内容です。
このプロジェクトは、当社の問い合わせ管理システムを入れ替えるための要件定義です。
以下を前提として、すべての回答で守ってください。
【組織】
・従業員400名の製造業。自社製品を代理店経由で販売している
・問い合わせを受けるのは、カスタマーサポート課の6名
・情報システム部門は2名で、他システムの運用も兼務している
・私は営業推進部の担当者で、要件定義を書くのは初めて
【現状】
・問い合わせはExcelの台帳と共有メールボックスで管理している
・月の問い合わせ件数は約900件
・過去のやりとりは担当者の個人フォルダに散在している
【守ってほしいこと】
・私が伝えていない数値、期限、金額を、事実であるかのように書かない
・数値が必要な箇所は、空欄にして「要確認」と書く
・専門用語を使うときは、その場で普通の言葉に言い直す
・要件を書くときは、必ずその要件の出どころを併記する
最後の指示が効きます。出どころを書かせておくと、あとで「これは誰が言ったことなのか」を追えます。ChatGPTが気を利かせて足した要件は出どころが空欄になるので、一目で見分けられます。
プランや時期によって使える機能が異なるため、最新の仕様は公式情報で確認してください。プロジェクトが使えない環境なら、同じ前提文を会話の1通目に貼り付けても同じように動きます。
ヒアリング項目を洗い出す
現場に話を聞きに行く前に、聞くべきことを並べさせます。要件定義の経験が浅いと、機能の希望ばかり聞いて帰ってきて、あとで運用や権限の話が抜けていたと気づきます。
問い合わせ管理システムの入れ替えについて、現場にヒアリングする項目を作ってください。
相手は次の3者です。それぞれ別のリストにしてください。
1. カスタマーサポート課の担当者3名。毎日この台帳を触っている
2. カスタマーサポート課の課長。件数や対応時間を月次で報告している
3. 情報システム部門の担当者
【条件】
・1人あたり30分で聞ける分量にする。合計15問以内
・「どんな機能が欲しいですか」のように、相手に解決策を考えさせる質問は入れない
・代わりに、今どうやっているか、何に困っているか、直近で困った実例を引き出す質問にする
・各質問の後ろに、その質問で確かめたい要件の観点を一言添える
・聞き忘れると後戻りが大きい質問には、印をつける
解決策を聞かないという条件は外せません。現場に機能を聞くと「検索を速くしてほしい」という答えが返り、それを要件に書いてしまいます。実際には検索が遅いのではなく、過去のやりとりがメールとExcelに分かれていて2か所を見ているだけ、ということがあります。困っている状態を聞けば、解決策は後で選べます。
ヒアリングの記録をそのまま要件の材料にする進め方は、ChatGPTで議事録を作成する手順と合わせて読むと流れがつながります。
具体例1:曖昧な要望を、検証できる条件に書き換える
ヒアリングから戻ると、手元には現場の言葉が並びます。「使いにくい」「探せない」「二重入力が面倒」。このままでは開発会社に渡せません。測れる形に直します。
ヒアリングで出た要望を、検証できる条件に書き換えてください。
【出た要望】
・台帳が使いにくい
・過去の似た問い合わせが探せない
・メールと台帳に二重入力していて面倒
・担当者が休むと状況が分からない
・月次の集計に時間がかかる
【書き換えのルール】
・1つの要望につき、条件の案を2つ出す。条件の厳しさを変えて並べる
・条件は「誰が」「どの操作をしたときに」「どうなっていれば達成か」の形にする
・時間や件数の数値は、私がヒアリングで確認していない限り空欄にして「要確認」と書く
・その要望が、今の運用のどこで起きているのかを1行で添える
・書き換えた条件が満たされたかを、受け入れテストでどう確かめるかも1行で書く
出てくるのは、たとえばこういう形です。「担当者が休むと状況が分からない」は、「サポート課の全員が、担当者以外の問い合わせについても、対応状況と直近のやりとりを一覧画面から確認できること」に変わります。そして確かめ方として「担当者Aの問い合わせを、担当者Bのアカウントで検索し、最新の返信本文まで表示できるか」が添えられます。
数値の空欄は自分で埋めます。「集計に時間がかかる」を「月次集計を5分以内で終えられること」にするかどうかは、今何分かかっていて、どこまで短くなれば課長の作業が楽になるかを知っている人しか決められません。ChatGPTが勝手に埋めた数字をそのまま通すと、後になって過剰な要件だったと分かり、見積もりが跳ね上がります。
必須と要望を分ける
条件の形に直った要件は、たいてい30から50項目になります。全部を必須にすると予算に収まりません。
先ほど整理した要件を、次の3つに分類してください。
A:これがないと、今の業務が回らない
B:あると業務が改善するが、なくても運用でしのげる
C:今回は見送り、次の段階で検討する
【条件】
・分類の理由を、業務がどう止まるかという観点で1行ずつ書く
・AとBの境目が微妙なものは、判断が分かれる理由を添えて別に並べる
・Aに分類した要件について、それを外したときに現場で何が起きるかを一言書く
・私が答えていない前提が必要な分類は、分類せずに質問として返す
判断が分かれるものを別に並べさせるのが、この指示の狙いです。ここに並んだ項目こそ、課長や情報システム部門と話し合うべき論点になります。すべてをきれいに3分類して返されると、議論すべき場所が見えません。
分類が終わったら、Aの要件だけを持って現場に戻ります。「これがないと業務が回らないと整理しましたが、合っていますか」と聞くと、現場から「これは運用で回避できる」「むしろこっちが抜けている」という反応が返ります。この往復を1回挟むかどうかで、要件の精度が変わります。
具体例2:現行の台帳を添付して、今の運用を要件に翻訳する
ヒアリングで出てこない要件は、現物の中に埋まっています。Excelの台帳をChatGPTに添付し、列の構成から運用の実態を読ませます。
顧客名や担当者名が入ったままのファイルを上げてよいかは、社内ルール次第です。判断がつかないときは、1行目の列名だけを残し、中身をダミーに置き換えたファイルを作れば足ります。列名と入力規則さえあれば、運用の推測はできます。
添付したファイルは、現在使っている問い合わせ管理台帳です。
中のデータはダミーに置き換えてありますが、列の構成と入力規則は実際のものです。
このファイルから、次を読み取ってください。
1. 各列が、業務のどの作業のために作られたと考えられるか
2. 列の中に、実質的に同じ情報を二重に持っているものがないか
3. 入力が任意になっているが、本来は必須であるべき列
4. この台帳では記録できていないが、問い合わせ対応では必要になるはずの情報
5. 新システムに移すときに、そのまま移してはいけない列とその理由
推測で答える箇所には、その旨を明記してください。
4番の指摘が役に立ちます。今の台帳にない列は、現場が「あればいいのに」と思いながら諦めている情報です。一次回答の期限、エスカレーションの相手、製品のロット番号。指摘が出たら現場に持ち帰り、実際に必要かを確かめます。ChatGPTの推測をそのまま要件に入れると、使われない項目が増えます。
5番は移行の話につながります。担当者名を自由入力で持っている列は、そのまま移すと新システムでも表記ゆれが続きます。ここで気づいておくと、移行の要件を見積もりに含められます。
現場の問い合わせ対応そのものを整理し直したい場合は、問い合わせ対応をAIで効率化する方法も参考になります。
抜けを指摘させ、別画面で文書に組み立てる
要件がそろったと思った時点で、抜けを探させます。自分で作ったものの穴は自分では見えません。
ここまでに整理した要件一覧を、次の3つの立場から読み直してください。
1. この要件で開発を請け負う開発会社の見積もり担当者
2. 情報システム部門の運用担当者
3. 実際に毎日この画面を触るサポート課の担当者
それぞれの立場で、「この要件のままでは判断できない」「ここが書かれていないと困る」
と感じる箇所を挙げてください。
【条件】
・指摘は立場ごとに5点以内に絞り、影響の大きい順に並べる
・それぞれ、なぜ困るのかを具体的な場面で説明する
・権限、データ移行、障害時の対応、監査ログ、既存システムとの連携の5つは
書かれているかどうかを必ず確認し、書かれていなければその旨を指摘する
最後の5項目を名指しするのは、業務部門が書く要件で抜けやすい箇所だからです。機能の話は現場から出てきますが、誰がどこまで見られるか、旧台帳の3年分をどう移すか、止まったときどうするかは、聞かれなければ誰も言いません。
指摘を反映したら、文書の形に組み立てます。ここで会話の中に長文を出させると、修正のたびに全文が出力し直されて読みにくくなります。長い文書を別画面で編集する機能を使うと、要件定義書の本体が横に残り、章ごとの修正が会話の流れに埋もれません。
ここまでの内容を、開発会社に渡す要件定義書の初稿としてまとめてください。
編集しやすいように、別画面の文書として出力してください。
【構成】
1. 背景と目的
2. 対象業務の範囲と、対象外とする範囲
3. 関係者と、それぞれの役割
4. 機能要件 … 表にする。列は 番号 / 要件 / 分類 / 検証方法 / 出どころ
5. 非機能要件 … 性能、権限、可用性、ログ、保守の観点で分ける
6. データ移行の方針
7. 制約と前提
8. 未決事項 … 私が確認して埋める箇所を一覧にする
【条件】
・私が伝えていない数値は書かず、すべて「要確認」と記す
・8章には、誰に確認すべきかも併記する
8章の未決事項一覧が、そのまま次の1週間のやることになります。
うまくいかないときの対処
もっともらしい数値が勝手に入る。 前提の「伝えていない数値を書かない」という指示が、会話が長くなると効かなくなります。文書を作らせる直前に同じ条件をもう一度書き添えてください。それでも入るなら、出力後に数字だけを拾って、自分の記録と突き合わせます。
要件が抽象的なまま返ってくる。 「具体的に」と頼むより、読み手を指定するほうが変わります。「この要件を読むのは、当社の業務を何も知らない開発会社の見積もり担当者です。その人が工数を見積もれる粒度に書き直してください」と伝えます。
会話が長くなって前半の条件が崩れる。 要件一覧そのものをファイルに書き出して保存し、新しい会話に添付してやり直すほうが早く済みます。プロジェクトに前提を置いておくと、この再開が軽くなります。
現場の言葉と食い違う要件が混ざる。 出どころの列を空欄のまま放置したときに起こります。空欄の要件は、いったんすべて保留にしてから現場に確認してください。
要件が多すぎて優先順位がつけられない。 「予算が半分になったとして、それでも入れるべき要件を10個選び、選んだ理由を書いてください」と頼むと、議論の出発点になる案が出ます。選ばれた10個をそのまま採用するのではなく、課長と見直す材料に使います。
人が確認してから先に進む
ChatGPTが出した要件定義の初稿は、社内の誰の合意も得ていない下書きです。渡す前に3つを踏みます。
現場の担当者に、機能要件の表を読んでもらいます。読むのは表だけで構いません。「この要件が実現したら、あなたの明日の仕事はどう変わりますか」と聞くと、実態と合わない項目がその場で出ます。
情報システム部門に、非機能要件とデータ移行の章を見てもらいます。既存の認証の仕組み、社内のネットワーク、保守の契約。業務部門では判断できない制約がここで出ます。
課長と、分類と未決事項を確認します。必須の線引きと予算の話は同じ場でしないと決まりません。
この3つを終えてから、開発会社に渡します。同じ作業を他のツールで進める手順は、Copilotで要件定義を整理する手順とGeminiで要件定義を整理する手順にまとめています。
まとめ
入れ替えを検討している仕組みを1つ選び、現場の誰に話を聞くかを3人まで書き出すところから始めてください。ChatGPTにプロジェクトを作って前提を置き、ヒアリング項目を出させ、戻ってきた言葉を検証できる条件に書き換え、必須と要望を分けます。数値の空欄と出どころの空欄は、自分の足で埋めます。一度作った前提文とプロンプトは保存しておくと、次の案件では組織と現状の部分を差し替えるだけで使えます。
よくある質問
要件定義を書いた経験がなくてもChatGPTで進められますか?
進められます。ChatGPTに聞くべき項目を並べさせ、それを持って現場に話を聞き、戻ってきた言葉を測れる形に書き換えてもらう流れなら、書式を知らなくても要件の骨格は作れます。ただし何を必須とするか、予算と期限をどこに置くかは人が決めます。
ChatGPTが作った要件定義書はそのまま開発会社に渡せますか?
渡せません。ChatGPTは現場の運用も既存システムの制約も見ていないため、実際には成り立たない要件や、誰も言っていない要望が混ざります。各項目の出どころを本人に確認し、情報システム部門に既存の仕組みとの整合を見てもらってから渡してください。
社内の問い合わせ内容や顧客名をChatGPTに入力してもよいですか?
自社の生成AI利用ルールに従ってください。判断がつかない場合は、顧客名や担当者名をA社、B社のような記号に置き換え、件数や項目名だけを渡せば要件の整理には足ります。入力してよい範囲は情報システム部門に先に確認するのが確実です。