講演者の自己紹介
堀越悠久史氏（以下、堀越）：先ほど紹介いただきましたISID、電通国際情報サービスの堀越と申します。よろしくお願いします。
（スライドを示して）先ほど「あっ、変わっているな」と思ったんですけど、何回か紆余曲折を経て、（セッションの）正式なタイトルが「クラウド時代のエンジニアが知っておくべき、顧客のビジネス課題を解決するクラウド間のシステム連携／アーキテクチャ設計のステップ」です。だいぶ長ったらしいタイトルですが（笑）。こんな話をさせてもらえればなと思っています。よろしくお願いします。
まず講演者の自己紹介をさせてください。私は電通国際情報サービスのXイノベーション本部デジタルエンゲージメントセンターに所属している、堀越と申します。テックリードの立場で、SalesforceあるいはAWSを活用したような、コンタクトセンターやWebなどのシステムを導入しています。そういう立場の者です。鶴田さん、お願いできますか？
鶴田拓己氏（以下、鶴田）：私も電通国際情報サービスのXイノベーション本部デジタルエンゲージメントセンターに所属しています。主にSalesforce案件に従事して、現在は特にSalesforceの中でもExperience Cloudを利用した受付サイト系の案件を、Salesforceの認定アプリケーションアーキテクトとして担当しています。
堀越：よろしくお願いします。今回の進め方ですが、ちょうど（2人が）同じプロジェクトに入っているということもあるので、先輩と後輩みたいな立場でうまく対話というか、コミュニケーションしながら進めていきたいなと思っています。
話のメインは私で進めますが、時々鶴田さんに質問を投げかけるとか、「それで一緒に考えていきましょう」みたいな。そんなスタイルで進められたらいいなと思っています。できるだけ和気藹々と、緊張せずにやりたいなと思っていますが、今だいぶガチガチです（笑）。
Salesforceで作成した顧客サポート向けのシステム
堀越：ではよろしくお願いします。まずイントロダクションです。（スライドを示して）今回テーマとしたいシステムのイメージになっています。まず、タイトルとして「こんな画面の顧客サポート向けのシステムがあります」「こういうのをどうやって作ったらいいでしょうか？」という投げかけからスタートします。
実はこの画面は、昨日の夕方ぐらいに少しずつ、2時間ぐらいでこさえたものなんですが、全体としてSalesforceでできています。もしSalesforceを知っている方がいたら、だいたい（の人が）「あぁ、こんな画面が出てきますよね」というイメージを持ってもらえるのかなと思っています。
元のSalesforceは営業向けのシステムなので、どんなことができるかというと、お客さんから案件の相談が来て、例えばそれは2回目だった時に、「あの半年前ぐらいのアレの話なんですけど」みたいに電話してきたりするわけです。
営業からすると「半年前の話、何だっけな？」みたいな話になるわけですよね。そういうことをきちんとSalesforceみたいなものに記録しておくと、「あぁ、あの時に話したアレですよね」みたいなところで話を弾ませることができて。（Salesforceは）非常に営業の力になれるシステムです。
今のは営業の例でしたが、顧客サポート全般にSalesforceは使えます。具体的にいうと、コールセンターでも使えたりしています。
そういうもので作っていくと、比較的簡単にこんな画面が作れます。顧客情報みたいなものが載っていて、名前や電話や住所が記録できるものが比較的簡単に作れます。
（スライドを示して）本題は右側のほうですね。拡大するとこんな感じのものが書いてあります。なにが書いてあるかというと、契約の情報が出ています。それから契約の状態の変更の機能。これはちょっとわかりにくいですが、ボタンのイメージで作ったようなものです。こんなものをちょっとこさえてきました。これはどんなイメージかというと、お客さんがどういう契約をしているかというのを出しています。
私たちがよくシステムを提供するのは金融機関、銀行やカード会社なので、エンドユーザーさんの契約、銀行口座、あるいはカードの保有状態みたいな情報を持っています。そういうのをあわせて表示する機能です。
あとは、その時に取引の履歴も一緒に出すような機能もあったりします。「いついつにどこどこでこのカードを使いましたね」みたいな機能も一緒に出してあげたいと。そうするとなにがうれしいかというと、「この取引のこの話って、なんかちょっとよくわからないんですけど、どうなっているんですかね」という問い合わせがきた時に、見ながら答えられるようなものを作ってあげると、迅速にサポートできます。
今回持ってきたのは、私たちがよく知っている金融系のものでしたが、例えば最近だと、サブスクや、あるいはもしかすると携帯電話みたいなところも、当然ながらこういう情報が出てくるだろうという感じもします。
また、「お客さんが家電を買いました。どういう家電をいつ買っていますか？」みたいな話があ（るような仕事であ）れば、そういったものでもこのように管理することがあるかもしれません。あとは、本当にちっちゃい買い物をした時でも、最近はポイントプログラムみたいなものがあって、そういうのも管理されているので。そういったところをイメージしてもらうといいのかなという例として（金融系の画面を）持ってきました。
比較的シンプルな機能として作ったつもりで画面をこさえてきたのですが、鶴田さん、これはけっこう簡単にできそうですかね？ どうですかね？
鶴田：そうですね。データがSalesforce内やシステム内にあれば表示して。（ただ）データがほかのシステム上にあるのであれば、ほかのシステムと連携して持ってこなければいけないので、それなりにちょっと考えるところはあるかなとは思いますね。
あとは画面のどこにどの項目を配置するかもちょっと考えなきゃいけないかなとは思います。ちょっとだけ考える必要があるので、そんなに簡単ではないかなという感じですね（笑）。
堀越：はい（笑）。ありがとうございます。「簡単って何よ？」という話だったので。だいぶむちゃ振りした質問ですみません。
鶴田：いえいえ（笑）
堀越：あと、一応（鶴田さんとは）台本で打ち合わせてきたので、その台本どおり（の回答）という感じですね（笑）。
（スライドを示して）この例のシステムはどういう構成かというところです。パッと見は、比較的シンプルな画面を持ってきたつもりですが、実はほかのシステムのデータを扱っている構成をイメージしています。
これはどういうことかというと、先ほど見ていた画面が、SoE（Systems of Engagement、顧客接点）のようなところを担うシステムでできていますが、それに顧客データがあって、契約データ、取引の履歴データを表示させています。ユーザーがそれを触りにいくというものです。
実際はこの契約データ、あるいは取引の履歴データは、SoR（Systems of Records）という、契約データや取引の履歴データみたいなものを管理する、別のシステムから持ってきたところをイメージしています。
実は作成ハードルがあるSoEとSoRを活用したシステム
堀越：「こういうシステムってどんな感じでできるんかいな？」「そんなに難しくないんじゃないの？」と思うのですが、「けっこうハードルがあるよ」というのが私たちの経験で（実際に）あるところですね。
なにかというと、SoRは、いろいろなシステム作りの伝統みたいなところもありますが、ここで“プライベート領域”と呼んでいる、オンプレミス、いわゆるデータセンターや、あるいはそのデータセンター上にあるシステムをリフト＆シフトして、プライベートクラウドに持ってきたような領域に作ってあることがけっこう多いです。
先ほど例として出したのがSalesforceですが、そのSalesforceみたいなパブリッククラウドにある状態から、プライベート領域にあるところに対して連携をしなければいけません。
（スライドを示して）ちょっと戻りますが、特にこの「利用の一時停止」みたいな機能をやろうと思うと、例えばこちら（SoE）側の画面のボタンを押したらこちら（SoR）側の処理を叩くみたいな必要が出てきます。
プライベート領域はけっこうアクセスができなかったりするので、この壁をなんとかして乗り越えないと、先ほどみたいなシステムの画面ができないことになります。
先ほど鶴田さんが言っていましたが、「契約データ、取引の履歴のデータをここにコピーしてくればいいじゃん」ということも、まぁ当然あると思います。ただ、「本当にそれでいいんですかね」ということも議論の余地があったりします。
けっこう難しい話が出てきちゃうところです。特にプライベート領域に入り込まなきゃいけない、この壁をなんとか乗り越えなきゃいけないので、けっこう難しい話になっちゃいます。
“ちょっとした便利機能”は実現した方がいいか？
堀越：そうすると、いろいろな意見が出てきます。ユーザーからすると「なんでボタン1つなのにやってくれないんだろうな？ けっこう簡単じゃん」みたいな思いが出てくるし、セキュリティ担当からすると「クラウド側からAPI連携して叩きに来るのか。大丈夫なのかね？」みたいな話が出てきます。
そうすると、PMはけっこう困っちゃいますよね。「なんか多様な意見が出ちゃったけど、どうまとめていったらいいんだろう？」みたいな。「そこらへんをうまくやっていかなきゃ、先ほどのようなシステムは実現できません」ということはけっこうあったりします。
これがもう1個のクエスチョンですね。鶴田さん、こういったちょっとした便利機能は実現したほうがいいですかね？ どうしますか？
鶴田：そうですね。僕だったら「状況によるかな」というところはありますが、工数的に余力があれば実現はしたほうがいいと思います。しかし、余力がない場合は運用で逃げたりというか、打ち取ったりしていったほうが現実的なのかなとは考えますね。そんなに主要な機能でなければというところではありますが。
堀越：ありがとうございます。主要機能かどうかとか、あるいは余力があった時にどこまでやったらいいのかということは、けっこう大きな判断なのかなと思います。
やはり「ボタン1つなのに」みたいなユーザーさんの気持ちには（現実には）なかなか寄り添えなかったりするので、そのあたりをどういうふうに考えていったらいいんだろうということを、システムを作る時にけっこう考えなきゃいけないのかなと思ったりします。
今日の勉強会で持ち帰ってほしい2つのこと
堀越：本日は勉強会の形式ですが、お持ち帰りしてほしいものを大きく2つ用意しています。
（スライドを示して）今回のテーマはシステムを連携させることと言っていますが、そこにどれだけの意味があるのか。その価値です。先ほど「比較的ハードルがあります」という話をしましたが、そのハードルを越えて実現させるために、どのぐらいの意味があるのかをあらためて考えたいです。これが1点目です。
あとは、実際にこのハードルを乗り越えるためにシステム連携を考えるということを、実際にケーススタディを通しながらうまく学んでいきたいなと。そんな流れにしたいと思っています。
というわけで、この2本立てで始めていきたいと思います。すみません、だいぶイントロダクションが長くなっちゃいましたね。
（次回に続く）
