Blog
ブログ

スクラムセレモニーとは、スクラムイベントやミーティングの一種で、プロジェクトをよりタイムリーかつ効率的に進めることを目的としたものです。このセレモニーは、制作プロセスの重要なポイントで行うもので、チームメンバー間の組織的なコラボレーションとコミュニケーションを重視し、複雑な開発プロセスやキューを簡素化することを支援します。例えば、デイリースクラムは毎朝行われ、どの項目が完了し、どの項目に取り組んでいるか、そしてどの項目が先に控えているかを確認する儀式です。

スクラムセレモニーには、以下のような５つのスクラムイベントがあります。 スプリントプランニング：スプリントバックログを決定し、チームの期待値を設定するためにスプリントの最初に開催されます。 デイリースタンドアップ／スクラム：毎日（多くは一日の始まりに）行われる15分間のセレモニーで、チーム全体のアイテムの進行状況をスクラムチームメンバー全員に素早く報告します。 スプリント：スプリントは、スクラムチームメンバーが協力してスプリントバックログを完成させるためのイベントと考えられています。 スプリント／イテレーションレビュー：スプリントや特定のマイルストーンの終了時に開催され、完了した作業をレビューして発表します。 レトロスペクティブ：イテレーションの終わりに開催され、イテレーション中に何がうまくいったか、どんな問題が出てきたかを分析します。レトロスペクティブの目的は、継続的な改善を促し、開発を最善の方法で前進させることです。

スクラムやその他のアジャイル手法で非常に重要なのは、チームメンバーや利害関係者全員が制作のライフサイクルについて明確かつ共有した理解を持つことです。スクラムのセレモニーは、物事を整理し、前進させるための接着剤となります。 この記事では、これら５つのスクラムセレモニーについて、どのスクラムチームメンバーが関与するのか、それぞれのミーティングは通常いつ、どれくらいの時間行われるのか、そしてそれぞれのスクラムセレモニーの目的について詳しく見ていきます。

アジャイルメソドロジー＆スクラム

企業やその規模にかかわらず、全ての開発チームの主要な目標の１つは、新しい製品やアップデートを迅速かつ効果的にユーザーに展開することです。定期的かつ確実なアップデートによって製品／サービスの体験を継続的に改善できれば、ユーザーとの信頼関係やロイヤリティーが徐々に構築されます。さらに、幸せな顧客を持つことによる収益性の向上は、利害関係者との良好な関係を維持することにつながります。

今日、テクノロジー企業は、信頼できるプレミアムなユーザー体験を提供するために、アジャイル開発方法論を用いて生産プロセスの改善に役立てています。そして、これらのアジャイル開発手法の中で、スクラムは明らかにNo.1であり、約60％の組織が製品開発にスクラムを活用しています。スクラムは、作業内容、進捗状況、タスクやアイテムの優先順位など、チームの完全な理解に基づくものです。

スクラムの５つのセレモニー

スクラムセレモニー#1：スプリントプランニング

スプリントプランニングは、スプリントの最初に行われるミーティングで、スプリントバックログ（スプリント中にチームが完成させるべき項目の全一覧）を決定します。また、このミーティングでは、スプリントを成功させるために、チーム全体への期待値を設定する必要があります。

スプリントプランニングに参加するのは誰ですか？** スクラムの全役割（開発者、スクラムマスター、プロダクトオーナー） スプリントプランニングはいつ行われますか？** それぞれの新しいスプリントの開始時 スプリントプランニングのミーティングの長さはどれくらいですか？** １～２時間 スプリントプランニングはどのくらいの頻度で行うべきですか？** 全スプリントの前

スクラムセレモニー#2：デイリースクラム

デイリースクラムは、プロダクトバックログで何が起こっているかを全員に知らせるために、最も一般的には午前中に開催される短い毎日のミーティングである。このミーティングはかなり短時間であるべきですが、各メンバーが完了したもの、取り組んでいるもの、障害に遭遇していないかなどを議論する時間を確保する必要があります。

デイリースクラムに参加するのは誰ですか？** 全スクラムロール デイリースクラムはいつ行われますか？** 通常、作業の開始時 デイリースクラムの長さはどれくらいですか？** 15～20分 デイリースクラムはどのくらいの頻度で行うべきですか？** 毎日

スクラムセレモニー#3：スプリント

スプリントは、指定された時間ブロックの間にチーム全体が完了するように設定されたタスク（または仕事の塊）のリストです。これは、スプリントプランニングのセレモニーで示されるものです。

スプリントに参加するのは誰ですか？** 開発者 スプリントはいつ行われますか？** さまざまです スプリントの長さはどれくらいですか？** スプリントプランニングに基づき、各スプリントにはそれぞれブロック化された時間目標があります。スプリントの期間は数日から数週間、数カ月とさまざまですが、スプリントバックログの内容によって異なります スプリントはどのくらいの頻度で行うべきですか？** さまざまです

スクラムセレモニー#4：スプリント／イテレーションレビュー

スプリント／イテレーションレビューは 、スプリントやその他の特定のマイルストーンの完了後に開催されます。このセレモニーの目的は、完成した作品をレビューし、紹介することです。スプリント／イテレーションレビューでは、開発チームは完成した機能やアップデートをチーム全体に向けてデモンストレーションします。他のチームメンバーやステークホルダーからのフィードバックが得られるだけでなく、開発者にとっても自分の頑張りをアピールできるチャンスです。

ここで重要なのは、これはあくまで部分的なレビューであり、完全なレビューは「レトロスペクティブ」で行われるということです。

スプリント／イテレーションレビューに参加するのは誰ですか？** 全てのスクラムロール、ステークホルダー、プロジェクトの他のチームメンバー スプリント／イテレーションレビューはいつ行われますか？** スプリントやマイルストーンが終了したとき スプリント／イテレーションレビューの長さはどれくらいですか？** 最大４時間 スプリント／イテレーションレビューはどのくらいの頻度で行うべきですか？** スプリントが完了したとき

スクラムセレモニー #5： レトロスペクティブ

レビューが製品や完成した仕事に焦点を当てるのに対して、スプリントレトロスペクティブはプロセスに焦点を当てます。何がうまくいったのか、何が問題だったのか、プロセスの問題点を解消し、ツールを追加・調整し、人間関係やコミュニケーションを改善するための計画を立てる場でもあります。

レトロスペクティブに参加するのは誰ですか？** 全スクラムロール レトロスペクティブはいつ行われますか？** 完了したスプリントやその他のマイルストーンの終了時 レトロスペクティブの長さはどれくらいですか？** スプリントの長さ１週間につき最大45分（例：２週間のスプリントの場合、最大1.5時間のレトロスペクティブとなる） レトロスペクティブはどのくらいの頻度で行うべきですか？** スプリントが完了したとき

スクラムセレモニーのメリット

製品がますます複雑化する中、チームメンバー間の組織的なコミュニケーションとコラボレーションはこれまで以上に重要です。スクラムの５つのセレモニーは、チームメンバーが製品／プロジェクトについて共通の理解を持ち、製品ライフサイクルを通じて同期を保つことを支援します。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

DevOpsでは、オンコールプロセスについてよく話しますが、オンコール中の人間的な側面についてはどうでしょうか？例えば、シフト中のストレスや不安に対処する効果的な方法は何でしょうか？オンコール当番中に子供の世話をしなければならないなど、オンコールに専念しづらい生活状況とどのように両立すればよいでしょうか？また、共感的なチームカルチャーは、燃え尽き症候群や離職を防ぐのにどのように役立つのでしょうか？ 2021年11月から12月にかけて、PagerDutyの９つのチームのオンコールエンジニアが集まり、オンコールの人間的側面についてディスカッションしました。ここでは、そのセッションで得られた５つの重要なポイントを紹介します。

チーム内の共感が重要である 一日中グラフを眺めていてはいけない ポストモーテムはストレスになり、多くの労力を要する 緊急性の低いアラートは、夜間のノイズを減らす １週間のオンコールは燃え尽き症候群につながる可能性がある

それぞれの重要なポイントに入る前に、私たちが話を聞いたチームに関連するいくつかの指標を見てみましょう。

DevOpsは、ソフトウェアの提供とインフラストラクチャの変更のプロセスを自動化および加速しながら、ソフトウェア開発者とIT運用の専門家の間のコラボレーションとコミュニケーションを強調する文化、ムーブメント、実践手法です。 DevOpsプラクティスを実装するには、人、教育、ツール、組織の調整など、いくつかの種類の投資が必要です。しかし、これらの投資から組織が受け取るリターンを判断するのは難しい場合があります。効果測定では何を重視しますか？　どうやって投資を価値あるものにしますか？

DevOpsがROIに与える影響

DevOpsのない世界では、ソフトウェアリリースの頻度は低く、以前のリリース以降に開発チームによって構築されたすべての新機能、更新、および変更が含まれています。ビルドされたが次のリリースまで出荷されないコードは、ビジネスには何の価値も生み出しません。コードのユーザーへの配信を加速するということは、ジャストインタイムの製造のようなものであり、完了後すぐに価値を生み出します。そして、今日の継続的なデジタルトランスフォーメーションの世界では、新しい機能をデプロイし、競合他社よりも早く問題を解決する能力が、市場での優位性につながるのです。 DevOpsの主な目標の1つは、ソフトウェアリリースを頻繁に、定期的に、自動化することです。1日に複数回リリースする能力がある場合、個々の本番環境へのプッシュはたいしたことではありません。リリース頻度の低い「ビッグバン」スタイルの体制、つまり全員が臨戦態勢で、土壇場でのトラブルシューティングに追われ、やり遂げるまで深夜も週末も作業する運用チームを必要とするような体制と比較してください。デプロイの失敗によるダウンタイムを解決するために髪を振り乱すのではなく、より幸せで休息の取れた運用チームが次の問題を積極的に解決することの方が、組織にとって明らかにはるかに大きな価値があります。

