※本記事は、AWS re:Invent 2024のセッション「Modernize mainframe applications faster using Amazon Q Developer (DOP221-NEW)」の内容を基に作成されています。セッションの詳細情報は https://www.youtube.com/watch?v=pSi0XtYfY4o でご覧いただけます。本記事では、セッションの内容を要約・構造化しております。なお、本記事の内容は発表内容を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルのセッション動画をご視聴いただくことをお勧めいたします。また、AWSの公式イベント情報（ https://go.aws/3kss9CP ）やAWS公式チャンネル（ http://bit.ly/2O3zS75 ）もご参照ください。

登壇者紹介：

• Elio Damaggio氏：Amazon Q Developerの変換機能における製品責任者。AIを活用したメインフレームモダナイゼーションの製品戦略を主導。
• Alexis Henry氏：Amazon Q Developerのメインフレームモダナイゼーション部門のシニアソフトウェアマネージャー。15年以上のメインフレーム専門家としての経験を持つ。
• Dave Tsai氏：トヨタ自動車北米のエンジニアリング・エンタープライズAI部門のバイスプレジデント。組織全体のAI活用戦略を指揮し、メインフレームモダナイゼーションプロジェクトを推進。

1. メインフレームモダナイゼーションの課題

1.1 アプリケーションの規模と複雑性

Elio Damaggio： メインフレームアプリケーションは極めて大規模で複雑です。これらは何十年にもわたる技術と機能の進化の結果であり、その複雑さを管理することは組織にとって困難な課題となっています。

私たちの分析によると、比較的小規模な300万行のコードを持つアプリケーションであっても、その複雑性は驚くべきものです。このアプリケーションの接続数は米国の電力網の3倍にも及び、構成要素の数は航空機の6倍以上、情報量は1000冊以上の本に相当します。

しかし、これはまだ小規模な例に過ぎません。医療、金融、自動車などの業界では、メインフレームアプリケーションは容易に1億行規模のコードに達します。このような大規模なアプリケーションになると、接続数は米国の電力網の100倍、構成部品は航空機の200倍以上、情報量は30,000冊以上の本に相当する規模となります。

このような膨大な情報量と規模は、システムのモダナイゼーションを担当するチームに大きな負担をかけています。彼らは分析、計画、承認の取得、そしてモダナイゼーションプロジェクトの実行という複雑な作業を行う必要があり、その規模と複雑さは従来の手法では対応が困難になっています。

これらの課題は、各企業のモダナイゼーションプロジェクトの進行を著しく妨げており、効率的な解決策が求められています。アプリケーションの規模が大きくなるほど、その複雑性は指数関数的に増加し、従来の手法での対応が困難になっているのが現状です。

1.2 複数年にわたるプロジェクト期間の問題

Elio Damaggio： メインフレームモダナイゼーションプロジェクトは、複数の要因により多年にわたる長期プロジェクトとなることが一般的です。最も大きな問題の一つは、これらのメインフレームアプリケーションに関する適切なドキュメントが存在しないことです。

また、プロジェクトの各個別タスクが非常に労働集約的な性質を持っています。これは主にこれらのアプリケーションで使用されている特殊な技術に起因しています。さらに、これらのシステムはビジネスにとって極めて重要なシステムであるため、その変更には細心の注意を払う必要があります。

実際のプロジェクトでは、このような状況によりプロセス全体に遅延が生じています。メインフレームアプリケーションがビジネスの重要なシステムを支えているため、その修正や変更には最大限の注意を払う必要があり、これがプロジェクト期間の長期化の一因となっています。

各タスクにおける労働集約的な性質と、ビジネスクリティカルなシステムであることによる慎重な対応の必要性は、相互に影響し合い、プロジェクト期間の長期化をさらに助長しています。これらの課題に対する効果的な解決策がなければ、メインフレームモダナイゼーションプロジェクトは今後も長期化の傾向が続くことが予想されます。

1.3 技術的な課題

Elio Damaggio： メインフレームアプリケーションが直面している技術的な課題の中で、最も重要なのはアプリケーションのモノリシックな性質です。様々な機能が一つのシステムに混在しており、それぞれの機能が密接に絡み合っている状態にあります。

コードの構造自体にも大きな課題があります。機能が互いに入り組んで同じコード上に共存している状態で、これらの機能を理解し、切り分け、より現代的なコーディング方法に変換することは非常に困難です。特に、コードが順次的な方法で記述されているため、その理解と整理が複雑になっています。

