OPS03-BP03 エスカレーションが推奨されている - AWS Well-Architected フレームワーク

OPS03-BP03 エスカレーションが推奨されている

リーダーシップは、期待される成果がリスクにさらされ、期待される基準が満たされないと判断された場合にチームメンバーが問題や懸念事項を上位レベルの意思決定者やステークホルダーにエスカレーションするよう奨励します。これは組織内文化の特徴となり、あらゆるレベルで推進されます。リスクを特定し、インシデントの発生を防ぐため、エスカレーションは、早期かつ頻繁に実行する必要があります。リーダーシップは、問題をエスカレーションした個人を叱責することはありません。

期待される成果: 組織全体の個人は、問題を直上のリーダーシップにエスカレーションすることに慣れています。チームがいかなる問題であっても安心してエスカレーションできるはずだという期待を、リーダーシップは意図的かつ意識的に確立しています。組織内の各レベルで問題をエスカレーションするメカニズムが施行されています。従業員がマネージャーにエスカレーションする場合、影響レベルと問題をエスカレーションすべきかどうかを連携して決定します。従業員がエスカレーションを開始するには、問題に対処するための推奨される作業計画を含める必要があります。直属のリーダーシップがタイムリーにアクションを起こさない場合、組織へのリスクがエスカレーションに値すると確信する従業員は、トップレベルのリーダーシップに問題を提起するよう奨励されます。

一般的なアンチパターン:

  • エグゼクティブリーダーシップは、クラウドトランスフォーメーションプログラムのステータスミーティング中に、十分な質問をしておらず、問題や障害が発生している個所を発見することができません。ステータスとして良好な報告のみが提示されます。いかなる課題が提起されても、CEO はプログラムが失敗していると判断するため、良好な報告のみを発表したいと CIO が明言したためです。

  • クラウド運用エンジニアが、新しいナレッジ管理システムがアプリケーションチームによって広く採用されていないことに気づきました。この企業では、この新しいナレッジ管理システムに数百万 USD を投資し、1 年かけて実装しました。しかし、チームは依然としてランブックをローカルで作成し、組織のクラウド共有で共有しているため、サポートされているワークロードに関連するナレッジを検索するのが困難となっています。このシステムを継続的に使用することで業務効率を向上できるため、クラウド運用エンジニアは、この件についてリーダーシップに報告しようとします。ナレッジ管理システムの実装を主導するディレクターにこの件について伝えたところ、この報告により投資が問題視されるという理由で、ディレクターはクラウド運用エンジニアを叱責します。

  • コンピューティングリソースの強化を担当する情報セキュリティチームは、リソースを本番環境でリリースする前に、EC2 インスタンスが完全に保護されていることを確認するために必要となるスキャンをコンピューティングチームが実行する必要があるプロセスを導入することを決定しました。これにより、リソースのデプロイがこれまでより 1 週間遅延し、SLA に違反することになります。コンピューティングチームは、情報セキュリティ担当 VP の評判が悪くなることを懸念して、この問題についてクラウド担当の VP にエスカレーションすることを躊躇しています。

このベストプラクティスを活用するメリット:

複雑な問題や重大な問題が、ビジネスに影響を及ぼす前に対処されます。無駄な時間が低減します。リスクが最小限に抑えられます。問題を解決する際、チームがより積極的になり、結果を重視するようになります。

このベストプラクティスを活用しない場合のリスクレベル:

実装のガイダンス

組織のあらゆるレベルで自由にエスカレーションする意欲と能力は、組織と文化の基盤であり、重点的なトレーニング、リーダーシップのコミュニケーション、期待値設定、組織全体のあらゆるレベルでのメカニズムのデプロイを通じて、意識的に発展させる必要があります。

実装手順

  1. 組織のポリシー、基準、期待される内容を定義します。

    1. ポリシー、期待される内容、基準を幅広く採用し、理解されていることを確認します。

  2. 基準が満たされない場合、早期かつ頻繁にエスカレーションを行うよう従業員を奨励し、トレーニングを行い、権限を付与します。

  3. 早期かつ頻繁にエスカレーションすることがベストプラクティスであるという組織的な認識を確立します。エスカレーションした内容が事実ではないと判明する場合があること、およびエスカレーションしないことによってインシデントを阻止する機会を逃すよりもインシデントを阻止する機会が得られる方が好ましいということを受け入れます。

    1. エスカレーションのメカニズムを構築します (Andon コードシステムなど)。

    2. エスカレーションをいつどのように行うかを定義する手順を文書化します。

    3. アクションを実行または承認する人々を権限順に定義します。また、各ステークホルダーの連絡先の情報も追加します。

  4. エスカレーションが行われた場合、リーダーシップが促進する一連のアクションによりリスクが軽減されたとチームメンバーが認めるまで、エスカレーションを続行する必要があります。

    1. エスカレーションには以下を含める必要があります。

      1. 状況およびリスクの性質の説明

      2. 状況の重要度

      3. 影響が及ぶ人々や事項

      4. 影響の規模

      5. 影響が発生した場合の緊急性

      6. 推奨される救済策と緩和計画

    2. エスカレーションする従業員を保護します。対処を行わない意思決定者やステークホルダーを避けてエスカレーションしたチームメンバーを報復行為から保護するポリシーを施行します。これが発生しているかどうかを特定し、適切に対応するメカニズムを備えます。

  5. 組織が生み出すすべてのものに、継続的な改善のフィードバックループを取り入れる文化を奨励します。フィードバックループは責任者への軽微なエスカレーションとして機能し、エスカレーションが必要ない場合でも改善の機会を特定できます。継続的な改善の文化は、誰もがより積極的に行動することを押し進めます。

  6. リーダーシップは、ポリシー、基準、メカニズム、報復されることのないオープンなエスカレーションと継続的なフィードバックループを奨励することを定期的に繰り返し強調すべきです。

実装計画に必要な工数レベル:

リソース

関連するベストプラクティス:

関連ドキュメント:

関連動画:

関連する例: