クレディセゾン、アクセンチュア、日本IBMに聞く、「オブザーバビリティー」が運用高度化、ビジネス貢献に効く理由：「可視化されたデータ」が全関係者の共通言語になる

社会全体にデジタル技術が浸透し、ITサービスの提供品質が企業の収益、ブランドを左右する時代になって久しい。こうした中で注目されているオブザーバビリティー（可観測性）だが、ITサービスの提供品質、ひいてはビジネスにどう貢献するのか。その意義と実践のポイントを聞いた。

PR／＠IT

PR

　およそ全てのビジネスをデジタル技術が支える今、顧客接点や業務遂行手段となるITサービス／アプリケーション（以下、アプリケーション）の「開発・運用」が「ビジネス展開」と同義になって久しい。だが、昨今はニーズの変化に対応する「開発のスピード」だけではなく、安全性や安定性、「ユーザーが快適に使えているか」といったリリース後の運用品質も問われている。事実、アプリケーションのレスポンス遅延が機会損失や信頼失墜を招き、社会問題となった例も珍しくない。

　こうした中、「オブザーバビリティー」（可観測性）を実践する企業が着実に増えつつある。では、注目を集めている理由は何か。従来の「監視」とは何が異なるのか。ビジネスにどう貢献するのか。オブザーバビリティーの実践者であるクレディセゾン、IT課題に深い知見を持つアクセンチュア、オブザーバビリティーの導入・支援に多数の実績を持つ日本IBMの3社を招き、その意義と実践のポイントを聞いた。

オブザーバビリティーが注目されている背景とは

モデレーターを務めるアイティメディアの内野宏信（統括編集長）

アイティメディアの内野宏信（以下、内野）　社会全体にデジタル技術が浸透している今、質の高い顧客体験を実現できるアプリケーション開発やシステム運用の在り方が改めて問われていると思います。今の経営環境におけるこれらの重要性を、アクセンチュアの中さんはどう見ていらっしゃいますか？

アクセンチュアの中寛之氏（以下、中氏）　従来は「システムを安定運用できているのか」がIT部門の主たる関心事でしたが、コロナ禍を経たこの5年ほどの間に、ユーザーの目線に立って「サービスとしてきちんと使えているか」をチェックすべきだという認識に変わってきたと思います。中心となっているのはITが直接顧客サービスにつながっている企業です。ネット上で評判が瞬時に拡散されることもあり、品質劣化が自社やサービスの評価を毀損（きそん）することに非常に敏感になっています。

　しかし従来の監視ツールだと「サービスとして適切な品質で提供できているか」をチェックする機能が不足している。これを受けてオブザーバビリティー製品を導入する企業が増えつつあると見ています。実際に使ってみて、「サービス品質をチェックするとユーザーに良いアピールができそうだ」「ITによるビジネス貢献の成果を表しやすい」といった認識を持ち、さらに導入が広がっているように思います。

内野　一般に、IT部門はビジネス部門と分断された状態で活動してきました。それがオブザーバビリティー製品によって、ようやくITとビジネスをひも付けて議論できるようになってきたと。

中氏　そう考えます。ここで触れておきたいのはITSM（ITサービスマネジメント）に加えて、この3年ほどで「ITエクスペリエンスマネジメント（ITXM）」という概念が台頭してきたことです。これはまさに「ITサービスの利用者が満足しているかどうか」を評価の中心に置いたフレームワークです。オブザーバビリティーは「サービスの利用者が満足しているか」を「客観的なデータで証明する手段」として有効なんですね。

内野　ただ、データでITサービスの提供品質を把握できても、それがビジネスに与える影響をうまく翻訳して伝えるスキルは必要ですよね。

アクセンチュアの中寛之氏（プリンシパル・ディレクター ビジネス コンサルティング本部 コンサルティンググループ テクノロジーストラテジー＆アドバイザリー プラクティス）

中氏　これまでの運用課題はそこにあります。ITサービス／アプリケーションを支えるITシステムのことを分かっている人が、サービスオーナーであるビジネス・サイドの方に、どう必要な情報を伝えるのか。「伝える努力」をIT側が行う必要があったんですが、その努力も少なくなっていくと考えます。「必要な情報は必要とする人が自分で取ってくる」時代に変わっていくからです。具体的には、オブザーバビリティー製品による各種データを基に、ステークホルダーの各組織、各役割の人が、それぞれ必要な情報が取れるダッシュボードを用意し、適切な情報を基に関係者間で判断を下す、判断が難しい場合はAIを利用して示唆を取り出す、といったことが可能になっているからです。

