複数システムの連携は3ステップで考える　DA（決定分析）表を活用した「議論して、意思決定する」こと

SoEとSoRの連携を具体的にどう進めていくか

堀越悠久史氏（以下、堀越）：「実際、どういうふうに進めましょうか？」というところにいよいよ入っていきたいなと思っています。

（スライドを示して）さて、もう1回最初のところのおさらいです。SoE、例にSalesforceを出しましたが、鶴田さんのやっていたようなWebでもぜんぜんいいです。SoEがあって、そこに顧客データがあります。顧客はそのシステムに直接的に触りにいくとか、あるいは営業担当やコールセンターのユーザーが触ります。

一方で、取引データあるいは契約データは、SoRを見ます。ただし、SoEからSoRに連携させるためには、プライベート領域にアクセスしなければいけないところもあるので、ちょっとハードルがあります。「データをここに持ってくればいいじゃん」という話ですが、「本当にそれでいいのか」と少し議論の余地があります。

全体として、こういう複数のシステムがあった時に、その連携の方式やアーキテクチャをどういうふうにしたらいいのかをきちんと考えなければいけません。おさらいすると、だいたいこんなところかと思います。

注目ポイントは、機能とデータの配置場所です。“機能”は「やはりSoEに寄せたほうがよさそうだ」ということが今までの話だったと思います。ただしデータに関して、SoRにあるのがこのあたり（顧客データ、契約データ、取引・履歴データ）だと思うので、これを持ってくるわけにはいかなそうだというところです。

でもそうすると、こことここ（SoEとSoR）を連携させるためには、通信や接続をどういうふうにやっていけばいいのかを考えていかなければいけません。これがシステム連携の方式であり、アーキテクチャを考えるというところになります。

システム連携方式・アーキテクチャを考える3つステップ

堀越：実際どういうふうにやっていけばいいのかです。「少なくとも私はこういうやり方でやっています」ということをちょっと紹介します。

（スライドを示して）上からいきますね。（1個目が）取り得る選択肢を列挙します。いろいろなやり方があるかもしれないです。2個目が、要件や制約を洗い出します。3個目が、その選択肢を評価して意思決定します。“意思決定”という言葉を使っていますが、いろいろなプロジェクトの関係者がいるので、みんなで「これでいいよね」と決めることを“意思決定”と呼んでいます。

この意思決定の過程はちゃんと表現してあげることが必要で、そのためにこんな表を作ります。縦軸、横軸は逆でもいいんですが、（スライドに示しているものは）とりあえず横に案が並んでいます。案1、案2、案3みたいなところで、選択肢が並んでいます。要件や制約を表の上に書いていきます。その交点に○や×がつくような表を作ってやります。

この○や×が各選択肢の評価になっています。こういうものを決定分析表とか、あるいは略してDA（Decision Analysis）表と言ったりしますが、だいたいこういうものを作ります。

プロジェクト上でかなり大きな意思決定になるので、こういうものを作って、きちんと「やっていける」ということをあえて（示して）やるのは、けっこう価値があるのかなというところで、こういうことをやっています。

ステップ1　取り得る選択肢を列挙する

堀越：では、上からのステップを見ていこうと思っています。ここは少し省略気味にいきます。（発表の）後ろでケーススタディが3つほどあるので、そこでしっかりと見ていければいいなと思っています。

まず軽めですがステップ1です。システム連携をするとどんな選択肢がありますかね。鶴田さん、なにかパッと思いつくものはありますか？

鶴田拓己氏（以下、鶴田）：パッと最初に思いつくのは、やはりAPI連携の部分かなと思いました。次点で、データ連携基盤みたいなのを間に挟んで連携してあげるのと、最後が、SoRかCSVで手動で引っこ抜いて、ほかのシステムにアップロードしてあげる（方法）。手動になりますが、今の段階ではそういう方法はパッと思いつきましたね。

堀越：ありがとうございます。だいたいそんな感じですね。APIや、あとはデータの連携みたないなものもあるかもしれないですね。あえてシステム間連携をせずにCSVでやるというのは、それに該当するのかなというところですね。

あと、これだったら選択肢の数を持っているかは、けっこう大事だと個人的には思っています。プラクティスになっていて「だいたいこういう方式を取るよね」ということを選んであげるということもあります。

あとは、考えられる（システム連携の）パターンもあったりするので、そこから「こういうやり方はできそうか」と（考えていく）。あとはクラウドプラットフォーム（ごとの方式）ですね。AWSなら、SNSやSQS、あるいはAPI Gatewayみたいなものがあったりするので、そういうのができるのかを確かめにいくようなところがあるのかなと思います。

どんなパターンがあるかというと、私はだいたいこんな整理をしています。

（スライドを示して）昔ながらのシステムの作り方は、このような3層で考えます。UI層があって、ビジネスロジックがあって、データ層があると考えて。それぞれが直接UIからデータベースにアクセスしにいくことはないので、間にビジネスロジックが入ったりしますが、普通のシステムはこういう縦の関係です。

これを連携として考えると、横にも同じようなのがあります。並べて見ると、下から④データの連携があり、先ほど鶴田さんが言ったみたいに③APIの連携、サーバー間の連携があります。

あとは、①UIの連携もあります。SoRで対応するものはなかなかないですが、Webでよくある「URLを指定してあげるとそっち側にジャンプできる」とか、あるいはマッシュアップみたいなものができたりします。よくある「Googleマップをどこかのサイトに埋め込みます」みたいなことはこのマッシュアップでできています。

似たようなもので、UIから別のサイトに対してAPIを連携することもできたりします。（スライドを示して）この斜めの②みたいな線ができると思います。

