Blog
ブログ

PagerDutyでは、お客様を最優先にすることを約束します - これは会社のコアバリューです。私たちの製品は素晴らしい価値を提供し、優れたサービスを提供し、そして私たちとビジネスをすることをシンプルにする必要があります。

2022年冬のG2 Grid for AIOps Platforms Relationship Indexは、これらの価値を紹介し、PagerDutyをAIOps分野のリーディングプレーヤーとして取り上げています。

AIOpsの展望が進化し続ける中、PagerDutyは、よりインテリジェントで自動化されたオペレーションを実現するために、お客様の成功を促進することに力を入れています。ドメインにとらわれないアプローチで、戦略的な投資に基づいて構築することで、「壊して取り替える」という考え方ではなく、組織が観察可能性やその他の監視ツールで成し遂げてきた成功をさらに後押ししています。PagerDutyは、組織内に既にある戦略遂行能力を基に構築することに重点を置いており、ワークフローと連携して大きな価値を提供するために、再調整やわずかな改善点を探すことはしません。

私たちの顧客は、数秒という短い時間で適切な情報を適切な人に届けるためのサービスとしてPagerDutyを信頼しています。AIOps機能の加速は、この約束の実現を加速させ続けてきました。

昨年のレポート以降、AIOpsの領域で導入した新機能は以下のとおりです。

自動化とオーケストレーションのためのRundeckの機能を追加し、チームが安全にセルフサービスオペレーションを実行可能に コンテキストと状況認識のため、数少ないシステムからの変更イベントを、事実上あらゆる構成または展開ツールに統合 過去のインシデントと変更イベントのビューを統合し、モバイル機能を拡張 イベントのスループットを40倍に向上 イベントオーケストレーションの導入により、ルール管理を簡素化し、複雑なネスト化されたロジックを比較的容易に作成可能に イベントやインシデントがサービスに与える影響を理解しやすくするため、グラフィカルなサービスマッピングを開始 考えられる原因（Probable Cause）を示唆し、問題解決の出発点としてチームを特定のサービスに誘導し、MTTRを短縮

PagerDutyは、AIOpsの約束を実現するために、Actionable Intelligenceの推進に注力しています。PagerDutyのAIOpsソリューションにより、チームは数年にわたる実装を待つ必要はなく、PagerDutyは今すぐペインポイントの解決を応援することができます。

私たちのソリューションは、データサイエンティストを必要とせず、簡単に始められ、価値創造までの時間が短いため、チームがより良い、データ主導の意思決定を行えるよう支援します。** サービス、レスポンダー、インシデント、監視などに関する深い洞察を提供することで、チームはプラットフォームの専門家でなくても、より良い運用上の意思決定ができるようになります。私たちが独自のデータセットを使って開発したMLとデータサイエンスのアルゴリズムは、ノイズの低減、根本原因の迅速な分析、自動化を可能にし、チームはすぐにでもその恩恵を受けることができます。 プラットフォームを誰でも使いやすくし、分散チームやハイブリッド運用モデルに合わせた分散構成で、セルフサービスオペレーションを実現します。** PagerDutyのAIOpsは、中央のITチームには診断と自動修復を実行するための簡単なボタンを、開発チームには根本原因のトラブルシューティングを行うための合理的な方法を提供し、600以上のインテグレーションパートナーによってあらゆる技術スタックにシームレスに適合します。 インシデント対応のライフサイクルを通じて、自動化された次善の策を提案します。** イベントオーケストレーションでは、より少ないルールでよりスマートにネストされたルールを提供することで手動処理を削減し、インシデントの詳細と同時に考えられる原因や関連する変更を表示し、Rundeckを活用してエスカレーションの回数を減らし、インシデント解決を自動化します。

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

PagerDutyは、ラウンドロビンスケジューリングを発表できることをうれしく思います。ラウンドロビンスケジューリングは、チームメンバー間でオンコールシフトの責任を公平に分配することを可能にします。自動的に異なるユーザーまたはエスカレーションレベルのオンコールスケジュールに新しいインシデントを割り当てることで、チームが可能な限り効率的にインシデントを解決することを保証します。また、複数のユーザーで作業負荷のバランスをとることで、燃え尽き症候群のリスクも軽減されます。

同一サービスで発生した複数のインシデントのシームレスな解決