　また、データから示唆を取り出して障害の予兆を分析し、事前に手を打つプレディクティブ・アナリシスには、これまで一定の分析スキル、手法が必要でしたが、AIが急速に発達している中で、「データから傾向を予測する機能」が発展していくと考えます。その機能を使いこなした上で、ビジネス側をはじめサービスの各関係者と対話して改善を推進する力を持つ人材が今後は重要になってくると思いますね。

「監視」とは何が違うのか

内野　IBMではオブザーバビリティーの浸透度をどう見ていますか。

日本IBMの堤康広氏（プロダクト・マネージャー テクノロジー事業本部 オートメーション・プラットフォーム事業部 製品統括部）

日本IBMの堤康広氏（以下、堤氏）　日本ではまだばらつきがありますが、DevOps実践企業ではオブザーバビリティー製品が必須になってきていると思います。われわれが製品を提供し始めた4年前は「言葉すら知らない」という方が多かったんですが、今は「知らない」方はまずいらっしゃいません。ただ「自分たちにはまだ早い」とか「監視との違いが分からない」という方はいらっしゃいます。しかし2024年までとは大きく違って、「自分たちの運用を高度化したい」というお客さまが急に増えてきたのは確かです。

内野　背景には何が。

堤氏　経営層など組織の上のレイヤーの方が、「オブザーバビリティーの有用性について検討してほしい」と指示をしている可能性が考えられます。というのも、AWS Summitなどのイベントでブースを出展すると、「AIを使った運用高度化の方法は」とか「オブザーバビリティーに興味がある」というお客さまが多数お越しになって列を作る状態でした。2024年まではあり得なかったですね。うれしい悲鳴を上げている状態ですが、確実に変わってきたなと肌で感じています。

内野　昨今はアプリケーションのレスポンスが遅延したり、停止したりすると即ニュースになることが多い。アプリケーション＝ビジネスという認識が広がってきたのかもしれませんね。では先ほども話に出た「監視との違い」を改めて教えていただけますか。

堤氏　従来の監視は、死活監視をベースに、個々のシステムがきちんと稼働しているかどうかを確認するものです。点と点をそれぞれ確認していました。ただ、アプリケーションはエンド・ツー・エンドでリクエストが流れていきます。その途中にある色んなコンポーネントの動きによって1つのリクエストが完結する。レスポンスが遅ければ顧客がそのサービスから離れてしまうこともありますし、障害が起きれば当然ビジネスはそこで終わりです。その「どこからどこまでに、どのくらい時間がかかったのか」「障害が起きたときに、どこでどんな障害が起きているのか」を知る必要があるわけです。

　オブザーバビリティー製品は、それら全てを対象にして「どこで何が起きているのか」をインフラのレイヤーからアプリ、コードのレベルまでフルスタックで把握できるようにするものです。長年の現場経験がある人の勘とか知識に頼っていたものが、ダッシュボードを通じて関係者全員が同じ結果を、瞬時に数値で把握できるようになる。だから「知識や経験の違いによって見方や答えが変わる」こともない。

　障害が起きた際も即座にビジネスインパクトを測れます。「このサービスがどれだけ止まったのか」すぐ分かりますし、「この障害でどれだけの顧客が離れたのか」をユーザーベースで把握することもできる。障害後のトラッキングも当然しやすい。ビジネスインパクトを「本当の意味で測る」のはオブザーバビリティーなしでは難しいと思いますね。

内野　ITXMもこれがないと難しいでしょうね。

中氏　従来の監視ツールでは機能的にどうしても実現できない部分がありますね。堤さんがおっしゃったように、オブザーバビリティー製品と呼ばれているものはエンド・ツー・エンドで監視します。特徴は、1つの機能として外形監視を実現することです。だからこそユーザー目線でサービスパフォーマンスを見ていける。そこからさらに機能を強化して、インフラまで含めてシステム全体を把握できたり、アプリの品質を管理できたりと機能が広がってきた印象です。

アプリ、インフラ、ビジネス―――全関係者で「ファクト」を可視化、共有

内野　では実際にオブザーバビリティーを実践されているクレディセゾンさんに話を聞いてみましょう。まず外形監視から取り入れたという話ですが、経緯を教えていただけますか。

クレディセゾンの小野和俊氏（取締役 兼 専務執行役員CDO 兼 CTO）