あなたのチームはあなたの最大の資産です

DevOpsを実装する最良の方法は、解決が必要な問題に権限と責任の両方を集中させることです。最前線のチームは、時間が無駄になっているところ、隠れた非効率性がどこにあるのか、どこに最適化の機会があるのかを知る最適な立場にあります。プロセスに自動化を導入することについての最大の誤解のひとつは、それが必然的にチームから仕事を奪うということです。むしろ、面倒な手作業を自動化に置き換えることで、チームはより価値の高い活動に集中できるようになるのです。 結局のところ、あなたのビジネスをあなたのチームよりよく知っている人たちはいません。人件費にどれだけ投資したかを考えてください。チームの生産性を最大化することは、DevOpsを実装することによるROIの大きな改善点です。重要な問題の解決に時間を費やしてもらうことで、ビジネス全体の成果の量と質が向上し、面倒なエラーが発生しやすいタスクがToDoリストから削除されるため、リスクが排除されます。

ROIをビジネスの目標に結び付ける

では、DevOpsプラクティスを採用するためのビジネスケースを検証するために、ROIの適切な指標をどう選択すればいいでしょうか？　これはビジネスにとって大変重要なことです。デジタルトランスフォーメーションが広がるにつれ、新しいビジネスモデルと顧客との新しい対話方法が、あらゆる業界で生み出される価値を根本的に変えています。成功を測定するための鍵は、ユーザーに提供する独自の価値を理解し、それを達成するために指標を結び付けることです。顧客が目標を達成するために費やす時間を最小限に抑える、ユーザーあたりの収益を最大化するなど、DevOpsへの投資を主要なビジネス指標の改善に直接関連付けることができるはずです。

			時は金なり
			鍵は効率化
			柔軟に最適化を
		
	
	
		
			チームがより価値の高い問題に時間を費やすことができれば、あなたのビジネスにより多くの価値をもたらすでしょう。
			ボトルネックを防ぐために、問題に近い現場に権限と責任を持たせましょう。	
			どんなケースでも即通用するというものではありません。ビジネスにとって何が重要かを把握し、そのために最適化を図ってください。

そして忘れてはいけないのは、何かを測定できるからといって、そうする必要があるとは限らないということです。我々は時にビジネスの目標に関係ない指標に気を取られてしまいがちです。開発者の生産性を測定するためには非常に多くのツールが利用可能であるため、記述されたコードの行数や修正されたバグの数など、実際には重要ではないあらゆる種類のデータを追跡できます。計算や最適化は簡単かもしれませんが、ユーザーのために生み出そうとしている価値とは実際には関係のないことです。

「数えれられることすべてが大事なわけではないし、大事なことすべてが数えられるわけではない。」（ウィリアム・ブルース・キャメロン）

ビジネスへの教訓

DevOpsの変革とは、ITの流れを加速することを目的としたプロセスの変更がすべてです。つまり、ROIを測定する際の最大の課題は、DevOpsが提供するさまざまな種類のメリットを理解し、それらのメリットをビジネス目標に結び付けることができるかどうか、ということなのです。 配信されないソフトウェア在庫の山の削減から、手作業による障害リスクの削減、生産性と従業員の満足度の向上まで、DevOpsプラクティスを実装することの価値はすぐに得られます。今日のデジタル環境で競争力を維持しようとしている企業にとって、DevOpsに移行する余裕があるかどうかという問題は、「DevOpsに移行せず現状のままで安泰なのか？」という問いになってきています。

ROIの決定に使用できるDevOps指標

これらをあなたのビジネス目標に当てはめてください

			指標
			詳細とメリット
		
	
	
		
			1日／週／月あたりの本番環境へのプッシュ数
			本番環境への展開の頻度を増やすことで、ユーザーにビジネス価値を提供する速度を上げ、「倉庫の在庫」コードを減らすことができます。
		
		
			1か月／年あたりのダウンタイムの分数	
			自動化が進むと、アプリケーションのダウンタイムが削減されます。これは、ユーザーの満足度と収益に直接関係します
		
		
			自動テストカバレッジ	
			自動化を広範に使用すればするほど、手動エラーの可能性が少なくなり、移動が速くなります。
		
		
			新入社員がコードを本番環境にデプロイするのに必要な時間	
			新入社員が迅速に対応できるようにするためのフレームワークとプロセスを構築することで、新入社員の生産性が向上し、既存のチームの生産性も向上します。
		
		
			新しいイニシアチブと既存のプロセスの実行に費やされた従業員の時間	
			手動プロセスを自動化することで、チームは既存の問題に対処するのではなく、ボールを前進させることに時間を費やすことができます。
		
		
			従業員の幸せ	
			作業に忙殺されるのではなく貴重な問題に時間を費やしている幸せな労働者は、生産性が高く、長期間にわたって戦力となってくれます。これは、NPS（Net Promoter Score）を介して直接測定することも、トラブルシューティングに追われる夜と週末の数を介して間接的に測定することもできます。

2021年6月に開催されたPagerDuty Summit 2021から、注目セッションのご紹介のパート２です。

パート2では2つのセッションを取り上げます。最初のセッション「The power of PagerDuty in alert noise suppression」（アラートノイズ抑制におけるPagerDutyの力）は、Hudson’s Bay Company社のPlatform Visibility and Command Center Monitoring部門のディレクターであるMarcelo LaRosa氏が登壇しました。このセッションで彼は、測定対象を管理することで生産性と従業員の満足度がどう向上したかを共有しました。 ノイズ抑制に関しては日本の皆さんも興味のあるところだと思います。

さらにご紹介する2番目のセッションは「How PagerDuty & Rundeck Drives Operation Maturity」（PagerDuty＆Rundeckが運用の成熟度を高める方法）です。こちらはTrimbleのCloud Engineering and Infrastructure部門のディレクターであるAndrea Valenti氏と、TrimbleのシニアリードDevOpsエンジニアであるAli Soheili氏の講演です。

The power of PagerDuty in alert noise suppression： (アラートノイズ抑制におけるPagerDutyの力)

Hudson’s Bay Company社のMarcelo LaRosa氏 ©PagerDuty

「The power of PagerDuty in alert noise suppression」（アラートノイズ抑制におけるPagerDutyの力）の講演は、Hudson’s Bay Company社のPlatform Visibility and Command Center Monitoring部門ののディレクターであるMarcelo LaRosa氏によって行われました。

最初にLaRosa氏は、「誰もノイズなんか聞きたくない、特にモニタリングでは」と述べました。 彼は、受信する必要のないアラートを処理するためにアクションを実行する必要があり、アクション可能なアラートのみを受け取るようにする必要があると述べました。

最初に行う必要があるのは、PagerDutyでデータを収集することです。分析内で、レポートを選択し、月次データを取得する必要があります。彼は、「少なくとも1年分のデータを取得し、通常の月よりもアラートが多い可能性がある場所を確認すること」を提案しました。次に、その月次データを取得したら、特定のサービスごとに月次統計を分析する必要があります。彼は、高い頻度でアラートを出す上位3つのサービスを確認し、各サービスのCSVレポートをプルダウンして、ピボットテーブルビューを作成することを強く勧めました。

アラートノイズの問題を改善するための手順 ©PagerDuty

そのデータを入手した後に、彼はトップ3のアラートサービスのオーナーとの個別の会議を設定すべきだと強調しました。「サービスオーナーの知識に応じて、アラートをP1 / P2またはP3などとして優先し、警告を設定し、アラートをグループ化するなど、分類法を改善する必要があります」。そして彼が最後に提案したのは「メンテナンス」です。 彼は、改善のための、PagerDutyを使った反復的なモニタリングを確立することを提案しました。彼のチームでは、毎日、毎週、毎月のリズムを確立し、定期的にアラートをチェックしています。そして、ある時点で何かがトップ10に入っているのを見ると、すぐにそのデータの再分析を開始します。

最後に、彼は「継続的改善はまさにそれ自体、継続的に改善すべきである」と私たちに思い出させました。 彼は、こうした説明したプロセスを継続することを強く推奨しました。 「最初の数カ月は大変かもしれませんが、大量のアラートと戦ったあとは簡単になります。こうしたたくさんのレポートを取得する方法はおそらく自動化できます。 自然と会議ができるようになり、意見が出てきます。 その意見が広まり、人々が私たちを求め始めると、何か大きなことをやったんだと感じるようになります」。

How PagerDuty & Rundeck drives operational maturity： (PagerDuty＆Rundeckで運用の習熟度を上げる)

このセッションでは、建設をはじめ複数の業種にサービス提供している国際企業で、大規模なDXを遂げているTrimble社のシニアリードDevOpsエンジニアであるAli Soheili氏と、同社のクラウドエンジニアリングおよびインフラストラクチャのディレクターであるAndrea Valenti氏が講演しました。彼らのプラットフォーム 「Trimble　Project and Program Management」（Trimble PPM。同社の「Connected constructions Portfolio」の一部）は、PagerDutyとRundeckを使いインシデント対応プロセスを自動化しています。彼らがどうやってインシデント解決までの時間を短縮し、エスカレーションを削減したかを学ぶことができます。

