AIで要求定義書は作れる？自社の業務と課題を整理するために必要なこと

生成AIへ自社の業務や課題を伝えると、改善案だけでなく、要求定義書のような資料まで作成できるようになりました。

「受注業務を効率化したい」

「Excelで管理している情報を一元化したい」

「同じ内容を何度も入力する作業をなくしたい」

このような相談をすると、AIは必要な機能を整理し、業務フローや画面構成、使用するサービス、開発手順まで提案してくれます。

これだけ具体的な回答が返ってくると、

「システム会社に依頼しなくても、自社で要求定義ができるのではないか」

「生成AIに相談しながら、自分たちでシステムまで作れるのではないか」

と感じるのも自然なことです。

実際、AIを使えば、これまで専門家へ依頼しなければ作成できなかった資料の下書きを、自社で作れるようになっています。

しかし、AIが要求定義書らしい文章を作ったことと、自社の業務を正しく分析できたことは同じではありません。

要求定義では、何を決めるのか

要求定義では、システムの細かな機能や画面配置を決める前に、会社として何を実現したいのかを整理します。

例えば、次のような内容です。

• どの業務に問題があるのか
• なぜ、その問題を解決する必要があるのか
• 誰がシステムを利用するのか
• どの作業を改善したいのか
• どの情報を管理したいのか
• 何ができれば、改善したと判断できるのか
• どこまでを今回の対象とするのか
• 予算や期限にどのような制約があるのか
• 現在の業務のうち、何を残し、何を変えるのか

要求定義は、「どのようなシステムを作るか」だけを決めるものではありません。

その前に、「何のためにシステムを作るのか」「会社として何を実現したいのか」を明確にするものです。

ここが曖昧なまま画面や機能を作り始めると、完成したシステムが本来の課題を解決できない可能性があります。

AIが答えを作るためには、業務の情報が必要

AIは、入力された情報を基に回答します。

例えば、

Excelで受注管理をしています。
入力作業に時間がかかるため、システム化したいです。

と伝えれば、AIは次のような機能を提案するかもしれません。

• 受注入力画面
• 顧客マスタ
• 商品マスタ
• 売上一覧
• 納期管理
• CSV出力
• 自動集計
• メール通知

一見すると、必要な機能がきれいに整理されています。

しかし、実際の受注業務には、入力画面と一覧表だけでは表現できない作業が存在します。

• 注文はメール、FAX、電話、Webサイトから届く
• 顧客によって注文書の形式が異なる
• 商品名や商品コードの表記が統一されていない
• 担当者が内容を確認し、入力前に修正している
• 在庫がない場合だけ、別の担当者へ確認している
• 得意先ごとに価格や納期の決め方が異なる
• 急ぎの場合は通常とは違う手順で処理する
• 受注後に数量や納期が変更される
• 一部の商品だけ、社長や責任者の承認が必要になる
• システムへ入力した後、別のExcelや帳票にも転記している

こうした情報をAIへ伝えていなければ、AIは存在しない業務として要求定義書を作ります。

AIの提案が間違っているというより、提案の前提となる情報が不足しているのです。

ITコンサルタントが確認する情報

要求定義を行うとき、ITコンサルタントは「どのような機能が欲しいですか」と聞くだけではありません。

業務がどこから始まり、どのような情報や判断を経て、どこへ渡されるのかを確認します。

1．改善したい目的

最初に確認するのは、ツールや機能ではなく、改善の目的です。

• 作業時間を減らしたい
• 入力ミスを防ぎたい
• 二重入力をなくしたい
• 担当者以外でも対応できるようにしたい
• 情報を一元管理したい
• 処理状況を見えるようにしたい
• 集計結果を経営判断へ使いたい
• 引き継ぎしやすい状態にしたい
• 顧客への回答を早くしたい

同じ「Excelをシステム化したい」という相談でも、目的によって必要な仕組みは変わります。

2．現在の業務の流れ

現在の業務を、開始から終了まで確認します。