クレディセゾンの小野和俊氏（以下、小野氏）　われわれがオブザーバビリティーの概念を取り入れたのは、2019年3月1日に内製組織を一から立ち上げたのがきっかけです。内製組織を作ったのは、ビジネスにおいてデジタルがここまで重要になっている時代に、開発・運用をベンダーに全て依存することはあり得ないと考えていたからです。自分たちでサービスを作っていくからこそ、内部監視だけでなく外形監視の環境も整えて、ダッシュボードでビジネス・サイドと状況を共有していこうと。

　それ以前は基本的に開発、運用は外部ベンダー依存で、月1でレポートを確認したり、障害発生時に対応を支援いただいたりという形でした。ただ、対応がどうしても事後的になってしまう。予兆検知して事前に対策しておくことでパフォーマンスの劣化を防ぐ、その先にある障害を防ぐといったことができていなかった。アプリケーションの運用を改善するには、解像度高くいろんなことを把握する必要があるという課題感がありました。

内野　アプリケーション＝ビジネスになっている。そうした中で外部の力を借りないと稼働を担保できないというのは確かに怖い話です。そういう危機感があったんですか。

小野氏　いや、餅は餅屋でシステム専門の人たちが開発・運用を担ってくれるわけですし、それはそれで合理的な考え方だったんだと思います。ただ、そうした環境では「自分たちがサービスを作って運営していくんだ」「ビジネス・サイドも含めて自分たちで状況を把握するんだ」といった主体性がどうしても芽生えにくい。

　といっても、そういう課題感からオブザーバビリティーを入れようとなったわけではありません。2019年ですから堤さんがおっしゃるように当時はオブザーバビリティーという言葉すらあまり聞かれなかった頃です。あくまで「僕らが作るものはちゃんと可視化しよう」「何かあればすぐ気付けるようにしよう」「何かあれば担当者にリアルタイムでメンションが飛ぶようなモダンな運用をしていこう」といった内製組織としての意識から始まりました。

　最初に実践したのはスマホアプリのキャンペーンです。ダッシュボードでリアルタイムにさまざまな情報を把握できるようにしました。すると、ミッションクリティカルシステムを担当していた情報システム部門から「なぜそんなに早く問題に気付けるのか？」と驚かれたんです。そこで「ちょっとうちのダッシュボード見てみます？」と画面を見せると、「何ですかこれ！　こっちのシステムでもできますか」となり、多くの社内システムに自然に浸透していきました。

内野　情報システム部門の方にとって新鮮な驚きだったわけですね。

小野氏　取り組みが加速した要因は他にもあるんです。2019年に内製組織を立ち上げた当初は、自分たちのアプリの内部監視、外形監視をしていた。その中に非常に当事者意識が高いスタートアップ出身のメンバーがいましてね。リクルートさんの社内用語に「圧倒的当事者意識」という有名な言葉がありますが、僕はさらにその先に「あふれ出る当事者意識」というものがあると思っていて、彼は他部門が主幹しているECシステムでも勝手に外形監視を始めたんですよ（笑）

一同　すごい（笑）

小野氏　一般的には、こうした行為は嫌がられますよね。それでも彼は外形監視の結果、「夜間にレスポンスが落ちている」ことを見つけ、それを土曜の夜に主幹部門のSlackチャンネルに勝手に報告した。主幹部門からは私宛てに「何なんですか彼は」と連絡が来ましたが、その後精査してみると、レスポンスが落ちていた時間帯に確かに売り上げが落ちていたことが分かった。その後、主幹部門は機会損失を減らす対策を講じ、内製チームは「すごく助かりました」と感謝されることになったんです。“あふれ出る当事者意識”が外形監視の網をあちこちに張り巡らせて、その価値に気付いたビジネス部門が網の範囲をさらに拡大させていった形です。

内野　ダッシュボードには何を表示していたんですか。

小野氏　システムだけでなく、サービスに関わるほとんどのデータを表示していました。例えばセゾンカードでは以前、抽選で1万人に現金1万円が当たる「セゾンのお月玉」というキャンペーンがありました。当時は「抽選券は何枚で、対象は何万人いるのか」「抽選券が何枚だった人は翌月どのくらいリテンションしているのか」なども監視していました。それらにサイトのレスポンス・タイムなどシステムのKPIを組み合わせて、一体的に見られるダッシュボードを作っています。現在はそれらに加えて、 サイトのパフォーマンスを見て心配したビジネス・サイドの担当者がシステム側に声を掛けることもあれば、その逆もあります。

