【第5回】アプリケーションの系譜とそれを支えるIBM i

これまでIBM i アーキテクチャーの背景にある「哲学」と、このシステムが誕生以来、いかにして変化の激しいIT業界の中で生き残ってきたのかについて説明してきました。ただ重要であるけれど、きちんと触れてこなかった話題があります。 システムは何らかの目的をもって導入されます。その際に重要なのは何のためのシステムなのか、どのようなアプリケーション・プログラムを搭載するのか、という視点です。最終回の今回はアプリケーション・プログラムに関わるテクノロジーを歴史的に捉えてみようという試みです。

専用端末でサーバーを管理していた時代

今でこそサーバー用の端末と言うと、PCないし、スマートフォンやタブレットなどのモバイル・デバイス類を思い浮かべます。かつてPCがまだ業務用途として使い物にならなかった時代、黎明期から概ね1980年代までの主力は専用端末でした。見た目はPCのようにディスプレイとキーボードを備えていましたが、電源をオンにするとサーバーに接続するための画面が立ち上がり、他に使える機能はありません。画面に表示される一切の内容について、自律的なものは何もなく、中央集権的なサーバーから表示文字一つに至るまで制御されます。「専用」端末と言うだけあって、その位置付けはサーバーの一部としての扱いです。そしてサーバーとの間のコミュニケーションの手段（プロトコル）は、サーバーの都合で独自に策定されておりました。IBM社汎用機の例で言うと3270シリーズという端末群があり、IBM i （厳密にはこの数世代前のシステム）については5250シリーズという端末群がありました。1970年代に登場したこれらのシリーズは、サーバーと端末との間の通信プロトコル名として、今日においても生き残っています。 現在に比べると、当時の通信速度は低速、端末も非力、というわけですから、画面の表現力にも限界があります。英数字にして横80桁、縦24行というのが一般的なサイズでしたので、一画面の情報量は、罫線や点滅といった表示属性や色の違いなどを考慮したとしても、せいぜい３KB程度しかありません。5250画面は非常に「軽い」のです。そしてシステム操作やアプリケーションの稼動においても、文字だけの入出力処理、すなわちCUI（Character User Interface）が基本にありました。

PCとLotus 1-2-3の登場が端末の状況に変化を

PCの登場が端末テクノロジーに変化をもたらします。1981年の初代IBM PCに始まり、その後IBM社からいくつかのPCモデル群が登場しましたが、家庭用もさることながら企業にも数多く導入されました。業務用としてIBM PC購入の動機となったソフトウェア、いわゆるキラーアプリケーションの一つにLotus 1-2-3があります。現在はIBMの事業部の一つ、当時はLotus Developmentという独立した会社から販売されていたスプレッド・シートです。そしてPCが企業に浸透してくると、せっかくディスプレイとキーボードが付いているので、そのまま専用端末の代わりとして使えないかという発想がごく自然に出てきます。そこでPCに専用端末を模倣させるためのソフトウェアが登場します。5250シリーズ端末を模倣する（エミュレート）ためのソフトウェアは5250エミュレータ（模倣する者）、というわけです。サーバーの方は、エミュレータ搭載PCであったとしても専用端末が接続されていると思っていて、相変わらず中央集権的に端末を制御し続けます。

GUIが直感的なアプリケーション操作を可能にへ

さて1990年代になると、分散型コンピューティングという従来とは逆の発想が流行します。そしてサーバーと端末の関係においては、画面表示とデータ入力だけでなく、PC側にも何らかの処理を受け持ってもらおうという発想が生まれます。例えば1981年に登場した初代IBM PCに搭載されていたプロセッサは、16ビット・タイプでクロックレート5MHzのIntel 8088と非力でしたが、1989年になると32ビット・タイプ、25MHzのIntel 486が登場するなどPCの能力は格段に向上します。一方でオペレーティング・システムについても1992年には、プロセッサのパワーを活かしてGUI（Graphical User Interface）を基本に据えたWindows 3.1が登場します。システム操作やアプリケーション利用においても、このGUI機能、すなわちWindows 3.1が提供するGUI用API群を活用したアプリケーションが登場します。単にサーバーの言いなりになるのではなく、サーバーと対等にデータのやり取りをおこない、PC独自の処理をおこなうのです。ユーザーは前提知識がなくとも、GUIのお陰で直感的にアプリケーションを利用できるようになります。 その後、2000年代に入るとインターネットの普及とともにブラウザ、さらにはモバイル・デバイスなど端末のテクノロジーが多様化していきます。当然のことながら、業務アプリケーション利用にあたってこれら端末をどう使いこなしてゆくか、という課題がIT部門にとっての関心事の一つになります。ブラウザに対応すれば、どのような端末をサポートするべきなのかという点に煩わされる必要がありませんし、インターネットという広域・高速なネットワークの力を借りて、サーバーと端末との間の距離を気にする必要が無くなります。さらにモバイル・デバイスを利用すれば、アプリケーションの利用場所はオフィス内にとどまることがなく、ビジネスとしての機動力が増すわけです。

