AIが要件を書けるようになったら、要件定義はどう変わるのだろう

AIに、

「このシステムの要件を整理して」

と頼む。

すると、

機能要件。

非機能要件。

利用者。

業務フロー。

例外ケース。

前提条件。

制約。

かなりそれらしい形で、

要件のたたき台を作ってくれます。

以前なら、

会議をしながら少しずつ整理していた内容を、

短い時間で文章にできる。

これは大きな変化だと思います。

そこで気になります。

AIが要件を書けるようになったら、要件定義は簡単になるのでしょうか。

私は、

文書を作ることはかなり簡単になる。

でも、

要件定義そのものは、

むしろ別の難しさが目立つようになるのではないかと思っています。

「書くこと」と「決めること」は違う

要件定義というと、

要件定義書を書く作業を思い浮かべることがあります。

何を作るのか。

誰が使うのか。

どんな機能が必要なのか。

どんな制約があるのか。

それを文章にする。

AIは、

この部分をかなり助けてくれるでしょう。

でも、

文章を書けることと、

内容が決まっていることは、

同じではありません。

たとえば、

「管理者はユーザー情報を編集できる」

という要件を書けたとしても、

誰が管理者なのか。

どこまで編集できるのか。

変更履歴は必要なのか。

本人の同意は必要なのか。

削除はできるのか。

そこまで決まっていなければ、

本当の意味では要件になっていません。

AIは文章を作れても、

決まっていないことまで決めてくれるわけではない

ということです。

曖昧でも、それらしい文章は作れてしまう

ここは、

AI時代の要件定義で少し怖いところだと思います。

AIは、

曖昧な情報からでも、

かなり整った文章を作れます。

見出しがある。

項目が並んでいる。

専門用語も入っている。

読むと、

「ちゃんと決まっている」

ように見える。

でも実際には、

関係者の認識が揃っていない。

例外時の扱いが決まっていない。

責任の所在が曖昧。

運用方法も未定。

ということがあります。

つまり、

文章の完成度と、要件の完成度がずれる

可能性があります。

AIがきれいに書いてくれるほど、

この違いに気づきにくくなるかもしれません。

要件定義は「聞いたことを書く」だけではない

利用者に、

「何が必要ですか」

と聞く。

それを要件として書く。

一見すると分かりやすいですが、

実際の要件定義は、

もう少し複雑です。

利用者が言っていること。

本当に困っていること。

今の業務。

例外時の対応。

システム化しなくてもよいこと。

他部署への影響。

将来変わりそうなこと。

そうしたものを見ながら、

「本当に必要なのは何か」

を整理します。

利用者が、

「この画面が欲しい」

と言ったとしても、

必要なのは画面ではなく、

ある情報を早く確認できることかもしれません。

つまり、

要望と要件は同じではありません。

ここは、

AIが文章を書けても、

人が考える必要が残る部分です。

AIは、質問を作るのがかなり得意になる

一方で、

AIは要件定義そのものにも、

かなり役立つと思います。

特に、

質問を作ることです。

たとえば、

予約システムを作るとして、

「どんな点を確認すべきか」

と聞けば、

予約可能時間。

キャンセル。

重複予約。

権限。

通知。

変更履歴。

例外処理。

かなり多くの観点を出してくれます。

人だけで考えると、

見落としていた問いが出てくることもあります。

そうなると、

AIの役割は、

要件を書き上げることより、

「まだ決まっていないこと」を見つけること

の方が重要になるかもしれません。

良い要件定義は、良い質問から始まる

これからは、

要件を書く能力よりも、

どんな質問をするかが重要になる気がします。

誰が使うのか。

いつ使うのか。

失敗したときはどうするのか。

今はどう対応しているのか。

この作業は本当に必要なのか。

誰が責任を持つのか。

何を保存するのか。

どこまで自動化するのか。

何は人が判断するのか。

AIに、

「この要件を書いて」

と頼むだけではなく、

「この要件で、まだ決まっていないことは何か」

と聞く。

こうした使い方の方が、

要件定義には向いているように思います。

要件が増えすぎる問題も出てくる

AIは、

