DXレポートで示された「最大12兆円/年の経済損失」に懐疑的なITマネージャーに贈ります！

API とは 2025年の崖と未来をつなぐ架け橋

• LINEで送る
• ツイート
• 

そう考えた場合、「頭痛が痛い」ではないですが、「DX戦略」では「戦術戦略」となってしまう日本語に違和感を感じられる方が少なくないことを願ってやみません。

本トピックは、当サイトの人気コンテンツ「CIO・情報システム部門のミッション考察」および「ERP移行・基幹系システムの再構築を成功させる5つのステップ」と続いた3部作の最終章として、「戦略：strategy」の下位にあるDXという「戦術：tactics」、さらにその下位にある「戦法：methods」という身近なところから、「APIエコノミー」をキーワードとして皆さんに未来への希望をお持ちいただくべく寄稿いたします。

目次

• 「2025年の崖」で標的にされたメインフレームなどレガシーIT資産の現状は？
• 本当の problem：問題はデータが活用できないこと
• 今後の issue：課題はAPIエコノミーの住人になること
• Waha! Transformer によるデータ連携は、REST API経由のデータ授受に対応しています。
• REST APIオプションの活用例

「2025年の崖」で標的にされたメインフレームなどレガシーIT資産の現状は？

これは筆者の周辺で、某銀行や某教育産業に従事する知人から聞いた観測範囲の狭い話しではありますが、共通していたのは「メインフレーム／ホストコンピューター（汎用機）は捨てていない」ということでした。
専門家ではない彼ら・彼女らの話しを裏取りしてみると概ね下記のような状況のようで、結論としては「（大騒ぎするような）崖などそもそもないらしい」ということでした。

• ハードウェアについてはメーカー保守が切れてもサードパーティ保守で安価に使い切る
• COBOLベースの業務アプリケーションについては変換サービスがあるから、COBOLを直接触らなくても新システム側でメンテナンスできるので使い切る
• 設置拠点についても、かつての電算センターがコンタクトセンターとなって拡充し続けているから、電源設備含めて存続可能

このような風潮・トレンドは、SDGs：Sustainable Development Goals の一環というわけではないのでしょうけれども、大量生産・大量消費・大量廃棄の時代には考えもしなかった「使い切る」エコシステムが拡がっているのでしょうか。

2018年の「DXレポート」で「最大12兆円/年の経済損失が生じる可能性！」と警鐘が鳴らされた問題の現状は、蓋を開けてみればそれ以前から計画されていた新システムへの移行の過程で、コスパ高く・賢く・華麗にスルーされていることがよくわかりました。

脊髄反射せずによく考えてみれば当然の話しですが、例えば我が国が世界に誇るスーパーコンピューターもハードウェアとソフトウェアで構成されているわけで、相手がモノである以上当然のこととして寿命はあり、全体をゴソッと入れ替えるのかパーツの入れ替えやアプリケーション・モダナイゼーションなどの手法で延命できるのかは、適切なタイミングで最も費用対効果の高い方法を選択すればよいわけですね。

本当の problem：問題はデータが活用できないこと

筆者が「DXレポート」の中で良心として読み取ったのは「データ活用ができない場合、」という、問題の本質への言及がきちんとされていたところです。

情報システムで重要なのは「ハコモノ」ではなく「中身：データ」のはずであり、ハードウェアや業務アプリケーションは「ハコ」ですから寿命に応じて更新し続ける必要があります。
例えば決算や取引データのように一度確定したデータはそのまま保持し続けることができなければいけませんし、電子帳簿保存法のような法制もそのために改正されたと捉える必要があるはずです。

ここで一つ、「システム障害」によって「データ活用できない場合」を、影響範囲が広くて深そうな商業銀行を例に想像してみましょう。

メガバンクや地銀と呼ばれる国内の商業銀行は、日銀からの借り入れや預金を原資に、主に融資する際の利率との差額を利益として事業が運営されてきましたが、もし仮に融資先や融資残高のデータが消滅したり誤って記録されるなど、データを正しく活用できなくなってしまったら何が起きるでしょう？

まじめで几帳面な融資先は期日通りに返済してくれるでしょうけど、うっかりさんな融資先は返済期日を忘れたり、引き落とし口座の残高不足が発生してしまうかもしれません。さらに、融資担当者は紙ファイルで持っていた最新ではない融資データをもとに融資先にコンタクトしてしまうことで、最新の正確なデータを持っていないことが顧客に露呈してしまい、信用失墜につながってしまうことでしょう。