「見栄え」重視で軽視されたアプリケーションの継承性

かつてのAS/400登場当初の業務アプリケーションは、CUIの5250エミュレータを前提とする、RPGやCOBOLといった言語と、その開発ツール群によって支えられていました。マシンインターフェースないしTIMIによって、コンパイル済みの古いアプリケーションであっても、新しいハードウェアやIBM i バージョンにおいてそのまま利用できるという特性は、ユーザーから高く評価されています。しかしながら、ITを取り巻く環境が変化するにつれ、アプリケーションに求められる価値にも変化が生じます。GUIの登場は、アプリケーションの使い勝手や直感的に利用できること、という価値尺度に人の目を向けさせるきっかけになりました。見栄えの良さは素人目にもわかりやすく、比較的強い印象を植え付ける効果があります。その一方で、アプリケーション資産の継承性とか信頼性・拡張性といった面は少々地味であるため、それだけでは市場に対する訴求力が足りなくなってきたのです。旧来のRPGやCOBOLプログラムのようにCUIのままでは、見栄えの劣る過去の遺物という意味から、レガシーという言葉で表現されることすら生じるようになりました。 1990年代になると、UNIXやPCがサーバー領域に進出し始めます。特にPCは、端末として使用されていた時代に培われユーザーが慣れ親しんでいるGUIやアプリケーション・テクノロジーを、そのままサーバー領域に持ち込みます。IBM i 上のRPGやCOBOLで記述されているアプリケーションを、このような環境に移し変えようという試みが散見されるようになりました。しかしながらこれは極めて負荷のかかかる作業です。そればかりでなく、期待したパフォーマンスを得る事ができなかったり、プロジェクト期間中に要件変更が相次いで、結局失敗に終わるケースも少なからず発生しました。また、仮に成功したとしても、IBM i の最大の特徴である、アプリケーションの継承性は失われます。リスクがあるのにそれに見合ったメリットをなかなか得ることができない、というのが実情でした。

業務をテクノロジーの犠牲にしないために

では、どうすべきなのか。プログラムの移行を検討する際、そもそも何が問題なのかという点に着目する必要があります。筆者自身の個人的な経験から言うと、ユーザー・インターフェースの古めかしさがあり、それゆえに将来性が感じられないというサーバー本体に対するイメージや漠然とした不安がその本質です。そうであれば無理をせずに、切り分けして本来のメリットは維持しながら、問題箇所を解決するような対策を打てば良いはずです。すなわち旧来のアプリケーションを変更することなく、GUI、ブラウザ、モバイル・デバイスに対応させるのです。このために、IBM社やIBM社以外からも、実績あるツールが日本国内で販売されています。地味に映るかもしれないアプリケーション資産の継承性とか信頼性・拡張性は、基幹業務を支えるアプリケーションとして、極めて重要な特性なのです。業務をテクノロジーの犠牲にしてしまうわけにはいきません。 さて、見栄えの改善は効果のある手法なのですが、昨今のアプリケーションに対する需要を考えると、やはりRPGやCOBOLだけで全てをまかなうのは限界があります。販売管理、生産管理、人事・給与・経理などといった、従来からの基幹とされるアプリケーションは良いのですが、オープンな言語、オープンなアプリケーションは必要です。例えばそれは最近新たに登場した、クラウド対応やアナリティクス（データ活用）などといった領域のものです。

