IBM i RPGソフトウェアのリライトは、ほとんどの場合、良くないアイデアである
IBM i-AS/400のRPGアプリケーションをリライトしようとすると、危険なことや落し穴が待っているようです。そうした試みが良いアイデアとなるケースもありますが、大規模リライトという選択肢を選ぼうとする場合は、あらゆる角度から慎重に検討を行う必要があります。選び得る最悪の選択肢となってしまうこともよくあります。
IBM i RPGソフトウェアが、少なくとも現在の形としては、耐用年数の終わりに近付いていることに気付き始めると、RPGアプリケーションをリライトすることが選択肢として浮かび上がってきます。私たちが切に願うのは、そうした選択肢にすぐに飛び付くのではなく、リライトということについて非常に真剣な検討を行ってみてほしいということです。大規模なミッション クリティカルなエンタープライズ アプリケーションをリライトするということは、障害が発生する可能性が高い、多大な労力を要する困難なタスクであるからです。
ASNAでは、IBM i RPGアプリケーションの持続化についての話を、数多くの顧客から伺ってきました。アプリケーションのリライトの話になったときに、組織のソフトウェアをリライトしたい理由として最もよく耳にするのは、次のような理由です。
- 現行のコードがひどい代物である。
- 今ならもっと良い仕事をすることができる。
- 最初に使用したプログラミング言語が間違いだった。
- ソフトウェアを高速化し、より多くの機能を追加することができる。
- 何が必要なのか当時は理解していなかったが、今は理解している。
これらの理由に共通している点は、どのようなことでしょうか。これらの中に、アプリケーションをリライトすることがどうしてビジネスにとって有益なのかということが伝わってくるものは1つもありません。アプリケーションをリライトする理由については、プログラマー側の領域に焦点が当てられるべきではありません。ビジネス側の領域に焦点が当てられるべきです。プログラマーというのは、新たなソフトウェアを書くことや、新たなツールを使用すること、未知の領域を探索することが大好きです。プログラマーは、ソフトウェアをリライトすることで、自分たちにとって様々な面でメリットがあることを伝えることはできます。けれども、ソフトウェアをリライトすることで、ビジネスにとってどのようなメリットがあるのかについて伝えるのはあまり上手ではないようです。
RPGのSoR（基幹系システム）をリライトする理由は、ビジネス主導であるべきです。計画段階で解決しておく必要がある問題は、どのような新しいプログラミング フレームワークを使用するべきかということではありません。取り組むべきは、たとえば次のような問題です。
- アプリケーションがどれくらい早期にROIを生み出せるようになるか。そのROIをどのように測定するか。
- 新たなアプリケーションが100%正確であることをどのように確認するか。
- どのようにしたら最も適切に資源を割り当てることができ、現実的なスケジュールを作成することができるか。
- 新バージョンは顧客やビジネス パートナーを満足させ続けることができそうか。
このような問題についてじっくり考えてみると、既存のアプリケーションについて何か決断を行う際は、事前にそうしたアプリケーションについて総合的・全体的な評価を実施する必要があることが明らかになってきます。受け売りの知識や情報ではなく、まさに今、身に付いている知識や情報に基づいて判断を行うことが極めて重要です。全体的な評価が適切に行われていれば、アプリケーションについて適切な判断をするために必要となる、信頼できる唯一の情報源が確保されることになります。
リライトは単にコードを書くことにとどまらない
ソフトウェアのリライトというタスクは、単にコードを書くだけの問題ではありません。特に、ドキュメンテーションが書かれていない、数十年来のソフトウェアの場合はなおさらです。実際、コードを書くことは、作業全体の中の簡単な部分であるに過ぎません。しかし、コードを書く前には、以下のことを決めておく必要があります。
- 新たなソフトウェアをどのようにテストするのか。正常に動作するかどうかをどのように確認するのか。
- ソフトウェアをリライトするための現実的なスケジュールはどのようなものになるか。
- どのような資源が必要となるか（たとえば、プログラマー、ツール、サーバーなど）。
- RPGプログラムは他との連携なしには存立し得ないため、システムの補足的な機能（たとえば、EDI、テレフォニー、ジョブ スケジューリングなど）を、どのようにして、そしてどのようなものに置き換えるか。
RPGアプリケーションをリライトしようとしているチームの、そのアプリケーションについての知識は、ないに等しいくらいだというケースがよくあります。元のアプリケーションの適用範囲および複雑さについて、そのチームが十分に理解しておくことは極めて重要なことです。また、そのような知識を持ち合わせていても、デリバリーのスケジュールを作成することは非常に大変です。そしてそのスケジュールを守ることはさらに大変です。ほとんどの場合、善かれという意図のもとであっても、エンタープライズ アプリケーションのリライトをデリバリーするスケジュールというのは、ひどく現実離れしたものになりがちです。
RPGのSoR（基幹系システム）には、何十万行、さらには何百万行ものコードがあります。これをリライトする場合、プログラマーの作業量として、何人年となるでしょうか。たとえば、あるショップに4人のRPGプログラマーがいるとします（「 2021 IBM i Marketplace Survey 」によれば、69%のIBM i のショップには、1～10人のRPGプログラマーがいるということです）。この4人のチームが10年間、RPGアプリケーションについて作業した場合、そのアプリケーションについての作業量は40人年ということになります（図を参照）。最良の環境下でも、RPGアプリケーションのリライトは、複数年にまたがる取り組みということになります。
リライトするなんて言わせたくないですね。
データベースに関する検討事項
大規模なリライト プロジェクトにゴーサインを出す前に、解決しておくべき非常に重要な問題がもうひとつあります。すなわち、どのようにして、データベースを移行およびリファクタリングし、その正確性を確保するのかということです。
プログラマーが1行目のコードを書く前に、データベースの引っ越し先を見つけておかなければなりません。IBM i データベースは、非常に大規模であることに加えて、他に類のないデータベースです。IBM i データベースには、ほとんど他のどのデータベースにもない専門用語や制約があります。たとえIBM i データベースにDB2データベースというブランドが付いていても、IBM i バージョンのDB2は、他のプラットフォーム上のDB2とプラグ&プレイできるわけではありません。
新たなアプリケーションのためにIBM i データベースを移行するというのは、単に、1つのデータベースから別のデータベースへデータをコピーするということではありません。ほぼ間違いなく、プログラマーが新たなソフトウェアを書く前に、データベースをリファクタリングし、十分にクレンジングしておくことが必要となります。こうしたデータベース作業だけでも、困難を極めます。データベースの移行という課題は、それが動く標的であることから、さらに多くの労力を強いるものとなります。新たなソフトウェアを書いている何か月かの間には、データベースは、通常通り、メンテナンスを受ける必要があり、また、変更が加えられることもあります（ビジネス規則の変更への対応など）。
リライトするべき対象を特定する
リライトすることが可能なコンポーネントを特定しても、コアとなるRPGアプリケーションをどうするべきかという課題は、すぐに解決するわけではありません。しかし、特有のビジネス価値を保持する上で重要ではないとみなすことができるものをすべて置き換えることで、RPGシステムを置き換えるという課題が少しは容易になります。
IBM i RPGアプリケーションは、モノリシックな、何でも行うアプリケーションであることが非常に多いです。これらのアプリケーションのほとんどは、ビジネス コンピューティングの草創期に生まれ育ったものです。大量のサードパーティ パッケージが溢れる時代、さらには今日のクラウドベースのソリューション プラットフォームの時代からすると、ずいぶん昔のことです。初期のほとんどのAS/400ショップにはRPGプログラマーがいたため、そうしたプログラマーがビジネス固有のソリューション以外のソリューションも書くというのは普通のことでしたが、総勘定元帳システムや買掛管理システムなどといった、より一般向けの作業を行うソリューションを書くこともありました。
RPGのSoR（基幹系システム）を置き換えることを考えると、RPGアプリケーションのコア部分ではないとみなされるコンポーネントは、どれもがサードパーティ ソリューションに置き換える候補となるのかもしれません（これには総勘定元帳システムや売掛管理システムといったコンポーネントが含まれるかもしれません）。このケースでは、適用範囲は狭く、コンポーネントの目的は容易に切り分けられて明確化されます。
エンタープライズRPGアプリケーションでは、どのコンポーネントが独立したコンポーネントであるのか識別し始めたらキリがありません。つまり、従来のRPGシステムのほとんどのコンポーネントには、他のコンポーネントとの間に何らかのレベルで垂直的な相互運用性があるからです。ほとんどは汎用であるコンポーネントが、在庫管理コンポーネントにアクセスして、直接影響を及ぼしているということは非常によくあります。実際にこうした「越境（fence-jumping）」がある場合は、切り離してサードパーティ コンポーネントに代替して統合するように設計し直すコスト次第で、これらのコンポーネントが切り離されて置き換えることができるか、RPGアプリケーションのコア部分とみなされるべきかが決まります。
苦渋の選択
エンタープライズ ソフトウェアのリライトは、困難を極める、長期間にわたる取り組みとなります。あらゆる角度からその選択肢について調査を行い、極めて現実的な予測を立てておく必要があります。大規模リライトが必ず失敗するとは限りませんが、成功しないことも考えられます。その場合は、資金の浪費になるだけでなく、より大事なことに、時間の浪費になってしまいます。
年数を重ねたRPGアプリケーションと、少なくなる一方のRPGプログラマー人材を前提にして、ビジネス持続性のプランを練るというのは、困難極まりないタスクだと言わざるを得ません。ASNAでは、課題解決の鍵となるのはRPGソース コードであると考えます。ASNAのアプリケーション マイグレーション スイートは、RPGソースを、最新の有用なC#アプリケーションへ変換し、新世代のC#プログラマーが保守や機能強化を行えるようにします。RPGの課題に対するASNAのアプローチについて詳しくは、ASNAのホワイトペーパー、「 The Decade of Crisis for the IBM i and RPG （IBM i およびRPGにとっての危機の10年）」、または ASNA.comサイトをご覧ください。