さらに、組織的な課題も存在します。メインフレームを管理する組織は、技術の進化に伴って通常サイロ化された状態で運営されています。このサイロ化により、部門間の協力が限定的になり、システム全体の理解や改善が困難になっています。

これらの技術的な課題は相互に関連し合い、モダナイゼーションの複雑さを増大させています。モノリシックな構造、機能の混在、順次的なコーディングスタイル、そして組織のサイロ化が組み合わさって、システムの理解と改善を一層困難にしているのです。これらの課題に効果的に対処するためには、技術面だけでなく、組織的なアプローチも含めた包括的な解決策が必要となっています。

1.4 専門知識の不足

Elio Damaggio： 専門知識の不足は、メインフレームモダナイゼーションにおける重要な課題の一つです。特に深刻なのは、メインフレームの専門家が次々と職場を去っていることです。彼らはメインフレームシステムに関する豊富な知識と、COBOL、PL/Iといったメインフレーム特有の言語に関する専門知識を持ち去っていきます。

これらの専門家の減少は、単なる人材の問題以上の影響を及ぼしています。メインフレームシステムとそのプログラミング言語に関する深い理解を持つ人材が不足することで、既存システムの保守や改善が困難になっているのです。さらに、これらの課題は、クラウドアーキテクチャに関する知識の不足とも相まって、より複雑な状況を生み出しています。

多くの組織では、モダナイゼーションの目標としているクラウドアーキテクチャに関する知識も限られています。メインフレームの専門家はメインフレームについては深い知識を持っていても、最新のクラウド技術については必ずしも精通していないという現実があります。この知識のギャップは、モダナイゼーションプロジェクトの成功を妨げる大きな要因となっています。

これらの専門知識の不足は、メインフレームシステムの保守とモダナイゼーションの両方に影響を与える深刻な問題となっており、早急な対応が求められています。

2. Amazon Q Developerの概要

2.1 主要な機能と特徴

Elio Damaggio： 昨日、私たちはAmazon Q Developerのメインフレームモダナイゼーション機能を発表しました。これは大規模なメインフレームアプリケーションのモダナイゼーションのための初めての生成AI システムです。特筆すべきは、数億行規模のコードを処理できる能力を持っていることです。

Q Developerは、モダナイゼーションプロセスの多くのフェーズと活動をサポートし、ガイドすることができます。主な機能として、まずコードベースの分析と依存関係の発見があります。これにより、複雑に絡み合ったコードの関係性を理解することが可能になります。

次に、既存のメインフレーム資産に対するドキュメント生成機能を提供します。これは特に、長年にわたって蓄積された知識を文書化する上で重要な役割を果たします。

さらに、コードと데이터の依存関係を考慮しながら、モノリスを機能ドメインに分解する能力を持っています。これにより、巨大な一枚岩のようなシステムを、より管理しやすい単位に分割することが可能になります。

最後に、移行プロセスの優先順位付けとシーケンス化を行いながら、移行計画を立案する機能があります。これにより、モダナイゼーションの各段階を適切に管理し、効率的に進めることができます。

そして重要なのは、これらの機能がクラウドレディなJavaへのメインフレームコードのリファクタリングまでカバーしているということです。このように、分析から実装まで、モダナイゼーションの全工程をサポートする包括的なソリューションとなっています。

2.2 AIエージェントの自律的な動作

Elio Damaggio： Q Developerは、チーム内の複数の役割を持つエキスパートが協力してメインフレームモダナイゼーションプロジェクトに取り組める統一されたWeb体験を提供します。ユーザーは特定の目標を持つ変換ジョブを開始でき、AIエージェントがそれらの目標を自律的に達成しようと動作します。

これらのゴールは、単にドキュメントを生成したい、分解したい、計画を立てたいといった具体的なタスクから、特定の機能ドメインについて分析からドキュメント作成、計画立案、リファクタリングまでを含む完全なPOCの作成まで、さまざまなレベルに対応できます。

AIエージェントは目標達成のために自律的に動作しますが、中間成果物の承認が必要な場合や、自律的に実行できないタスクに遭遇した場合には人間に連絡を取ります。これは、チームとAIの間の信頼関係を確立する上で非常に重要な特徴です。

Qは最新の基盤となる生成AIモデルを活用していますが、それだけではありません。ニューラルネットワークや自動推論、メインフレーム特有のコード分析ツールなど、メインフレーム専用のAIツールも組み合わせて利用しています。これにより、メインフレーム特有の課題に対して、より適切な対応が可能となっています。

2.3 パターンに依存しない柔軟性

Elio Damaggio： Q Developerの重要な特徴の一つは、そのパターンに依存しない柔軟性です。これらのフェーズと機能は、メインフレームをリファクタリングパターンで近代化する場合だけでなく、他のパターンを選択した場合でも活用できます。

例えば、再構築（reimagine）、再プラットフォーム化（re-platform）、拡張（augment）、置換（replace）といったパターンを選択した場合でも、Qの機能を活用することができます。これらの分析や機能は、お客様が選択する移行パターンに関係なく、モダナイゼーションプロジェクト全体を支援することができます。

このパターンに依存しない柔軟性により、お客様は自身のビジネスニーズや技術要件に最適な移行戦略を選択することができ、それぞれのパターンに応じてQの機能を適切に活用することが可能です。これは、様々な状況や要件に対して柔軟に対応できることを意味し、より多くのお客様のニーズに応えることができます。

3. トヨタ自動車北米での導入事例

3.1 既存のメインフレーム環境の課題

Dave Tsai： トヨタ北米におけるメインフレームは、私たちのビジネスにとって非常に長期にわたって重要な役割を果たしてきました。このシステムは45年以上にわたって運用され続けており、当社のビジネスの重要な部分を支えています。

特に、私たちのメインフレームはサプライチェーンの基幹システムとして機能しており、多くの業務が基本的なバッチジョブとして実行されています。このような状況は、ビジネスの俊敏性と拡張性の面で大きな課題となっています。これらの変更には非常に長い時間がかかり、ビジネスのスピードに追いつくことが困難になってきていました。

また、システムの高齢化に伴う課題も深刻です。多くのシステムは、おそらく在席している皆様よりも古く、私自身よりも古いものもあります。ドキュメントの不足も大きな問題となっています。これは組織を去った高齢の従業員が持ち去った知識が適切に文書化されていないことに起因します。

さらに、COBOL技術やメインフレーム技術に精通した人材の全般的な不足も深刻な課題となっています。これらの課題は、システムの維持管理とモダナイゼーションの両面で、私たちの取り組みを困難にしています。

3.2 過去の失敗からの学び

Dave Tsai： AWSとの今回のパートナーシップは、私たちにとって実はメインフレームモダナイゼーションの初めての試みではありません。私たちは以前にも複数回、メインフレームのモダナイゼーションを試みてきました。

特に重要な経験として、別のハイパースケーラーパートナーとの取り組みがありました。私は正直に申し上げますが、その試みは失敗に終わりました。この失敗は、私が現在のAmazon Q Developerに特に期待している理由の一つでもあります。

これらの過去の試行と失敗は、私たちに重要な教訓を与えてきました。過去の取り組みでの課題を踏まえ、私たちは昨年、Alexisと生成AIによってこれらの問題に取り組むという新しい可能性について議論を始めました。当時のソリューションはまだ初期段階でしたが、パートナーシップと改良を重ねることで、現在では強力なツールへと進化しています。

これらの経験は、メインフレームモダナイゼーションの複雑さと、適切なツールおよびアプローチの重要性を私たちに教えてくれました。過去の失敗を糧に、より効果的なアプローチを見出すことができたと考えています。

3.3 Amazon Q Developerの活用成果

Dave Tsai： Amazon Q Developerを活用することで、私たちは何年もの間埋もれていたレガシーコードに対する説明可能なドキュメントの生成に成功しました。当初は生のソリューションでしたが、パートナーシップと改良を重ねることで、COBOLコード、RPG、さらにはJCLジョブまでを分析できる強力なコード分析ツールへと進化させることができました。

特に革新的だったのは、複数のペルソナに対応したドキュメント生成機能です。私たちには、ビジネスアナリストとエンジニアの両方がドキュメントを読む必要がありました。ビジネスアナリスト向けのドキュメントは、数十年にわたってコードに埋もれていたロジックを分かりやすく説明することができ、今日のエンジニアリングのニーズを理解できる形で提示することができました。

また、エンジニアリングのドキュメントとユースケースを使用して、コードが実際に何を行っているのかを詳細に説明することもできました。これらのドキュメントは対話的に検証することも可能です。