　当初は外形監視から始めましたが、今はコンテナのAPIを監視して「負荷が増えているから事前にリソース割り当てを調整する」といった予防保守や予兆検知もできています。これは従来の運用体制では不可能で、状況を高い解像度で把握できるオブザーバビリティーの成果です。

オブザーバビリティーという「新たなやり方」にどう取り組むか、浸透させるか

中氏　まさに「百聞は一見に如かず」ですね。特に技術者はワクワク感をもって仕事をしたいという方が多いですから、それが生かされているのは重要なポイントだと感じました。また、クレディセゾンさんのようなバイモーダル組織では、モード1、モード2、それぞれの強みをビジネス・サイド含めて共有し合う仕組みが重要ですが、その共通言語になるのがオブザーバビリティーですよね。

（注）バイモーダル：基幹システムなど高度な安定性・可用性が求められる領域のシステムを担う部門と、新規ビジネス創出などスピードと変化対応力が求められる領域のシステムを担う部門が共存してビジネスを推進するIT戦略の考え方

小野氏　その通りですね。ビジネス・サイドとシステムサイドの共通言語としてのダッシュボードもあるし、モード1とモード2の共通言語としてのダッシュボードもある。オブザーバビリティーによって分かるデータはファクトなので、堤さんがおっしゃったように知識、経験、価値観の違いによって見方が変わるということが一切ない。強力な共通言語になると思います。

内野　ただ、クレディセゾンさんではそうした「新しいやり方」がスムーズに組織に広がっていきましたが、たとえメリットがあると分かっていても、一般的には変化に抵抗を感じる方も多いと思います。例えば運用自動化でも「仕事がなくなる」と懸念する向きは多い。

小野氏　DXの取り組み全般にも当てはまることですが、私たちは否定的なやり方や破壊的なやり方は一切していません。従来のやり方には合理性があります。そこに敬意を払いつつ「違うやり方もあるからちょっとやってみるね。もし賛成してもらえたり、自分たちもやりたいと思ったりしたら、ご一緒しましょう」というスタンスです。そこで重視しているのが、ORではなくANDで進めることです。オブザーバビリティーを従来の監視に置き換えるのではなく、従来のやり方に加えて、ちょっとしたダッシュボードを作ってみる。体験は情報量が多く、取り組みの第一歩として重要です。

内野　やはり「こんなことができるのか」という発見や納得感がカギなんですね。

堤氏　 そうですね。実は私も過去に運用部門で長く働いていた時代があり、既存の勢力と戦った経験があります。実際、自動化を取り入れたときには「仕事がなくなる」と散々言われました。でも、そんなことは全くないんです。ITには山ほど仕事があります。やり方を変えて、一つ課題を解決すればまた新たな課題が出てくる。そうした取り組みを通じて、成果を見せ、そこに価値を感じていただけると人のマインドは変わるんです。「やってよかった」となれば「じゃあ次は何やろう」と、どんどん運用高度化に向けて進んでいける。

　オブザーバビリティーも同じです。われわれのお客さまでも、スムーズに導入されている方々は口をそろえておっしゃいます。「やるべきことを一つずつ進めていっただけだ」と。本当はIT部門の人間もビジネスの観点を持っているはずなんです。でも日々の忙しさに埋もれて新たなことを何もできなくなっている。ですから、まずは取り組みを開始できるかどうか。抵抗を受けたら誰かがサポートしてあげられるかどうか。そこがカギなんです。マネジャー層は変わっていく「きっかけ」を作ってあげることが重要だと思います。

内野　それは抵抗勢力と戦っていた当時の、まさに堤さんご自身のお気持ちだったわけですよね。ただ、運用部門というと「動いていて当たり前」と周囲からは減点法で見られている。ただでさえ多忙な中、新たなことはしたくないという気持ちも分かる気がしますが。

堤氏　分かります。運用部門は何か障害が起きたらまず疑われますから。私も散々経験しました。それでつるし上げられる。で、調べたら原因はアプリでした、みたいな（笑）。

一同　あるある（笑）

堤氏　私の経験上、10件中7〜8割はアプリの問題だったのですが、残りの2〜3割があるので時間と工数をかけて原因を究明して身の潔白を証明するしかない。そうしたときもオブザーバビリティー・ツールがあると、ダッシュボードを通じてリアルタイムに稼働状況が見られますし問題原因まで瞬時に分かる。

