顧客のビジネス課題を解決するクラウド間のシステム連携、アーキテクチャ設計のステップを解説

アーカイブ動画

電通国際情報サービス
Xイノベーション本部 デジタルエンゲージメントセンター
鶴田 拓己氏

今回登壇した堀越氏は、テックリードという立場でSalesforceやAWSを活用したコンタクトセンターやWebポータル、CRMなどのシステム導入を担当。鶴田氏はSalesforce案件、中でもExperience Cloudを利用した受付サイト系の案件を担当している。

現在、堀越氏と鶴田氏は同じプロジェクトに参画しており、堀越氏が先輩で、鶴田氏が後輩という間柄だ。セッションでは堀越氏が解説を行い、重要なポイント部分では鶴田氏に質問を投げかけ、参加者と共に考えるという和気藹々とした形式で進められた。

シンプルに見える画面でも容易に実装できるわけではない

まず堀越氏は、あるシステムの機能イメージの全体像を示し、「このシステムはどうやって作ったらいいでしょう」と投げかけた。

この画面は、金融やサブスクのビジネスでの顧客対応をイメージしてSalesforceで作成した営業向けのシステムで、顧客情報や対応履歴情報などの取り扱い(主に画面左側)はSalesforceの標準機能を利用している。

「例えば、顧客から『半年前に話していたことが知りたい』という問い合わせがあったとしても、Salesforceで記録していれば、さっと内容が確認でき、話をスムーズに進めることができます」（堀越氏）

この画面自体は比較的簡単に作れるが、問題は画面右側の「契約情報」や「お取引履歴」の内容だ。顧客の口座やカードの有効状態、カードを使った取引履歴やポイント付与の情報なども表示できる機能である。さらに、契約状態の横に「利用の一時停止」ボタンが設けられている。顧客対応においては必須の機能群である。

堀越氏は「この機能は簡単に実装できそうですか」と鶴田氏に問いかける。すると鶴田氏は、「データが他のシステムにあるのであれば、システム連携をしなければならないのではないか。簡単に実装できるとは言えないですね」と回答した。

一見シンプルに見える画面だが、実は別システムのデータを扱っていることになっている。このように、顧客対応に利用するSoE（System of Engagement）は、契約データや取引履歴データをSoR（System of Record）から取得し、紐付けて参照、場合によってはSoR上のデータを操作しなければならない。

SoRはオンプレミスやプライベートクラウドで構築されていることが多く、「このような連携は結構なハードルがある」と堀越氏は明かす。Salesforceを始めとするSaaSはパブリック領域つまりインターネット上にある。この連携を実現するには、パブリック領域からプライベート領域にシステム連携し、SoEのボタンを叩けばSoRのデータを取得・操作するという仕組みにする必要がある。

「本当にそんな仕組みを作っていいのか、プライベート領域のシステムと連携するために壁を乗り越えるには、セキュリティなどの、様々な意見が出てくると思います」（堀越氏）

ユーザーからは、「ボタン一つなのになぜ実現してくれないんだろう」という意見が当然ながら出てくる。セキュリティ担当からは、クラウド側からAPI連携してSoRのデータを取得・操作することに不安の声が出てくるだろう。プロジェクトマネジャーはそれらの意見に板挟みとなり、こうした機能は実現できないことも少なくない。

ここで、堀越氏は鶴田氏に次のような質問を投げかけた。 「実現しようとしているのはあくまでも”便利機能”。本当に実現した方が良いと思いますか」
鶴田氏は「工数的に余力があれば実現した方が良いが、運用でカバーする方が現実的だと思います」と回答。堀越氏は鶴田氏の回答に頷き、こう説明した。

「主要な機能か否か、余力があるかなどによって判断は分かれます。一方で、ユーザーにどこまで寄り添うか、ビジネスの側面も含めてよく考える必要がある。ボタン一つ画面一つとは言え、その連携にどれだけのビジネス上の価値があるのか考えることが重要です」（堀越氏）

