率直に言いましょう。計画されたピークイベント(ブラックフライデー、主要な製品リリース、年末の確定申告の慌ただしさなど)が発生すると、あらゆる人が、急にシステムに詳しくなったかのように振る舞います。

「注目の視線」が一気に集まります。あらゆる角度から、存在すら知らなかった幹部たちからも次々と質問が飛んできます。データドリブンな企業ほど、ピークイベントでは、迅速かつ簡潔で「今すぐ対応が必要な」回答を提供しなければならないプレッシャーが高まります。

オブザーバビリティは、予想外の質問も含め、こうした多くの疑問に答えるのに最適で、豊富なリアルタイム情報を提供してくれます。しかし、そのデータからどのようにして実用的な洞察を引き出すのでしょうか?いかに迅速に実行し、社内の他のメンバーが実際に理解できる形で提示できるでしょうか?

この記事では、技術領域外の関係者、たとえば業務部門、他のサービスチーム、サプライヤー、さらには消費者に対して、データの収集と提示方法を改善するための手法について説明します。これらのスキルは、ピークを乗り切るのに役立つだけでなく、日々のコミュニケーションを円滑にする上でも役立ちます。

本記事で扱う内容:

  • ビジネス通貨について:企業がすぐに理解できる言葉でコミュニケーションを図る方法について説明します。
  • 「通常」とはどのような状態でしょうか?何が良くて、何が悪いのでしょうか?すべてはコンテキスト次第で、ピーク時にはコンテキストが予期せず変化することがあります。
  • データを知恵に変える - 単なるデータではなく、実行可能な洞察を提供します。
  • 効果的なダッシュボード - 少ないほど効果的:行動を促すダッシュボードに関するヒント。
  • 必要なデータを見つける - 収集済みのデータから得られる洞察に驚くかもしれません。

1. ビジネス通貨について

企業がすぐに理解できる言葉でコミュニケーションを図る方法について説明します。

特に忙しいときは、明確なコミュニケーションが不可欠です。日々の業務では、あなたはデータやそれがサービスにとって何を意味するのかを熟知しています。しかし、チーム外の人とコミュニケーションを取ると、誤解や思い込み、誤った判断が生じる可能性があります。

あなたはPodの退避率やLCPの変動に興味があるかもしれませんが、利害関係者はおそらくそうではありません。コラボレーションを改善するには、技術的なメトリクスを「ビジネス通貨」に変換する必要があります。

「ビジネス通貨」とは何でしょうか?これは、関係者がすでに理解している、成果を測るための実践的な指標です。最終的な成功は財務的な成果ですが、日々の業務での優先事項はより具体的なものです。

それを見つけるには、相手の優先順位を知ることが大切です。リリース速度、平均購入数、支払い失敗、リソースコストのどれに重点を置いているか?あるいは、予約済みのフライトや承認された請求のことかもしれません。

相手の通貨で報告すると、コミュニケーションの摩擦がなくなります。社内の技術的なメトリクスを理解してもらう必要がなくなり、データを見てすぐに行動できるようになります。

通貨タイプの図

2. 「通常」とはどのような状態でしょうか?何が良くて、何が悪いのでしょうか?

すべてはコンテキスト次第で、ピーク時にはコンテキストが予期せず変化することがあります。

典型的な1日では、「通常」がどのようなものかはご存知でしょう。エラー率、平均購入数、1分あたりの売上に関するダッシュボード、SLO、アラートがあります。

ただし、ピーク時のイベントは通常とは異なります。トランザクション数が一気に跳ね上がり、偏った負荷が発生します。ダウンタイムのコストが急騰するにつれて、リスク許容度も変化します。こうした状況では、ピーク時という前提を踏まえて、データを解釈する必要があります

サインインの失敗例を挙げてみましょう。たまに起こる失敗には慣れているはずです。しかし、ピーク時にはこの数値が急上昇し、ダッシュボードが赤くなり、アラートが次々と表示されます。

これは本当に問題なのでしょうか?ログインサービスに不具合がある可能性があります。しかし、ログイン総数が増加し、それに伴ってエラーのも増加している可能性もあります。失敗は健全な範囲内かもしれません。

修正は簡単です。信号を正規化するだけです。個別のカウント(失敗したログイン数)をスループットベースのレート(例:1,000回あたりの失敗したログイン数)に変換します。これにより、それが実際の問題なのか、それともピーク時のトラフィックによる副作用なのかがすぐにわかります。