まず、Andrea Valenti氏は同社の重要な目標のひとつとして、CEOのRob Painterの言葉を引用し「私たちがサービスを提供する業界のライフサイクルをつなぐこと」と述べました。PPMは、そのTrimbleにおけるSREの変革の最前線です。彼はPagerDutyとRundeckの導入の経緯を説明しました。特定の部門内だけでなくTrimble全体で、PagerDutyとRundeckの両方を長い間使用してきた経験があります。

TrimbleでのPagerDutyとRundeckの導入と自動化の歴史 ©PagerDuty

また、特に同社の「e-Builder」SaaSアプリケーション群で、すでに数年間PagerDutyを使用していると述べました。Rundeckについてはヨーロッパグループの輸送部門で最初のプロジェクトを開始したときかに使い始めたそうです。PPMでは、エンタープライズレベルでのセキュリティと統合を進めることが彼らにとって最重要なポイントであるため、彼らはさらに2つの製品を活用することを決めました。

Trimbleは、2018年以降、複数のアプリケーションの統合ポートフォリオの運用を開始しました©PagerDuty

2018年からは複数のアプリケーション、e-Builder、ProjectSight、Prolog、Prolianceの統合ポートフォリオの運用を開始しました。その運用は、全グループが独自の方法、独自のツール、独自の解釈とアイデンティティを持っているため、非常に困難でした。そこでSREグループはまず複数のグループでプロビジョニングとデプロイメントについて一貫性のある命名法を決めました。これはまだ継続中ですが、ほぼ確立しています。同時にインシデント管理についても命名法を決めました。以前はイベントがなぜ起きたかをチームごとに別々の見方で調べていました。そのためインシデントの状況を特定すること困難でした。そこで彼らは、イベント管理や各グループがもたらす多様性を消してしまうのではなく、決断をするようになりました。インシデントの概念にフォーカスして、全イベントをPagerDutyに集約することを決めたそうです。

次に、Ali Soheili氏は、SREチームを単一のクラウドチームに変えるべき3つの理由を共有しました。

Rundeckを使いビジネスオペレーションを自動化したことで得られた効果 ©PagerDuty

次に、インシデント管理がどう設定されているかを説明しました。同社ではNew Relicをはじめ複数の監視ソリューションがさまざまな部門で使われていました。Rundeckの利用目的の1つはそのオペレーションの自動化でした。彼らはそれらをセルフサービスとしてRundeckで自動化しました。結果として複数のチームがこれらのセルフサービスジョブを利用できるようになり、時間を大幅に節約できます。例えばあるケースでは、開発チームのオペレーションには5日間のサイクルタイムがありましたが、数分に短縮されました。コスト削減も大事な目的であり、このセルフサービスを使用するメリットの１つです。

次の図はPagerDutyとRundeckを使用して実行した自己修復の例です。

PagerDutyとRundeckを使用して実行した自己修復の2つの例 ©PagerDuty

最後に、Andrea Valenti氏は、RundeckとPagerDutyの利用について学んだことを共有しました。

自動的に修復をする実用的なフレームワークを用意してください。小さくて簡単なものでも、インシデントの優先順位付けで最上位に当たるP1をダウングレードする際に再利用できます。 SME（Subject Matter Experts）のセカンドラインが待機していることを確認してください。 PagerDutyを使用すると、複数の監視ツールからの情報を集約でき、インスタンスを表示する方法を1つに絞ることができます。

すべての画像の著作権はPagerDutyにあります。

PagerDuty Summit 2021のサイトでは詳しい資料と動画を公開していますので、こちらをご覧ください。

2021年6月に開催されたPagerDuty Summit 2021から、注目セッションの様子をご紹介します。 パート1では、CEOのJennifer Tejadaによる基調講演「DigitalOps Now」と、データサイエンスのシニアディレクターであるMitra Goswamiのセッション「The Power of AIOps」の要約を掲載します。

PagerDuty Summit 2021 基調講演: DigitalOps Now by Jennifer Tejada , CEO of PagerDuty

PagerDutyのCEOであるJennifer Tejadaが、近年のAIOpsのニーズの増大とそれにPagerDutyがどう対応するかを解説 ©PagerDuty

最初の講演「DigitalOps Now」でJenniferは、大手企業がデジタルアクセラレーション、DevOpsトランスフォーメーション、クラウド移行への投資を増やし続けており、75パーセント以上が今後1年半の間にAIOpsに投資すると予想されていると述べました。

ここでゲストとして招待されたNetflixのDelivery Engineering担当ディレクターであるAmy Smidutz氏は自分のチームとNetflixがプラットフォームの信頼性を確保するためにPagerDutyにどう頼ってきたかを共有しました。PagerDutyの機能によりチームとサービスを結びつけることで、インシデントが起きた時に反応するのではなく、予測して計画を立てることができます。

PagerDutyの新しい製品「Service Graph」ではビジネスと技術サービスを担う組織を一望できる ©PagerDuty

続いてJenniferはPagerDutyの新製品である「Service Graph」を紹介しました。これは、フルサービスのオーナーシップを強化するための、ビジネスと技術サービスの関係の全体的なマップです。最も意味のある、または問題のある組織の領域をセグメント化し、これらのプロセスを推進するデータソースを直接リンクして、ビジネスサービスと技術サービスの間に新しい接続を作成します。Jenniferはもう一つ、無駄な時間とエスカレーションを減らし、人の介入を必要とせずに対応を自動化する「Runbook Action」を発表しました。

ここでゲストとして招待されたZoom、Box、Tenable、UiPathの投資家兼取締役でゴールドマン・サックス・グループのKim Hammonds氏は、デジタルトランスフォーメーションがどこまで進んだか、そしてまだどこまで行かなければならないかについて、彼女の考えを共有しました。デジタルトランスフォーメーションを主導するための種を撒くには、第1に稼働時間、可用性、回復力、災害復旧などのすべてが機能する必要があります。そして2番目に重要なのは、世界中の誰もがサイバーセキュリティの脅威に対処しているためのサイバーセキュリティです。3つ目はカスタマーエクスペリエンスです。そして4つ目は何が起こっているかをデータから理解し、データを使って顧客により良いサービスを提供する方法を理解することです。

ゴールドマン・サックス・グループの会長兼CEOであるDavid M. Solomon氏が登壇 ©PagerDuty

ここでさらにスペシャルゲストとして、ゴールドマン・サックス・グループの会長兼CEOであるDavid M. Solomon氏が登壇しました。彼は「PagerDutyのようなツールを使うことで、エンジニアがトラブルシュートに備えて定期的につながっている状況を確実に担保できる」と述べました。彼は、ゴールドマン・サックス・グループが個人を対象にしたビジネスを拡大しているとも述べ、その理由は、「デジタルの世界は個人が白紙の状態で参加することを可能にし、さらに経済的生活を統合するためのツールを提供するからだ」とのことです。彼は、現在定着している消費者金融サービスの世界で巨大なデジタルによる破壊が起きると信じています。彼はまた、消費者がやりたいことは摩擦の少ないデジタルアプリケーションによって、はるかにシームレスな方法で経済的生活を管理することだ、と考えています。

PagerDuty自身のチーフプロダクトオフィサーであるSean Scottが、最新のデジタルオペレーションについて紹介 ©PagerDuty

続いて、PagerDutyのチーフプロダクトオフィサーであるSean Scottが登壇し、組織内で発生する重要で喫緊の作業に現代のデジタルオペレーションが対処している状況を紹介しました。彼は、2019年から2021年の間に重大インシデントが21％増加したことが分かったと述べました。各インシデントの解決には、平均2時間かかり、組織の管理には年間15万ドル以上の費用がかかりました。また、昨年はレスポンダーが以前より不規則に働くことが増え、3分の1以上が24時間体制で問題に対処するために1日2時間余分に働いていることも分かりました。従業員は過労になると仕事を辞める可能性が高くなります。そこで、対策が必要です。

この点での最大のニュースが昨年9月のPagerDutyによるRundeck買収でした。お客様からのフィードバックによると、彼らは労力を減らし、エスカレーションを減らし、運用全体の保守とサポートを民主化する必要がありました。そのため、PagerDutyはそのニーズに投資したのです。RundeckチームとPagerDutyによる自動化が統合されたことで、インシデント解決時間の短縮と開発者の作業の中断を減らせます。お客様の一部はすでにこの価値を理解していると思います。

PagerDutyがRundeckのテクノロジーをマージすることで実現しつつある主なイノベーション ©PagerDuty

6カ月後、彼らのチームは、PagerDutyプラットフォームにこのテクノロジーを統合したことで大きなイノベーションを提供し続けました。

Sean Scottは、Salesforce ServiceCloud用の新しいPagerDutyアプリケーションを提供するSalesforceとの戦略的パートナーシップも発表しました。この新しいパートナーシップにより、最前線のカスタマーサービスエージェントと主要な内部の利害関係者に、Salesforce Service Cloud内で直接に強力なPagerDutyエクスペリエンスを提供します。この機能は、昨年、プロフェッショナルレベルのカスタマーサービスプランナーに新しい価値を追加し、新しいビジネスレベルのカスタマーサービスプランにも統合されます。これは、サポートエンジニアのデスク統合と監視統合に役立つものです。

彼はさらに架空の大手小売業者のビジネスを想定し、PagerDutyの新機能をデモしました。

最後に彼は「PagerDutyはあなたをデジタルの勝者にするパートナーであり、私たちは一緒に完璧な顧客体験を提供することができます」と述べてセッションを結びました。

