「Integration 101」ブログシリーズの他の投稿もぜひご覧ください：
これまでの「Integration 101」ブログシリーズでは、統合の基本を取り上げ、APIやWebサービスにまつわる誤解を解いてきました。たとえば、それらが何なのか、そして何ができて何ができないのかといった点です。
そして、誤解といえば、「プッシュ」と「プル」に関して理解が難しい点があります。誰がプッシュして誰がプルしているのか？どのタイミングでプッシュすべきか、それともプルなのか？そして、それは本当に重要なのか？答えは重要です。しかも、想像以上に重要なのです。
この投稿では、以下の点について説明します：
- プッシュとプルの違い
- なぜその区別が重要なのか
- これらの用語を正しく理解していなかったことで、次の統合プロジェクトで予期せぬトラブルが起こらないようにする方法
統合プロジェクトにおけるコミュニケーションの重要性
私はこれまで、プッシュとプルという統合用語を混同して使用ことで、プロジェクトが破綻しかけた例を何度も見てきました。統合において情報を「プッシュ」するか「プル」するかによって、開発者に求められる作業範囲は大きく異なります。さらに、「自分情報をプルする」場合と「他者が自分から情報をプルする」場合でも、必要となる作業内容はまったく異なるのです。
ここで少し、以前APIについて書いたブログで用いたたとえ話である「郵便受け」と「郵便配達員」について思い出してみましょう。統合を成功させるためには、次の2つの要素が必要です。1つ目は「郵便受け」で、これは情報を入れたり取り出したりする場所です。2つ目は「郵便配達員」で、これは郵便を届けるサービスであり、情報を郵便受けに入れたり、そこから取り出したりします。
シンプルなAPIプロジェクト定義：プッシュとプル
情報をプッシュするとは、別のシステムに情報を送信することを意味します。つまり、「郵便受けに情報を入れる」イメージです。典型的な例としては、営業のコンタクト情報があります。リードジェネレーション（見込み客獲得）システムがコンタクト情報の送信を開始する場合、リード情報を生成元からSalesforceのようなCRM（顧客関係管理）システムにプッシュしていることになります。
情報をプルするとは、情報を取得することを意味します。上記と同様の例で言えば、CRM側がコンタクト情報の取り込みを開始している場合、それはリードジェネレーションシステムから情報をプルしている状態です。データベースやシステムから情報を取り出す場合、それはプルです。逆に、データベースに情報を入れる場合はプッシュです。
デジタル統合において違いを理解することの重要性
問題は、次のような形で始まります。たとえば、私たちが「私たちはNetSuiteの専門家であり、Salesforceとの統合をお手伝いできます」と言ったとします。あなた（顧客）は、「NetSuiteに情報をプッシュしたい」と言います。その時点で、あなたの開発者がSalesforceでの開発に精通していることを伝えたことになります。
NetSuiteにはAPIがあります。私たちは、どのエンドポイント（つまり郵便受け）に情報をプッシュするかを一緒に特定し、それが分かれば私たちの仕事は完了です。あなたが「NetSuiteに情報をプッシュしたい」と言ったことで、Salesforceが郵便配達人であることが伝わったわけです。
同様に、「NetSuiteから情報をプルしたい」と言えば、それもやはりSalesforceが郵便配達人であるということを意味しています。NetSuiteはAPI、つまり郵便受けを持っていて、そこから情報をプルしようとしているのです。
この前提で見積もりが作成されたり、開発者が契約されたりします。しかしその後、誰かが「NetSuite側がSalesforceから情報をプルする」と言い出すと、状況は一変します。それは当初の合意内容とは異なり、すべてが変わってしまいます。今度はNetSuiteが郵便配達人になり、Salesforceから情報を取得するためのコードをこちらが書く必要が生じます。
最終的には、文法の問題に行き着きます。文の主語、つまり「Xがプルする」「Xがプッシュする」という主体が、統合処理の起点（郵便配達人）になります。動詞はその主体が行う「情報を送る（プッシュ）」「情報を受け取る（プル）」という動作を示しています。
本当にそれほど単純なのか？
最も基本的なレベルでは、本当にそんなに単純なものです。郵便配達人は、情報を郵便受けに入れるか、郵便受けから取り出すかのどちらかです。でも、「悪魔は細部に宿る」とも言います。統合のコンセプトが単純だからといって、実際の実装が簡単とは限りません。関係者全員が、「誰が郵便配達人であるか」「プッシュなのかプルなのか」についてきちんと共通認識を持っていることは、統合プロジェクトを成功に導くための非常に重要な一歩です。
Boomiはどのように支援するのか？
Boomiはプッシュもプルもどちらも対応可能です。どちらの統合も、簡単に作成・管理できるように設計されています。たとえば、Boomiは NetSuiteから情報をプルし、 Salesforceへプッシュすることができます。もちろん、それ以外のアプリケーション同士でも同様です。Boomiは統合処理の両側を担うことができ、開発者によるコーディングも不要です。
Boomiはローコードの構成型プラットフォームで、ドラッグ＆ドロップのインターフェースを備えています。業務担当のビジネスアナリストでも、情報をプッシュ／プルするシンプルな統合を学んで作成できます。さらに、複雑な統合を必要とする場合でも、Boomiは直感的で一元化されたクラウドネイティブな環境を提供し、開発者の作業をスピーディに進められます。
統合プロジェクトを軌道に乗せるために
統合要件ドキュメントを作成しましょう
これまで説明してきた「誰がプッシュし、誰がプルするのか」といった点は、要件定義書に明記しておく必要があります。さらに、以下のような重要な要素も忘れずに盛り込みましょう。
- どのような郵便受けが存在するのか？ API自体は存在していても、どのような機能が提供されているのかを確認する必要があります。自社のユースケースに対応する機能がAPIに含まれていない場合、その機能を追加する開発コストに見合うビジネス上の価値があるかも検討が必要です。
- 利用可能なスキルセットは？たとえば、NetSuiteの開発者がいないがSalesforceの開発者はいるという場合、プッシュもプルもSalesforce側で行うのが現実的かもしれません。しかし、Boomiを使えばコーディング不要で、どちらのシステムでも、数回のクリックだけで簡単にプッシュ／プル統合を構築できます。
- イベント駆動型のデータ移動が必要か？情報をプッシュする場合、特定のアクションやイベントをトリガーとして情報を移動するプロセスを定義できます。一方、プルする場合は、バッチ処理やスケジュールベースの統合しか選択肢がありません。
- ビジネスロジックはどこに置くか？一般的に、ビジネスロジックは最も多くのリソースを投資しているアプリケーションに配置するのが理にかなっています。つまり、自社が今後も活用・拡張していく予定のシステム側にロジックを持たせるのがベストです。
- コストの制約はあるか？社内に開発リソースがある場合、外注するよりも社内で作業した方が経済的です。ここでも、Boomiは社内開発者にとって大きな力になります。
これが、プッシュとプルの統合の基本です。次に統合プロジェクトを始める際には、これらの用語を最初に整理しておくことで、誰がどのタイプの統合を担当するのかに関する混乱を防ぐことができます。
システム統合は、データのサイロ化やテクノロジーの断片化を解消する第一歩です。それらの障壁を回避する方法については、弊社の電子書籍『Chaos to Order（混乱から秩序へ）：断片化されたデジタル環境を現代的な統合でつなぐ』をご覧ください。
著者について ニック・モーテンセンは、BoomiのパートナーであるEide Bailly Technology Consulting の開発ディレクターです。同社はERP、CRM、クラウドテクノロジーの導入・カスタマイズ・統合を専門とするビジネスアドバイザリー企業です。