Blog
ブログ

顧客の期待値の変化

ここ数年、顧客からの要求が大幅に増加し、カスタマーサービスの担当者はプレッシャーを感じています。最近のZendesk CX Trendsレポートによると、68％の担当者が腰が引けてしまっていると感じているそうです。PagerDutyでは、カスタマーサービス担当者がより幸福であれば、顧客との交流がより前向きになり、ブランドとの関係もより強固になると考えています。

カスタマーサービスチームがこの問題に対処できるよう、PagerDutyはZendeskとのインテグレーションを深め、カスタマーサービスチームが可能な限り迅速かつ効率的にインシデントを解決できるよう支援し続けています。最新のリリースでは、PagerDuty Automation ActionsがZendeskのPagerDutyアプリケーション内で利用可能になった ことを発表でき、嬉しく思います。

自動化でカスタマーサービス担当者を強化する

PagerDuty Automation Actionsは、レスポンダーをPagerDuty内の修正オートメーションにつなぐことで、インシデントの診断と修復を迅速に行うことができます。Zendesk向けPagerDuty Applicationの最新リリースでは、担当者が自動的に問題を検証し、チームが診断して解決するための重要な情報を即座に取得することができます。

担当者は、顧客に影響を与える問題を検証し、Zendesk用のPagerDutyアプリケーションから直接自動化アクションを実行する権限を与えられています。これにより、問題解決にかかる時間を短縮し、問題解決チームのために重要な顧客情報を即座に追加することでバックエンドチームの負担を軽減します。また、エンジニアリングチームにエスカレーションされる問題の数を減らすことができます。例えば、緊急性がない場合や、お客様がサービスを利用する上で影響がない場合などです。

Automation Actionsで、カスタマーサービス担当者の負担を軽減

カスタマーサービス担当者は、急増する仕事量を増やすことなく、重要なインシデントに対処する権限を与えられなければなりません。自動化は、その負担を軽減し、チームがより多くのことを行えるようにするのに役立ちます。ここでは、自動化が担当者の日常を楽にするためのいくつかの方法を紹介します。

自動化は、繰り返される類似の問題に対する一貫した対応を確立するのに役立ちます。プロセス改善のための事後報告にも有用です。 カスタマーサービス担当者がケースに対応する際の効率を向上させられます。 解決までの時間を短縮できます。 顧客との関係構築と維持に、より多くの時間を割けるようになります。 顧客からのプレッシャーにさらされたケースに対応する際に、担当者が手作業で行わなければならないミスの可能性を自動化によって減らせます。

PagerDuty Automation ActionsとZendeskの連携について詳しくは、PagerDutyのナレッジベースをご覧ください。また、アカウントマネージャーに連絡するか、今すぐデモをリクエストすることができます。

この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

PagerDuty Operations Cloudの新しいアップデートと機能拡張を発表できることを嬉しく思います。PagerDuty Summitの成功を受けて、製品のいくつかの領域で開発が続けられています。製品チームからの最近のアップデートには、インシデントレスポンス、PagerDuty® Process AutomationとPagerDuty® Runbook Automation、パートナーインテグレーションとエコシステム、そしてコミュニティーとアドボカシーイベントのアップデートが含まれています。インシデントレスポンスの自動化を支援し、他のチームにエスカレーションされる問題の量を減らすことに加えて、次のことが可能です。

-Incident ResponseとService Standardsの間の一貫性と予測可能性を向上させます。 PagerDuty CloudWatch Logsプラグイン、Systems Managerプラグイン、ECS Remote Commandプラグインなど、最新のPagerDuty® Process AutomationとPagerDuty® Runbook Automation AWS Plugins for Automated Diagnosticsについて説明します。 最近リリースされた他のAWSプラグイン（ECSとLambda）やAnsibleプラグインのアップデート、PagerDuty® Process AutomationとPagerDuty® Runbook Automationの多数のコアおよび商用アップデートに関する詳細を最新の4.4.0リリースでキャッチアップすることができます。 PagerDuty App for Slackの改良を含む**、最新のパートナー統合とエコシステムのアップデートをお楽しみください。次世代Slack V2 専用インシデントチャンネルの改善（早期アクセス）およびWebhooks V3など PagerDuty App for ZendeskのAutomation Actions** により、カスタマーサービスエージェントの生活を改善し、解決までの時間を短縮し、エンジニアリングチームへのエスカレーションを削減します。 製品廃止のお知らせ** とユーザー管理画面のコールトゥアクションで常に最新情報を入手 今後のイベントに登録し、最近のポッドキャストやTwitchストリームを閲覧し、コミュニティチームや製品チームのメンバーと一緒に新製品やソフトウェア業界のリーディングプラクティスを学ぶことができます。

インシデントレスポンス Service Standards Service Standardsは、チーム全体で「良い」とは何かを標準化する基準を定義することで、運用の成熟度を高め、より良いカスタマーエクスペリエンスを提供できるようになります。ベストプラクティスに従ってサービスを一貫して構成し、インシデント対応時の予測可能性を向上させます。組織全体にわたってサービスの所有権を拡大します。サービス設定の精度を向上させることで、分析機能を強化します。管理者とアカウント所有者は、デフォルトでサービス標準を表示できますが、権限を調整して、全てのユーザーが表示できるようにすることもできます。

検索機能の強化 全スケジュールとチームスケジュールの切替 詳細度に合わせて情報を折りたたんだり、拡大したりすることができます。 タイムウィンドウ表示によるスケジュール比較の容易化 オンコール対応者をシフト時間と共に効率的に表示

ナレッジベースで詳細をご覧いただくか、オンデマンドでウェビナーをご覧ください。

Service Standardsのデモ映像はこちらからご覧いただけます。

PagerDuty® Process AutomationソフトウェアとPagerDuty® Runbook Automation

自動診断のための新しいAWSプラグイン あなたのアプリやサービスはAWSにありますか？もしそうなら、AWS上のインシデントをより速く、より効率的にトリアージするのに役立つ自動診断のためのAWSプラグインを用意しました。これらの新しいプラグインは、既存のライブラリーに追加されます。

更新内容は以下の通りです。

CloudWatch Logsプラグインは、AWSインフラストラクチャーとアプリケーションから診断データを取得します。これにより、ユーザーはより簡単に、複数のアカウントや製品にまたがるAWSの自動診断を実行できるようになりました。

Systems Managerプラグインにより、構成管理、パッチ適用、監視およびセキュリティーツールエージェントの展開などのタスクをより迅速に実行し、正確に実行することができます。運用者は、セキュリティーのベストプラクティスを備えた単一のインターフェイスで、グローバルなEC2フットプリントを表示および管理できるようになりました。 ECS Remote Commandプラグインは、コンテナ上でコマンドを実行するための機構を提供します。これにより、開発者や運用者は、サービスを再展開する前に、実行中のアプリケーションからリアルタイムに診断データを取得することができます。

ブログをお読みいただくか、お問い合わせください。

PagerDuty®プロセスオートメーションソフトウェアとPagerDuty® Runbookオートメーション リリース4.4.0

商用製品ユーザーは、LambdaとECS（Fargate）の新しいAWSジョブステッププラグインを利用できるようになりました。

詳細はこちら

Lambda Custom Code Workflowステップでは、Jobステップで提供されたカスタムコードを入力として、新しいLambda関数を作成、実行、オプションで削除することができます。Runbook Automationのユーザーにとって最も有利なのは、ソフトウェアをインストールすることなく、カスタムスクリプトをジョブのステップとして実行できることです！

ご好評いただいているAnsibleプラグイン、最近の追加機能拡張と修正を行いました。

Ansibleインラインインベントリーを修正 Ansible Gradleを7.2に更新 Ansibleの行区切りをLFに正規化(unix) Ansible Ansibleのバイナリーディレクトリーへのパスを設定するフィールドを追加 Ansibleのバイナリーディレクトリへのパスを設定するフィールドを追加

詳細はこちら

また、その他のさまざまな商用アップデートやコア製品のアップデートについては、リリースノートで詳しく説明されています。

統合とパートナーエコシステム

PagerDuty App for Zendesk - Automation Actions

