IBM i

システムと開発環境の複雑化にどう立ち向かうのか？ -IBM iとローコード開発環境LANSAがベストマッチな理由-

2021-08-23

記事をシェアする:

本記事は、IBM iで稼働するソリューションを提供する株式会社ランサ・ジャパン代表取締役中村哲氏の寄稿記事です。記事の内容は寄稿者自身の見解であり、必ずしもIBMの立場、戦略、意見を代表するものではありません。

システムの複雑化が永続的なDX推進の最大の阻害要因

求められることが多くなると、その結果システムがサポートする範囲は広がり、全体を俯瞰することは困難で、また既存のものと新しいものが混在することで更に複雑化が進みます。技術の選択肢が増えることは良いことですが、選択肢が増えたなりに複雑化が進むことは否めません。現在のシステムは、この状況下で複雑さがますます進行しています。当分の間は益々複雑化が加速することが容易に想像できます。

これだけ多くのITの習得や運用がDXに必要なのか?

この複雑化こそが、ITを阻害する全ての元凶であると筆者は考えています。人口が減少に転じそれでなくても人材不足のなか、状況は、理想は一人でより多くの新技術を研究し、その技術を縦横無尽に駆使してシステムを組み合わせ、組み立てることです。そうなるとそれを実現するスーパーマンが必要になりますが、そう簡単には見つかりません。その結果、要素技術毎に技術者のサイロが出現することになります。エンドユーザー企業も自社だけでこれらの技術を扱えないと、どの技術はどのパートナーに頼むかというように考えざるを得ません。DXの成功要因として、内作やアジャイルなどを進める考え方がありますが、この技術サイロの構築は大きな障害となります。

ノーコードやRPAなどでの局所的なシチズン・デベロッパーの活用は有効ですが、近い将来に全てのシステムがシチズン・デベロッパーで開発されて、システムがそれらと外部サービスで成り立つと考えるのは時期尚早ではないでしょうか。

システムの全体像は把握しなくても良いと開き直れれば良いですが、上記の状況からだんだん全体把握は難しくなり、事業に対するタイムリーなシステムの最適化、つまりDXは難しくなります。

シンプルで継続性のある強靭なITインフラがDXを成功に導く

既存の資産を生かしつつ、小さなチームで迅速に追加変更し続けることで、サステナブルなDXを実現

複雑化は、人口が減る時代にもかかわらず関係者を増やし、コミュニケーションを困難にして、全体の俯瞰を極めて難しくします。現在、アプリ、技術、環境がますます複雑化することが避け難い中で、できるだけシンプルな環境を選択することは判断基準として重要度を増していると考えています。

もう一つのポイントは継続的にDXが続けられるかです。システムは、ややもするとAからBに置き換えて、精根尽き果てて一段落としてきたことは否めません。DXの本質はAからBに総取り換えすることではなく、継続的に利用可能な既存の資産を最大限生かしつつ、必要なものを柔軟に小さなチームで迅速に追加変更し続けることが求めています。あえてDXにサステナブルのSを付けてSDXと呼ぶとして、シンプルさが継続できるかが大きな鍵となるのではないでしょうか。

したがって、システムを継続的に進化させていくには、インフラはシンプルで継続性があり強靭であるべきです。（インフラとはシステムのハードウエア、OS、そして開発環境などを指します）

シンプルなのに高機能・高セキュリティー・高パフォーマンスなITインフラ

システムハードウエア、OSの観点で、IBM iはOS、DB(テーブル)、セキュリティーが一体管理されバージョンアップでも相互の整合性が担保されていることは大きな価値と言えます。また、多くのユーザーが異口同音に強固で止まらない堅牢さも担保されています。筆者のお客様で、退職するまでの7年間不具合によるシステム停止はなかったという話も聞いたことがあります。セキュリティーについては、未だにハッキングされたことのないOSであり、パフォーマンスもIBMが肝いりで開発を続けているPowerチップのおかげで、ムーアの法則で進化しています。気がついて見るとIBM iはインフラとして、相互の整合性が担保されることで、扱う技術者の負荷を大幅に軽減し、オンプレでもクラウドでも最もシンプルで継続性のあるプラットフォームと言うことができるのではないでしょうか。