ここまではあくまでもイントロダクション。今回のセッションでは、システムを連携させることの価値、実際にハードルを越えるためのシステム連携アーキテクチャ設計のステップを考えていく。

システムを連携させることの価値を考える

鶴田氏は最近、残念な顧客体験をしたという。ネットショッピングのサイトで買い物かごに入れて注文したにも関わらず、あとから在庫切れであることが分かり、結果として手に入れられなかったのだ。

「残念な顧客体験をすると、次の購買に結びつかなくなります。昨今の企業にとって、顧客体験は至上命題ともいえるでしょう」（堀越氏）

インターネットが当たり前となった21世紀型の顧客行動は以下の図のように、「調査」の際には他社の顧客体験も含めて検索されることになる。良い顧客体験であれば奨励・共有されて次の顧客を呼び込むが、期待に届かない顧客体験では、そこで終わってしまう。

この顧客体験を与えるのがWebやスマホアプリ、店舗・営業部隊、コールセンターなど、企業側の「顧客接点」である。これらの顧客接点を支えているのがSoEであり、SaaSやPaaSをはじめとしたクラウドサービスが多用されている。顧客情報を管理することができ、さらに営業やコールセンター向けの機能が最初から提供されているため、顧客やビジネスの変化に迅速かつ柔軟に対応できるからだ。

「例えば、その顧客がキャンペーン対象かどうかのフラグをデータベースに追加して管理するようにすることも、Salesforceならものの数分で実装できます」（堀越氏）

従来のシステムであれば、このようなデータベースへの項目追加や画面に表示する仕掛けを作るとなると、それなりに工数がかかる。Salesforceはそれらが不要なのだ。

一方、顧客対応で必要となる対応履歴や契約などの情報は基幹系、いわゆるSoRで管理されている。

「そうしたシステムはクラウドが登場する前から存在しており、業務ごとに個別にシステム化され運用されてきました」（堀越氏）

結局、現在では、顧客対応するには、SoEとSoRの両方を見なければならないことになる。

このときの操作は次のようになる。まず顧客対応の過程で、SoE側で顧客番号などの顧客特定キーを把握する。次に、SoRにログインし、把握した顧客特定キーなどをもとに顧客を検索する。見つかった顧客情報が合っているかを確認し、合っていれば情報を参照・更新する。この操作はさほど難しくはないだろう。

一方、コールセンターでの対応を例に挙げると、顧客対応のたびにこの操作をすることとなると、人間であるオペレータは、イライラしてしまうこともあるだろう。この感情は、もしかすると電話の先の顧客にも伝わっているかもしれない。また、先のような操作が繰り返し行われるので、どうしても応対時間が長くなり、顧客を待たせてしまうことになる。これはつまり、顧客対応の効率性に関するKPIだけでなく、顧客体験にもマイナスの影響を与えてしまう。

だが、もしここで冒頭で示した画面のようにSoEとSoRが連携していれば、応対時間が短縮され、それはそのまま顧客の待ち時間が短縮され、顧客体験の向上につながっていくことになる。こう考えると、”ただの便利機能”とは言えない面もあるのだ。

アーキテクチャ設計の進め方

昨今の企業の至上命題である良好な顧客体験を提供するために、SoEとSoRを連携させることには意味がある。一方で、冒頭であったようにセキュリティ上の懸念などをクリアしない限り、この連携は実現できない。どのようなシステム全体設計を行うか、アーキテクチャ設計がポイントになる。また、多数の関係者と共にその方針を決定する意思決定が必要となる。

「アーキテクチャ設計の注目ポイントは次の点」と語り、堀越氏が挙げたのが、「機能とデータの配置場所」と「通信・接続の可能性」である。「機能とデータの配置場所」については、パブリックにあるSoEに顧客情報がありここで顧客応対を行い、契約や履歴の情報はプライベート領域にあるSoRに配置されているのが現状の多くの場合である。あとは、「通信・接続の可能性」を考えていくことになる。 堀越氏は次の図のようなステップでシステムアーキテクチャ設計を進めていると語る。