• 何をきっかけに業務が始まるのか
• 最初に情報を受け取る人は誰か
• どの情報を、どこから入手するのか
• 誰が内容を確認するのか
• 途中でどのような判断が行われるのか
• 次の担当者へ、どのように情報を渡すのか
• 最後に何を出力し、どこへ保存するのか
• 処理が完了したことを、誰が確認するのか

説明だけでなく、可能であれば実際に使用しているExcel、紙の帳票、メール、入力画面、CSV、集計資料なども確認します。

担当者の説明と実際の作業が異なることは、珍しくありません。

3．管理するデータ

システムでは、画面よりも先に、どのデータをどのように管理するかを考える必要があります。

• 顧客、商品、担当者など、基準となる情報は何か
• 同じ情報を複数の場所で管理していないか
• 一件の案件に、複数の商品や明細があるか
• データを識別する番号は何か
• 誰が、いつ、どの情報を登録するのか
• 登録後に内容が変更されることはあるか
• 変更前の情報を残す必要があるか
• 他のシステムへ連携する情報は何か
• 過去のデータを移行する必要があるか
• データを何年間保存するのか

見た目の分かりやすい画面を作れても、データの持ち方が適切でなければ、後から集計や変更ができなくなります。

4．通常業務と例外業務

業務には、必ず例外があります。

「通常はこの手順ですが、この顧客だけ違います」

「急ぎの場合は、担当者へ直接連絡します」

「月末だけ処理方法が変わります」

「一部の商品だけ、別の承認が必要です」

すべての例外をシステムへ組み込むと、複雑で使いにくくなります。

一方、例外を無視して標準業務だけを作ると、現場はシステムの外でExcelや手書きのメモを使い始めます。

そのため、例外を次のように分けて考えます。

• 今後も必要な例外
• 標準業務へ統一できるもの
• システムで管理するもの
• 人が判断するもの
• 一時的な運用として残すもの
• 現在の担当者しか知らないもの

例外を見つけるだけでなく、それを仕組みに含めるかどうかを判断する必要があります。

5．利用する環境

技術的に作れるかどうかだけでなく、実際の利用環境で動かせるかを確認します。

• 利用するパソコンやスマートフォン
• Windows、Macなどの端末環境
• 社内ネットワークやインターネット環境
• 利用しているMicrosoft 365やGoogle Workspaceの契約
• Excelがデスクトップ版かWeb版か
• ファイルの保存場所
• 複数人が同時に利用するか
• 社外や自宅からアクセスするか
• 他のシステムと連携するか
• 社内に管理者となる人がいるか
• 導入後の利用料金を負担できるか

AIが提案した機能や自動化方法が、現在の契約や端末では利用できないこともあります。

6．権限とセキュリティ

業務システムには、利用者ごとの権限が必要です。

• 誰がデータを閲覧できるのか
• 誰が登録、変更、削除できるのか
• 管理者権限を誰に与えるのか
• 個人情報や機密情報を扱うのか
• 社外からのアクセスを認めるのか
• 操作履歴を残す必要があるか
• 退職者や異動者のアカウントをどう管理するのか
• 外部サービスへどの情報を送信するのか

生成AIへ業務情報を入力する場合は、入力してよい情報の範囲も考えなければなりません。

顧客名、個人情報、契約内容、価格情報、社外秘の資料などを、そのまま外部のAIサービスへ入力してよいとは限りません。

7．障害、バックアップ、復旧

通常どおり動いているときだけでなく、使えなくなったときの対応も必要です。

• データをどのようにバックアップするのか
• 誤って削除したデータを復元できるのか
• システムが停止したとき、業務をどう継続するのか
• 誰が障害へ対応するのか
• サービス提供会社が停止した場合、データを取り出せるのか
• 担当者が不在でも運用できるのか
• 自動処理が失敗したことを、どのように検知するのか

「動くものを作る」だけであれば、AIを使って短期間で実現できる場合があります。

しかし、「業務で安心して使い続けられるもの」にするには、障害や復旧まで考える必要があります。

モックアップから抜け出せない理由

AIへシステム開発を依頼すると、最初にモックアップや試作画面が作られることがあります。

入力フォームや一覧画面が表示され、ボタンを押すと画面が切り替われば、「もうすぐ完成する」と感じるかもしれません。

