Category
ベストプラクティス

PagerDutyは、ミッションドリブンの各組織が緊急のニーズに即応できるよう支援することを目的として、2019年にインパクトファンドを立ち上げました。それ以来、私たちは既に400万ドル以上を分配して、人、製品、声の力を動員し、より公平な世界の構築を支援するために、Time-Critical Health（緊急性の高い健康問題）とJust & Equitable Communities（公正で公平なコミュニティー）という２つの重点分野での戦略的な慈善投資を優先して進めています。2022年、Googleは公正で公平なコミュニティーへの投資を優先するためにClimate Equity Fundを立ち上げました。

気候変動は、私たちが地球規模で直面する喫緊かつ複雑な課題です。これは、気候変動の影響が世界中の経済的・社会的に疎外されたコミュニティーに不均衡に影響を与えるため、公平性の観点から重要です。これらのコミュニティーは普通、気候変動の原因にほとんど貢献していませんが、彼らを癒しと成長の中心に据えるソリューションを構築するために相談されたり、投資されたり、信頼されたりすることはめったにありません。コミュニティーソリューションは重要ですが、それだけでは不十分です。企業にとって、絶滅の危機に瀕した地球への解決策に積極的に取り組むことは、長期的な価値創造にとって重要です。環境保護主義者で登山家のDavid Brower（訳注：自然保護団体Sierra Clubの初代事務局長を務めた著名な環境保護主義者）が言ったように、「死んだ惑星でやるべき仕事はありません。」

学習と資金調達の原則

気候の公平性をサポートすることが不可欠であることを念頭に置いて、私たちは昨年、深い学習の旅に没頭してきました。私たちは昨年の冬、好奇心と謙虚さを備えた資金提供者として参加することを目的として、この作業を開始しました。私たちの目標は、セクターとそのリーダーのニーズに耳を傾け、学び、フォローすることでした。2022年２月に４つの気候公平性組織に25万ドルの初期投資を行いました。これらの組織やその他の気候リーダーとのパートナーシップから得た重要な教訓には、次のようなものがあります。

• 世界の慈善寄付のうち、気候変動の公平性に向けられるのはわずか２%で、コミュニティー主導のグループに向けられる寄付は１％未満です。この深刻な資金不足に注意を喚起し、解決のためにより多くの資金とリソースを活性化するために、これらの数字を共有します。 長期的に成功するためには、気候変動の影響を最も大きく受けるコミュニティーを中心に据えた気候ソリューションが必要です。 企業の資金提供者にとって、気候変動の公正な取り組みに真摯に取り組むことは、社内と社外の仕事です。言い換えれば、コミュニティーの取り組みに資金を提供することは良いことですが、十分ではありません。また、私たちのビジネス慣行が意図しない否定的な結果にどうつながるか可能性があるかを含め、私たちの貢献について全体論的に考える必要があります。害を加えるシステムを永続させておいて、その症状を緩和するために慈善活動を利用することはできません。

私たちのパートナーシップ、対話、学習から得た情報に基づいて、気候変動に対する公平な慈善活動を前進させるための４つの資金調達原則を策定しました。

私たちの資金は、ギャップを埋めるときに最も効果的です。私たちは有色人種と女性が率いる組織、例えば気候変動の矢面に立たされている地域や最前線のコミュニティーとそのリーダーを中心とした気候ソリューションを引き続き優先します。 継続的な学習と関与は、資金提供者としての信頼を築き、最終的には気候の公平性の分野でリーダーになるための鍵です。私たちは相互学習を求め、学んだことをオープンソースにして他の人に利益をもたらします。 最前線の組織への直接的な資金調達と仲介者を通じた資金調達を組み合わせて、多様なポートフォリオの構築を目指します。 ミッション関連の投資、プログラム関連の投資、インパクト投資など、あらゆる分野で慈善資本を活用します。資本の展開方法を多様化することで、ソーシャルインパクトのイノベーターやリーダーを、そのインパクトとビジネスモデルにとって最も価値のある種類の資金調達でサポートすることができます。

新しいパートナーシップ

これらの基本原則に沿って、コミュニティーで構築された気候ソリューションを実現している２つの驚異的な組織とのパートナーシップを発表できることをうれしく思います。これらの組織は、無制限の助成金、スキルベースのボランティア活動、PagerDuty Operations Cloudプラットフォームへのアクセス、広報強化など、PagerDutyのあらゆるサポートを受けられます。これらの組織とその影響について詳しく知ることをお勧めします。

Navajo Power Home：Navajo Power Homeは、アリゾナ州、ニューメキシコ州、ユタ州の２万7000平方マイルを超える地域であるナバホ保留地のオフグリッド住宅にソーラーサービスを提供しています。ナバホ保留地の家庭の３分の１は、信頼できる電力にアクセスできません。Navajo Power Homeは、フルサービスの太陽光発電を提供することで、この状況を変えています。この投資は、先住民主導の組織が受け取った気候資金の0.3％に影響を与え、Navajo Power Homeが 2030 年までに１万以上の家庭に手頃な価格でクリーンな電力を供給するのに役立ちます。

「電気のないナバホ保留地で育ったことで、多くの家族が最初から暗闇の中にいましたが、太陽光発電のおかげで、今では電化製品を活用し、子供たちに宿題をさせ、食べ物を冷蔵しておけます。これにより、ここナバホ保留地での生活が楽になります。」– Navajo Power Homeのゼネラルマネージャー、Jerry Williams氏。

Beneficial Returns：Beneficial Returnsは、ラテンアメリカと東南アジアの社会的影響力のある起業家に融資を提供し、コミュニティーが直面する課題に対する気候変動に強いソリューションを構築します。彼らのポートフォリオには、エクアドルの先住民農家を支援し、インドネシアで浄水技術を開発し、メキシコの家庭に太陽光発電をもたらす社会的企業が含まれます。私たちは、７年間にわたってPagerDuty.orgインパクトファンドに返還されるミッション関連の投資ローンと、一般的な運用コストに対する少額の助成金を組み合わせて、Beneficial Returnsに投資しています。この創造的な資本の取り決めにより、Beneficial Returnsは、気候変動の影響を過度に受けている地域の社会起業家をサポートすると同時に、全範囲のソーシャルファイナンスで私たちの学習の旅をサポートすることができます。

PagerDutyの気候公平性の旅は次にどこへ？

これは気候変動に対する私たちの慈善活動の始まりにすぎません。2023年も、コミュニティー主導の取り組みと気候の公平性に関する技術ソリューションを引き続きサポートしていきます。私たちは、完全にパートナー主導のアジェンダでパートナーをまとめるために、史上初の年次パートナー会議を計画しています。私たちの目標は、パートナーがその影響力を拡大するために必要なリソースとネットワークに接続することです。慈善活動に加えて、私たちはビジネスの観点から気候ソリューションに取り組んでおり、意図しないマイナスの結果を軽減しています。2023年のGoogleの優先事項には、Science-Based Targets Initiative（SBTi）を通じて短期的な気候目標を設定することにより、パリ協定に沿った気候への取り組みを確立することと、職場、情報システム、財務その他の重要なビジネス分野のための強力な環境ポリシーを策定することが含まれます。 私たちは、デュートニアン、パートナー、企業のソーシャルインパクトの仲間たち、投資家と、私たちの進歩と学んだことを共有し続けます。

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