カスタマーサービス担当者は、PagerDuty App for Zendesk内で直接Automation Actionsを実行できるようになりました。この自動化により、効率が向上し、担当者の急増する作業負荷が軽減され、プレッシャーの高い顧客ケースに対応する際に担当者が手動タスクを実行しなければならない場合のミスの可能性が減り、労力を増やさずに担当者の生活を向上させるだけでなく、担当者も楽になります。また、カスタマーサービス担当者が自動的に問題を検証し、重要な情報を即座に取得して、対応チームが診断して解決できるよう支援します。Automation Actionsを実行することで追加されるコンテキストは、対応チームが解決時間を短縮するために瞬時にアクセスするために重要であり、バックエンドチームの負荷も軽減されます。エンジニアリングチームにエスカレーションされる問題の量を減らすことができ、緊急度が低い問題や顧客への影響が少ない問題などによる作業の中断を減らし、より効率的に作業できるようになります。

ナレッジベースで詳しく学ぶ

• ブログを読む アカウントマネージャーに連絡する

PagerDutyアプリ for Slack専用インシデントチャンネル改良のお知らせ

次世代Slack V2のインシデント専用チャンネルの改善は、アーリーアクセスで、現在、お客様にご利用いただける状態になっています。これらの改善により、組織内のコラボレーションチームは、インシデントの専用インシデントチャンネル内から以下にアクセスすることができます。

全てのインシデントの詳細、履歴、および更新を表示 全てのインシデントアクションを実行 全てのレスポンダーをチャンネルに追加（レスポンダーが事前にSlackアカウントをPagerDutyにリンクしている必要あり） 専用のZoom会議ブリッジを投稿または作成

ブログを読む

Webhooks-V3-Update

Webhooks V3 のチーム統合を管理したいアクセス制限ユーザー、またはその知り合いの方はいらっしゃいますか？そのような場合、Manager Team Role の割り当てを受けることができます。これにより、グローバル管理者やアカウント所有者が日々の運用を管理する必要がなくなり、あなたと運用チームのメンバーに権限を与えることができます。

この機能のアーリーアクセスを有効にするには、PagerDutyサポートにご連絡ください。 ウェブフックについてもっと知る

製品廃止のお知らせ 今後予定されている非推奨製品について、チームにお知らせください。

V1/V2ウェブフック 現在、PagerDuty環境でV1/V2ウェブフック拡張を使用している場合、機能を維持するためにそれらをV3ウェブフックサブスクリプションに移行する必要があります。

移行ガイドに従ってください。

重要な日程

V1ウェブフック** – V1のウェブフック拡張は、2021年11月13日から非対応（新機能やバグ修正の停止）となり、2022年10月に動作停止となります。 V2ウェブフック** – V2ウェブフック拡張は、2022年10月にサポートが終了し、2023年3月に動作しなくなります。

必要な権限 管理者* またはアカウント所有者* は、アカウント全体を移行することができます。 チームマネージャー** は、割り当てられたチームのウェブフックのみを移行できます。

ウェブフックとは？ ウェブフックを使用すると、PagerDutyアカウントで重要なイベントが発生したとき、例えばインシデントがトリガー、エスカレート、解決されたときにHTTPコールバックを受け取ることができます。イベントに関する詳細は、Slackや独自のカスタムPagerDuty Webhookプロセッサーなど、指定したURLに送信されます。

ご質問がある場合は、PagerDutyの担当者またはサポートチーム（[email protected]）までご連絡ください。

ウェブフックについてもっと知る

この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

9月14日に開催されるAutomated Diagnosticsウェビナーイベントに登録し、一般的なコンポーネントの一般的な診断方法と、すぐに始められるジョブテンプレートの提供方法について学びましょう。

今回は、PagerDuty Process Automationポートフォリオの一般的なユースケースであるAutomated Diagnosticsに関するシリーズの２回目です。

前回は、Automated Diagnosticsの基本について、また、Automated Diagnosticsを利用することで専門家へのエスカレーションを減らし、レスポンダーがより早くアクションを起こせるようにする方法についてお伝えしました。今回のブログでは、ユーザーにとって最も関係の深いコンポーネントの基本的な診断例について説明します。

しかし、その前に、前回の記事についてTwitterに寄せられた読者の声をもとに、Automated Diagnosticsが該当しないことを明確にしておきましょう。

Automated Diagnosticsとアラート相関は異なります。 アラート相関は、指定された信号の深さと、相関のある信号を適切に識別できるエンジンに依存します。Automated Diagnosticsの目的は、第一レスポンダーが問題の原因を三角測量し、問題を迅速に解決するか、より正確にエスカレーションするかです。 Automated Diagnosticsとモニタリングは別物です。 モニタリングは、パフォーマンスやアクティビティーにおいて望ましくない状態を特定することを目的としています。つまり、ほとんどのモニタリングは、第一レスポンダーのアクティビティーをエミュレートして真偽を確認したり、最初に取るべきアクションを特定したりすることを目的としていないのです。モニタリングは、アラートを上げることに重点を置いています。自動化された診断は、アラートが既に作成された後に、問題を修正する方法を決定することに重点を置いています。

とはいえ、Automated Diagnosticsでは監視ツールで収集したデータを利用することができます。ほとんどの人は、収集した全てのデータポイントに閾値を適用しているわけではありません。 実際、私たちがより一般的に使用している診断インテグレーションの１つは、CloudWatchのログ照会です。ログアグリゲーターを監視ツールと考えるかもしれませんが、純粋に問題を診断するために存在する監視ツールのデータを見ることが調査の最初のステップである場合もあるのです。

レスポンダーに自身の環境のオンデマンドまたは事前診断機能を提供することで、第一レスポンダーが原因を迅速に特定できるようになり、その結果、インシデントをサポートするために必要な人員を減らすことができます。通常、専門家でなければ取得できない「診断」データをレスポンダーに提供することで、トラブルシューティングのために多くの人員を投入する必要性が大幅に軽減されます。これにより、インシデントのコストを削減し、通常は手作業で行われる調査手順を自動化することで、平均応答時間（MTTR）を短縮することができます。

現状を把握する。インシデント対応の自動化

運用管理者は、自己回復や自動修復を可能にするというアイデアに期待することがよくあります。自動化によって解決を早めることは、「治療法を適用すること」と考えるのは自然な傾向です。しかし、多くの場合、「まったく同じインシデントは２つとない」という業界の理論が頭をもたげてきます。変動が大きい場合、自動化が実行される可能性が低くなるため、そのような自動化の価値は低下します。例えば、今日の問題を解決するためにコアサービスを再起動することは正しい方法かもしれませんが、明日には障害が連鎖し、さらに大きなインシデントにつながる可能性があります。

読者はここで、対応の初期段階に認知のギアを切り替えます。

しかし、非常に繰り返しが多くなる傾向があるのは何か、ご存知でしょうか。何が問題だったのかを診断し、何が起こったのかを判断するためにレスポンダーが行う調査手順そのものです。繰り返しが多いということは、自動化によって得られる価値も多いということです。例えば、Kubernetesディストリビューションでインシデントが発生したとします。インシデントの性質的にイメージリポジトリーかロードバランサーかを問わず、おそらくKubernetesログを引き出すという同じ診断ステップを取ることになるでしょう。

これらの診断手順はほとんどの場合、固定です。作業しているコンポーネントにより、発生したインシデントの優先順位は関係ありません。Automated Diagnosticsは、異なる種類のインシデントに適用できます。繰り返し発生する同種のインシデント専用に構築する必要はなく、一般的なコンポーネントのあらゆる種類と深刻度を対象に、お客様の環境に合わせてカスタマイズして適用することができます。これは、病院に行くようなものだと考えてください。特定の症状で緊急医療を受ける場合でも、年に一度の健康診断を受ける場合でも、診察室に入ってから体温、血圧、体重を測定します。

一般的な例

開発者の環境はそれぞれ異なりますが、一旦蓋を開けてみると、多くの環境は非常によく似ています。レスポンスの初期段階では、ほとんどの診断が３つの主要なデータソースから行われます。

アプリケーションデータ** システムデータ** 環境データ**

一般的な診断やコンポーネントは、レスポンス開始時に自動的に引き出される例がいくつかあります。これはレスポンダーがインシデントの重大性をよりよく理解するのに役立つだけでなく、レスポンダーが多くの専門家を巻き込みすぎて通常の業務を中断させないようにするのにも役立つでしょう。例えば、インシデント発生時にレスポンダーが使用するコンポーネントとしてKubernetes（k8s）を見てみましょう。k8s環境内でインシデントが発生した場合、この技術を維持するインフラエンジニアは通常、次のようなアクションを実行することになります。

k8sのPodからテールログを取得する k8sからセレクターラベルでログを取得する イメージリポジトリーを確認する デプロイメントを記述する Podでコマンドを実行する