PagerDuty Summit 2021 基調講演： Power of AIOps

PagerDutyのデータサイエンスのシニアディレクターであるMitra GoswamiがAIOpsの威力について解説 ©PagerDuty

注目のセッション「The Power of AIOps」では、PagerDutyのデータサイエンスのシニアディレクターであるMitra Goswamiが、AIOpsの威力について、その理由と、この分野で最も大きな影響を与える可能性のあるAIの使用例について説明しました。

「AIOpsという言葉は2016年にGartnerが作り出したもので、「ビッグデータと機械学習を組み合わせて、イベント相関、異常検出、因果関係の判断など、IT運用プロセスを自動化するもの」です。この定義は組織によって異なります。Gartner自身は数年後に『AIOpsなしではIT運用の未来はない』と主張しました」。

彼女は次に、PagerDutyがAIOpsをどう強化するかを説明しました。

「この旅を始めたとき、当社はお客様と話し合い、AIOpsの3つの問題点を共有しました。お客様は『まず大事なことはセットアップと開発の容易さだ』と言いました。この点は、PagerDutyは実装が非常に簡単で、すぐに使えます。2番目に大きな問題点は『原因をすばやく発見すること』です。この点についてPagerDutyは新たに3つのソリューションを採用しました。3つ目の問題は、お客様がAIと機械学習のソリューションの信頼度を高めてほしいと考えていることです。（AIという）ブラックボックスで重要な決定を下すことになるので信頼性が高いことを求めています」。

彼女はまた、開発者にとっての3つの問題と、AIOpsソリューションを必要とする理由を共有しました。「最初の問題点は『アラートが殺到すること』です。インシデントが発生すると、開発者は数百または場合によっては数千のアラートを受け取ります。そのため、関連性のある有用な情報を確認することは非常に困難です。2番目は開発者から見て『高レベルの重要なコンテキストが不足している』ことです。十分な時間があるかどうか分からず、狭い部分しか見られない場合、それらはいくつかの重要なコンテキストへの配慮を欠くかもしれません。 3番目は、インシデントを以前の変更に関連付けることができないことです。インシデントの80％が変更イベントによって引き起こされており、現在のすべての情報が右側の同じ場所にないため、インシデントが発生しているときにアクティブな変更と履歴の変更をそれらのインシデントに関連付けることは非常に難しいのです。以上の課題を解決してできるだけ短期間に素因を見つけられるようにするために、AIOpsソリューションが必要です。」

彼女はここでPagerDuty式の「素因分析（RCA）」を共有しました。これは、「勧告、修復、最適化」という3つのアプローチに基づいています。彼女は、「素因の勧告」はこの旅の非常に重要なステップであると述べました。そして目標は、開発者が素因に対処し、できるだけ早くイノベーションに戻ることができるようにすることです。

より高速な素因分析（RCA）により、MTTRが大幅に削減されます ©PagerDuty

彼女は次のように述べています。「効果的な素因分析（RCA）は、開発者の日常生活に直接的な影響を及ぼします。より高速な素因分析により、解決までの時間（MTTR）が短縮され、重大なインシデント解決プロセスの中で起きてほしくない燃え尽き症候群やストレスも回避されます」。

彼女はまた、「RCAをするための3つの方法」についても説明しました。「1つ目はノイズの低減です。PagerDutyのソリューションは、同様のアラートを集約し、関連するインシデントをマージすることに基づいています。そのため、開発者は、何千ものシステムがアラートを開始したときにも波に呑まれることなく、重要で関連性のあることに集中できます。2つ目は、インシデントの分類です。3つ目は変更イベントとインシデントの相関度を示すことです。レスポンダーは潜在的な要因を特定し、無関係な変更を排除できます」。

彼女はまた、Event Intelligenceパッケージとそのデジタル運用計画で利用できる「Intelligent Alert Grouping」機能を紹介しました。チームがシステムの複雑さの増大に合わせて増員できない場合、アラートによる疲労が士気を落とし、何が実行可能かを特定するのを困難にする、という問題に言及しました。この問題を解決するために、PagerDutyのアルゴリズムは、インバウンドのシグナルのパターンとレスポンダーの動作の両方から、アラートをグループ化する方法を学習します。

Incident Alert Groupingは、関連するアラートを単一のインシデントに自動的にグループ化できます ©PagerDuty

彼女が次に言及したのは、新機能の「Incident Outliers」です。これは、レスポンダーが対応に集中している間は、過去の同様のインシデントの経験に関するコンテキストの情報を得る機会が不足することです。解決策は、インシデントをRare、Novel、またはFrequentに自動分類する最適化されたモデルを用意することです。

Incident Outlierは、各インシデントをrare、novel、またはfrequentに分類できる機能です ©PagerDuty

3番目の新機能は、「Change Events & Correlation」です。このソリューションは、お客様の履歴データとアクティブな変更を確認する、最適化されたモデルを提供します。お客様は過去の変更に関するウィンドウを移動することができ、変更をインシデントに関連付けられるようになります。

「Change Events & Correlation」は、お客様がインシデントの原因となる可能性のある変更を特定するのに役立つ機能です ©PagerDuty

最後に、Mitraは、PagerDutyがAIOpsをどう改善しようとしているのかについて言及しました。「PagerDutyの巨大な分析プラットフォームの強みを活用しており、そのアルゴリズムはお客様との信頼関係を構築するために、誤報の50〜60％を即座に削減しています。また、新しい機械学習機能を開発し、お客様と対話できるようにするハイブリッドな方法を導入しています。そうした施策により、多くの力をお客様に還元し、AIOpsソリューションの信頼度を向上させています」。

すべての画像の著作権はPagerDutyにあります。

PagerDuty Summit 2021のサイトでは詳しい資料と動画を公開していますので、こちらをご覧ください。

多くの組織がDevOpsの導入を検討しているのは、リリース速度の向上、開発速度の向上、開発者がイノベーションに集中できる時間を確保できることなどが期待されているからです。しかし、DevOpsの採用は万能薬ではありません。その代わり、DevOpsモデルが奨励するコミュニケーション、コラボレーション、批判しない前提での振り返りの考え方は、問題を解決するだけでなく、プロセスを改善してボトルネックを解決し、より無駄のないシステムを構築するのに役立ちます。

DevOpsを実装する組織にとって最大の課題の1つは、ワークフロー内の既存の問題を特定して削除し、より新しく、よりアジャイルな方法論に道を開くことです。ガートナー社は、システムが目標達成に近づくのを妨げる不便さ、挫折、その他の制限要因を意味する制約を取り除き、真の意味でDevOpsの速度を向上させるために組織が取ることができる6つのステップを以下にまとめました。

ステップ1：プロセスを定義する

プロセスを再構築する際には、DevOpsチームは、初期の構想から最終的な顧客価値に至るまでのワークフローをデザインし、プロセスを定義する必要があります。既存のプロセス内のすべてのステップを文書化することにより、プロセス全体に積極的に貢献していない可能性のある制約領域をより簡単に見つけ出し、改善できます。さらに、サイクルタイム、おおよその時間間隔、ハンドオフ、待機状態など、より価値の高い流れを明確に把握できます。これがすべて整理されたら、チームは最大のプロセス制約を簡単に特定し、プロセス全体を改善するための手順を開始し、プロセス文書化の効果を高めることができます。

ステップ2：最大の制約を特定する

典型的なDevOpsのワークフローでは、アイデアから価値へのプロセスを遅らせる段階が常に存在します。体系的な改善を推進するために、チームは進行を妨げている特定のフェーズを特定し、制約の原因を取り除く必要があります。

最大の制約を特定するには、「誰もが常に何を待っているのか」を問います。これを尋ねることで、チームは効率を高めるために特別な注意が必要なことを特定できます。責任追求をしない建設的な環境でこれを行うと、チームメンバーは発言しやすくなります。最大の制約を特定したら、プロジェクトの進行状況を監視して、ブロック要因が正しく特定されていることを確認します。

ステップ3：制約条件下での無駄を取り除く

制約が特定された場合、最も一般的な行動方針は、より多くのリソース（人、お金、新しいシステムなど）を投入することです。ただし、役に立たない可能性があるリソースを追加するのではなく、無駄な可能性のあるリソースを排除することがより効果的です。

ガートナーによると、クライアントが特定した上位3つの無駄の発生源は次のとおりです。

インシデント:** 新しい製品や機能の開発などの付加価値活動を犠牲にして、インシデント管理に貴重な時間が費やされています。このためのベストプラクティスは、チームメンバーを相互訓練してインシデント管理に習熟することです。将来のインシデントを防止する1つの方法は、責任追求をしない事後検証を実施して、インシデントの根本原因を解明し、将来それを防止することです。 待機:** 人、外部組織、その他のリソースを待つことは、常に課題です。これは、多様なスキルと知識を備えた従業員をトレーニングや雇用して、並行して作業できるようにすることで軽減できます。これにより、他の人の対応を待っている間に、プロジェクトの目標や他の割り当てられた仕事を達成することができるようになります。 人のポテンシャル:** データベースの更新であれ、インシデントのエスカレーションであれ、多くのIT専門家は多くの時間をかけて手動で作業しています。組織はできる限り自動化することでより多くの価値を実現し、人々はより価値の高いタスクに集中できるようになります。

ステップ4：制約を無視しない