IT部門の予算が厳しい昨今、プロジェクトの正当化や拡大には、投資対効果の証明が不可欠です。よいニュースは、自動化は必要な人間の労力を減らすことでコストを削減 できるということです。これは、ロボット掃除機に投資するのと似ています。初期費用はかかりますが、人間が掃除機をかける必要がなくなるので、時間（とお金）を節約できるのです。

自動化プログラムによってもたらされる価値の報告は、自動化の対象によってその価値が大きく異なるため、困難なケースがあります。プロジェクトの提案では、特定の手動タスクを自動化することで、時間やコストの削減を予測できます。このような節約を追跡し報告することで、プロジェクトのビジネスインパクトを示せます。では、トラッキングとレポーティングはどう簡素化できるのでしょうか。

PagerDuty Process Automationには、ROI Metric Dataプラグインという機能があります。ROI Metric Dataプラグインは、自動化が実行されるたびに価値を提供するというシンプルな原則に従っています。自動化開発者は、自動化で節約した時間:10などの主要な値を定義することで、価値の指標を指定します。

ジョブが実行されるたびに、これらのメトリクス値は実行のログエントリーに追加されます。また、このプラグインは、実行に関する他のメタデータとともに、これらの実行のJSONレコードを抽出するエンドポイントを提供し、これらのメトリクスを長期的にコンパイル、計算、分析することが可能です。 ではここから、自動化プロジェクトが提供するビジネス価値追跡のためのパターンをいくつか紹介します。

人件費削減による節約を報告する

タスクを自動化することで得られる最も直接的なメリットは、代替となる労働力のコスト削減です。PagerDuty Summit 2022でBrinks社のRobert Powers氏が共有したこのユースケースを例に挙げます。同社では、データ転送を繰り返し行っており、スタッフが5～10時間かけて手作業で行っていました。

このプロセスをPagerDuty Process Automationで自動化することで、毎週１人の仕事の1/4を占めていたこのプロセスを、自動タスクに変え、人間による作業時間を０にしました。

データ転送自動化プロジェクトのコスト、機会、利益の基準

ROI Metric Data Pluginを使ってこのシナリオで生成された価値を追跡するには、このプロセスの実行記録にこのメトリックを含めるために、値10でメトリックhours_savedを定義するだけです。これにより、このプロセスの実行ごとに節約された時間の合計を示す、簡単なメトリックをエクスポートできるようになります。自動化ジョブに機能を追加すると、これらの値は時間の経過とともに変化する可能性があるため、このような任意のキーバリューのアプローチを選択しました。この方法では、データをグラフ化する際に、キー名を変更しない限り、新しいバージョンの自動化の値を古いバージョンと比較できます。

あなた自身のシナリオでは、自動化を試みる作業を手作業している担当者が、どのくらいの時間をかけているかを判断したいところでしょう。これは望む最終結果に応じて正確にできます。見積もりでもいいですし、観察によって平均的な時間を割り出すこともできます。平均値や推定値は、hours_savedなどのキーとペアにした値になります。コスト削減や作業量分布の変化を追跡したい場合は、従業員の職種別にこれらを分けられます。キーと値のペアを、さらにDBA_hours_saved、senior_engineer_hours_savedなどに定義するだけです。投資対効果を計算したい場合は、自動化を作成するために必要な時間も記録しておく必要があります。また、分析時に値を金額で定義したり、時間を金額に換算したりすることもできます。

ここでは、ジョブの実行ごとに記録される2つのキーと値のペアを作成しました。Hours_Saved : 1.25 と Dollars_Saved : 250 です。

ジョブ実行データをTableauなどのお好みのレポートツールにアップロードしてください。ユーザーやジョブごとに異なる指標の集計を時系列でグラフ化できます。例えば、ユーザーによる手動実行とスケジュールされたジョブ実行で節約できた時間を表示できます。節約した金額は、定義したメトリクスから直接計算することも、異なる時間メトリクスをコストに変換することによっても計算できます。

ここでは、スケジュールされたジョブ実行とユーザーによるジョブ実行によって、お金と時間の節約につながることを示すログデータをチャート化した例を紹介します。

これらの指標を投資対効果に変換するには、自動化の導入に関連するコストを追加する必要があります。上記で紹介したお客様の事例では、20FTE時間（同等の人件費を想定）が自動化されたプロセス作成のためのコストとなりました。これに１年以上のメンテナンスが含まれると、次のようになります。520 FTE時間節約 - 20 FTE時間（自動化するための時間） = 500時間節約（運用開始1年目のみ）

自動化の成果でメトリクスを調整する

自動化が実行されればいつでも価値を提供するという原則に基づき、自動化の結果に応じた価値の算出が望まれるでしょう。これは、失敗したオートメーション実行をフィルターすることにつながります。

自動化の実行が失敗する理由はさまざまです。ジョブ定義自体に問題がある場合もあれば、ジョブを終了させないノードやワークフロー・ステップから報告されたエラーもあります。このような失敗した実行は、値計算の対象から除外することをお勧めします。

失敗したステップを含むジョブ実行例

アナリティクスを実行する際、統合されたシステムからの外部障害による失敗をフィルターするよう選択できます。

節約した時間やお金、仕事の状況が分かるチャート例

ROI Metric Data Pluginはバージョン4.7からPagerDuty Process Automationで利用できるようになり、PagerDuty Runbook Automationの一部として利用することもできます。ROI Metric Data Pluginを使用した作業の詳細については、Process Automation Documentationを参照してください。

まだPagerDuty Process AutomationまたはPagerDuty Runbook Automationのユーザーでない方は、今すぐデモまたはトライアルを予約してください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

はじめに

多くの企業で業務のデジタル化が進んでおり、その大半はクラウドに移行しています。 この変革に伴い、データチームはこれまで以上に大規模で複雑なデータセットを分析し、下流チームは日常的により迅速、かつ正確な意思決定を行えるようにしなければならなくなりました。その結果、ほとんどの組織では、顧客データ、製品データ、利用データ、広告データ、財務データなどを扱う必要があります。これらのデータセットは、構造化されているものもあれば、半構造化されているものもあり、また非構造化されているものもあります。つまりさまざまなタイプのデータが、複数のソースから無限に、しかも矢継ぎ早に到着しているのです。

このようなビッグデータの量、速度、多様性（一般に3Vと呼ばれる）の増大により、データライフサイクルの管理に対する従来のアプローチでは不十分となり始めたのです。同時に、2000年代前半の終わりごろから、ソフトウェア開発チームは、ソフトウェア開発ライフサイクルにアジャイル手法を採用しはじめました。これらの方法論は、DevOps（DevelopmentとOperationsの合成語）として知られるようになりました。 次の図は、DevOpsのプロセスを高いレベルで示しています。

DevOpsプロセス

一方、データの専門家は、ソフトウェア開発の同僚を見習い、DevOpsの方法論と概念を自分たちの複雑なデータ環境に適用し始めました。 これが、DataOpsのアプローチをもたらしたのです。

では、DataOpsとは何でしょうか？