これらのアクションに共通することは、１つだけです。インシデントを受任した一般的なL1レスポンダーは、これらのアクションをどのように構成すれば良いのか分かりません。しかし、PagerDutyのAutomated Diagnosticsのすぐに使えるジョブがあれば、L1レスポンダーは自動的にこれらの診断を実行し、ジョブを実行することができます。

一般的な診断やアラートの例としては、以下のようなものがあります。

CPU／メモリ消費型サービス よくあるアラート： CPU／メモリ使用率が高い よくある質問： どのサービスがCPUやメモリを消費しているか ファイルサイズ ／ ディスク消費量 よくあるアラート： CPU／メモリ使用率が高い よくある質問： どのファイル／ディレクトリーが最も容量を消費しているか システムログ：Linux／Windowsコマンド よくあるアラート： サーバー／サービスの問題 よくある質問： OSの問題か、アプリの問題か SQLデータベースコマンド よくあるアラート： データベースブロック／デッドロック よくある質問： 長時間稼働しているクエリーが他のデータベース要求をブロックしていないか ホストの可用性 よくあるアラート： ホストの停止 よくある質問： 実際にダウンしているのか、それとも誤検出による到達性の問題か アプリケーションのエラー：アプリケーションログまたはトレース よくあるアラート： 400／500エラーコード よくある質問： スタックトレースとは何か

既知の部品に対する一般的な診断のいくつかの例を示します。

Cloudwatchのログ：** 特定のアプリケーションとVPCのログを表面化させる。 ECS：** 停止したECSタスクのエラーを表示させる。 ELB：** 利用できないターゲットグループインスタンスをデバッグする。 Kubernetes：** Podsからセレクターラベルでログを取得する。 Linux：** サービスステータスを取得する。 Nginx：** エラーログを取得する。 Redis：** ログエントリーを低速にする。

また、これらはAutomated Diagnosticsソリューションガイドに掲載されている、ユーザーのために構築した30以上のすぐ使えるジョブテンプレートの一部に過ぎません。Automated Diagnosticsソリューションを使用するには、PagerDutyランブックオートメーションライセンスまたはProcess Automation（旧Rundeck Enterprise）ライセンスのいずれかが必要です。使用方法の詳細については、FAQを参照してください。どちらのライセンスもお持ちでない場合は、弊社までお問い合わせください。

PagerDuty内の診断の自動化

レスポンダーに通知されるインシデントには、アラートに対して「近視眼的な」見方をする監視ツールから提供される情報が多く含まれます。よくある例としては、CPU使用率の高さがアラートのトリガーとなり、レスポンダーに通知されるというものです。しかし、アラートに含まれる情報は表面的なもので、急増したCPUの原因が何であるかが特定されていません。

診断データ は、インシデントの「なぜ」「どこで」という質問に答えるのに役立つ、より深いレベルの情報です。モニタリングや相関ツールの中には、ユーザーに根本的な原因分析を提供するのに役立つものもありますが、そのほとんどは、異種のデータソースを統合ビューに照合するレスポンダーの調査／トラブルシューティングの手順をエミュレートする能力において不足しています。オンデマンドまたは事前実行の診断機能をレスポンダーに提供することで、最初のレスポンダーが自分で問題を解決する確率が高まり、インシデントを支援するための人員も少なくて済む可能性が高まります。Automated Diagnosticsの出番です。

使用するコンポーネントの一般的な診断についてもっと知りたいですか？PagerDutyのシニアソリューションコンサルタントのJustyn Robertsが登壇する9月14日に開催されるウェビナーイベントにご登録ください。Process Automationは初めてですか？デモをリクエストしてください。既にPageDutyのProcess Automationをお使いですか？Automated Dianosticsソリューションガイドをご覧になり、完全なソリューションを実現するためのエンドツーエンドプロセスをご確認ください。ご質問は、Twitterで@sordnamに直接ください。お話ししましょう。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

PagerDuty Summit 2022の注目のセッションを紹介します。Part 2では、次の3つの講演を紹介します。

"Real Talk: PagerDuty’s Product Impact"PagerDutyの製品担当SVPのJonathan Rendeが、Anaplanの米州担当副社長兼カスタマーサクセス責任者のFiona Gillさんに、PagerDutyが彼らの最も重要な指標、チーム、そしてデジタルオペレーション全体に与える影響について、お聞きしました。 "Delivering Value: A two-way street"PagerDutyのチーフカスタマーオフィサーのManjula Talrejaが、LogicMonitorのCEOであるChristina Kosmowskiさんと対談し、企業が顧客と接する際に「価値」をどのように考え、PagerDutyが組織内でどのようにその価値を創造しているのかについて議論しました。 "Leadership in a Digital-First World"DocuSignのCEOであるDan SpringerさんとPagerDutyのCEOであるJennifer Tejadaがデジタルファーストの世界でのリーダーシップはどうあるべきかを対談しました。

「カスタマーサービスソフトウェアはこの10年で大きく進化したが、どれも同じ問題を解決しているように見える！」。これは、全体的な応答時間と解決時間の短縮に関する最近のブレインストーミングの会話で、あるカスタマーサービスリーダーが発した言葉です。

現代のカスタマーサービス担当者の役割は、ますます複雑になってきています。カスタマーサービス担当者は、高度な共感とコミュニケーションを必要とする最前線の顧客対応に努めなければならないだけでなく、顧客に影響を与える混乱が生じたときに、複数のシステム、チャネル、「信頼できる情報源」を駆使して、バックオフィスのエンジニア／開発／ITチームとコミュニケーションをとり、協力しなければならないという負担がかかっています。テクノロジーの進化と社内システム、ツール、プロセスの複雑化は、問題をさらに深刻にしています。

この点を説明するために、金融サービス会社ABCに勤務するカスタマーサービス担当者の例で、ログイン失敗に関するチケットを受け取った場合を考えてみましょう。カスタマーサービス担当者は、ヘルプデスクシステムのキューの一番上にあるチケットを受け取りますが、このチケットに加えて、同様の問題に関する50件のチケットがキューに蓄積していることに気づきます。オンラインポータルにパフォーマンスの問題がある可能性があることに気づいたカスタマーサービス担当者は、エンジニアリングチームに問題をエスカレーションし、支援を求めました。

このシナリオでは、従来のカスタマーサービスソフトウェアに関連するカスタマーサービスワークフローとプロセスの限界が見え始めています。このソフトウェアは、カスタマーサービス担当者が単発の顧客要求を迅速に解決して対応できるようにチケットキューを整理して優先順位をつけるなど、フロントオフィスでの顧客とのコミュニケーションやチケットに関する問題を解決する素晴らしい機能を備えています。しかし、システム停止やバグなどの中核的な問題を解決するために、バックオフィスのエンジニア／開発／ITチームの支援を必要とする場合はどうでしょうか。

カスタマーサービス担当者は、技術的な問題をエスカレーションするためのワークフローやプロセス、そして解決に向けた進捗状況の可視化など、多くの課題に直面しています。典型的なワークフローは、次のようなものです。

顧客がパフォーマンスの問題に遭遇し、カスタマーサービスにヘルプデスクチケットを提出する。 カスタマーサービスは、ヘルプデスクシステムでチケットを受け取る。 カスタマーサービス担当者は、コミュニケーションプラットフォームのタブを切り替える。SlackやTeamsの共有チャンネルで呼びかけ、（場合によっては個々の専門家に）表面化した技術的な問題にバックオフィスでも気づいているかどうかを確認する。 この例では、エンジニア／開発／ITチームは気づいていない。カスタマーサービス担当者は、社内のWikiやスプレッドシートを参照し、どのチームがサービスを担当しているかを把握する。 カスタマーサービス担当者は、別の社内ヘルプデスクシステム（Jiraなど）に移動し、社内チケットを提出する。 エンジニア／開発／ITチームがインシデントを解決すると、コミュニケーションプラットフォームに更新が投稿される。 カスタマーサービス担当者は、ヘルプデスクチケットシステムとコミュニケーションプラットフォームを同時に切り替えて、情報を収集し、顧客に対応しなければならない。

さらに、可視性の問題から、カスタマーサービス担当者は自分自身や他の人に問いかけます。

バックオフィスのチームは、顧客に影響を与えるテクノロジーの問題を認識しているのか。 修正作業は行われているのか。 この問題について、顧客に伝えられることは何か。 この問題の解決に向けた進捗状況はどうか。どれくらい時間がかかるか。

