API × IBM i （基幹システム）の導入パターン・効果・活用例・「摩擦レス」な次世代継承

記事をシェアする:

 

オムニサイエンスの下野・高島と申します。（共著形式で執筆させていただきます）

今年2022年は IBM i × API (つまりIBM i上で稼働する基幹アプリケーションと、APIの組み合わせ) が大きく浸透する年になると確信しています。その理由について寄稿させていただきます。

弊社オムニサイエンスではIBM i × DXを進めるツール群の一つとしてIBM i を簡単にAPI対応できる API-Bridgeというプロダクトをリリースしています。その関係で2021年は IBM i × API の話を 50社以上の様々な業種・規模の企業様と対話の機会をいただきました。その経験をもとにお話しいたします。

1. API × 基幹システム

昨今、「API」というキーワードは、決して新しい言葉ではありませんが、以前に比べて注目が増しています。その背景にはAPI連携前提のSaaS [ソフトウェア・アズ・ア・サービス: クラウドで提供されるアプリケーション] が増えていること、様々なデータがAPIを経由して公開される 「APIエコノミー」 が進んでいることなどがあります。そんな中、基幹アプリケーションが稼働するIBM i のユーザー企業でもAPIが注目を集めています。

それではまず初めにAPIについて、確認しておきましょう。API = アプリケーション・プログラム・インターフェースの略です。APIは様々な種類がありますが、本稿では主にREST APIのことを指して、執筆します。REST APIが何かについては、検索するとたくさん出てきますので、あまり立ち入りませんが、柔軟性が高いことから様々なサービス間の連携で利用されるプロトコルです。

具体的にイメージいただけるように、受注Webシステムから基幹システムの稼働するIBM i への連携を、例に簡単に図にしてみました (図1参照)。REST APIが仕込まれたURLを引数（パラメーター）と共に呼び出すと、その結果をJSON形式のファイルで返します。基幹システムで利用しているビジネス・ロジックを外部からも利用できます。URL実行時に特定のIPアドレスのアクセス制限やセキュリティー・キーを有する通信以外は受け付けないといったセキュリティー機能を持たせたりすることも可能です。

2. API × IBM i が注目される４つのテーマ別パターン

ではIBM i ユーザー様では、どういった状況において検討・採用されているのでしょうか。これまでにいただいたご相談を総合すると、濃淡はあるものの、大きく下記４つのパターンに分類できます。

• パターン１：APIアーキテクチャーの推進
• パターン２：顧客向けDX
• パターン３：社内DX （新アプリとの連携）
• パターン４：社内DX（IBM i アプリ強化）

コンサルティング会社や大手SIerが支援されている大規模な企業様では、特にパターン１が多く、当初の想定以上に社内システムをAPI連携前提のアーキテクチャーに変革を進める企業様が増えていることを実感しました。そして、企業規模問わず、社内外のDXを実現する一つの手法としてクラウドやSaaSの検討が進み、その連携手法として、APIに注目する企業様も多くいらっしゃいました。それぞれのパターンの詳細は図２をご覧ください。

3. API × IBM i サーバー＆クライアント ２つのパターン

それではもう少しIBM i × API連携の技術的な内容を掘り下げたいと思います。サーバー・クライアントの関係においては、IBM i がAPIを実行するサーバーになるのか、外部のAPIを呼び出すクライアントになるのか、２種類のパターンがあります。

IBM i をAPIサーバー化するパターンは、外部からIBM i 上のアプリケーション・ロジックを利用したい、データベースをリアルタイムに更新・照会したいというニーズです。一方IBM i がクライアントとして外部のAPIを呼び出すパターンは、IBM i をトリガーとして外部に通知・更新するニーズと、外部のサービスからAPIでデータをIBM i に取り込みたいニーズの２つがあります。こちらも詳細は図3をご覧ください。

4. API × IBM i の効果と意義は何なのか？

多くの企業様とIBM i × APIをテーマとしたお話をする中で、IBM i ユーザーがAPIを取り入れることの効果と意義が広範囲にわたることを、当初の想定以上に再認識しました。効果は以下３つに集約されます (図4も併せご参照ください)。

• 効果１：アーキテクチャーの脱密結合・疎結合化
• 効果２：開発体制の柔軟性の強化（Web＆クラウドとIBM i の壁を壊す）
• 効果３：連携先ソリューションの幅が広がる（IBM i でソリューションを稼働させる必要がない）

こうしたアーキテクチャーと組織体制やソリューション選択肢の多様化は企業のDX実現力に直結します。DXで主役となるアプリとIBM i の基幹システムの連携を実現する部分がボトルネックになると、DX推進スピードを大きく削ぐごとになります。IT業界で使われることが増えてきた言葉でありますが、アジリティー（俊敏性）を高めるうえで、APIは非常に効果的です。

次の点は、学びの一つでもあり、本稿で最もお伝えしたいことの一つであるのですが、IBM i の担当者と連携先アプリの担当者との責任分界点を明確にできるということが、API × IBM i の最も重要な効果と捉えられる企業様も多いように感じました。責任分界点が明確だと、開発体制を整えやすくなります。

責任分界点が不明確、連携が密結合になると、IBM iもWebも両方できる技術者を探さないといけない！となります。しかし両者の連携がシンプルであれば、IBM iを知らなくてもいいのでWebができる技術者と、Webは知らないけどRPGができる技術者がいればプロジェクトを推進できます。

API連携前提のアーキテクチャーであれば、疎結合化が進み、アプリケーションの連携がシンプルになることによって、結果として、スピード、コスト、開発体制準備の難易度 すべてにポジティブな影響を与えます。

5. API×IBM i は”摩擦レス”な次世代継承に役に立つ？

IBM i の技術者がシニアな方が多く、次の世代にどう繋げていくか検討されている企業は比較的多いかと思います。長年IBM i の基幹システムを担当されてきたベテランの技術者は、単にRPGやデータベースなどIT技術のみならず、業務スキルも豊富な方が多くいらっしゃいます。そのため後任の方への期待値も高く、更に技術継承のハードルが高まってしまっている例も多いでしょう。

業務スキルとITスキルの修得プランは分けて考える必要があるのでないかと思います。業務スキルは、その企業特有の部分も多く、各社固有のプランになる部分が多いかと思いますが、これはDXプロジェクトを経験する中で、一定の時間をかけて修得されていくパターンが多いかと思います。一方、ITスキルはある程度、すべての企業で共通する部分も多いでしょう。これも一気にすべてを修得できるわけではないため、段階分けしていく必要があります。その例として、３つの段階があります。

• STEP1：IBM i のロジック・DBを利用したWebやSaaSの開発
• STEP2：さらに、IBM i 側のAPIも含めた開発
• STEP3：必要に応じてRPGロジックを追加開発

ビジネス状況、情報システム部門の体制など、企業ごとの事情によって、様々なプランがあると思いますが、一つの例を記載しました。こちらも詳細は図5をご覧ください。

表にも記載の通り「IBM i API化ツール（API-Bridgeなど）」・「アプリケーションの解析ツール（X-Analysisなど）」・「RPG開発モダナイゼーション技術（FF-RPG・VScodeなど）」とIBM i モダナイゼーション 3種の神器（？）を利用して、”摩擦レス”な次世代継承ロードマップを描くご参考にいただければ幸いです

6. IBM i × APIで広がる選択肢の例（業種・連携先）

多くのご相談をいただく中で、APIで接続したい先はユーザーによって様々です。こちらも参考までに表にしてみました。詳細気になるものがありましたら、ぜひお問合せいただけますと幸いです。

7. API × IBM i の浸透に向けた取り組み

ここまでAPI × IBM i について、いくつかの視点でまとめました。その意義を一言で言うと、「疎結合アーキテクチャーを実現しながら、Web＆クラウドとIBM i の技術・技術者の壁を壊し、短期でも長期でもDX実現力を高めること」です。今後IBM i × DXを推進する突破口として、APIという切り口はますます一般的になっていくと確信しています。（コンセプトを実現するいいツールがなかっただけかもしれませんが、なぜ今まであまり浸透していなかったかが、逆に不思議に感じています。）

弊社では、これまでオープンソース協議会 – IBM i でのコミュニティー活動や、プロダクト提供・受託開発を通して、日本のIBM i ユーザー企業にオープンソースの浸透を図ってきました。2020年までがオープンソースによるWeb化の時代だったとすると、2030年に向けてはIBM i はクラウド対応時代になると予測しています。クラウドへの対応をいかにスムーズに進めていけるかが、IBM i を次の時代も有効活用していく上で、非常に大事なポイントで、そのご支援をしていきたいと思っています。その一環として進めている３つの取組につき、最後にご紹介させてください。

取り組み１：API-Bridgeの製品提供

IBM i のAPIサーバー化、APIクライアント化の両方に対応でき、インターフェースを徹底的にシンプルにすることで、IBM i の企業様がこれまでの延長上で簡単にIBM i × API連携に着手できるように、全て自社開発で提供しています。

• ご参考ページ：「API-Bridge」製品ページ・問合せフォーム（株式会社オムニサイエンス）
• ご参考ページ：「API-Bridge」Webセミナー情報（株式会社オムニサイエンス）

取り組み２：DXチャレンジ 2021への協力

APIがIBM i × DXの推進における有力な切り口であるということで、日本IBM主催のDXチャレンジ 2021への協力の機会をいただきました。IBM i × DXのプロトタイプを、ビジネス・パートナー各社が作成するコンテストです。LINE、kintone、slack連携といったプロトタイプ作成の技術支援およびAPI-Bridgeのご提供をさせていただきました。

• ご参考ページ：準備中（2022年春 ご案内見込み）

取り組み３：「APIコンソーシアム-IBM i」の発足

IBM i をAPI化するだけであれば、API-Bridgeなどのツールを活用することで、簡単にできます。しかし、IBM i × APIによって、何を実現できるのかが一番重要です。また連携先のアプリケーションによっては、多少ノウハウもありますので、そうしたノウハウや活用事例を如何に簡単に情報収集いただけるかもまた、重要になっていくでしょう。そのためのエコシステム開発に注力していきたいと思っています。

• ご参考ページ：IBM i市場でのAPI普及を狙い、「APIコンソーシアム-IBM i」が発足 ～APIユースケースの発信や情報提供に注力

最後までお読みいただきまして、誠にありがとうございました。