生成AIが要件定義の在り方を変えるとき、情シスがすべきこと──“守りの要諦”として担うべき3つの役割

生成AIが「システム要件定義の品質」にもたらす変化

　生成AIブームの最中、自社も含めて多くの経営者と会話を交わす中で筆者が感じることは、生成AIをチャンスととらえ、既存事業の拡大や新規事業の開発など「攻めたい」と思う気持ちがある一方で、「システムを止めたくない」「サイバー攻撃から自社を守るレジリエンス力を高めたい」など、守りもしっかりやっていきたいと考えている人が多いということです。「攻め」のシステム開発が増えれば、それだけ「守り」の数も増えます。特に、“攻め”を担当する事業部門が実施する要件定義の工程は、生成AIに大きく影響を受けると筆者は考えています。

　これまでの要件定義では、事業部門が業務整理を行い、担当者が文章や画面案を作成して、上長や情報システム部門が確認しながら時間をかけて整えていくプロセスが採用されていました。しかし生成AIを使うことで、専門的な知識がなくても、システム企画書の作成や画面イメージ、モックなどが短時間で作れる世の中になりました。

　これは、企画の初速が上がるという点では大きなメリットです。特に、新規事業を進めたい部門にとっては、頭の中にある構想をすぐに可視化し、関係者と議論を進められるようになるため、ポジティブな変化として受け止められます。

　一方で、注意すべき点もあります。それは、出力した内容の完成度が高そうに見えても、整合性が不足していたり、処理負荷やセキュリティの面で問題が潜んでいたりする可能性があるということ。こうしたリスクを提言するためにも、生成AI時代の要件定義は、どのように点検して無理や矛盾がないかを確認するかが重要になると筆者は考えます。

　たとえば、ある会社の事業部門が生成AIを用いて、スマートフォンのアプリで顧客管理画面のモックを作成したケースを考えてみます。契約情報や請求情報、問い合わせ履歴を一つの画面にまとめ、「関係性を一望できる」ものとして作成しました。しかし、それを情報システム部門が確認してみると、膨大なデータ量が一度に読み込まれるため、ピークアクセス時には表示に時間がかかり、結果として利用しづらい画面になることが予想されました。加えて、アクセス制御の仕組みとも整合しづらく、運用やセキュリティ面で気をつけるべき点が多いことも見えてきました。

　このように、見た目は便利でも、実運用に耐えられるかといった観点での検討が十分にできていないケースなどは容易に想像できます。

　従来、要件定義の過程で行われるモック作成は作業量が多く、経験を積んだ事業部門の担当者と管理職が充分にチェックして、時間をかけて要件定義書を作り上げる必要がありました。そのため、情報システム部門はそれをサポートしながら、品質に配慮して作業ができていたのです。

　しかし今では、生成AIによって事業拡大のための要件定義を誰でも簡単にできるようになりました。このような状況下では、要件定義の品質を早い段階で点検する役割が情報システム部門には求められます。生成AIが作るアウトプットを否定するのではなく、業務とシステムの双方の視点から無理がないか見極めることが重要になるのです。生成AIによってスピードが上がる時代だからこそ、初期段階での丁寧な点検がトラブル防止につながると筆者は考えています。

「攻め」が増すほど「守り」の負荷は増大……

　経営層が「攻め」に舵を切ると、往々にしてシステムの開発数そのものが増加するでしょう。新しいアプリ、既存サービスの改修、他社サービスとの連携などの「攻め案件」が並行的に立ち上がることが想定されます。

　しかし「守り」の視点で見れば、攻め案件の増加に比例してリスクも確実に増えます。開発・運用・統合テスト・データ連携・ログ管理・セキュリティなど、守りの観点で注意すべき点が急激に広がるためです。

　たとえば、生成AIで作られた画面モックやワークフローが複数並行で走ると、システム全体で整合性を欠く設計が混ざりやすくなります。データ定義がバラバラになってしまったり、APIの利用が統一されなかったり、同じ業務を別の方式で実装したりなど、長期的な保守性に影響が出る可能性があります。

　このように、生成AIによって攻めの事業が加速するほど、情報システム部門には、全体アーキテクチャの整合性を保つ役割、案件の優先順位を整理する役割、品質を早期に確認することなどといった「守りの役割」が新たに追加されます。そのため、開発スピードに合わせて守りの機能をどう強化するかが、今後の重要な経営課題になると考えられます。