だいたいこの4つぐらいに分かれるんじゃないかなと思っていて、その中で、やはり③と④のAPIの連携とデータ連携がけっこう中心的な感じなのかなというところです。

（スライドを示して）あともう1つ気にしなければいけないのが、APIの連携です。これはケーススタディで中心的にやるので少し端折り気味にいきたいと思いますが……。ファイアウォールがあって連携できないという話です。

ただこれは接続の方向だけ規定してあるので、内側から外側に接続していく分には別に大丈夫です。データ連携に限って言うと、内側から外側にデータを出すことは普通にできるし、内側から（接続して）外のデータが取ってくることができれば別にいい、みたいな話かなというところです。

すみません、時間がなくなってきました。省略気味にいきますね。

ステップ2　要件や制約を洗い出す

堀越：2個目です。要件や制約を洗い出すところですね。これも鶴田さんに聞いてみますかね。気をつけなければいけないことはどんなことがありますかね？

鶴田：セキュリティの部分と、連携失敗した時のエラー処理のところはパッと思いつきますね。そこはけっこう詰まる部分ではあるかなと思います。

堀越：ありがとうございます。だいたいそんな感じですかね。（スライドを示して）先ほどやったようなエラー処理はもちろんあるし、セキュリティポリシーのほうが（エラー処理よりも）けっこう大事かもしれないですね。

やはり組織ごと、お客さんごとに、「これこれこういうふうなことをしなきゃいけない、しちゃいけない」みたいなセキュリティポリシーがあるので、そこにちゃんと合わせていくというところです。

あと考えなければいけないのが、データの最新性みたいなところですね。もしユーザーさんが「最新のデータを絶対見たいんです」みたいな話になると、それに対応できる方式は何なのかということです。

データ連携はけっこう日次バッチでやったりするので、1日前のデータをユーザーさんに見せることになります。本当にそれでいいのかというところはけっこうポイントになってくるかもしれないですね。

（スライドを示して）どんな要件や制約があるかもヒントを載せています。ここはすみません、キーワードだけになっちゃいます。AWSを使っている方にはWell-Architected Frameworkがあると思うので、その内容を見てもらえれば、「こんなことに気をつけなければいけないな」ということがわかると思います。

あとはもっと大きい話で、どんなシステムでも「こんな品質で見ていけばいいよね」みたいなことがISO/IEC25010という標準で定義されているので、そういうことをヒントにしましょうと。

あとは特にSIerだと、組織的にこういうところは、けっこうこれまでの知見とかも共有されていたりするので、そういうことをきちんと確認しましょうというところだと思います。

ステップ3　選択肢を評価して意思決定する

堀越：3個目は、各選択肢を評価するというところですね。（スライドを示して）先ほどの表を使っていきましょう。

最終的に表現をするためには、やはり○とか×とか△という表現をすればわかりやすいのですが、○・×・△をつけるだけがポイントではなくて、それに向かってどれだけ考えるかというところかなと思っています。

あとは、表ができて「それが正解です、不正解です」という話ではなくて、（それは）あくまで議論のたたき台だということですね。

「ちょっとこんな表を作って検討してきたんですけど、どうですかね？」とやると、ユーザーさんやあるいはセキュリティの担当者からは、「これこれこういうふうな制約とか、こういうポイントが気になるんですけど、どうなんですかね？」ということが出てきたりします。そうすると「あぁ、そうですね」と言って、制約が1個増えたりするというような感じです。

これはアーキテクトとして気がつかなかったという悔しがるポイントでもあるのですが、逆に言うと、組織的には、よりみんなで合意できるような選択肢を選ぶために、より精度が上が……。（音声が途切れる）

司会者：堀越さん、止まっちゃいましたかね？　鶴田さん、聞こえていますか？

鶴田：ごめんなさい。今聞こえなかったので、ちょっと1回抜けちゃったんですけれど。

司会者：いえいえ。堀越さんがたぶん家庭のネット環境の不具合で止まってしまったかと思うので、みなさま、少々お待ちください。途中で止まっちゃいましたね（笑）。

鶴田：そうですね。

司会者：ネット環境の不具合は特になかったのに。みなさま、もう少々だけお待ちいただければと思います。その間に鶴田さんのつなぎがもしあれば（笑）。

鶴田：おおっ、難しいところですね。つなぎですか。ちょっと難しいので、クリスマスっぽい音楽だけ流しときますか。

司会者：そうですね。みなさんもし今の時間で質問などがあれば投げかけてもらえると非常にありがたいなと思います。気になることがあったら、ぜひQ&Aか、チャットでもかまいませんので、してもらえたらなと思います。

あっ、堀越さん来ましたね。よかったです。

鶴田：来ましたね（笑）。

司会者：堀越さん、ミュートを解除してもらえたら。ありがとうございます。

堀越：すみません。ブルースクリーンに見舞われるという最悪の事態で（笑）。

司会者：大丈夫です。みなさま、お待たせしました。再開していきたいと思います（笑）。

堀越：すみません、これどこまでいきましたっけ（笑）。ちょっと、私自身だいぶびっくりしています。

鶴田：ケーススタディの1個前ですかね。

堀越：すみません、ありがとうございます。大事なのは、この表が、1発で「正解です」となるものではなくて、この表を使って議論をするためのたたき台になるというところです。やはり○や×が大事なのではなくて、説明をしていきます。

「なんで私はこういうふうに評価したんですか」「これはこういうことです」みたいな題材にしていくというところですね。これを使って、「これだったら大丈夫ですよね」ということを議論して、意思決定しましょうというところかと思います。

というわけで、この流れに沿ってケーススタディに入っていきたいと思います。

（次回に続く）