AIと作る要件定義のたたき台｜下書きを短期間で、人が仕上げる

結論：要件定義書は白紙から書かず、AIでたたき台を作って人が仕上げる

要件定義書を白紙から書き起こそうとすると、手が止まりがちです。何を書けばいいか、どの粒度で書けばいいかが決まらず、最初の1行が出てこないからです。そこで、たたき台をAIに作らせて、その下書きを人が削って直す、という順番に変えます。ゼロを1にするのはAIが得意で、1を10に仕上げるのは人がやる、という分担です。

この記事では、AIとの対話で要件定義書のドラフトを短期間で組み立てる段取りを、コピペで使えるプロンプト付きで紹介します。あわせて、AIに任せてよい部分と、人が決めるしかない部分の線引きも示します。ここを曖昧にすると、もっともらしいだけで中身の薄い要件定義書になりやすいので、そこが肝心です。

なぜ、たたき台をAIに作らせるのか

たたき台の価値は、完成度ではなく「叩く対象ができること」にあります。白紙を前に「要件を出してください」と言われても意見は出にくいものですが、粗くても項目が並んだ資料があれば、「この機能は要らない」「ここが抜けている」と反応が出てきます。議論は、否定できる対象があるほど進みやすくなります。

AIは、一般的な業務システムの要件定義書がどんな構成になるかを知っています。だから「受注管理システムの要件定義書の章立てを作って」と頼めば、機能要件・非機能要件・データ・画面・移行・運用といった枠を、それらしく並べてくれます。この枠組みを出発点にすれば、あとは自社の事情に合わせて埋めたり削ったりしていけます。白紙の壁を越えるための道具として使うわけです。

ドラフトを組み立てる段取り

当社では、次の順で進めます。いきなり全文を書かせず、枠組み→穴あき本文→穴埋め、と段階を踏むのがコツです。

1. 材料を集める（既存の画面・帳票・業務メモ・As-Is/To-Beの業務フローなど）
2. AIに章立て（目次）だけを作らせる
3. 章ごとに、材料を渡して本文を書かせる
4. AIが埋められなかった箇所を「要確認」として洗い出させる
5. 「要確認」を人が埋め、AIの推測部分を削る

最初のプロンプトは、完成文ではなく章立てを求める形にします。

これから「受注管理システム」の要件定義書を作ります。
まず、要件定義書の目次（章立て）だけを提案してください。

- 中小企業の業務システム更改を想定する
- 機能要件・非機能要件・データ・画面・帳票・移行・運用の
  観点が漏れないようにする
- 各章に、そこで決めるべきことを1〜2行で添える
- まだ本文は書かない

章立てが固まったら、章を1つずつ進めます。ここで材料を渡すのが重要です。手元の画面や帳票の情報を添えると、AIの推測が減り、自社に即した本文になります。画面情報の集め方はスクショ×AIで設計ガイドを作る手順が使えます。

「機能要件」の章の本文を書いてください。次の材料だけを
根拠にし、材料にないことは推測で書かないでください。
書けない部分は本文に混ぜず、章末に「要確認」として
箇条書きにしてください。

【材料】
- 受注入力画面の項目一覧（別途貼り付け）
- 現在Excelでやっている与信チェックの手順メモ
- 「月末に締めて請求書を一括発行している」という運用

当社の進め方では、材料がそろっている業務なら1日程度でドラフトの形にできることもあります。ただし「形になる」と「使える」は別です。仕上げは人の仕事として残ります。

AIが書ける部分と、人が決める部分

要件定義には、事実を整理すれば書ける部分と、判断や交渉が要る部分が混ざっています。前者はAIに任せ、後者は人が引き取る。この線引きをはっきりさせておくと、AIの下書きに振り回されずに済みます。

特に「例外業務をどう扱うか」は、AIに任せきりにはできません。「特定の取引先だけ締め日が違う」「担当者が手作業で例外的に処理している」といった仕様は、残すか、この機会にやめるかを人が決める必要があります。ここはコストと現場の納得の両方が絡むので、機械的には割り切れません。線引きの考え方はAIに質問させて業務フローを整理する方法でも触れています。

Access移行での使いどころ

Accessで作り込まれた業務システムを移行するとき、要件定義でつまずくのは「今のAccessが何をしているか」を言語化する部分です。長年の改修でテーブルやVBAが積み重なり、当時の担当者もいない、というご相談も少なくありません。

こういう場合は、まず既存資産の棚卸しを進め、そこで分かった事実をAIに渡してドラフトの材料にします。テーブル構成や帳票の一覧、画面の項目——こうした「今あるもの」の情報を、Access移行前の業務フロー調査のやり方で集めておくと、AIの下書きが空想ではなく実態に沿ったものになります。図が要るところは業務フロー図の作成ツールと組み合わせると、文章と図の両面で要件を固められます。

ただし、できあがったドラフトを見積の根拠にする前に、必ず人のレビューを挟んでください。AIが「たぶんこうだろう」で埋めた部分が残っていると、移行の途中で「そんな仕様は聞いていない」という食い違いが起きるおそれがあります。何をチェックすべきかはAIが作った設計資料をそのまま信じてはいけないにまとめました。

使うときの注意

たたき台づくりは速くて便利ですが、いくつか気をつける点があります。

• AIは材料にない部分を推測で埋めることがある。プロンプトで指示しても完全には防げないので、「要確認」に切り分けさせ、推測を本文に残さない
• 取引先名・単価・個人情報などの機密は、渡す前に伏せる。使うAIの入力データの扱いは各社の公式ポリシーで確認する
• できたドラフトは「下書き」と割り切る。そのまま契約や見積の根拠にしない

当社では、こうしたAIによる一次整理と、人による確認を組み合わせて、移行相談用の要件のたたき台づくりを支援しています。何から手をつければいいか分からない段階でも、無料の解析可否チェックから相談できます。

よくある質問

Q. 本当に1日で要件定義書ができますか。

「ドラフト（下書き）」を1日程度で形にすることを目安にした表現です。材料がそろっていれば章立てと本文の骨格はその日のうちに組めることもありますが、優先順位づけや例外業務の判断、関係者の合意まで含めた「完成」には、それ以上の時間がかかります。あくまで着手を速くする方法だと考えてください。

Q. 専門知識がなくても要件定義書を作れますか。

たたき台までは作れます。ただし、出てきた項目が自社に必要かの取捨選択や、費用対効果の判断には、業務とシステム両方の知識が要ります。たたき台を土台に、詳しい人や外部の支援を入れて仕上げる、という使い方が現実的です。

Q. AIが書いた要件を、そのままベンダーに渡していいですか。

渡す前に、必ず自分たちで中身を確認してください。AIの下書きには、実在しない仕様や、逆に自社の重要な例外が抜けていることがあります。確認せずに渡すと、その誤りを前提に見積もられてしまい、あとで手戻りにつながりかねません。

Q. どの章から書き始めるのがいいですか。

「今の業務で何をしているか（機能要件とデータ）」から始めるのがおすすめです。ここは事実の整理なのでAIと進めやすく、土台になります。非機能要件（性能・セキュリティなど）や移行・運用は、業務の全体像が見えてからのほうが決めやすくなります。