前回の記事において、オフコン「IBM i（AS/400）」のアプリケーション資産のホワイトボックス化の必要性の提言と、そのためのソリューションを紹介した。今回はそのソリューションを用いて最初に着手すべき内容を解説する。
不健康のまま近代化する危険性
人は年齢を重ねると同時にさまざまな体の問題を抱えていくことがある。早めに発見、対処するために人間ドックというものがあるが、アプリケーション資産についてもその必要がある。
IT業界にはひと昔前、変化のスピードが犬の成長のように速いことを表現した「ドッグイヤー」という言葉があった。依然としてITのトレンドは変化が激しく、ライフサイクルはますます短くなっており、人間ドック的なことをする前に新しいものに置き換えられてしまう場合もある。
一方、IBM i（AS/400）に関しては、人並みにライフサイクルが長い。現在の状態の把握と、対処した方が良い不健康な箇所、無駄な箇所などの特定がホワイトボックス化に向けて必要となる。問題を抱えたままで近代化（モダナイゼーション）すると、その問題を継承してしまうだけでなく、新しい環境で新たな問題を引き起こす可能性があるからである。長年の進化でさまざまな処理工程を軽減しているために発生する問題のほか、強固なセキュリティで守られていることなどを理由に、従来IBM iで問題にならなかったことがIBM i以外の環境になった途端に噴出する問題も含まれる。
健康診断項目の整理
それでは、人間ドックのように現状システムの健康を診断する項目を挙げていきたいと思う。
まず、カテゴリとして、「資産現状診断」「資産スキル継承難易度診断」「TOBEモデル診断」に大別できる。これらを構成する詳細項目を見ていこう。
資産現状診断
これは「X-Analysis」などホワイトボックス化ソリューションであるアプリケーション解析ツールを使って多角的に分析、診断するものである。
1：稼働資産分析
プログラムやファイルなどのアプリケーション資産の中にある、既に本番稼働していない資産状況を把握する。IBM i（AS/400）では資産継承性が高く、更にそのカタログ情報も引き継がれるが、オブジェクトの最終稼働日時はリセットされる。マシンリプレースから全く稼働していないものを中心に、複数年稼働していないものを明確化する。
2：機能分析
オブジェクトの種別と役割を整理する。役割は、例えばプログラムでの呼び出し関係におけるレベルや画面系、バッチ系の区別など、システム全体で機能として俯瞰できる分類を指す。
3：システム相関分析
業務レベルのサブシステム間の関係性と独立性、密着度を明確化する。
4：影模規模分析
プログラム、ファイルなどの変更に伴う影響範囲を明確にする。データを作成（Create）、読み出し（Read）、更新（Update）、削除（Delete）する「CRUD分析」もこの範疇である。
5：複雑度分析
プログラムの複雑度を定量的に算出、定性的に診断し、プログラムソースのステップ数以外の複雑性における判断基準項目を設ける。
6：共通化分析
冗長性や類似性を分析し、共通化できる可能性のある資産を抽出する。
7：問題分析
アプリケーション資産の不備を明確化する。単純なものではコンパイル元のソースコードが見つからないオブジェクトなどが相当する。
8：不要資産分析
非稼働資産や共通性分析で削減できるオブジェクトも含まれるが、ほかにデッドコードや参照の無いコピー句など、不要な資産と資産内の特定箇所を明確化する。