ステップ1　取り得る選択肢を列挙する
ステップ2　要件や制約を洗い出す
ステップ3　各選択肢の評価、意思決定

「このやり方を実施するために、右のような表を作成します。横に要件や制約を並べ、各選択肢を評価するための決定分析表(DA表)を作成します。大きな意思決定になるので、あえてこのようにしっかりとやる価値はあると思います」（堀越氏）

ステップ1で堀越氏が挙げた選択肢の例が次の通りである。

•  API呼出で連携
•  バッチでのデータ連携
•  Pub/Sub通知で連携
•  あえて連携を実施しない

列挙のポイントとしては、引き出しにしまっている数が大事だ。AWSなどのクラウドプラットフォームで提供されている方式は多数ある。「いつか使えるかも」という情報収集がポイントになりうる。そして、考えられるパターンから論理的に導き出し、対象のプラットフォームで可能な方式かを確かめにいくのである。

堀越氏は、システム間連携のパターンは図のようにUI、ビジネスロジック、データの3つに分けて整理しているという。UI層での連携では「URL連携による画面遷移やマッシュアップなどのUIレベル連携」「クライアントAPI連携（他のドメイン）」がある。

ビジネスロジック層での連携パターンが「サーバ間API連携」、データ層での連携パターンとして、「データ連携」(ETLなど)がある。これらの中でも中心的になるのが、サーバ間API連携とデータ連携だと堀越氏は言い切る。

加えて留意したいのが、インターネット上のクラウドからプライベート領域ヘの通信ファイアウォールによる制限がかかる点だ。一方、内側(プライベート領域)から外側(パブリック)へは一般に接続は可能である。通信の接続の方向に留意が必要になるのだ。それを表したのが以下の図だ。データや処理を連携したい方向と、接続できる方向の双方を意識しておきたい。

ステップ2の要件や制約を洗い出す際に、気をつけなければならないこととは何か。鶴田氏は「セキュリティや連携した際のエラー処理」と回答した。堀越氏が要件や制約のキーワードとして挙げたのは次の図の通りだ。

要件や制約の洗い出しをする際のポイントの第一は、世の中の標準やフレームワークをヒントとすること。AWS Well-Architected FrameworkやISO/IEC25010 SQuaREシリーズの品質モデルなどが参考になる。

第二のポイントは、組織的もしくは公共知となっている経験やノウハウを利用すること。組織で蓄積された失敗事例を確認したり、過去のプロジェクトでのふりかえりや分析を共有したりすることである。

ステップ3の各選択肢の評価・意思決定では、いよいよ決定分析表を作成する。ただし、実は決定分析表を作成すること自体が重要なわけではない。

「この方式ならこのレベルで実現できるだろうと、この表をたたき台に、関係者と議論、検討ことが大事なのです」（堀越氏）

表を作ることで、なぜそう評価したのか。またある要素がだめでも付加的な対策の追加できるなどの議論をすることで選択肢の精度が高められ、より良い意思決定に繋がるからだ。

3つのケーススタディから学ぶ、システム連携の勘所

続いては、3つのケーススタディについて、鶴田氏と連携の方式を考えていく。

ケーススタディ1は「IaaS上に構築されたSoEで、SoRで管理されている契約データと履歴データを参照したい」。

SoR側では、他のシステムと連携実績のあるAPIが提供されている。「この場合はどんな方式が考えられるか」という堀越氏の問いに、鶴田氏は「SoR側にAPIが装備されており、VPNや専用線の接続が可能なので、SoE側からAPIを叩きにいって、契約データや取引履歴データをSoRから返してもらう方式が頭に浮かびました」と回答。