一方で大きく進化を続けるIBM iは、業界スタンダードとなる全ての技術を搭載し、いつでもDXの取り組みの準備ができていますが、実際には様々な言語に関する習熟とその周辺知識が必要となり、取り組み方を誤るとDXを阻害することにもなります。

開発環境をシンプルにするという観点で、この状況を打破できないのでしょうか。

ローコードでシンプルなアプリ開発を実現

昔の開発環境について言えば、特にAS/400(IBM i)はシンプルで良かったと思います。AS/400の時代のプログラマーだったら理解してもらえると思いますが、当時はセッションのコントロールはOSに任せ、RPGとCLとDDSだけで使いこなすことができました。それでも苦労があり、CLだけで全部できたら楽なのにと思ったのを筆者は記憶しています。

LANSA (https://www.lansa.jp/)が、その夢を30年前から実現してきた事実を改めてご紹介します。

LANSAはQ&Aのみで実行可能なアプリを生成するところから始まります。今風に言えばノーコードです。生成されたアプリはLANSAが提供する言語で記述され、ローコード環境として柔軟にカストマイズすることができます。実際のLANSAの言語の起源は実はCLのシンタックスを採用していました。それから30年、LANSAの言語は、ちょうどFF RPGの様に言語は進化し、5250、クライアントサーバー、Web、ネイティブアプリ、PWAのクライアント・サイド(ロジック、UI表現を含む)、サーバー・サイドの両方の記述を共通の言語で実現しいています。そして、30年前に記述されたアプリは、コード変換をする必要もなく、最新バージョンでコンパイル、デバッグ、最新版エディタで修正可能になっています。

難しいITの習得抜き。ローコードでシンプルなアプリ開発を実現。

ノーコード・ツールにせよ、ローコード・ツールにせよツールの想定を超える詳細なカストマイズは、生成されたRPG、C++、Java、JavaScript、HTML、CSS他を直接修正するのが一般的です。しかし、そうなると初期開発の効率を上げられたとしても、その後いくつもの技術者サイロが必要になることになります。

しかしLANSAは、提供する言語から適材適所でRPG、C++、Java、JavaScript、HTML、CSS他を生成していますが、生成されたそれらのソースコードを解析、修正して使っているユーザーは世界的にも皆無です。デバッグもLANSAの提供する言語で行うことができます。

これほどシンプルで継続性を実現してきた世界は現在のところ他には見当たりません。

LANSAとIBM i はベストマッチでDXをサポート

IBM iは、OSの中にソフトウエアのインフラを一元的に管理できる仕掛けを搭載し、かつ一度作成されたアプリの継続的なサポートは群を抜いているシンプルなプラットフォームということをお話ししました。LANSAも前述の通り、新しい技術を取り込みながらシステムの継続的な保守運用と、刷新をサポートしてシンプルなプラットフォームであると言うことをお話ししました。この２つのシンプルなインフラを組み合わせることで、受け身になりがちな情報システム部門が、自ら業務改革を提案する部門となったケースは数知れない。

IBM iとローコード開発環境LANSAを選択したお客様のDX

例えば、清酒「白鹿」「黒松白鹿」で知られる兵庫県西宮市の辰馬本家酒造様の事例が参考になります。

従業員200人の同社は、2004年にメインフレームからIBM iへの移行を実施し、IBM i上の業務ロジックをRPGで、クライアント側の基幹画面をVisual Basic 6 (VB6）で開発していました。VB6のサポート終了、サーバー側かクライアント側か不具合の原因の特定にも苦労していました。

しかし継続したIBM iプラットフォームとLANSAを採用することによって、一つの開発環境、一つの言語でシステムを開発・運用・メンテナンスすることが可能となり、現在は、「他部署で手に余っていることがあれば、システム部門の仕事としてどんどん取り組む」ことをLANSAを使って実現されています。結果として、部門名も「システムマネジメント室」から「経営管理室」になりました。経営に関わる仕事と情報システム部門の仕事は表裏一体であるという事例であり、小さなチームでDXを実現しています。