IBM iアプリケーションのモダナイズについてのアドバイス
経営幹部のほとんどは、ITの重要性を認識していません。ITの重要性を理解していないからこそ、10年前、20年前、さらには30年前に導入されたシステムを再構築することでもたらされる潜在的なビジネス上の利点を見出すことができないでいます。それでは、組織内でのITの認識を変えさせることはどれくらい重要でしょうか。
また、どのようにしたらITについて戦略的に考える経営者が多くなるのでしょうか。手掛かりの1つは、ITがどのようにして成長の原動力になるのか、そしてITはリスクが高く投資利益が少ない金食い虫などではないことを示すことです。確かに、克服しなければならない課題はあります。そうした課題に目を背けてはなりません。
これらはすべて、あるウェブキャストを聞いていて頭に浮かんだことです。そのウェブキャストは、IBM i Webおよびモバイル アプリケーションがビジネスの成長をどのように支援できるかについて説明するものでした。プレゼンテーションの途中で視聴者に対して、既存のコアとなっているアプリケーションに関する今後の計画について質問が投げかけられました。半数以上は、何をしたらよいのかまだ模索中という回答でした。おそらく、視聴者は良いアイデアがないか探していたのであり、だからこそ、このウェブキャストを視聴していたのでしょう。
コアとなっているビジネス アプリケーションをモダナイズするプロジェクトを、どのようにしたら成し遂げることができるかまだ模索中であるときに、あるIT計画（それほど戦略的でないものも含めて）が価値ある投資なのだと経営幹部を納得させるのは簡単なことではないでしょう。
ウェブキャストのパネリストで、Fresche Solutions社のIBM iのモダナイゼーションの専門家であるGreg Patterson氏はこう述べています。「資金なしでは夢は実現しません。資金が十分になかったら、成功はもたらされません」 事業に影響を及ぼすようなプロジェクトを開発する必要があります。特に多大な影響を及ぼすタイプのプロジェクトの例としては、次のようなものがあります。-新たな市場を切り開く機能。-セルフサービス、eコマースWebサイトの開発。-他のアプリケーションとの統合（双方向の情報アクセス）。それぞれの複雑さの度合いは、簡単なものから難しいものまで様々です。
Patterson氏のアドバイスで最初に行うべきとされていることは、経営幹部に対してITの現状についての評価を提示することです。スキル、利用可能なリソース、リスク、コスト、およびスケジューリングについての説明が示されたロードマップが必要になるとPatterson氏は述べます。
スキルの習得が必要とならないケースはほとんどないでしょう。アプリケーションをWebに展開する場合は、エミュレータ前提のアプリケーション開発からの脱却が必要となります。新たな言語や新たなアーキテクチャーを扱うことになります。スキルを習得するためにトレーニングするか、不足しているスキルを持つ従業員を新たに雇用するか、あるいは以前に何度かこうしたプロジェクトを経験している専門家と契約するかのいずれかです。
スキル不足に対する不安感は、私見ですが、誇張され過ぎているように思われます。うまくいっている組織では、ビジネス ロジックについての知識経験が豊富な既存のRPG開発者に対してトレーニングを行っていたり、モダンRPGスキルをすぐに習得する若い非IBM i開発者を雇用したりしているようです。しかし、アプリケーションをモダナイズおよびモジュール化することは、IT評価の一部でなければなりません。書き直しが必要となるアプリケーションが出て来ることや、外部の支援がなければ評価を完了できない場合もあることを考慮に入れて計画を練る必要があります。
IBM iのショップにおけるコア アプリケーションと言えば、たいていは大幅にカスタマイズされたグリーン スクリーン アプリケーションです。それらは、元々は社内での使用を目的として、そして他のプラットフォームとの統合は限定して書かれたものです。そのままにしておいた場合、顧客やビジネス パートナーが使用したり、モバイル ユーザーが利用しているアプリケーションと比べたときに、それらのビジネス価値はしばしば疑いの目で見られるようになってしまいます。ビジネス価値を最大化するとしたら、モダナイゼーションかマイグレーションか、どちらかに決めることになります。両方の選択肢を検討したほうがよいでしょう。どちらか一方が全面的に正しいわけでも、間違っているわけでもないからです。
良い判断は知識や経験に基づいて行われるものです。経営幹部というのは、より良い判断を行えるように、より多くのより良い情報を求めるのが常です。にもかかわらず、私が耳にした話からすると、レガシー アプリケーションについてどうするべきか判断する際に、少なくともIBM iサイドからの選択肢に関しては、あまり十分な情報が提供されないまま、判断がなされてしまうことがよくあるようです。
どのような選択肢を選ぶかは、次の1年間、3年間、さらには5年間のビジネス ニーズやIT戦略次第で変わってきます。そうしたビジネス ニーズやIT戦略の例としては、次のようなものがあります。
既存のグリーン スクリーン アプリケーションをWeb対応させることによって外観的な変更を行うとともに、タブやドロップダウン メニューを導入してナビゲーションの強化を図る。これは、一番手っ取り早く、一番簡単で、一番費用が掛からない選択肢です。また、選ばれることの多い選択肢でもあります。最小限のトレーニングは必要です。
既存のコア ロジックを呼び出す新たなWebアプリケーションまたはWebサービスを導入することによって既存のアプリケーションを拡張する。これは、完全な書き直しに比べれば、手っ取り早く、より簡単で、費用は少なめで済みます。既存のスタッフをWeb開発の概念に慣れ親しませるために、おそらくある程度のトレーニングが必要となります。あるいは、これらのスキルを必要に応じてコンサルタントから提供してもらうことも可能です。
場合によっては、完全な書き直しが最良の選択となるケースもあるかもしれません。モノリシックな(※一枚岩的な、モジュール化されていない）RPGコードは非常に複雑に入り組んでいるため、アプリケーションを理解してコードを部品として再利用しようとするよりも、書き直した方が手っ取り早いケースもあります。組織によっては、プラットフォームに依存しないJavaまたは別の言語（PHPまたはNode.jsなど）でRPGアプリケーションを書き直すのもよいかもしれません。
もうひとつの選択肢は、既存のアプリケーションをパッケージ アプリケーションに置き換えることです。この場合、既存のビジネス ロジックは使用できるかもしれませんし、できないかもしれません。使用できるとしたら、プロジェクトのコストは少なくて済み、より迅速にプロジェクトを完了でき、元のアプリケーションにあったフィーチャーや機能が新たなアプリケーションで使えなくなるというリスクは少なくなるはずです。パッケージ アプリケーションで再利用できるビジネス ロジックがほとんどまたはまったくない場合は、フィーチャーおよび機能が失われるリスクは非常に高く、プロジェクトの失敗につながりがちです。こうした完全置き換えの方式に時間と費用をつぎ込んだにもかかわらず、以前のコードが一部しかカバーされなかったり、パフォーマンスが悪かったりという結果に終わってしまうことも十分あり得ます。
プロジェクトの計画が十分に練られ、適切に資源が投じられていれば、マイグレーションであろうと、モダナイゼーションであろうと、うまく行く可能性は高くなりますが、プラットフォームから離れてしまうのは、多くのマイグレーションで良い結果をもたらしていないようです。
十分に練られたプロジェクトということとの関連で、Patterson氏はアジャイル開発プロセスの使用を勧めました。これは、プロジェクト全体の中の小さな部分に焦点を当てることを可能にするため、次の開発段階へ進む前に企業ユーザーから少しずつフィードバックを得ることができます。ユーザーの問題点、ワークフローに向き合うことで、ステークホールダーを理解し、プロセスの一部に変えるというわけです。
Patterson氏はまた、プロジェクトの計画者がIBM iの外側からの視点で考えてみることも勧めています。すなわち、他のソースからのデータのアクセスについて検討するということです。Webサービス、他のプラットフォーム、および他のデータベースは、おそらく統合される必要があるでしょう。新しいテクノロジーおよび情報のソースは、ほとんどの場合、アプリケーションの機能の強化をもたらしてくれます。
展開というのは、もはやエミュレーターに対して使うだけではなくなっています。アプリケーションは、クライアント側でも、サーバー側でもホスティングできます。既存の人員に対してトレーニングを行ってください。彼らは既存アプリケーションについての知識や経験を豊富に持っています。彼らには、Web開発のスキルがあるでしょうか。RPGとデータベースのスキルを併せ持つ人材が必要です。
詳細な説明や価値提案がなされないのであれば、経営幹部からの支援を勝ち取れる見込みはほとんどありません。
私が聞いたウェブキャストは、こちらのリンクからオンデマンドで視聴できます。このウェブキャストでは、ビジネス戦略に沿う形でアプリケーションをうまくモダナイズした組織の成功事例もいくつか紹介されています。