堀越氏の考えは、IaaS上にプライベート領域を構築して、VPNや専用線などでSoRとプライベートに接続するという方式である。

「特にAWSを念頭に置くと、パブリックサブネットとプライベートサブネットがあるので、プライベート側に専用線やVPNを敷いてアクセスするやり方です。クラウドデザインパターンに載っている非常にオーソドックスなやり方と言えると思います」（堀越氏）

ケーススタディ2は「純粋なパブリッククラウドのSoEで、迅速にSoRにある契約データ/取引・履歴データを参照したい」。ただし、SoRには他のシステムやアプリケーションで利用された既設のAPIゲートウェイおよびAPIの提供があり、運用も確立されている、というケースである。

「考えられる方式はどのようなものがあり、どんな制約がありますか」と問いかける堀越氏に、鶴田氏は、「既設のAPIゲートウェイやAPIを使って連携する方法が考えられる。制約については、セキュリティ認証を考えなければならない」と答えた。

連携方式の検討は、次の図の通り。プランAはSoEからAPIでSoRより取得する「サーバ間API連携」である。このケーススタディにおいては、検討の結果としてプランAに決定したと堀越氏は言うが、SoE側に夜間バッチでコピーするデータ連携やSoE側からSoR側に画面遷移するUIレベル連携などのプランも有力な選択肢として考えたという。

プランBはキャパシティ・運用コストに×が付けられている。その理由は契約情報などの膨大なデータ量をSoE側に取り込むことが想定されるからだ。鶴田氏は×が付けられた理由を以下のように挙げる。

「パブリッククラウドだとストレージ容量が制約として発生します。ストレージの計算やストレージを空けるためのアーカイブや削除の方式についても考えないといけません。パフォーマンスにも影響してくると思いました」（鶴田氏）

ケーススタディ3は「純粋なパブリッククラウドのSoEで、迅速にSoRにある契約状態を変更したい」。ケーススタディ2とは異なり、APIゲートウェイは存在せず、SoRはMQによるシステム連携のみ。このような状態でどんな連携が考えられるか。

その問いに対して鶴田氏は、以下のように回答している。

「金融機関の基幹系だと想定して、使ったことのある方式はデータ連携基盤を介して連携させる方法です。具体的には基幹系から踏み台サーバにファイルを送り込み、踏み台サーバからデータ連携基盤にファイルを送り、FTP通信やSFTP通信でデータ連携基盤とやり取りさせて、SoEとそのデータ連携基盤をコネクトさせます」（鶴田氏）

さらに堀越氏は「冒頭の画面のように、SoEの画面からSoRにある契約状態を変更したいという場合はどうするか」と突っ込んだ質問を鶴田氏に投げかけた。

「APIを使うのが良いが、APIゲートウェイもなくセキュリティも厳重なので、SoR側のステークホルダーとの調整が大変になるのではないでしょうか」（鶴田氏）

堀越氏は「実はこのケースは非常に悩んだ」という。最終的に堀越氏が選んだアーキテクチャが下図である。実はUIとなるブラウザはプライベート領域である構内LANにあるため、そのUIから、新規に構築したプロトコル変換サーバを介してシステム連携させるというマッシュアップ的な実現方式だ。これは、連携パターンとしては「クライアントAPI連携」にあたる。UIとプロトコル変換サーバとはAPIで連携し、プロトコル変換サーバからSoRへはMQを介してアクセスするようにした。

3つのケーススタディを終えて、継続的かつ組織的なアーキテクチャ設計をするためには、「決定分析表を作って議論して意思決定することをお勧めします」と堀越氏。その短期的な効果としては「二の矢」が放てること。様々な事情や状況の変化から、当初のプランでは実現できない事態に陥ることも実際のプロジェクトでは多い。その場合でも、他の選択肢を含めて関係者と一緒に検討しているので、次善の策への切り替えも合意が取りやすいからだ。

