要件定義に生成AIをどう使うか。任せてよい作業と、任せない判断

要件定義の現場で、生成AIを使う人が増えています。会議の録音から議事録の下書きを作る。分厚い既存の資料を要約する。次の打ち合わせで聞くことを洗い出す。どれも、これまで夜に時間をかけてやっていた作業です。

一方で、使い方を間違えると、要件定義そのものが崩れます。AIが整えた議事録に、実際には決まっていないことが「決定事項」として書かれている。要約からこぼれた一文が、後で大きな手戻りの原因になる。どれも、道具のせいというより、任せる範囲を決めていなかったことが原因です。

この記事では、要件定義に参画するコンサルやPMO、上流のSEの立場から、生成AIに任せてよい作業と、人が持ち続けるべき判断を分けて考えます。特定の製品の使い方ではなく、どの道具でも通じる考え方として書きます。

要件定義で生成AIが役に立つ場面

要件定義の仕事を細かく分けると、情報を集める、整理する、論点にする、合意を取る、文書に残す、という流れになります。このうち、生成AIが得意なのは、集めた情報を整理する部分と、文書の形に整える部分です。

たとえば、ヒアリングで聞いた話を箇条書きのメモにしておき、それを業務の流れの順に並べ替えてもらう。部署ごとに出てきた要望を、似たもの同士でまとめてもらう。こうした作業は、人がやると時間がかかるうえに、疲れていると漏れが出ます。AIに一度並べさせてから、人が見直すほうが速く、抜けにも気づきやすくなります。

用語の整理にも向いています。要件定義の初期には、同じものを部署ごとに違う名前で呼んでいることがよくあります。営業部の「受注」と経理部の「受注」が、実は違うタイミングを指している、という具合です。ヒアリングのメモから用語を抜き出し、使われ方の違いを一覧にしてもらうと、確認すべき言葉が見えてきます。最終的な定義は関係者と決めますが、たたき台を作る手間はかなり減ります。

逆に、苦手なのは、その場の空気や、発言の裏にある事情を読むことです。会議で部長が「それは検討します」と言ったとき、それが前向きな意味なのか、やんわり断っているのかは、文字だけでは分かりません。要件定義では、こうした見えない情報が判断を左右します。

ここから、使い方の基本が見えてきます。AIには、材料を並べる、形を整える、抜けを指摘する、という作業を任せる。何を材料として渡すか、出てきたものをどう読むかは人が決める。以下では、具体的な作業ごとにこの線引きを見ていきます。

議事録の下書きは、決まったことと決まっていないことを分けさせる

議事録の下書きは、もっとも取り入れやすい使い方です。録音の文字起こしやメモを渡し、議題ごとに要点をまとめてもらう。これだけで、会議後の作業時間はかなり減ります。

ただ、そのまま使うと危ない点があります。AIは、話の流れを読みやすく整えようとします。その結果、議論の途中で出た案が、結論のように書かれることがあります。「A案で進める方向で一致した」と書かれていても、実際には「A案がよさそうだが、営業部に確認してから」という話だったかもしれません。

そこで、下書きを頼むときは、出力の形を先に決めておきます。

• 決定事項。誰が、何を決めたのかが分かる形で書く
• 未決事項。何が決まっておらず、誰がいつまでに何をするのか
• 確認事項。会議の場で答えが出ず、持ち帰りになったもの
• 発言の記録。結論に至らなかった意見も残す

このように枠を決めて頼むと、AIが無理に結論をまとめることが減ります。そのうえで、決定事項の欄は必ず人が一行ずつ確認します。とくに、主語が抜けている決定事項は要注意です。誰が決めたのかが書けない項目は、本当は決まっていない可能性が高いからです。

文字起こしをもとにする場合は、発言者の取り違えにも気をつけます。オンライン会議で一つのマイクを複数人で使っていると、誰の発言かが正しく記録されないことがあります。「情シスの課長が了承した」と書かれていても、実際に話したのは業務部門の担当者だった、ということが起こります。発言者が判断に関わる箇所は、自分のメモと照らし合わせて確かめます。

議事録は、要件定義の中で合意の証拠になる文書です。下書きをAIに任せても、配る前に責任を持って読むのは人の仕事です。配った議事録に誤りがあると、後から訂正するのは、最初に書くよりずっと大変です。

論点の洗い出しと質問リストに使う

次の打ち合わせの準備にも、生成AIは役に立ちます。たとえば、これまでのヒアリングのメモと、現行業務の流れを渡して、「この業務で、まだ決まっていない点を挙げてください」と頼む。あるいは、「この業務の担当者に確認すべき質問を、例外処理を中心に挙げてください」と頼む。

人が一人で考えると、どうしても自分の経験の範囲で考えます。過去に似た業務を担当したことがあれば深く聞けますが、初めての業務だと、どこに落とし穴があるかが分かりません。AIに広く挙げさせると、自分では思いつかなかった観点が混ざることがあります。返品のときの扱い、月をまたぐ処理、担当者が不在のときの代行、といった例外の話は、とくに抜けやすいところです。

ただし、出てきた質問をそのまま客先に持って行くのは避けます。AIが挙げる質問は、一般論としては正しくても、その会社の事情に合っていないことがあります。すでに前回の会議で答えが出ている質問も混ざります。「それは先週お話ししましたよね」と言われると、相手の信頼を失います。

使い方としては、AIに出させた候補を、人が三つに分けるのがおすすめです。すでに答えが分かっているもの、聞く必要がないもの、次の会議で聞くもの。最後の群だけを、相手の言葉づかいに合わせて言い直してから質問リストにします。この手間をかけることで、質問の質が上がり、会議の時間も短くなります。

