モダンを極める：IBM i アプリケーションの管理を簡略化し、価値のある知見を抽出する
アプリケーションについてのドキュメンテーションというのは、存在しているにしても、たいていは古過ぎて使い物にならないということを、IBM i の開発者や管理者は嫌というほど分かっています。 シンガポール マネジメント大学のある調査 によると、開発者が新たなコードを書く作業に費やす時間は、作業時間全体のうちの5%に過ぎないそうです。レガシー コードの修正に費やされる時間が20%、そして 修正に先立ってコードについて理解しようとするための作業に費やされる時間は全体の60%を占めているそうです。
業界内での競争に企業が適応するにつれて、IT部門には、既存システムの保守と並行して、システムの刷新やアジリティの向上を求める圧が強まってきます。また、意思決定を支援するために、関係者がアプリケーションから素早くデータにアクセスできるということも極めて重要です。こうしたことは平均的な開発者には無理な注文であり、リソースが第一線を退き、一緒にアプリケーション ナレッジも連れて行かれたら、なおさら困難になります。こうした状況は、アプリケーションを管理するために熟練した開発者を確保する上でも、適切な影響分析なしでアプリケーション変更を導入する際のリスクを軽減する上でも、企業に対する大きな負担となります。
それでは、効率的かつ効果的なやり方で、アプリケーションを理解するにはどのようにしたらよいのでしょうか。
先日のウェビナーでは、参加者の約50%が、彼らのアプリケーションで作業してきた年数は10年未満と回答しています。アプリケーションにはドキュメンテーションがないものの、手作業で作成するのは現実的でないという話は、多くのクライアントから耳にしています。
組織に加わったばかりでも、幸運にもアプリケーションをよく知る同僚に恵まれた場合は、現状の把握を手伝ってもらえるかもしれません。しかし、アプリケーションのスコープによっては、そうしたプロセスは、数か月または数年を要することもあります。
また、そうしたプロセスは、ビジネス要件やコンポーネントについて分かっていても、変更の影響を効率的に分析できないという意味では、ヒューマン エラーのリスクをもたらします。大事なことが見落とされるに至った経緯や、ギリギリになっても変更の影響を理解していなかったということにまつわる悲惨な話を私たちは皆聞いたことがあります。これらは、IT管理者が夜、眠れなくなる原因になります。
RPGまたはCA 2E（Synon）アプリケーションを稼働している企業は、刷新する必要性が不可避であることをよく理解しています。デジタルな世界を迎え、組織はテクノロジーによって産業界に創造的破壊をもたらしています。ITの視点から見れば、お勧めは、まずは、アプリケーション管理に関して異なる考え方をしてみることです。長年にわたって、アプリケーション管理に対する一般的なアプローチとしては、「長年一緒にやってきた対象分野の専門家が何人かいるのだから大丈夫」というものでした。これが許されるのは、アプリケーションが変更されないか、モダナイズされない場合のみです。
一般に、RPGやCA 2E（Synon）アプリケーションは、規模が大きく、モノリシックな構造をしています。コードをモダナイズするポイントは、小さい再利用可能なコンポーネントに分割することです。たとえば、プログラム、ファイル、および表示装置ファイルがあるとします。アプリケーションを管理する従来のグリーン スクリーン アプローチでは、いくつか少数の項目を追跡することが求められていたかもしれません。コードをモダナイズするとした場合、数多くのより小さな部品が生じることになります。そうしたケースでは、機能領域は、たとえば3つのオブジェクトから40個のオブジェクトへと増えることになるかもしれません。アプリケーションはさらに追跡しづらくなります。結果として、変更の影響は、単一のモノリシックなオブジェクトや、同じプログラムの異なる複数のバージョンがあるケースとは異なるものになってきます。
あるクライアントでは、コード行数52,000行のプログラムをモジュール化する必要がありました。タスクを自動化するツールがなかったとしたら、そのプログラムを手作業で理解しようとするのは、ほぼ不可能な作業となっていたでしょう。
どのようにしてアプリケーションを理解するかに影響を及ぼす要因はたくさんあります。前述の通り、ドキュメンテーションがないことは、1つの障害です。何十年も前のことですが、ある同僚がIBM i アプリケーションの開発をし始めたとき、彼はプログラムを印刷し、蛍光ペンを片手にレビューしながら、覚えておく必要がある項目を探していたものでした。それがどのような処理を行うのか、それが何を呼び出すのか把握しようとしていたのです。今は、そのようなやり方はしません。
どこから始めるか?
通常、どのような重要なプロジェクトでも、出発点となるのはコード クリーンアップです。たとえば、コードをモダナイズし始めるとします。何十年分ものコードを分析することになるかもしれません。その場合は、一度にすべてに取り掛かろうとするのではなく、企業にとってメリットの大きいアプリケーションの重要領域を特定するようにすることをお勧めします。そうすることにより、意図せぬ変更が発生することなく、企業価値を高める改善を導入しつつ、対象範囲と労力をコントロールすることが可能になります。アプリケーションをオブジェクトのレベルで調査して、どのオブジェクトが使用されているか確認できれば、修正する必要があるものを修正し、テストする必要があるもののみをテストするだけで済むようになります。
アプリケーション管理を改善する最も効率的な方法は、 Fresche社のX-Analysis のようなツールを使用して、アプリケーションに関して収集したメタデータを活用することです。メタデータがあれば、コード クリーンアップのようなタスクはすぐに行うことができます。一定期間、使用していないオブジェクトを自動識別することもできます。また、それらのオブジェクトが独立しているか、他のオブジェクトに依存しているかを調べることもできます。さらに、プログラムを一切修正することなく、システムから簡単に除去できるものについてのサンプルを作成することもできます。
これはすべて、コードを調べることなく、行うことができます。代わりに、X-Analysisが捕捉したメタデータを見て判断することができます。X-Analysisでは、アプリケーション オブジェクトをフィルタリングおよびソートすることができるため、コード クリーンアップのための強力なツールとなります。使用していない、または繰り越ししないコードをモダナイズするのは意味がないので、時間と労力の大幅な節約になります。たとえば、システム全体のテストを実行する代わりに、1つの機能領域に絞って重点的に取り組むこともできます。
メタデータを使用することは、モダナイゼーション プロジェクトのアプリケーション管理のための有用なアプローチです。たとえば、列および表のサイズ変更（顧客番号をより大きくするなど）を行いたいとします。影響の大きさがどのようなものか、そして、どのようにそれをテストするか把握しておく必要があります。変更を一度にすべてロール アウトすることはできないかもしれません。では、テストを最小にし、リスクが最小になるような方法で、どのようにしてそれを行うのでしょうか。コードを見ることなく、アプリケーションを管理し、依存関係を調べることができるため、プロジェクトをより効果的に管理できます。
自動化されたテストの重要性
X-Analysisによって依存関係が明らかにされるため、テスト環境を極めて迅速にセットアップすることができ、また、テスト環境に他の開発者からの交差汚染が一切ないことが保証されるようにすることができます。また、隔離してテストする必要があるすべてのオブジェクトを確認することができます。さらに、プロセスを繰り返し実行できるようにします。
コードをモダナイズする際に、ビッグバン アプローチは取りたくないものです。一度に少量ずつ行うことを推奨します。つまり、これらのテストを繰り返し何度も実行することになるということです。自動化は、モダナイゼーション プロジェクトを促進する最善の方法です。それらのテストをセットアップし、それらを繰り返し実行することで、利益を生むことになるからです。これは、既存のプロジェクトに当てはまるだけではなく、完了したら、アプリケーション本体とまったく同じ価値のあるアプリケーションの追加コンポーネントを手にすることになります。テストは、元を取ってもお釣りが来る投資なのです。
X-Analysisについて
X-Analysisは、昨日開発されたばかりのものであろうと、30年前に開発されたものであろうと、既存のアプリケーションについての深い理解を可能にする、詳細な解析情報およびインタラクティブな図表作成機能を、アナリスト、開発者、アーキテクト、およびオペレーション チームに提供します。
このアプリケーション分析および管理ツールは、そうでなければ手作業で見つける必要がある、アプリケーションに関する情報を発見することを可能にします。このツールにより、アプリケーションを理解し、アプリケーションの重要でない部分を切り分けする能力が大幅に高まります。変更する必要がある領域に焦点を定めることができるため、開発者の生産性が向上します。それに加えて、X-Analysisは自動化された影響分析を提供するため、リスクが軽減されます。
一部には、既存のアプリケーション設計からのかなりの分量の設計ロジックを保持しておいて、モダナイズされたバージョンのアプリケーションへ移植したいという要望をお持ちの企業もあります。そうした状況では、X-Analysisは、リカバリーされた設計からのエクスポートとしてJEEおよびRPG業界標準モダン コンポーネントおよび図表を自動的に作成する、設計抽出機能を提供します。
レガシー アプリケーション コンポーネントは、JSF、EGL、Facelets、およびHibernateのような永続性フレームワークを組み合わせて使用して書き直すことができ、すべてが、リカバリーされたX-Analysisモデルからトップダウンの自動化によって生成されます。それぞれの組織の状況は様々であるため、X-Analysisスイートは、そのクライアントの適切な開発段階または予算制約に合わせた、様々なエディションで利用可能です。
X-Analysisは、最も構造化されていないアプリケーションからでさえも、設計ロジックをリカバリーすることができます。一方、より構造化されているアプリケーション（たとえば、CA 2E生成アプリケーション）では、X-Analysisは、既存のモデルの詳細を直接抽出することもできます。これにより、効率的かつ効果的な設計リカバリーおよびJEEへのリエンジニアリングのための優れた基準が提供されます。