あるサービスでインシデントが発生すると、１人のレスポンダーがアラートを受信し、トリアージを開始します。インシデントが１つだけであれば対処可能です。しかし、アラートの量が多いサービスでは、レスポンダーが複数のインシデントに対応するために複数の方向に引きずられるため、インシデント対応中に混乱が生じる可能性があります。あるサービスで、30分以内に対処しなければならない５つの異なるアラートが同時に発生したとします。１人のオンコールエンジニアがその全てに対応することはできません。そこで、ラウンドロビンスケジューリングが役に立ちます。

ラウンドロビンスケジューリングでは、新しいエスカレーションポリシーを作成するか、既存のエスカレーションポリシーを編集して、”Users are assigned via round robin on the escalation level”（エスカレーションレベルではユーザーはラウンドロビンで割り当てられる）というボックスをチェックすれば、ユーザーは簡単にローテーションを設定することができます。

上記の例のような場合、ラウンドロビンの各担当者は、５つのアラートのうち１つをトリアージするよう割り当てられることになります。これにより、インシデント対応が効率化され、ダウンタイムが短縮され、顧客体験が向上します。

ラウンドロビンスケジューリングなし	ラウンドロビンスケジューリングあり
全てのインシデントが１人の担当者に割り当てられ、残りのメンバーはスケジュールにないためアイドル状態	インシデントをチーム内で公平に割り当て、それぞれが分担する
１人のレスポンダーが複数のアラートを処理しようとするため、MTTAとMTTRが増加する	各レスポンダーがアラートに最大の注意を払うことができるため、MTTAとMTTRが減少する
レスポンダーに余裕がなくなると、エスカレーションを余儀なくされる	入ってきた問題にすぐに対応できる別のレスポンダーがいるため、エスカレーションの頻度が少ない

さらに、ローテーションの対象者を特定するのも簡単です。ユーザーがエスカレーションポリシーを表示すると、ラウンドロビンのローテーションで誰が次になるかが緑の矢印で示されるので、問題が発生したときに誰がアラートを受けるかがあらかじめ分かるのです。

燃え尽き症候群を減らすために、仕事を分散し、必要に応じてエスカレーションする

大量の依頼を受けるオンコールチームでは、燃え尽き症候群が常に念頭にあります。 一人のチームメイトが複数の問題を同時に処理し、他のチームメイトが待機していることもあります。このようなオンコールシフトは、注意力不足、応答速度の低下、認知能力の低下などを引き起こす可能性があります。たとえオンコールシフトが月に一度しか発生しないとしても、それは離職率を高めるのに十分な圧力となり得ます。

ラウンドロビンスケジューリングは、各新規インシデントが、マネージャーもユーザーも含めて順次割り当てられるようにし、チームが責任のバランスをより良くとれるようにします。これは、エスカレーションの上位レベルにいるディレクターなど、優先順位の高いインシデント中にステップインする必要があるかもしれない人も含めて、オンコールスケジュールにいる全ての人にとって公正かつ予測可能なローテーションを維持するのに役立ちます。

ラウンドロビンスケジューリングを使用する

あなたのチームでオンコールボリュームを管理し、インシデント対応を合理化し、公平に作業負荷を分散する方法をお探しですか。ラウンドロビンスケジューリングは、BusinessとDigital Operationsの全てのプランで利用できるようになりました。現在ご利用中のお客様で、この機能へのアクセスを解除するためのアップグレードをご希望の場合は、PagerDutyアカウントチームまでご連絡ください。まだご利用でない方は、この機能を14日間無料でお試しいただけます。

ラウンドロビンスケジューリングの詳細については、こちらのサポートドキュメントをご覧いただくか、こちらのYouTubeショートムービーをご覧ください。

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

今日、ほとんどのサポート組織は、何らかの形で従来の階層型サポートモデルを採用しています。これは、エスカレーションと顧客の引き継ぎのプロセスに基づいているものです。このモデルでは、顧客の問題は、サポート階層の複数のレベルを介してエスカレーションされ、３つの階層が一般的なワークフローとなります。

この典型的な３層構造のサポートシステムの例では、Tier 1は入ってくる顧客の問題を受ける最初の防御線であり、一般的なテクニカルサポートを提供します。Tier 1サポートで解決できない問題は、より深い技術的知識とサポートスキルを持つTier 2にエスカレーションされます。このレベルでも解決できない場合は、対象となるアプリケーションの専門家であるTier 3のスペシャリストにエスカレーションされます。

このモデルは、それほど深刻でなく繰り返し発生する問題には有効ですが、今日の常時接続のデジタル世界において、優先度が高く重要なインシデントに対処する場合には、全く適していません。おそらく、今日のカスタマーサービス組織で広く見られるこの従来のサポートモデルの考え方を疑うべき時が来ているのでしょう。

