ノーコードアプリ開発は自己完結、ノーコードデータ連携は連携先と処理がある
「ノーコード」と聞くと、操作が簡単で専門知識がない人でも使えるというイメージがあります。これは、「ノーコードアプリ開発ツール」のイメージが強いからだと思います。kintone に代表されるノーコードアプリ開発ツール・サービスは確かに使いやすいです。専門的な知識をもたなくてもある程度実用に耐える業務アプリケーションを組んで運用することが可能です。
では、「ノーコードデータ連携ツール」はどうでしょう？実は私、メールシステムのContact 情報をCRM にノーコードツールでポチポチっと連携したら、既存のCRM のデータがメールアドレスを残して全部消えちゃった、という笑えない経験があります。CRM から成約案件データを会計システムにポチポチっとつないだら実行毎に同じデータが新しいデータとして登録され、売上が膨れ上がってぬか喜びしたこともあります。
ノーコードデータ連携では、基本的にノーコードだから簡単」という考え方は通用しません。データ連携はノーコードアプリ開発ツールのようにプラットフォーム内で完結しません。データ連携ですから多くの場合外部データを読み出したり、書き込んだり、アクションをトリガーしたりします。「外部への処理を定義する＝プログラミング」なんですね、コードを書かないだけで。たまたま処理が単純であれば、簡単に使えますし、処理が複雑であれば、難易度は高くなります。
この記事では、処理の種類ごとにデータ連携の難易度とツールを使うユーザーの注意すべき点を見ていきます。そう、私のように安易な連携で爆死しないように。
この記事はCData Software Advent Calendar 2020 - Qiita の3日目の記事です。
データ連携を種類に分けて難易度を考えてみよう
この記事では、データ連携を大きくイベントドリブン系とデータドリブン系、さらにそれを4つのカテゴリに分けて考えてみました。
データ連携の難易度
イベントドリブンとデータドリブンの分け方は、前に記事を書いていますので、細かくはこちらを参照してください：
https://www.cdata.com/jp/blog/2020-03-27-184900
1. イベントドリブンなデータ連携
1.1 アクション実行系のデータ連携
イベントドリブンでもアクション実行系は皆さんが思い浮かべるAPI 連携に近いものです。stripe で決済を実行する、Twilio で電話をかける、Sendgrid でメールを送る、Box にファイルをアップロードする、画像解析API にデータを投げて結果を返すなどのAPI 連携です。
1.2 通知系のデータ連携
イベントドリブンのもう一つの連携は通知系です。何かのトリガーが発生したら、Slack に通知する、メールを出す、Tweet する、などのデータ連携です。
イベントドリブン連携は比較的安心して使ってよい
これらのアクション実行や通知系のイベントドリブンなデータ連携は、処理自体は派手でかっこいいのですが、データ連携としてはシンプルです。連携はリアルタイム、実行は一つずつ、多くは1 インプット・1アウトプット、そしてステートレスです。言ってみれば点の操作です。
連携をプログラムからAPI コーディングで実装することも比較的簡単です。「タグ・スニペット」をコピーしてさっと連携できます。ノーコード連携ツールでの連携にも不安はありません。IFTTT やZapier などのレシピ型のiPaaS の最も得意な領域といえます。どんどんデータ連携・API 連携を試していきましょう。
データドリブンなデータ連携
難易度が高いのはデータドリブンな連携です。これらの連携はイベントドリブンが点だとすれば「面」のデータ連携です。レコード単位ではなく、業務アプリケーション・業務SaaS の裏にあるデータベースを意識した操作が必要になるからです。
Read Onlyなデータ連携
Tableau やPower BI などのBI ツールでSaaS でSaaS データを分析したい、Google BigQuery やSnowflake のようなDWH にデータをパイプラインしたい、アプリケーションから別のアプリケーションのデータをLookup して利用したい、このようなデータ連携はデータドリブンかつReadOnly な連携です。
このようなデータの読み出し連携の難しさは、使いたいデータがRDB ではない場合です。SaaS データの多くはAPI でJSON を返しますし、NoSQL データベースはデータの持ち方がテーブルではありません（非構造化データや半構造化データ）。一方、データを読んで使うBI、帳票、NoCode 開発ツール、DWH は構造化データであるリレーショナルなテーブルデータをSQL 言語で使うように設計されています。ということは、データ連携で大事な点は「SQL できるデータに加工してツールに渡すこと」と言えるでしょう。
BI ツールや帳票ツールのSaaS データ連携機能、DWH へのパイプラインツール、マーケティング用のデータを複数のSaaS から統合するCDP などはこのような構造化データへのデータ連携をノーコードで実現してくれます。ユーザー目線では、ReadOnly のデータ連携の価値はデータを連携した後の分析作業などのデータ活用にあります。データを連携することは只のコストであり価値はありません。であれば、このデータ連携作業をツールが担ってくれることには大きな価値があります。 心配せずにどんどんReadOnly 系のデータ連携を使って、人間の思考を必要とする分析作業に力を注ぎましょう。
敢えて言えば、ツール選定で気にするべき点は以下でしょうか：
データソース対応
パフォーマンス、差分更新できるか
データ取得時にカスタムSQL が書けるか
デバッグ（実行ログを取得・解析）できるか
更新を行うデータ連携
データ連携で一番難しいものは更新を行うデータ連携です。Sansan のデータをSalesforce などのCRM に書き込む、Dynamics CRM のデータをPCA 会計などの会計ツールに書き込む、異なるSaaS 間で顧客マスターや商品マスターを同期する、といったアプリケーション間連携は更新を伴うデータ連携です。
なぜ難しいか？データの更新は大変センシティブな処理だからです。データの書き込みは新規レコードの挿入だけではありません。連携先のデータに同じレコードがあった場合、既存データを更新するのか、どのカラムまでを更新するのか、どうやって「同じレコード」だと判断するのか、データによって別のプロセスを流す必要があるのか、などといった基本的なところだけでもロジックが必要なことがわかるでしょう。目で確認してのコピー＆ペーストではないので、自動化ツールでは設定を間違うと広範囲に影響がある失敗がおきます。
RDB ではなくSaaS やNoSQL データの/への更新を行うデータ連携をさらに難しくする要因に、データモデル・リレーションシップを把握しずらく、それではちょっとした追加・更新もできない点もあります。マスター無くしてトランザクションは追加できず。ヘッダーなくディテイルは作成できずと。RDB時代はER図という地図がありましたが、アプリケーションがSaaS となり、良くてインタフェース仕様（API仕様書）、さらに前述のノーコードアプリ開発のSaaSだとデータモデルも自由に作成できる、スキーマレスの便利さはデータ連携での難しさの裏返しになります。
データ更新はロジックでありプログラミングです、ノーコードであっても
レシピ型のツールの場合には、ツール提供者側がドメイン知識を持って、サービスを提供する必要があります。データを右から左に流すだけではなく、連携シナリオの落とし穴をしっかりと埋めてくれるレシピ型のツールには大きな価値があります。一方、自由にマッピングを行うタイプのノーコード連携ツールの場合は、ユーザーが「これはプログラミングなんだ。」という意識を持って使うことが必要です。ツールは使いやすくても、その実行ボタンを押していいかの判断はロジックを理解しないとできません。 知識がなければノーコードツールであってもデータ連携に強いSIer に依頼することが正解かもしれません。
最後にCData は何をしてくれるの？
CData を活かせる連携はデータドリブンな連携です。ほぼすべてのデータ系のノーコードツール・サービスでCData Drivers を使って、200を超えるSaaS やNoSQL データをシームレスにつなぐことが可能です。
これができるのはノーコードデータ連携ツールを支えているのはSQL だからです（記事は以下を参照してください）：
https://www.cdata.com/jp/blog/2019-11-15-130300
そして、iPaaS、ノーコードで使えるETL/EAI ツールでもCData Drivers を使って、接続できるSaaS を拡張することが可能です。SaaS データへのアクセスインターフェースをJDBC やODBC に統一することでツール側でデータを扱いやすくなります。ただし、CData Drivers は、インターフェースを統一することはできても、ロジックは作れません。ロジック部分、特に更新系のデータ連携操作は、やはり、ツールベンダーかエンドユーザーかSIer かの誰かがロジックの実装を担わなければなりません。では、データ処理の種類ごとに難易度を理解して、楽しいデータ連携ライフを！
関連コンテンツ
