NEWS
IBM i のモダナイゼーションを考える(旧コラム) IBM i のモダナイゼーションを考える(旧コラム)
2019.03.19

【第1回】モダナイゼーションは何のため?

【第1回】モダナイゼーションは何のため?
ここ数年、モダナイゼーションという言葉をよく耳にするようになりました。今盛んに議論されているモダナイゼーションとは一体何なのか、改めて考えてみる必要がありそうです。ただ、ひと口にモダナイゼーションと言ってもハードウェアからソフトウェア(アプリケーション・プログラム)に至るまで、その対象範囲は広範です。 そこで、本コラムではIBM iにおけるアプリケーションのモダナイゼーションに話題を絞り、連載形式で考えてみたいと思います。第1回目の今回は、IBM iのアプリケーションのモダナイゼーションの必要性とその目的に焦点を当て、今アプリケーションのモダナイゼーションに取り組むべき理由を探ります。  

モダナイゼーションとは?

アプリケーションのモダナイゼーションに関して、アプリケーションのWeb化、クラウド化、AIの活用、GUI化あるいはJavaやPHPのようなオープン言語の使用など様々なことが言われています。では、これらの新しいIT技術を採用すればモダナイゼーションと言えるのでしょうか。少なくとも、モダナイゼーションとはある特定のIT技術を導入すればそれで完了するものではないことは確かです。なぜなら、新しいIT技術は、あくまでもモダナイゼーションを実現するための手段に過ぎないからです。 では、アプリケーション・モダナイゼーションとは一体何なのでしょうか。アプリケーションのモダナイゼーションの本質を捉えるには、その必要性と目的を理解することが不可欠です。  

モダナイゼーションの必要性と目的

IBM iユーザーの喫緊の課題として、アプリケーションのモダナイゼーションがクローズアップされてきている背景には、IT技術の進化に伴うビジネス環境の急速な変化とプログラマーの高齢化という2つの要因があります。 伝統的なアプリケーションは、一般的にモノリシックで巨大かつ複雑で、修正が難しいものです。ビジネス変化に素早く対応するには、モダナイゼーションによってこの伝統的アプリケーションを将来にわたり容易にかつ短期間で修正、拡張できるように構造を変える必要があります。 伝統的アプリケーションには、長年にわたりビジネスの要求を満たすために多くの投資が行われてきました。そこで、これまで開発してきたアプリケーションを無駄にすることなく中核となるビジネス・ロジックを活かしながら、変化し続ける新たなビジネス要件を満たすことが求められています。 中核となるビジネス・ロジックを維持、再利用しながら、リエンジニアリングやリファクタリングという手段を通じて必要なアプリケーションを短期間で修正あるいは機能拡張できるような構造に改めることがモダナイゼーションの1つの目的です。 次に、もう1つの要因に目を向けてみましょう。現在多くのIBM iユーザーがRPGプログラマーの高齢化という現実に直面しています。ベテランプログラマーの定年退職に伴い、RPGで書かれた大量のアプリケーション・プログラムの保守・管理が難しくなることが懸念されています。 この課題を解決するために、モダナイゼーションという掛け声の下、プログラム構造を見通しの良い理解しやすいものに変えると同時に、独特な構文を持つ旧来のRPGからJavaなどの言語に親しんでいる若い世代のプログラマーにも違和感なく受け入れられる新しい構文をもつ自由形式のRPGに置き換えることで、プログラマーの若返りを図ろうとする動きが出ています。 モダナイゼーションのもう1つの目的は、将来にわたって継続的にアプリケーションの保守・管理ができる環境を整備することだと言えます。  

モダナイゼーションの対象領域

アプリケーションのモダナイゼーションを行うにあたり、何をどのようにモダナイズすれば良いのかその方針を明確にする必要があります。そのためには、アプリケーションの構成要素であるプログラム、データ(データベース)、インターフェースと、開発・運用環境の4つの領域に分けて考えると、モダナイゼーションの方針が整理しやすくなります。それぞれの領域におけるモダナイゼーションの主な狙いは次の通りです。

プログラムのモダナイゼーション

  • プログラムの構造の見直しを行い、アプリケーション・アーキテクチャを統一して理解しやすく修正の容易なものにする

データベースのモダナイゼーション

  • DBエンジンをClassic Query Engine(CQE)からSQL Query Engine(SQE)に切り替えることでパフォーマンスの向上を図る
  • レコードレベル・アクセスからSQLによるアクセスに変え、DBとプログラムの独立性を高めると同時にセキュリティの強化を図る
  • RDBの正規化を行い、DBMSの機能でテーブル間の整合性を担保することによりアプリケーション・ロジックの簡素化を図る

インターフェースのモダナイゼーション

  • タブレット端末やスマートフォンなど、新しいタイプの装置を既存アプリケーションの入出力端末として使用できるようにする
  • クラウドサービスの利用をはじめとする他システムとの連携処理を標準的な形で行えるようにする