制約を無視して新たに発生した問題に集中すると、元の問題に対処できなかったため、作業が遅くなり、将来さらに問題が発生します。たとえば、鎖について考えてみましょう。鎖の中の最も弱い環が強化されていない場合、鎖はある時点でその場所で切れてしまいます。

制約を無視することで、チームは次のようなさまざまな課題を経験することになります。

ミスや欠陥の増加 チームの効率と生産性への悪影響 変化率の高い状況での費用のかかるやり直し

ステップ5：容量を追加する

上記の手順は、スループットを少なくとも30％向上させるのに役立ち、問題を評価する能力と時間を利害関係者に与えるので、迅速な解決策を選択するのではなく、最善の解決策を慎重に検討できます。チームは専門サービスの契約であろうと追加のスタッフの採用であろうと、キャパシティを増やすことができる他の方法を見つけるためにこの時間を取るべきです。

ステップ6：次の最大の制約を見つける

リリース速度を向上させることは簡単なことではなく、プロセスを継続的に改善する必要があります。例えば、あるチームが制約を取り除くことに成功したとしても、ワークフローの別の部分で別の制約が取って代わることがあります。時間が経つにつれて、チームは高い開発スピードを達成するために、プロセスとプラクティスを適応させる必要があります。最後に、顧客のニーズを確実に満たすためには、開発サイクルのデューデリジェンスを実施し、必要に応じて改善する必要があります。

ガートナーの完全なレポートをお読みになりたい方は、「制約を削除してDevOpsのリリース速度を向上させる6つのステップ」をご覧ください。

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

チェスをしたことがある人なら誰でも、望む結果に到達する方法が1つではないことを知っています。1手目の後には400の違った指し手があり、2手目の後には19万7742の、3手目の後には1億2000万の可能性があり、これらはすべて望む同じな結果に向かって進んでいます。

「これがDevOpsと何の関係があるの？」。真っ当な質問です。チェスの試合にアプローチする方法が1つではないのと同じように、DevOpsの変革に取り組む方法も1つではありません。

では、どのようにしてビジネス、既存のプロセス、従業員に大きな影響を与えることなく、より速いデプロイメント、安定性の向上、コラボレーションの向上を約束する変革を行うのでしょうか？

PagerDutyでこれに成功した企業は、5つの重要な戦術に従っていることがわかりました。

避けられない変化を認識する

今日の企業は、顧客の期待の高まりに応えるためにデジタルサービスを変革していかなければなりません。変化はしばしば不快なものであり、多くの組織は変革の取り組みに関してチームからの反発を経験し、場合によってはメンバーの離職を経験することもあります。多くの場合、DevOpsの「自分で構築して自分がオーナーになる」というモットーは、現実には一歩踏み込みすぎていることがあります。

しかし、それでいいのです。私たちは、多くの組織で抵抗や従業員の離職が起こるのを見てきました。しかし、このシナリオでは、短期的な苦痛は長期的な利益に値します。

あなたと一緒に変革の旅に出たいと思っている人には、この変革を視覚化するのを手伝ってあげてください。既存のプロセスを解体して置き換えるのではなく、小規模なプロジェクトから始めることで、新しいアイデアをテストし、リスクを評価し、すぐに成果を得て、将来の「新しい標準」の感覚を得ることができます。目標は、オンコールを変化の障壁にするのではなく、学び、成長する機会にするために、考え方を変えることです。成功の種を蒔き、早期に小さな成功を得ることで、たとえ変化が避けられないとしても、少なくともそれがより身近なものになるようにしましょう。

DevOpsはゼロサムゲームではありません。加算的です。その意図は、チームのアウトプットとスキルの質を継続的に向上させることです。

ビジョンへの賛同を得る

トップの賛同なしでは、開発者チームがより多くのオーナーシップを持つようになれないということを強調することが重要です。経営陣と開発チームの両方が、将来の状態と潜在的な利益について相互に理解していることが重要です。

小さく始めて、隠れたところでいくつかの勝利を得ることは、2つの目的に役立ちます。

アジャイルアプローチが達成可能であり、開発者とOpsチームにとっても同様にうまく機能していることを示します。周囲の期待を得ると、この成功を紹介して新しいプロセスを実現する開発者のサポートを得られるため、経営陣へのアピールが容易になります。 この成功の成果が、開発側が得たデプロイ頻度の向上やコード品質の向上なのか、運用側が得た重大インシデントの減少やインフラの回復力の向上なのかに関わらず、それが経営陣の賛同を得るための要素であり、目に見えるものであることが重要です。結果を定量化することで、組織が新しいプロセスを完全に実装した場合に、経営陣はこれらの新しいプロセスがもたらすプラスの影響をよりよく理解することができます。

開発チームの賛同を得ることは、乗り越えなければならない大きな障害のように思えるかもしれませんが、最終的には彼らのサポートが最も貴重な資産となります。ビジョンに取り組むことで、役割と責任を調整し、DevOps への全体的なアプローチを作成することができます。

インセンティブの変化を理解する

PagerDutyを使用することで開発文化がシフトし、より多くの説明責任を果たすことができるということを、私たちは顧客からよく聞かされます。では、これは正確には何を意味しているのでしょうか？

従来のOpsモデルでは、開発者とOpsチームのインセンティブは一般的にずれています。開発者は迅速なコード出荷を望んでいますが、コードが本番になってからの信頼性の可視性は低くなっています。一方、Opsチームは、たとえ出荷が遅くなったとしても、信頼性と完璧に動くコードを望んでいます。

DevOps のアプローチでは、インセンティブが変わります。開発者は出荷するコードのオーナーなので、夜中に本番環境で起きた問題で起こされるのを避けるために、品質に焦点を当てようとする意欲が高まります。多くの開発者は、このような理由からオンコールを恐れています。しかし、私たちが発見したのは、アジャイル DevOps アーキテクチャではコードの品質が大幅に改善されているため、実際に電話が掛かってくることは予想よりもずっと少ないということです。

オンコールであることは、オーナーシップを促進し、インセンティブを調整する戦術であり、リアルタイムの学習を促し、品質の向上とより迅速なイノベーションを促進します。

DevOpsを自分のものにする

チームがDevOpsトランスフォーメーションをナビゲートするのに役立つ情報は、そこら中に豊富にあります。しかし、最終的には、DevOpsの実装方法はチームや組織に固有のものであり、ツールやプロセスだけでは実現できません。

DevOpsの原則は単なるフレームワークですが、そのフレームワークをどのようにチームに適合させるかによって、DevOpsは組織独自のものとなります。チームを変革プロセスに参加させ続けることが、最終的な成功への最も重要なステップです。例えば、新しいプロセスについてチームからのフィードバックを収集し、組織全体からの提案や新しいアイデアを求めてフォーラムを開いておくことは、チームの一体感を構築し、チームが新しい変化を積極的に受け入れようとするモチベーションを高めるのに役立ちます。

このようにして、より多くの成功を収めることで、より多くの支持と採用を得ることができ、文化的な変化は有機的に起こるようになります。多くの先行投資が必要ですが、早い段階での投資は、将来的に配当金として戻ってきます。

指標を理解する

DevOpsの利点について説得力のある議論をするには、証明が必要です。既存のプロセスを測定して定量化し、以下のような質問をして、比較のためのベースラインを作成することを確認してください。

新しいコードを本番環境にデプロイするのにどのくらいの時間がかかるか？ デプロイの頻度は？ バグのトラブルシューティングにはどのくらいの時間がかかるか？ 四半期ごとのダウンタイムはどのくらいか？

これらは単なる測定基準のサンプルであり、あなたの組織で測定するものは全く異なる可能性があります。重要なのは、DevOps モデルの「後」の状態のパフォーマンスを評価できるように、「前」の状態の指標を十分に把握しておくことです。

理想的には、DevOpsアプローチにより指標がより良い結果を示すことが望ましいです。例えば、アップタイムの向上やデプロイ頻度の向上などです。通常、問題を確認する平均時間（MTTA）と解決する平均時間（MTTR）に注目しますが、重要な指標はこれだけではありません。

これらの測定基準を取得することで、改善すべき領域をより明確に把握することができます。経営の第一人者であるピーター・ドラッカーがかつて言ったように、「測定できないものを改善することはできない」のです。 DevOpsには幅広い解釈があり、あなたの組織にとって意味するものは、別の組織にとっては全く異なる意味を持つことがあります。DevOpsへの移行は、リスク、忍耐、コミットメントを伴う重大な変化であり、それが早すぎたり、組織全体の賛同を得ずに行われた場合には、不安な気持ちになることもあります。しかし、思慮深いアプローチでは、開発者がオンコールしている状態でDevOpsの世界に移行する際に生じる懸念や成長の痛みの多くを軽減することができます。

「アジャイル」はソフトウェア開発でよく使われるバズワードで、一部の組織やチームはアジャイルを装っていますが、実際には全く違うことをしています。私はアジャイルコーチとしてのキャリアの中でそれを何度も見てきました。あるリーダーは、アジャイルの価値観を受け入れていると主張していましたが、エンジニアリングチームを細かくマネジメントし、開発者を操って長時間労働させるための方法としてアジャイルを利用していました。その結果、私たちの業界のエンジニアの中には、アジャイルソフトウェア開発を嫌っている人がいます。それは、エンジニアリング以外の人が彼らを操り、ソフトウェア開発をゲーム化するためにアジャイルソフトウェア開発を利用していると感じているからです。

この記事では、エンジニアがアジャイルやスクラムで経験する3つの「問題点」をお話しします。そして、悪質なアクターや誤解が蔓延している「アジャイルのBS」を切り取って、なぜこれらが全く問題ではないのか、その理由をお話しします。