DataOpsは、ソフトウェアおよびデータエンジニアリング、品質保証、インフラストラクチャー運用を、1つの機敏な組織にまとめ、活用するプラクティスです。DataOpsは、組織がデータアプリケーションを開発・展開する方法を最適化します。プロセスの進化、組織の連携、複数のテクノロジーを活用し、データの作成、移動、変換、消費に関わる全ての人（開発者、データエンジニア、データサイエンティスト、アナリスト、ビジネスユーザー）が関係を構築できるようにします。DataOpsは、コラボレーションを促進し、サイロを取り除き、よりよいビジネス上の意思決定を行うために組織全体でデータを使用する能力をチームに提供します。総合的に見ると、DataOpsは、チームがデータを収集して準備し、分析し、完全なデータセットからより迅速かつ正確な意思決定を行えるようにします。またDataOpsは、データの品質を監視することで、データのダウンタイムや障害を低減します。

DataOpsは、組織のデータ環境に共通するさまざまな課題に対応します。その中には、以下のようなものがあります。

サイロを取り払い、チーム間のコラボレーションを促進する データエンジニア、サイエンティスト、アナリストが協力しなければなりません。 文化的な大変革が必要です。企業は、社員がデータドリブンのアイデアで迅速に実行することを認める必要があります。 *効率性と俊敏性の向上 * チーム間のコミュニケーションとコラボレーションを強化し、自動化を利用することで、バグや不具合への対応を劇的に減らすことができます。 データの品質を向上させる。 DataOpsは、データ専門家がデータを自動的にフォーマットする機能を提供し、複数のデータソースを使用して、チームがデータを分析し、よりよい意思決定を行うのを支援します。 4.データチームがデータ品質を監視 そのため、データのダウンタイムや障害が発生しなくなります。

データオブザーバビリティーとは？

「データオブザーバビリティー」は、複数のツールやデータライフサイクル全体にわたって、組織のデータの健全性を監視・管理するためのツールや手法を提供します。データオブザーバビリティーによって、組織は、問題がビジネスユーザーに影響を与える前に、リアルタイムで積極的に問題を修正できます。

Data ObservabilityとDataOpsの関係とは？

データオブザーバビリティーは、DataOpsを可能にするフレームワークです。 DataOpsチームは、アジャイルアプローチを使用して、エンタープライズデータからビジネス価値を引き出します。しかし、誤ったデータや不正確なデータに問題があると、特に問題（別名：データダウンタイム）がビジネスに影響を与える前に検出されない場合、深刻な問題が発生する可能性があります。幸いなことに、AIを活用したデータオブザーバビリティーにより、組織はデータダウンタイムを検出、解決、防止できます。

Data Observabilityツールは、鮮度、統計的分布、ボリューム、スキーマ、リネージといったデータに関するものです。データオブザーバビリティーツールの正しい使用は、より質の高いデータ、信頼性の向上、そして運用面でより成熟した環境をもたらします。

DataOpsのステークホルダーは誰ですか？

組織内の全部門間の関係を構築する、強力な中心データチームを構築することは、データ運用の成熟度を達成するための重要なカギとなります。データチームは通常、最も関連性の高いデータセットを公開するため、意思決定、分析、およびデータモデルは、信頼できる1つののソースから確実に行われるようになります。一方で、その対極にあるデータアナリストや事業部門のユーザーは、質問やデータの回答から答えを抽出し、これらのデータセットを利用します。注意深く、意図を持って役割と責任を定義することは、組織が矛盾、冗長性、非効率を避けるのに役立ちます。

DataOpsのペルソナ

ここでは、データのライフサイクルに関わる最も一般的なプロフィール（別名：ペルソナ）を紹介します。

データエンジニア：** データエンジニアは、データを収集し、パイプラインを構築してソースシステムからデータストアに取り込み、アナリストやデータサイエンティストがデータにアクセスできるようにする役割を担っています。データのクレンジングと変換を行い、コアデータセットを公開します。クリーンで精選され、必要な人がアクセスできるデータをタイムリーに提供します。古くからあるデータ環境では、ETL（Extraction, Transformation, and Loading）の頭文字をとってETLと呼ばれます。 データサイエンティスト：** 統計学の知識を応用し、予測・処方モデルを構築します。一般的な環境はScala、Python、Rで、統計学以外にも、データマイニング、機械学習、深層学習などの専門家であることが多いです。例えば、金融業界では、数学に強いことから、伝統的に「クオンツ」と呼ばれています。 データアナリス／ビジネスアナリスト：** データの専門家で、通常、事業部門または機能部門（販売、マーケティングなど）に所属しています。 組織の運営方法、戦略目標、データが必要な場所や方法などに精通しており、ビジネス上の質問をデータクエリーに変換します。 エグゼクティブが目標を達成するために必要な情報や主要な指標を深く理解しています。フロントエンドBI（ビジネスインテリジェンス）ツールのエキスパートです。 データプラットフォーム管理者：** インフラが正常に動作し、十分な容量を確保し、インフラに依存している全ての部門に高品質のサービスを提供できるように管理します。トランザクション・データベース、データウェアハウス、データレイク、BIツールなどを担当します。さらに、アクセスポリシーの策定、インフラストラクチャーの管理、ライセンスコストの管理も行います。 事業部門データ利用者：** データの最終的な利用者であり、通常、意思決定のためにデータを使用します。BIツールに依存し、データの内容に基づいて行動を起こす責任を負います。例えば営業リーダーは、営業活動に基づいて、特定の地域にもっと投資することを決定するかもしれません。マーケティング・マネジャーは、ROI指標に基づいて、特定のタイプのキャンペーンにキャンペーン資金を割り当てることを決定するかもしれません。 チーフデータオフィサー：** データチーム全体の運営を監督します。通常、CEO、CTO、場合によってはCIOに報告します。

PagerDutyのDataOpsプロセスにおけるステークホルダーたち

上の図は、PagerDutyのDataOpsプロセスにおいて、ステークホルダーを従来の責任範囲に配置したものです。組織によって重なる部分はさまざまでしょう。

PagerDutyのDataOps

PagerDutyでは、PagerDutyと数少ないテクノロジーパートナーを活用したDataOpsのプラクティスを実装しました。PagerDutyとDataOpsの原則を適用することで、私たちは以下のことを実現しました。

複数のデータウェアハウスからMuleSoft、Segment、Fivetran、Kafka、Sparkパイプラインのデータセットが格納されている１つのデータウェアハウスに移行し、１つの信頼できるソースに統合できます。 自動化とデータテクノロジーのパートナーシップを活用することで、複数のデータワークロードから得られるデータのSLAを満たせます。 オブザーバビリティーを活用して、ユーザーが気づく前にデータを検出・解決し、インシデントを防げます。 データチームのフォーカスを、管理業務からデータ駆動型のインサイトとデータサイエンスにシフトさせます。 データ利用事例の急増に対応するためのデータ環境の将来性を高めます。 BIから新しい人工知能（AI）アプリケーションまで、複数の部署に所属する400人以上の社内ユーザーと数千人の顧客からの要求に対応するためです。

PagerDutyにおけるDataOpsの環境

上の図は、私たちのDataOps環境を構成するいくつかの主要なコンポーネントを描いたものです。 各組織のデータニーズやデータ環境はそれぞれ異なりますが、私たちの問題やアーキテクチャがそれほどユニークでないことはお分かりいただけるでしょう（複数のデータウェアハウス、複数のETLツール、厳しいSLA、データセットに対する膨大な要求など）。おそらく皆さんは、既にご自身のデータ環境とアーキテクチャーの類似点や、共有されている高レベルの問題をいくつか発見していることでしょう。

PagerDutyはDataOps環境でも活用できます

PagerDutyデジタルオペレーションプラットフォームは、データの問題が発生するとすぐにデータチームと下流のデータユーザーや消費者に警告を発し、データのダウンタイムを防ぎます。現在公開されている6つのDataOpsまたはデータ関連のインテグレーションをエコシステム内で発表できることをうれしく思います。これらのテクノロジーパートナーは、組織全体におけるデータパイプラインとデータ品質の問題を解決します。 コラボレーションを改善し、摩擦を減らし、アライメントを改善することでデータの失敗を減らします。

• Monte Carlo：エンドツーエンドのデータ観測性を提供し、データのダウンタイムを事前に解決します。 Lightup : 企業がクラウドスケールで優れたデータ品質を達成できるよう支援します。 Arize ：機械学習（ML）モデルの問題を監視し、トラブルシューティングし、解決するための観測可能なプラットフォームです。 WhyLabs：データとモデルの監視を提供することで、コストのかかるAIの失敗を防止します。 Prefect：リアルタイムアラートによるデータパイプラインの構築と監視を提供します。 Astronomer： パイプラインのリアルタイムデータ監視により、データのダウンタイムを削減します。

PagerDuty DataOpsエコシステム

最も重要なことは、これらの新しいDataOpsとPagerDutyの統合は、データパイプラインオーケストレーション、テストとプロダクション品質、デプロイの自動化、データサイエンス／MLモデル管理などの主要な領域をカバーしているということです。 PagerDutyとこれらのPagerDutyエコシステムテクノロジーパートナーを組み合わせることで、部門横断的なチーム間の緊密なコラボレーションを促進し、より少ないデータダウンタイムでより良く迅速な意思決定を達成できますので、是非お試しください。同様に、PagerDutyインテグレーションを構築しようと考えている場合は、開発者アカウントにサインアップして開始してください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

今日のデジタル社会では、企業は常に変化を強いられています。クラウドへの移行や大規模なDevOpsの展開などが、全てイノベーションを推進するというお題の下で行われています。しかし、モノリシック構成からマイクロサービスへ移行すると、アプリケーションはますます分散化します。問題が発生したとき、顧客はチームやサービスの数、アーキテクチャーの複雑さなど気にも留めません。ただ、必要なときに必要なサービスが動くかどうかが重要なのです。

そのためには、チーム、サービス、データなど、全てを一元管理することが重要です。緊急の仕事がチケット管理ツールで一元管理されては困ります。

そこで、ITサービスマネジメントツールとデジタルオペレーションプラットフォームを組み合わせることで、中央のITと分散型チームとの間のギャップを埋めることができます。PagerDutyとServiceNowを組み合わせることで、レスポンダーたちは遅滞なく行動を起こすための自動化を利用できるようになり、全アクティビティーの完全な履歴を維持しながら、数秒でリアルタイムの対応を実現することが可能になります。この組み合わせにより、インシデントに対するビジネスレスポンスも合理化され、関係者は常に最新の情報を得られます。

この”better together”アプローチは、現代の企業スタックで活用されているインシデント対応プロセスの代表的なものです。PagerDutyは、IHS Markitのようなお客様にもご利用いただいています。

文化の衝突

IHS Markit は、金融サービスプロバイダー、政府機関、その他主要産業に対して、分析およびインテリジェンスを提供しています。英国ロンドンに本社を置き、全世界で1万6000人の従業員を擁しています。

IHS Markitは、急速に拡大するハイブリッド運用をまとめ、ビジネス全体を完全に可視化し、集中管理されたコマンドセンターからインシデントを管理する必要がありました。同社は買収によって成長し、現在では約700の顧客向けサービスと300の社内向けサービスを提供していました。この規模でのインシデントの追跡は非常に困難であり、ビジネスのさまざまな領域が持つ相反する要件によって、さらに困難になっていました。

DevOpsチームは** 、あらゆる監視のニーズを完全に制御しながら「アジャイルで自律的で素晴らしい」状態を維持したいと考えていました。DevOpsの主要な要件は、チームがチケットを発行したり、ServiceNowにログオンする必要がないようにすることでした。 オペレーションコマンドセンター（OCC）チームは** 、より伝統的なITIL（IT Infrastructure Library）構造に基礎を求め、ServiceNowをベースにシステムを構築していました。このチームは、より優れたスケジューリングとエスカレーションポリシーを求めましたが、"既存の成熟したインシデント管理プロセスへの影響はゼロ "でした。 コンプライアンス** IHS Markitは、さまざまな規制下で多くの製品を扱っているため、ServiceNowの共通の記録システムで管理し記録を追跡することを望んでいました。 経営陣は** 、チームがDevOpsと連携しているか、より伝統的なITILを基にしているかに関わらず、全チームにわたりグローバルな監視を行うことを求めました。経営陣は、ServiceNowがこの可視性を提供することを望んでいました。

IHS Markit は既にPagerDuty を導入していましたが、その利用を拡大したいと考えていました。IHS MarkitのObservability担当ディレクターであるJohn Kennedy氏は、"インシデント管理を全社的に水平展開し、適切に管理できる１つのエンタープライズサービスにまとめたいと考えていました"と説明しています。

全ての人のためのソリューション

これを実現するために、IHS MarkitはServiceNowのインシデントとPagerDutyを統合しました。IHS MarkitはPagerDutyのカスタマーサクセスチームと協力し、PagerDutyのプラットフォームをカスタマイズして全ての要件に対応し、運用を改善しました。

これにより、DevOpsチームはPagerDuty内でサービスのオーナーシップを維持できるようになりました。これらのチームにとって、ServiceNowとの統合は「ステルス」導入されたもので、プラットフォームにログインすることなく、全てがServiceNowで追跡・記録されました。

OCCチームにとって、PagerDutyとServiceNowの統合は、既存のインシデント管理プロセスをそのまま維持することを保証するものでした。PagerDutyをまだ導入していなくても、誰もがPagerDutyのダッシュボードを介して主要なインシデントを監視することができます。インシデントマネージャーはワンクリックで、上級管理者や製品の専門家など、さまざまなスキルを持つ専門チームを迅速に呼び出すことができました。

また、PagerDutyはシステム全体を一望できるため、コンプライアンスと経営陣の可視化の要件も満たしています。

「全ての重大インシデント管理はPagerDutyで行われ、インシデントがPagerDutyの外で発生した場合は、重大インシデントの管理者がPagerDutyと同期するようになっています」とJohn氏は説明します。「そのうえで、レスポンスプレイを使って経営者を呼び寄せ、迅速な意思決定ができるようにしているのです。その結果、特にMTTRの面で大きな効果を得ています」。

このBetter Together連携により、中央のIT部門は、分散したチーム全体への可視性とアクセスを確保することができます。これは、IHS Markit が成長を続けていく上で不可欠なものです。

IHS Markitの次なる目標は？

今後、IHS Markit は可視性の一元化を進めていく予定です。「アジャイルとDevOpsの方法論が全社的に大きく広がっており、インシデント管理のコンバージドモデルの次の進化を考える必要があります 」とJohnさんは述べています。

また、DevOpsが「アジャイルかつ自律的」であることを維持することも、主要な焦点となることでしょう。「そのため、ServiceNowのテクニカルサービスを考え、その階層にフックする必要があるかどうかを判断する必要があります」と、Johnさんは説明します。「ガバナンスも重要ですーつまりシステムの品質を維持し、それをどのように一元管理するかということです」。

DXが進み、チームがこれまで以上に分散する中で、緊急の仕事を管理するビジネスプロセスをリアルタイムで運用できることが重要です。PagerDutyがServiceNowやその他のITSMツールをどのように強化し、解決時間の短縮と連携強化を実現するかについては、以下のリソースをご覧ください。

ITSMツールとPagerDutyの組み合わせで、リアルタイムに仕事をするためのダイナミックなデュオを作る方法

ITSMの強化

ソリューション概要 PagerDutyでITSMワークフローを拡張する

そして、PagerDutyの動作を確認する準備ができたら、14日間無料でお試しください。 訳注：IHS Markitは2022年2月にS&P グローバルに買収されました。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

顧客の期待値の変化

ここ数年、顧客からの要求が大幅に増加し、カスタマーサービスの担当者はプレッシャーを感じています。最近の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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。

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

しかし、サハラ以南のアフリカの農村部では、信頼できる電力を持つ病院は約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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

単独のオンコールエンジニアがオンラインで問題解決に当たる場合もあれば、CTO、CISO、CIOといった上級技術者まで巻き込んだ大規模なチーム横断の取り組みまで、インシデントレスポンスチームは、顧客が気付く前に問題を解決できれば御の字です。しかし、顧客に影響が及ぶようなケースでは、営業やカスタマーサービスなど他のステークホルダーにも情報を提供し、最新情報を入手する必要があります。

インシデントレスポンスとは、システム内で発生した予期せぬ問題に対する技術的な対応を指します。問題発生を知らされたSME（Subject Matter Expert：専門家）が戦場に飛び込み、問題点を診断し、修正し、システムを正常な状態に戻します。

しかし、高度にデジタル化した今日の世界では、顧客向けアプリケーションで発生したインシデントは、対応する技術チームだけでなく、より広い範囲に影響を及ぼします。もちろん、お客様は自分のツール、アプリ、ポータル、ゲーム、ショップがなぜ動かなくなったのか不思議に思っています。そして、社内では、リーダーシップや他のビジネスラインのステークホルダーが答えを探しています。

この「偉い人の差し出口とちゃぶ台返し」は、状況報告のために作業を中断しなければならないレスポンダーにとっては迷惑で威圧的と思われるかもしれませんが、このコミュニケーションは見落とせないのです。コミュニケーションは、インシデント対応プロセスの重要な部分であり、特にハイブリッド／リモートワーク方式を採用しているチームでは、その重要性が増しています。そして、技術者と非技術者の双方がサポートと権限を得てインシデントを見届けるためのやり方があるのです。

ビジネスインシデント対応とは、深刻な技術的インシデントからビジネスへの影響を軽減するための非技術的な対応フレームワークです。ビジネスインシデント対応は、通常業務を緊急業務モードに移行させることと、外部の顧客や社内のステークホルダーとの積極的なコミュニケーションを管理することの２つの主要機能から構成されます。今回のブログでは、顧客とチームの両方の体験を向上させるためのコミュニケーション管理に焦点を当てます。

誰が知る必要があるのか

インシデント発生時には、何が起こっているのかについてさまざまなレベルの詳細を必要とする複数の関係者が存在します。舞台裏で起きていることについて顧客が深い技術的理解を必要とすることはまずないでしょう。また、顧客向けの短いコミュニケーションで経営陣が満足することはないでしょう。読み手に応じて、メッセージを調節することが大切です。

コミュニケーション作成に万能のアプローチはありませんが、事件の優先順位が高い場合には、コミュニケーションを検討すべき相手がいます。ここでは、念頭に置くべき５つの対象者を紹介します。

経営陣。** 経営幹部は、優先順位の高い問題について情報を得たいと考える最も一般的なステークホルダーですが、技術に最も明るいとは限りません。前もって最重要事項を伝えておくとよいでしょう。彼らが最も気にすることの１つは、顧客への影響です。また、ビジネス上必要であれば、SLA違反も気にかけるかもしれません。また、何かニーズやリソースがある場合は、早い段階で頻繁に問い合わせを行い、必要なサポートを受けられるようにする必要があります。 カスタマーサービスチーム。** これらのチームは、インシデントの最前線にいることが多いのですが、解決プロセスがどのように進んでいるのかが分からないまま置いてきぼりになっていると感じることがあります。カスタマーサービスチームは、サービスがいつ正常に戻るかについて、顧客とコミュニケーションを取りたいと考えています。このようなチームが、新しいインシデントの進展について最初に知ることができるようにすることが重要です。これは、顧客とエンジニアの間のコミュニケーションの橋渡しとなり、信頼を育むことにつながります。特に重要な顧客においては、このような配慮が解約と更新の分かれ目になることがあります。 その他の技術チーム。** 自分が担当するサービスでのインシデントが、他のチームに影響を与えることがあります。彼らは、それについて積極的に何かをすることはできませんが、それでも情報共有されておく必要があります。優先度の高いインシデントでは、顧客への影響、関連する進捗状況を共有し、必要な支援（人手を増やす、システムの異常に注意を向ける）を求めるとよいでしょう。この連絡では、関係者がシステムの観点から何が起こっているかを理解する可能性が高いため、チームの理解を深めるのに役立つのであれば、技術的な詳細まで踏み込むことができます。 その他の事業チーム。** マーケティング、セールス、法務、財務などのチームは、自分たちのビジネスのやり方に影響を与える出来事について知っておく必要があるかもしれません。マーケティング部門は、壊れたウェブサイトに見込み客を誘導するようなキャンペーンを中止したいかもしれません。営業部門は、デモを延期したいと思うかもしれません。法務や財務は、SLAのペナルティーを先取りしたいかもしれません。これらのチームは、おそらく技術的な面にはあまり関心がなく、あなたの役に立つようなリソースを持っていないかもしれません。しかし、これらのチームは、顧客への影響を理解し、定期的に進捗状況を報告する必要があります。 顧客。** 顧客に影響を与えるインシデントは、信頼を損なうおそれがあります。信頼を維持する１つの方法は、顧客に影響を与えるインシデントについて、顧客と率直にコミュニケーションすることです。顧客基盤がどのように分かれているかにもよりますが、これを２つのカテゴリーに分けて行うことは理にかなっているかもしれません。１つは、戦略的顧客グループ。もう１つは、それ以外の顧客層です。戦略的な顧客は、より頻繁に、より詳細なアップデートを求めるかもしれません。その他の顧客層は、インシデントが発生したことを理解し、その解決に取り組んでいることと、サービスが正常に戻ったことの２種類のお知らせが必要かもしれません。これは、組織の標準的なトーンとブランドとの関係によって異なります。

これで、更新が必要な人物の見当がつきました。しかし、社内でこの情報を整理する最善の方法は何でしょうか。特にインシデントの解決が優先される場合、このようなコミュニケーションを即座に調整するのはストレスが溜まります。

ビジネスインシデント対応のための社内準備

ほとんどの大規模インシデントでは、コミュニケーションリードの役割を果たす人がいます。この担当者は、ステークホルダーに状況の最新情報を発信し、ビジネスが正しい方向に進んでいることを確認し、さらなる影響を軽減する方法を理解している必要があります。