開発・運用環境のモダナイゼーション

  • 開発・運用プロセスおよび支援ツールの見直しを行い、開発期間の短縮とソフトウェア品質の向上とを両立させる。
  • 既存のソフトウェ資産を活かしつつ、若手プログラマーの採用、育成がしやすい開発言語環境を整える
 

モダナイゼーションの実施方法

モダナイゼーションの必要性と目的、その対象領域について理解していただいたところで、今度はその実施方法について考えて見ましょう。 まず、モダナイゼーションの対象とするアプリケーションを選定する必要がありますが、基本的に自社でメンテナンスを行うアプリケーションはすべて対象にします。逆に自社でメンテナンスしないアプリケーション、例えばパッケージ・アプリケーションなどは変更等をベンダーに依頼することになりますので対象外とします。 次に、モダナイゼーションの対象アプリケーションの優先順位付けを行います。投資対効果の観点から、ビジネス上の価値が高いアプリケーションの優先度を高く、とりわけ課題が顕在化しているアプリケーションを最優先にします。一方、どの会社でも必要とされるアプリケーションではあるものの、ビジネスの競争優位性にほとんど関係のない所謂コモディティ・アプリケーションの優先順位は低くし、場合によってはクラウドサービスやパッケージ・アプリケーションで置き換えるという選択肢も考えます。この場合当然ながら当該アプリケーションはモダナイゼーションの対象外となります。 優先順付けができたら、各対象アプリケーションの調査を行い、プログラム構造、データの構造、プログラムとデータの関係性などを分析し、その規模や複雑度を把握します。その上でアプリケーションの優先順位、規模、複雑度を勘案してパイロット・プロジェクトの候補を決めます。このとき、パイロット・プロジェクトとしてはあまり規模が大きくなく、複雑でないアプリケーションを選択することが重要です。 モダナイゼーションには新しい技術、開発方法が必要ですが、初めてのプロジェクトでは当然それらに関する習熟度は低く、プロジェクトを実施する上でのリスクになります。パイロット・プロジェクトを実施する目的の1つは、こうしたリスクを最小化することにあり、できるだけ単純で小規模なアプリケーションまたはその一部分に対象を絞るのが理に適っています。さらにパイロット・プロジェクトには、その実践を通じてスキルの習熟を図ると同時に、自社に合ったモダナイゼーションのための技術標準や作業標準を確立するというもう1つの目的があります。 パイロット・プロジェクトを通じて実践的なスキルを習得し、モダナイゼーションに関する自社の標準を確立した後、先に決定した優先順位に基づいて本格的なモダナイゼーション作業の実施計画を立て、それに従ってモダナイゼーションを実行に移します。 お気付きのように、上記のアプローチはシステムあるいはサブシステム全体をモダナイズすることに全社的な理解と同意が得られ、予算が付きプロジェクトとして活動が開始できることを前提としています。しかし、一般的にはなぜ今問題なく使用できているものに時間とコストをかけて調査し直し、リスクを伴う修正をする必要があるのかという声が出るケースがほとんどでしょう。特にIBM iはソフトウェア資産の保護を特長の1つとしてきましたから、そうした反応が返ってくるのは当然かもしれません。 こうした声を跳ね返してモダナイゼーションを推進するには、長期的展望に立ったモダナイゼーションの意義をスポンサーである経営層に理解してもらい、同意と協力を得るための努力が欠かせません。そのためには、まずIT部門自身がモダナイゼーションに対してその真の目的を理解し、「わが社のITシステムはかくあるべし」という確固たる将来像をもつことが肝要です。  

おわりに

今回は、ここ数年アプリケーションのモダナイゼーションが盛んに話題にされている背景、その必要性と目的、実施方法について概観しました。 ともすると、新しいIT技術を導入することがモダナイゼーションであるかのような議論に陥りがちですが、技術はあくまで手段に過ぎません。目的と手段を取り違えることなく、真のモダナイゼーションを目指していただきたいと思います。 次回以降は、今回ご紹介したモダナイゼーションの4つの領域について、それぞれ回を分けてもう少し詳しくご説明する予定です。どうぞ、おたのしみに。  
<著者プロフィール> 西原 裕善(にしはら ひろよし) 日本IBMでSEとしてS/34、S/38のシステム設計および導入作業に従事した後、米国ロチェスターの国際技術支援部門に出向し、全世界のIBM SEやお客様に対してAS/400の技術サポートを行う。帰国後、日本IBM システムズ・エンジニアリング(株)でITアーキテクトとして様々なシステムのアーキテクチャ設計を担当。現在はフリーのテクニカル・ライターとしてIBM iを中心に執筆活動を行っています。
いいねと思ったらシェア
twitter
facebook
hatena
IBM i のモダナイゼーションを考える(旧コラム) 目次を見る

この連載は…

IBM i のモダナイゼーションを考える(旧コラム)
あなたにオススメの連載
できるIBM i 7.4解剖
14記事
できるIBM i 7.4解剖
IBM i の”新”必須言語 〜FFRPG入門〜
14記事
IBM i の”新”必須言語 〜FFRPG入門〜
Windows10待ったなし!どうする5250徹底検証
4記事
Windows10待ったなし!どうする5250徹底検証
PAGE TOP