サプライチェーンシステム内で100以上のドキュメントを処理し、それらはビジネスアナリストや、そのコードをモダナイズする将来のエンジニアによって検証されました。全てのドキュメントは非常に高い精度と品質で検証されており、実用的な価値を提供しています。

3.4 ビジネス価値の創出

Dave Tsai： 私たちがAmazon Q Developerを活用することで得られた利点は、先ほど述べた技術的な成果以上に広がっています。最も重要な成果の一つは、コードそのものと、その例外処理を含むビジネスの運営に不可欠な機能について、明確な理解が得られたことです。

運用効率の面でも大きな改善が見られました。コードの構造がより良く理解できるようになり、バッチジョブからリアルタイムシステムへの変換など、必要な変更をどのように行うべきかの理解が深まりました。これにより、システムの運用効率が大幅に向上しています。

また、ビジネスニーズとの整合性も強化されました。特に、ビジネスペルソナベースのドキュメントとエンジニアリングドキュメントを組み合わせることで、より良い説明が可能になりました。これにより、技術的な詳細とビジネス要件の間のギャップを埋めることができました。

最後に、長年の課題であった知識ギャップの解消にも成功しています。これは私たちのメインフレームシステムの次世代への移行を加速する上で、特に重要な成果となっています。サプライチェーンの次世代システムへの変革に多額の投資を行っている中で、このような知識の橋渡しができることは、私たちの移行の旅を確実に加速させ、より良い方向へと導いています。

4. Amazon Q Developerの詳細機能

4.1 ドキュメント生成機能

Alexis Henry： メインフレームアプリケーションは他のアプリケーションとは異なる特徴を持っています。これらは何十年もの間存続しており、通常、私たち開発者の2、3世代にわたってシステムが維持されてきました。そのため、初期設計に関わった人々は既に不在であり、通常はごくわずかなドキュメントしか残されていません。また、システム内には当初想定していた以上のビジネスルールが埋め込まれていることも多いのです。

このような状況に対応するため、ドキュメント生成エージェントはソースコードから直接ドキュメントを生成します。また、プログラム間の依存関係グラフも分析し、包括的なドキュメントを作成します。

現在、私たちは2種類のドキュメントレベルを提供しています。アーキテクトがアプリケーション全体を理解するための高レベルのドキュメントと、主題専門家向けの詳細なドキュメントです。高レベルのドキュメントはアプリケーションの全体像を把握するために使用され、詳細なドキュメントはコードの構造、ビジネスルール、データ操作などの深い理解を可能にします。

さらに重要な特徴として、モダナイゼーション中にコードが変更された場合でも、ドキュメントを随時更新できる機能があります。これは一般的なケースで、モダナイゼーション中もコードは進化し続けるからです。必要に応じてドキュメントを常に最新の状態に保つことができ、これによってプロジェクト全体を通じて正確な情報を維持することが可能です。

4.2 コード分析と分解機能

Alexis Henry： メインフレームアプリケーションのモダナイゼーションにおいて、私たちは実際にはコードの移行ではなく、ビジネスの移行を行っているのです。そのため、モノリスをビジネスドメインに分割する能力は非常に重要です。メインフレームアプリケーションは100万行から10億行のコードを含む可能性があり、私は数十億行のコードを持つ顧客も見てきました。

このような規模のアプリケーションに対応するため、私たちは新しいタイプのモデルを開発しました。このモデルは、モノリスをビジネスドメインに分解する際に、技術的なモジュール性ではなく、アプリケーションのセマンティクスとロジック構造を結び付けます。

この機能は例示による学習で動作します。例えば、特定のKICKトランザクションがカード管理ドメインの一部である、あるいは特定のバッチが与信管理の一部であるといった例を提供することで、Qはモノリスの構造を分析し、ビジネスラインに分解することができます。また、KICKの定義ファイルやJCLのスケジューリングから自動的にこれらのシードを識別することも可能です。

重要な特徴として、Qはビジネスドメインと共通コンポーネントを区別します。共通コンポーネントは、全てのビジネスドメイン間の接続を形成する部分です。マイクロサービス化を行う際、これらの共通コンポーネントはライブラリとして昇格され、ビルド時に組み込まれます。これにより、実行時の依存関係を排除し、より効率的なシステム構造を実現しています。

4.3 移行計画の最適化