頼み方にも工夫の余地があります。「質問を挙げてください」とだけ頼むと、一般的な質問が並びます。相手の役職、その人が担当している業務の範囲、前回までに確認したことを先に伝えると、出てくる候補がぐっと具体的になります。また、「この質問への答えによって、何が決まるか」を一緒に書かせると、聞く意味の薄い質問を外しやすくなります。

資料の要約は「何が書かれていないか」まで見る

上流の案件に途中から参画すると、過去の資料が大量に渡されます。構想段階の企画書、現行システムの設計書、過去の会議の議事録。すべてを丁寧に読む時間はないことが多く、要約に頼りたくなります。

要約は、全体の地図をつかむには便利です。どんな資料があり、それぞれに何が書かれているのかを短時間で把握できます。参画して最初の数日で、資料の全体像をつかむために使うのはよい使い方です。

注意したいのは、要約は「書かれていること」を短くしたものだという点です。要件定義で本当に効いてくるのは、書かれていないことのほうです。たとえば、企画書に「業務の効率化」と書かれていても、何をどれだけ効率化するのかが書かれていない。設計書に例外の処理が書かれていない。こうした抜けは、要約するとさらに見えにくくなります。

そこで、要約を頼むときに、あわせて「この資料で、決まっていない点や、根拠が示されていない点を挙げてください」と頼みます。そのうえで、判断に関わる部分、つまり数字、条件、例外、責任の所在が書かれた箇所は、必ず原文に戻って読みます。要約は読む順番を決めるための道具であって、原文を読まずにすませるための道具ではありません。

合意、優先順位、責任は人が持つ

ここまでの作業は、どれも人の判断を助けるためのものです。要件定義には、AIに渡してはいけない判断があります。大きく分けると、合意、優先順位、責任の三つです。

合意は、関係者が同じ理解に立ったことを確かめる行為です。AIが論点を整理し、選択肢を並べることはできます。しかし、どの選択肢で合意するかは、関係者が話し合って決めることです。会議の前にAIに結論案を作らせ、それを「整理した結果です」と出すと、相手は議論の余地がないと感じるかもしれません。案を出すなら、人が考えた案として、理由と一緒に出します。

優先順位も同じです。要望を並べて、効果と工数の観点で整理することはAIにもできます。しかし、実際の優先順位は、予算、スケジュール、社内の力関係、経営層の関心など、資料に書かれていない事情で決まります。それを知っているのは、現場に入っている人です。AIの出した順位を、そのまま提案に使うことは避けたほうがよいでしょう。

そして責任です。要件定義書に書かれたことは、後の設計、開発、テストのすべての土台になります。そこに誤りがあれば、誰かがその責任を負います。AIが書いた一文であっても、それを文書に載せた時点で、載せた人の責任になります。「AIがそう出したので」は、客先にとって説明になりません。

たとえば、要件定義書のレビューで、客先の担当者から「この非機能要件の数字はどこから来たのですか」と聞かれた場面を考えます。根拠となる会議や資料を示せれば、話はそこで終わります。AIが一般的な値として出したものをそのまま載せていた場合、答えに詰まり、文書全体の信頼が揺らぎます。数字や条件を載せるときは、根拠を自分の言葉で説明できるかを、載せる前に確かめておきます。

こう考えると、AIをうまく使える人ほど、自分の判断に自信を持って説明できる人だと言えます。AIに任せる作業が増えるほど、人が持つ判断の重みは増していきます。

客先の情報を入れる前に確かめること

要件定義で扱う情報は、多くが客先の機密です。業務の流れ、組織の課題、取引先の名前、システムの構成。これらを生成AIに入れてよいかどうかは、使う人が自分で決めてよい問題ではありません。

業務委託で参画している場合はとくに、客先のルールと、自分が契約している会社のルールの両方を確かめる必要があります。確かめたいのは次の点です。

1. 使ってよいツールが決められているか。客先が契約している環境に限られるか
2. 入力してよい情報の範囲。個人情報や取引先の情報はどう扱うか
3. 入力した内容が学習に使われない設定になっているか
4. 生成AIを使って作った成果物について、その旨を伝える必要があるか

ルールが明文化されていない客先もあります。その場合でも、自分の判断で使い始めるのではなく、窓口の担当者に一度聞いておきます。「議事録の下書きに生成AIを使いたいのですが、社内でルールはありますか」と聞くだけで十分です。聞いたことと、返ってきた答えはメールで残しておきます。

情報を入れてよいと分かった場合でも、入れる量は必要な範囲にとどめます。会議の文字起こしをそのまま入れる前に、個人名や取引先名を役割の名前に置き換えるだけでも、万一のときの影響は小さくなります。手間は少し増えますが、客先の信頼を守るための作業だと考えてください。

明日の会議から試すなら

生成AIの使い方は、一度にすべてを変える必要はありません。まずは一つの作業から始め、自分の中で任せる範囲を決めていくのが確かな方法です。

最初に試すなら、議事録の下書きがよいでしょう。決定事項、未決事項、確認事項、発言の記録という枠を決めて下書きを作らせ、決定事項の欄だけは自分で一行ずつ確かめる。これを数回続けると、AIがどこで話をまとめすぎるのか、どんな会議だと誤りが出やすいのかが分かってきます。

その前に、客先と自分の契約先のルールを確かめることを忘れないでください。ルールの確認がすんでいれば、次の会議の議事録から、枠を決めた下書きを一度試してみてください。