前回の記事において、一般的なレガシーのイメージとは違う「IBM i（AS/400）」のレガシーの正体を特定した。今回は、レガシーであるユーザーアプリケーションや古い使い方のモダナイゼーションを阻む障壁を分析し、本記事の主題である「新しい選択肢」につながる、乗り越えなくてはいけない条件を提示したいと思う。
サステナブルなレガシー
IBM iと他のシステムとの大きな違いの一つとして、アプリケーションリソースの継承性が挙げられる。
多くのシステムではOSやフレームワーク、ミドルウェアなどのバージョンアップに伴い、アプリケーションに何らかの手を入れる必要がある。この手間が大きい場合は、全体をリビルド（再構築）し、更にフレームワークやミドルウェアも変更するなど、基盤のリプレースも併せて選択するユーザーもでてくる。
これはコストがかかるというデメリットがあるが、一方でメリットとして、数年に一度アプリケーションが最新のアーキテクチャーに順応するという点が挙げられる。
一方、IBM iのプログラムやデータベース関連のオブジェクトはリコンパイル（再変換）無しに、そのまま新しいOS、マシンに移行でき、そのまま稼働するサステナブルな仕組みとなっている。
サステナブルの意味としては「維持できる」「持ちこたえられる」といったものがあるが、この仕組みを使った移行コストは他のシステムに比べて極端に少ない傾向にある。30年以上経過したアプリケーション資産が最新のマシンでそのまま稼働することは、テクノロジーとしては素晴らしい一方で“諸刃の剣”でもあり、アプリケーションを最新のIBM iのアーキテクチャーに順応させる数年に一度の機会を失っている。
アプリケーション自体が塩漬けになることこそ無いが、開発手法や開発ツール、アプリケーションのインターフェースなどが30年前のままといった塩漬け状況も生んでいる。
レガシーボリューム
サステナブルなシステムということは、表向きサーバーやOSなどのプラットフォームを最新化しても、同じプラットフォームで長年に渡りアプリケーションを利用することと同じ意味になる。アプリケーションリソースの棚卸しやスリム化をしにくい状況を作っている。
また、長年同じプログラムを使うことは、前任者が何年も前に作ったプログラムのロジックの詳細がわからないなどの問題も生みやすい。前任者のコーディング意図を理解できず、ソース行の増加、複雑化という負のスパイラルに陥る傾向がある。
古いプログラムを丸ごとコピー、ソースの一部を変更して新しいプログラムを作ることも横行しており、派生、冗長化した処理がそのまま大量に蓄積している。このボリュームが年々大きくなってきており、モダナイゼーションに対する量的な障害となっている。量が多いことはモダナイゼーション費用の高騰に直結する。他のプラットフォームに移行を試みて見積もりを取った企業の中には、自身が考えていた見積もりと1桁、場合によっては2桁違う額を受け取り愕然としたという声も多い。