始める前に、「アジャイルBS」を定義しましょう。

アジャイルBS：アジャイルの原則と価値観に沿っていないチーム、プロジェクト、または組織を指すときに「アジャイル」という用語を使うこと。例えば、アジャイルを装ったウォーターフォールや、実際には機能不全のプロセスを「アジャイル」という言葉で呼ぶこと。

この定義を念頭に置くために、チームまたは組織がアジャイルでないことを示す「アジャイルBS」フラグの例をいくつか示します。

エンジニアリングチームのメンバーがソフトウェアのユーザーと話したり、観察したりしていない

ユーザーからエンジニアリングチームへの継続的なフィードバックが行われていない

実用最小限の製品をできるだけ早く出荷して早期のフィードバックを得るよりも、完全なプロジェクト要件を満たすことを優先する

「アジャイルBS」の詳細については、国防総省のアジャイルBS検出ガイドをご覧ください。アジャイルの原則と価値観は、人々がアジャイルについて時々表現する問題、特にこの記事で指摘されている問題を解決するために作成されたのです。

問題1：アジャイルは、マネージャーが悪意を持って使用するための多数のプロセスとツールを提供するが、エンジニアが前向きの影響力を発揮するためのものはほとんどない

マネージャーがデイリースタンドアップを使用してチームメンバーを細かく管理できるのは事実です。また、マネージャーはスクラムチームのスプリントへの取り組みを「保証」と混同し、エンジニアにスプリントの目標を達成するために長時間労働を強要することがあります（問題2を参照）。しかし、これらはアジャイルソフトウェア開発の問題ではなく、マネージメントの問題です。そして、アジャイルソフトウェア開発では悪いマネージメントを克服することはできません。これは、アジャイルの原則と価値観が達成しようとしていることに対して、間違った期待をかけていることになります。

それでは、組織が適切な管理を実施しているとしましょう。どうすればアジャイルを受け入れることができるでしょうか。組織は、あらゆるレベルでアジャイルの原則と価値観を実践する必要があります。これには、リーダーシップによるアジリティへの取り組みが必要であり、アジャイルコーチのサポートを受けながらアジャイル変革の取り組みを通じて達成できます。PagerDutyの場合は、組織の効率を継続的に改善し、チームの可能性を最大限に引き出すシステム、プロセス、文化を構築、拡張するための専用のアジャイルリーダーシップチームがあります。

この「問題」と密接に結びついているのが、アジャイルはプロセスやツールよりも個人や相互作用を大切にしているということです。それは実際には何を意味するのでしょうか。

プロセスよりも人を大切にする。ソフトウェア開発を管理するのは人であってプロセスやツールではない

プロセスとツールに対する万能型のアプローチを求めるのは、ソフトウェア開発にはうまく機能しない

多様性を許さないプロセスや相互作用を妨げるツールに注意する。ガイダンスとガバナンスを考える

プロセスとツールについて考えるとき、アジャイルではないことを示す「アジャイルBS」フラグは次の通りです。

Doneの定義のようなプロセスの考慮事項が、エンジニアリングチームのトップダウンで定義されている

チームがプロセスソリューションを所有していない（例：スクラム対カンバンの選択）

マネージャーは、エンジニアを細かく管理する方法として、デイリースタンドアップとスプリントゴールを使用している

問題2：アジャイルは意図的に「見積もり」と「コミットメント」を混同し、エンジニアを操って時間外労働をさせる

この問題を2つに分けて考えてみます。

アジャイルは意図的に「見積もり」と「コミットメント」を混同している

チームの取り組みについて話し合う場合、言語は特に重要です。「スプリントへの取り組み」というスクラムの概念を説明するために、スクラムアライアンスとアジャイルアライアンスの共同創設者であるマイク・コーン氏からのアドバイスを紹介します。

「チームのコミットメントが保証と見なされないことが重要です。チームのコミットメントは最善を尽くすことです。私はコミットメントに、おおむね80％の時間を費やしてほしいと思っています。それは彼らが真剣に取り組み、時間の大半を占めるものでなければなりません。これは、チームが提供できるという内容をビジネス側が信頼するために必要なことなのです」。

ここで重要なのは、チームのコミットメントが保証と見なされないことです。チームは最善を尽くし、各イテレーションの終わりに達成したものと目標を比較し、それに応じてプロセスを適応させます。

エンジニアを操って長時間労働をさせる

時間外労働はアジャイルであることとは関係がなく、企業文化と関係があります。とはいえ、アジャイルマニフェストの原則は、アジャイルプロセスは持続可能な開発を促進するということです。これは、エンジニアが時間外労働を一切しなくてもいいということでしょうか？ もちろんそんなことはありません。

エンジニアリングリーダーは、チームとともに適切な労働時間を設定することが重要です。たとえば、エンジニアリングマネージャーは期待を次のように伝えます。

私は誰もが週に40〜50時間働くことを期待します。これは通常、1日8時間の稼働で、月に1週間はオンコールであるということです。年に2回、私はチームに時間外労働をお願いするかもしれません。ただし、どうしても必要な場合を除いて、これをすることはありません。

マネージャーはチームに定期的に時間外労働を要求しているわけではありません。しかし、彼らはこれが毎年数回起こる可能性があるということを理解します。

持続可能な開発に関連して、チームや組織がアジャイルではないことを示す「アジャイルBS」のフラグは以下の通りです。

エンジニアリングチームがスプリントに取り組む場合、これは保証と同義である

スクラムチームは常にスプリントのコミットメントを守る

エンジニアリングチームは、スプリントのコミットメントを守るために、定期的に時間外労働をする

問題3：「コミットメント」というスクラムの概念は、2週間ごとに特定の量の完成した作業を実行することを意味する。これは、ソフトウェア開発について長期的な意思決定を望むエンジニアにとっては過度に敵対的である

スクラムチームが次のスプリントの計画を開始すると、彼らは顧客にとって最高の優先度を持つと決定された項目を引き出します。チームの長期的な決定は、チームの製品ロードマップで事前に計画されています。しかし、製品のロードマップは双方向です。プロダクトオーナーは、チームが解決すべき次に重要な問題を定義します。エンジニアがロードマップにフィードバックを提供し、チームが取り組むべきより価値のあるものがあると感じた場合は、それをプッシュバックするかどうかはチームのエンジニアにかかっています。

エンジニアが製品ロードマップにフィードバック（またはプッシュバック）するのはなぜでしょうか。

オンコールローテーションを行っているチームの場合、最近オンコールが特に騒がしくて苦痛を伴う場合、次のスプリントで最も価値のある作業は、インフラの改善を優先することです

チームが大量の技術的負債を蓄積している場合、問題が大きくなる前に、ロードマップを調整してそれに焦点を合わせる必要がある場合があります

チームがユーザーや利害関係者からフィードバックを受け取り、それによって提供している価値を向上させることができた場合、ロードマップを適応させてこのフィードバックに優先的に対応することが、最も価値のある仕事になるかもしれません

長期的な決定について考えるとき、チームまたは組織がアジャイルではないことを示す「アジャイルBS」のフラグをは次の通りです。

エンジニアリングチームには、プロダクトオーナーから解決すべき問題ではなく解決策が与えられる

エンジニアリングチームが製品ロードマップにフィードバックを提供する仕組みがない

成功とはなにか

組織が真のアジリティを受け入れれば、

エンジニアは、メトリクス（製品エンゲージメント、収益への影響、予測可能性など）、チームヘルスチェック、チームの回顧などのメカニズムを使用して、組織に前向きの影響を与えることができます。

形式の整ったスクラムとカンバンチームは、持続可能なペースで作業しながら、予測可能な価値を顧客に提供するとの信頼を得ます

エンジニアはフィードバックを提供し、製品ロードマップを調整して、常に最も価値のあるものに取り組むことができます。さらに、HackWeekを定期的に開催することで、組織にとって最も重要だと思うことに取り組むことができるようになります

学びを共有する

組織やチームが「アジャイル」を装っているのに、実際には全く違うことをしていることに気がついたことはありますか？ PagerDutyコミュニティでは皆様からのご意見をお待ちしています。

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

2020年7月初め、多くの地域で、サービスプロバイダーのルータの設定ミスによる大規模なインシデントが発生しました。これにより、サービスの障害が連鎖的に発生し、いくつかの有名なSaaSに広範囲の停止と混乱を引き起こしました。

障害が発生したとき、我々PagerDutyのチームはすぐにイベントやインシデントの世界的な急増に気付きました。いくつかの組織内でアラートやインシデントが増加することは珍しくありませんが、今回のケースでは、複数の地域で多数発生していました。これは懸念材料でした。

インシデントの量が異常に増加した場合には、問題に対処するために総力を挙げて対処できるように、予防措置としてメジャーインシデント対応を積極的に展開しています。対応者にタイムリーに通知を行うために、PagerDutyのモバイルアプリを使用して、必要な関係者がどこにいようとも、即座に連絡を取るようにしています。

この特定の問題は、私たち全員がリモートで仕事をしている時に起きたので、私たちはSlackとZoomを使って対応を調整しました。PagerDutyとSlackとのインテグレーションを利用して、インシデント責任者、エキスパート、利害関係者、記録係からなる完全にリモートのチームを編成し、サンフランシスコ、トロント、アトランタで協力して大規模なインシデント対応を3分以内に完了させました。

