TOPICS
DXレポートで示された「最大12兆円/年の経済損失」に懐疑的なITマネージャーに贈ります！
本トピックは、withコロナ収束間近と言われる2021年12月に公開しました。
当サイト好例の質問からで恐縮です。
皆さんが所属されている組織では、「DX〇〇」といった言葉やテキストが、どれぐらい飛び交っているでしょうか？
「少なくとも義務教育で3年以上英語を学んでいるはずなのに英語ができない」と卑下される私たちでも、「DX」がデジタル＋トランスフォーメーションを組み合わせた造語であることぐらいはわかるのですが、実はその「デジタル」も「トランスフォーメーション」も、その文脈を単語単位でさえ理解できていなかったりしませんでしょうか？
なぜ、このような問いを思いついたのか、
そのトリガーは、IPA：独立行政法人情報処理推進機構から2021年10月に発刊された「DX白書2021」を拝読して、たびたび登場する「DX戦略」なるフレーズに違和感が浮かんでしまったからに他なりません。
21世紀に使われる「デジタル：digital」については、それ以前まであった「アナログに対する電子化・デジタル化」からバージョンアップし、「デジタライゼーション」と呼ばれるようにインターネットをベースとしたテクノロジー文脈であることは概ね外れていないと思われます。
もう一つの「トランスフォーメーション：transformation」は直訳すれば「変身・変形」ですが、ビジネス用語として使うときは「ビジネス（価値交換）プロセスの変革」を示していると解釈しており、その上位には「（ビジネスの）成長戦略」があるのでしょうから、これまで当サイトでは「DX」を目的ではなく戦術レイヤーにおける選択肢の一つにすぎないものと位置付けてきました。
そう考えた場合、「頭痛が痛い」ではないですが、「DX戦略」では「戦術戦略」となってしまう日本語に違和感を感じられる方が少なくないことを願ってやみません。
本トピックは、当サイトの人気コンテンツ「CIO・情報システム部門のミッション考察」および「ERP移行・基幹系システムの再構築を成功させる5つのステップ」と続いた3部作の最終章として、「戦略：strategy」の下位にあるDXという「戦術：tactics」、さらにその下位にある「戦法：methods」という身近なところから、「APIエコノミー」をキーワードとして皆さんに未来への希望をお持ちいただくべく寄稿いたします。
ERP：基幹系システム刷新時のデータ移行「17のあるあるをチェック！」セミナー
本セミナーでは、新旧システムのデータ移行に関連して見過ごされがちな「あるあるチェックリスト」をご提供し、チェック項目ごとに具体的にどのような対策が有効なのか、わかりやすく具体的にお伝えします。
これは筆者の周辺で、某銀行や某教育産業に従事する知人から聞いた観測範囲の狭い話しではありますが、共通していたのは「メインフレーム／ホストコンピューター（汎用機）は捨てていない」ということでした。
専門家ではない彼ら・彼女らの話しを裏取りしてみると概ね下記のような状況のようで、結論としては「（大騒ぎするような）崖などそもそもないらしい」ということでした。
このような風潮・トレンドは、SDGs：Sustainable Development Goals の一環というわけではないのでしょうけれども、大量生産・大量消費・大量廃棄の時代には考えもしなかった「使い切る」エコシステムが拡がっているのでしょうか。
2018年の「DXレポート」で「最大12兆円/年の経済損失が生じる可能性！」と警鐘が鳴らされた問題の現状は、蓋を開けてみればそれ以前から計画されていた新システムへの移行の過程で、コスパ高く・賢く・華麗にスルーされていることがよくわかりました。
脊髄反射せずによく考えてみれば当然の話しですが、例えば我が国が世界に誇るスーパーコンピューターもハードウェアとソフトウェアで構成されているわけで、相手がモノである以上当然のこととして寿命はあり、全体をゴソッと入れ替えるのかパーツの入れ替えやアプリケーション・モダナイゼーションなどの手法で延命できるのかは、適切なタイミングで最も費用対効果の高い方法を選択すればよいわけですね。
筆者が「DXレポート」の中で良心として読み取ったのは「データ活用ができない場合、」という、問題の本質への言及がきちんとされていたところです。
情報システムで重要なのは「ハコモノ」ではなく「中身：データ」のはずであり、ハードウェアや業務アプリケーションは「ハコ」ですから寿命に応じて更新し続ける必要があります。
例えば決算や取引データのように一度確定したデータはそのまま保持し続けることができなければいけませんし、電子帳簿保存法のような法制もそのために改正されたと捉える必要があるはずです。
ここで一つ、「システム障害」によって「データ活用できない場合」を、影響範囲が広くて深そうな商業銀行を例に想像してみましょう。
メガバンクや地銀と呼ばれる国内の商業銀行は、日銀からの借り入れや預金を原資に、主に融資する際の利率との差額を利益として事業が運営されてきましたが、もし仮に融資先や融資残高のデータが消滅したり誤って記録されるなど、データを正しく活用できなくなってしまったら何が起きるでしょう？
まじめで几帳面な融資先は期日通りに返済してくれるでしょうけど、うっかりさんな融資先は返済期日を忘れたり、引き落とし口座の残高不足が発生してしまうかもしれません。さらに、融資担当者は紙ファイルで持っていた最新ではない融資データをもとに融資先にコンタクトしてしまうことで、最新の正確なデータを持っていないことが顧客に露呈してしまい、信用失墜につながってしまうことでしょう。
そうなれば金融庁による業務改善命令どころではなく、収入がなくなって支出するだけの事業体に残された道は破産・倒産しかありませんし、そのような基幹データを紛失・誤用してしまう事業者であれば、事業再生の道も閉ざされてしまうのではないでしょうか。
筆者が「2025年の崖」で示して欲しかったのはこのような例示であり、銀行の勘定系システムに代表されるメインフレーム：巨大な一元管理システムにすべてのデータが集約されているのであれば、BCP：事業継続計画の観点からそれこそが大問題ということではないでしょうか？
預金や融資のように事業の根幹を支える基幹データは、それぞれの業務フローに最適化されたアプリケーションとデータベースで運用し、勘定系のような基幹システムでは各業務アプリケーションと必要なデータを受け渡しするなどしてリスク分散をはかるのが、そもそもの金融業の得意なところであり、私たちのモデルとなってくれるはずではないでしょうか。
先に紹介した知人に一元管理か分散管理かといった辺りも聞いてみたのですが、彼ら・彼女らは情報システム部門に属しているわけではないので、詳しいところまでわかりませんでした。
しかしながらさすがは著名企業、IT関連メディアに各社とも「API連携」を推進・分散管理している状況がお披露目されていました。
API：Application Programming Interface と聞くと「気象庁の天候データ」のようにオープンデータやインターネット経由のデータ受け渡しを思い浮かべる方がいるかもしれません。
ところが、長年にわたってソフトウェア開発に従事している方々にとって「Windows API」などは慣れ親しんだものでしょうし、クラウドシフトが進んだ令和の時代にあっては、企業や官公庁で使われるような業務アプリケーションも、システム間のデータ連携手段として API に対応しているものが増えてきましたし、API で直接アクセスできない場合も、別建てで API サーバーを構築できるような製品・サービスも登場しています。
さらに、金融DXといった文脈で注目される「ブロックチェーン」も大きくとらえれば API の一種とも言われていますから、テクノロジーの知見を得る意味からも、APIエコノミーの住人になっておくことにはメリットがありそうです。
「DX」という戦術論に踊らされることなく、「2025年の崖」をヒントにした戦法のレイヤーの中心に「一元管理システムからの脱却」や「API 経由で連携する分散システム」を据えることで、ビジネス現場主導のトランスフォーメーションにも柔軟対応できるようにすることを、「DX推進」の前提に位置付けていただくのがよいのではないでしょうか？
商品名の transformer は直訳の変圧器・変成器やAI分野で著名な深層学習モデルというより、データ変換・加工装置とご理解ください。
1999年のリリース以来、類似製品が提供する SDK：Software Development Kit（ソフトウェア開発キット）のようにアプリケーション仕様の改変・拡張によって保守サポート範囲を狭めてしまうような機能提供は行ってきませんでした。
その理由は、データ連携の処理性能を最重要と位置付けていたためであり、カスタマイズされるべきは汎用性のあるデータ連携先の拡充にあると考えていたためです。
そのような提供方針の元、前述のようなトレンドを受け、リリース20周年を迎えた2019年に「REST：Representational State Transfer API」によるデータ連携オプションを開発・提供開始しました。
さらにその翌年には、Waha! Transformer で作成したデータ処理設定を、WebブラウザからAPI経由で手動実行できるオプションも開発・提供開始しています。
情報システムのご利用環境やデータ連携対象となる業務アプリケーションのクラウドシフトが進む中、少なくとも「2025年の崖」を迎える前に、Waha! Transformer も「APIエコノミーの住人」になったわけです。
これにより Waha! Transformer のデータ連携先は一気に拡大しました。
さらに、DB読み書きオプションと同様、接続先が増えるたびにオプション課金が積み重なっていく類似製品のような提供方式はとらず、機能としてのオプションを導入していただくだけで接続先のサーバー数といった制限は設けていませんから、ご利用範囲が拡張するたびにROI：投資対効果も向上していくという好循環サイクルで運用していただけるようになっています。
その結果、例えば「2025年の崖」に隠された問題でもある「業務アプリケーションがシステム間でデータ連携するためのアドオン開発やカスタマイズ」といったように、負の遺産となることが目に見えている部分最適・サイロの象徴を、ゼロにはできなくても相当量削減していただくことでお役に立てると考えています。
組織内外のデータを連携させる基盤としての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オプション」を利用すれば、クライアントPC上のAccess Runtimeにて柔軟に条件を指定することで、利用者自身で条件を設定し必要な情報が抽出できるようになります。「ETL側にバッチ処理をゆだねることで必要な情報抽出が迅速になるだけでなく、抽出件数が事前にわかるため、利用者側にとっても使いやすい環境が整備できると考えたのです」と佐橋氏は語ります。
このような経緯で、Access Runtime上で条件を入力して必要な情報がExcel帳票で出力できる調査ツールの環境として、「REST Serverオプション」が採用されたのです。
Webサービス利用者が帳票出力依頼を行うと、「Waha! Transformer REST Serverオプション」を介したAPI連携によってリスクエストを受け取り、DB読み込み・書き込みオプションを経由してRDBと連携。最終的には「Spread Sheet Adapter for Excelオプション」によって必要な情報が記載されたExcel帳票を生成してWebサーバーからダウンロードできるようになります。他にも、Excelで作成された工程表や外部システム内にある出退勤データなどをWebサービスへ取り組む際にも「Waha! Transformer」が活用されており、現在は25ほどのジョブを作成・運用しています。
ETL：データ連携ツール比較表（RFP添付用）
1999年にWaha! Transformerの提供を開始して以来、ETL：データ連携ツールの導入を検討されている数多くのお客様からRFIやRFPをご提示していただきご回答してまいりました。
その内容を整理・再編して、複数の製品・サービスの比較表としてご利用いただけるシートをご用意しましたので、ETL：データ連携ツールを比較・検討していただく際のお役に立てれば幸いです。
ERP：基幹系システム刷新時のデータ移行「17のあるあるをチェック！」セミナー
本セミナーでは、新旧システムのデータ移行に関連して見過ごされがちな「あるあるチェックリスト」をご提供し、チェック項目ごとに具体的にどのような対策が有効なのか、わかりやすく具体的にお伝えします。
【アーカイブ配信】今さら聞けない「EDI 2024年問題」の傾向と対策
ユニリタ × インテック共催 ～ EDI × ETLセミナー ～
本セミナーでは、EDI：データ交換システムの歴史から2024年問題を紐解きながら、通信回線の移行に留まらない円滑なデータ交換および社内情報システムにおけるシステム間データ連携に向けた問題解決の道筋についてご紹介いたします。
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活用は技術面の情報に加えて、自社の基幹データをどのように利用していくかの企画力・発想力・構想力が重要となるため、同コンソーシアムではその足掛かりとなる多彩な情報提供や活動に注力していくとのことだ。
社内のデータ活用でお悩みの方は
お気軽にご相談ください。