そうなれば金融庁による業務改善命令どころではなく、収入がなくなって支出するだけの事業体に残された道は破産・倒産しかありませんし、そのような基幹データを紛失・誤用してしまう事業者であれば、事業再生の道も閉ざされてしまうのではないでしょうか。

筆者が「2025年の崖」で示して欲しかったのはこのような例示であり、銀行の勘定系システムに代表されるメインフレーム：巨大な一元管理システムにすべてのデータが集約されているのであれば、BCP：事業継続計画の観点からそれこそが大問題ということではないでしょうか？

預金や融資のように事業の根幹を支える基幹データは、それぞれの業務フローに最適化されたアプリケーションとデータベースで運用し、勘定系のような基幹システムでは各業務アプリケーションと必要なデータを受け渡しするなどしてリスク分散をはかるのが、そもそもの金融業の得意なところであり、私たちのモデルとなってくれるはずではないでしょうか。

先に紹介した知人に一元管理か分散管理かといった辺りも聞いてみたのですが、彼ら・彼女らは情報システム部門に属しているわけではないので、詳しいところまでわかりませんでした。
しかしながらさすがは著名企業、IT関連メディアに各社とも「API連携」を推進・分散管理している状況がお披露目されていました。

今後の issue：課題はAPIエコノミーの住人になること

API：Application Programming Interface と聞くと「気象庁の天候データ」のようにオープンデータやインターネット経由のデータ受け渡しを思い浮かべる方がいるかもしれません。

ところが、長年にわたってソフトウェア開発に従事している方々にとって「Windows API」などは慣れ親しんだものでしょうし、クラウドシフトが進んだ令和の時代にあっては、企業や官公庁で使われるような業務アプリケーションも、システム間のデータ連携手段として API に対応しているものが増えてきましたし、API で直接アクセスできない場合も、別建てで API サーバーを構築できるような製品・サービスも登場しています。

さらに、金融DXといった文脈で注目される「ブロックチェーン」も大きくとらえれば API の一種とも言われていますから、テクノロジーの知見を得る意味からも、APIエコノミーの住人になっておくことにはメリットがありそうです。

「DX」という戦術論に踊らされることなく、「2025年の崖」をヒントにした戦法のレイヤーの中心に「一元管理システムからの脱却」や「API 経由で連携する分散システム」を据えることで、ビジネス現場主導のトランスフォーメーションにも柔軟対応できるようにすることを、「DX推進」の前提に位置付けていただくのがよいのではないでしょうか？

Waha! Transformer によるデータ連携は、REST API経由のデータ活用に対応しています。

商品名の transformer は直訳の変圧器・変成器やAI分野で著名な深層学習モデルというより、データ変換・加工装置とご理解ください。

1999年のリリース以来、類似製品が提供する SDK：Software Development Kit（ソフトウェア開発キット）のようにアプリケーション仕様の改変・拡張によって保守サポート範囲を狭めてしまうような機能提供は行ってきませんでした。
その理由は、データ連携の処理性能を最重要と位置付けていたためであり、カスタマイズされるべきは汎用性のあるデータ連携先の拡充にあると考えていたためです。

そのような提供方針の元、前述のようなトレンドを受け、リリース20周年を迎えた2019年に「REST：Representational State Transfer API」によるデータ連携オプションを開発・提供開始しました。
さらにその翌年には、Waha! Transformer で作成したデータ処理設定を、WebブラウザからAPI経由で手動実行できるオプションも開発・提供開始しています。

• REST Clientオプション：REST APIサーバーに対してリクエストを発行するクライアント機能
• REST Serverオプション：Waha! Transformer が REST APIサーバーとなって、データ処理の実行リクエストを受け付けられる機能

情報システムのご利用環境やデータ連携対象となる業務アプリケーションのクラウドシフトが進む中、少なくとも「2025年の崖」を迎える前に、Waha! Transformer も「APIエコノミーの住人」になったわけです。

これにより Waha! Transformer のデータ連携先は一気に拡大しました。
さらに、DB読み書きオプションと同様、接続先が増えるたびにオプション課金が積み重なっていく類似製品のような提供方式はとらず、機能としてのオプションを導入していただくだけで接続先のサーバー数といった制限は設けていませんから、ご利用範囲が拡張するたびにROI：投資対効果も向上していくという好循環サイクルで運用していただけるようになっています。

その結果、例えば「2025年の崖」に隠された問題でもある「業務アプリケーションがシステム間でデータ連携するためのアドオン開発やカスタマイズ」といったように、負の遺産となることが目に見えている部分最適・サイロの象徴を、ゼロにはできなくても相当量削減していただくことでお役に立てると考えています。

ETLツール×API×RPAはデータ連携の最強トリオ？