ピーク時の計画を立てる際には、その状況を踏まえてダッシュボードとアラートを見直してください。それらは依然として正しい情報を伝えていますか?負荷テストはこれを確認する絶好の機会です。高負荷の状況では、「通常」とされる閾値を調整する必要があるかもしれません。

これはピーク時だけの問題ではありません。午後3時には許容範囲内であった注文率でも、午前3時にはシステム停止状態になります。そのような通知で呼び出されたくないでしょう。

これに対処するにはいくつかの方法があります。季節変動の場合は、異常検知または外れ値検出が役立ちます。また、営業時間外の通知にミュートルールを使用したり、時間に合わせて信号を操作したりすることもできます。

たとえば、営業時間中の注文率が低い場合にのみアラートを通知するには、次のようなクエリを使用できます。

FROM Orders SELECT if(hourOf(timestamp) NOT IN ('20:00','21:00',...,'07:00','08:00'), rate(count(*), 1 minute), 10)

これにより、営業時間外は信号を安全な値(10)に設定し、営業時間内には実際の値を報告します。

より包括的なアプローチには、コードとしてのオブザーバビリティ(Observability As Code)(例:Terraform)を使用します。これにより、アラートやダッシュボードの複数の「状態」を定義・管理できます。「通常」、「ピーク」、「休日」の設定を用意して簡単に切り替えたり、トラフィック量に基づいて切り替えを自動化したりすることもできます。

Terraformを使用した状態切り替えの基本的な例は、https://github.com/jsbnr/nr-terraform-posture-switchでご覧いただけます。

3. データを知恵に変える

単なるデータではなく、実行可能な洞察を提供する

多種多様なデータを収集しますが、ただのデータは人間(またはAI)にとって理解しやすいものとは言えません。ダッシュボードはデータを集約してグラフ化することで役立ちます。しかし、単にデータを提示するだけでは、最初のステップに過ぎません。どうすればそれを有意義かつ実行可能なものにできるでしょうか?

シンプルな手法として、「情報ファネル」があります。生のデータを徐々に洗練させ、知識や知恵を加えていくことで、誰にとっても分かりやすく、アクセスしやすく、意味がある、実行可能な洞察へと変えていきます。

このプロセスの実際の簡単な例を見てみましょう...

情報

このバーチャートは、サービスごとのホスティングコストを高い順に並べたものです。まず目が行くのは「product catalog」と「currency service」です。これは単なる情報です。順序付けは参考になりますが、本当の問題に気づいているでしょうか?

知識

この2番目のチャートは、知識。具体的には過去の利用状況を追加しています。これで、先週からのコストの変動が分かります。「adservice」が最も増加していることから、注目点が移りました。

また、閲覧者が数えなくても済むように、概要データ(「より高額な3つのサービス」)も追加しました。「より高額」と「より低額」の意味を定義し、ウィジェットに直接知識を組み込むことで、閲覧者の認知負荷を減らしています。

しかし、ファネルをここからさらに一歩先に進めることもできます...

知恵

この最後のウィジェットでは、ビジネス目標の理解という知恵を応用したものです。サービスは変動しますが、これで予算に対するコストの状況がわかります。「store-frontend」は予算を大幅に超えており、他の2つにも注意が必要です。

アクションを要約し(「1つのサービスは重要であり、対応が必要です」)、さらに重要な点として、リスクをビジネス通貨に換算して「リスクのある総コスト」としました。

自身のダッシュボード、特にチーム外と共有しているものを確認してください。情報ファネルを活用して、単なるデータから脱却し、具体的で行動につながる知恵に変えるにはどうすればよいでしょうか?

4. 効果的なダッシュボード

少ないほど効果的です。行動を促すダッシュボードに関するヒント。

ダッシュボードは情報を共有するための一般的な方法です。New Relicを使用すると、テレメトリーを簡単に表示し、魅力的なビューを作成できます。しかし、ついやりすぎて「情報を詰め込みすぎの」ダッシュボードを構築してしまうことがよくあります。

自分にとっては役立つかもしれませんが、外部の利害関係者がそれをどのように利用するかを考慮することが重要です。

このダッシュボードは誰に向けたものか?

構築前に、この質問に答えることが極めて重要です。誰にとっても便利なダッシュボードを構築するのは非常に困難です。

コミュニケーションを図ろうとしている具体的な関係者を特定し、その関係者専用のダッシュボード(またはページ)を作りましょう。

一貫性と分かりやすさ

すぐに情報が必要な場合は、使い慣れた形式が不可欠です。ダッシュボードの仕組みを理解しようとして時間を無駄にしたくはありません。

車のダッシュボードと同様に、用語、時間枠、ビジネス通貨を統一することで、データを効率的に理解できます。