その他のインシデントの場合、このコミュニケーションリードは、ビジネスインシデント対応リードとは別の人物となります。コミュニケーションリードは、チームとエンジニアリングまたはオペレーションのリーダーとの間の全ての技術的なコミュニケーションに対処し、ビジネスインシデント対応リードは、全ての非技術的なステークホルダーとコミュニケーションを取ります。この２人は密接に連携しながらも、コミュニケーションを明確かつ合理的にするために、役割をはっきりと分ける必要があります。いずれの場合も、コミュニケーションは事前に可能な限り準備する必要があります。

そのための１つの方法として、テンプレートがあります。テンプレートは、対象者ごとに伝えるべきことを理解するのに十分な構造を持ち、かつ状況が変化した場合に編集できる柔軟性を備えています。テンプレートをいくつ作成するかは、組織が何を適切と考えるかによります。いくつかの主要な対象者向けに１つのテンプレートを用意する組織もあれば、対象者ごとにテンプレートを用意する組織もあります。また、優先順位やインシデントの段階に応じて、それぞれの対象者に対応するテンプレートを用意する組織もあります。どの程度詳細な設定が必要かは、社内のステークホルダーと顧客にとって何が適切かによって異なります。

これらのテンプレートも、ただ闇雲に作成すればよいというものではありません。むしろ、社内のステークホルダーのニーズを満たしているか、当人たちに確認する必要があります。さらに、インシデントが発生したときに、顧客と一緒にテストを行い、フィードバックに基づいてテンプレートを変更することもできます。最後に、テンプレートを使用する前に、社内で承認が必要なチームがあるかもしれません。多くの場合、法務部や経営陣は、大規模なインシデントが発生したときにコミュニケーションが円滑に進むように、テンプレートを閲覧し、承認することを望みます。

ステークホルダーとの信頼と透明性の構築

ビジネスインシデント対応策を準備しておくことは、重要な情報を社内でよりよく伝達するのに役立ちます。さらに、インシデントの進行に伴い、情報や動向を積極的に共有することで、困難な状況下でも顧客の信頼を維持することができます。

上記のプロセスは、基本的なガイドラインですが、大規模な組織や成熟した組織では、プロセスの調整と簡素化を支援するツールが必要になります。PagerDutyは、ビジネス全体のチームが合理的な対応を調整し、特に数秒が重要なときに、全ての瞬間について顧客への影響を最小限に抑えることができるようにします。

14日間無料でお試しいただき、お客様のチームの改善にどのように貢献できるかをご確認ください。ビジネスインシデント対応についてもっと知りたい方は、こちらの「Ops Guide」をご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

ここ数年、ストリーミング、ショッピング、仕事、ヘルスケアなど、私たちの世界はますますデジタル化しています。顧客はこれらのデジタル体験がシームレスであることを望んでいます。これはあらゆる企業にとって重要な優先事項となっています。なぜなら、企業の売り上げやブランドの評判は顧客満足度に左右されるからです。 このようなシームレスなデジタル体験を保証するために、テクノロジーチームは信頼性、ユーザー体験、新機能の構築に過去と比べ倍以上の努力を払ってきました。しかし、デジタルの世界は完璧ではありません。問題が発生した場合でも、顧客を安心させ、維持するために、企業はこれまで以上にカスタマーサービス（CS）チームを必要としています。 PagerDuty for Customer Serviceは、カスタマーサービスチームがプロアクティブになり、ケースに費やす時間を短縮し、SLAを達成し、比類のないレベルのカスタマーサービスを提供できるよう支援します。 昨秋当社は、Salesforce Service Cloud用の PagerDutyアプリケーションを発表しました。これにより、ユーザーは Salesforce Service Cloudで直接作業でき、コンテキストを切り替える必要性が減りました。これにより、カスタマーサービスチームは、迅速かつ効率的に、そして部門を越えて仕事ができるようになりました。今回、カスタマーサービスエージェントのユーザーのために、さらに多くの機能を発表できることを嬉しく思います。これらの新機能により、チームは顧客に影響を与える問題の影響範囲を把握し、より迅速に対応できるようになります。

Incident Subscription Incident Subscriptionにより、CSエージェントは、リアルタイムのサービスステータスコンソールを介して、SFDC内で直接インシデントを閲覧（サブスクライブ）できるようになりました。シングルクリックで、エージェントはインシデントの進捗と解決に関するリアルタイムのアップデートを受け取ることができます（以前のように、チケットとインシデントを手動で「リンク」させる設定は必要はありません）。一度サブスクライブすれば、エージェントは自分のキューにある他の顧客チケットを処理することができ、影響を受けた顧客とのループを閉じるときにPagerDutyが再エンゲージするのを知ることができます。

ダッシュボードトグル この新機能により、カスタマーサービスエージェントは、自分たちに特化・関連したStatus Dashboardを持てるようになります。顧客向けサービスに特化したビジネスサービスのStatus Dashboardを作成できるため、バックエンド全体のシステムヘルスと顧客に直接関連するシステムヘルスを分けて表示することができます。これにより、CSはよりシンプルになります。

PagerDutyのインシデントタイトルをSalesforceのデータでカスタマイズする エージェントはさらに、Salesforceのケースから得た重要な情報に基づいてチームがPagerDutyのインシデントをカスタマイズできるよう、強力に支援できます。このデータにより、顧客と問題と緊急性を特定し、複数のケースをPagerDutyのインシデントにリンクさせることが容易になります。エージェントは、ケースをドリルダウンしたり、ツール間でコンテキストを切り替えたり、ケースの進行に関するリアルタイムの更新を確認したりすることなく、どのインシデントに関連するのかを一目で確認し、できるだけ多くの詳細を提供することができます。

PD WebでリンクされたSF案件の可視化 インシデントが顧客に与える影響範囲や、問題によって影響を受ける顧客の数を気にしたことがありますか？ もう悩むことはありません。PD Web、モバイル、電子メールのいずれでも、PD for Customer Serviceはインシデントに関連するケースをリンクしてレポートします（逆もまた然り）。なぜでしょうか？カスタマーサービスエージェントは、受け取ったケースの数に基づいて、特定のインシデントの緊急性を正当化できるからです。また、インシデント対応では、障害に対してどれだけの顧客が不満を抱いているかを確認できます。結局のところ、顧客はデジタル資産の健全性を示す重要な信号なのです。 これらの新機能により、サポートチームとレスポンスチームの間のサイロを継続的に解消し、あらゆるインシデントに迅速かつ容易に対応するための方法を、カスタマーサービスチームに提供していきます。これにより、カスタマーサービスエージェントは、ケースを最初から最後まで自分で管理できるようになります。

PagerDuty Customer Service Opsについて詳しくはこちら。さらに、営業に連絡するか、14日間の無料トライアルに申し込むと、すぐに始められます。

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

Round Robin Schedulingについてお聞きになったことや、自分のチームに合っているかどうか検討されたことがあるかもしれません。このオンコールスケジューリングの方法を考えるとき、Round Robin Schedulingがどう使われ、どんなチームに最適なのか理解することが大事です。さらに、避けたい落とし穴だけでなく、採用すべきベストプラクティスもあります。このブログでは、PagerDutyのRound Robin Schedulingについて知っておくべきこと、そしてどのように始めるべきかを紹介します。

Round Robin Schedulingの仕組みは？

Round Robin Schedulingは、チーム全体のオンコール責任を分散させる方法です。これにより、より柔軟なローテーションが可能になり、複数のレスポンダーが同じシフトにオンコールで対応することができるようになります。新しいインシデントを異なるユーザーに公平に割り当てることで、チームが燃え尽きるリスクをできるだけ少なくし、効率的にインシデントを解決できます。

