AS/400　特集

AS/400の生い立ち

AS/400は、オフコンのシリーズ名で、発売当初（1988年）日本では「社長さんのコンピュータ」として中小企業向けに発売されました。
AS/400も勿論ですが、オフコンも汎用機も各メーカーが独自のアーキテクチャで開発しており、当然各メーカーのハードウェアの互換性はなく、多くの販売店や開発会社はハードウェアに依存した独自の環境でソフトウェアを構築し、ユーザーにサービスを提供していました。
その当時のオフコンを例に挙げれば、富士通はＫシリーズ、三菱はメルコム、NECは3100シリーズ等、その他沖電気、日立もオフコンをラインナップしていましたが、現在は全て生産されておらず、現在も活躍し続けているのは唯一AS/400のみです。AS/400のシリーズ名は、時代とともに変わり、いまはAS/400ではなく「PowerSystems（パワーシステムズ）」です。
しかし「AS/400」の名称が馴染み深いため、今でも「AS400」や「AS」の名前が一般的に多く使われています。（IBM関係者以外はAS400と呼んでいると言ってもいい程）

AS/400の優位性

AS/400のアプリケーションソフトウェア資産は、OSがバージョンアップを繰り返した現在でも、発売当初の30年前に開発したソフトウェアも継承ができ、稼働します。
さらにはAS/400の旧型機であるSystem/36（システム36）、System/38（システム38）の時代に開発されたソフトウェアも現在のOSで動き、OSのバージョンアップの度に、アプリケーションソフトウェアを改修し、ユーザーに費用負担を余儀なくしているWindows環境で開発されたソフトウェアと比べると、AS/400のアプリケーションソフトウェアは驚異的な長寿なアプリケーションソフトウェアと言えます。

AS/400のスペック

AS/400のオペレーティングシステム（OS）としてはOS/400（現在呼称はIBM i）、データベースシステムとしてはリレーショナルデータベースのDB2が搭載され、マシンを仮想化することによってアプリケーションプログラムの実装をハードウェアから切り離すことを可能にしています。
LPAR（Logical PARtitioning、論理区画）機能がIBMのメインフレームから導入され、ひとつのマシンを論理的に複数に分割して使用することができるようになり、各パーティションにはシステムリソース（メモリ、ハードディスク容量、CPU割合）を割当てられ、それぞれにOSが動作します。
動作可能なオペレーティングシステム (OS) は、IBM i (OS/400) 、Linux、AIX、WindowsServer、NotesServerが有ります。
CPUは、当初CICS型が採用されていましたが、1995年にRISC型に移行され、開発言語としてはRPG（Report Program Generator）やCOBOL、C、FORTRN、BASICが用いられていましたが、現在では、TCP/IP環境にてJAVA、PHP等も統合した環境で稼働が可能です。
またオブジェクト思考的に開発できる環境もWeb系言語が流通する前から確立されています。
現在では、Server環境としてHttpServer（Apache Tomcat）,MailServer,FileServer,APServer等、ありとあらゆる機能を初期で実装しており、異機種間との連携も可能なマシンになっています。
またCUoD(IBM eServer Capacity Upgrade on Demand)というサービスがあり、必要な日に必要なだけプロセッサーを増強でき、使用した日数分の料金を支払えば良いサービスがあります。
これは一時的に負荷がかかる繁忙期等が限られたお客様や、一時的に締め処理を速めたい等の要望があるお客様には嬉しいサービスです。
要は高いプロセッサーのマシンを最初から購入投資しなくて済むというわけです。
上記の通りAS/400は、管理面での信頼性と安定性、更に驚くほどのパフォーマンス、高いセキュリティ性を実現しており、会社規模に関わらず、多くの業種で使用され続け、日経コンピュータのユーザー顧客満足度第1位を数年にわたって獲得していました。
その信頼性の高さの逸話として阪神大震災の際には、震災の消化活動で大量の水がかぶったAS/400をパワーオンしたところ、動いたという事例もあったようです。

AS/400の悩ましい現状

その一方、ここ最近、AS/400で開発されたアプリケーションソフトウェアが長寿になったが為に、ユーザー内で起きている世代交代によって技術継承ができない問題と併せ、ドキュメントの更新管理が為されないまま、改修が施され続けたケースによる、AS/400のブラックボックス化問題、更にはオブジェクトのみ存在し、一部のソースコードを紛失してしまったが為に、改修不能となってしまった事例も現実問題としてあり、AS/400の優位性が、却って仇となっている皮肉な現象が起こっているのも事実です。
またAS/400特有のグリーン画面(CUI）は、ユーザーからみると、オープン系（GUI）システムしか馴染みがない若いユーザーには敬遠されがちで、AS/400を捨ててGUI系システムに再構築する決断をしたユーザーも多くあります。
さらにAS/400エンジニアの高齢化により、10年後、20年後に開発ベンダーからAS/400のエンジニアが居なくなってしまうかもしれないと仮定すると、「自社の基幹システムの保守維持は果たしてその状況下でできるのか？」と、高まるリスクと迫る現実に危機感を感じているユーザーも少なくはありません。
AS/400のエンジニアの中には、若手エンジニアがいないことで、自身の存在感が増すと安堵感を持っている熟練エンジニアもいるようですが、若手の育成をしなければ、数年後にはAS/400のユーザー自体がなくなってしまうかも知れないことを現実視すべきと思います。
そこにAS/400の開発ベンダーはAS/400エンジニアの若手の育成が急務と言え、開発体制を維持することで、AS/400離れをしようとするユーザーに対し、少なくとも歯止めをかけるファクターになると思います。

AS/400の今後と課題

その様な中、ユーザーの中にはAS/400の利点を活かしながら、オープン系と何ら遜色がないインターフェースを提供する手立てとして、AS/400はサーバーとして使用し、弱点であるフロントはWeb化している例が、多く見受けられます。
これはAS/400とWebの設計開発技術力を持った一部の開発ベンダーが奮起して、エンジニアの育成に惜しみなく投資をしたことで実現しており、結果ユーザーニーズに応えきれ、更なる信頼を勝ち取っています。
しかしこれらのスキルを持ったベンダーは、業界の中に決して多くはなく、その為ユーザーは相談できる開発ベンダーはないものと判断し、メーカーの営業や開発ベンダーの提案のまま、他のプラットフォームに移り換わるケースが多いようです。
しかし現実的には、AS/400で開発されたプログラムを他の環境に移植するのは中々困難で、当初立てたスケジュールをリスケするケースや、諦めて部分移植に留めるケース、またはプロジェクトを凍結し、基幹をAS/400に戻すケースもあるようです。メーカーやSierも中々AS/400の牙城を崩せず、ユーザーもAS/400を捨てきれないでいるようです。
そこで、他のプラットフォームに業務を侵食されている多くのAS400に、開発ベンダーは、若手のエンジニアエンジニアを育てると同時にAS/400側の開発とweb系の開発能力を兼ね備えたキーになる人材を育て、提案できる体制を築くことで、ビジネスチャンスが広がると思われます。

まとめ

優れたマシーンであることに間違い無いAS/400ですが、優れた能力を持ちながらも、時流に押し流されつつある厳しい環境を打破する為にも、個に拘らず、AS/400の開発ベンダー同士での技術の共有や、大型案件にベンダー同士でジョイントしで提案するなど、個々の力を集めてAS/400の優位性をアピールし続け、実績をあげていく動きが必要と思われます。