
ノーコードアプリ開発は自己完結、ノーコードデータ連携は連携先と処理がある
「ノーコード」と聞くと、操作が簡単で専門知識がない人でも使えるというイメージがあります。これは、「ノーコードアプリ開発ツール」のイメージが強いからだと思います。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かの誰かがロジックの実装を担わなければなりません。では、データ処理の種類ごとに難易度を理解して、楽しいデータ連携ライフを!

コメント