Alexis Henry： メインフレームアプリケーションのモダナイゼーションでは、お客様の組織が「移行を実行できるか」「移行戦略を持てるか」「どこから始めるべきか」といった質問に非常に神経質になります。特に「そのビジネスドメインから始めて良いのか？」「依存関係の影響は？」「優先順位はどうすべきか？」といった疑問を持ちます。例えば、倉庫管理から始めて、その後に販売最適化を行いたいという具体的な要望があります。

これらの質問は一見シンプルに見えますが、メインフレームアプリケーションが複雑で大規模で、多くの相互依存関係を持つため、実際には非常に複雑な問題となります。そこで、Qはコードを自動的に分析し、異なるオプションを検討できるようにしています。これにより、チームや経営陣に対して、移行の進め方を具体的に提示することが可能になります。

ビジネスルールをコードから取り出し、20〜30のビジネスドメインで構成されるビジネスマップを作成することで、非常に複雑なシステムと数百万の依存関係から、より明確な構造を得ることができます。この単純化により、最適な移行戦略を自動的に生成することが可能になります。

ただし、Qが提案する最適化された戦略が、お客様の優先順位と一致しない場合もあります。そのため、Qではお客様が優先順位を定義できるようになっています。特定のドメインを最初に、最後に、あるいは途中に配置したり、複数のドメインをグループ化したりすることができます。Qは2秒以内に、お客様の制約とドメイン間の依存関係の現実とのバランスを取りながら、新しい計画を作成します。

これらの計画は、Qが実際に実行できるものであることが重要です。Qはアドバイスを提供するだけでなく、提案した移行計画を実際に実行することができます。これにより、理論的な計画ではなく、実践的で実行可能な移行戦略を提供することができます。

4.4 コード変換の自動化

Alexis Henry： Q Developerの処理速度は、従来のモダナイゼーションプロジェクトと比較して劇的に速くなっています。移行シーケンスは数秒で完了し、分解は数分以内に実行され、アクションプランの定義は10-20秒程度で完了します。特筆すべきは、コード生成速度で、約10分で100万行のコードを生成することができます。

このスピードにより、1日のうちに5〜6種類の異なる移行戦略を検討し、即座に結果を確認することができます。生成されたコードを確認し、実際の効果を評価することも可能です。

マイクロサービス分解に関して、ビジネスドメインごとに独立したアプリケーションとして生成することができます。各ドメインは、指定された方法でパッケージ化され、デプロイされます。分解フェーズで定義された情報は、コード生成ポートで直接活用されます。

共通コンポーネントについては、特別な扱いをしています。これらは実行時の依存関係を持つべきではないため、ライブラリとして昇格され、ビルド時に組み込まれます。これにより、より効率的なシステム構造を実現しています。デプロイメント戦略も考慮され、各コンポーネントは適切に管理され、展開されます。

これらの自動化された機能により、モダナイゼーションプロジェクトの実行速度が大幅に向上し、より確実な移行が可能になっています。特に重要なのは、これらの変換がすべて確実に実行可能であることが保証されている点です。Qが提案する戦略は、すべて実際に実行可能なものとなっています。

5. 実践的なデモンストレーション

5.1 マルチテナント会話の開始

Alexis Henry： デモンストレーションでは、まずマルチテナント会話からスタートします。私はメインフレーム移行への関心を示し、Q Developerに対してメインフレームモダナイゼーションの機能について質問を投げかけます。Qはその機能について自己認識しており, 自身の持つ機能について包括的に説明してくれます。

より具体的な情報が必要な場合は、特定の機能について詳しく尋ねることができます。例えば、コードとドキュメントについてより詳しく知りたい場合、Qは組織の知識を保持する能力や、2つのレベルのドキュメント（要約と詳細）の生成機能、そして具体的にどのような作業ができるかを説明してくれます。

また、必要に応じてQに対してより簡潔な回答を求めることもできます。この対話式のアプローチにより、各機能の構造や利用方法について、より深い理解を得ることができます。例えば、ドキュメントの生成について質問すると、各プログラムのドキュメントに含まれる章立て（ビジネスコンテキスト、ドメイン機能、データフロー、I/O操作、エラー管理など）まで詳しく説明してくれます。

このようなカスタマイズ可能なアプローチは、コード分解、移行計画、その他のドメインエージェントについても同様に適用できます。各サブエージェントは専用の知識ページを持っており、その使用方法と得られるメリットについて、対話を通じて理解を深めることができます。