しかし、モックアップは、システムの見た目や操作の流れを確認するためのものです。

本当に業務で使用するには、その後に多くの検討と実装が必要です。

• データをどこへ保存するのか
• 複数のデータをどう関連付けるのか
• 同時に操作された場合、どう処理するのか
• 入力内容の誤りをどう防ぐのか
• 途中で処理が失敗した場合、どう戻すのか
• データが重複して登録されないか
• 誰がどの情報を変更できるのか
• 外部システムとの連携に失敗した場合、どうするのか
• 過去データをどのように移行するのか
• 本番環境へどのように公開するのか
• 公開後の修正や保守を誰が行うのか

画面が表示されることと、業務システムとして完成していることの間には、大きな距離があります。

生成AIとのやり取りだけで作ろうとすると、問題が発生するたびに部分的な修正を繰り返すことがあります。

一つの問題を直した結果、別の機能が動かなくなることもあります。

システム全体の構成やデータの関係を理解していなければ、AIから提示された修正方法が適切かどうかを判断できません。

そのため、「まずはモックアップを作る」ところまでは進めても、業務で使える状態まで完成させられないことがあります。

「自動化ツール」と「業務システム」の境目

生成AIの普及により、「専門知識がなくても自動化ツールを作れた」という事例を目にすることが増えました。

実際、決まった形式のファイルを変換する、特定の文章を作成する、一つの表を集計するなど、範囲が限定された作業であれば、AIを使って便利なツールを作れることがあります。

これは大きな変化です。

これまで手作業で行っていた業務を、自分で改善できる機会が広がっています。

しかし、単純な自動化ツールと、複数人が継続して使用する業務システムは同じではありません。

例えば、次のような条件が増えると、単純なツールではなく、業務システムとしての設計が必要になります。

• 複数人が同時に利用する
• 複数の部署や取引先が関係する
• 顧客情報や個人情報を扱う
• データを長期間保存する
• 登録後に承認や変更が発生する
• 他のシステムとデータを連携する
• 利用者によって操作できる範囲が異なる
• 処理結果が売上や請求へ影響する
• 操作履歴を残す必要がある
• システムが停止すると業務も止まる
• 担当者が変わっても利用を継続する

自分だけが使う一時的なツールであれば、自分で問題を理解し、手作業で修正できるかもしれません。

しかし、会社の業務として複数人が使うのであれば、「作った本人だけが分かる」状態では運用できません。

どこからがシステムなのかは、使用する技術だけでは決まりません。

業務への影響、利用者の数、扱う情報、継続性、障害時の影響などによって変わります。

AIが作った要求定義書は、事実とは限らない

AIは、情報が不足していても、それらしい要求定義書を作成できます。

これは便利な反面、注意が必要な点です。

AIが作成した資料の中には、次のような内容が混ざる可能性があります。

• 実際には聞いていない業務
• 存在しない承認手順
• 利用できないシステム連携
• 現場では必要のない機能
• 契約や環境上、使用できないサービス
• 会社として決めていない運用方針
• 担当者一人の意見を、全社の要求として扱った内容
• 一般的な業務を、自社でも行っていると推測した内容

要求定義書の文章が整っていると、内容まで正しいように見えます。

しかし、AIが作った文章は、決定事項ではありません。

事実として確認できている内容、仮説、提案、未確認事項を分ける必要があります。

AIで要求定義を行うときの進め方

AIを要求定義に活用するのであれば、最初から完成した要求定義書を書かせるのではなく、段階的に進める方がよいでしょう。

1．現在の業務を事実として書き出す

理想の状態や改善案を考える前に、現在の業務を整理します。

誰が、いつ、何を見て、何を判断し、どこへ入力し、次の担当者へ何を渡しているのかを書き出します。

この段階では、「こうした方がよい」という改善案を混ぜないようにします。

2．困っていることを具体的にする

「非効率」「使いにくい」といった言葉だけでなく、何にどれくらい困っているのかを整理します。

• 一件の入力に何分かかるのか
• 一日に何件処理するのか
• どのようなミスが何件起きているのか
• どこで作業が止まるのか
• 誰に確認が集中しているのか
• 修正や手戻りにどれくらい時間がかかるのか

数値を確認できない場合でも、発生する場面や影響を具体的にします。

3．通常処理と例外処理を伝える

AIへ標準的な流れだけを伝えるのではなく、例外も入力します。

ただし、すべてをそのままシステム化するのではなく、今後も必要なのか、統一できないのかを検討します。

4．制約条件を伝える

利用環境、予算、期限、契約、担当者のITスキル、既存システム、セキュリティルールなどを伝えます。

制約を伝えなければ、AIは技術的には可能でも、実際には採用できない方法を提案することがあります。

5．AIに不足情報を質問させる

すぐに解決策を作らせるのではなく、要求定義に必要な情報をAIから質問させます。

例えば、

この業務を要求定義するために、不足している情報を質問してください。
確認できている事実と、推測を分けてください。
一度に結論を出さず、業務、データ、利用環境、例外、権限、セキュリティ、バックアップの順に確認してください。

と依頼します。

AIの質問へ回答することで、自分たちが把握できていない業務や、関係者間で認識が異なる事項に気づくことがあります。

6．事実、要求、提案を分ける

AIが整理した内容を、少なくとも次のように分類します。

• 現在の業務として確認できた事実
• 現在発生している課題
• 会社として実現したい要求
• AIが提案した改善方法
• まだ確認できていない事項
• 関係者による判断が必要な事項

AIが提案した内容を、そのまま会社の要求へ含めないことが大切です。

7．関係者が確認する

要求定義は、AIとの会話だけで完成させるものではありません。

経営者、業務責任者、現場担当者、システム管理者など、立場の異なる人が内容を確認する必要があります。

経営者には見えていない現場の作業があります。

反対に、現場担当者には見えていない会社全体の方針や費用の制約もあります。

一人の説明だけで作成した要求定義書を全社の要求として扱うと、導入後に認識の違いが表面化します。

AIは要求定義を支援できる

AIは、要求定義に使えないわけではありません。

正しく活用すれば、次のような作業を支援できます。

• ヒアリング項目の作成
• 現在の業務フローの整理
• 課題、原因、影響の分類
• 不足している情報の洗い出し
• 通常処理と例外処理の整理
• 利用者ごとの要求の分類
• 複数の改善方法の比較
• 要求定義書の構成作成
• 関係者へ確認する事項の一覧化
• 要求の優先順位を考えるための材料作成

これまで資料作成に使っていた時間を短縮し、その分を業務の確認や関係者との話し合いに使えるようになります。

ただし、AIは、自社で実際に行われている業務を見ているわけではありません。

業務の説明に不足があれば、不足した情報を基に回答します。

関係者の認識が異なっていても、どちらが正しいのかを自動的に判断できるわけではありません。

要求定義書を作ることが目的ではない

要求定義の目的は、きれいな資料を完成させることではありません。

会社として解決したい課題を明確にし、関係者の認識を合わせ、実現可能な方法を検討できる状態にすることです。

AIを使えば、要求定義書らしい文章は作れます。

モックアップや簡単な自動化ツールも、以前より短時間で作れるようになりました。

しかし、業務で継続して使えるシステムにするには、環境、データの流れ、例外処理、権限、セキュリティ、バックアップ、障害対応、保守まで考える必要があります。

これらをすべて自社だけで考えることが難しい場合は、AIを使って作成した資料を、システム会社やITコンサルタントへ相談するためのたたき台にする方法もあります。

「何も分からないので、すべて任せます」と依頼するよりも、自社の業務、課題、目的、制約が整理されていれば、相談の質は高くなります。

AIによって、自社の業務を自分たちで整理できる範囲は広がりました。

一方で、AIが作った提案を、実際に使える仕組みへ変えるには、業務分析とシステム開発の知識が必要です。

AIに要求定義書を書かせることよりも、その前に、自社の業務をどこまで具体的に伝えられるか。

そして、AIが作った内容のうち、何が事実で、何が提案で、何が未確認なのかを判断できるか。

そこが、AIで要求定義を行うときの重要なポイントです。