広く閲覧されるダッシュボードにはスタイルガイドの導入を検討してください。たとえば、重要なデータは左上に、詳細な内訳は2番目のタブに、オンコールの連絡先は右上に表示します。どのようなスタイルを選択する場合でも、一貫性があれば、ユーザーはデータに基づいて迅速に行動することができます。

運用かレポート向けか?

ダッシュボードにはさまざまな目的があります。共通の差別化要因の1つは、リアルタイムの運用データ長期的な傾向レポートです。この2つの目的を1つのダッシュボードで両立させることは稀で、別のページまたは完全に別のダッシュボードに分ける必要があります。

運用ダッシュボードは、現在何が起こっているかに重点を置いています。次のような疑問に答える必要があります。

  • 緊急事態は発生しているか?
  • 状況は悪化しているか、改善しているか?
  • 問題はどの程度広がっているか?
  • ビジネス影響はどのようなものか?

レポートダッシュボードでは、より長い期間を見通し、次のような傾向に焦点を当てます。

  • 時間の経過とともにパフォーマンスは低下したか?
  • SLO(サービスレベル目標)は達成できているか?
  • 今週のビジネス状況は先週と比べてどうか?

これら2種類のダッシュボードは、デフォルトの時間枠と優先順位が異なります。これらを別々に管理することで、閲覧者を混乱させずに済みます。

実行可能か?

見栄えのよいダッシュボードも便利ですが、実用的な洞察を提供するダッシュボードこそが理想的です。ウィジェットを追加する際には、「このグラフはどのような質問に答えているのか」を自問自答してみましょう。

たとえば、キャンセル率に関するデータがあるとします。各レストランのキャンセル率をリストアップすれば、「各レストランのキャンセル率はどれくらいか?」という問いに答えられます。

しかし、より適切で実行可能な質問は、「懸念すべきキャンセル率のレストランはどこか?」です。情報ファネルから学んだように、この事前に整理された思考により、データをはるかに実行可能なものに変えてくれます。

意思決定に役立つか?

個々のチャートは実用的な場合もありますが、意思決定には集約されたデータが必要になる場合もあります。必要な情報をすべて1か所に集めたダッシュボードは非常に強力です。

たとえば、新しい機能を導入する前に、依存関係の健全性を把握する必要があります。「デプロイ準備」ダッシュボードでは、これを一目で確認できます。情報ファネルを使用して、可能な限りシンプルなデータを表示することもできます。すべてが緑色になります。

できるだけシンプルに!

KISS原則はダッシュボードにもよく当てはまります。「便利な」ウィジェットを次々と追加したくなりますが、他の人を混乱させるだけかもしれません。

経験則として、ダッシュボードの複雑さは、そのユーザー数に反比例するべきです。自分だけのために使うのであれば、好きなだけ複雑にしても構いません。組織全体が見るダッシュボードでは、ウィジェットを最小限に抑えましょう。

明確さと文書化

「OMSオーバーフロー脱落率:6.8」—これはあなたにとっては意味のあることですが、他の人にはまったくわからないかもしれません。

これを「注文が期日通りに発送されない」などのビジネス通貨に変換してみてください。それができない場合は、良い点と悪い点を示すヒント(ガイドラインや色分けなど)を提供します。また、マークダウンウィジェットを使用して、メトリクス、それが重要な理由、それぞれの値がビジネス運営にどのような意味をもたらすかを説明することもできます。

より広範囲に共有

ダッシュボードをより幅広いユーザーに公開するのは簡単です。一部の顧客は、外部向けのダッシュボードにリンクする「インデックス」ダッシュボードを構築しています。「ダッシュボードの共有」機能を使用して、New Relic外部のサプライヤーやパートナーとデータを共有することもできます。

5. 必要なデータを見つける

収集済みのデータから得られる洞察に驚くかもしれません。

オブザーバビリティデータには豊富な洞察が詰まっています。エージェント、OpenTelemetry、ログフォワーダーなど、どのようなデータであっても、これらのデータはシステムパフォーマンスとビジネスそのものの両方を理解するのに役立ちます。

日々、システムの健全性と可用性のメトリクスを監視しています。しかし、すでに説明したように、これらのメトリクスは外部の利害関係者にとっては意味をなさない場合があります。そこで重要なのは、データをビジネス通貨に関連付けて解釈する必要があります。少し工夫すれば、既に収集しているテレメトリーからビジネスレベルのデータを導き出すことができる場合が多くあります。

では、具体的なソースをいくつか見ていきましょう。