当社のインシデント責任者が対応を調整し、カスタマーサポートが内部と外部の情報更新を管理し、専門分野のエキスパートが取るべき必要な手順を議論し、記録係が対応の進捗状況とコミュニケーションを文書化しました。

幸いなことに、当社のシステムがインシデントトラフィックの急激な増加に対応できることを迅速に判断し、問題を沈静化することができました。

リモートインシデント対応の重要性

完全に遠隔地での作業環境でのこのような大規模なインシデントは、場所に関係なく、インシデントを迅速に受任し、チームとして対応することの重要性を浮き彫りにしました。PagerDutyでは、分散化した作業と対応の文化は、初日から私たちのプロセスに組み込まれています。実際、当社のインシデント対応ドキュメントを見てみると、対処中に対応者の物理的な接近を必要とするプロトコルは1つも見当たりません。PagerDutyプラットフォームを使えば、どこにいても、インシデントに瞬時に対応し、作業することができます。

また、SlackやZoomのようなコラボレーションツールを利用して、インシデント発生時にリアルタイムでコミュニケーションを取ることもできます。今回のケースでは、PagerDutyとSlackのインテグレーションが、インシデントの状況と関係者への情報更新のための中心的なハブとなりました。Slackで当社のチームメンバーは主要な利害関係者に通知し、役割を割り当て、仮想的な場所に集まり、インシデントに真正面から取り組むことができました。

さらに、インシデントが解決したあとにも、Slackは事後検証のプロセスに役立つため、将来の対応プロセスにも貢献します。記録係はSlackインテグレーションを使用して、対応中に発生したすべてのことを文書化して記録します。誰が対応したのか、誰が対応しなかったのか、なぜエスカレーションしたのかなど、起きたことをすべて見ることができるので便利です。これにより、インシデントの全体像を把握して理解することができ、将来インシデントが発生した場合でも、より迅速に対応して解決するためのプロセスを改善することができるようになります。

私たちの分散型エンジニアリングの文化は、PagerDutyが何があってもお客様のために常にオンになっていることを保証することを可能にしています。PagerDuty をコラボレーションツールや明確に定義されたプラクティスと共に真実の単一ソースとして使用することで、事実上どこからでもインシデントに効果的に対応することができます。多くの場合、オフィス内のオーケストレーションから仮想的な対応に移行することは困難だと思うでしょうが、PagerDuty を使用することで、ほとんどの場合、通常通りの業務を行うことができます。

チームがどのように PagerDuty を使ってリモートインシデントレスポンスを行うかについては、分散型コミュニケーションに関するこのブログを参照してください。

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

COVID-19の急速な感染拡大に伴い、多くの企業が完全なリモートワークに移行しています。顧客、ベンダー、パートナーがオンラインであることは、企業にとってこれまで以上に重要です。PagerDutyでは、従業員、その家族、そして私たちが属するより広い地域社会の健康と安全に主眼を置いていますが、他の最優先事項の1つは、特にこのような困難な時期には、顧客へのコミットメントです。

ご存知の方もいらっしゃるかもしれませんが、現在、全世界の従業員がリモートで仕事をしており、出張を停止しています。これが今のところの新しい常識かもしれませんが、リモートワークは当社にとって新しいことではなく、当社は最初からこのようなシナリオを想定して作られています。

当社の従業員は世界中に分散しており、分散したリモート環境での当社プラットフォームの開発と運用に慣れています。つまり、この事態にもかかわらず、お客様のデジタルビジネスが24時間365日稼働するように、PagerDutyを稼働させ続けることができます。

お客様へのコミットメント

デジタル運用管理のマーケットリーダーとして、当社はこの分野で最大規模、最も信頼性が高く、回復力のあるプラットフォームを提供しています。当社のお客様からは、昼夜を問わず、いつでもシステムに問題が発生したときに、リアルタイムで適切な対応を行うための支援を受けることができるとの信頼をいただいています。では、それをどうやって実現しているのでしょうか。

当社のチームメンバーが分散しているのと同様に、当社のプラットフォームアーキテクチャも分散しています。当社は、複数の物理的なデータセンターからなる地理的に独立したクラウドリージョンに分散して配置されています。当社のアーキテクチャは、お客様からのトラフィックの急増を想定しています。例えば、旅行業界やEコマース業界とは異なり、予測可能なトラフィックパターンには季節性がありません。1万2700人以上のお客様からの予期せぬトラフィック量の増加に最善の準備をするために、必要に応じて動的にスケーリングできるように準備しています。

当社は、「失敗の金曜日」シリーズでカオスエンジニアリングを実践し、お客様のために信頼性と回復力を維持する能力を実践していることで知られています。時間をかけて障害シナリオのシミュレーションに取り組んできた結果、現在では「Failure Anydays」（失敗はいつでも起こる）を実施しています。そう、当社のチームの1つまたは複数が、お客様へのサービス提供の質に影響を与える可能性のある問題を迅速に特定して軽減するために、制御された障害テストをいつでも実施しているのです。2013年以来、当社のプロセスと実践をお客様と共有してきたので、失敗からの学習への投資は新しいものではありません。私たちは、プラットフォームアーキテクチャ、ベストプラクティス、そしてお客様への取り組みを維持するために懸命に努力し続けるチームに適した要素を備えていると確信しています。

ダウンタイムといえば、PagerDutyでは予定されたダウンタイムはありません。あなたの時計は止まることはありません。当社のサービスレベルアグリーメント（SLA）は、お客様に提供する可用性とパフォーマンスの両方をカバーします。メンテナンスのために計画的なダウンタイムを実施することはありません。問題が発生した場合、設定された配信期間内にお客様が通知を受け取ることができるように、プラットフォーム製品に冗長性を持たせています。

多くの企業がリモートワークへのシフトを行おうとしているか、または行っています。そして今、これまで以上にデジタルビジネスが稼働し続けることが不可欠です。PagerDutyはそれを助けるためにここにいます。

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

進行中のパンデミックとその結果としての景気後退は、市場の状況を劇的に変化させました。その結果、エンジニアチームは、完全リモート環境に突然移行することによる影響を軽減するために、財務リスクを最小限に抑え、コストを削減する必要性をますます感じることになりました。

一部の人にとっては、ビジネスの継続性を維持するための苦労がありました。つまり、皆が自宅で仕事をしているときもビジネスの物理コンポーネントは実行し続けています。他の人にとっては、社内外の顧客に対するデジタルサービスへの依存度を強調することが課題の中心となっています。最近の調査で判明したように、すべての組織や部門が同じように影響を受けるわけではありません。

このような環境では、会社の種類に関係なく、ビジネス目標はコストを削減し、収益を保護し、デジタルトランスフォーメーションを加速するという3つのニーズに集約されます。困難なように思われるかもしれませんが、楽観的な見方があります。適切なテクノロジーソリューションを導入することで、組織は予算を拡大し、プロセスをより効率的にし、シームレスなデジタル体験で顧客を満足させることができます。

PagerDutyは、お客様の課題解決を支援するために、対応チームの効率を向上させ、デジタルファーストの世界でお客様との関係を保護できるようにする最新のリリースを発表しました。

積極的なインシデント対応

デジタルサービスへの信じられないほどのアクセスに直面している場合でも、それがまもなく予定されている場合でも、あらゆる組織が積極的にインシデント対応することが重要であると考えています。積極的になるとは、技術スタッフとビジネススタッフの両方にデジタルサービスを活用するためのツールを提供し、問題が発生しても無知の状態から始まらないようにすることです。デジタルの世界では、秒単位の時間が重要であり、重要な個人がその場でインフラや対応手順について学習することはできません。今こそ行動の時です。そのため、デジタルの準備が非常に重要です。

積極的なインシデント対応に関する新機能とアップデートされた機能により、すべてのチームにデジタルサービスとその依存関係、ハイパーケアを提供し、収益に影響する危機になる前に問題を回避するために必要な運用指標を提供します。

サービスプロファイルを使用すると、エンジニアリングマネージャーと対応者はランブック、抑制されたアラート、過去のインシデント、通信チャネルなど、サービスに関する関連情報を整理、検索することができます。

サービスダッシュボードは、運用メトリックとKPIを分析して、組織間の調整を行い、より良いビジネス成果を実現します。

サービスの依存関係（アーリーアクセス可能）は、ユーザーがPagerDutyのサービス間の関係を理解し、問題をより迅速に特定、トリアージ、修正し、チーム全体でより効果的にコラボレーションするのに役立ちます。

可視性コンソール（アーリーアクセス可能）は、サービスパフォーマンスのリアルタイムの統合ビューを提供し、UIが一新された高度なフィルタリングとカスタマイズ可能なレイアウトが含まれるようになりました。このツールは、チームがインシデント対応に積極的なアプローチを取り、ハイパーケアの瞬間に顧客のニーズを満たすのに必要なコンテキストを提供します。

インテリジェントな対応と自動化

チームがまだハンドブックを調べて問題への対応方法を決定している、または手動で過去のインシデントを調べて何が関連しているのかを確認していては、時間やリソースを最大限に活用できません。チームの効率を改善して収益を保護する最も簡単な方法の1つは、価値の低いアクティビティや労力を自動化して削減し、貴重なリソースを他の場所に再展開できるようにすることです。

インテリジェントな対応と自動化のための最新のソリューションは、何が最も重要であるかに焦点を当てたリアルタイム情報を提供します。また、作業の重複を減らし、マシンが手動タスクを自動化できるようにすることで、対応者の負担を軽減します。自動化でより少ないリソースでより多くのことを実行できるようになり、ビジネスの回復力が向上し、収益が保護されます。

