モダナイゼーションがうまくいかない理由を二つ挙げた。これら二つの理由からも、十分な現状分析に基づいた現実的なモダナイゼーション計画を立案することの重要性が見えてくる。だが一方で、計画ばかりで次の一歩に進めないユーザー企業も多い。

 十分な現状分析が必要といっても、長年作り込まれたシステムを完全に棚卸しすることは困難であるため、ある程度のトライ&エラーは避けられない。仮説に基づいて実際にリライトやリビルドを試み、技術的な課題の解消や手法のブラッシュアップを段階的に進めることが現実的なアプローチといえる。従って、トライ&エラーも含めた全体計画の立案が重要になる。

「オープン化」と「最適化」で作業を分ける

 筆者らは、モダナイゼーションの作業を二つのステップに分けて遂行することを推奨している(図4)。最初のステップが「オープン化(現行機能の担保)」の作業、二つめのステップが「最適化(リファクタリング)」の作業だ。

図4●2ステップのリライト手法
図4●2ステップのリライト手法
[画像のクリックで拡大表示]

 二つのステップに分ける理由としては、最初のステップが現行機能を担保したオープン化という必須の対応であるのに対して、二つめのステップの最適化はいわば追加要件で、予算や期間に応じて対応範囲を決めることができるオプション的な作業だからだ。

 さらに二つの作業は、必要となるツールやスキルが異なるのでプロジェクト遂行上で区別したほうがよいという判断もある。万が一、最適化がうまくいかなくても、現行機能のオープン化という最低限の目的を担保できる。さらに品質面の要請もある。最適化作業を同時にやると、現新比較の拠り所がなくなり、どこでバグが仕込まれたのか特定が難しくなるからだ。

 具体的な作業としては、最初のオープン化では、現行機能を担保する形でJavaなどへの言語変換(リライト)を実施する。その際、通常採用されるような1行ずつ遂行する言語変換はできるだけ避けるべきだ。これでは、Javaのコードは可読性の悪いCOBOLに近いものとなる。

 筆者らは、次の最適化のステップを見越して、リバースエンジニアリングとフォワードエンジニアリングを組み合わせた方法を推奨している。現行機能をUMLに落とし込み、ターゲットとなるJavaのアーキテクチャーに則するようにUML上のモデルを修正し、Javaソースコードをフォワードエンジニアリングする手法である。

 これにより「汚いプログラムがそのままJavaに変換されてしまう」というリライト手法に対する疑念はなくなり、狙ったJavaアーキテクチャーの上で適切にクラス分けされたプログラムを実現できる。あとは、現新比較のテストを実施することで現行機能が担保されたオープン化が完了する。

 次の最適化のステップでは、重複機能の共通化や、パフォーマンスのチューニング、データモデルの見直し、新規要件に基づく機能の修正・追加などを行う。この最適化に対するニーズが高くない場合は、先ほど避けるべきと述べた1行ずつ遂行する言語変換は、コスト面やスピード面で優れているから、非常に適したリライト手法になる。要は、ニーズに合わせて適切な手法を選択すべきなのだ。

この先は日経クロステック Active会員の登録が必要です

日経クロステック Activeは、IT/製造/建設各分野にかかわる企業向け製品・サービスについて、選択や導入を支援する情報サイトです。製品・サービス情報、導入事例などのコンテンツを多数掲載しています。初めてご覧になる際には、会員登録(無料)をお願いいたします。