最悪なのは、顧客のチケットが技術チームに引き渡されると、カスタマーサービスの評価基準となるビジネスルールや成功基準が適用されなくなることです。その結果、初回コンタクト解決率、応答時間、解決時間、および顧客満足度に悪影響が生じます。これは、タイムリーな顧客対応に必要な手段や可視性をカスタマーサービスが欠いているためです。

今日、ほとんどのカスタマーサービス組織は、技術チームからサイロ化されています。このサイロ化の影響は、コラボレーションを促進するためのツールやシステムによってさらに悪化します。例えば、カスタマーサービスは、面倒なコピー＆ペースト作業によってさまざまなプラットフォームで情報を重複させ、他のチームが技術的な問題を解決している間に、複数のシステムに注意を散らしていることがよくあります。

カスタマーサービスとエンジニアの両チームとの会話からは、顧客体験を向上させるために、コミュニケーションの壁を取り払い、コラボレーションすることを強く望んでいることが分かります。エンジニア／開発チームは、デジタル資産の健全性を示すもう一つの重要なシグナルとして顧客を扱い、ダウンタイムを減らすことに注力しています。一方、カスタマーサービスチームは、顧客の期待に応えるために応答時間と解決時間を短縮することに引き続き注力しています。技術的な問題が最初に顧客から提起された場合、カスタマーサービスチームは、顧客に影響を与える混乱を正しくエスカレーションするための合理的な方法を必要としています。特に技術チームによる技術的な問題の解決を含むときは、顧客チケットのライフサイクルの始めから終わりまでが完全に可視化されていなくてはなりません。

そこで、次のような疑問が生じます。バックオフィスのチームが顧客に影響を与える障害に気づいていない場合、カスタマーサービスが顧客の問い合わせやリクエストに迅速に回答し、最前線からテクノロジーの問題をエスカレーションするために必要な可視性と情報をどのように提供すればよいのでしょうか。

異なるアプローチ

カスタマーサービスと技術チームの連携がうまくいっていないことが、ダウンタイムやレスポンス、解決時間の増加につながっていることを組織が認識したとき、異なる視点が必要になります。デジタル資産の健全性を示すもう一つの重要なシグナルとして、顧客を認識するのは今なのです。

「顧客は重要なシグナルである」が受け入れられると、組織はカスタマーサービスと技術チームの間の壁を取り払う方法を見出します。PagerDutyを他のテクノロジースタックの中枢神経系として、またリアルタイムオペレーションを行うメカニズムとして活用することで、各チームはインシデント対応プロセスに従事するために選択したシステムを離れることなく「自分の持ち場で働く」権限を与えられます。

PagerDutyをインシデント対応に関わる他のテクノロジースタックと統合することで、各チームは自分が選んだシステムで作業を行うことができます。PagerDutyは、各チームが作業を行うさまざまなシステムやプラットフォームにインシデント情報を配信し、「唯一の信頼できる情報源」となるのです。

カスタマーサービスエージェントが「ABC社」でインシデント関連のチケットを受け取るという以前のシナリオとは異なり、ワークフローは以下のステップに簡略化されます。

顧客がパフォーマンスに問題を感じ、ヘルプデスクチケットをカスタマーサービスに提出する。 カスタマーサービスは、ヘルプデスクシステムでチケットを受け取り、会社のバックエンド技術に問題があることに気付く。 カスタマーサービス担当者は、ヘルプデスクチケットのシステムUIに直接ある内部ステータスダッシュボードで、デジタル資産の健全性を確認できる。 技術的な問題が技術チームに知られていない場合、カスタマーサービスは、特定のビジネスサービスを担当するチームに対して「インシデント」を作成し、トリアージする。アラートは修復に携わるメンバーだけに飛ぶ。 カスタマーチケットとPagerDutyインシデントの間には、双方向のリンクが自動的に作成される。解決までの進捗は、チケットプラットフォームのチケット／ケースビューに流れる。 カスタマーサービス担当者は全ての情報をリアルタイムで受け取ることができ、顧客対応にかかる時間を短縮することができる。

そして何より、このコラボレーションプロセス全体は、カスタマーサービス担当者が日常業務で使用しているチケットシステム内で直接行われるのです。

カスタマーサービスチームと技術チーム間のコミュニケーションとコラボレーションプロセスを最適化することで、エスカレーションプロセスにおいて顧客に影響を与えるような混乱が発生するリスクを軽減することができます。カスタマーサービスチームは、複数のシステムを行き来したり、プラットフォーム間で同じ情報を重複させたりする必要性を排除できます。その結果、初回コンタクトの解決、応答時間、解決時間、そして最終的には顧客満足度が改善されます。

この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2020年は、私たちの働き方に革命をもたらしました。多くの人が一夜にして、フルタイムのオフィスワークから100％リモートワークへと移行しました。そして今、再びオフィスでの仕事が視野に入ってきたため、企業はフレキシブルな働き方を継続する方法を考えています。しかし、これには課題が増え、この働き方に合ったツールが必要とされています。

PagerDutyのモバイルアプリケーションは、App StoreやGoogle Playで星4.8の評価を得ており、高い認知度を誇っています。私たちは、適切な人にすぐに連絡することがいかに重要かを理解しています。だからこそ、レスポンダーがいつでもどこでも重要な仕事を解決できるように、iOSとAndroidに多大な投資を行ってきました。

このブログ記事では、最も必要な情報を見つけるための新しいナビゲーションインターフェース、過去および現在のインシデントを通じたインシデントインテリジェンスの向上、自動診断の起動と修正アクションを実行するための自動化の活用など、最もエキサイティングな改善点をいくつかご紹介します。

必要な情報を簡単に見つけられる

レスポンダーは、自分がいつオンコールになるのか、どのようなサービスのためにオンコールになるのかを知る必要があります。万が一、呼び出しを受けた場合、自分が担当する技術サービスがどのように機能しているかを確認できることが極めて重要です。そして最も重要なことは、これらの情報をモバイルアプリから一目で確認できることです。複数の画面を参照したり、アプリの奥深くに埋もれた情報を探したりする必要はありません。

新しいPagerDutyモバイルホーム画面エクスペリエンスでは、レスポンダーが必要とする最も重要な情報が容易に利用可能です。このデザイン変更により、オープンインシデント、オンコールシフト、影響を受けるテクニカルサービスを中心に表示し、アプリ内のナビゲーションに必要なタップ数を減らすことができます。

デザイン変更されたホーム画面は、現在、早期アクセス可能です。試してみたい方は、この早期アクセスフォームに必要事項を記入し、「新しいモバイルホーム体験」の選択をすると、案内が送られてきます。

フレキシブルに働くということは、最も重要な瞬間に、クリティカルインシデントの状況を自由に把握できることを意味します。インシデントが発生したら、できるだけ早く対応し、影響を軽減するための最善の方法を決定する必要があります。

その方法の１つが、新しいモバイルインシデント詳細画面です。この画面では、視覚的に分かりやすく、最も重要な機能全てにアクセスできるため、インシデント対応に迅速に取り組むことができます。インシデントで作業している他のレスポンダーのメモ、変更イベント、過去のインシデント、最新のアラートなど、インシデントに関する最も重要な情報をすぐに利用することができます。

また、更新版のモバイルインシデント詳細画面にある新しいカルーセルでは、プレーの実行、優先度やメモの追加、ステータスアップデートの投稿などを行うことができます。

過去または現在におけるクリティカルインシデントのコンテキストを獲得する

インシデントが発生したとき、最大のハードルの１つは、「以前にもあったか」という質問に答えることです。もしあれば、以前に動作したプレーを実行したり、自動化シーケンスを実行することで簡単に解決できるかもしれません。しかし、そのような過去の状況を見つけることはしばしば困難であり、それは誰にも許されない無駄な時間です。