イベントインテリジェンスの一部であるモバイルインテリジェントトリアージは、チームによる作業の重複を防ぎます。機械学習は、問題とコラボレーションの履歴レコードを利用し、関連するインシデントをマージすることで、誰が責任を持ち、問題に取り組んでいるかをより正確に特定できるようにします。

インシデントの再開**（アーリーアクセス可能）は、対応者の柔軟性が向上し、インシデントの重複が減少し、問題が予期せずに再発したときに、より迅速な再動員が可能になります。

Rundeck、Ayehu、Pliant、Amazon EventBridgeとのインテグレーションは、ワークフローマニュアル自動化し、レスポンスプレイの一部として対応チーム内のコミュニケーションを改善することができます。

リアルタイムビジネスオーケストレーション

今日、テクノロジーチームは、デジタルサービスに対する顧客の需要の劇的な増加だけでなく、完全に分散されたチーム間でのインシデントコミュニケーションの管理にも取り組んでいます。一方、顧客は依然として完璧な体験を期待しています。インシデントが発生した場合、ビジネス面での対応と技術的な対応を緊密に統合することが重要であると考えています。これは、既存の技術プロセスの自然な拡張である必要があり、手動のプロセスを伴うことや、追加のツールをセットアップをしなくてもいいことが必要です。

当社の最新の機能強化は、サイロを分解し、すべてのチームに適切なレベルの情報を提供することで、重要な瞬間に作業とコミュニケーションをより効率的に行えるようにし、最終的にはより良い顧客体験につながります。

モバイルステータスダッシュボードは、ビジネスの利害関係者に、ビジネスサービスに関する情報更新への外出先でのアクセスを提供します。

ステータス更新ブランディングはブランド化された通知により、通知受信者のエンゲージメントと信頼を高めます。

Salesforceとのインテグレーションにより、チームはワークフローをカスタマイズして適切なリソースを適切なタイミングで動員できるようになるため、デジタルサービスのカスタマーサポートにおけるクラス最高の統一フロントが実現します。標準のSalesforceオブジェクトと統合して、PagerDutyで対応するアクションをトリガーします。

オンコールスケジューリングタイムライン（制限付きアクセス）および* ハンドオフ通知の拡張機能*により、オンコールシフトとチームメンバーが担当するサービスの可視性が向上し、競合、ワークロード、シフトのオーバーライドを管理する簡単な方法がユーザーに提供されます。

Microsoft Teamsとのインテグレーションにより、対応者はチーム内の重要なインシデントの詳細を表示できます。また、新しいインシデントを受任、解決、トリガーするだけでなく、インシデントのメモをすべて1つのインターフェイスから追加できます。

新しいインテグレーションとAPI

詳細が重要であることはわかっており、小さな改善や拡張されたインテグレーションでも、停止に迅速に対応し、最高のパフォーマンスで運用するチームの能力にすべての違いをもたらすことができます。そのため、私たちはSalesforce、Microsoft Teams、Jiraなどのツールとの統合を強化し、テクノロジースタック全体の可視性を最大化して、すでに知っているツールやお気に入りのツールから作業できるようにするために懸命に取り組んできました。さらに、ビジネスサービスとレスポンスプレイAPIにより、主要なデータと機能にアクセスできます。

最新のリリースの詳細については、このリンクをご覧ください。

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

良くも悪くも、私たちの社会はは効率化に取りつかれています。オンラインバンキングやEコマースアプリからスマートIoTデバイスに至るまで、私たちの生活の隅々にその痕跡があります。しかし、私たちは個人生活のほぼすべての面で自動化を使用しているにもかかわらず、PagerDutyとDimensional Researchが実施した共同研究では、90%の企業が問題解決のための自動化をほとんど、あるいは全く行っていないことがわかりました。なぜでしょうか。私たちは簡単なことをより簡単にするため、私たちの生活の中で毎日自動化を利用しているのに、なぜ仕事でもそれを利用していないのでしょうか。

頑張らずに賢く働く

社内では「技術の達人」と呼ばれているにもかかわらず、仕事を終わらせるために面倒な手動のプロセスに頼っているIT担当者の多さに驚くことでしょう。

多くのITチームは、時間やリソースを最大限に活用できていません。その代わりに、問題への対応方法を決定するためにハンドブックに目を通したり、過去のインシデントを手作業で調べて関連性があるかどうかを確認したりしています。しかし、チームの効率を向上させ、収益を守るための最も簡単な方法の1つは、インテリジェントな対応と自動化であり、繰り返し可能な手順を自動化することで、貴重なリソースを他の場所に再配分することができます。

2020年春に発表された最新の機能強化では、インテリジェント対応と自動化に3つの方法でアプローチしています。（1）人とプロセスの調整、（2）対応チームが必要なときに適切なコンテキストと情報を提供する、（3）使いやすい自動化機能を提供することで、問題を迅速に診断して解決できるようにする。これがどのように機能するかを詳しく見てみましょう。

新機能の詳細 インテリジェントトリアージ

PagerDutyイベントインテリジェンスの一部として、モバイルで利用できるようになったインテリジェントトリアージは、チーム作業の重複を防ぐことができます。これにより、複数のチームに影響を与えるインシデントについて、何が本当の原因となっているかを判別するために、Related Insidents機能を使用することができます。Related Insidentsは、イベントインテリジェンスの機械学習機能をノイズ削減の域を超えて拡張し、サービス全体にわたってリアルタイムのコンテキストに基づいた洞察を対応者に提供します。

目下のインシデントに関連している可能性のある他のサービスで同時発生しているインシデントを調査することで、対応者は影響の幅と範囲をより深く理解し、重複したコミュニケーションを回避し、問題解決のためにチームがお互いを邪魔しないようにすることができます。インテリジェントトリアージは、機械学習を利用して以下のことを可能にします。

ビジネス全体で今現在何が起こっているかを見る 問題がローカルなものなのか、他に影響を与えるものなのかを理解する 適切なチームメイトを募り、協力して問題を解決する MTTRの改善

インシデントの再開

時には、インシデントが実際には解決されていないにもかかわらず、対応中に誤ってインシデントをクローズしてしまうことがあります。あるいは、インシデントが終了したと思って大規模なインシデントを解決済みにしたにもかかわらず、その後すぐにモニタリングやカスタマーサポートなどの他のチャネルを通じて、同じ原因に起因する進行中の症状に気づくこともあります。

大丈夫です、間違いは起こります。私たちは皆人間です。だからこそ、PagerDuty は新しいアラートをトリガーすることなく、応答者がインシデントを再開することができる新機能（アーリーアクセス可能）をリリースしました。このシンプルでありながら重要なアクションは、対応者の柔軟性を高め、インシデントの重複を減らし、重大なインシデントの症状が再発していることが判明した場合に、対応チームの再動員をより速く、より簡単にします。また、ServiceNowのような隣接するツールを同時再開することができます。

ランブックオートメーションのインテグレーション

もう1つの方法は、運用上の「ランブック」で取得した手動または部分的に自動化された手順をすべて自動化して、自動化されたインテリジェントなインシデント対応プロセスに接続することです。Amazon EventBridgeとの既存のインテグレーションに加え、ランブック自動化のために新しくリリースされたRundeck、Ayehu、およびPliantとのインテグレーションは、Amazon EventBridgeとの既存のインテグレーションに加えて、手動のITレスポンスプレイワークフローを自動化し、対応チーム内のコミュニケーションと解決スピードを向上させることができます。

Rundeck 統合のランブック自動化機能を使ったインシデント対応の例を見てみましょう。

「Eコマースビジネスのピーク時にサーバがダウンして、顧客がチェックアウトしたり、カートの中の商品を購入したりすることができなくなりました。PagerDutyはインシデントが発生したことを適切な人に警告しました」

さて、どうしますか。どのようにして対応者がインシデントを診断し、解決するための迅速な行動を取ることができるでしょうか。もし彼らが同僚や他のチームにエスカレーションしなければならない場合、あなたは時間をロスすることになります。wikiを閲覧したり、マニュアルのランブックを調べたりする場合も時間の無駄になります。

そうではなく、対応者が行動を起こすために必要な自動化されたオペレーション手順に安全にセルフサービスでアクセスできるようにしましょう。Rundeckによるランブックの自動化により、対応者の誰もが専門家と同じように診断や修理の手順を安全に実行できるようになり、インシデント時間をより短くし、より少ないエスカレーションで済むようになります。

RundeckとPagerDutyのインテグレーションにより、以下のことが可能になります。

PagerDutyのインシデントの開始時に自動的にRundeckジョブをトリガーする。例えば、最初の対応者がPagerDutyにログインする前に診断を開始したり、修理アクションを試したりする PagerDutyのWebやモバイルUIでカスタムアクションを使って、インシデント発生時にRundeckジョブをトリガーする Rundeckジョブが自動的にPagerDutyのインシデントノート／タイムラインを更新する Rundeckジョブが失敗した場合にPagerDutyインシデントをトリガーする

このシナリオでは、ランブックの自動化を利用することで、Eコマースビジネスはリソースをより効率的に展開し、MTTRを改善し、停止の結果として失われる収益を保護することができます。

インテリジェントな対応と自動化を実現

これらの新機能は作業の重複を減らし、機械による手作業の自動化を可能にすることで対応者の負担を軽減します。PagerDutyはチームに少ない労力でより多くのことを行う能力を与えることで、企業の回復力を向上させ、顧客との関係性と獲得した収益を保護することを支援します。

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