多くの日本企業、特に規模の大きな日本の伝統的企業「JTC（Japanese Traditional Company）」では、デジタルや生成AIの活用に関する議論が進む一方で、実際の変革が思うように進んでいないケースが少なくありません。その原因の多くは技術そのものではなく、マインドセット、組織体制、開発プロセス、人材といった「非技術的な構造」にあります。つまり、変革を支える“人と組織の仕組み”が整っていないのです。連載「住友生命 岸和良の“JTC型DX”指南書」では、筆者が住友生命での実務経験をもとに、JTCの変革に必要な視点を解説してきました。最終回となる第10回は、生成AI時代の要件定義工程の変化をテーマに、本連載を締めくくりたいと思います。
生成AIが「システム要件定義の品質」にもたらす変化
生成AIブームの最中、自社も含めて多くの経営者と会話を交わす中で筆者が感じることは、生成AIをチャンスととらえ、既存事業の拡大や新規事業の開発など「攻めたい」と思う気持ちがある一方で、「システムを止めたくない」「サイバー攻撃から自社を守るレジリエンス力を高めたい」など、守りもしっかりやっていきたいと考えている人が多いということです。「攻め」のシステム開発が増えれば、それだけ「守り」の数も増えます。特に、“攻め”を担当する事業部門が実施する要件定義の工程は、生成AIに大きく影響を受けると筆者は考えています。
これまでの要件定義では、事業部門が業務整理を行い、担当者が文章や画面案を作成して、上長や情報システム部門が確認しながら時間をかけて整えていくプロセスが採用されていました。しかし生成AIを使うことで、専門的な知識がなくても、システム企画書の作成や画面イメージ、モックなどが短時間で作れる世の中になりました。
これは、企画の初速が上がるという点では大きなメリットです。特に、新規事業を進めたい部門にとっては、頭の中にある構想をすぐに可視化し、関係者と議論を進められるようになるため、ポジティブな変化として受け止められます。
一方で、注意すべき点もあります。それは、出力した内容の完成度が高そうに見えても、整合性が不足していたり、処理負荷やセキュリティの面で問題が潜んでいたりする可能性があるということ。こうしたリスクを提言するためにも、生成AI時代の要件定義は、どのように点検して無理や矛盾がないかを確認するかが重要になると筆者は考えます。
たとえば、ある会社の事業部門が生成AIを用いて、スマートフォンのアプリで顧客管理画面のモックを作成したケースを考えてみます。契約情報や請求情報、問い合わせ履歴を一つの画面にまとめ、「関係性を一望できる」ものとして作成しました。しかし、それを情報システム部門が確認してみると、膨大なデータ量が一度に読み込まれるため、ピークアクセス時には表示に時間がかかり、結果として利用しづらい画面になることが予想されました。加えて、アクセス制御の仕組みとも整合しづらく、運用やセキュリティ面で気をつけるべき点が多いことも見えてきました。
このように、見た目は便利でも、実運用に耐えられるかといった観点での検討が十分にできていないケースなどは容易に想像できます。
従来、要件定義の過程で行われるモック作成は作業量が多く、経験を積んだ事業部門の担当者と管理職が充分にチェックして、時間をかけて要件定義書を作り上げる必要がありました。そのため、情報システム部門はそれをサポートしながら、品質に配慮して作業ができていたのです。
しかし今では、生成AIによって事業拡大のための要件定義を誰でも簡単にできるようになりました。このような状況下では、要件定義の品質を早い段階で点検する役割が情報システム部門には求められます。生成AIが作るアウトプットを否定するのではなく、業務とシステムの双方の視点から無理がないか見極めることが重要になるのです。生成AIによってスピードが上がる時代だからこそ、初期段階での丁寧な点検がトラブル防止につながると筆者は考えています。
「攻め」が増すほど「守り」の負荷は増大……
経営層が「攻め」に舵を切ると、往々にしてシステムの開発数そのものが増加するでしょう。新しいアプリ、既存サービスの改修、他社サービスとの連携などの「攻め案件」が並行的に立ち上がることが想定されます。
しかし「守り」の視点で見れば、攻め案件の増加に比例してリスクも確実に増えます。開発・運用・統合テスト・データ連携・ログ管理・セキュリティなど、守りの観点で注意すべき点が急激に広がるためです。
たとえば、生成AIで作られた画面モックやワークフローが複数並行で走ると、システム全体で整合性を欠く設計が混ざりやすくなります。データ定義がバラバラになってしまったり、APIの利用が統一されなかったり、同じ業務を別の方式で実装したりなど、長期的な保守性に影響が出る可能性があります。
このように、生成AIによって攻めの事業が加速するほど、情報システム部門には、全体アーキテクチャの整合性を保つ役割、案件の優先順位を整理する役割、品質を早期に確認することなどといった「守りの役割」が新たに追加されます。そのため、開発スピードに合わせて守りの機能をどう強化するかが、今後の重要な経営課題になると考えられます。
「攻め」と「守り」を両立する情シスに必要な3つの要素
社内で動いている案件が増えるほど、従来の前提で設計された仕組みでは対応しきれない場面も増えていきます。こうした状況を踏まえ、情報システム部門は今後、従来の「守りの業務」に加えて、生成AI時代のスピードに対応する以下のような役割が追加されることになります。
1. 要件定義の早期点検と共通ルールづくり
生成AIで作られた要件は、構成が整っており完成度が高く見えがちです。しかし、業務上必要な前提条件が抜けていたり、既存のデータ構造と合わなかったりするケースも多く見られます。
たとえば、ある情報と別の情報を同一画面にまとめる案が生成AIから出てきたとしても、実際はデータベースが別体系になっており、単純に統合すると表示負荷が大きくなったり、アクセス権限の管理と矛盾したりする可能性もあるでしょう。
こうした問題を早い段階で把握するためには、企画段階における早期レビューが欠かせません。特に、画面項目の整理・データ定義の一致・アクセス権の妥当性といった基本的な整合性の確認は初期段階で実施する必要があります。
2. 全体アーキテクチャの一元管理
個々の案件では正しい判断をしていても、企画や要件が増えるほど全体として統一性が取りづらくなることは少なくありません。たとえば、別々の部門がAIを使って画面モックを作成すると、同じ機能を実装した似たような画面が複数生まれたり、似たデータを異なる形式で扱う設計が混ざったりすることがあります。
このような状態が続くと、将来的な改修コストが増え、システム全体の保守性にも影響します。そこで必要になるのが、アーキテクチャを一元的に管理する体制。新しい企画が既存の構造にどう影響するのか、データやAPIは統一的に扱えるのかといった“全体最適”の視点から、情報システム部門がアーキテクチャを確認し、判断することが求められます。
3. セキュリティレビューの前倒し
画面やAPIが増えるほど、サイバー攻撃者に狙われるポイントも増えていきます。特に、生成AIによる設計は意図しないデータの結合や想定外のアクセス経路が混ざる可能性もあるため、後工程でまとめて確認する方法では対処が難しくなります。
たとえば、新しい外部サービスとの連携案がAIで生成された場合、その案が一見便利なように見えても、実際には通信方式が既存のセキュリティ基準を満たしていなかったり、ログ管理が不十分だったりする可能性があるのです。そのため、情報システム部門がネットワーク構成、権限管理、外部接続の条件といったセキュリティ項目を企画段階で確認できる体制の整備が必要です。
まとめ
生成AIの普及により、要件定義はこれまでとはまったく違うプロセスになる可能性があります。システム企画書や画面モックが短時間で生成されることで初速は上がりますが、前提条件の抜けやデータ構造との不整合が生じやすくなり、品質のばらつきやセキュリティ上の懸念も生まれます。
今後は、企画段階での早期点検、画面・データ・アクセス権のルール統一、アーキテクチャの整合性の確認を前倒しする仕組みが重要になるでしょう。生成AIを前提にした要件定義の変化を理解し、スピードと品質を両立させる情報システム部門の役割がこれまで以上に重要になると考えられます。
本連載では、全10回にわたってJTCにおけるDXの実務課題を取り上げてきました。そして最終回となる本稿では、要件定義の変化に焦点を当てました。皆さまの現場に少しでも役立てば幸いです。ご読了ありがとうございました。
Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.