PagerDutyモバイルアプリのPast Incidents（過去のインシデント）機能では、現在アクティブなインシデントと同じサービス上で発生した、類似したメタデータを持つインシデントが表示されます。この追加コンテキストにより、正確なトリアージが容易になり、解決までの時間が短縮されます。例えば、自分やチームの誰かが過去に同様のインシデントに巻き込まれたことがあるかどうかを確認し、詳細を調べてどのような改善策が取られたかを知ることができます。 Change Events（変更イベント）。システム内の変更は、しばしばインシデントの影の犯人です。特に、多くの組織が１日に何十回、何百回も新しいコードを出荷している場合、どの変更がインシデントを引き起こしたかを正確に特定するのは難しいため、見過ごされがちです。しかし、「Gartner社の推定によると、全てのパフォーマンスインシデントの約85％は追跡可能」です。変更イベントにより、お客様の環境に影響を与える変更を確認し、潜在的な根本原因を特定することができます。変更イベントは、モバイルアプリの２つのエリア（新しいモバイルインシデントの詳細画面と、サービスの詳細画面）で簡単に確認できます。目的のインシデントをタップして変更イベントにスクロールするか、サービスディレクトリーに移動してサービスを選択し、最大２つの変更イベントを表示できます。表示されるイベントの詳細には、日時、概要、サービス、タイプ、リンク、ソースが含まれます。 インシデント対応におけるもう１つの重要な情報は、問題の影響範囲を理解することです。この情報を得るための１つの方法は、Service Dependencies（サービス依存関係）を理解することです。大規模で顧客向けのビジネスサービスが、技術的なサービスインシデントによって問題が発生している場合、問題の範囲をよりよく理解するために、より速く、より文脈的なインテリジェンスで対応する必要があります。モバイルアプリのサービス依存関係画面では、どのサービスが影響を受けるかを表示して、範囲をよりよく理解することができます。サービス依存関係は、サービスディレクトリーの各サービスのプロファイル内に表示されます。

自動化を活用した迅速な対応

テクノロジー環境がより複雑になるにつれ、人々の時間と認知資源を節約することがこれまで以上に重要になっています。これは、人間ではなく、機械が最初の防衛線として機能することを意味します。

反復的な手作業やよく理解されている事象を自動化することで、対応者の不必要な労力を軽減し、本業に集中できるようにし、最も必要とされている事象にのみ注意を向けるようにできます。これを実現する１つの方法が、指先のタップで実行できる自動化です。

PagerDuty Automation Actionsは、PagerDutyモバイルで一般的に利用できるようになり、いつでもどこからでも自動診断と修復アクションを実行できるようになりました。繰り返し行われる診断と修復のステップを自動化することで、手動で行っていた作業を代替し、生産性を向上させることができます。スクリプトを実行するだけでなく、過去に実行したスクリプトや出力レポートをモバイルアプリから直接表示することができます。これらはリアルタイムで更新されるため、見落としがありません。

PagerDutyモバイルアプリケーションに追加されたこれらの最新機能は、時間、品質、顧客体験を犠牲にすることなく、レスポンダーが思い通りに作業できるよう支援します。フレキシブルな働き方は今後も続きます。PagerDutyの強力なモバイルアプリケーションは、あなたがそれを最大限に活用できるよう支援することを約束します。PagerDutyのモバイルアプリケーションをまだお試しでない方は、今がチャンスです。QRコードを使って、どちらかをダウンロードしてください。

iOS

Android

重要：モバイル体験の安全性を確保するために

PagerDutyモバイルに多くの新しい素晴らしい機能が追加されました。モバイルアプリが革新的で安全であり続け、ユーザー体験を向上させるために、新しい最小システム要件を導入します。2022年6月27日より、PagerDutyモバイルアプリの将来のバージョンでは、Android 9.0かiOS 14.0以降が必要となります。モバイルアプリのアップデートを継続的に受信するために、お使いのデバイスが最新に保たれていることをご確認ください。

この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

ここ数年、企業と従業員の双方にとって、ビジネスと文化の根本的な転換が起きています。

COVID-19は、デジタル業務に早くから投資してきた企業にチャンスをもたらし、他の企業は現状維持に苦心しました。後者は、記録的な従業員の燃え尽き症候群をもたらし、俗に言う「大退職」と呼ばれる事象を生じさせました。

CNBCの調査によると、2022年3月に450万人の米国人労働者が、燃え尽きた、仕事に不満がある、自分の人生を見直すなどの理由を主として仕事を辞めています。また、2021年のPagerDutyのユーザー調査によると、回答者の64％が自組織で離職率が上昇したと答え、過去１年間で離職率が上昇しなかったと答えたのは34％のみでした。

大退職時代が続く中、企業は従業員の生産性を維持し、離職率を下げるための新たな方法を模索しています。私たちは、ベストプラクティスに投資することが大きな違いを生むことを、お客様との経験から知っています。

デジタルオペレーション成熟度モデルは、一般的な行動を段階的に説明し、リアルタイムのオペレーション上の課題に対処する準備ができているかどうかによって、成熟度を分類します。チームは、デジタルトランスフォーメーションの旅を容易にするベストプラクティスとプロセスに投資することで、成熟度を高め、より積極的になることができます。

デジタルオペレーション成熟度モデルとは

デジタルオペレーション成熟度モデルは、対応チームが現在の成熟度を評価し、システム停止やシステム障害の検出、トリアージ、動員、対応、解決をより短時間で行うための新しいデジタルオペレーションを構築することを支援します。

このモデルには、５段階のオペレーション成熟度が含まれています。

Manual（手動型）。** 開発者が目の前の問題に奔走し、リクエストには夜通しでその場しのぎの対応が必要。 Reactive（受動型）。** システム障害や顧客からのクレームが発生すると、調整と計画なしに常に消火態勢に入る。 Responsive（反応型）。** 問題が発生すると、調整と計画が合理化され、解決される。 Proactive（積極型）。** シームレスで協調的な問題管理により、顧客が気づく前に問題を解決する。 Preventative（予防型）。** 問題が発生する前に先手を打ち、過去と現在のインシデントから継続的に学ぶ。

デジタル運用成熟度モデルの目標は、DevOpsチームがITインフラの一貫性、信頼性、回復力を管理・維持するために、積極型および予防型の段階に移行することを支援することです。また、ワークフローとワークライフバランスがより予測しやすくなるため、従業員の燃え尽きが減少します。

オペレーション成熟度向上によるメリット

2021年、PagerDutyのプロダクトマーケティングアナリストであるTejere Oteriは、優れたオペレーションプラクティスがビジネスインパクト、オペレーションの健全性、人的要因に与える影響を理解するために調査を実施しました。調査結果を分析した際、Tejereは、受動型組織の参加者と予防型組織の参加者の回答の仕方に違いがあることに気づきました。

チームの仕事量について質問したところ、受動型組織の参加者の33％が仕事量は均等に分散していると感じていましたが、大多数は仕事量の改善を希望していました。同じ質問を予防型組織にしたところ、83％が仕事量は均等に分散していると感じており、そう思わないという回答は意外にもありませんでした。

また、Tejereは、受動型組織は予防型組織に比べて、従業員の離職率が２倍高くなることを発見しました。具体的には、予防型組織は反応型組織に比べて、プライベートな時間や睡眠時間を仕事のためのインシデントに費やすことが少なく、燃え尽きが少なく、離職率が高まる可能性が低いことがデータ分析から明らかになりました。

成熟度モデルを製品の使い方にマッピングしたらどうなるか

オペレーション成熟度モデルをお客様に紹介し、お客様全体に見られる傾向を明らかにするために、私たちはこのモデルを製品の使用行動にマッピングしました。PagerDutyのシニアプロダクトアナリティクスマネージャーであるScott Bastekは、PagerDutyの製品導入を通じて各成熟段階を調べ、いくつかの興味深い発見をしました。

受動型チームは、インシデントの特定を監視ツールに頼っており、MTTRを短縮するための強固な対応策を構成するまでには至っていない。 反応型チームは、オンコールスケジュールに力を入れ、現状を維持するために複数の防御レベルを設定することで、問題が発生したときに解決することができる。 積極型チームは、サービス依存関係や変更イベントなどの高度なインシデント対応機能を導入し、問題が発生した時点で問題を理解し、診断する。 予防型チームは、ノイズ除去、イベントオーケストレーション、分析レポートなどを活用して、インシデントの発生を未然に防ぐ。

デジタルオペレーション成熟度モデルのどの辺りに位置するか

従業員の燃え尽きや離職を懸念するリーダーは、現在の成熟段階を評価し、運用成熟度モデルに示された例を参考に、新しい運用プロセスを導入する必要があります。最高の運用成熟度を達成するには、オンコールスケジューリング、調整済み課題管理、イベントインテリジェンス、およびプロセス自動化ツールを使用してDevOpsチームに投資することが最適です。これらの投資により、DevOpsチームは全てのインシデントに対してより積極的かつ予防的になり、組織全体のMTTAとMTTRの量を減らすことができます。

デジタルオペレーション成熟度モデルの詳細については、「Getting from Reactive to Proactive and Beyond（受動型から積極型へ、そしてその先へ）」をご覧ください。このビデオでは、Scott BastekとTejere Oteriがオペレーション成熟度のレベルについて掘り下げ、その結果についてより詳細な統計分析と考察を提供しています。

また、組織が最高の運用成熟度を達成するための例として、PagerDutyの最新eBookと最新の「デジタル運用の現状レポート」をダウンロードすることができます。

この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

信頼できる電力源を持つことは、私たちの多くが当たり前のことと思っています。特に医療施設では、生命維持のために電力に依存している弱い立場の患者を守るため、安定した信頼できる電力を確保することが重要です。

しかし、サハラ以南のアフリカの農村部では、信頼できる電力を持つ病院は約28％に過ぎないと推定されています。停電がいつ、どのように発生するかを把握するためのデータがほとんどないため、病院職員による管理はますます困難になっています。

Nexleaf Analyticsは、この課題の解決に取り組んでいます。Nexleafは、中低所得国においてより良い健康上の成果を得るためのデータと技術ソリューションを生み出しています。健康推進団体、政府、地域コミュニティーと協力することで、大規模な意思決定のための実用的なデータを提供しています。Nexleafの使命は、人々の健康を向上させる持続的なソリューションを構築するために必要なデータを各国が確実に入手できるようにすることです。

データおよびアナリティクスの事例

電力供給が不安定な場合、地方の病院ではさまざまな問題が発生します。例えば、電力が不安定な場合、多くの病院はディーゼル発電機に頼っています。これはバックアップ電源を確保する唯一の方法ですが、不安定な電力システムに高コストで非効率的に備えざるを得ないことを意味します。こうした施設の多くは、停電の傾向を把握するためのベースラインデータがないため、病院職員はいつ停電が起こるか推測し、常に厳戒態勢を敷いています。また、ディーゼル燃料費の予算予測にも問題があります。

停電の時間やコストを正確に示すデータがなければ、これらの病院が追加資金を正当化することは困難です。Nexleaf Analyticsの医療機器プロジェクトマネージャーであるAmos Momanyi氏は、次のように述べています。「私たちの主な目的は、電力データの需要を記録し、データを可視化することによって支援できる問題や課題が何であるかを理解することでした」

PagerDuty、Nexleaf、Center for Public Health and Developmentの３社では、停電がいつどのように発生するかを理解し、停電発生時に医療施設を維持するためのプロトコルを確立することを目的としたパイロットプログラムを実施しました。ケニアの15の地方病院が、いくつかの目標を掲げてこのプログラムに参加しました。

電力データに対する要求を文書化する データの可視化によって支援される問題や課題を理解する アラートとデータが停電の解決にどのように役立つかを理解する

PagerDutyの威力

Nexleafは、PagerDutyと接続されたIoTセンサーを導入し、SMSとオンラインアプリケーションで病院職員に通知を送れるようにしました。これにより、職員は停電の根本原因を容易に把握できました。例えば、ある病院では、近隣の施設と電力を共有しているため、午前６時に停電が発生することがわかりました。この病院では、電力供給を予測可能にするために、電力使用時間を別の時間帯にずらしました。

PagerDutyプラットフォームのデータは、医療施設がディーゼルエンジン増強の必要性を説明し、予算超過の理由を正当化するのにも役立ちました。さらに良いことに、このデータは数カ月先の財務予測の精度を高めるのに役立ちました。

最も重要なのは、PagerDutyからのリアルタイム通知により、生物医学エンジニアが施設にいなくても停電の発生が検知できるようになったことです。アラート受信後、病院職員は迅速に行動し、施設に電力を再供給できます。これにより、手動でバックアップ電源を監視する必要がなくなり、患者の容体に大きな影響を及ぼす恐れのある停電を防ぐことができました。「PagerDutyのおかげで、停電による機器の不具合を原因とする死亡事故を未然に防げるようになりました」とMomanyi氏は述べています。

未来は明るい

パイロット運用の成功により、病院とその職員はさまざまな解決策を見出すことができました。病院の職員は、施設の電力管理に関する効果的かつ効率的な意思決定に役立つ電力データのユースケースを決定するために取り組みました。プログラムに参加した施設ではPagerDutyを使い続けており、Nexleafは新たな施設へとソリューションを拡大しつつあります。

Nexleaf Analyticsの歩みについては、Summit '22のセッションの全容をこちらでご覧ください。

PagerDutyのリアルタイムオペレーションがどのように非営利団体に力を与えるか、今すぐ14日間の無料トライアルをお試しください。

この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

13年以上にわたってデジタル運用のビジネスに携わってきた私たちが学んだ本質的なことが１つあるとすれば、それは、全ての事業がレジリエンスを構築するために独自のアプローチを持ち、特注の技術スタックとプロセスで実現しているということです。

世界中の多くのPagerDutyのお客様が、Live Call Routing（LCR）を使ってオンコールチームへの直接アクセスを提供し始めています。簡単に言うと、LCRはPagerDutyのアドオン機能です。企業は電話やボイスメールをオンコール中のレスポンダーに動的にルーティングすることで、インシデント対応のためのカスタマーサポートを拡張できるようになります。

LCRは、顧客やスタッフがインシデントを迅速に報告できるようにする、オンコールチームへのホットラインとお考えください。LCRは、このプロセスを自動化し、オンコールチームが迅速かつ効果的にインシデントを受信して解決できるようにすることで、電話によるインシデント運用の複雑さを解消します。全ての着話はオンコールチームのスケジュールに基づいてルーティングされるため、誰でもすぐに適切なレスポンダーに連絡を取ったり、インシデントとなるボイスメールを残したりすることができます。

今日のLive Callに関するビジネス上の課題は何か

従業員がシステム障害について助けを求めている場合でも、顧客がシステム障害を報告している場合でも、人が報告したインシデントは、最初のレスポンダーがITチケットを作った時点で文書化されます。しかし、そのレスポンダーがその問題の専門家（SME）でない場合もあり、その時は適切な助けを得るために、ビジネス全体の複数のチームに問い合わせます。場合によっては、専門家が不在であったり、休暇中で代替要員がいなかったりします。レスポンダーが代わりの専門家に簡単に助けを求められるシステムがないため、解決策を見いだせずにインシデント対応が立ち往生してしまいます。

企業にとって真の課題は、平均受任時間（MTTA）と平均解決時間（MTTR）を短縮することです。従来のITチケットシステムは、インシデントを記録する手段ではありますが、解決までの時間を短縮する手段ではありません。

LCRのメリットにはどのようなものがあるか

LCRは、顧客に最高のサービスを提供することを保証します。例えば、顧客は直通電話でオンコールスタッフとリアルタイムに会話できます。オンコールスケジュールを調べずに済み、MTTAとMTTRを大幅に削減できます。さらに、LCRのおかげで、同じグローバルなオンコールスケジュールとエスカレーションルールを介してお客様の電話を転送し、適切なチームのレスポンダーが問題に対処できるようになります。

レスポンダーが通話中で、かかってきた要求に答えられないとします。この場合、顧客はボイスメールを残すことができ、LCRは自動的に次に対応可能なレスポンダーのためにインシデントを生成します。また、LCRは、PagerDutyを介して簡単に域内や国際電話番号を割り当てられます。世界中の顧客をサポートするためにオンコールチームを設定できるのです。

Live Call Routingの一般的な使用例

お客様インタビューに基づき、Live Call Routingの一般的なユースケースをいくつか挙げました。

重要なパートナーのための専用回線。** ある決済サービスでは、広い地域で80%の収益をあげている重要なパートナーがいます。このパートナーに「VIP」待遇を与え、Live Call Routingを有効にした専用電話番号を提供し、緊急事態の発生時にいつでもサポートチームに電話できるようにしたいと考えています。このパートナーは過去数年間、この番号に１度しか電話しませんでしたが、結果として地域全体のサービス停止や、数百万ドルの損失、数百万人の顧客からの信を失う事態を未然に防げました。 資産にホットライン番号をタグ付け。** カリフォルニア沿岸で、ボートからジェットスキーまで100種類以上の乗り物をレンタルしている事業者があります。各船舶には、レンタルする人が助けを求めるための固有のホットライン番号が設定されています。しかし、これでは、レンタル事業者とそのレスポンダーは多くのレンタル商品にわたって複数のホットライン番号を管理しなければならず、どの電話番号がどの船舶のものか、どのインシデントに対処すべきかをレスポンダーが見分けることが難しくなってしまいます。この企業は、全てのレンタル船舶に対応できる「１つのホットライン番号」でLive Call Routingを有効にし、電話をかけてきた人がリストからサービスを選べるようにしました。インシデントは適切に識別され、適切な専門家に転送されるため、短時間でインシデントに対応できるようになりました。 社内チームへの直通電話。** あるテクノロジー企業には1000人以上の従業員が在籍し、世界中にさまざまな顧客サービスを提供する複数のチームが存在します。あるサービスがダウンした場合、担当チームとそのスケジュールを追跡できません。情報がチーム間で共有されておらず、アクセスもできないためです。Live Call Routingは、複数のサービスの全てのインシデントに対応できる直通電話を設定し、担当の適切なチームに直接電話をつなぐことができます。各チームはインシデントを迅速に解決し、業務を効率化することで、世界中でより良い顧客サービスを提供することができます。

なぜPagerDutyのLive Call Routingか

PagerDutyのLive Call Routingは、インシデントを適切な専門家につなげ、人が介在するインシデントを管理する方法を変革します。コールルーティング、連絡網、グローバル番号割り当てなどの柔軟な機能により、適切なスタッフを待機させるためのよくある管理の複雑さを全て排除し、対応時間を短縮します。

PagerDutyのLCRは24時間365日体制で、顧客から報告されたインシデントが直ちに適切な個人またはチームへ転送され、エスカレーションされることを確認します。最も重要なことは、インシデントの通知と対処を希望する通信手段によって行うことで、インシデントを管理することができるということです。人が呼んだインシデントがボイスメールに入ったとしても、それは自動的にインシデントとなります。

あなたの声をお聞かせください

私たちは常にお客様とお話しし、Live Call Routingを活用するためのお客様のアイデアや使用例について知りたいと考えています。私たちは、質問にお答えし、アイデアを交換し、Live Call Routingがあなたの組織に適しているかを検証できる「Office Hour」を設けました。Calendlyを使って30分の無料セッションに申し込んでください。

Live Call Routingのシニアプロダクトマネージャー、Ben Wiegelmannによる「Always Reach On-Call Responders Immediately with Live Call Routing」を見て、Live Call Routingとその機能についての詳細をご覧ください。一般的な使用例を紹介し、MTTAとMTTRを改善する主な機能を実演しています。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

サービスオーナーシップはDevOpsのベストプラクティスで、チームメンバーが開発ライフサイクルの各段階で、自分たちが提供するソフトウェアのサポートに責任を持つというものです。このレベルのオーナーシップにより、開発チームは顧客と事業と提供価値により密になることができます。

サービスオーナーは、そのサービスの主題の専門家（SME）であり、サービスオーナーシップモデルでは、あらゆる生産上の問題への対応にも責任を負います。このモデルに移行するチームにとって、オンコールになることは大変なことに思えるかもしれません。週末や夜間にラップトップを抱えてインシデントに対応するという恐ろしい話を聞いたことがありませんか？

オンコールは大変なことです。しかし、サービスオーナーシップのようなベストプラクティスは、オンコールシフトに秩序と予測可能性を導入し、理想的には全員の生活の質を向上させることができるのです。

なぜサービスオーナーシップが重要なのか

次のシナリオを想像してみてください。システムのどこかに問題があるためにミーティングに呼ばれましたが、サービスオーナーが決まっていないため、SMEが誰なのか誰も知りません。15分が20分になり、30分になり..。その間、さらに多くの人が電話に飛びつくが、何の進展もなく...。

こんな混沌としたインシデント対応は貴重な時間を浪費し、非効率の典型です。そして、最悪なのは、このようなことが常に絶えないことです。

こんな事態は避けなければなりません。しかし、その前に、なぜ多くのチームが手作業によるインシデント対応に負担を感じ、いつまでも引きずってしまうのか、その理由を考えてみましょう。対応が遅くなる理由を考えてみると、それは、いくつかの非常に重要な質問に答えられないことに集約されます。

どのサービスが影響を受けるのか？ サービスの依存関係は？ それぞれのサービスのオーナーは誰？

先に挙げた例のようなミーティングは、これらの質問に答えようとするものですが、後手に回ってしまいます。これらの質問に答えることができない限り、チームは立ち止まったまま、インシデントの解決に進めないのです。

テクノロジーのエコシステムが変化し続け、あらゆる規模の企業でより複雑になるにつれて、このような状況はますます一般的になってきています。何百ものサービス、マイクロサービス、分散型オーナーシップによって、何か問題が発生したときにどのように行動を起こせばよいのかが分からなくなっています。

サービスオーナーシップは、組織がより積極的にインシデント対応に取り組むのに役立ちます。とはいえ、これは簡単なことではありません。文化を変えることは難しく、DevOpsとサービスオーナーシップへの移行に何とか成功した組織は、ベストプラクティスに従うことと、サービスオーナーシップを採用するためのプロセスを持つことが、組織全体の定着と規模の拡大に役立つことに同意するはずです。

組織がサービスオーナーシップを採用できれば、サービスオーナーから経営陣のステークホルダー、顧客に至るまで、全ての人がメリットを得られます。サービスオーナーは、必要なときだけ呼び出されます。ステークホルダーは、インシデントによって何が影響を受けるかを把握し、技術チームと協力して影響を軽減できます。また、顧客はサービス中断中も明確な応対を受けられ、以前ほど復旧まで待たされていると感じなくなります。

顧客の期待がかつてないほど高まり、カスタマーエクスペリエンスが重要な鍵を握る世界において、インシデントに対応する人々の生活を向上させながら、組織を競争優位に立たせることができるのです。

実際のところ、サービスとは何なのか

サービスを定義することは、一見したところ意外と難しいものです。サービスをさまざまな方法で分割している組織を見てきましたが、クラウドに展開されているサービスと一致するほど単純なものではありません。組織によっては、分割できない要素の存在も考慮する必要があります。では、どのように物事を管理しやすいピースに分割し、チームが責任を持てるようにすればよいのでしょうか。

PagerDutyでは、サービスを "価値を提供し、チームが完全に所有する機能の個別ピース"と定義しています。別の言い方をすれば、サービスは監視するエンティティーを表し、インシデントを適切なエスカレーションポリシーに関連付ける関連インシデントのコンテナとして機能する、ということです。

つまり、監視し、インシデントを関連付け、特定の担当者を待機させるのであれば、それはサービスだ ということになります。これはより広範な定義であり、従来とは異なるサービスをチームがどのように定義するかについて、より柔軟性を持たせることができます。

しかし、レスポンダーは、問題に対処するための十分な準備をするために、これらの境界線だけでなく、それ以上の情報を知っておく必要があります。ここで、サービスの構成が大きな違いを生むことになります。

サービスが適切に構成されているとはどういうことか

PagerDutyでは、サービスオーナーシップの導入を進めようとしている組織にとって価値があると思われる一連の標準を確立しました。これは私たちがサービスをどう作成するかのガイドラインであり、「良い」とはどんなものかを決めるものです。

この基準はフレキシブルなものでもあります。全サービスが同じように構築されるわけではありませんし、私たちの基準のいくつかは、それぞれの状況には当てはまらないかもしれません。この基準は、お客様がオンコールをより効率的にし、第一線で働くオペレーターの負担を軽減するための出発点として考えてください。

大事なのは、サービスオーナーシップはプロセスであって、ToDoリストでチェックすべきボックスではないということに留意することです。運用の成熟度によっては、基準を設定し、採用するペースは異なるかもしれません。

比較的小規模で、サービスオーナーシップの経験が浅く、クラウドベースのサービスを中心に扱っている場合は、数日で基準を設定し、それに従ってサービスを構成できるかもしれません。ゼロから始める場合は、さらに簡単です。最初のサービスを作るときに基準を適用すれば、以前に設定したサービスに戻って変更する必要がなく、長期的にうまく導入できます。

しかし、数百、数千のサービスを持つ大規模な組織では，この移行は難しいかもしれません．このような組織では、次のような問いかけをすることで、今後の進め方を検討できます。

既存のサービスのうち、今すぐ基準を設定できるものは何か、またその基準は何か。 いくつかの基準は、全てのサービスに適用するのが簡単であると気づくかもしれません。たとえば、サービスには、それが何をするものかを正確に説明する名前が必要です。このように、大多数のサービスが従うべきと分かっている基準があれば、実装を始める適した場所です。このような変更を行うよう、パイロットチームにどのように依頼できるかを考えてみてください。 新しいサービスを作るためのプロセスはどのようなものか。 基準は決まっていても、現在のサービスを全てその基準に合わせるのは大変な仕事です。大規模な組織であれば、全てのサービスを一度に再構成することは通常不可能です。また、サービスを再構成することは、最初に正しく設定するためのプロセスに従うことよりもフラストレーションがたまる可能性があります。 長期的な目標は何か。そのためのスケジュールはどのようなものか。 サービスによっては、これらの基準が必要ないものもあるかもしれません。残りのサービスについては、期限を決めて計画を立て、追加のチームのオンボーディングを開始し、時間をかけて少しずつ変更していきましょう。 どのように依存関係を知るか。 基準を作成し、適用するだけでなく、サービス同士がどのように対応し、互いに影響し合っているかを知ることも重要です。基準を確立する一方で、構成プロセスでこの情報を体系化することをどのように奨励するかについて考えてください。

これらの質問に個別に答えることは、大きな差別化要因にはならないかもしれません。しかし、それらがどのように拡張されるかを考えるとき、インシデントへの対応に大きな違いが生まれます。

インシデント対応にどのように役立つか

インシデント対応では、重要でない仕事に時間や労力を浪費しないことが重要です。インシデントを解決するためにチームが集中する必要があるものに、全てを絞り込む必要があります。

サービスオーナーシップは、対応プロセス全体を通じて、このことを明確にするのに役立ちます。

例えば、サービスの設定が適切であれば、適切な緊急性と最小限のアラートノイズでアラートが表示されるため、最も重要な信号のみに対応し、それに応じて優先順位をつけることができます。また、サービスの所有者を把握できるため、適切な担当者を迅速に配置することができます。成熟度が上がれば、サービスの自動化シーケンスを作成し、サービスを正常な状態に戻すための作業を軽減することも可能になります。

また、サービス上で何が変更されたかを確認できるため、何が問題だったのかを診断するのも簡単です。また、サービスマッピングにより、システムに対する全体的な影響を把握することができます。

問題解決中は、サービスに必要なインテグレーションを迅速に行い、ステークホルダーに情報を提供することができます。インシデントの影響を受けると分かっている関係者だけに連絡を取り、組織内でも影響を最小限にとどめることができます。

最後に、インシデントからよりよく学ぶことができます。サービスのSMEとして、過去の文脈を把握し、その学習結果を対応プロセスにフィードバックすることで、長期的な耐障害性を高めることができます。

サービスオーナーシップを組織全体に拡大すると、こうした改善によって顧客とチームメンバーの両方に劇的な変化がもたらされます。サービスオーナーシップの導入や運用の成熟度を向上させ、そのプロセスをガイドしてくれるパートナーをお探しなら、14日間無料でPagerDutyをお試しください。大規模なサービスオーナーシップの基準化についてもっと知りたい方は、こちらのウェビナーをご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

Great Place to WorkとFortune誌は、PagerDutyを今年のBest Workplaces in Bay Area（ベイエリアで最も働きがいのある会社）の１社に選出しました（当社は、2020年と2021年にも米国で最も働きがいのある会社として認定されています）。この賞は、毎年100万人以上を対象に行われる米国での労働力調査に基づいています。この調査において、PagerDutyの従業員の91％が、私たちは素晴らしい職場であると回答しています。米国に拠点を置く一般的な企業の従業員は57％でした。

この賞は、私たちの素晴らしい人材と特別なカルチャーを反映しているものであり、非常に誇りに思っています。人材主導のカルチャーは、私たちのDNAの中にあります。従業員は業務、キャリア成長、開発に、グローバルチームからのサポートを受けながら自発的に取り組んでいます。私たちは、ユーザーを第一に考え、自由に学び、創造し、リスクを取ることを誇りにしています。

しかし、実際に PagerDutyは何がそんなに特別なのでしょうか？

カルチャーを大切にする会社_**

2020年３月以降、40％以上の成長を遂げました。私たちは「People First」の考え方から外れることなく、私たちのカルチャーの最も強い部分を維持しながら、ビジネスの方向性やお客様のニーズに沿った、私たちの望む未来の状態を実現するために、意図的にカルチャーを進化させることに取り組んできました。

そのために、今年初めにカルチャー・戦略チームを結成しました。カルチャー・戦略チームのミッションは、意図的な傾聴、企業価値と実践の活性化、従業員、お客様、パートナーへの従業員価値提案の伝達を通じて、従業員のライフサイクル全体を通して従業員エンゲージメントを高めることです。

特に従業員が分散している場合、強力で持続可能な企業カルチャーを育むことは、私たちにとって決して「あったらいいな」ではなく、従業員と私たちの目標、目的、ビジョン、ミッション、そしてお互いを結びつけるための会社の必須条件でした。私たちが成長し、規模を拡大し続けるためには、私たちの行動、規範、そして人々を私たちの価値観に根付かせることが不可欠なのです。

従業員体験は、組織、リーダー、従業員、そしてカルチャー・戦略チームの間で共有される責任です。このチームは、傾聴、エンゲージメント、コミュニケーションという重要な柱を通じて、ミッションをサポートし、ビジネス全体に持続的な変化をもたらす主要なプログラムや施策を推進しています。

仕事以外でもデュートニアンをサポートする_**

私たちは皆、リモートワークへの地殻変動を感じていました。共有の場で仕事と家庭を両立させること、子どものバーチャル学習の支援、孤立への対処、燃え尽き症候群などの課題に無縁でいられる人はほぼ皆無だったのです。私たちは、従業員が職場の外で対処し、成長するのを助けるために、福利厚生を充実させる必要があることを理解していました。

既存の従業員支援プログラムに、24時間365日対応の感情サポート、ライブ行動コーチング、カウンセリングなど、新たなメンタルヘルスサービスを追加しました。また、「デュートニアンウェルネスデイ」と「ウェルネスウィーク」を導入し、全社的に有給休暇を取得できるようにし、法定以上にCOVID-19関連の病気や介護のための有給休暇を追加しました。

仕事の内外で「自分らしく」いることは、PagerDutyのコアバリューです。そのため、従業員のメンタルヘルスとワークライフバランスを支援するこれらのサービスは、今後も無期限で継続される予定です。

包摂性、多様性、公平性_**

PagerDutyでは、包摂性、多様性、公平性（ID&E）は、誰もが所属し、成功できる職場であることを約束するための中心的な要素です。また、長期的な成功のためには、私たちがサービスを提供するさまざまなコミュニティーやアイデンティティーを代表する人材とカルチャーを構築することが必要です。

ID&Eは、多様な人材を惹きつけ、開発し、維持するためにも重要です。私たちの従業員リソースグループ（ERG）は、過小評価コミュニティーに、より大きな包摂性と帰属意識を与えています。

社会的インパクト_**

私たちの影響は、会社の枠をはるかに超えて広がっています。PagerDuty.orgを通じて、デュートニアンがさまざまなコミュニティーに変化をもたらす存在として活性化するお手伝いをしています。例えば、次のようなことです。

従業員には毎年20時間のボランティア休暇（VTO）が付与され、ボランティア、投票、特定の政治思想に偏らない参政活動に充てることができます。新入社員や年間５時間以上ボランティアに参加した従業員、そしてGiving Tuesdayには、寄付金クレジットが付与されます。 私たちは毎月、公平と正義を推進し、非営利団体の顧客がその活動を拡大できるよう支援することを目的としたボランティアイベントを開催しています。 インパクトアンバサダーのグローバル協議会を運営し、ボランティア活動、マッチングキャンペーン、ERG助成プログラムを通じて従業員リソースグループ（ERG）と密接に連携しています。 2020年には、デュートニアンの93％がボランティア活動や寄付を行い、110以上の組織で2,860時間以上のボランティア時間を記録し、従業員の寄付や従業員のマッチングプログラムを通じて約196,000ドルを寄付しました。

また、PagerDutyの助成パートナーや顧客がミッションクリティカルな業務に我々のプラットフォームを導入するのを支援するため、技術スキルベースのボランティア活動を開始しました。PagerDutyはTrekMedicsのようなパートナーと協力し、最も恵まれない人々の緊急対応や医療における遅れを取り戻し、成果を向上させる上で極めて重要な役割を担っているのです。

PagerDutyは、適切な瞬間に適切な対応を可能にします。私たちは日々、お客様のためにこれを行い、また従業員のためにも同じことを行うよう努力しています。私たちがベイエリア、そして国際的な事業展開をしている米国や世界で、最も働きやすい職場のひとつと評価されているのも不思議ではありません。

支え合い、人々の業務外の生活にも気を配り、多様性を祝い、本来の自分らしさを発揮することを奨励することで、私たちはきっと長く「働きがいのある会社」であり続けられるでしょう。PagerDutyで働くことに興味はありませんか？私たちは事業全体で採用活動を行っています。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。