2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
リンクをコピー
記事をブックマーク
堀越悠久史氏(以下、堀越):(スライドを示して)せっかくここまで来たので。こんな感じでケーススタディを通して、常にこの表を使ってやってきましたが、これはやはり継続的かつアーキテクトの個人技によらずにできるようになりたいところだと思っています。
あらためて、こういう表を作っておくとなにがいいかを確認したいと思います。同じプロジェクトの中だと、「”二の矢”を放てる」という表現をしています。この表は、みんなというか、プロジェクトの関係者と一緒に検討していました。よくあるのが、「案1で進めていたけれど、実はその方式がちょっとだめになっちゃった」ということです。私も1回そういうことがあって、「専用線を引きましょうよ」と言っていたのですが、「間に合いません」と言われて、「うわっ、どうしよう」となりました。
実はその(当初の検討)時に「まぁ、VPNだったらいいんじゃないですか?」という話もしていたので、(専用線がダメとなったとき)「このぐらいであれば、VPNぐらいのデータ量やスループットでも耐えられますよね」という話をして、「とりあえず最初はそれでいってみましょう」という議論ができました。
あとは、こういう表を作ってあると、ほかのプロジェクトになったとしても選択肢が提供できます。新しいやり方がどんどん増えたりしますが、同じような要件があって、ここに1つ(新しい)案が増えたとしても、管理ができます。そんな感じにできるかなというところです。「こんな簡単にいくかいな?」というところだったりしますが(笑)。
(スライドを示して)こちらに、よもやま話をいろいろ持ってきました。本当はちょっと鶴田さんにもある程度語ってほしいところです。
1個目です。Case3で、APIゲートウェイなしでなんとかSoE、SoRの連携をやってみましたが、これには後日談があって。新しくもう1個SoEを追加しました。
この(あとからSoEを追加する)プロジェクト(をやっている中で)、以前やったプロジェクトで「インターネット側から比較的簡単に接続ができるようにした」という話を聞きつけてきて、「(SoE側接続を)できるようにしました」と言ったら、突然「そこらへんの仕掛けを入れていなかったのでできません」みたいな話になりました。
そういうことがあって、「なんでこんなやり方を選んだんですか?」と言われて。「それはみんなでそれを選んだからです」と喉元まで出かかりました。
なんでそんなことになったかというと、運用する人や先方のPM担当者が代わってしまった時に、(引き継いだ人から見た時に、連携方式の仕様が)すごくわかりにくかったからだと思っています。トリッキーなのはやはり避けたほうがいいなと思いました。
堀越:鶴田さんは、なにか苦労話みたいなものはありますか?
鶴田拓己氏(以下、鶴田):そうですね、システム的な部分での苦労話もありますが、それ以上にシステム連携となると、ほかのシステムの担当の方とステークホルダーがちょっと増えてくるので、そこの調整で苦労しました。
あと、なにかしら連携でエラーやうまく連携できなかった場合の責任分界の部分はちょっと苦労したというか、引っかかった部分ではありますね。
堀越:エラーの責任。「これはどっちの責任だ」という。
鶴田:そうですね、はい(笑)。お互い原因がわからない状態だと、「おたくが……」みたいなことがますます発生しがちなところではあるかなと思いました(笑)。
堀越:ありがとうございます。せっかくなので、もうちょっとだけこれを引っ張ると、リトライみたいなことをちゃんと考えなければいけないというのもあったりしますかね。
先ほどみたいに、エラーが発生した時に、ある程度タイムアウトしたらリトライしますようなことをよく入れたりします。(そうなった時に)例えば「ポイントの交換の時にリトライが起きたらどうなっちゃうんでしょうね」みたいなことがあったりします。
そうすると、二重で(APIリクエストが)行くのはけっこう大変なことになってしまったりします。(なので)テクニックとしては、ちゃんとIDをつけて、リトライをしても同じIDなので、同じIDが来た場合には撃ち落とすみたいなことをします。まぁまぁ、そういうのはあるんですけど、意外と忘れがちみたいなやつですね。
私もちょっとやったことがあるので、あえて書いています(笑)。
堀越:ちょっとすみません。トラブルもあって時間が経ってしまったのですが、できるだけしゃべりきりたいなと思っています。
そんな感じで、今後の潮流としてシステム連携を見ていく時に、「私はこんなことを考えています」ということを話したいと思っています。
Case3で「APIゲートウェイなしでもなんとかできますね」というところがありましたが、これはやはり後々になって大変だったところがありました。やはり「APIゲートウェイを作っておけばよかったですね」というのが今になっての気持ちです。
実は今はAPIゲートウェイを経由して、先ほどのいろいろな連携を進めていくことも多いのですが、(それでも)やってみると、開発時に「APIをどういう仕様でやりますか?」ということ(による困難)はけっこうあったりします。
やはり人手によるコミュニケーションが中心の世界です。「Swagger」みたいなやつでAPI仕様記述はありますが、細かいところで「こういう条件の時にはどうなるんですか?」という話になってくると、やはり人手が出てきます。(さらに)やはりシステム間の結合テストで初めてぶつけてみて、「ぜんぜん合わねぇじゃん」みたいなことが出てくることがあります。
こういうことがあるので、もうちょっとAPIゲートウェイみたいなものが進化してくれないかなと。(スライドを示して)ここにAPIマネジメントと書いてありますが、今後もシステム連携は数が増えてくるので、そういうところまで(APIによるシステム連携の仕組みで)やっていきたいかなというところですね。
(スライドを示して)そう考えていくと、今後どんな世界が広がっていくのかなと勝手な想像をしていますが、APIゲートウェイ(の進化)がありますね。もともとあった、ぜんぜんシステム間の連携がされていないものがこんな(サイロ)状態です。ちょっとずつシステム連携の数が増えていくと、(スライドのような)進化をしていきます。
APIゲートウェイでやっていると、インフラやネットワークレベルではサポートされていますが、開発や運用がちょっと大変です。
先ほど鶴田さんが言っていましたが、エラーが起きた時に、「どこでエラーが起きていて、どっち側が悪いんじゃい」みたいな話になるので、そこをパッとわかるようにしておきたいとなると、やはりオブザーバビリティみたいになって、(そういう)キーワードの世界が必要になってきます。
そのあたりをやってくれるのが、Integration Platform as a Service、iPaaSと呼ばれているやつです。こういうところに手を入れていかなければいけないのだろうという気がしています。
逆に、このあたりが発達していくとどうなってくるかというと、普通にAPIで(システムが)つながる世界になってくれば、「だったらもうちっちゃいサービスをどんどん作っていけばいいよね」みたいな話になってくるんだと思います。そうなってくると、いわゆる「マイクロサービスでいろいろなシステムを作っていきましょう」みたいな世界になってくるのではないかと想像ができます。
このあたりの「僕たちは今どこにいるんだろうね」「このお客さんはどこにいるんだろうね」ということを考えながらちょっとずつ(システム連携を)やっていくようなことがいいのかなと思ったりします。そろそろで、いったん終わります。
堀越:まとめですね。どうしよう。せっかくなのでここは鶴田さんにまとめてもらおうかな(笑)
鶴田:まとめ(笑)。そうですね。システムを連携させることの価値でいくと、先ほどのただの便利機能の実現ではなくて、コールセンターの応答時間というか、対応時間の話にもありましたが、顧客体験につながってくる部分で、ただの便利機能ではなくて、メイン機能というか、今後のDXでは重要になってくる部分だと思っています。
かつ、2番目のシステム連携アーキテクチャ設計のステップとしては、選択肢をどれだけ持っているかというところで、その選択肢と要件や制約を洗い出して、その選択肢の中からどれが一番いいのかという意思決定をしていきます。
仮に、意思決定というか選択肢の評価がうまくいかなくても、選択肢を多く列挙していけば次善の策、第二の矢が放てるというところが、今回の大きなポイントだったかなと思っています。
堀越:ありがとうございます。むちゃぶりしちゃいました(笑)。すみません。だいたいそんなところだと思います。
そろそろ終わりますが、最後に、今回のこのスライドを作っていく中で、メッセージを1個考えなければいけないなと思ったので、そこだけちょっと表明します。
鶴田さんは残念な顧客体験をしちゃったわけですが、それって誰のせいだと思いますか。
鶴田:誰のせい? そうですね。誰のポカだったかという側面でいくと、Webを作ったITエンジニアや、担当されていた方が忙しい中で一生懸命設計したものだと思いますが、そこでたまたま、ちょっとポカったところかなと思います(笑)。
堀越:まぁまぁ、ポカってというか、もともと難しい(こと)。
鶴田:そうですね。
堀越:在庫の引き当ては私は体験したことないですが、SoR側がああいうことをやると(なると)難しい世界だと思います。でも、もしかすると、あえて言いたいのは、それは鶴田さんのせいかもしれないということです(笑)
なにを言いたいかというと、私たち自身もやはりITエンジニアだと思うんです。ということは、残念な顧客体験を作り上げているのは、やはりその裏側にシステムがあって、それを作っているのはITエンジニアなので、結局自分たちが悪い顧客体験を作り込んでいる可能性があるということなんじゃないかと思っています。
そう思うと、本当に「ただの便利機能じゃないか」とか、「余力がないからちょっとやめておきましょう」というところで踏みとどまっていていいのかなという気がしています。
ITエンジニアは何気にけっこうな力を持っています。顧客体験を変えるとか、世の中をちょっとでも良くするという力を持っていると思っているので、もうちょっとがんばったほうがいいかなという(笑)。
それが顧客体験を変えていく、世の中を変えていくところにつながればいいのかなと思いながらこのスライドを作っていました。
最後にメッセージです。今回マーケティングのような話も少し絡めましたが、電通国際情報サービス(ISID)あるいは電通グループはキャリア採用の応募者を絶賛募集中です。
今回みたいなマーケティングに絡む話や、それに絡めたいわゆるデジタルトランスフォーメーションにもし興味があって「ちょっと話を聞いてみたい」ということがあったら、ぜひお気軽に連絡をもらえればと思っています。
最後にそんなメッセージに代えて、私たちの発表というか、登壇をいったん終えたいと思います。ありがとうございます。
関連タグ:
2024.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには