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

「攻め」と「守り」を両立する情シスに必要な3つの要素

　社内で動いている案件が増えるほど、従来の前提で設計された仕組みでは対応しきれない場面も増えていきます。こうした状況を踏まえ、情報システム部門は今後、従来の「守りの業務」に加えて、生成AI時代のスピードに対応する以下のような役割が追加されることになります。

1. 要件定義の早期点検と共通ルールづくり

　生成AIで作られた要件は、構成が整っており完成度が高く見えがちです。しかし、業務上必要な前提条件が抜けていたり、既存のデータ構造と合わなかったりするケースも多く見られます。

　たとえば、ある情報と別の情報を同一画面にまとめる案が生成AIから出てきたとしても、実際はデータベースが別体系になっており、単純に統合すると表示負荷が大きくなったり、アクセス権限の管理と矛盾したりする可能性もあるでしょう。

　こうした問題を早い段階で把握するためには、企画段階における早期レビューが欠かせません。特に、画面項目の整理・データ定義の一致・アクセス権の妥当性といった基本的な整合性の確認は初期段階で実施する必要があります。

2. 全体アーキテクチャの一元管理

　個々の案件では正しい判断をしていても、企画や要件が増えるほど全体として統一性が取りづらくなることは少なくありません。たとえば、別々の部門がAIを使って画面モックを作成すると、同じ機能を実装した似たような画面が複数生まれたり、似たデータを異なる形式で扱う設計が混ざったりすることがあります。

　このような状態が続くと、将来的な改修コストが増え、システム全体の保守性にも影響します。そこで必要になるのが、アーキテクチャを一元的に管理する体制。新しい企画が既存の構造にどう影響するのか、データやAPIは統一的に扱えるのかといった“全体最適”の視点から、情報システム部門がアーキテクチャを確認し、判断することが求められます。

3. セキュリティレビューの前倒し

　画面やAPIが増えるほど、サイバー攻撃者に狙われるポイントも増えていきます。特に、生成AIによる設計は意図しないデータの結合や想定外のアクセス経路が混ざる可能性もあるため、後工程でまとめて確認する方法では対処が難しくなります。

　たとえば、新しい外部サービスとの連携案がAIで生成された場合、その案が一見便利なように見えても、実際には通信方式が既存のセキュリティ基準を満たしていなかったり、ログ管理が不十分だったりする可能性があるのです。そのため、情報システム部門がネットワーク構成、権限管理、外部接続の条件といったセキュリティ項目を企画段階で確認できる体制の整備が必要です。

まとめ

　生成AIの普及により、要件定義はこれまでとはまったく違うプロセスになる可能性があります。システム企画書や画面モックが短時間で生成されることで初速は上がりますが、前提条件の抜けやデータ構造との不整合が生じやすくなり、品質のばらつきやセキュリティ上の懸念も生まれます。

　今後は、企画段階での早期点検、画面・データ・アクセス権のルール統一、アーキテクチャの整合性の確認を前倒しする仕組みが重要になるでしょう。生成AIを前提にした要件定義の変化を理解し、スピードと品質を両立させる情報システム部門の役割がこれまで以上に重要になると考えられます。

　本連載では、全10回にわたってJTCにおけるDXの実務課題を取り上げてきました。そして最終回となる本稿では、要件定義の変化に焦点を当てました。皆さまの現場に少しでも役立てば幸いです。ご読了ありがとうございました。