目次

月曜の朝、基幹システムを改修した影響で、請求処理の一部が止まった。担当者が古い設計書を探し、別のチームが周辺システムへの影響を調べる。詳しい人は限られている。修正を急ぎたいのに、どこまで手を入れていいのか判断できない。

こうした場面で、AIがコードを読み、依存関係を洗い出し、修正案まで出してくれたら助かる。では、AIは長年先送りされてきたレガシーシステムの問題を、今度こそ解決できるのだろうか。

ZDNET Japanの記事が伝えるKyndrylの調査には、期待と慎重さの両方が表れている。AI、とくにエージェント型AIは刷新作業を速める可能性がある。一方、過去のモダナイゼーションが費用と時間に見合う成果を出せなかった企業も多い。さらに、元IBMの戦略担当者は、レガシーシステムの問題は「経済的に成り立たない」と指摘している。AIを導入すれば自動的に採算が合う、と考えるのは早い。

モダナイゼーションは、なぜ何度も先送りされるのか#

メインフレームをはじめとするレガシーシステムの刷新は、CIOにとって長年の課題だ。ウェブサービスやマイクロサービス、クラウド、仮想化、x86ベースのWindowsやLinuxサーバーなど、新しい技術が登場するたびに、システムを柔軟にしようという取り組みが続いてきた。

それでも、刷新はしばしば「5年先の課題」に戻ってしまう。既存システムは複雑で、長年の改修によって設計書だけでは分からない動きをしている。周辺システムとのつながりも多く、ある機能を変えたとき、どこに影響が出るかを見通しにくい。移行中も業務を止められないため、古い仕組みと新しい仕組みを並行稼働させる必要がある。

その結果、刷新は単純な「古いものを新しいものに置き換える作業」にならない。要件の確認、コードの解析、データ移行、テスト、現場への定着まで含む長いプロジェクトになる。見積もりの時点で全体像が分からず、途中で遅延や追加費用が生じることもある。

Kyndrylが上級のIT意思決定者2000人を対象に実施した調査では、モダナイゼーションに取り組む企業のうち、IT運用の改善を達成できたと答えたのは約半数だった。イノベーションの成果を感じている企業は半数に届かない。18％は、得られた価値が限定的、または不透明だと回答している。回答者の半数近くは、計画の遅れやコスト超過にも直面していた。

これだけの負担があれば、「刷新したほうがよい」と分かっていても、投資の承認を得にくい。ここで元IBM戦略担当者の「経済的に成り立たない」という指摘が重く響く。個々の企業が持つ複雑な仕組みを、すべて一律に置き換える考え方では、費用に見合う成果を出せないケースがある、という問題提起として読める。

AIが手伝えるのは、まず「分からない」を減らすこと#

今回のAIへの期待は、システム全体を一度に作り替えることではない。まずは、これまで人手に頼っていた調査や文書化を支援し、刷新の見通しを立てやすくすることにある。

Kyndrylの調査では、エージェント型AIをITモダナイゼーションのツールとして使っていると回答した技術責任者は10％にとどまった。また、新旧システム間の依存関係を完全に把握できていると自信を持つ組織も、10％未満だという。刷新対象のコードを読めても、データの流れや関連業務、別システムの呼び出しまで把握できているとは限らない。

エージェント型AIは、こうした状況で複数の作業を支援する。たとえば、隠れた依存関係を探し、コードの候補を生成し、既存の仕様や作業内容を文書にまとめる。人が一つずつ調べていた作業を短縮できれば、影響範囲の確認やテスト計画に時間を回せる。

ただし、AIが出した説明やコードを、そのまま正しいと見なすわけにはいかない。古いシステムには、文書に残っていない業務ルールや例外処理が入り込んでいることがある。AIの解析結果は、現場の担当者や既存のログ、テスト結果と照らし合わせて確認する必要がある。生成されたコードも、移行先の環境で動くか、業務要件を満たすかを検証しなければならない。

Kyndrylは、エージェント型AIを使わない組織は、早期導入企業に比べて計画より大幅に遅れる可能性があると指摘する。これはAI導入企業なら必ず成功するという意味ではない。AIを使うかどうかだけでなく、対象を絞り、人が結果を確かめ、プロジェクトの成果を測れるかが問われる。

「置き換える」前に、採算を小さく確かめる#

AIを刷新プロジェクトに加えるなら、最初から全社規模の計画を立てるより、範囲を限った検証から始めたい。採算が見えないという指摘を、導入の賛否だけで片付けず、どの作業なら費用に見合うかを実測する。

進め方の例は次のとおりだ。

  • 対象を一つ選ぶ。障害対応に時間がかかる処理や、変更のたびに影響調査が必要なプログラムなど、困りごとがはっきりした範囲に絞る。
  • 作業の現状を記録する。依存関係の調査、設計書の作成、テスト準備に何人日かかるか、現在の所要時間と手戻りを残す。
  • AIには、まず解析や文書化をさせる。実行環境の変更や本番コードの書き換えは後回しにし、担当者が結果を確認できる形で使う。
  • 数週間から数カ月の試行で、作業時間、指摘の正確さ、手戻り、追加費用を比べる。利用料だけでなく、AIの結果を確認する人の工数も含めて計算する。

大切なのは、コードの生成量ではなく、業務上の改善を測ることだ。調査にかかる時間が減っても、確認作業が増えたり、テストで不具合が見つかったりすれば、全体のコストは下がらない。反対に、特定の作業で調査時間や手戻りが減り、担当者がその結果を再現できるなら、次の対象に広げる根拠になる。

判断基準も先に決めておこう。たとえば「依存関係の確認にかかる時間をどれだけ短縮するか」「AIが見落とした重要な処理はいくつか」「試行に必要な人件費を含めても費用対効果があるか」を記録する。数字の目標はシステムや組織によって異なるので、外部の成功談をそのまま当てはめるのではなく、自社の現状を基準に置く。

未来のレガシーも、いずれ点検が必要になる#

いま新しく作るシステムも、運用が続けば将来のレガシーになる。AIを使ってコードを速く書けても、なぜその処理が必要なのか、どの業務が依存しているのかを残さなければ、数年後の担当者が同じ調査に苦労する。AIを刷新の道具として使うなら、生成したコードだけでなく、判断の根拠や変更履歴も管理したい。

また、刷新の目的は古い技術を消すことだけではない。Kyndrylの報告書によれば、企業がモダナイゼーションに取り組む動機は、コスト削減やレガシーからの脱却に限らなくなっている。AIによってIT需要が高まるなか、新旧が混在する環境をどう機能させるかも課題になっている。ソブリン（主権）に関する懸念も、技術の選択に影響する。

だからこそ、何を残し、どこを変え、どの業務から着手するかを決める作業は人に残る。AIはコードや依存関係を調べる負担を減らせるかもしれないが、投資の価値や許容できるリスクまで自動で判断するわけではない。

「AIを入れればレガシー問題は解決する」と決めつけず、まず一つの業務で現状の工数と費用を測ってみよう。AIに任せる範囲と人が確認する範囲を決め、試行後に得られた数字を見て、次の刷新対象へ進むか判断してほしい。

出典: https://japan.zdnet.com/article/35253404/

目次