DA（決定分析）表があることで代案が立てやすくなる
堀越悠久史氏（以下、堀越）：（スライドを示して）せっかくここまで来たので。こんな感じでケーススタディを通して、常にこの表を使ってやってきましたが、これはやはり継続的かつアーキテクトの個人技によらずにできるようになりたいところだと思っています。
あらためて、こういう表を作っておくとなにがいいかを確認したいと思います。同じプロジェクトの中だと、「”二の矢”を放てる」という表現をしています。この表は、みんなというか、プロジェクトの関係者と一緒に検討していました。よくあるのが、「案1で進めていたけれど、実はその方式がちょっとだめになっちゃった」ということです。私も1回そういうことがあって、「専用線を引きましょうよ」と言っていたのですが、「間に合いません」と言われて、「うわっ、どうしよう」となりました。
実はその（当初の検討）時に「まぁ、VPNだったらいいんじゃないですか？」という話もしていたので、（専用線がダメとなったとき）「このぐらいであれば、VPNぐらいのデータ量やスループットでも耐えられますよね」という話をして、「とりあえず最初はそれでいってみましょう」という議論ができました。
あとは、こういう表を作ってあると、ほかのプロジェクトになったとしても選択肢が提供できます。新しいやり方がどんどん増えたりしますが、同じような要件があって、ここに1つ（新しい）案が増えたとしても、管理ができます。そんな感じにできるかなというところです。「こんな簡単にいくかいな？」というところだったりしますが（笑）。
（スライドを示して）こちらに、よもやま話をいろいろ持ってきました。本当はちょっと鶴田さんにもある程度語ってほしいところです。
1個目です。Case3で、APIゲートウェイなしでなんとかSoE、SoRの連携をやってみましたが、これには後日談があって。新しくもう1個SoEを追加しました。
この（あとからSoEを追加する）プロジェクト（をやっている中で）、以前やったプロジェクトで「インターネット側から比較的簡単に接続ができるようにした」という話を聞きつけてきて、「（SoE側接続を）できるようにしました」と言ったら、突然「そこらへんの仕掛けを入れていなかったのでできません」みたいな話になりました。
そういうことがあって、「なんでこんなやり方を選んだんですか？」と言われて。「それはみんなでそれを選んだからです」と喉元まで出かかりました。
なんでそんなことになったかというと、運用する人や先方のPM担当者が代わってしまった時に、（引き継いだ人から見た時に、連携方式の仕様が）すごくわかりにくかったからだと思っています。トリッキーなのはやはり避けたほうがいいなと思いました。
連携不備が出た時の責任分界
堀越：鶴田さんは、なにか苦労話みたいなものはありますか？
鶴田拓己氏（以下、鶴田）：そうですね、システム的な部分での苦労話もありますが、それ以上にシステム連携となると、ほかのシステムの担当の方とステークホルダーがちょっと増えてくるので、そこの調整で苦労しました。
あと、なにかしら連携でエラーやうまく連携できなかった場合の責任分界の部分はちょっと苦労したというか、引っかかった部分ではありますね。
堀越：エラーの責任。「これはどっちの責任だ」という。
鶴田：そうですね、はい（笑）。お互い原因がわからない状態だと、「おたくが……」みたいなことがますます発生しがちなところではあるかなと思いました（笑）。
堀越：ありがとうございます。せっかくなので、もうちょっとだけこれを引っ張ると、リトライみたいなことをちゃんと考えなければいけないというのもあったりしますかね。
先ほどみたいに、エラーが発生した時に、ある程度タイムアウトしたらリトライしますようなことをよく入れたりします。（そうなった時に）例えば「ポイントの交換の時にリトライが起きたらどうなっちゃうんでしょうね」みたいなことがあったりします。
そうすると、二重で（APIリクエストが）行くのはけっこう大変なことになってしまったりします。（なので）テクニックとしては、ちゃんとIDをつけて、リトライをしても同じIDなので、同じIDが来た場合には撃ち落とすみたいなことをします。まぁまぁ、そういうのはあるんですけど、意外と忘れがちみたいなやつですね。
私もちょっとやったことがあるので、あえて書いています（笑）。
APIによるシステム連携の発展予想
堀越：ちょっとすみません。トラブルもあって時間が経ってしまったのですが、できるだけしゃべりきりたいなと思っています。
そんな感じで、今後の潮流としてシステム連携を見ていく時に、「私はこんなことを考えています」ということを話したいと思っています。
Case3で「APIゲートウェイなしでもなんとかできますね」というところがありましたが、これはやはり後々になって大変だったところがありました。やはり「APIゲートウェイを作っておけばよかったですね」というのが今になっての気持ちです。
実は今はAPIゲートウェイを経由して、先ほどのいろいろな連携を進めていくことも多いのですが、（それでも）やってみると、開発時に「APIをどういう仕様でやりますか？」ということ（による困難）はけっこうあったりします。
やはり人手によるコミュニケーションが中心の世界です。「Swagger」みたいなやつでAPI仕様記述はありますが、細かいところで「こういう条件の時にはどうなるんですか？」という話になってくると、やはり人手が出てきます。（さらに）やはりシステム間の結合テストで初めてぶつけてみて、「ぜんぜん合わねぇじゃん」みたいなことが出てくることがあります。
こういうことがあるので、もうちょっとAPIゲートウェイみたいなものが進化してくれないかなと。（スライドを示して）ここにAPIマネジメントと書いてありますが、今後もシステム連携は数が増えてくるので、そういうところまで（APIによるシステム連携の仕組みで）やっていきたいかなというところですね。
（スライドを示して）そう考えていくと、今後どんな世界が広がっていくのかなと勝手な想像をしていますが、APIゲートウェイ（の進化）がありますね。もともとあった、ぜんぜんシステム間の連携がされていないものがこんな（サイロ）状態です。ちょっとずつシステム連携の数が増えていくと、（スライドのような）進化をしていきます。
APIゲートウェイでやっていると、インフラやネットワークレベルではサポートされていますが、開発や運用がちょっと大変です。
先ほど鶴田さんが言っていましたが、エラーが起きた時に、「どこでエラーが起きていて、どっち側が悪いんじゃい」みたいな話になるので、そこをパッとわかるようにしておきたいとなると、やはりオブザーバビリティみたいになって、（そういう）キーワードの世界が必要になってきます。
そのあたりをやってくれるのが、Integration Platform as a Service、iPaaSと呼ばれているやつです。こういうところに手を入れていかなければいけないのだろうという気がしています。
逆に、このあたりが発達していくとどうなってくるかというと、普通にAPIで（システムが）つながる世界になってくれば、「だったらもうちっちゃいサービスをどんどん作っていけばいいよね」みたいな話になってくるんだと思います。そうなってくると、いわゆる「マイクロサービスでいろいろなシステムを作っていきましょう」みたいな世界になってくるのではないかと想像ができます。
このあたりの「僕たちは今どこにいるんだろうね」「このお客さんはどこにいるんだろうね」ということを考えながらちょっとずつ（システム連携を）やっていくようなことがいいのかなと思ったりします。そろそろで、いったん終わります。
残念な顧客体験はITエンジニアが作り込んでいるものかもしれない
堀越：まとめですね。どうしよう。せっかくなのでここは鶴田さんにまとめてもらおうかな（笑）
鶴田：まとめ（笑）。そうですね。システムを連携させることの価値でいくと、先ほどのただの便利機能の実現ではなくて、コールセンターの応答時間というか、対応時間の話にもありましたが、顧客体験につながってくる部分で、ただの便利機能ではなくて、メイン機能というか、今後のDXでは重要になってくる部分だと思っています。
かつ、2番目のシステム連携アーキテクチャ設計のステップとしては、選択肢をどれだけ持っているかというところで、その選択肢と要件や制約を洗い出して、その選択肢の中からどれが一番いいのかという意思決定をしていきます。
仮に、意思決定というか選択肢の評価がうまくいかなくても、選択肢を多く列挙していけば次善の策、第二の矢が放てるというところが、今回の大きなポイントだったかなと思っています。
堀越：ありがとうございます。むちゃぶりしちゃいました（笑）。すみません。だいたいそんなところだと思います。
そろそろ終わりますが、最後に、今回のこのスライドを作っていく中で、メッセージを1個考えなければいけないなと思ったので、そこだけちょっと表明します。
鶴田さんは残念な顧客体験をしちゃったわけですが、それって誰のせいだと思いますか。
鶴田：誰のせい？ そうですね。誰のポカだったかという側面でいくと、Webを作ったITエンジニアや、担当されていた方が忙しい中で一生懸命設計したものだと思いますが、そこでたまたま、ちょっとポカったところかなと思います（笑）。
堀越：まぁまぁ、ポカってというか、もともと難しい（こと）。
鶴田：そうですね。
堀越：在庫の引き当ては私は体験したことないですが、SoR側がああいうことをやると（なると）難しい世界だと思います。でも、もしかすると、あえて言いたいのは、それは鶴田さんのせいかもしれないということです（笑）
なにを言いたいかというと、私たち自身もやはりITエンジニアだと思うんです。ということは、残念な顧客体験を作り上げているのは、やはりその裏側にシステムがあって、それを作っているのはITエンジニアなので、結局自分たちが悪い顧客体験を作り込んでいる可能性があるということなんじゃないかと思っています。
そう思うと、本当に「ただの便利機能じゃないか」とか、「余力がないからちょっとやめておきましょう」というところで踏みとどまっていていいのかなという気がしています。
ITエンジニアは何気にけっこうな力を持っています。顧客体験を変えるとか、世の中をちょっとでも良くするという力を持っていると思っているので、もうちょっとがんばったほうがいいかなという（笑）。
それが顧客体験を変えていく、世の中を変えていくところにつながればいいのかなと思いながらこのスライドを作っていました。
最後にメッセージです。今回マーケティングのような話も少し絡めましたが、電通国際情報サービス（ISID）あるいは電通グループはキャリア採用の応募者を絶賛募集中です。
今回みたいなマーケティングに絡む話や、それに絡めたいわゆるデジタルトランスフォーメーションにもし興味があって「ちょっと話を聞いてみたい」ということがあったら、ぜひお気軽に連絡をもらえればと思っています。
最後にそんなメッセージに代えて、私たちの発表というか、登壇をいったん終えたいと思います。ありがとうございます。