　予期せぬ副次効果が生まれたというお客さまもいらっしゃいます。例えば、ある金融系のお客さまでは、これまでアプリ部門とインフラ部門に垣根がありましたが、ツール導入によってリアルタイムで同じダッシュボードを参照できるようになった。そのためツールを介した迅速な対応が可能になり、開発スピードが上がったという例もあります。障害発生時にいち早く根本原因にたどり着いて障害を短期間で解決できた、という声はもちろん多くいただいています。

内野　アプリのビジネス貢献度をみんなで見られる。そのためBizDevOpsのような取り組みも自然発生的にできるようになる。運用部門の方も、身の潔白を証明できるだけでなく（笑）、自分たちがどうビジネスに貢献しているのか、どうアプリを守っているのかを可視化でき、おのずと存在感が高まっていくわけですね。

堤氏　ただ一方で、まだオブザーバビリティーに取り組んでいない企業の方に「アプリケーションの品質低下や障害が、どの程度の機会損失につながっていますか」と聞くと、ほとんどのお客さまが答えられません。これでは本当の意味でのITのビジネスへの貢献度やROIは分かりません。インフラ、アプリ、ビジネスが一体となって機会損失を発生させない取り組みを進めていくべきだと思います。

アプリの稼働状況だけではなく、ROIも可視化できる

内野　では最後に、組織にオブザーバビリティーを取り入れていく上でのアドバイスをいただけますか。

小野氏　ITの世界では、ツールが概念を教えてくれるということがあります。例えば、テスト駆動開発（TDD）の概念から入ってJUnitを使い始める人もいれば、JUnitを現場で使ってTDDの感覚を自然に身に付けた人もいる。オブザーバビリティーについても、概念は知らなくても、みんなで同じデータを見て、ビジネス・サイドやシステムサイドのKPIを把握して、そこからアクションを起こす人がいれば自然と取り組みは進んでいきます。

　一方、技術面で言えば、われわれの場合、内製システムはメトリクスやログ、トレースなど何でも組み込めるため、内部監視、外形監視を入れやすかったんですが、外部ベンダーが提供するシステムへの導入は課題でした。責任分界点の関係でベンダーが運用する部分に手を入れるのは限界があるからです。ただ、オブザーバビリティー製品は「フルスタックで入れる」一択ではなく、われわれのように外形監視から始めることもできる。まずはビジネス、インフラ、開発、全関係者にとって重要な数値からダッシュボードに表示してみて、みんなで小さな成功体験を作っていくことが第一歩になると思います。

中氏　ツールをきっかけに業務を変えていくことはとても大事な視点です。かつてPoC（概念実証）疲れという言葉がありましたが、私がよく言うのはPoCではなくパイロットから始めることです。パイロットとは小野さんがおっしゃる「小さな成功体験」のことで、PoCのように試行と本番を区切るのではなく、そのまま本番に移行できるような取り組みです。育てていく前提で、最初から目的意識を持って取り組みを進める。そのためには予算も必要ですから、小さな成果を積み重ねて毎年少しずつ予算を確保し、取り組みを継続することが重要です。

堤氏　提案する側としても、スモールスタートで始め、価値を出すことに力を入れています。PoCも無料で実施していますが、最近はPoV（価値実証）を重視しています。実際に触っていただくと、これまでの常識や先入観が覆るのです。「何でもっと早く教えてくれなかったの」というお客さまも多くいます。長くインフラ管理の仕事をしてきた私自身の経験からしても、当時これがあれば本当に良かったのにと思えるほどです。

IBMのオブザーバビリティー・ソリューション（提供：日本IBM）《クリックで拡大》

　また、最近はFinOps（クラウドのコスト管理）もオブザーバビリティーの対象となり、アプリケーションに対するインフラリソースの費用対効果を可視化して自動的にリソース／コストを最適化するなど、アプリからオンプレミス／クラウドというインフラのレイヤーまで、また各種管理ツールからの情報も含めてIT環境全体を管理する「フルスタック・オブザーバビリティー」に概念が変化しつつあります。IBMは「IBM Instana Observability」や「IBM Turbonomic」を通じて、フルスタック・オブザーバビリティーの実現を支援していますが、実際にツールの力を見て価値を実感できればマインドや文化が自然と変わっていくはずです。

　まずは興味を持ったところから一歩踏み出していただきたいですね。「やってよかった」「次は何をやろう」と、どんどん運用高度化が進んでいく、ビジネスに貢献できるIT組織になれると思います。IBMも全力でサポートさせていただきます。

左から、アイティメディアの内野宏信、クレディセゾンの小野和俊氏、アクセンチュアの中寛之氏、日本IBMの堤康広氏