このモデルは、エスカレーションと顧客の引き継ぎのプロセスに基づいているため、以下のようないくつかの欠点があることは驚くことではありません。

解決までの時間、First Reply Timeが長い。** 全チケットが同じトリアージのキューに従うため、最終的に適切な担当者にたどり着くまでは、その問題に対処する能力がないエージェントのもとで時間を浪費することになります。このモデルでは、適切な専門家にたどり着くまでに障壁があり、問題についての重要な文脈や情報が途中で失われることが多く、不必要な遅延が発生します。 長いバックログ項目。** Tier 1レベルで解決できないお客様の問題は、他のサポート層への待ち行列に入ります。このケースは、リアルタイムでアクティブに作業されている状態から、バックログのアイテムになるのです アカウンタビリティーの低下。** 階層化モデルは、エスカレーションと顧客対応のプロセスに基づいています。最前線のスタッフが問題を専門家にエスカレーションすることを求められると、アカウンタビリティーが低下し、インシデントからエンドツーエンドで学ぶ機会も減少します。 顧客にネガティブな体験をさせる。** 複数のサポート担当者に問いを繰り返さなければならなかった経験のある人なら誰でも、このことが顧客満足度にマイナスの影響を与えると理解してるはずです。

これは、サポート組織は階層型サポートモデルを廃止すべきである、と言っているのではありません。階層型サポートは、それほど深刻でない問題や単発の質問に対応するには非常に効果的です。しかし、重要で緊急性の高いインシデントになると、階層型モデル特有の非効率性が、最終的に顧客離れにつながる負の顧客体験をもたらす可能性があります。

IIntelligent Swarming℠は、オーソドックスな階層型サポートに代わるフレームワークを提供します。このフレームワークでは、キュー内の作業よりもリアルタイムの作業、サイロ内の作業よりもコラボレーション、一方的なエスカレーションよりもケースのオーナーシップを優先します。

インテリジェントスウォーミングモデルでは、チケットを受け取ったカスタマーサービス担当者が、その案件を最後まで担当します。サポートに階層はなく、お客様の引き継ぎもありません。チケットの所有者であるエージェントが解決できない場合、そのエージェントは即座に問題の「スウォーム」化を行う専門家チームを引き込みます。このような的を絞ったアプローチはインテリジェントスウォーミングと呼ばれ、適切な人が適切なタイミングで動員され、協調した対応を行います。これは、多くの人が対応策に参加しても、必ずしも問題解決に適した専門家であるとは限らないという、インシデントに対する協調性のないスウォーミングとは対照的なものです。インテリジェントスウォーミングのフレームワークでは、ケースオーナーが専門家チームと情報を共有し、解決に向けて協力し合います。

このモデルには、いくつかの利点があります。

この理論を実践するためには、カスタマーサービス担当者が適切な情報にアクセスし、専門家と協働できるようにする必要があります。つまり、組織全体からリアルタイムのサービス障害データを提供してもらうことです。また、運用チームとの双方向のコミュニケーションを可能にする双方向通信チャネルを確立することも必要です。また、機械学習機能を使って、顧客に影響を与える前にインシデントを特定することも可能です。

PagerDutyでは、サポートエージェントがインシデントの履歴コンテキストを可視化し、テクニカルリソースからの監視データを提供することで、問題の全体像を把握し、正しい解決策を特定できます。エージェントがチケットで助けを必要とする時は、PagerDutyの一連の機能を使って迅速に追加支援を引き出すことで、スウォーミングモデルをさまざまな方法で実現できます。

エージェントは、インシデントにレスポンダーを追加することで（「Add responders」という分かりやすい名前の機能があります）、PagerDutyで迅速にスウォームリクエストを始められます。これにより、組織全体から必要な専門家が直ちにループに入れられ、コラボレーションのための会議ブリッジを設定するオプションも用意されています。追加されたレスポンダーは、緊急性の高い通知ルールで通知され、重要な問題を見逃すことがないようにします。

PagerDutyのエージェントは、レスポンスプレイ（ボタンをクリックするだけでインシデントに対して実行できる定義済みアクションのセット）を利用して、スウォームの開始に関連する定番のワークフローを自動化することもできます。これらの定義済みアクションには、対応者の追加、カンファレンスブリッジの設定、関係者のインシデントへのサブスクライブ、ステータスアップデートの公開などが含まれます。レスポンスプレイは、特定のサービスに結びついたインシデントに対して自動的に実行されたり、PagerDutyを使っている誰もが手動で開始したりでき、実行されるアクションが問題の規模に適していることを確認できます。