組織内外のデータを連携させる基盤としてのETLツールに、接続先としてAPI連携可能な業務アプリケーションやオープンデータが加わることの効果は、本トピックをご覧いただいている方であればすぐにイメージしていただけるかと思います。

さらに、バックエンドでデータ連携するETLツール×APIに、フロントエンドでデータ連携するETLツール×RPAツールが加えれば、データ連携の機械化・自動化の範囲は無限に拡がるといっても過言ではないでしょう。（個人の感想です）

先のトピック：RPAを導入しても成果が出せない組織がはき違えている「生産性」というマジックワードから引用します。

特に、ETLツールと比較されることの多いEAIツールのように、接続先のアプリケーションごとにアダプター／コネクターと呼ばれるオプション導入が必要になる場合、そのコストは1オプションあたり数十万円要することが多いようです。（接続する業務アプリケーション＝アダプターの数が増えると、EAIツール本体よりオプション価格の方が高額になってしまうこともありえますね。）

それに対し、データ処理性能を優先するETLツールを補完するRPAツールという組み合わせであれば、1ライセンス：100万円程度のRPAツールでアプリケーションのフロントエンドからデータの授受を行うことができるようになるでしょうから、いつまで使い続けるかわからないアプリケーションごとにアダプター／コネクターのオプションを導入・廃棄するライフサイクルと比べれば、データ連携の自動化に要する TCO：Total Cost of Ownership を飛躍的に向上させることも可能になるでしょう。

公開事例はこちら

複雑な連動手順をマイクロサービス化する「Waha! Transformer REST Serverオプション」｜スガキコシステムズ株式会社 様

「Waha! Transformer」が持つ「REST Serverオプション」を利用すれば、クライアントPC上のAccess Runtimeにて柔軟に条件を指定することで、利用者自身で条件を設定し必要な情報が抽出できるようになります。「ETL側にバッチ処理をゆだねることで必要な情報抽出が迅速になるだけでなく、抽出件数が事前にわかるため、利用者側にとっても使いやすい環境が整備できると考えたのです」と佐橋氏は語ります。

このような経緯で、Access Runtime上で条件を入力して必要な情報がExcel帳票で出力できる調査ツールの環境として、「REST Serverオプション」が採用されたのです。

柔軟な帳票出力を実現するための基盤として採用された「Waha! Transformer」｜株式会社オーカワパン 様

Webサービス利用者が帳票出力依頼を行うと、「Waha! Transformer REST Serverオプション」を介したAPI連携によってリスクエストを受け取り、DB読み込み・書き込みオプションを経由してRDBと連携。最終的には「Spread Sheet Adapter for Excelオプション」によって必要な情報が記載されたExcel帳票を生成してWebサーバーからダウンロードできるようになります。他にも、Excelで作成された工程表や外部システム内にある出退勤データなどをWebサービスへ取り組む際にも「Waha! Transformer」が活用されており、現在は25ほどのジョブを作成・運用しています。

ブログサイトの関連記事

• 巨大な一元管理システムではなく、データがシームレスに連携できればよいはず
• 基幹系システムと基幹システムの違いとは？情報系システムとは？
• わりと知られていない「レガシーIT人材」≦「デジタル人材」

参考ニュース

AWS、「AWS Mainframe Modernization」を発表 | AWS

AWS Mainframe Modernization は、検討、分析、移行、テストの各フェーズが自動化され、お客様とシステムインテグレーターに、リプラットフォームおよびリファクタリングされたメインフレームワークロードをデプロイするためのマネージドなランタイム環境を提供します。これにより、アプリケーションのモダナイゼーションを迅速かつ容易に行うことが可能となります」

「金融×DX」のアクセル、API連携によるモダナイゼーション | DATA INSIGHT | NTTデータ

アプリケーションモダナイゼーションとは、守るべきIT資産と思い切って作り変えるIT資産を切り分け、優先度とコストを勘案して現実的な落とし所を目標に、段階的にDXのあゆみを進めていくことです。

IBM i市場でのAPI普及を狙い、「APIコンソーシアム-IBM i」が発足　～APIユースケースの発信や情報提供に注力 - アイマガジン｜i Magazine｜IS magazine

活動内容としては、IBM iユーザーによるAPI活用のユースケース紹介、Webinerやセミナー・勉強会などのイベントを通じた情報発信、会員間の協業推進などを予定しており、2022年は活動を本格化させていく。 API活用は技術面の情報に加えて、自社の基幹データをどのように利用していくかの企画力・発想力・構想力が重要となるため、同コンソーシアムではその足掛かりとなる多彩な情報提供や活動に注力していくとのことだ。

• LINEで送る
• ツイート
• 

関連コンテンツ