考えられる機能をたくさん出せます。

必要そうな要件。

便利そうな機能。

考慮すべきケース。

どんどん追加できます。

でも、

すべてを要件にする必要はありません。

ここは、

前に考えた、

「何を作らないか」

という話にもつながります。

AIが、

「あれも必要です」

「これも考慮できます」

と候補を増やすほど、

人は、

今、本当に必要なのか。

初期リリースに必要なのか。

後でよいのか。

そもそも不要なのか。

を決めなければなりません。

要件定義は、

要求を集める仕事だけではなく、

要求を減らす仕事

にもなっていくと思います。

要件定義書は、完成品ではなくなるかもしれない

これまで、

要件定義の成果物として、

要件定義書を作ることがありました。

何十ページ。

場合によっては、

何百ページ。

それをレビューして、

承認する。

AIが文書作成を支援するようになると、

こうした資料は、

かなり速く作れるようになります。

でも、

だからこそ、

「文書を完成させること」がゴールではなくなるかもしれません。

重要なのは、

関係者が理解しているか。

認識が一致しているか。

決まっていないことが見えているか。

変更したときに追跡できるか。

つまり、

要件定義書という成果物より、要件を合意し続ける仕組み

の方が重要になる可能性があります。

変更に強い要件定義へ

システム開発では、

最初に決めたことが、

最後まで一度も変わらないとは限りません。

実際に画面を見ると、

違うと思う。

利用者に触ってもらうと、

別の要望が出る。

制度が変わる。

優先順位が変わる。

AIによって開発が速くなれば、

こうした変更も早く起こるようになるかもしれません。

そのとき、

最初の要件定義書を絶対視するより、

なぜこの要件になったのか。

いつ変わったのか。

何に影響するのか。

誰が決めたのか。

を追えることが重要になります。

要件定義も、

一度決めて終わりではなく、

開発と一緒に更新されるもの

へ変わっていくのかもしれません。

AIが書いた要件を、そのまま信じない

AIが出した要件は、

とてもそれらしく見えることがあります。

だからこそ、

確認が必要です。

本当にこの業務に合っているか。

存在しないルールを作っていないか。

抜けている関係者はいないか。

セキュリティ上問題はないか。

法律や契約と矛盾していないか。

実際の運用で使えるか。

AIは、

一般的には正しそうな要件を出せます。

でも、

その会社。

その利用者。

その現場。

そのシステム。

そこに本当に合っているかは、

別の問題です。

要件定義は、人と人の認識を合わせる仕事になる

AIが要件を書けるようになったら、

要件定義担当者はいらなくなる。

そう考えることもできます。

でも私は、

少し逆に見ています。

文章を書く時間が減る。

整理する時間も減る。

その分、

利用者と話す。

認識の違いを見つける。

決めていないことを表に出す。

選択肢を示す。

何を作らないか決める。

合意を取る。

そうしたところに、

時間を使えるようになる。

つまり、

要件定義は、

「文書を書く仕事」から「認識を合わせる仕事」へ

さらに重心を移していくのかもしれません。

AIが要件を書くほど、人は「問い」を持つ

AIが、

機能要件を書いてくれる。

非機能要件も整理してくれる。

要件定義書も作ってくれる。

それ自体は、

かなり便利になると思います。

でも、

要件定義の本当に難しいところは、

文章を書くことではありません。

何が問題なのか。

誰の問題なのか。

何を変えるのか。

何は変えないのか。

どこまで作るのか。

何を諦めるのか。

そして、

それを関係者が本当に同じ意味で理解しているのか。

そこです。

AIが答えを書けるようになるほど、

人に求められるのは、

答えを書くことではなく、

「まだ何を聞かなければならないのか」を見つけること

なのかもしれません。

AIが要件を書ける時代に、

要件定義はなくならない。

むしろ、

文章の向こう側にあった本当の仕事が、

以前より見えやすくなる。

そんな変化が起きるように思います。

この記事を最後まで読んでいただき、ありがとうございます。
「♡」（スキ）を押していただけるとうれしいです。これからの記事づくりの励みになります。
もし気に入っていただけましたら、フォローもよろしくお願いします。