多くの組織では、スプレッドシートを使い、たくさんの手間をかけてこのプロセスを始めています。ある人がインシデントに対応するたびに、マネージャーはスケジュールを移動し、別のインシデントが発生したら次の人の出番を知らせなければなりません。これでは、その場しのぎの対応になり、チームは常にすぐオンラインに移れることを期待されているような気がしてしまいます。Round Robin Schedulingは、それをサポートするツールがなければ、恩恵というより重荷になるかもしれません。そこで、PagerDutyの出番です。

PagerDutyのRound Robin Schedulingを使うと、あなたのチームは燃え尽きを減らすために、必要に応じて作業を分配しながら、同じサービス上で発生した複数のインシデントをシームレスに解決できるようになります。あなたがオンコール中であり、同時に発生した２つ以上のインシデントを担当すると想像してみてください。すぐに無理と思ってしまうのは目に見えています。Round Robinなら、複数のインシデントに必要な人数を投入し、お客様への影響を確実に軽減できます。

以下は、働き方の比較です。

しかし、Round Robin Schedulingは、あらゆるチームに適しているのでしょうか？必ずしもそうではありません。このメソッドが例外的にうまく機能するチームのタイプが２つあります。

Round Robin Schedulingで最も得をするのは誰？

オンコールの方法を作ったり、変更したりするのは難しいことです。ある特定のオンコールメソッドを使うには、チームの目標やインシデントボリュームを考慮に入れ、最適だという理由を基に決める必要があります。多くの場合、Round Robin Schedulingから一番恩恵を受けるチームがいくつかあります。

カスタマーサポートやヘルプデスクのチーム。 時間帯や週末、祝日をまたいで常に電話がかかってくるようなチームでは、１人のオンコール担当者では、殺到する電話に対応しきれない場合があります。むしろ、Round Robin Schedulingは、予定外のチームメイトにタグを付ける必要がなく、あらかじめ決められた人々がリクエストを処理し、チーム全体に均等に作業負荷を分散することができます。

中央ITチームまたはNOC。 カスタマーサポートやヘルプデスクと同様に、これらのチームは24時間体制で人員を配置し、大量のリクエストを受けることがよくあります。複数のサービスをサポートする中央のITチームやNOCでは、インシデントの量が１人のオンコールエンジニアの能力を簡単に越えてしまうことがあります。さまざまなインシデントに最初に対応するチームにとって、レスポンダーを増やせることは、適切な特定課題の専門家（SME）を迅速に投入することを可能にし、お客様への影響を軽減できます。

Round Robin Schedulingのコツとベストプラクティス

Round Robin Schedulingのコツをつかむには、少し時間がかかることがあります。任意のオンコール変更と同様にすぐには完璧にはできないでしょう。人々は、オーバーライドしたり拒否したりする権利を持っています。克服すべき課題があるでしょう。しかし、ここでは移行を容易にするために使えるヒントがいくつかあります。

毎週末、全員をオンコールにするのはやめる。** 毎週末や夕方にチーム全員を待機させるのは理にかなっているように思えるかもしれません。結局のところ、仕事をより多くの人で分担すれば、１人当たりの負担は当然軽くなります。しかし、これでは、常にオンコール状態であるかのように感じられてしまうかもしれません。それよりもオンコールのシフトを快適にこなすために必要な最低限の人数を考え、その人数でシフトを組むようにしましょう。他の人が息抜きできるような休憩時間を確保するのです。 チームメイトが休みを取る場合、その人たちが呼び出されないと分かっていてもローテーションから完全に外しておくこと。** 典型的なオンコールシフトがどのようなものかはご存じのはずです。あなたのチームが十分大きく、処理すべきインシデントの量も少ないと、ローテーションの最後にいる人が電話を受ける可能性は極めて低くなるかもしれません。それでも、休暇中の人はローテーションから外しておくことが重要です。仕事を離れている間、心からくつろぐことができるようにするだけの目的であっても。 動き回れ！** チームによっては、これは奇妙に映るかもしれませんが、オンコールのため、一日中デスクに座ってスクリーンを見ている必要はない、ということです。問題が発生したときに、その問題を解決するために利用できるようにすればよいのです。また、PagerDutyモバイルアプリを使えば、多くのインシデントを外出先で解決できます。 チームを訓練する。** 複数の人がオンコールで対応するからといって、新しいチームメイトへの教育を怠ってはいけません。ラウンドロビン型のオンコールローテーションでは、一貫した顧客体験を確保できるだけの、同じようなスキルセットと専門知識レベルを全員が持っている必要があります。毎週オンコールのレビューを行うことで、知識のギャップを明らかにし、チームメンバー間の情報共有を促すことができます。 チームと確認し合おう。** ラウンドロビンは燃え尽き症候群を減らすのに役立ちますが、万能薬や特効薬ではありません。特に、チームメンバーが複数のオンコールローテーションに参加していて、現在のローテーションに加えて他の問題にも取り組んでいる場合は、チーム内でチャットをして、誰も負担を感じていないことを確認し、必要に応じてローテーションを調整する必要があります。

あなたのチームでも試してみませんか？

Round Robin Schedulingは、通常、全ビジネスプランとデジタルオペレーションプランで利用可能です。現在ご利用中のお客様で、この機能へのアクセスを解除するためのアップグレードをご希望の場合は、PagerDutyアカウントチームまでご連絡ください。まだお客様でない方は、この機能を14日間無料でお試しいただけます。

Round Robin Schedulingの詳細については、こちらのサポートドキュメントをご覧いただくか、こちらのYouTubeショートムービーをご覧ください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

セキュリティーがより高度かつ利便性が高まるにつれ、企業は競争力の維持のために、より効率的にリソースを活用する方法を模索する必要があります。従業員のリソースが限られている、サービスの遅れに対する顧客の許容度が低いなど、企業の能力を制限する課題がある中、信頼性が高く、手ごろな価格のソリューションが必要とされています。この場合、従来のセキュリティー業界の概念を壊すことを意味します。組織は、自動化とテクノロジーを頼りにして、目標を達成しているのです。

Knightscope社がリードする

米国の先端セキュリティー技術企業であるKnightscope社は、過去9年間にわたり、Autonomous Security Robotsで業界をリードしてきました。同社は、ショッピングモールや駐車場、近隣、カジノなどの公共の場で人や車を監視するためのAutonomous Security Robotsを設計、製造、配備しています。ロボットとプロアクティブなモニタリングによって、セキュリティーリスクを抑止しレポートすることで、公共の安全を革新してきました。Knightscope社のミッションは、「アメリカを世界で最も安全な国にする」という野心的なものです。

Knightscope社が2015年に最初のロボットを出荷したとき、セキュリティーロボット業界はまだ黎明期でした。競合が少なく、業界の風景はまっさらな状態だったため、Knightscope社はパイオニアとなりました。同社は自律型セキュリティーロボットの分野に真っ先に飛び込み、今では100台以上の自律型セキュリティーロボットと契約しています。

多くの労力が必要

Knightscope社の全てのロボットは、基本的には同社のAPIソフトウェアのための器です。ロボットが収集したデータこそが、同社の真の商品なのです。システムを稼働するためには、複数の部門が連携し、可能な限り効率的に作業する必要があります。Senior Operations ManagerのJane Miller氏は、Knightscope社のNetwork Operations Center（NOC）を管理し、クライアントのロボットを24時間365日稼働するための保守を担当しています。「NOCは、私たちのロボットの技術的な問題を解決するための最初の防衛線なのです」と、Miller氏は述べています。

