iPaaS が注目されています。
エンタープライズで増え続けるSaaS 利用。しかしSaaS データはサイロ化しデータの統合利用がますます困難になっています。DX 実現のためにはSaaS データを手軽に統合利用するサービスであるiPaaS は今後成長するソフトウェアサービス分野でしょう。
ただし、iPaaS ユーザーは低価格、豊富な連携先、ユーザーに知識が不要、フレキシビリティ（柔軟性・カスタマイズ）というトレードオフな要望を持っています。これに応えようとすると、iPaaS ベンダーは開発すればするほどジリ貧という状況に陥ります。サービス拡大期に入る前に、スケールするアーキテクチャやビジネスモデルを整えましょう。
この記事はiPaaS ユーザーではなく、iPaaS ベンダー向け記事です。とはいえ、SaaS ベンダーや他のソフトウェアベンダーでも「SaaS データ連携機能をサービス内に内包する」ということをしている場合は同じ問題を抱えています。
また、高機能高価格系のiPaaS はありますが、そちらの方々にはこの記事の話は既出のトピックですのでニヤニヤと余裕をもってお読みください。
iPaaS のユーザーおよびKBF
iPaaS に大きな期待をしているユーザーとはどのようなユーザーでしょうか？
現在の「クラウド連携の民主化」というトレンドとして語られているiPaaS のユーザー層は、高機能EAI ツールを未導入の先だと思います。現在の日本の企業のEAI 導入率が30-40% と言われていますので、EAI 未導入の60-70% がクラウドデータ連携市場に入ってくるダイナミックな流れです。
iPaaS のターゲットユーザー
中堅中小規模のサービス業や成長中のIT 企業
多くSaaS を使っている
生産性向上に対する意識は高く、自動化が好き
高価なEAI ツールを導入していない
SaaS 連携はコストを抑えたい（多くて月数万？）
Key Buying Factors（KBFs）
これらの企業がiPaaS のユーザーとなる際のKBFs は以下。
KBF をもう少しくだけた言葉でいうと
ユーザーさんは「安くて、API やデータ連携の知識がなくても使えて、でもカスタムオブジェクトや個別のユースケースにもフレキシブルに対応して、でも自分では操作はできないんですが、ちゃんと安定して動いてほしいです。iPaaS ならできますよね？」
ユーザーさん、無理を言わないでください！ それはその価格ではできません。
iPaaS が万能ではない事情
サポート先SaaS はLong Tailで、対応先増加でジリ貧に
ユーザーが利用するSaaS は増加しています。US では中堅中小規模の企業が平均20個のSaaS を使っているそうです。日本でも遅かれ速かれそういった数になることは間違いありません。
SaaS でもCRM やグループウェアのような多くのユーザーが同様のオペレーションを行うものはユーザー基盤が大きいです。Salesforce、Dynamics、G suite、SharePoint、Marketo などです。これらのサービスへの対応は作れば利用するユーザーが多いのである程度のROI が期待できます。
一方、現在増加しているSaaS は、上記の先行するSaaS の後発組か、機能に特化したものが主流です。決済機能、メール、電話、電子契約などの細かい業務に特化しています。各業態に圧倒的なシェアを持つサービスがなく、多くのSaaS ベンダーがしのぎを削っています。また傾向としては後発もしくは機能特化のSaaS はサブスクリプション単価が低いです。1企業の月々のサブスクリプション費用が数千円～数万円というものが主流です。
これらの低価格の数十～数百のSaaS への連携対応は大変開発コストがかかります。多くの連携先に対応すればするほど、対応したサービスを実際に利用するユーザーは少なく、データ連携に支払える対価も小さいため、ROI が下がってしまいます。
SaaS のAPI への連携実装は再現性が少ないことがこの問題を深刻にしています。それぞれのSaaS のAPI 仕様が大幅に異なるため、Salesforce のAPI 連携を実装したからといって、次にNetSuite のAPI 連携を実現する際にコードの再利用をして二回目以降の実装を効率化するという効果は限定的です。連携先を増やせば増やすほど、開発コストが比例して増加してしまいます。
「定型だから低価格」、なのにフレキシブルさを求める？
また、iPaaS が低価格でサービスを提供できるビジネス的な背景には、「開発したデータ連携シナリオが定型」だという点があります。iPaaS ベンダーは、レシピのように定型化された連携を一度開発し、多くのユーザーに使ってもらえるので低価格でも開発費を回収できます。
チャット、メール、SNS、クラウドストレージとの連携などは比較的定型化しやすいものです。次にCRM や会計でも「デフォルトのオブジェクトをそのまま使う」という連携であれば、ある程度、連携レシピを定型化することができます。
ところが、多くのSaaS では、オブジェクトをユーザーがカスタマイズして増やすことできるようになっています。Salesforce しかり、Dynamics 365しかりです。kintone などは元々自分で自由にアプリを作る仕様です。同じSaaS を使っているユーザーが言う「顧客データ」といっても、連携したいデータ・エンドポイントは全然異なるということです。NoSQL などはそもそもスキーマがないことが前提のものもあります。
ところが、そんなことはユーザーの知ったことではありません。ユーザーからすれば、「それぐらいiPaaS でフレキシブルにやってくれよ」です。
iPaaS ベンダーとしては、ユーザーのニーズに応えるために定型をくずし、下手をするとユーザーのフレキシブルさを求める案件毎にバックエンドでAPI 連携プログラミングを行う羽目になってしまいます。これでは個々の案件に開発費用が発生してしまい、定型の連携レシピを一度開発して多くのユーザーに売って回収する、というビジネスプランがくずれてしまいます。
iPaaS ベンダーがとるべき対策オプション
これらの問題をビジネスモデル、もしくはアーキテクチャによって乗り越えない限りiPaaS をさらにスケールすることは難しいのではないでしょうか？対応するための方法を考えてみます。
1. Long Tail な接続先SaaS を追わずに、ターゲットを絞る
「顧客データ」にだけフォーカスしたiPaaS、「会計データ」にフォーカスしたiPaaS などです。対応するSaaS 数を絞る、もしくはSaaS 数は多くても対応するオブジェクトの種類を絞ることによって、開発チームにドメイン知識をため込むことにより、レシピ開発コストを下げる戦略です。また営業・マーケティングもドメインを絞っている分、訴求力が高くなります。
去年の秋に買収されたpiesync は、顧客情報にターゲットを絞っている例です。
国内のActRecipe は、財務会計領域特化をうたっています。
2. サービスとして高価格で提供
大規模ユーザーの複雑なニーズに特化し、SAP、NetSuite、Marketo 連携、レガシーな基幹システムとのなど高いインテグレーション手数料が期待できる分野に特化する方法もあります。レシピ型ではなく、インテグレーションを含めたiPaaS です。
ユーザーにしてみればプラットフォームとしてのiPaaS であるか、インテグレーションサービスを含むかはあまり問題になりません。高価格帯のSaaS に価値の高いインテグレーションを行うことで単価の高いサービスとして成立します。
Salesforce、NetSuite、Marketo の専業のインテグレータの提供するサービスはこのビジネスモデルです。
3. 連携開発の効率化（データモデル、クエリなどの共通化）によるコスト低減
連携先Saas をガンガン増やしてがぶり四つでビジネスをする場合、メタデータの動的取得、共通データモデル、共通クエリを内部で実装し、レシピ開発のコストを圧倒的に下げる戦略があります。また共通化ができていると、連携レシピを完全に定型にせず、フレキシブルなオブジェクトの選択、マッピング操作をユーザーにセルフで行わせることができるようになります。
共通化によるコストダウンができれば、低価格で使い勝手のよいiPaaS を継続して提供可能です。共通基盤があればエンドユーザーの皆様にレシピを作ってもらって共有してもらってコミュニティで再利用するような方法も可能でしょう。
マイクロソフト社のPower Automate やLogic Flow はこのような共通化を行っていると見え、コネクタ数の充実、高い利便性と低コストを実現しています。
ただし、このフレキシブルな操作をユーザーに行わせることはリスクをはらみます。「本当にそのオブジェクトを上書きしていいのか？」の判断がユーザーにできるでしょうか？意図しないデータの更新や喪失のリスクのあるアクションを行っているという意識がユーザーにも必要です。となるとiPaaS ユーザーでもアッパー層を狙う形に自然となるでしょう。
CData Software OEM が提供するデータ連携の標準化
CData Software では、クラウドデータ連携の標準化を実現するソフトウェアを提供しています。CData の標準ドライバーは世界中のETL、BI ツールベンダーに加え、iPaaS 企業にOEM 利用されています。
200 種類以上のSaaS に接続できるCData Drivers のOEM では、クラウドデータ連携に必要な以下の要素を提供します。
テーブル型データモデルへの標準化
CData では、すべてのSaaS API データをRDB に仮想化し、リレーショナルなテーブル・ビューとして、データ型などのスキーマ定義を付与されて表現されます。カスタムオブジェクトについても動的にメタデータ検出・テーブルへのモデル化を行います。Salesforce、kintone、SharePoint などの連携を簡単にします。さらにNoSQL データベースのMongoDB やDynamoDB などのスキーマレスなデータストアでも行スキャンを行い、適切なテーブル構造・メタデータを推定する機能を持っています。
SQL クエリへの共通化
CData Drivers では、ANSI-92 のSQL をすべてのドライバーで対応しています。フィルタリング、ソートに加え、JOIN や、SQL 関数にも対応しています。クエリ方式を共通化することにより、データのフィルタリングや挿入・更新処理をデータソース毎に実装する必要がありません。
これらの共通化により、レシピ開発工数を減らすだけでなく、エンドユーザーがセルフで操作するエンドポイント選択、カスタムマッピングを行う機能の実装が容易になります。
認証レイヤーの統一
認証は、Basic 認証、トークン認証、OAuth、証明書付きなど多様な認証をすべて接続プロパティレイヤーで設定・操作が可能になっています。
標準ドライバーインターフェース
JDBC、ODBC、ADO.NET といった標準インターフェースでドライバー化されています。
これによりiPaaS 内部では、汎用JDBC、ODBC、ADO.NET というインターフェースに対応するだけで、200 を超えるデータソースに対応するドライバーを内包することが可能です。
iPaaS ベンダーの皆様には、データソース対応を進める前に「将来にわたりスケールできるアーキテクチャ」をCData Drivers のOEM によりご検討ください。
