Web API に対する過度な期待
「Salesforce にはAPI があって、外部連携ができる。Cybozu kintone にもAPI があって外部連携ができる。じゃあ、Salesforce – kintone 連携は簡単にできるでしょう。」という期待をよく聞きます。特に非エンジニアのマネジメントの中にはそのような理解の方が多いように見受けられます。これは、Salesforceやkintone に限ったことではなく、クラウドサービス全体の話です。また、「弊社のサービスのAPI を公開しました。これであらゆる外部サービスと弊社サービスの連携が可能になります。」という発表を見ることもあります。現実はそう簡単ではありません。特色のあるクラウドサービスを組み合わせてマイクロサービス的に使うという夢は、なぜかあまり実現できておらず、企業データはいっそうサイロ化してしまっています。
これらのクラウドサービス（SaaS）同士のデータ連携についての過度な期待は、クラウドサービスはサービスであり、外部サービスを呼び出したり、処理、ロードしたりするような機能が実装されていない、ということを見逃しているためです。
現時点では、多くのクラウドサービスへの連携に対応するETL/EAI を使う、もしくはカスタムの中継アプリを使うという方法が考えられます。また、クラウドサービスの中には関連する他のクラウドサービスに連携する機能を提供するものも出始めています。
この記事では、「データ連携」というビッグワードをパターン分けして、どんな実現方法があるのかを考えてみます。
ETL を使った連携
ETL は、連携元データの取得、データ変換、クレンジング、マッピングなどの加工・処理、連携先へのデータのロードの3つの機能をそろえています。相手がクラウドサービスであれ、カスタムアプリやRDB、CSV・Excel などのファイルであれ、ETL がデータソースへの対応をしていれば、ETL ツールが連携のすべてを行ってくれます。正に「データ連携のためのツール」です。
基幹系の連携や多数のデータソースが関係するような複雑な連携にはETL による連携が今後も主流となると思われます。
アプリケーション/ツールからの直接連携
ETL は基幹系などの主要な連携を担う場合が多いわけですが、「1サーバー数百万円と価格が高くなりがちで安価なクラウドサービスを連携するのに、ETL ツールの導入費用がクラウドサービスの料金を簡単に上回ってしまう」という声を聴きます。特にSME では価格がネックとなり導入ができていない企業も多いと思います。SaaS データをExcel で手元で使ったり、セルフサービスBI ツールを使ったり、自分の連絡先や予定をシンプルに同期したい、というニーズにはETL ツールを使わずにBI、帳票、DWHなどのツール、カスタムアプリ、Access・Excel などのOffice ツールから直接データ連携を行うことも可能です。カスタムアプリケーションや、多くのツールは主要なRDB およびファイルデータを直接取得する機能が備わっています。ただし、クラウドサービスへの連携はそれぞれのWeb API を直接コーディングにより参照する必要があり、開発者の大きな負担となっています。パッケージツールなどではそもそもAPI コーディングでの連携機能実装がエンドユーザーにはできない作りのものも多いです。
そこで、CData Drivers がそれぞれのWeb API を元々アプリケーションやツールに備わっているODBC やJDBC などの標準インターフェースに変換することで、「取得」の機能を担い、ツール側が標準SQLにより「加工」を行うことを実現しています。
クラウドサービス間の連携
クラウドサービスは基本的には、ユニークな単一の機能を提供する為に開発・提供されています。この記事で説明しているように外部データとの連携には、取得・加工・ロードなどの複雑な機能が必要であり、ほとんどのサービスには外部データを自由に連携する機能がありません。そもそもサービスで使っているDB もロジックも外部からは触れない訳ですから、ユーザーのニーズに合わせたカスタムの連携機能開発を行うことは望めません。ここが多くの方に見逃されている不都合な事実です。Web API はデータ連携の為に存在するにもかかわらず、Web API だけでは、異なるクラウドサービス間の連携が行えないのです。
そこで、現在は主に3つの方法でクラウド間の連携が組まれています。ETL を使った連携、中継サーバー（アプリケーション）での連携、AWS Lambda やAzure Functions などのFaaS （Function as a Service）を使う方法です。
注意しなければならないことは、それぞれのツール・サービスがすべてのWeb API に対応している訳ではないという点です。RDB やファイル連携は主要なツールでは対応が当然でしたが、Web API は共通規格がないのでツール・サービスによって対応状況はまちまちです。「連携先の多様性」がツール選定の一番大きな要因になっているという調査結果が出ています。データ連携ツールで重要な「接続先の多様さ」
ツールベンダーおよびエンドユーザーのAPI 連携対応をサポートしているのがCData です。CData Drivers およびCData API Server はETL、カスタムアプリ（Java/C#/Python/PHP/C++/Delphi/Ruby etc.）、FaaS と併せて使うことができ、ユーザーの利便性を大きく向上しています。
それでもクラウドサービスのユーザーとしては、外部ツールを使わずにデータ連携ができることがUX としてはベストと考えるでしょう。すでに一部のクラウドサービスでは他のクラウドサービスのWeb API を使って、直接他のサービスを参照したり書き込んだりする機能を実装している例も出てきています。クラウドサービス内でのSNS と連携、カレンダー機能のGoogle やOffice 365 との同期、Box などのクラウドストレージ同期、CRM とERP・会計サービス連携などが例として挙げられます。今後このような流れは大きく加速すると考えられます。
ユーザーとして考えるべきこと
クラウドサービスのユーザーとしては、どのクラウドサービスがどのツール・開発環境・ほかのクラウドサービスと連携できるかを広く把握する必要があります。そしてコスト面やその業務上の性質（SoR/SoE など）から、最適な連携方法を選択できるようにすべきです。集中管理だけでなくマイクロサービス的な分散型のデータ連携も重要性を増すと思われます。
ツールベンダー・プラットフォーム側として考えるべきこと
増加するクラウドサービスへの幅広く迅速な連携対応は競争力となります。80を超えるCData Drivers のツールへのOEM 組込みによってクラウドサービス連携機能を飛躍させることができます。自社リソースでのAPI 連携は主要なAPI にとどめることを強く勧めています。データ連携の技術的負債をヘッジする
クラウドサービスベンダーが考えるべきこと
API を公開することはMUST です。API の公開による外部との連携機能の提供なしに、顧客満足度を保つことは難しいと言えます。逆に使いやすいAPI、つまり開発者に理解しやすく、各種ツールから利用しやすいWeb API を整えることができれば、より多くのユーザーを獲得できる大きな可能性があります。Web API には、OData やOpen API といった標準化の流れが出てきており、それを意識することも大事です。CData ではAPI Server により簡単に標準準拠のOpen API/OData API をノンコーディングで自動生成するツールを提供し、API 公開をサポートしています。さらに既存のAPI に対してもCData Drivers を開発することで、開発環境や主要なツールからシームレスにWeb API が使えるようになります。
このように、クラウドサービスの連携にはいろいろな方法があります。その中でCData Software は、Web API の標準インターフェース化により、エコシステム全体をサポートしています。
関連コンテンツ