NOCは、ロボット内のコンピューターのハードディスクが満杯になるなど、営業時間外も含め、いつでも潜在的なソフトウェアやハードウェアの問題に対処する必要があります。また、Knightscope社のソフトウェアは自律型警備ロボットで動作しているため、ソフトウェアの不具合とは別に、ロボットの容器自体に問題が発生することもあります。例えば、荒らされたり、車にひかれたりすることもあります。どのような判断をすればいいのか分からない状況で、人間の介入が必要になることもあります。このような場合、オンコールで対応するチームメンバーは、適切なチームに引き継ぐ準備として、問題解決や診断完了をしておく必要があります。

Miller氏は、Knightscope社のソフトウェア・インターフェースによってクライアントがロボットと対話できる、Security Operations Center（KSOC）の技術的なクライアントサポートも担当しています。ここでは、クライアントがロボットから送られてくる映像を見たり、ロボットがSecurity Teamに電話をかけるようプログラムされた緊急電話システムを利用したりできます。また、脅威やアクセス制限区域に侵入を発見した場合、音声アナウンスを促すことも可能です。

さまざまなシステムや部門が存在することによって、問題解決は複雑化する可能性があります。同社はテクノロジーカンパニーなので、全システムとチーム連携のために信頼と実績のある方法が必要だと理解しているのです。

PagerDutyはNightscope社のソリューションです

Knightscope社は2015年からPagerDutyを利用して、リアルタイムな運用管理を行っています。PagerDutyのAPIを独自のロボットソフトウェアに接続し、ロボットのハードウェア、ソフトウェア、自律的な意思決定を監視しているのです。ソフトウェアの一部が予期せずクラッシュした場合や、ロボットが物理的なヘルプを必要とする場合、ロボットとの接続が失われた場合などは、チームはPagerDutyを介してプロアクティブな通知を受け取ります。また、PagerDutyはロボットの健康状態に関するデータも提供し、新しいソフトウェアのリリースやバグフィックスが期待通りに動作しているかどうかを確認します。

「また、ハードウェアやソフトウェアに問題がある場合は、セキュリティーの観点からロボットが必要なことを全て行っているかどうかを確認します。何か問題があれば、PagerDutyが知らせてくれて、私たちが対処します。新たな問題が発生した場合は、調査し、研究開発チームにエスカレーションします」とMiller氏は言います。

PagerDuty Incident Responseはここでその価値を発揮します。ロボットが正常に動作していない場合、「PagerDutyを使って、ロボットがクライアントをサポートするために必要なことを全て行っているかどうかを確認しています」とMiller氏は語っていました。実際、Knightscope社で働き始めた新入社員にとって、何か問題が発生したときに、大量のデータをかき集める代わりにPagerDutyが教えてくれるというのは大きな安心材料となっています。

PagerDutyは、Knightscope社が新しい機能とプラットフォームを開発し続ける中で、適応性と信頼性があることを証明してきました。テクノロジー企業、特に業界のディスラプターが驚異的な進歩の最前線にいるとき、そのシステムは軽快で素早く変化できることを保証する必要があります。「私たちはまだスタートアップ文化にいるので、常に物事に変化を与え続けています。チームにとって、PagerDutyを新しいテクノロジーに統合し、適応しながら成長するのは本当に簡単なことでした。このおかげで、私たちはいつでもクライアントと一緒に仕事ができる状態にあります。」とMiller氏は言います。

Knightscope社は以下のような部分から、PagerDutyの利便性を感じています。

使いやすさ** ー PagerDutyのカスタムAPIを使って簡単に自社のソフトウェアと統合できる 適応性と俊敏性** ー 新しい機能、プラットフォーム、テクノロジーを簡単に実装できる 柔軟性** ー ローテーションスケジュールや通知を簡単に作成、変更できる 費用対効果** ー 24時間365日利用可能なオンサイトロボットにより、人の労働力を削減できる

未来が変化している

Knightscope社の未来の可能性は無限大です。テクノロジーの世界においては、変化は確実なものなのです。優先順位、危機、予算、信頼できる従業員へのアクセスなどが常に変化する中、Knightscope社のような企業は、効果的で一貫したソリューションを生み出す方法を常に模索しています。同社はセキュリティーの新時代を切り開き、その目標を達成するためにPagerDutyを頼りにしているのです。

PagerDutyがどのよう組織に役立つかを知るには、アカウントマネージャーに連絡するか、今すぐ14日間の無料トライアルをお試しください。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

2023年、顧客維持のための戦いは、全ての人が予測する「ビジネスが不況を生き残れるかどうか」を決定づける、最大の要因の１つになるでしょう。Salesforceが発表した「2022 State of Service Report」によると、顧客維持の中心にあるのは優れたサービスであることが分かりました。48%の顧客は、何か問題が発生した場合、よりよいカスタマーサービスを求めてブランドを切り替えると回答しています。オープンなコミュニケーションは、顧客がカスタマーサービスの質を評価する際の重要な要素であると捉えているのです。顧客は、最も回復力のあるデジタルシステムでさえ、時折問題が発生する可能性があることを理解しています。しかし、そんな問題によって取り引きや企業との交流が妨げられ、全てが不透明なまま放置されることは許さないでしょう。

お客様の信頼とロイヤリティーを高めるには、問題の進行状況について積極的かつ詳細なコミュニケーションを確立することが重要です。しかし多くの企業では、顧客との迅速かつ積極的なコミュニケーションに必要なプロセスが手作業や引き継ぎ、複雑さによって、必要以上に多くなっています。

PagerDuty Status Pagesは、このような複雑な状況を打破するために開発されました。PagerDuty Status Pagesは、組織のオペレーションを視覚的にリアルタイムで把握できるため、ブランドはあらゆる状況下で顧客に積極的に情報を提供し、支援できます。インシデントが発生した場合、PagerDutyユーザーは、PagerDuty Operations Cloudから直接、顧客とリアルタイムのオペレーションアップデートを安全に通信し、好みのオーディエンス別通信サービスを活用できるようになります。この新しいアドオン機能は、PagerDutyのカスタマーサービスとインシデント対応ソリューションを、当社のパートナーや顧客にも拡大するものです。

メリット

私たちは、サービス担当者の生活をより快適にし、お客様の時間とコストの節約を目指しています。現在、積極的なコミュニケーションにより、チームはお客様が気付く前に、問題があることをお知らせできています。これにより、障害発生時にカスタマーサービス部門に送られるチケットの数を減らし、各チケットの人件費削減につながります。また、最新情報を入手するための信頼できる唯一の情報源を持つことで、特に時間が最重要となる場合に、エンジニアリングチームに送られる問題についての、他リクエストも回避できます。DevOpsとCSOpsの両チームは、認識が一致するため、時間とリソースを節約できるのです。

特に大規模な障害やイベントの際に、オープンな透明性を確保できるようになったことも、お客様にとって大きな価値となります。PagerDuty Status Pagesを利用することで、顧客との信頼関係を築き、サービスに問題が発生したときにすぐに知り、顧客が最も気になるステータスについて常に情報を得られます。これは全て同じ場所にある、信頼できる唯一の情報源なのです。

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