中長期的な効果としては、基本パターンはそう変わらないため、技術が進化して連携の選択肢が増えてもアップデートしやすいこと。仮にあるプロジェクトで苦労しても、次回の制約の洗い出しの参考にすることができることだ。

最後に堀越氏は、今後のシステム連携のあり方についての展望を語った。 ケーススタディ3のような方式は、なんとか一つのSoEと一つのSoRを連携させることは実現できたが、連携対象を増やそうと思ったときには個別対応になるため合理的ではない。共通の連携基盤(APIゲートウェイ)を構築するのが合理的であり、さらに「インフラレベルのAPIゲートウェイだけでない、高度なAPI連携のための基盤の導入が進むだろう」と堀越氏。たしかにAPIゲートウェイによってSoEとSoRの連携は可能となったが、まだこの状態では、開発においてはAPI仕様の個別の擦り合わせが必要であり、運用時にはどこでエラーが起きていてそれがどこに影響しうるのかわかりにくい。

しかも今後、連携されるシステムは増えていくことが想像できる。そうなるとそれぞれの関連を管理しきれなくなってくるだろう。APIマネジメントでシステム連携のライフサイクル全体をサポートしていくことが必要となるだろう。

「それを可能にするのがiPaaSであり、さらにその先にはAPI連携を前提としたマイクロサービスネイティブへと進化していくでしょう」（堀越氏）

SoEとSoRの連携は顧客体験に直結している。つまり残念な顧客体験があるとすると、その裏側には、残念なシステムの存在があるということ。堀越氏はこう呼びかけセッションを締めた。

「どんな顧客接点もシステムが支えている以上、顧客体験の善し悪しは実はITエンジニアが握っています。ぜひ良い顧客体験ができるよう、私たちが変えていきましょう」（堀越氏）

多くの質問が寄せられ、盛り上がったQ＆Aセッション

Q&Aセッションでは参加者から様々な質問が投げかけられた。いくつか紹介したい。

Q．連携方式によってシステム構成や実現の工数に変動があると思うが、連携方式の検討はプロジェクトの計画時点で詰め切れるものなのか

堀越：仮説を持っておくことです。具体的には要件定義をする中である程度工数を算出しておくこと。ウォーターフォール型の場合は要件定義をした後に、再見積りをするモデルを取りたく、その場合にはその時点で費用面が固まりやすいと思います。

Q．システム連携しづらいパターンなどはあるか（自社システムは連携しづらいなど）

堀越：技術の問題より人の問題の方が大変かもしれません。ステークホルダーが多いケースやクラウド導入が初めてというケース、クラウドの考え方が合わない顧客も苦労します。

鶴田：セキュリティが厳重な場合も、単純にはできないので苦労します。Salesforce前提はHTTPSがメインになりますが、インターネットへの導線がないと単純なAPI連携ではなく、選択肢をいろいろと出さないといけなくなります。

Q．DA表を作っても差が見えてこない場合は、どのように意思決定していくか

鶴田：要求や制約などの評価軸が足りていないからかもしれません。DA表もいろんな軸を用意していますが、さらに評価軸を増やしていくことで意思決定していきます。

堀越：DA表を書くことは目的ではなく、次の行動を決めるためにあると考えたいところです。どのプランも制約や要求を満たせないような場合は新たな選択肢を考えなければなりませんが、複数の候補が許容可能ならば、どれでも良いということで、むしろラッキーかもしれません。一長一短あって決まらないのであれば、最悪サイコロを振ってもいいし、その中でも自分たちが学びになるような、やりたいものを選べばいいと思います。

鶴田：最近はSoRと連携したいというプロジェクトがどんどん増えています。これから少なくなることはないでしょう。今回のセッションのように対応していきたいと思います。

株式会社電通国際情報サービス
https://www.isid.co.jp/

株式会社電通国際情報サービスの採用情報
https://career.isid.co.jp/