DXのためのアプリケーション 基幹系システムのデータを活用できるかが鍵に
DXに資するモダンなアプリケーション開発においては、単にSoE（System of Engagement）のデータだけがあれば良いわけではなく、顧客体験の向上を実現するためには、基幹系システムのデータをいかに活用できるかが鍵となる。とはいえ、レガシーシステムは、他のシステムと柔軟に連携できるようなアーキテクチャではないことが一般的だ。この課題を解決するためには、レガシーシステムとのAPIを容易に開発できるだけでなく、安全に運用するための仕組みが必要となってくる。
「日々、ひたすらAPIを触っています。日本国内で一番数多くのAPIを触っている人間だと思います」と話すのは、CData Software Japan（以下、CData）で国内外のAPI連携パートナーの開拓、APIコネクタの開発に携わっている同社リードエンジニアの杉本和也氏。実際、CDataでは270ほどのAPIコネクタを作成しており、杉本氏はそれらのサポートサービスを提供できるレベルでAPIを熟知している。
たとえば、国内で流通しているSaaSを集めた業界レポートに掲載されていた600種類以上のサービスをくまなく調査。一つひとつAPIが公開されているか、公開されているAPIの仕様や連携のしやすさ、認証方法、リファレンスの有無に至るまで詳細に調査しているというから驚きだ。
最近では、電気自動車のテスラに搭載されているAPIが気になり「当初は少し楽しめればという軽い気持ちでテスラのモックアップAPIを作りましたが、いざ作ってみると本番環境が欲しくなり、結局買ってしまいました」と杉本氏。ちなみにCDataでは、テスラに接続できるAPIコネクタは残念ながらまだ用意されていないが、将来的にビジネスニーズが高まれば電気自動車と接続するAPIコネクタも提供されるかもしれない。その際には、この経験も遺憾なく発揮されることになるだろう。
そんな杉本氏が日々さまざまなAPIに触れている中で感じているのは、レガシーな基幹系システムに格納されているデータの重要性だ。DX実現に向けて、顧客体験を向上させるためのアプリケーションを構築しようとする企業が多い中、SNSのデータや画像、映像などの非構造化データを活用するだけでは十分でない。何よりもレガシーシステムのデータを活用すること自体が容易ではない現実も目の当たりにしているからだ。
「企業はノーコード／ローコードツールなどを使い、アプリケーションをどんどん作っています。しかしながら、現場メンバーの使いたいツールから欲しいデータへすぐにアクセスできず、頭を抱えているケースは珍しくありません」と杉本氏。たとえば、SaaSであればAPIが用意されていてデータが取得できることも多いが、サービスごとにAPIの仕様が異なり、“欲しい形”で容易にデータを取得できるとは限らない。
より問題なのが、企業が利用しているレガシーな基幹系システムだ。たとえば、顧客にECサイトなどで商品を購買してもらうためには、商品の詳細情報が必要となる。しかしながら、最新の商品マスタなどは、独自開発した生産管理システムに入っているかもしれない。また、購入した商品の正確な納期を顧客に伝えるためには、在庫管理や販売管理の最新情報を参照する必要もある。商品購入後のサポートサービスならば、顧客が過去に購入した商品情報はもちろん、顧客との契約情報など、基幹系の各システムにあるトランザクションデータが欠かせない。
杉本氏は、「顧客体験を向上するためにアプリケーションを構築しようとすると、商品や顧客などのマスターデータ、購買の情報、見積り、請求などのトランザクションデータが必要です。それらは、まだまだレガシーシステムにあることが現実です」と説明。レガシーシステムにあるデータを用いて新たなアプリケーションを構築したいが、そのための環境が整っていないことがDXの阻害要因になっていると指摘する。
自社で独自開発したシステムはもちろん、長くオンプレミスで使ってきたパッケージシステムにおいても、APIなどのデータ連携用インターフェイスがない。また、レガシーシステムの多くは十分なドキュメントなどもなく、構築した担当者も既にいないケースも多々あるだろう。つまり、多くの企業でシステムがブラックボックス化していて簡単に触れない。「そもそも、どのようなデータ構造なのかを把握している人もいません」とも杉本氏は言う。
当然ながら、そのようなレガシーな基幹システムを解析し、データ連携のためにAPIを構築することは困難だ。API開発で考慮しなければいけないエレメント（エンドポイント設計・セキュリティ管理・ドキュメントなど）が数多く存在することはもちろん、そもそもIT部門は慢性的な人手不足で、アプリケーションを作りたいというビジネス部門からの要求にタイムリーに応えることも難しいだろう。「基幹系システムからデータをCSVファイルで抽出してもらおうとIT部門に依頼すると、数週間から数ヶ月かかることもあります」と杉本氏。
もちろん、予算を獲得して、レガシーシステムにアクセスするためのAPI開発プロジェクトが始動するケースもある。多くの場合、「汎用性の高いAPIを構築しよう」と考え、しっかりとレガシーシステムを解析し、幅広い要求に応えられるように詳細設計を行う。そして、API構築のプロジェクトはどんどん拡大していき、アプリケーションへとタイムリーに必要なデータを渡していく……しかしながら、そうした本来の目的から外れてしまい、いつの間にか“完成度の高いAPIを作ること”が目的となり、大きな手間とコストをかけて必要のないAPIを作ってしまうケースは少なくないという。
では、そもそも必要なデータの取得だけならば、ETLツールでも良いのではないかと考えるかもしれない。ETLツールを使えば、データを取得・加工してアプリケーションに渡すことは可能だ。しかしながら、多くの場合はレガシーシステムからバッチ処理によってデータを抽出・加工するため、リアルタイムに情報を渡すことが難しい。さらに加工したデータはCSVファイルなどでアプリケーションに渡すため複製され、それのデータに対してアクセスコントロールなど、データガバナンスを効かせることも容易ではないだろう。取得データのセキュリティとガバナンスの担保は、APIの独自実装においても課題視されており、実現には相当の手間が発生する。