リアルユーザー監視(BrowserとMobile)

当社のBrowserおよびMobileエージェントは、実際のユーザーからのデータを報告します。PageViewMobileなどのイベントは、サービスをどのように(そして誰が)利用しているかに関する豊富な情報を提供します。このデータを使用すると、トラフィックの地理を把握したり、ユニークユーザー数をカウントしたり、セッションを調査したりすることができます。

たとえば、uniqueCount()関数を使用して、セッションIDに基づいて現在サイトを閲覧しているユーザー数をカウントできます。

FROM PageView select uniqueCount(session) since 10 minutes ago

APMトランザクション

APMエージェントからのトランザクションイベントは、アプリケーション内の個々の作業単位を表します。これにより、データベース呼び出しや、特定のアクティビティのスループットやパフォーマンスを詳細に分析できます。

トランザクション名は、多くの場合、ビジネス目的に合わせて設定されます。たとえば、/payment/declinedというトランザクションの件数をカウントし、失敗した支払いのリアルタイム指標として活用することができます。

必要な情報がさらに深く埋もれている場合もあります。製品IDがrequest.uri属性に含まれている場合があります。この場合、そのデータを抽出する必要があります。NRQLには、aparse()capture()などの役立つ関数が用意されています。

たとえば、URIが/product/detail/hitachi-air-fryer/242234/viewのような場合、製品名を抽出し、最も人気のある製品をグラフ化できます。

WITH aparse(request.uri,'/product/detail/*/%/%')as productName
FROM Transaction
SELECT count(*) as productViews
FACET productName

ログの活用方法

アプリケーションログは常に豊富なデータソースです。ビジネス運営に直接関連する情報が見つかることもよくあります。

ここでもaparse()capture()を使用できます。また、取り込み時の解析を使用してログを構造化データに変換すると、クエリの実行が容易になります。

取り込み時の自動解析では、ログの構造を定義することで、自動的にデータを抽出できます。たとえば、次のログ行を考えてみましょう。

claim submitted: type=insurance riskValue=400000 price=35.99 customerProfile=A457X

次の解析ルールを使うことで、ログを構造化されたレコードに変換します。

claim submitted: type=%{WORD:type} riskValue=%{NUMBER:riskValue} price=%{NUMBER:price} customerProfile=%{WORD:customerProfile}

結果:

{
  "riskValue": "400000",
  "price": "35.99",
"customerProfile": "A457X",
  "type": "insurance"
}

ログデータにはJSONエンコードされたデータも含まれる場合があります。その場合は、クエリ時にjParse()を使用してさらに抽出することができます。

データの強化

テレメトリーには十分な情報が含まれていますが、実際に実用的なデータにするには、より多くのビジネス上のコンテキストが必要になる場合があります。データを強化することで、その価値を大幅に高めることができます。

収集時またはクエリ時にデータを強化できます。収集時に、エージェントSDKを使用してカスタムアトリビュートまたはイベントを追加できます。たとえば、チェックアウト操作にユーザーのロイヤルティステータスを含めることができます。

クエリ時には、結合とルックアップを使用できます。これにより、共有キーを介してさまざまなデータを結合できます。たとえば、デポの位置データを含むルックアップテーブルをアップロードし、それをdepotIDでテレメトリーと結合することで、マップ上にデポをプロットすることができます。

オブザーバビリティは、エンジニアにとって単なるトラブルシューティングツールではありません。特にピークシーズンの混乱時には、ビジネス全体にとっての唯一の信頼できる情報源となります。技術的なメトリクスをビジネスで利用可能な情報に変換し、「通常」とは何かを明確化し、生のデータを実用的な情報に変えることで、単にデータを提示するだけでなく、実際の行動を促すことができます。シンプルで分かりやすいダッシュボードを構築し、収集済みのデータを工夫して活用することで、ピークシーズンをうまく乗り切るだけでなく、年間を通じて、主要な関係者とのコミュニケーションもより明確で効果的なものになります。

小売業界がピーク時のトラフィックをどう乗り切っているか、ご興味はございませんか?本ガイドでは、混乱から明確さへと変えるための具体的な方法を説明しました。それでは、小売業界全体の現状を見てみましょう。

同業他社がピーク時のトラフィックの課題にどのように取り組んでいるか、どこにオブザーバビリティリソースを投資しているか、どのようなビジネスメリットを実現しているかをご覧ください。
無料レポートを読む:2025年小売業界におけるオブザーバビリティの現状

今すぐレポートをお読みください: 
https://newrelic.com/resources/report/state-of-observability-for-retail-2025