5.2 コード分析とドキュメント生成

Alexis Henry： デモンストレーションの次のステップとして、私はコード分析とドキュメント生成のプロセスを実演します。まず、Qはコードの場所が必要です。メインフレームの場合、通常はお客様のアカウント内のS3バケットを選択します。これは、お客様の非常にセンシティブなコードのコピーを私たちが保持しないようにするためです。

一度コードの場所が提供されると、Qは最初のコード分析を実行します。この分析結果は、その後のドキュメント生成のベースとなります。このデモでは、特定のファイルに対するドキュメント生成を実演し、Qは数秒でこのプロセスを完了します。

ドキュメントの生成プロセスでは、各章の構成が明確に示されます。ビジネスコンテキスト、ドメインの機能と特徴、データフロー、I/O操作、エラー管理など、プログラムの各側面が体系的にドキュメント化されます。この構造化されたアプローチにより、生成されたドキュメントは技術者だけでなく、ビジネス部門の方々にも理解しやすいものとなっています。

これらの結果は、リアルタイムで確認することができ、必要に応じて追加の分析やドキュメント生成を要求することも可能です。この反復的なプロセスにより、必要な情報を段階的に集めていくことができます。

5.3 ビジネスドメインの分解

Alexis Henry： コード分解のデモンストレーションでは、私はまずユーザーとしてQに対してビジネスドメインの例を提供します。この例では、特定のCOBOLファイルを選択し、それらが属するビジネスドメインを指定します。デモでは3つのCOBOLファイルを選択し、それらが特定のビジネスドメインに属することを示すだけで十分です。

しかし、このシード情報の提供は手動で行う必要はありません。Qは、KICKの定義ファイルやJOBスケジューリングファイルから自動的にシード情報を識別することも可能です。このアプローチにより、システムは自動的にビジネスドメインの候補を特定できます。

結果は視覚的に表示され、多くのプログラム間の接続を持つ元のアプリケーションから、最終的なビジネスドメインの分解結果を確認することができます。例えば、アカウント管理、請求、トランザクション、メニュー、カード管理などの明確なドメインが識別され、さらに共通コンポーネントも特定されます。ここでQは、ビジネスドメインと全てのビジネスドメイン間の接続を形成する共通コンポーネントを区別する重要な特徴を持っています。この視覚化により、複雑なシステムの構造をより理解しやすい形で把握することが可能になります。

5.4 移行計画の作成と最適化

Alexis Henry： 分解が完了すると、デフォルトでQはプロジェクト全体の計画を自動的に生成します。しかし、ユーザーとしてこのデフォルト計画に同意できない場合があります。例えば、管理モジュールを最初のドメインとして設定する必要がないと判断した場合、私たちはそれを最後に移動させることができます。

その代わりに、管理モジュールは機能的なドメインでテストを開始したいという要望を指定することができます。ユーザーは任意の移行における優先順位を変更でき、Qはリアルタイムでその計画を更新します。Qは同じ移行ウェーブ内でドメインをグループ化することもあります。これは移行を容易にするためです。

例えば、このデモンストレーションでは、Qは共通コンポーネント、データクロスリファレンス、データローディング、ファイル管理から始めることを提案しました。これは、このアプリケーションが主にバッチアプリケーションであり、多くのデータローディングとクロスリファレンスを含むためです。これらはアプリケーション内のフレームワークとして機能しているため、Qはこれらを最初のボートに含めることを選択しました。

その後、管理、請求、メニューと続く計画を提案しています。これはあくまで提案であり、Qが完璧な計画を生成する保証はありません。通常、Qはビジネスドメイン間の依存関係を考慮しながら、ユーザーの制約の90〜95%を満たす方法を見つけ出します。もしユーザーの制約が依存関係と競合する場合、Qは移行が成功するように移行計画を適応させます。メインフレームからAWSクラウドに移行する際に、依存関係が欠落したものをデプロイすることは避けなければならないからです。

5.5 コード生成の実行

Alexis Henry： 移行計画が完了すると、Qはコード生成を開始します。私たちのデモンストレーションでは、選択した一部のドメインのみを生成対象としたため、Qはそれらのドメインに特化したコードを生成します。これにより、特定のビジネス領域に焦点を当てた変換プロセスを確認することができます。