最後に、PagerDutyはZendeskなどのチケットツールやSlackなどのChatOpsツールとネイティブに統合されているため、エンジニアリングチームと簡単に双方向のコミュニケーションが可能です。また、エージェントが使っているツールからPagerDutyのインシデントをトリガーできるため、コンテキストスイッチの必要がなく、適切なチームや専門家にすぐに接続して問題を解決できます。PagerDutyをオールインワンの対応オーケストレーションおよびコラボレーションツールとして使用することで、チームは簡単に問題をスウォーミングし、顧客とエージェントの両方にとってよりシンプルで合理的なエクスペリエンスを実現できます。

スウォーミングや階層型プラクティスを使用するかどうかにかかわらず、今日、あらゆる顧客問題をサポートするためのよく知られたアプローチが存在します。適切なスウォーミングの手法を事前に構築しておけば、適切なタイミングで適切な専門知識を自動的に活用できます。また、即時対応が必要でない重要度の低い問題については、階層化されたアプローチを自動化（自動エスカレーションポリシーやオンコール通知など）することです。

デジタルイノベーションとユーザーエクスペリエンスによって定義されるようになるパンデミック後の世界では、カスタマーサービス機能を強化する新しい方法を検討する時期が来ています。

Intelligent Swarming℠は、サービスイノベーションコンソーシアム™のサービスマークです。

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

PagerDutyのOperation Cloudは、ITチームからカスタマーサービス、人事、マーケティング、営業など、ビジネス全体にわたる重要な業務で組織を支援します。PagerDutyを使用することで、組織は正確な優先順位付け、効率的な対応、運用上のオーバーヘッドの削減が可能になります。

今回のブログでは、新しい「ビジネス向けソリューションガイド」を使って、IT部門だけでなく、あらゆる部門の重要業務にPagerDutyを活用する事例をご紹介します。

人事部が社員と候補者の体験を向上させる

人事部は、現在働いている人、退職する人、入社を希望する人、全ての人に配慮する責任があります。人事部にとって重要な仕事は、賃金や税金の情報が常に最新であることの確認、従業員の迅速なオフボーディング、候補者の面接プロセスにおける直前の変更の調整など、多岐にわたります。このような重要な作業は、従業員や候補者の経験を確保するための鍵です。このようなワークフローに支障が生じると、優秀な候補者を逃したり、人材が減少したり、あるいはコンプライアンス上の問題が生じたりする可能性があります。

PagerDutyは、人事チームが刻々と変化する組織の状況を把握し、ワークフローが適切な担当者によって迅速に実行されるよう支援します。さらに、これらのワークフローを最適化することで、運用上のオーバーヘッドを削減し、何度も「リマインダー」メールを送信することに別れを告げることができます。

例えば、人事部門がオフボーディングを担当しているとします。オフボーディングのリクエストが来たとき、誰かの受信トレイに埋もれさせるわけにはいきません。オフボーディングのプロセスに遅れが生じると、リスクが高まるからです。そこで、オフボーディングリクエストごとに通知を設定し、すぐに適切な担当者に転送できるようにします。さらに、人事部がオフボーディングを完了した時点で、その社員のアカウントを削除するITチームに通知を再割り当てすることができます。

ITチームは、これが重要な作業であることを理解し、対応します。チケットを送信して、キューに入れられたワークフローで解決されるのを待つよりも、迅速に対応することができるのです。人事チームは、ITチームが作業している間に通知を見ることができ、フォローアップやメール送信の必要なく、プロセスがエンドツーエンドで完了したことを確認できます。これにより、オフボーディングワークフローの継続性が確保され、人事部門にとって価値の低い手作業が削減されます。最も重要なことは、タイムリーに従業員を退職させられないことから生じるリスクを軽減することです。

営業がお客様の取引サイクルを促進する

営業チームは会社の顔であり、収益を上げる重要な原動力です。営業は、対応力があり、有能で、親しみやすいと思われる必要があります。バックエンドでは、セールスエンジンをスムーズに動かすためのプロセスやワークフローが数多く存在します。このチームにとって重要な仕事は、顧客向け（重要な取引や見込み客のメッセージをカスタマーサポートに伝えるなど）、社内向け（月末の見積もり更新を迅速に行うなど）のものがあります。

PagerDutyは、営業チームが散らかった受信トレイを整理し、何が本当に重要なのかを理解し、生産性を維持・向上させることができるよう支援します。これにより、より効果的な営業チーム、より幸せな顧客、そしてより多くの成約を得ることができるのです。