「PASE」が実現するアプリケーションの分業体制

新たな需要を見据えて、IBM i では2000年から、PASEと呼ばれる新しいアプリケーション環境を搭載しています。PASEは公式には「Portable Application Solutions Environment」（可搬性のあるアプリケーション・ソリューション環境）の頭文字を並べたものですが、元々開発内部では「Private Address Space Environment」と呼ばれていた機能です。IBM i の単一レベル記憶という広大なメモリ空間は2**64 [=2 の 64 乗]バイト（16エクサ・バイト、理論上は2**128 [=2 の 128 乗]バイトまで拡張可能）の大きさを持っており、その中で区切られたAIXアプリケーション（バイナリ・コード）稼動用のメモリ・アドレス空間を用意するものです。AIXは単一レベル記憶をサポートしませんが、IBM i と共通のプロセッサを持ちますので、メモリ・アクセスの部分をAIX用に確保しておけば、アプリケーションはそのまま稼動します。これはエミュレーション環境ではありませんので、パフォーマンス上のオーバーヘッドは生じません。そしてこのPASE空間はIBM i の単一レベル記憶の一部ですので、AIXアプリケーションはこれを普通のメモリとして認識しますが、その実態はメモリまたはディスク上に存在します。こうして従来の基幹業務はIBM i、オープンなアプリケーションはPASEという分業体制を単一システム上に作り上げたわけです。 PASE上ではJava、PHP、Ruby、Python、Node.js、Perlといった具合に、サポートされる言語メニューを拡大し続けています。例えばPerlをサポートする旨公式に発表されたのは2016年10月でした。これはIT環境の流動的な動向に合わせて、IBM i のアプリケーション環境も柔軟に対処させてゆこうという戦略に沿ったものです。

IBM iはビジネスのためのサーバーとして今後も変化してゆく

これら言語はオープンであり、その稼動プラットフォームが仮にIBM i ではなくWindowsであったとしても、その仕様に変わりはありません。そうであるならば何故敢えてIBM i 上で例えばPythonプログラムを動かす必要性があるのか、Windows上のPythonで十分ではないのか、という疑問を持たれる方もいらっしゃるかもしれません。筆者は次のように考えています。 企業としてのアプリケーションである以上は、Pythonが独立して存在するわけではなく、DB2上にある基幹業務データにアクセスしたり、RPGやCOBOLの結果を参照したりという事は必須の要件です。そこでメーカーとして、新旧両方のアプリケーション環境を連携するための、ドライバー、API、ライブラリ群を用意し、公式にサポートしています。個人用ではない、あくまでもビジネスのためのサーバーだからです。 IT環境の変化を感じさせる事象は身近なところでも発生しています。個人的なことながら、筆者は大学の非常勤講師として、ITとビジネスの関わり合いに関する授業を受け持つ身分でもあります。受講している学生に聞いたところによると、これまでは大学で最初に習うプログラム言語はJavaだったのですが、2016年度新入生からPythonに置き換わったのだそうです。初めてのプログラミングであっても比較的容易に取り組む事ができる反面、意外に多機能で奥が深いから、というのがその理由のようです。 数年後になると、JavaよりもPythonが得意な学生が社会に出てくるのかも知れません。その時に我々は、その新社会人にPHPを学習するよう求めるべきでしょうか。IBM i としてはそうではなくて、サーバー側でPythonを使えるようにしておく事を選択したわけです。アプリケーションのライフサイクルが短くなるとしたら、言語を学習してから開発に取り掛かる、といったような悠長なことはしていられません。そしてもちろん変化は今後も続きます。IBM i の旧来の環境なのか、PASEを活用するのか、もしくは全く新たな環境が用意されるのかはわかりませんが、今後ともアプリケーション・テクノロジーの変化を積極的に取り入れてゆくことでしょう。IBM i ならばそれを成し得るはずです。これまでの歴史がそれを証明しています。 ＜バックナンバー＞ 【第1回】 戦時中に産声をあげたコンピュータの原風景 【第2回】究極のビジネスマシン開発のために考え抜かれた「哲学」 【第3回】TIMIはどのようにして生まれ、その効果を発揮しているのか？ 【第4回】ITトレンドの中のIBM i サバイバル