コード生成プロセスの進捗は、リアルタイムでモニタリングすることができます。Qは、生成の各段階で進捗状況を明確に表示し、処理の透明性を確保します。

最終的に、Qは全ての専門エージェントの動作結果をダッシュボードに表示します。このダッシュボードには、コードの変換状況、生成された成果物の概要、そして品質メトリクスなどが含まれます。これにより、変換プロセス全体の成果を包括的に把握することができます。

このデモでは示していませんが、同じジョブを再実行して新しい入力を提供することも可能です。例えば、分解を変更したい場合や、コードドキュメントを追加して分析したい場合などです。その場合、Qは必要なサブエージェントのみを起動し、以前の結果と新しい結果を統合します。このような柔軟性により、反復的な改善と最適化が可能になります。

6. 期待される効果と今後の展望

6.1 評価フェーズの短縮

Alexis Henry： 私たちのソリューションによって実現される最も重要な効果の一つは、プロジェクトの評価フェーズの劇的な短縮です。従来、1年以上かかっていた評価フェーズを、わずか数週間に短縮することが可能になりました。

これを実現する技術的な基盤として、Qの高速な処理能力があります。移行シーケンスは数秒で完了し、分解は数分以内、アクションプランの定義は10-20秒で完了します。また、コード生成も約10分で100万行のコードを生成できる速度を実現しています。

この処理速度により、一日のうちに5〜6種類の異なる移行戦略を検討し、即座に結果を確認することが可能になりました。さらに重要なのは、Qが提案する戦略が全て実行可能なものであり、単なる理論的な提案ではないということです。

このような迅速な評価と戦略立案の能力により、組織はより自信を持って移行戦略を策定できるようになりました。なぜなら、実際に何をしようとしているのかを明確に理解し、その戦略を実行に移せることが分かっているからです。開発者チームにコードを提供したり、ドキュメントを基に再実装を行ったりする際にも、明確な方向性を持って進めることができます。

6.2 専門知識への依存度低下

Alexis Henry： Amazon Q Developerの導入により、これまでのような特定の専門知識への依存度を大幅に低下させることができました。特に重要なのは、私のような15年の経験を持つメインフレーム専門家に依存する必要がなくなったことです。

以前は、移行のアドバイスを提供し、典型的な罠や間違いを避けるために、私のような専門家の知見が不可欠でした。しかし現在では、Qがその役割を担うことができます。私の介入が必要になるのは、極めて困難な状況に直面した場合や、Qの機能をさらに強化するためのトレーニングが必要な場合のみです。

これは組織にとって大きな変革を意味します。お客様は自身でアプリケーションのモダナイゼーションを実行できるようになりました。Qに組み込まれた専門知識とAIによる支援により、組織内で自立的にプロジェクトを推進することが可能になっています。これは、メインフレームの専門家が不足している現状において、特に重要な進歩といえます。

このように、専門知識への依存度を下げながらも、高品質なモダナイゼーションを実現できるようになったことは、非常に革新的な変化です。組織は外部の専門家に頼ることなく、自らの判断でモダナイゼーションを進めることができるようになりました。

6.3 ビジネス主導の移行戦略実現

Alexis Henry： 私たちの実装経験から、ビジネス要件と密接に整合した移行戦略を実現できることが明らかになっています。お客様は自身の優先順位に基づいて、特定のドメインを先に移行したり、後回しにしたり、あるいは複数のドメインをグループ化したりすることができます。Qは、お客様のビジネス要件とシステムの技術的な制約の間で最適なバランスを見つけ出します。

特に重要なのは、この柔軟な優先順位付けがリアルタイムで行えることです。お客様の要件に基づいて計画を調整すると、Qは2秒以内に新しい計画を生成します。この計画は、お客様の制約の90-95%を満たしながら、同時にシステムの依存関係も考慮に入れています。お客様の要件と技術的な制約が競合する場合でも、Qは実行可能な代替案を提示します。

さらに、このアプローチにより継続的な改善が可能になります。同じジョブを再実行して新しい入力を提供したり、特定の側面に焦点を当てた分析を追加したりすることができます。Qはその都度、必要なエージェントのみを起動し、以前の結果と新しい結果を統合します。

このように、ビジネスの要件を中心に据えながら、技術的な実現可能性を確保する移行戦略を、柔軟かつ継続的に改善していくことができます。これは、ビジネス主導のモダナイゼーションを実現する上で、極めて重要な特徴となっています。