営業担当者は、月末や四半期末になると特別に忙しくなることがよくありますが、これには理由があります。顧客には、購入時期や予算の都合で、特定の時期に特定の製品を購入することがあります。四半期末の残り１日で取引が成立する場合、営業担当者も顧客も、売上処理の遅れを待つことはできません。たった24時間でも遅れると、取引を延期しなければならなくなり、せっかくの機会も失われてしまいます。

このような事態を避けるために、営業担当者はSalesforceやその他の記録システムとPagerDutyの間のインテグレーションを設定することができます。最終的な見積書が承認のために送信されると、承認者がサインオフするまでキューに入れられる必要はありません。また、営業担当者がメールやメッセージで優先度の高い案件であることを伝える必要もありません。その代わり、インテグレーションによって承認者に自動的に通知が送られ、すぐにこのアクションを完了するよう促されるため、案件をクローズに向けて順調に進めることができるのです。

財務チームによる期限内の支払いと受領の確認

財務チームでは、ミスが許されないため、問題を遅滞なく修正する必要があります。全ての取引が正しい時刻に正しい金額で行われることを確認する方法が必要です。財務部門にとって重要な仕事とは、予定した支払いが完了しないこと、処理に失敗したこと、監査統制違反に迅速に対処することなどが考えられます。このような重要な業務を発見できないままにしておくと、会社の収益に大きな影響を与えることになりかねません。

PagerDutyを使用すれば、財務チームは、プロセスに障害が発生したときに、担当チームや担当者に警告するテキスト、電話、eメールによる通知によって、重要な作業への対応の遅れを最小限に抑えることができます。この通知を受け取ったチームは、直ちに状況の改善に着手し、全ての取引が指定された時間内に完了するようにすることができます。

例えば、毎月末の午後９時59分に正確に完了するようスケジュールされた夜間決済があるとします。支払期日から24時間以内に支払いが完了しないと遅延とみなされます。その月の最終日は土曜日です。もしチームが月曜日の朝になるまで支払いの失敗を発見できなかったとしたら、会社には遅延損害金が発生します。

この問題を軽減するために、財務チームは、夜間の支払い処理に通知を設定しました。支払いに失敗した場合、PagerDutyが担当者に電話やメールを送り、担当者はすぐに支払いを再送信し、予定通りに支払いが完了するようにします。

マーケティングはデータを使って正しい方向にピボットする

マーケティングはペースの速い部署です。このチームは、データに基づいた意思決定を行い、営業に適格なリードを提供すると同時に、顧客や見込み客を教育することに努めています。このチームにとって重要な仕事は、競合他社の動向や計画されたキャンペーンの変更を常に把握すること、重要な機会を注視することなどです。

PagerDutyは、マーケティングチームが常に最新の情報を入手し、迅速に対応することで、時間と予算を最大限に活用できるよう支援します。マーケティングチームは、MarketoやHubspotのような頼りにしているツールが使えないときや、企業や競合他社の発表に基づいてピボットするタイミングを理解することができます。

例えば、ある小売企業のマーケティングチームが、年に一度のセールに先駆けて大規模なメールおよびソーシャルメディアキャンペーンを実施する計画をしているとします。この企業は実店舗も持っていますが、売上の大部分と最もエキサイティングなプロモーションのいくつかはオンラインのみで行われます。そのため、お客様に最高の体験をしていただきたいと考えています。

この体験を確実に守るため、マーケティング部門は、オンラインストアでお客様に影響を与える問題が発生した場合に、電話やメールで通知するよう設定しています。この情報をもとに、マーケティング部門はキャンペーンを延期するかどうか、リリース直前に判断することができます。こうして、キャンペーンが開始されると、顧客は購入することができ、マーケティングチームはその投資に対するROIを得ることができるのです。

重要な業務は、全てのビジネスの未来

重要な業務は、IT部門だけのものではありません。顧客、見込み客、従業員体験を守るために、全ての部門が重要な業務に対処する方法を必要としています。

PagerDutyソリューションガイド業務用は、ソリューションガイドをご覧いただくことで、あなたのチームをどのように支援できるかを知ることができます。 この記事はPagerDuty社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。

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

スクラムセレモニーには、以下のような５つのスクラムイベントがあります。 スプリントプランニング：スプリントバックログを決定し、チームの期待値を設定するためにスプリントの最初に開催されます。 デイリースタンドアップ／スクラム：毎日（多くは一日の始まりに）行われる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が日本語に訳したものです。無断複製を禁じます。原文はこちらです。