# 組織
**Topics**
+ [OPS 1. 優先順位はどのように決定すればよいですか?](ops-01.md)
+ [OPS 2. ビジネスの成果をサポートするために、組織をどのように構築しますか?](ops-02.md)
+ [OPS 3. 組織の文化はビジネスの成果をどのようにサポートしますか?](ops-03.md)
# OPS 1. 優先順位はどのように決定すればよいですか?
誰もが、ビジネスを成功させるうえで自分が果たす役割を理解する必要があります。リソースの優先順位を設定するために共通の目標を設定します。そうすることで、努力を通じて得られるメリットが最大限に活かされます。
**Topics**
+ [OPS01-BP01 外部顧客のニーズを評価する](ops_priorities_ext_cust_needs.md)
+ [OPS01-BP02 内部顧客のニーズを評価する](ops_priorities_int_cust_needs.md)
+ [OPS01-BP03 ガバナンス要件を評価する](ops_priorities_governance_reqs.md)
+ [OPS01-BP04 コンプライアンス要件を評価する](ops_priorities_compliance_reqs.md)
+ [OPS01-BP05 脅威の状況を評価する](ops_priorities_eval_threat_landscape.md)
+ [OPS01-BP06 メリットとリスクを管理しながらトレードオフを評価する](ops_priorities_eval_tradeoffs.md)
# OPS01-BP01 外部顧客のニーズを評価する
ビジネス、開発、運用チームを含む主要ステークホルダーと協力して、外部顧客のニーズに対する重点領域を決定します。これにより、目的のビジネス成果達成に必要なオペレーションサポートについて十分に理解していることを確かめることができます。
**期待される成果:**
+ 顧客の成果を起点に考える。
+ 運用体制がビジネス成果と目標をどのようにサポートしているかを理解する。
+ すべての関係者を関与させる。
+ 外部顧客のニーズを捉えるメカニズムがある。
**一般的なアンチパターン:**
+ 営業時間外にカスタマーサポートを設けないこととしましたが、サポートリクエストの履歴データを確認していません。あなたには、これが顧客に影響を与えるかどうかはわかりません。
+ 新しい機能を開発していますが、当該機能が望まれているかどうか、望まれている場合はどのような形式なのかを見出すために、顧客に関与してもらっておらず、また、提供の必要性および提供方法を検証するための実験も行っていません。
**このベストプラクティスを活用する利点:** ニーズが満たされている顧客は、顧客のままでいる可能性が高くなります。外部の顧客のニーズを評価し、理解することで、ビジネス価値を実現するためにどのような優先順位で注力すべきかを知ることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
**ビジネスニーズの理解:** ビジネスの成功は、ビジネス、開発、運用の各チームを含むステークホルダー全体で目標を共有し、理解を深めることで実現できます。
**外部顧客のビジネス目標、ニーズ、優先順位の確認:** ビジネス、開発、運用の各チームを含む主要関係者と外部顧客の目標、ニーズ、優先順位について議論します。これにより、ビジネスおよび顧客成果を達成するために必要なオペレーションサポートについて十分に理解できます。
**共通理解の確立:** ワークロードのビジネス機能、ワークロードの運用における各チームの役割、およびこれらの要因が内部および外部顧客の共通のビジネス目標をどのようにサポートするかについて、共通の理解を確立します。
## リソース
**関連するベストプラクティス:**
+ [OPS11-BP03 フィードバックループを実装する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_feedback_loops.html)
# OPS01-BP02 内部顧客のニーズを評価する
ビジネス、開発、運用チームを含む主要関係者と協力して、内部顧客のニーズに対する重点領域を決定します。これにより、ビジネス成果を達成するために必要なオペレーションサポートについて十分に理解できます。
**期待される成果:**
+ 確立された優先順位に基づいて、改善の努力を最も影響があるところに集中させる (チームのスキルの開発、ワークロードのパフォーマンスの改善、コストの削減、ランブックの自動化、モニタリングの強化など)。
+ ニーズの変化に応じて優先順位を更新する。
**一般的なアンチパターン:**
+ ネットワーク管理を容易にするため、製品チームに相談せず、IP アドレスの割り当てを変更することになった。製品チームに与える影響は未知数です。
+ 新しい開発ツールを実装しようとしているが、当該ツールが必要とされているかどうか、または既存のプラクティスと互換性があるかどうかを知るために、社内クライアントを関与させていない。
+ 新しいモニタリングシステムを実装しようとしているが、検討されるべきモニタリングまたはレポートのニーズがあるかどうかを把握するために社内クライアントに問い合わせていない。
**このベストプラクティスを活用するメリット:** 社内の顧客のニーズを評価し、理解することで、ビジネス価値を実現するためにどのような優先順位で注力すべきかを知ることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ ビジネスニーズの理解: ビジネス、開発、運用の各チームを含むステークホルダー全体で目標を共有し、理解を深めることでビジネスは成功します。
+ 内部顧客のビジネス目標、ニーズ、優先順位の確認: ビジネス、開発、運用の各チームを含む主要ステークホルダーと連携し、内部顧客の目標、ニーズ、優先順位について議論します。これにより、ビジネスおよび顧客成果を達成するために必要なオペレーションサポートについて十分に理解できます。
+ 共通理解の確立: ワークロードのビジネス機能、ワークロードの運用における各チームの役割、およびこれらの要因が内部および外部顧客の共通のビジネス目標をどのようにサポートするかについて、共通の理解を確立します。
## リソース
**関連するベストプラクティス:**
+ [OPS11-BP03 フィードバックループを実装する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_feedback_loops.html)
# OPS01-BP03 ガバナンス要件を評価する
ガバナンスとは、企業がビジネス目標を達成するために使用する、ポリシー、ルール、フレームワーク一式です。ガバナンス要件は、組織内から生まれます。選択する技術の種類に影響する場合も、ワークロードを運用する方法に関連する場合もあります。組織のガバナンス要件を、ワークロードに組み込みます。コンフォーマンスとは、ガバナンス要件が組み込まれていることを示す能力のことです。
**期待される成果:**
+ ガバナンス要件が、アーキテクチャの設計およびワークロードのオペレーションに組み込まれています。
+ ガバナンス要件に従っている証拠を提供できます。
+ ガバナンス要件は定期的に見直され更新されています。
**一般的なアンチパターン:**
+ 組織が、ルートアカウントを多要素認証とすることを義務としている。この要件を実装できなかったため、ルートアカウントが侵害された。
+ ワークロードの設計中に、IT 部門が承認していないインスタンスタイプを選択した。ワークロードを起動できず、再設計を行わなければならなくなった。
+ ディザスタリカバリ計画を備えることが必須となっているが、計画を作成しなかったため、ワークロードの停止が長引いた。
+ チームは新しいインスタンスの使用を希望していたが、ガバナンス要件が更新されていないため、許可されなかった。
**このベストプラクティスを活用するメリット:**
+ ガバナンス要件に従うと、ワークロードを組織のより大きなポリシーに合わせることができます。
+ ガバナンス要件は、業界の標準と組織のベストプラクティスを反映しています。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
関係者やガバナンス組織と協力して、ガバナンス要件を特定します。ガバナンス要件をワークロードに含めます。ガバナンス要件に従っている証拠を提供できるようにします。
**お客様事例**
AnyCompany Retail では、クラウドオペレーションチームが組織全体の関係者と協力して、ガバナンス要件を作成しました。例えば、Amazon EC2 インスタンスへの SSH アクセスを禁止しています。チームがシステムにアクセスする必要がある場合、AWS Systems Manager Session Manager を使用する必要があります。クラウドオペレーションチームは、新しいサービスを利用できるようになるたびに、ガバナンス要件を定期的に更新しています。
**実装手順**
1. 一元化されたチームがあればそれも含め、ワークロードの関係者を特定します。
1. 関係者と協力して、ガバナンス要件を特定します。
1. リストを作成したら、改善項目に優先順位を付け、ワークロードへの実装を開始します。
1. [AWS Config](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/) のようなサービスを使用して、governance-as-code を作成し、ガバナンス要件が順守されていることを検証します。
1. [AWS Organizations](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) を使用する場合は、サービスコントロールポリシーを活用してガバナンス要件を実装できます。
1. 実装を検証するドキュメントを提供します。
**実装計画に必要な工数レベル:** 中 ガバナンス要件を満たさずに実装すると、ワークロードをやり直すことになる場合があります。
## リソース
**関連するベストプラクティス:**
+ [OPS01-BP04 コンプライアンス要件を評価する](ops_priorities_compliance_reqs.md) - コンプライアンスはガバナンスに似ていますが、組織外から取得されます。
**関連ドキュメント:**
+ [AWS 管理とガバナンスのクラウド環境ガイド](https://docs.aws.amazon.com/wellarchitected/latest/management-and-governance-guide/management-and-governance-cloud-environment-guide.html)
+ [ Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment ](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/)
+ [Governance in the AWS クラウド: The Right Balance Between Agility and Safety](https://aws.amazon.com/blogs/apn/governance-in-the-aws-cloud-the-right-balance-between-agility-and-safety/)
+ [GRC (ガバナンス、リスク、コンプライアンス) とは何ですか?](https://aws.amazon.com/what-is/grc/)
**関連動画:**
+ [AWS Management and Governance: Configuration, Compliance, and Audit - AWS Online Tech Talks](https://www.youtube.com/watch?v=79ud1ZAaoj0)
+ [AWS re:Inforce 2019: Governance for the Cloud Age (DEM12-R1)](https://www.youtube.com/watch?v=y3WmHnavuN8)
+ [AWS re:Invent 2020: Achieve compliance as code using AWS Config](https://www.youtube.com/watch?v=m8vTwvbzOfw)
+ [AWS re:Invent 2020: Agile governance on AWS GovCloud (US)](https://www.youtube.com/watch?v=hv6B17eriHQ)
**関連する例:**
+ [AWS Config 適合パックのサンプル](https://docs.aws.amazon.com/config/latest/developerguide/conformancepack-sample-templates.html)
**関連サービス:**
+ [AWS Config](https://aws.amazon.com/config/)
+ [AWS Organizations - サービスコントロールポリシー](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)
# OPS01-BP04 コンプライアンス要件を評価する
規制、業界、および社内のコンプライアンス要件は、組織の優先順位を定義するための重要な推進要素です。コンプライアンスフレームワークによって、特定の技術や地理的場所を使用できない場合もあります。外部コンプライアンスフレームワークが特定されない場合は、デューデリジェンスを適用します。コンプライアンスを検証する監査またはレポートを作成します。
自社製品が特定のコンプライアンス基準を満たしていることを宣伝する場合、継続的なコンプライアンスを確保するための内部プロセスが必要です。コンプライアンス標準の例としては、PCI DSS、FedRAMP、HIPAA があります。適用されるコンプライアンス標準は、ソリューションが保存または送信するデータの種類、ソリューションがサポートするリージョンなど、さまざまな要因によって決まります。
**期待される成果:**
+ 規制、業界、および社内のコンプライアンス要件がアーキテクチャの選択に組み込まれています。
+ コンプライアンスを検証して監査レポートを作成できます。
**一般的なアンチパターン:**
+ ワークロードの一部が、クレジットカード業界のデータセキュリティ基準 (PCI DSS) フレームワークの対象となっているが、ワークロードはクレジットカードデータを暗号化せずに保存している。
+ ソフトウェア開発者とアーキテクトが、組織が遵守すべきコンプライアンスフレームワークに気付いていない。
+ 年次の Systems and Organizations Control (SOC2) Type II 監査が近く行われるが、コントロールが配置されていることを検証できない。
**このベストプラクティスを活用するメリット:**
+ ワークロードに適用されるコンプライアンス要件を評価し、理解することで、ビジネス価値を実現するためにどのような優先順位で注力すべきかを知ることができます。
+ コンプライアンスフレームワークに合致する適切な場所や技術を選択します。
+ 可監査性を持たせてワークロードを設計すると、コンプライアンスフレームワークを遵守していることを証明するのに役立ちます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
このベストプラクティスを実装することで、コンプライアンス要件をアーキテクチャ設計プロセスに組み込みます。チームメンバーは必要なコンプライアンスフレームワークを認識します。フレームワークに沿ってコンプライアンスを検証します。
**お客様事例**
AnyCompany Retail は、顧客のクレジットカード情報を保存しています。カードストレージチームの開発者は、PCI-DSS フレームワークに準拠する必要があることを理解しています。クレジットカード情報が PCI-DSS フレームワークに沿って安全に保存およびアクセスされていることを検証する手順を踏んできています。毎年、セキュリティチームと協力して、コンプライアンスを検証しています。
**実装手順**
1. セキュリティチームやガバナンスチームと協力して、ワークロードが準拠しなければならない業界、規制、組織内部のコンプライアンスフレームワークを精査します。コンプライアンスフレームワークをワークロードに組み込みます。
1. [AWS Compute Optimizer](https://docs.aws.amazon.com/compute-optimizer/latest/ug/what-is-compute-optimizer.html) や [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html) などの サービスとの AWS リソースの継続的なコンプライアンスを検証します。
1. チームメンバーがコンプライアンス要件に沿ってワークロードを運用および進化できるように、コンプライアンス要件を教育します。コンプライアンス要件は、アーキテクチャや技術を選択する際に含める必要があります。
1. コンプライアンスフレームワークによっては、監査またはコンプライアンスレポートを作成する必要があります。組織と協力して、このプロセスをできるだけ自動化します。
1. [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html) などのサービスを使用して、コンプライアンスを検証し、監査レポートを生成します。
1. AWS セキュリティおよびコンプライアンスドキュメントは、[AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/what-is-aws-artifact.html) でダウンロードできます。
**実装計画に必要な工数レベル:** 中 コンプライアンスフレームワークの実装は課題が多い場合があります。監査レポートやコンプライアンスドキュメントを作成するとさらに複雑になります。
## リソース
**関連するベストプラクティス:**
+ [SEC01-BP03 管理目標を特定および検証する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_control_objectives.html) - セキュリティ統制目標は、全体的なコンプライアンスの重要な部分です。
+ [SEC01-BP06 標準的なセキュリティ統制のデプロイを自動化する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_securely_operate_test_validate_pipeline.html) - パイプラインの一部として、セキュリティコントロールを検証します。新しい変更に関するコンプライアンスドキュメントを作成することもできます。
+ [SEC07-BP02 データの機密性に基づいてデータ保護統制を適用する](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_data_classification_define_protection.html) - 多くのコンプライアンスフレームワークには、データ処理とストレージポリシーがベースになっています。
+ [SEC10-BP03 フォレンジック機能を備える](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_prepare_forensic.html) - フォレンジック機能は、監査コンプライアンスに使用できる場合があります。
**関連ドキュメント:**
+ [AWS コンプライアンスセンター](https://aws.amazon.com/financial-services/security-compliance/compliance-center/)
+ [AWS コンプライアンスのリソース](https://aws.amazon.com/compliance/resources/)
+ [AWS リスクとコンプライアンスのホワイトペーパー](https://docs.aws.amazon.com/whitepapers/latest/aws-risk-and-compliance/welcome.html)
+ [AWS 責任共有モデル](https://aws.amazon.com/compliance/shared-responsibility-model/)
+ [コンプライアンスプログラムによる対象範囲内の AWS のサービス](https://aws.amazon.com/compliance/services-in-scope/)
**関連動画:**
+ [AWS re:Invent 2020: Achieve compliance as code using AWS Compute Optimizer](https://www.youtube.com/watch?v=m8vTwvbzOfw)
+ [AWS re:Invent 2021 - Cloud compliance, assurance, and auditing](https://www.youtube.com/watch?v=pdrYGVgb08Y)
+ [AWS Summit ATL 2022 - Implementing compliance, assurance, and auditing on AWS (COP202)](https://www.youtube.com/watch?v=i7XrWimhqew)
**関連する例:**
+ [AWS での PCI DSS および AWS Foundational Security Best Practices](https://aws.amazon.com/solutions/partners/compliance-pci-fsbp-remediation/)
**関連サービス:**
+ [AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/what-is-aws-artifact.html)
+ [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html)
+ [AWS Compute Optimizer](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html)
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)
# OPS01-BP05 脅威の状況を評価する
ビジネスに対する脅威 (競合、ビジネスリスクと負債、運用リスク、情報セキュリティの脅威など) を評価し、リスクのレジストリで現在の情報を維持します。注力する場所を決定する際に、リスクの影響を考慮します。
[Well-Architected フレームワーク](https://aws.amazon.com/architecture/well-architected/)は学習、測定、改善に重点を置いています。アーキテクチャを評価し、時間の経過とともにスケールする設計を実装するための一貫したアプローチを提供します。AWS は、[AWS Well-Architected Tool](https://aws.amazon.com/well-architected-tool/) が開発前にアプローチを、本番稼働前にワークロードの状態を、本番稼働中にワークロードの状態をレビューするのに役立ちます。最新の AWS アーキテクチャのベストプラクティスと比較して、ワークロードの全体的なステータスをモニタリングし、潜在的なリスクについてインサイトを得ることができます。
AWS をご利用のお客様は、AWS のベストプラクティスと照らし合わせて[アーキテクチャを評価](https://aws.amazon.com/premiumsupport/programs/)するために、ミッションクリティカルなワークロードのガイド付き Well-Architected レビューを受けることもできます。エンタープライズサポートのお客様は、クラウドでの運用へのアプローチにおけるギャップの特定を支援するよう設計された[運用レビュー](https://aws.amazon.com/premiumsupport/programs/)を受けることができます。
これらのレビューのチーム間での関与は、ワークロードとチームの役割の成功への貢献方法に関する共通理解を確立するのに役立ちます。レビューを通じて特定されるニーズは、優先順位を決定するのに役立ちます。
[AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/technology/trusted-advisor/) は、最適化を推奨する中心的なチェックのセットへのアクセスを提供するツールであり、優先順位を決定するのに役立ちます。[ビジネスおよびエンタープライズサポートのお客様](https://aws.amazon.com/premiumsupport/plans/)は、優先順位をさらに高めることができるセキュリティ、信頼性、パフォーマンス、コストの最適化に重点を置いた追加のチェックにアクセスできます。
**期待される成果:**
+ Well-Architected と Trusted Advisor 出力を定期的に確認し、これに基づいて対応する
+ サービスの最新のパッチステータスを把握する
+ 既知の脅威のリスクと影響を理解し、適宜対応する
+ 必要に応じて緩和策を実施する
+ アクションと背景情報を伝える
**一般的なアンチパターン:**
+ 自社製品に古いバージョンのソフトウェアライブラリを使用しています。あなたは、ワークロードに意図しない影響を及ぼす可能性のある問題について、ライブラリのセキュリティ更新が必要なことを認識していません。
+ 最近、競合他社は、あなたの製品に関する顧客からの苦情の多くに対処する製品のバージョンをリリースしました。あなたは、これらの既知の問題の対処について優先順位付けを行っていません。
+ 規制当局は、法規制コンプライアンス要件を遵守していない企業の責任を追求してきました。未対応のコンプライアンス要件への対応に優先順位が付けてられていません。
**このベストプラクティスを活用するメリット: **組織とワークロードに対する脅威を特定して理解することで、対処すべき脅威、その優先度、対処に必要なリソースを判断しやすくなります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
+ **脅威の状況の評価:** ビジネスに対する脅威 (競合、ビジネスリスクと負債、運用リスク、情報セキュリティの脅威など) を評価し、重点領域を決定する際にその影響を織り込めるようにします。
+ [AWS セキュリティ速報](https://aws.amazon.com/security/security-bulletins/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
+ **脅威モデルの維持:** 潜在的な脅威、計画および実施された軽減策、またその優先順位を特定する脅威モデルを確立し、維持します。脅威がインシデントとして出現する確率、それらのインシデントから回復するためのコスト、発生が予想される損害、およびそれらのインシデントを防ぐためのコストを確認します。脅威モデルの内容の変更に伴って、優先順位を変更します。
## リソース
**関連するベストプラクティス:**
+ [SEC01-BP07 脅威モデルを使用して脅威を特定し、緩和策の優先順位を付ける](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/sec_securely_operate_threat_model.html)
**関連ドキュメント:**
+ [AWS クラウド コンプライアンス](https://aws.amazon.com/compliance/)
+ [AWS セキュリティ速報](https://aws.amazon.com/security/security-bulletins/)
+ [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/)
**関連動画:**
+ [AWS re:Inforce 2023 - A tool to help improve your threat modeling](https://youtu.be/CaYCsmjuiHg?si=e_CXPGqRF4WeBr1u)
# OPS01-BP06 メリットとリスクを管理しながらトレードオフを評価する
複数の関係者の利害が対立している場合、労力の優先順位付け、機能の構築、ビジネス戦略に沿った結果の実現が難しくなることがあります。例えば、IT インフラストラクチャコストの最適化よりも、新機能の市場投入までの時間短縮を優先させるよう求められる場合があります。これにより、2 つの利害関係者の間で対立が発生します。このような場合、対立を解消するには、より上位の権限者に決断を委ねる必要があります。意思決定プロセスから感情的な固執を取り除くには、データが必要です。
戦術レベルでも同様の問題が発生する可能性があります。例えば、リレーショナルデータベースまたは非リレーショナルデータベースのどちらを使用するかという選択が、アプリケーションの運用に大きな影響を及ぼす場合があります。さまざまな選択肢で予想される結果を理解することが重要です。
AWS は、AWS とそのサービスについてチームを教育し、選択がどのようにワークロードに影響を与えるかについての理解を深める支援を行います。チームを教育するには、[サポート](https://aws.amazon.com/premiumsupport/programs/) ([AWS ナレッジセンター](https://aws.amazon.com/premiumsupport/knowledge-center/)、[AWS ディスカッションフォーラム](https://forums.aws.amazon.com/index.jspa)、[サポートセンター)](https://console.aws.amazon.com/support/home/) および [AWS ドキュメント](https://docs.aws.amazon.com/)が提供するリソースを使用します。さらに質問がある場合は、サポートまでお問い合わせください。
また、AWS は [Amazon Builders' Library](https://aws.amazon.com/builders-library/) のベストプラクティスとパターンも共有しています。[AWS ブログ](https://aws.amazon.com/blogs/)と[公式の AWS ポッドキャスト](https://aws.amazon.com/podcasts/aws-podcast/)では、その他さまざまな有益情報を入手できます。
**期待される成果:** クラウドデリバリー組織内のあらゆるレベルでの重要な意思決定を促進する、意思決定ガバナンスフレームワークが明確に定義されています。このフレームワークには、リスク登録簿、意思決定の権限を持つ定義済みの役割、考えられる意思決定の各レベルに対する定義済みモデルなどの機能が含まれています。このフレームワークでは、対立の解決方法、提示すべきデータ、オプションの優先順位付けの方法が事前に定義されているため、決定が下されたらすぐに決定にコミットできます。意思決定のフレームワークには、すべての意思決定のメリットとリスクを確認して比較検討し、トレードオフを理解するための標準的アプローチが含まれています。これには、規制コンプライアンス要件の順守などの外部要因が含まれる場合があります。
**一般的なアンチパターン:**
+ 投資家からは、Payment Card Industry Data Security Standards (PCI DSS) への準拠を実証することが求められています。投資家の要求に応えることと、現在の開発活動を継続することとのトレードオフについて検討しません。代わりに、準拠を実証することなく、開発作業を進めます。投資家は、プラットフォームのセキュリティと、投資の是非に懸念を抱いて、会社に対する支援を停止します。
+ 開発者の 1 人がインターネットで見つけたライブラリを含めることにしました。不明なソースからこのライブラリを採用するリスクを評価しておらず、脆弱性や悪意のあるコードが含まれているかどうかはわかりません。
+ 当初ビジネスが移行を正当化した理由は、アプリケーションワークロードの 60％ のモダナイゼーションに基づくものでした。しかし、技術的な問題により、モダナイゼーションは 20％ に留めるという決断が下されました。これにより、計画していた長期的メリットは減少し、インフラストラクチャチームがレガシーシステムを手動でサポートするためにオペレーターの労力が増え、この変更を予定していなかったインフラストラクチャチームでの新しいスキルセットの構築に大きく依存することになりました。
**このベストプラクティスを活用するメリット:** 取締役会レベルでのビジネスの優先順位を十分に調整し、これをサポートできます。成功の達成に伴うリスクを理解し、十分な情報に基づいた意思決定を行うと共に、リスクが成功のチャンスを妨げる場合に適切な措置を取ることができます。意思決定がもたらす影響と結果を理解することで、選択肢に優先順位を付けやすくなり、リーダーはより迅速に合意に達することができるため、ビジネス成果の向上につながります。選択肢のメリットを特定し、組織のリスクを認識することで、事例に頼った意思決定ではなく、データドリブンな意思決定を行うことができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
メリットとリスクの管理は、主要な意思決定の要件を決定する運営組織が定義すべきです。関連するリスクを理解したうえで、決定が組織にもたらすメリットに基づいて意思決定を行い、優先順位を付けます。組織の意思決定には正確な情報が不可欠です。この情報は、信頼性の高い測定に基づき、費用対効果分析という一般的な業界慣行によって定義されたものである必要があります。このような決定を下すには、中央集権型と権限分散型のバランスを取ります。必ずトレードオフはあるため、それぞれの選択肢が定義された戦略と期待されるビジネス成果にもたらす影響を理解することが重要です。
### 実装手順
1. 包括的なクラウドガバナンスフレームワーク内でメリットの測定方法を定式化します。
1. 中央集権型の意思決定と、権限分散型の意思決定のバランスを取ります。
1. あらゆる意思決定で負担の大きい意思決定プロセスを実施することが遅延につながることを理解します。
1. 意思決定プロセスに外部要因 (コンプライアンス要件など) を組み込みます。
1. さまざまなレベルの意思決定について、合意に基づいた意思決定フレームワークを確立します。このフレームワークには、利害の対立がかかわる意思決定を解決すべき人物が含まれます。
1. 取り消しが効かない可能性のある「ワンウェイドア」(一方通行の扉) の意思決定を一元化します。
1. 下位レベルの組織リーダーが「ツーウェイドア」(双方向に行き来できる扉) の意思決定を行えるようにします。
1. メリットとリスクを理解し、管理します。決定のメリットと関連するリスクのバランスを取ってください。
1. **メリットの特定**: ビジネスの目標、ニーズ、優先順位に基づいてメリットを特定します。例として、ビジネスケースへの影響、市場投入までの時間、セキュリティ、信頼性、パフォーマンス、コストなどがあります。
1. **リスクの特定**: ビジネスの目標、ニーズ、優先順位に基づいてリスクを特定します。例として、市場投入までの時間、セキュリティ、信頼性、パフォーマンス、コストなどがあります。
1. **リスクに対するメリットの評価と情報に基づく意思決定**: ビジネス、開発、運用を含む主要関係者の目標、ニーズ、優先順位に基づいてメリットとリスクの影響を決定します。メリットの価値を、リスクが現実化する可能性とその影響のコストに照らして評価します。例えば、信頼性よりも市場投入までのスピードを重視すると、競争上の優位性が得られます。ただし、信頼性の問題がある場合、稼働時間が短くなる場合があります。
1. コンプライアンス要件の順守を自動化する主な意思決定をプログラム的に実施します。
1. バリューストリーム分析や LEAN など既知の業界フレームワークと機能を活用して、現状のパフォーマンスやビジネスメトリクスのベースラインを定め、これらのメトリクスの改善に向けた進捗の反復を定義します。
**実装計画に必要な工数レベル:** 中～高
## リソース
**関連するベストプラクティス:**
+ [OPS01-BP05 脅威の状況を評価する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_threat_landscape.html)
**関連ドキュメント:**
+ [Amazon 1 日目の文化の要素 \$1 高品質で高速な決定を下す](https://aws.amazon.com/executive-insights/content/how-amazon-defines-and-operationalizes-a-day-1-culture/)
+ [クラウドガバナンス](https://aws.amazon.com/cloudops/cloud-governance/)
+ [管理とガバナンスのクラウド環境ガイド](https://docs.aws.amazon.com/wellarchitected/latest/management-and-governance-guide/management-and-governance-cloud-environment-guide.html?did=wp_card&trk=wp_card)
+ [クラウドの、そしてデジタル時代のガバナンス: パート 1 および 2](https://aws.amazon.com/blogs/enterprise-strategy/governance-in-the-cloud-and-in-the-digital-age-part-one/)
**関連動画:**
+ [Podcast \$1 Jeff Bezos \$1 On how to make decisions](https://www.youtube.com/watch?v=VFwCGECvq4I)
**関連する例:**
+ [データを使用して情報に基づいた意思決定を下す (DevOps サーガ)](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/oa.bcl.10-make-informed-decisions-using-data.html)
+ [開発価値ストリームマッピングを使用して DevOps 成果の制約を特定する](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-devops-value-stream-mapping/introduction.html)
# OPS 2. ビジネスの成果をサポートするために、組織をどのように構築しますか?
チームはビジネスの成果を達成するうえでの役割を理解する必要があります。チームは他のチームの成功におけるそれぞれの役割、自分たちのチームの成功における他のチームの役割を理解し、目標を共有する必要があります。責任、所有権、意思決定方法、意思決定を行う権限を持つユーザーを理解することは、労力を集中的に投入し、チームの利点を最大化するのに役立ちます。
**Topics**
+ [OPS02-BP01 リソースには特定の所有者が存在する](ops_ops_model_def_resource_owners.md)
+ [OPS02-BP02 プロセスと手順に特定の所有者が存在する](ops_ops_model_def_proc_owners.md)
+ [OPS02-BP03 パフォーマンスに責任を持つ所有者が運用アクティビティに存在する](ops_ops_model_def_activity_owners.md)
+ [OPS02-BP04 責任と所有権を管理するためのメカニズムが存在する](ops_ops_model_def_responsibilities_ownership.md)
+ [OPS02-BP05 追加、変更、除外をリクエストするメカニズムが存在する](ops_ops_model_req_add_chg_exception.md)
+ [OPS02-BP06 チーム間の責任は事前定義済みまたは交渉済みである](ops_ops_model_def_neg_team_agreements.md)
# OPS02-BP01 リソースには特定の所有者が存在する
ワークロードのリソースには、変更管理、トラブルシューティング、その他機能を受け持つ、特定できる所有者が必要です。所有者は、ワークロード、アカウント、インフラストラクチャ、プラットフォーム、アプリケーションに割り当てられます。所有権は、一元登録などのツール、またはリソースに添付されたメタデータを使用して記録されます。コンポーネントのビジネス価値で、それらに適用されるプロセスと手順が決まります。
**期待される成果:**
+ リソースに、メタデータまたは一元登録を使用して特定できる所有者がいます。
+ チームメンバーが、リソースを誰が所有しているかを特定できます。
+ アカウントの所有者は、可能な限り 1 人です。
**一般的なアンチパターン:**
+ AWS アカウントのその他の連絡先が入力されていない。
+ リソースに、それを所有するチームを特定するタグがない。
+ E メールマッピングのない ITSM キューがある。
+ インフラストラクチャの重要な部分で 2 つのチームの所有権が重複している。
**このベストプラクティスを活用するメリット:**
+ リソースの変更管理は、所有権が割り当てられていて、わかりやすくなっています。
+ トラブルシューティングが発生した場合に、適切な所有者を関与させることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
環境内のリソースユースケースにおける所有権の意味を定義します。所有権とは、リソースの変更を監督する人、トラブルシューティング中にリソースをサポートする人、または財務的な責任者を意味することもあります。名前、連絡先情報、組織、チームなどでリソースの所有者を指定し、記録します。
**お客様事例**
AnyCompany Retail は、所有権を、リソースの変更とサポートを担当するチームまたは個人と定義しています。同社は AWS Organizations を活用して AWS アカウントを管理しています。予備のアカウント連絡先は、グループ受信箱を使用して設定されています。各 ITSM キューは、E メールエイリアスにマッピングされています。タグによって、誰が AWS リソースを所有しているかを特定できます。その他のプラットフォームやインフラストラクチャについては、所有権と連絡先情報を特定できる wiki ページがあります。
### 実装手順
1. 組織における所有権を定義することから始めます。所有権は、リソースのリスクに対して責任を持つ人、リソースの変更を担当する人、またはトラブルシューティング時にリソースをサポートする人などを意味します。また、リソースの財務的または管理的な所有権を意味することもあります。
1. [AWS Organizations](https://aws.amazon.com/organizations/) を使用してアカウントを管理します。アカウントのその他の連絡先を一元管理できます。
1. 会社の E メールアドレスや電話番号を連絡先として使用することで、その E メールアドレスや電話番号の持ち主が組織から離れた場合でも、連絡先にアクセスすることができます。例えば、請求、オペレーション、セキュリティ用に別々の E メール配信リストを作成し、アクティブな AWS アカウントごとに請求、セキュリティ、オペレーションの連絡先として設定します。誰かが休暇を取っていたり、担当が変わったり、会社を辞めたりした場合でも、複数の人が AWS の通知を受け取り、対応できるようになります。
1. アカウントが [AWS Organizations](https://aws.amazon.com/organizations/) で管理されていない場合、代替のアカウント連絡先があれば、必要に応じて AWS が適切な担当者と連絡を取ることができます。アカウントの代替連絡先は、個人ではなくグループを指定して設定してください。
1. タグを使用して AWS のリソースの所有者を特定します。所有者と連絡先情報の両方を、別々のタグで指定できます。
1. [AWS Config](https://aws.amazon.com/config/) ルールを使用して、リソースに必須の所有権タグをつけるように強制できます。
1. 組織においてタグ付け戦略を策定する方法に関する詳細なガイダンスについては、「[AWS のタグ付けのベストプラクティス (ホワイトペーパー)](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)」を参照してください。
1. 生成 AI を活用する会話型アシスタント、[Amazon Q Business](https://aws.amazon.com/q/business/) を使用して、従業員の生産性を高め、質問に回答し、エンタープライズシステムの情報に基づいてタスクを完了します。
1. Amazon Q Business を会社のデータソースに接続します。Amazon Q Business には、Amazon Simple Storage Service (Amazon S3)、Microsoft SharePoint、Salesforce、Atlassian Confluence など、40 を超えるサポート対象のデータソースへの事前構築済みのコネクタが用意されています。詳細については、「[Amazon Q Business のコネクタ](https://aws.amazon.com/q/business/connectors/)」を参照してください。
1. その他のリソース、プラットフォーム、インフラストラクチャについては、所有権を特定するドキュメントを作成します。このドキュメントはチームメンバーが誰でも利用できるようにします。
**実装計画に必要な工数レベル:** 低。アカウントの連絡先情報およびタグを利用して、AWS リソースの所有権を割り当てます。その他のリソースについては、wiki の表などシンプルなものを使用して所有権と連絡先情報を記録するか、ITSM ツールを使用して所有権をマッピングします。
## リソース
**関連するベストプラクティス:**
+ [OPS02-BP02 プロセスと手順には特定の所有者が存在する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_proc_owners.html)
+ [OPS02-BP04 責任と所有権を管理するためのメカニズムが存在する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
**関連ドキュメント:**
+ [AWS アカウント管理 - 連絡先情報の更新](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact.html)
+ [AWS Organizations - 組織の代替連絡先の更新](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_update_contacts.html)
+ [AWS のタグ付けのベストプラクティス (ホワイトペーパー)](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [Amazon Q Business と AWS IAM Identity Center を利用して、プライベートでセキュアなエンタープライズ生成 AI アプリケーションを開発する](https://aws.amazon.com/blogs/machine-learning/build-private-and-secure-enterprise-generative-ai-apps-with-amazon-q-business-and-aws-iam-identity-center/)
+ [生成 AI を使用して従業員の生産性向上を支援する Amazon Q Business の一般提供開始](https://aws.amazon.com/blogs/aws/amazon-q-business-now-generally-available-helps-boost-workforce-productivity-with-generative-ai/)
+ [AWS クラウド運用および移行ブログ - AWS Config と AWS Organizations で自動かつ一元的なタグ付けコントロールを実装する](https://aws.amazon.com/blogs/mt/implementing-automated-and-centralized-tagging-controls-with-aws-config-and-aws-organizations/)
+ [AWS セキュリティブログ - AWS CloudFormation Guard で pre-commit フックを拡張する](https://aws.amazon.com/blogs/security/extend-your-pre-commit-hooks-with-aws-cloudformation-guard/)
+ [AWS DevOps ブログ - AWS CloudFormation Guard を CI/CD パイプラインに統合する](https://aws.amazon.com/blogs/devops/integrating-aws-cloudformation-guard/)
**関連するワークショップ:**
+ [AWS Workshop - タグ付け](https://catalog.workshops.aws/tagging/)
**関連する例:**
+ [AWS Config ルール - Amazon EC2 with required tags and valid values](https://github.com/awslabs/aws-config-rules/blob/master/python/ec2_require_tags_with_valid_values.py)
**関連サービス:**
+ [AWS Config ルール - required-tags](https://docs.aws.amazon.com/config/latest/developerguide/required-tags.html)
+ [AWS Organizations](https://aws.amazon.com/organizations/)
# OPS02-BP02 プロセスと手順に特定の所有者が存在する
個々のプロセスと手順の定義を誰が所有しているか、特定のプロセスと手順が使用されている理由、およびその所有権が存在する理由を理解します。特定のプロセスと手順が使用される理由を理解することで、改善の機会を見極めることができます。
**期待される成果:** 組織において、運用タスクのための一連のプロセスと手順が明確に定義され、維持されています。プロセスと手順は一元的に保管され、チームメンバーが利用できます。プロセスと手順は、所有権が明確に割り当てられ、頻繁に更新されます。可能な場合は、スクリプト、テンプレート、オートメーションドキュメントがコードとして実装されます。
**一般的なアンチパターン:**
+ プロセスが文書化されていない。断片化されたスクリプトが、隔離されたオペレーターワークステーションに存在している場合がある。
+ スクリプトの使用方法に関する知識が一部の個人によって保持されているか、チームの知識として非公式に共有されている。
+ レガシープロセスの更新が必要であるのに、更新の所有権が不明であり、当初の作成者が既に組織を離れている。
+ プロセスとスクリプトが検出可能になっていないため、必要なとき (インシデントへの対応時など) にすぐに利用できない。
**このベストプラクティスを活用するメリット:**
+ プロセスと手順が整備されていると、ワークロードの運用努力の効果が上がります。
+ 新しいチームメンバーがより早く成果を出せるようになります。
+ インシデントを軽減するための時間が短縮されます。
+ さまざまなチームメンバー (やチーム) が同じプロセスと手順を一貫した方法で使用できます。
+ 繰り返し使用可能なプロセスを持つことで、チームがプロセスをスケールすることができます。
+ プロセスと手順が標準化されているため、チーム間でワークロードの責任を移転することの影響を軽減できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ プロセスと手順に対し、その定義に責任を持つ所有者が指定されています。
+ ワークロードのサポートにおいて実施される運用アクティビティを特定します。これらのアクティビティを検出可能な場所に文書化します。
+ アクティビティの仕様に責任を有する個人またはチームを一意に特定します。当該個人またはチームは、適切なアクセス許可、アクセス、およびツールを持つ適切なスキルのあるチームメンバーが正常に実行できるようにする責任があります。そのアクティビティの実行に問題がある場合、アクティビティの改善に必要となる詳細なフィードバックを提供する責任はそのチームメンバーにあります。
+ AWS Systems Manager などのサービス、ドキュメント、AWS Lambda を通じて、アクティビティアーティファクトのメタデータの所有権をキャプチャします。タグまたはリソースグループを使用してリソースの所有権をキャプチャし、所有権と連絡先情報を指定します。AWS Organizations を使用してタグ付けポリシーを作成し、所有権と連絡先情報をキャプチャします。
+ 時間が経つにつれて、これらの手順はコードとして実行できるように進化し、人的介入の必要が減るはずです。
+ 例えば、AWS Lambda 関数、CloudFormation テンプレート、AWS Systems Manager オートメーションのドキュメントを検討します。
+ 適切なリポジトリでバージョン管理を行います。
+ 所有者と文書を簡単に識別できるように、適切なリソースタグを付けてください。
**お客様事例**
AnyCompany Retail では、所有権を 1 つまたは (共通のアーキテクチャプラクティスとテクノロジーを共有する) 複数のアプリケーションのプロセスを所有するチームまたは個人と定義しています。最初にプロセスと手順をステップバイステップガイドとしてドキュメント管理システムに文書化し、アプリケーションをホストする AWS アカウントと、アカウント内の特定のリソースグループのタグを使用して手順を検出可能にしています。同社は AWS Organizations を活用して AWS アカウントを管理しています。時間の経過に伴い、これらのプロセスはコードに変換され、リソースは Infrastructure as Code (CloudFormation または AWS Cloud Development Kit (AWS CDK) テンプレートなど) を使用して定義されます。運用プロセスは AWS Systems Manager または AWS Lambda 関数でオートメーションドキュメントとなります。これらの関数は、スケジュールされたタスクとして、AWSCloudWatch アラームや AWS EventBridge イベントなどのイベントに応じて開始する場合や、IT サービス管理 (ITSM) プラットフォーム内の要求に応じて開始する場合があります。すべてのプロセスには、所有者を識別するタグが付いています。オートメーションとプロセスのドキュメントは、プロセスのコードリポジトリによって生成された Wiki ページ内で管理されます。
### 実装手順
1. 既存のプロセスと手順を文書化します。
1. レビューを行い、最新の状態に保ちます。
1. 各プロセスまたは手順の所有者を特定します。
1. それらをバージョン管理下に置きます。
1. 可能な場合は、アーキテクチャ設計を共有するワークロードや環境全体でプロセスと手順を共有します。
1. フィードバックと改善のためのメカニズムを確立します。
1. プロセスをレビューする頻度に関するポリシーを定義します。
1. レビュー担当者と承認者用のプロセスを定義します。
1. フィードバックを提供し、追跡するための問題やチケットキューを実装します。
1. プロセスと手順は、可能な限り、変更承認委員会 (CAB) による事前承認とリスク分類を受ける必要があります。
1. プロセスと手順は、それらを実行するユーザーがアクセスおよび検出できることを確認します。
1. タグを使用して、ワークロードのプロセスと手順にアクセスできる場所を示します。
1. 有意義なエラーやイベントのメッセージを活用して、問題に対処するための適切なプロセスまたは手順を示します。
1. Wiki とドキュメント管理を使用して、プロセスと手順を組織全体で一貫して検索できるようにします。
1. 生成 AI を活用する会話型アシスタント、[Amazon Q Business](https://aws.amazon.com/q/business/) を使用して、従業員の生産性を高め、質問に回答し、エンタープライズシステムの情報に基づいてタスクを完了します。
1. Amazon Q Business を会社のデータソースに接続します。Amazon Q Business には、Amazon S3、Microsoft SharePoint、Salesforce、Atlassian Confluence など、40 を超えるサポート対象のデータソースへの事前構築済みのコネクタが用意されています。詳細については、「[Amazon Q のコネクタ](https://aws.amazon.com/q/business/connectors/)」を参照してください。
1. 必要に応じて自動化します。
1. サービスやテクノロジーが API を提供している場合は、オートメーションを開発する必要があります。
1. プロセスに関する指導を十分に行います。これらのプロセスを自動化するためのユーザーストーリーと要件を作成します。
1. プロセスと手順の使用状況を適切に評価し、問題を提起するか、チケットを作成して反復的な改善に役立てます。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS02-BP01 リソースには特定の所有者が存在する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP04 責任と所有権を管理するためのメカニズムが存在する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
+ [OPS11-BP04 ナレッジ管理を実施する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**関連ドキュメント:**
+ [AWS ホワイトペーパー - AWS での DevOps の概要](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [AWS ホワイトペーパー - AWS リソースのタグ付けのベストプラクティス](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [AWS ホワイトペーパー - 複数のアカウントで AWS 環境を構成する](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [AWS クラウド オペレーションと移行ブログ - Using Amazon Q Business to streamline your operations](https://aws.amazon.com/blogs/mt/streamline-operations-using-amazon-q-for-business/)
+ [AWS クラウド運用および移行ブログ - クラウドオートメーションプラクティスを構築して運用上の優秀性を実現する: AWS Managed Services 提供のベストプラクティス](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [AWS クラウド運用および移行ブログ - AWS Config と AWS Organizations で自動かつ一元的なタグ付けコントロールを実装する](https://aws.amazon.com/blogs/mt/implementing-automated-and-centralized-tagging-controls-with-aws-config-and-aws-organizations/)
+ [AWS セキュリティブログ - AWS CloudFormation Guard で pre-commit フックを拡張する](https://aws.amazon.com/blogs/security/extend-your-pre-commit-hooks-with-aws-cloudformation-guard/)
+ [AWS DevOps ブログ - AWS CloudFormation Guard を CI/CD パイプラインに統合する](https://aws.amazon.com/blogs/devops/integrating-aws-cloudformation-guard/)
**関連するワークショップ:**
+ [AWS Well-Architected 運用上の優秀性ワークショップ](https://catalog.workshops.aws/well-architected-operational-excellence/en-US/)
+ [AWS Workshop - タグ付け](https://catalog.workshops.aws/tagging/)
**関連動画:**
+ [How to automate IT Operations on AWS](https://www.youtube.com/watch?v=GuWj_mlyTug)
+ [AWS re:Invent 2020 - Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [AWS re:Inforce 2022 - Automating patch management and compliance using AWS (NIS306)](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [サポートs You - Diving Deep into AWS Systems Manager](https://www.youtube.com/watch?v=xHNLNTa2xGU)
**関連サービス:**
+ [AWS Systems Manager - Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html)
+ [AWS Service Management Connector](https://aws.amazon.com/service-management-connector/)
# OPS02-BP03 パフォーマンスに責任を持つ所有者が運用アクティビティに存在する
定義されたワークロードに対して特定のアクティビティを実行する責任を持つ者と、その責任が存在する理由を理解します。運用アクティビティを実行することに責任を負うのが誰かを理解すると、アクティビティを実行する人物、結果を検証する人物、アクティビティの所有者にフィードバックを提供する人物を把握できます。
**期待される成果:**
組織において、定義されたワークロードで特定のアクティビティを実行し、そのワークロードによって生成されたイベントに対応する責任が明確に定義されています。組織は、プロセスの所有権と履行を文書化し、この情報を検出可能にしています。組織で変更があった場合は責任を見直して更新し、チームは欠点や非効率を特定するアクティビティのパフォーマンスを追跡して測定します。フィードバックメカニズムを実装して、欠点や改善を追跡し、反復的な改善をサポートします。
**一般的なアンチパターン:**
+ 責任を文書化しない。
+ 断片化されたスクリプトが、隔離されたオペレーターワークステーションに存在している。一部の個人だけがスクリプトの使用方法を知っている、またはチームの知識として非公式に参照している。
+ レガシープロセスの更新が必要であるのに、プロセスの所有者が誰かを誰も把握しておらず、当初の作成者が既に組織を離れている。
+ プロセスとスクリプトが検出可能になっていないため、必要な際 (インシデントへの対応時など) にすぐに利用できない。
**このベストプラクティスを活用するメリット:**
+ アクティビティを実行する責任を持つのは誰か、アクションが必要なときに誰に通知すべきか、アクションを実行し、結果を検証してアクティビティの所有者にフィードバックを提供するのは誰かを理解できます。
+ プロセスと手順が整備されていると、ワークロードの運用努力の効果が上がります。
+ 新しいチームメンバーがより早く成果を出せるようになります。
+ インシデントを軽減するための時間を短縮できます。
+ さまざまなチームが同じプロセスと手順を使用して、一貫した方法でタスクを実行できます。
+ 繰り返し使用可能なプロセスを持つことで、チームがプロセスをスケールすることができます。
+ プロセスと手順が標準化されているため、チーム間でワークロードの責任を移転することによる影響を軽減できます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
責任の定義を始めるには、まず責任マトリックス、プロセスと手順、ロールと責任、ツールとオートメーションなどの既存のドキュメントから始めます。文書化されたプロセスについて責任をレビューし、ディスカッションを設けます。複数のチームとレビューして、文書化されている責任とプロセスの間の不一致を特定します。提供されるサービスについてそのチームの内部顧客と話し合い、チーム間での期待事項のギャップを特定します。
相違点を分析して対処します。改善の機会を特定し、頻繁にリクエストされ、リソースを大量に消費するアクティビティを探します。こうしたアクティビティは、一般的に有力な改善候補と考えられます。改善を簡素化し標準化するためのベストプラクティス、パターン、規範ガイダンスを調べます。改善の機会を記録し、改善が完了するまで追跡します。
経時的に、これらの手順をコードとして実行できるよう変換し、人的介入の必要性を減らします。例えば、AWS Lambda 関数、CloudFormation テンプレート、または AWS Systems Manager Automation ドキュメントとして手順を開始できます。これらの手順が適切なリポジトリでバージョン管理されていることを確認し、チームが所有者とドキュメントを簡単に特定できるように適切なリソースタグを付けます。アクティビティの実行責任を文書化し、オートメーションの正常な起動と稼働、期待される成果のパフォーマンスをモニタリングします。
**お客様事例**
AnyCompany Retail では所有権を、1 つのアプリケーションまたは共通のアーキテクチャプラクティスとテクノロジーを共有する複数のアプリケーションのプロセスを所有するチームまたは個人と定義しています。同社は、最初にプロセスと手順をステップバイステップガイドとしてドキュメント管理システムに文書化しています。アプリケーションをホストする AWS アカウントと、アカウント内の特定のリソースグループのタグを使用して手順を検出可能にし、AWS Organizations を使用して AWS アカウントを管理しています。時間の経過に伴って、AnyCompany Retail はこれらのプロセスをコードに変換し、Infrastructure as Code を使用して (CloudFormation または AWS Cloud Development Kit (AWS CDK) テンプレートなどのサービスを通じて) リソースを定義します。運用プロセスは AWS Systems Manager または AWS Lambda 関数でオートメーションドキュメントとなります。これらの関数は、スケジュールされたタスクとして、Amazon CloudWatch アラームや Amazon EventBridge イベントなどのイベントへの応答として、または IT サービス管理 (ITSM) プラットフォーム内のリクエストによって起動できます。すべてのプロセスには、誰が所有者かを示すタグが付いています。チームは、プロセスのコードリポジトリによって生成された Wiki ページ内で、オートメーションとプロセスのドキュメントを管理しています。
### 実装手順
1. 既存のプロセスと手順を文書化します。
1. レビューを行い、最新の状態であることを確認します。
1. 各プロセスまたは手順に所有者がいることを確認します。
1. 手順をバージョン管理下に置きます。
1. 可能な場合は、アーキテクチャ設計を共有するワークロードや環境全体でプロセスと手順を共有します。
1. フィードバックと改善のためのメカニズムを確立します。
1. プロセスをレビューする頻度に関するポリシーを定義します。
1. レビュー担当者と承認者用のプロセスを定義します。
1. フィードバックを提供して追跡するための問題やチケットキューを実装します。
1. プロセスと手順は、可能な限り、変更承認委員会 (CAB) による事前承認とリスク分類を受けます。
1. プロセスと手順を実行する必要がある人が、これにアクセスでき、検出できるようにします。
1. タグを使用して、ワークロードのプロセスと手順にアクセスできる場所を示します。
1. 有意義なエラーやイベントのメッセージを活用して、問題に対処するための適切なプロセスや手順を示します。
1. Wiki またはドキュメント管理を使用して、プロセスと手順を組織全体で一貫して検索できるようにします。
1. 適切である場合は自動化します。
1. サービスやテクノロジーが API を提供している場合は、オートメーションを開発します。
1. プロセスが十分に理解されていることを確認し、これらのプロセスを自動化するためのユーザーストーリーと要件を作成します。
1. プロセスと手順の適切な使用を評価し、問題を追跡して反復的な改善に役立てます。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS02-BP01 リソースには特定の所有者が存在する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP02 プロセスと手順に特定の所有者が存在する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_resource_owners.html)
+ [OPS02-BP04 責任と所有権を管理するためのメカニズムが存在する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_def_responsibilities_ownership.html)
+ [OPS02-BP05 責任と所有権を特定するためのメカニズムが存在する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_find_owner.html)
+ [OPS11-BP04 ナレッジ管理を実施する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**関連ドキュメント:**
+ [AWS ホワイトペーパー \$1 AWS での DevOps の概要](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [AWS ホワイトペーパー \$1 AWS リソースのタグ付けのベストプラクティス](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)
+ [AWS ホワイトペーパー \$1 複数のアカウントで AWS 環境を構成する](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/organizing-your-aws-environment.html)
+ [AWS クラウド運用および移行ブログ \$1 クラウドオートメーションプラクティスを構築して運用上の優秀性を実現する: AWS Managed Services 提供のベストプラクティス](https://aws.amazon.com/blogs/mt/build-a-cloud-automation-practice-for-operational-excellence-best-practices-from-aws-managed-services/)
+ [AWS Workshop - タグ付け](https://catalog.workshops.aws/tagging/)
+ [AWS Service Management Connector](https://aws.amazon.com/service-management-connector/)
**関連動画:**
+ [AWS Knowledge Center Live \$1 Tagging AWS Resources](https://www.youtube.com/watch?v=MX9DaAQS15I)
+ [AWS re:Invent 2020 \$1 Automate anything with AWS Systems Manager](https://www.youtube.com/watch?v=AaI2xkW85yE)
+ [AWS re:Inforce 2022 \$1 Automating patch management and compliance using AWS (NIS306)](https://www.youtube.com/watch?v=gL3baXQJvc0)
+ [サポートs You \$1 Diving Deep into AWS Systems Manager](https://www.youtube.com/watch?v=xHNLNTa2xGU)
# OPS02-BP04 責任と所有権を管理するためのメカニズムが存在する
自分の役割の責任と、ビジネスの成果に自分がどのように貢献するかを理解することで、タスクの優先順位付けと役割が重要である理由を知ることができます。これにより、チームメンバーはニーズを認識し、適切に対応できます。チームメンバーが各自の役割を把握していると、所有権を確立し、改善の機会を特定できるとともに、影響を与える方法や適切な変更を行う方法を理解できます。
責任の所有者が明確に定められていない場合もあります。このような場合は、このギャップを解消するメカニズムを構築します。所有権の割り当て権限を持つ個人への明確なエスカレーションパスを設定するか、ニーズに対処するための計画を立てます。
**望ましい結果:** 組織内のチームには、リソース、実行するアクション、プロセス、手順との関係性を含む、明確に定義された責任があります。これらの責任は、チームの責任と目標、および他のチームの責任と一致しています。エスカレーションパスを一貫性のある検出可能な方法で文書化し、決定内容を責任マトリクス、チーム定義、Wiki ページなどのドキュメントアーティファクトに反映させます。
**一般的なアンチパターン:**
+ チームの責任が不明瞭、または明確に定義されていない。
+ チームが役割と責任を一致させていない。
+ チームが目標や目的と責任を一致させていないため、成功の測定が難しい。
+ チームメンバーの責任が、チームや広範の組織と一致しない。
+ チームが責任を最新の状態に保っていないため、チームが実行するタスクとの整合性が取れていない。
+ 責任決定のためのエスカレーションパスが定義されていない、または不明瞭である。
+ エスカレーションパスに、適時の対応を保証するシングルスレッド (専任) の所有者がいない。
+ 役割、責任、エスカレーションパスが検出可能でないため、必要なとき (インシデントへの対応時など) にすぐには利用できない。
**このベストプラクティスを活用するメリット:**
+ 責任者または所有者が誰かを理解することで、適切なチームまたはチームメンバーに連絡して、リクエストをしたり、タスクを移行したりすることができる。
+ 不作為やニーズへの未対応というリスクを低減するために、責任や所有権の割り当て権限を持つ個人を特定できる。
+ 責任範囲が明確に定義されている場合、チームメンバーの自主性と所有権が高まる。
+ 責任を理解することで、決定すべき事項、実行すべきアクション、および適切な所有者に引き渡すべきアクティビティが明確になる。
+ 何がチームの責任範囲外かをしっかりと理解しているため、放棄された責任を特定しやすくなり、明確化のためにエスカレーションできるようになる。
+ チームの混乱や緊張を防ぎ、チームがワークロードとリソースをより適切に管理できるようになる。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
チームメンバーの役割と責任を特定し、チームメンバーが自らの役割に対する期待事項を理解していることを確認します。この情報を検出可能にして、組織のメンバーが、特定のニーズについて連絡する必要があるチームまたは個人を特定できるようにします。組織が AWS での移行とモダナイズの機会活用を目指す中で、役割と責任も変わる可能性があります。チームとそのメンバーにそれぞれの責任を認識させ、こうした変化の中で各自のタスクを遂行できるように適切にトレーニングを行います。
責任と所有権を特定するためのエスカレーションを受ける役割またはチームを決定します。このチームは、決定を下すためにさまざまなステークホルダーと連携できます。ただし、意思決定プロセスの管理責任はこのチームが負います。
組織のメンバーが所有権と責任を知り、特定するために、メンバーがアクセス可能なメカニズムを提供します。こうしたメカニズムによって、特定のニーズについて誰に連絡すべきかがわかります。
**お客様事例**
AnyCompany Retail は最近、リフトアンドシフトアプローチによって、オンプレミス環境から AWS のランディングゾーンへのワークロードの移行を完了しました。同社は、運用レビューを実施して、一般的な運用タスクをどのように達成するかを検討し、既存の責任マトリックスに新しい環境での運用が反映されていることを確認しました。オンプレミスから AWS に移行したことで、ハードウェアと物理インフラストラクチャに関連するインフラストラクチャチームの責任が軽減されました。この変化により、ワークロードの運用モデルを発展させる新たな機会があることも明らかになりました。
責任の大半の特定、対処、文書化を行うと同時に、見落とされた責任や、運用体制の発展に伴って変更が必要となる可能性のある責任についてのエスカレーションパスも定義しました。ワークロード全体にわたる標準化と効率向上のための新たな機会を探るには、AWS Systems Manager などの運用ツールや、AWS Security Hub CSPM および Amazon GuardDuty などのセキュリティツールへのアクセスを提供します。AnyCompany Retail では、最初に取り組むべき改善点に基づいて、責任と戦略の見直しをまとめました。同社は、新しい働き方や技術パターンの導入に合わせて、責任マトリックスを更新しています。
### 実装手順
1. 既存のドキュメントから始めます。一般的なソースドキュメントには以下が含まれます。
1. 責任または実行責任者 (responsible)、説明責任者 (accountable)、相談先 (consulted)、報告先 (informed) (RACI) のマトリクス
1. チーム定義または Wiki ページ
1. サービスの定義とサービス内容
1. 役割または職務内容
1. 文書化された責任をレビューし、ディスカッションを設けます。
1. チームとレビューを行って、文書化された責任と、チームが通常遂行している責任との間の不一致を特定します。
1. 内部顧客が提供している可能性のあるサービスについて話し合い、チーム間での期待事項のギャップを特定します。
1. 相違点を分析して対処します。
1. 改善の機会を特定します。
1. 頻繁に発生し、リソースを大量に消費するリクエストを特定します。通常、こうしたリクエストは改善の対象となる有力候補です。
1. ベストプラクティスを参照して、パターンを理解し、規範ガイダンスに従い、改善を簡素化および標準化します。
1. 改善の機会を記録し、完了まで追跡します。
1. チームが責任の割り当てを管理および追跡する責任を負っていない場合、その責任を担うチームメンバーを指定します。
1. チームが責任の明確化を求めるためのプロセスを定義します。
1. プロセスを見直し、明確で使いやすいことを確認します。
1. 必ず誰かがエスカレーションに責任を持ち、完了まで追跡するようにします。
1. 効果を測定するための運用メトリクスを設定します。
1. フィードバックメカニズムを作成して、チームが改善の機会を強調できるようにします。
1. 定期的なレビューのメカニズムを導入します。
1. 検出とアクセスが可能な場所にドキュメントを保管します。
1. Wiki またはドキュメントポータルが一般的です。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS01-BP06 トレードオフを評価する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)
+ [OPS03-BP02 チームメンバーに、結果にリスクがあるときにアクションを実行する権限が付与されている](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_emp_take_action.html)
+ [OPS03-BP03 エスカレーションが推奨されている](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_enc_escalation.html)
+ [OPS03-BP07 チームに適正なリソースを提供する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_res_appro.html)
+ [OPS09-BP01 メトリクスを使用して業務目標と KPI を測定する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_measure_ops_goals_kpis.html)
+ [OPS09-BP03 運用メトリクスのレビューと改善の優先順位付け](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_review_ops_metrics_prioritize_improvement.html)
+ [OPS11-BP01 継続的改善のプロセスを用意する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_process_cont_imp.html)
**関連ドキュメント:**
+ [AWS ホワイトペーパー - AWS での DevOps の概要](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/automation.html)
+ [AWS Whitepaper - AWS クラウド Adoption Framework: Operations Perspective](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-operations-perspective/aws-caf-operations-perspective.html)
+ [AWS Well-Architected フレームワーク運用上の優秀性 - ワークロードレベルの運用モデルトポロジ](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model-2-by-2-representations.html)
+ [AWS 規範的ガイダンス - Building your Cloud Operating Model](https://docs.aws.amazon.com/prescriptive-guidance/latest/strategy-cloud-operating-model/welcome.html)
+ [AWS 規範的ガイダンス - Create a RACI or RASCI matrix for a cloud operating model](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/create-a-raci-or-rasci-matrix-for-a-cloud-operating-model.html)
+ [AWS クラウド運用および移行ブログ - クラウドプラットフォームチームを編成してビジネス価値を提供する](https://aws.amazon.com/blogs/mt/delivering-business-value-with-cloud-platform-teams/)
+ [AWS クラウド運用および移行ブログ - クラウド運用モデルを導入すべき理由](https://aws.amazon.com/blogs/mt/why-a-cloud-operating-model/)
+ [AWS DevOps ブログ - 組織のクラウドオペレーションをいかにモダナイズするか](https://aws.amazon.com/blogs/devops/how-organizations-are-modernizing-for-cloud-operations/)
**関連動画:**
+ [AWS Summit Online - Cloud Operating Models for Accelerated Transformation](https://www.youtube.com/watch?v=ksJ5_UdYIag)
+ [AWS re:Invent 2023 - Future-proofing cloud security: A new operating model](https://www.youtube.com/watch?v=GFcKCz1VO2I)
# OPS02-BP05 追加、変更、除外をリクエストするメカニズムが存在する
プロセス、手順、およびリソースの所有者にリクエストを送信できます。リクエストには、追加、変更、除外などがあります。このようなリクエストは変更管理プロセスを通ります。利点とリスクを評価した後、実行可能で適切であると判断されたリクエストを、十分な情報に基づいて承認します。
**期待される成果:**
+ 割り当てられた所有権に基づいて、プロセス、手順、リソースの変更をリクエストできます。
+ 変更は、メリットとリスクを検討して、熟考の上で行われます。
**一般的なアンチパターン:**
+ アプリケーションをデプロイする方法を更新しなければならないが、オペレーションチームからデプロイプロセスの変更をリクエストする方法がない。
+ ディザスタリカバリ計画を更新しなければならないが、変更のリクエスト先になる特定できる所有者がいない。
**このベストプラクティスを活用するメリット:**
+ プロセス、手順、リソースを、要件の変更に合わせて進化させることができます。
+ 所有者は十分な情報に基づいて変更時期を決定できます。
+ 変更は熟考の上で行われます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
このベストプラクティスを実装するには、プロセス、手順、リソースに対する変更のリクエストが可能である必要があります。変更管理プロセスは簡単なものでかまいません。変更管理プロセスを文書化します。
**お客様事例**
AnyCompany Retail は責任割り当て (RACI) マトリックスを使用して、プロセス、手順、リソースの変更を所有しているのが誰かを特定しています。文書化された変更管理プロセスは、簡単で従いやすいものです。RACI マトリックスとこのプロセスを使用して、誰でも変更リクエストを送信できます。
**実装手順**
1. ワークロードのプロセス、手順、リソースと、それぞれの所有者を特定します。ナレッジマネジメントシステムにそれらを記録します。
1. [OPS02-BP01 リソースには特定の所有者が存在する](ops_ops_model_def_resource_owners.md)、[OPS02-BP02 プロセスと手順に特定の所有者が存在する](ops_ops_model_def_proc_owners.md) または [OPS02-BP03 パフォーマンスに責任を持つ所有者が運用アクティビティに存在する](ops_ops_model_def_activity_owners.md) を実装していない場合は、まずそれらから始めます。
1. 組織の関係者と協力して、変更管理プロセスを作成します。このプロセスは、リソース、プロセス、手順の追加、変更、除外を対象とします。
1. [AWS Systems Manager Change Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html) は、ワークロードリソースの変更管理プラットフォームとして使用できます。
1. ナレッジマネジメントシステムに、変更管理プロセスを記録します。
**実装計画に必要な工数レベル:** 中 変更管理プロセスの作成では、組織全体の複数の関係者と協調する必要があります。
## リソース
**関連するベストプラクティス:**
+ [OPS02-BP01 リソースには特定の所有者が存在する](ops_ops_model_def_resource_owners.md) - 変更管理プロセスを構築する前に、リソースに特定された所有者が必要です。
+ [OPS02-BP02 プロセスと手順に特定の所有者が存在する](ops_ops_model_def_proc_owners.md) - 変更管理プロセスを構築する前に、プロセスに特定された所有者が必要です。
+ [OPS02-BP03 パフォーマンスに責任を持つ所有者が運用アクティビティに存在する](ops_ops_model_def_activity_owners.md) - 変更管理プロセスを構築する前に、オペレーションアクティビティに特定された所有者が必要です。
**関連ドキュメント:**
+ [AWS 規範的ガイダンス - AWS 大規模な移行のための基盤プレイブック: RACI 行列の作成](https://docs.aws.amazon.com/prescriptive-guidance/latest/large-migration-foundation-playbook/team-org.html#raci)
+ [Change Management in the Cloud Whitepaper](https://docs.aws.amazon.com/whitepapers/latest/change-management-in-the-cloud/change-management-in-the-cloud.html)
**関連サービス:**
+ [AWS Systems Manager Change Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/change-manager.html)
# OPS02-BP06 チーム間の責任は事前定義済みまたは交渉済みである
チーム間には、チームがどのように連携し、互いにサポートするかを説明する、定義済みまたは交渉済みの契約があります (応答時間、サービスレベル目標、サービスレベルアグリーメントなど)。チーム間コミュニケーションチャネルが文書化されています。チームの仕事がビジネスの成果に及ぼす影響、および他のチームや組織の成果を理解することで、タスクの優先順位付けを知り、適切に対応できるようになります。
責任と所有権が未定義または不明な場合、必要な活動をタイムリーに処理できず、これらのニーズへの対応が重複し、競合する可能性のある作業が生じるリスクがあります。
**期待される成果:**
+ チーム間の作業またはサポートに関する契約が、合意され文書化されます。
+ 相互にサポートまたは協力するチームに、コミュニケーションチャネルおよび応答時間目標が定められます。
**一般的なアンチパターン:**
+ 本稼働環境で問題が発生し、2 つの個別のチームが別個にトラブルシューティングを開始した。このサイロ化された作業のために停止時間が長くなった。
+ オペレーションチームが開発チームの支援を必要としているが、応答時間の合意がない。リクエストが後回しにされる。
**このベストプラクティスを活用するメリット:**
+ チームが相互にやり取りおよびサポートする方法を理解します。
+ 応答性の目標が周知されます。
+ コミュニケーションチャネルが明確に定義されます。
**このベストプラクティスを活用しない場合のリスクレベル:** 低
## 実装のガイダンス
このベストプラクティスを実装すると、チームが協力し合う方法についてあいまいさがなくなります。正式に合意を結ぶことで、チームの協力方法や互いにサポートする方法を体系化できます。チーム間コミュニケーションチャネルが文書化されます。
**お客様事例**
AnyCompany Retail の SRE チームは、開発チームとサービスレベルアグリーメントを結んでいます。開発チームがチケットシステムでリクエストを行う際に、15 分以内の応答を期待できます。サイトが停止した場合は、SRE チームが開発チームのサポートを受けながら調査を主導します。
**実装手順**
1. 組織全体の関係者と協力して、プロセスと手順に基づき、チーム間の契約を策定します。
1. プロセスまたは手順が 2 つのチームで共有されている場合は、チームの協力方法に関するランブックを作成します。
1. チーム間に依存関係がある場合は、リクエストについての応答 SLA を結びます。
1. 責任の所在をナレッジマネジメントシステムに文書化します。
**実装計画に必要な工数レベル: 中** チーム間に既存の契約がない場合、組織全体の関係者が合意に至るまでに工数がかかる場合があります。
## リソース
**関連するベストプラクティス:**
+ [OPS02-BP02 プロセスと手順に特定の所有者が存在する](ops_ops_model_def_proc_owners.md) - チーム間で契約を設定する前に、プロセスの所有権を特定する必要があります。
+ [OPS02-BP03 パフォーマンスに責任を持つ所有者が運用アクティビティに存在する](ops_ops_model_def_activity_owners.md) - チーム間で契約を設定する前に、運用アクティビティの所有権を特定する必要があります。
**関連ドキュメント:**
+ [AWS Executive Insights - ピザ 2 枚チームでイノベーションを促進する](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/)
+ [AWS での DevOps の概要 - 2 枚のピザチーム](https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html)
# OPS 3. 組織の文化はビジネスの成果をどのようにサポートしますか?
チームメンバーにサポートを提供することで、チームメンバーがより効果的に行動し、ビジネスの成果をサポートできるようにします。
**Topics**
+ [OPS03-BP01 エグゼクティブスポンサーシップを提供する](ops_org_culture_executive_sponsor.md)
+ [OPS03-BP02 チームメンバーに、結果にリスクがあるときにアクションを実行する権限が付与されている](ops_org_culture_team_emp_take_action.md)
+ [OPS03-BP03 エスカレーションが推奨されている](ops_org_culture_team_enc_escalation.md)
+ [OPS03-BP04 タイムリーで明確、かつ実用的なコミュニケーション](ops_org_culture_effective_comms.md)
+ [OPS03-BP05 実験の推奨](ops_org_culture_team_enc_experiment.md)
+ [OPS03-BP06 チームメンバーがスキルセットを維持、強化することができ、それが推奨されている](ops_org_culture_team_enc_learn.md)
+ [OPS03-BP07 チームに適正なリソースを提供する](ops_org_culture_team_res_appro.md)
# OPS03-BP01 エグゼクティブスポンサーシップを提供する
トップレベルでは、シニアリーダーシップがエグゼクティブスポンサーの役割を果たし、成功の評価を含め、組織の成果に対する期待と方向性を明確に策定します。スポンサーは、ベストプラクティスの採用と組織の進化を提唱し、推進します。
**期待される成果:** クラウド運用の導入、変革、最適化に取り組む組織は、期待される成果に対して明確なリーダーシップと説明責任を確立します。このような組織は、新しい成果を達成するために組織が必要とする各能力を把握し、開発のための機能チームに所有権を割り当てます。リーダーシップは積極的にこの方向性を定め、所有権を割り当て、説明責任を担い、業務を定義します。その結果、組織全体にわたって個人が準備を整え、インスピレーションを受けて、期待される目標に向かって積極的に取り組むことができます。
**一般的なアンチパターン:**
+ クラウド運用のスポンサーや計画が明確にされないまま、ワークロードのオーナーにはワークロードを AWS に移行することが義務付けられています。これにより、チームは運用能力の改善や成熟に向けて意識的に協力することがなくなっています。運用上のベストプラクティス基準が欠如しているため、チームに負担がかかり (オペレーターの労力、緊急対応、技術的負債など)、イノベーションの制約となります。
+ リーダーシップのスポンサーや戦略を提供せずに、新しいテクノロジーの導入という新しい組織全体にわたる目標が策定されました。チームによって目標の解釈が異なるため、注力すべき個所、それが重要である理由、影響の測定方法について混乱が生じます。結果として、組織はテクノロジーの導入に関する推進力を失います。
**このベストプラクティスを活用するメリット:** エグゼクティブスポンサーシップが明確にコミュニケーションをとり、ビジョン、方向性、目標を共有することで、チームメンバーは自分に何が期待されているかを理解します。リーダーが積極的に関与すると、個人とチームは定義された目標を達成するために同じ方向で集中的に尽力を開始します。この結果、組織は成功するための能力を最大限に発揮できます。成功を評価すると、成功への障壁をより適切に特定して、エグゼクティブスポンサーの介入によって対処できるようになります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
+ クラウドジャーニーのあらゆるフェーズ (移行、導入、または最適化) で成功を得るには、指名されたエグゼクティブスポンサーによるトップレベルのリーダーシップの積極的な関与が必要です。エグゼクティブスポンサーは、定義された戦略に沿ってチームの考え方、スキルセット、作業方法を調整します。
+ **理由を説明する;** 明確さを保ち、ビジョンと戦略の背後にある論理について説明します。
+ **期待値を設定する:** 進捗状況や成功の測定方法など、組織の目標を定義して公開します。
+ **目標の達成度を追跡する:** (タスクの完了だけでなく) 目標の段階的な達成度を定期的に測定します。成果が危ぶまれる場合に適切な措置を講じることができるように、結果を共有します。
+ **目標を達成するために必要なリソースを提供する:** 人とチームを集めてコラボレーションを行い、定義された成果をもたらす適切なソリューションを構築します。これにより、組織の摩擦が軽減または排除されます。
+ **チームを支援する:** チームと常にかかわり、チームのパフォーマンスと、チームに影響を与える外的要因があるかどうかを理解します。チームの進行を妨げている障害を特定します。チームのために障害に対処し、不要な負担を取り除きます。チームが外部要因の影響を受けた場合、目標を再評価し、必要に応じてターゲットを調整します。
+ **ベストプラクティスの導入を促進する:** 定量的なメリットをもたらしたベストプラクティスを認定し、その考案者と採用者を評価します。さらなる導入を推奨して、得られるメリットを拡大します。
+ **チームの進化を促す:** 継続的な改善の文化を創造し、達成した進歩と失敗から積極的に学びます。個人と組織の両者の成長と発展を奨励します。データやエピソードを利用して、ビジョンと戦略を進化させます。
**お客様事例**
AnyCompany Retail は、生成 AI による顧客体験の迅速な改革、生産性の向上、成長の加速を通じたビジネス変革の途上にあります。
### 実装手順
1. シングルスレッドリーダーシップを確立して、変革を主導し、推進する主要エグゼクティブスポンサーを割り当てます。
1. 変革のビジネス成果を明確に定義して、所有権と説明責任を割り当てます。主要エグゼクティブに重要な決定を主導して下す権限を付与します。
1. 変革戦略が非常に明確であり、エグゼクティブスポンサーから組織のあらゆるレベルに広く伝えられていることを確認します。
1. IT とクラウドイニシアチブのビジネス目標を明確に定義します。
1. IT およびクラウドトランスフォーメーションを推進するための主要なビジネスメトリクスを文書化します。
1. 戦略の一端を担うすべてのチームおよび個人に着実にビジョンを伝えます。
1. 特定のリーダー、マネージャー、個別の貢献者にどのようなメッセージを伝える必要があるかを明記したコミュニケーション計画メトリクスを作成します。このようなメッセージを発信する人またはチームを指定します。
1. コミュニケーション計画は、一貫性をもって確実に遂行します。
1. 定期的に対面式のイベントを開催して、期待される内容を明確にして管理します。
1. コミュニケーションの有効性に関するフィードバックを受け入れ、これに応じてコミュニケーションを調整し、計画を策定します。
1. コミュニケーションイベントをスケジュールして、チームが抱える課題を積極的に把握し、必要に応じて方針を修正できるような一貫性あるフィードバックループを確立します。
1. リーダーシップの視点から各イニシアチブに積極的に関与して、影響を受けるすべてのチームが達成すべき成果を理解していることを確認します。
1. 各ステータスミーティングでは、エグゼクティブスポンサーは障害となる要因を探し、設定されたメトリクス、エピソード、またはチームからのフィードバックを調べ、目標に向けた進捗状況を測定する必要があります。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS03-BP04 タイムリーで明確、かつ実用的なコミュニケーション](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_effective_comms.html)
+ [OPS11-BP01 継続的改善のプロセスを用意する](wellarchitected/latest/operational-excellence-pillar/evolve/learn_share_and_improve/ops_evolve_ops_process_cont_imp.html)
+ [OPS11-BP07 オペレーションメトリクスのレビューを実行する](wellarchitected/latest/operational-excellence-pillar/evolve/learn_share_and_improve/ops_evolve_ops_metrics_review.html)
**関連ドキュメント:**
+ [組織の毛玉をほどく: 統制をとる](https://aws.amazon.com/blogs/enterprise-strategy/untangling-your-organisational-hairball-highly-aligned/)
+ [生きている変革: 実用本位で変更にアプローチする](https://aws.amazon.com/blogs/enterprise-strategy/the-living-transformation-pragmatically-approaching-changes/)
+ [未来に対応できる企業になる](https://aws.amazon.com/blogs/enterprise-strategy/becoming-a-future-ready-enterprise/)
+ [CCOE を構築するときに避けるべき 7 つの落とし穴](https://aws.amazon.com/blogs/enterprise-strategy/7-pitfalls-to-avoid-when-building-a-ccoe/)
+ [クラウドへの道しるべ: 成功のための重要業績評価指標 (KPI) とは](https://aws.amazon.com/blogs/enterprise-strategy/navigating-the-cloud-key-performance-indicators-for-success/)
**関連動画:**
+ [AWS re:Invent 2023: A leader's guide to generative AI: Using history to shape the future (SEG204)](https://youtu.be/e3snrDsct1o)
**関連する例:**
+ [Prosci: Primary Sponsor's Role & Importance](https://www.prosci.com/blog/primary-sponsors-role-and-importance)
# OPS03-BP02 チームメンバーに、結果にリスクがあるときにアクションを実行する権限が付与されている
リーダーシップが植え付けた所有権文化の行動により、すべての従業員が、定義された役割と説明責任の範囲を超えて、会社全体のために行動する権限を与えられていると感じるようになります。従業員は、リスクが発生するに従ってプロアクティブにリスクを特定し、適切なアクションを取るように行動できます。このような文化により、従業員は状況を認識したうえで価値の高い意思決定を行うことができます。
例えば Amazon では、従業員が状況に従って前進し、問題を解決し、対立に対処し、アクションを起こすために必要な行動を推進するためのガイドラインとして、[リーダーシップ原則](https://www.amazon.jobs/content/en/our-workplace/leadership-principles)を採用しています。
**期待される成果:** リーダーシップは、組織の下位レベルであっても、個人やチームが重要な意思決定を行える新しい文化に影響を与えます (ただし、意思決定は監査可能な許可と安全メカニズムで定義する必要があります)。失敗を恐れないことが奨励され、チームは将来的に同様の状況に対処できるように、意思決定と対応を改善する方法を繰り返し学びます。その他のチームに利益をもたらすような改善につながったアクションがあれば、このようなアクションから学んだ知識を積極的に共有します。リーダーシップは、オペレーションの改善を測定し、個人や組織が同様のパターンを採用するようにインセンティブを提供します。
**一般的なアンチパターン:**
+ リスクが特定された際に対処すべき内容についての明確なガイダンスやメカニズムが組織に存在しません。例えば、従業員がフィッシング攻撃を発見したときにセキュリティチームへの報告を怠った場合、組織の大部分が攻撃を受けてしまいます。これはデータ侵害の原因となります。
+ サービスが利用できないことについて、顧客が不満を訴えています。サービスが利用できない主な原因は、デプロイの失敗です。デプロイツールは SRE チームが担当しており、デプロイの自動ロールバックは長期的なロードマップの対象となっています。最近のアプリケーションロールアウトで、エンジニアの 1 人がアプリケーションを以前のバージョンに自動的にロールバックするソリューションを考案しました。このソリューションは、SRE チームが採用するパターンとなる可能性があります。ただし、このような改善を追跡するプロセスがないため、その他のチームはこの方法を採用していません。組織は、顧客に影響を及ぼしてさらにマイナスのセンチメントを引き起こすデプロイの失敗に引き続き悩まされることになります。
+ コンプライアンス維持のため、社内の情報セキュリティチームは、Amazon EC2 Linux インスタンスに接続するオペレーターに代わって、共有 SSH キーを定期的にローテーションするプロセスを長年管理しています。情報セキュリティチームがキーローテーションを完了するまでに数日かかり、その間の対象インスタンスへの接続はブロックされます。情報セキュリティにもその他のチームにも、同様の結果を得るために AWS のその他のオプションを利用することを提案する者はいません。
**このベストプラクティスを活用するメリット: ** 意思決定を行う権限を分散し、チームが主要な意思決定を行えるようにすることで、成功率を上げ、より迅速に問題に対処できます。さらに、チームは当事者意識を持ち始め、失敗を受け入れられるようになります。実験が文化の中軸となります。マネージャーやディレクターは、業務のあらゆる面で細かく管理されているようには感じません。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
1. 失敗が起こり得ることが予想される文化を育みます。
1. 組織内のさまざまな業務領域について、明確な所有権と説明責任を定義します。
1. 所有権と説明責任を全員に伝え、分散型の意思決定を円滑に進めるうえで支援を提供する人物が誰であるかを各自が把握できるようにします。
1. 単一の方向と双方向の意思決定を定義し、より高いレベルのリーダーシップにエスカレーションする必要があるケースを各自が把握できるようにします。
1. 成果がリスクに直面した場合、すべての従業員がさまざまなレベルで対処する権限を付与されているという意識を組織全体で高めます。ガバナンス、アクセス許可レベル、ツール、機会に関するドキュメントをチームメンバーに提供して、効果的に対応するために必要なスキルを練習します。
1. さまざまな意思決定に対応するために必要なスキルを練習する機会をチームメンバーに提供します。意思決定レベルを定義したら、ゲームデーを開催して、各貢献者がプロセスを理解し、実際に実行できることを確認します。
1. プロセスと手順のテストとトレーニングを実行できる安全な代替環境を用意します。
1. 成果に既に定義されているレベルのリスクがある場合、チームメンバーにはアクションを起こす権限があるという意識を受け入れ、育みます。
1. チームメンバーがサポートするワークロードとコンポーネントにアクセス許可とアクセス権を割り当てることで、アクションを実行するチームメンバーの権限を定義します。
1. チームが学んだこと (運用上の成功と失敗) を共有できるようにします。
1. チームが現状に問題意識を持てるようにして、改善点と組織に及ぼす影響を追跡して測定するメカニズムを提供します。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS01-BP06 メリットとリスクを管理しながらトレードオフを評価する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_priorities_eval_tradeoffs.html)
+ [OPS02-BP05 責任と所有権を特定するためのメカニズムが存在する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ops_model_req_add_chg_exception.html)
**関連ドキュメント:**
+ [AWS ブログ記事 \$1 俊敏なエンタープライズ](https://aws.amazon.com/blogs/enterprise-strategy/the-agile-enterprise/)
+ [AWS ブログ記事 \$1 成功を測定する: パラドックスと計画](https://aws.amazon.com/blogs/enterprise-strategy/measuring-success-a-paradox-and-a-plan/)
+ [AWS ブログ記事 \$1 吹っ切る: チームの自律性を育む](https://aws.amazon.com/blogs/enterprise-strategy/letting-go-enabling-autonomy-in-teams/)
+ [集中化か分散化か?](https://aws.amazon.com/blogs/enterprise-strategy/centralize-or-decentralize/)
**関連動画:**
+ [re:Invent 2023 \$1 How to not sabotage your transformation (SEG201)](https://www.youtube.com/watch?v=heLvxK5N8Aw)
+ [re:Invent 2021 \$1 Amazon Builders' Library: Operational Excellence at Amazon](https://www.youtube.com/watch?v=7MrD4VSLC_w)
+ [Centralization vs. Decentralization](https://youtu.be/jviFsd4hhfE?si=fjt8avVAYxA9jF01)
**関連する例:**
+ [Using architectural decision records to streamline technical decision-making for a software development project](https://docs.aws.amazon.com/prescriptive-guidance/latest/architectural-decision-records/welcome.html)
# OPS03-BP03 エスカレーションが推奨されている
リーダーシップは、期待される成果がリスクにさらされ、期待される基準が満たされないと判断された場合にチームメンバーが問題や懸念事項を上位レベルの意思決定者やステークホルダーにエスカレーションするよう奨励します。これは組織内文化の特徴となり、あらゆるレベルで推進されます。リスクを特定し、インシデントの発生を防ぐため、エスカレーションは、早期かつ頻繁に実行する必要があります。リーダーシップは、問題をエスカレーションした個人を叱責することはありません。
**期待される成果:** 組織全体の個人は、問題を直上のリーダーシップにエスカレーションすることに慣れています。チームがいかなる問題であっても安心してエスカレーションできるはずだという期待を、リーダーシップは意図的かつ意識的に確立しています。組織内の各レベルで問題をエスカレーションするメカニズムが施行されています。従業員がマネージャーにエスカレーションする場合、影響レベルと問題をエスカレーションすべきかどうかを連携して決定します。従業員がエスカレーションを開始するには、問題に対処するための推奨される作業計画を含める必要があります。直属のリーダーシップがタイムリーにアクションを起こさない場合、組織へのリスクがエスカレーションに値すると確信する従業員は、トップレベルのリーダーシップに問題を提起するよう奨励されます。
**一般的なアンチパターン:**
+ エグゼクティブリーダーシップは、クラウドトランスフォーメーションプログラムのステータスミーティング中に、十分な質問をしておらず、問題や障害が発生している個所を発見することができません。ステータスとして良好な報告のみが提示されます。いかなる課題が提起されても、CEO はプログラムが失敗していると判断するため、良好な報告のみを発表したいと CIO が明言したためです。
+ クラウド運用エンジニアが、新しいナレッジ管理システムがアプリケーションチームによって広く採用されていないことに気づきました。この企業では、この新しいナレッジ管理システムに数百万 USD を投資し、1 年かけて実装しました。しかし、チームは依然としてランブックをローカルで作成し、組織のクラウド共有で共有しているため、サポートされているワークロードに関連するナレッジを検索するのが困難となっています。このシステムを継続的に使用することで業務効率を向上できるため、クラウド運用エンジニアは、この件についてリーダーシップに報告しようとします。ナレッジ管理システムの実装を主導するディレクターにこの件について伝えたところ、この報告により投資が問題視されるという理由で、ディレクターはクラウド運用エンジニアを叱責します。
+ コンピューティングリソースの強化を担当する情報セキュリティチームは、リソースを本番環境でリリースする前に、EC2 インスタンスが完全に保護されていることを確認するために必要となるスキャンをコンピューティングチームが実行する必要があるプロセスを導入することを決定しました。これにより、リソースのデプロイがこれまでより 1 週間遅延し、SLA に違反することになります。コンピューティングチームは、情報セキュリティ担当 VP の評判が悪くなることを懸念して、この問題についてクラウド担当の VP にエスカレーションすることを躊躇しています。
**このベストプラクティスを活用するメリット:**
複雑な問題や重大な問題が、ビジネスに影響を及ぼす前に対処されます。無駄な時間が低減します。リスクが最小限に抑えられます。問題を解決する際、チームがより積極的になり、結果を重視するようになります。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
組織のあらゆるレベルで自由にエスカレーションする意欲と能力は、組織と文化の基盤であり、重点的なトレーニング、リーダーシップのコミュニケーション、期待値設定、組織全体のあらゆるレベルでのメカニズムのデプロイを通じて、意識的に発展させる必要があります。
### 実装手順
1. 組織のポリシー、基準、期待される内容を定義します。
1. ポリシー、期待される内容、基準を幅広く採用し、理解されていることを確認します。
1. 基準が満たされない場合、早期かつ頻繁にエスカレーションを行うよう従業員を奨励し、トレーニングを行い、権限を付与します。
1. 早期かつ頻繁にエスカレーションすることがベストプラクティスであるという組織的な認識を確立します。エスカレーションした内容が事実ではないと判明する場合があること、およびエスカレーションしないことによってインシデントを阻止する機会を逃すよりもインシデントを阻止する機会が得られる方が好ましいということを受け入れます。
1. エスカレーションのメカニズムを構築します (Andon コードシステムなど)。
1. エスカレーションをいつどのように行うかを定義する手順を文書化します。
1. アクションを実行または承認する人々を権限順に定義します。また、各ステークホルダーの連絡先の情報も追加します。
1. エスカレーションが行われた場合、リーダーシップが促進する一連のアクションによりリスクが軽減されたとチームメンバーが認めるまで、エスカレーションを続行する必要があります。
1. エスカレーションには以下を含める必要があります。
1. 状況およびリスクの性質の説明
1. 状況の重要度
1. 影響が及ぶ人々や事項
1. 影響の規模
1. 影響が発生した場合の緊急性
1. 推奨される救済策と緩和計画
1. エスカレーションする従業員を保護します。対処を行わない意思決定者やステークホルダーを避けてエスカレーションしたチームメンバーを報復行為から保護するポリシーを施行します。これが発生しているかどうかを特定し、適切に対応するメカニズムを備えます。
1. 組織が生み出すすべてのものに、継続的な改善のフィードバックループを取り入れる文化を奨励します。フィードバックループは責任者への軽微なエスカレーションとして機能し、エスカレーションが必要ない場合でも改善の機会を特定できます。継続的な改善の文化は、誰もがより積極的に行動することを押し進めます。
1. リーダーシップは、ポリシー、基準、メカニズム、報復されることのないオープンなエスカレーションと継続的なフィードバックループを奨励することを定期的に繰り返し強調すべきです。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS02-BP05 追加、変更、除外をリクエストするメカニズムが存在する](ops_ops_model_req_add_chg_exception.md)
**関連ドキュメント:**
+ [How do you foster a culture of continuous improvement and learning from Andon and escalation systems?](https://www.linkedin.com/advice/0/how-do-you-foster-culture-continuous-improvement-7054190310033145857)
+ [The Andon Cord (IT Revolution)](https://itrevolution.com/articles/kata/)
+ [AWS DevOps ガイダンス \$1 明確なエスカレーションパスを確立し建設的な反対意見を奨励する](https://docs.aws.amazon.com/wellarchitected/latest/devops-guidance/oa.bcl.5-establish-clear-escalation-paths-and-encourage-constructive-disagreement.html)
**関連動画:**
+ [Jeff Bezos on how to make decisions (& increase velocity)](https://www.youtube.com/watch?v=VFwCGECvq4I)
+ [【トヨタ生産方式】自働化: 異常が発生したらまず止める「呼び出しボタンとアンドン」](https://youtu.be/TUKpxjAftnk?si=qohtCCX0q78GDzJu)
+ [Andon Cord in LEAN Manufacturing](https://youtu.be/HshopyQk720?si=1XJkpCSqJSpk_zE6)
**関連する例:**
+ [Working with escalation plans in Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/escalation.html)
# OPS03-BP04 タイムリーで明確、かつ実用的なコミュニケーション
リーダーシップには、特に組織が新しい戦略、テクノロジー、または働き方を採用する場合、強力かつ効果的なコミュニケーションを創出する責任があります。リーダーシップは、スタッフ全員が企業の目標を目指して業務を行えるように、期待するものを明らかにする必要があります。リーダーシップが資金を提供し、スポンサーとなっている計画の実施を担当するチームにおける意識を向上し、維持するためのコミュニケーションメカニズムを考案します。組織間の多様性を活用して、複数の独自の視点での意見に注意深く耳を傾けます。この視点を使用して、イノベーションを高め、想定に挑み、確証バイアスに傾くリスクを軽減します。有益な視点が得られるように、チーム内でのインクルージョン、多様性、アクセシビリティを向上します。
**期待される成果:** 組織は、組織への変化の影響に対処するためのコミュニケーション戦略を設計します。チームには常に情報が提供され、反目し合うのではなく、相互に協力し合う意欲があります。個人は、明文化された目標を達成するうえで、自身の役割がいかに重要であるかを理解しています。E メールは受動的な通信手段に過ぎません。この点を踏まえて使用します。経営陣は、個別の貢献者と話す時間を取り、各自の責任や完了すべきタスク、担当業務がミッション全体にどのように貢献するのかを理解してもらいます。リーダーシップは必要に応じて、小規模な場所で直接従業員とのエンゲージメントの機会を持ち、メッセージを伝え、メッセージが効果的に伝わっていることを確認します。優れたコミュニケーション戦略があれば、組織はリーダーシップの期待と同等かそれ以上の成果を上げることができます。リーダーシップは、チーム内およびチーム間で多様な意見を出すことを奨励し、多様な意見を求めます。
**一般的なアンチパターン:**
+ 組織には、すべてのワークロードを AWS に移行する 5 か年計画があります。クラウドのビジネスケースには、すべてのワークロードの 25% をモダナイズしてサーバーレステクノロジーを活用することが含まれています。CIO は、この戦略を直属部下に伝え、各リーダーが対面でのコミュニケーションなしにマネージャー、ディレクター、個別の貢献者にこのプレゼンテーションを伝達することを期待しています。CIO は現場に関与せず、この組織で新しい戦略が実行されることを期待しています。
+ リーダーシップはフィードバックの仕組みを提供したり、利用したりすることはなく、期待のギャップが広がり、プロジェクトが行き詰まってしまいます。
+ セキュリティグループに変更を加えるよう求められますが、どのような変更が必要か、変更がすべてのワークロードにどのような影響を及ぼす可能性があるか、いつ実行すべきかについての詳細は提供されていません。マネージャーは、情報セキュリティの VP からの E メールに、「これを実行すること」と付け加えて転送しています。
+ 移行戦略に変更が加えられ、計画されているモダナイゼーションの件数が 25% から 10% に低減しました。これはオペレーション組織の下流に影響を及ぼします。この戦略的変更についての知らせはなかったため、AWS にリフトアンドシフトするワークロード数の増加分をサポートするのに十分なスキルを備えたリソースの準備が整っていません。
**このベストプラクティスを活用するメリット:**
+ 組織は、新しい戦略や変更された戦略について十分な情報を得ており、リーダーシップが設定した全体的な目標とメトリクスを相互に支援して達成するうえで、高いやる気を持って行動します。
+ メカニズムが存在し、 チームメンバーに既知のリスクや計画されたイベントをタイムリーに通知するために使用されます。
+ 必要なスキルとともに、新しい働き方 (人、組織、プロセス、またはテクノロジーの変更を含む) を採用することで、より効果的に組織に導入でき、組織はビジネス上の利点をより迅速に実現できるようになります。
+ チームメンバーは、受けとったコミュニケーションについて必要なコンテキストを把握できるため、より効果的に業務を進めることができます。
**このベストプラクティスを活用しない場合のリスクレベル:** 高
## 実装のガイダンス
このベストプラクティスを実装するには、組織全体の関係者と協力して、コミュニケーション基準に関して合意を得る必要があります。この基準を、組織の誰もが確認できるようにします。大規模な IT 移行の場合、このようなベストプラクティスを考慮に入れない組織よりも、確立されたプランニングチームの方が、変更による従業員への影響をうまく管理できます。大規模な組織では、新しい戦略に対する個別の貢献者全員の強い賛同を得ることが重要となるため、変更管理がより困難になる可能性があります。このような移行プランニングチームを設置しない場合、効果的なコミュニケーションはリーダーシップが 100% 責任を負うことになります。移行プラニングチームを設立する際は、すべての組織のリーダーと協力し、あらゆるレベルにおける効果的なコミュニケーションを定義して、管理するチームメンバーを割り当てます。
**お客様事例**
AnyCompany Retail は、AWS エンタープライズサポートにサインアップして、クラウド運用は別のサードパーティープロバイダーに依存しています。同社は、業務活動の主要なコミュニケーション媒体としてチャットと ChatOps を利用しています。アラートやその他の情報は特定のチャネルに入力されます。誰かのアクションが必要な場合、期待される成果が明確に提示され、多くの場合、使用するランブックまたはプレイブックが指定されます。本稼働システムへの主要な変更については、変更カレンダーを使用してスケジュールしています。
### 実装手順
1. 組織内の複数のレベルで発生する変化に対するコミュニケーション計画を策定し、着手する責任を担うコアチームを組織内に設立します。
1. シングルスレッドの所有権を導入して、監督体制を実現します。個別のチームが独自にイノベーションを生むことができる体制を整え、一貫性あるメカニズムをバランスよく使用できるようにすることで、適切なレベルの検査と方向性を提示するビジョンを実現できます。
1. 組織全体にわたる関係者と協力して、コミュニケーションの基準、慣行、計画への合意を取り付けます。
1. コアコミュニケーションチームが組織リーダーやプログラムリーダーと協力して、リーダーの代理として適切なスタッフへのメッセージを作成していることを確認します。
1. 告知、共有カレンダー、全員参加のミーティング、対面または 1 対 1 の方法で変更を管理するための戦略的コミュニケーションメカニズムを構築し、自身が取るべき行動についての適切な期待をチームメンバーが把握するようにします。
1. 対処が必要かを判断するために、必要となる状況、詳細、時間 (可能な場合) を提供します。アクションが必要な場合は、必要なアクションとその影響を提供します。
1. 社内チャット、E メール、ナレッジ管理など、戦術的なコミュニケーションを促進するツールを導入します。
1. すべてのコミュニケーションが期待される成果につながっているかを測定して検証するメカニズムを実装します。
1. すべてのコミュニケーションの有効性を測定するフィードバックループを確立します。特に、コミュニケーションが組織全体の変化に対する抵抗に関連する場合に、これは重要です。
1. すべての AWS アカウントについて、請求、セキュリティ、オペレーション用の[代替連絡先](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-update-contact-alternate.html)を設定します。理想的には、各連絡先は特定の個人の連絡先ではなく、E メールの配布リストであるべきです。
1. AWS サポートやその他のサードパーティープロバイダーなどの社内チームおよび社外チームと連携するために、エスカレーションとリバースエスカレーションのコミュニケーション計画を策定します。
1. 各トランスフォーメーションプログラムの全期間にわたり、一貫性あるコミュニケーション戦略を開始し、実行します。
1. 繰り返し可能なアクションを可能な限り優先し、大規模かつ安全に自動化します。
1. アクションが自動化されているシナリオでコミュニケーションが必要な場合、コミュニケーションの目的はチームへの情報提供、監査、または変更管理プロセスの一部であるべきです。
1. アラートシステムからの通信を分析して、誤検出や絶えず発生するアラートがないかを調べます。このようなアラートを削除したり変更したりして、人の介入が必要な際に起動されるようにします。アラートが起動した場合は、ランブックまたはプレイブックを指定します。
1. アラート用のプレイブックとランブックの作成には、[AWS Systems Manager ドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html)を使用できます。
1. リスクや計画されたイベントの通知を明確かつ実用的な方法で提供し、適切な対応を可能にするのに十分な通知を提供するメカニズムが設けられています。計画されたイベントに先立ち、E メールリストまたはチャットチャネルを使用して、通知を送信します。
1. [AWS Chatbot](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html) を使用すると、アラートを送信したり、組織のメッセージプラットフォーム内のイベントに応答したりできます。
1. 計画されたイベントを知ることができる、アクセス可能な情報ソースを提供します。同じシステムから計画されたイベントを通知します。
1. [AWS Systems Manager Change Calendar](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html) を使用すると、変更を実行できる変更ウィンドウを作成できます。これにより、チームメンバーは安全に変更を行うことができるタイミングを知ることができます。
1. 脆弱性の通知とパッチ情報をモニタして、ワークロードコンポーネントに関連する予期できない潜在的なリスクの脆弱性を理解します。チームメンバーが対応できるように通知を送信します。
1. [AWS セキュリティ速報](https://aws.amazon.com/security/security-bulletins/)を購読すれば、AWS 上の脆弱性に関する通知がお手元に届きます。
1. **多様な意見や視点を求める:** すべてのメンバーからの貢献を求めます。取り上げられることの少ないグループにコミュニケーションの機会を与えます。ミーティングでは、役割と責任の割り当てを定期的に変更します。
1. **役割と責任を拡張する:** チームメンバーが通常引き受けることのないであろう役割を引き受ける機会を提供します。チームメンバーは、このようなロールから、また、通常はやり取りしない新しいチームメンバーとのやり取りから、経験や視点を得ることができます。チームメンバーはまた、自身が得た経験と視点を、やり取りをする新しいロールやチームメンバーに提供することができます。視野が広がるにつれて、新たなビジネスチャンスや新たな改善機会を見極めます。チーム内のメンバーに、その他のメンバーが通常実行している日常的なタスクを交替で担当してもらい、このようなタスクを実行する需要と影響を理解してもらいます。
1. **安全かつ安心できる環境を提供する:** 組織内のチームメンバーの、精神的、身体的安全を確保するポリシーと統制を実施します。チームメンバーは、報復を恐れずにやり取りできる必要があります。チームメンバーが安全で安心できると、エンゲージメントと生産性が向上する可能性が高くなります。組織の多様化が進むと、お客様を含め、サポート対象への理解が深まります。チームのメンバーが安心して自由に意見を出し、話を聞いてもらえることを確信すると、貴重なインサイトを共有する可能性が高まります (マーケティングのオポチュニティ、アクセシビリティのニーズ、未開拓の市場セグメント、環境内の認識されていないリスクなど)。
1. **チームメンバーが完全に参加できるようにする:** 従業員がすべての業務関連活動に完全に参加するために必要なリソースを提供します。日々の課題に直面するチームメンバーは、このような課題を回避するうえでのスキルを身に付けています。このように独自に開発したスキルは、組織に大きな利点をもたらします。必要な調整を行いながらチームメンバーをサポートすることで、メンバーの貢献から得られる利点が拡大します。
## リソース
**関連するベストプラクティス:**
+ [OPS03-BP01 エグゼクティブスポンサーシップを提供する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_executive_sponsor.html)
+ [OPS07-BP03 ランブックを使用して手順を実行する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_runbooks.html)
+ [OPS07-BP04 プレイブックを使用して問題を調査する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_ready_to_support_use_playbooks.html)
**関連ドキュメント:**
+ [AWS Blog post \$1 Accountability and empowerment are key to high-performing agile organizations](https://aws.amazon.com/blogs/enterprise-strategy/two-pizza-teams-are-just-the-start-accountability-and-empowerment-are-key-to-high-performing-agile-organizations-part-2/)
+ [AWS Executive Insights \$1 複雑さではなくイノベーションの拡大を学ぶ \$1 シングルスレッドリーダー](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/#Single-Threaded_Leaders)
+ [AWS セキュリティ速報](https://aws.amazon.com/security/security-bulletins)
+ [OpenCVE](https://www.opencve.io/welcome)
+ [サポート App in Slack でサポートケースを管理する](https://aws.amazon.com/blogs/aws/new-aws-support-app-in-slack-to-manage-support-cases/)
+ [Amazon Q Developer in chat applications を使用して Slack チャネルの AWS リソースを管理する](https://aws.amazon.com/blogs/mt/manage-aws-resources-in-your-slack-channels-with-aws-chatbot/)
**関連サービス:**
+ [Amazon Q Developer in chat applications](https://docs.aws.amazon.com/chatbot/latest/adminguide/what-is.html)
+ [AWS Systems Manager Change Calendar](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html)
+ [AWS Systems Manager のドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-ssm-docs.html)
# OPS03-BP05 実験の推奨
実験は、新しいアイデアを製品や機能に変える触媒となります。実験は、学習を加速し、チームメンバーが関心と当事者意識を持ち続けることの一助となります。イノベーションを促進するために、チームメンバーは頻繁に実験することが奨励されます。結果が思わしくないものであっても、何をすべきでないかを知ることに価値があります。実験が成功したものの望ましくない結果が得られた場合、チームメンバーが罰せられることはありません。
**期待される成果:**
+ イノベーションを育むために、組織では実験が奨励されます。
+ 実験は学びの機会として使用されます。
**一般的なアンチパターン:**
+ A/B テストを実行したいが、実験を実行する仕組みがない。テストを行うことができないまま UI の変更をデプロイした。その結果、カスタマーエクスペリエンスが低下した。
+ 会社にはステージ環境と本稼働環境しかない。新機能や新製品を実験するサンドボックス環境がないため、本稼働環境で実験を行わなければならない。
**このベストプラクティスを活用するメリット:**
+ 実験はイノベーションを促進します。
+ 実験を通して、ユーザーからのフィードバックにより迅速に対応できます。
+ 組織に学習の文化が築かれます。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
実験は安全な方法で実行する必要があります。複数の環境を活用して、本稼働リソースを危険に晒すことなく、実験を行います。A/B テストや機能フラグを使用して、実験をテストします。チームメンバーがサンドボックス環境で実験を行えるようにします。
**お客様事例**
AnyCompany Retail では実験が奨励されています。チームメンバーは週の仕事の 20% を実験や新技術の学習に使用できます。サンドボックス環境があり、イノベーションを行うことができます。新機能には A/B テストが使用され、実際のユーザーのフィードバックを使用して機能を検証します。
**実装手順**
1. 組織全体でリーダーたちと協力して実験をサポートしてもらいます。チームメンバーは安全な方法で実験を行うことが奨励されます。
1. チームメンバーに、安全に実験できる環境を提供します。チームメンバーが本稼働環境に似た環境にアクセスできるようにする必要があります。
1. 別の AWS アカウントを使用して、実験用のサンドボックス環境を作成できます。[AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) を使用して、これらのアカウントをプロビジョニングできます。
1. 機能フラグや A/B テストを使用して安全に実験を行い、ユーザーからのフィードバックを収集します。
1. [AWS AppConfig 機能フラグ](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html)は、機能フラグを作成する機能を提供します。
1. [AWS Lambda バージョン](https://docs.aws.amazon.com/lambda/latest/dg/configuration-versions.html)を使用して、ベータテスト用に機能の新しいバージョンをデプロイできます。
**実装計画に必要な工数レベル:** 高。安全な方法で実験できる環境をチームメンバーに提供し実験を行うには、多額の投資が必要です。また、機能フラグを使用したり A/B テストをサポートしたりするために、アプリケーションコードの変更が必要になる場合があります。
## リソース
**関連するベストプラクティス:**
+ [OPS11-BP02 インシデント後の分析を実行する](ops_evolve_ops_perform_rca_process.md) - インシデントから学ぶことは、実験と共にイノベーションの重要な推進要因です。
+ [OPS11-BP03 フィードバックループを実装する](ops_evolve_ops_feedback_loops.md) - フィードバックループは実験の重要な部分です。
**関連ドキュメント:**
+ [内部から見たアマゾン文化:実験、失敗、そしてカスタマーオブセッション](https://aws.amazon.com/blogs/industries/an-inside-look-at-the-amazon-culture-experimentation-failure-and-customer-obsession/)
+ [Best practices for creating and managing sandbox accounts in AWS](https://aws.amazon.com/blogs/mt/best-practices-creating-managing-sandbox-accounts-aws/)
+ [Create a Culture of Experimentation Enabled by the Cloud](https://aws.amazon.com/blogs/enterprise-strategy/create-a-culture-of-experimentation-enabled-by-the-cloud/)
+ [Enabling experimentation and innovation in the cloud at SulAmérica Seguros](https://aws.amazon.com/blogs/mt/enabling-experimentation-and-innovation-in-the-cloud-at-sulamerica-seguros/)
+ [Experiment More, Fail Less](https://aws.amazon.com/blogs/enterprise-strategy/experiment-more-fail-less/)
+ [複数のアカウントで AWS 環境を構成する - サンドボックス OU](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/sandbox-ou.html)
+ [Using AWS AppConfig Feature Flags](https://aws.amazon.com/blogs/mt/using-aws-appconfig-feature-flags/)
**関連動画:**
+ [AWS On Air ft. Amazon CloudWatch Evidently \$1 AWS Events](https://www.youtube.com/watch?v=ydX7lRNKAOo)
+ [AWS On Air San Fran Summit 2022 ft. AWS AppConfig Feature Flags integration with Jira](https://www.youtube.com/watch?v=miAkZPtjqHg)
+ [AWS re:Invent 2022 - A deployment is not a release: Control your launches w/feature flags (BOA305-R)](https://www.youtube.com/watch?v=uouw9QxVrE8)
+ [Programmatically Create an AWS アカウント with AWS Control Tower](https://www.youtube.com/watch?v=LxxQTPdSFgw)
+ [Set Up a Multi-Account AWS Environment that Uses Best Practices for AWS Organizations](https://www.youtube.com/watch?v=uOrq8ZUuaAQ)
**関連する例:**
+ [AWS Innovation Sandbox](https://aws.amazon.com/solutions/implementations/aws-innovation-sandbox/)
+ [End-to-end Personalization 101 for E-Commerce](https://catalog.workshops.aws/personalize-101-ecommerce/en-US/labs/ab-testing)
**関連サービス:**
+ [Amazon CloudWatch Evidently](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Evidently.html)
+ [AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html)
+ [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html)
# OPS03-BP06 チームメンバーがスキルセットを維持、強化することができ、それが推奨されている
チームは、ワークロードに対応するに際して、新しいテクノロジーを採用し、需要と責任の変化をサポートするために、スキルセットを強化する必要があります。新しいテクノロジーにおけるスキルの発達は、多くの場合、チームメンバーの満足度の源となり、イノベーションをサポートします。チームメンバーが磨いているスキルを検証し、認識するような業界認証を取得し、維持できるように支援します。組織の知識とスキルを持ち、熟練したチームメンバーを失った場合は、クロストレーニングによって知識の伝達を促進し、重大な影響のリスクを緩和します。学習のために専用の時間を割り当てます。
AWS は、[AWS ご利用開始のためのリソースセンター](https://aws.amazon.com/getting-started/)、[AWS ブログ](https://aws.amazon.com/blogs/)、[AWS オンラインテックトーク](https://aws.amazon.com/getting-started/)、[AWS のイベントとウェビナー](https://aws.amazon.com/events/)、[AWS Well-Architected ラボ](https://wellarchitectedlabs.com/)などのリソースを提供し、チームを教育するためのガイダンス、例、詳細なウォークスルーを提供します。
[サポート](https://aws.amazon.com/premiumsupport/programs/)、[AWS re:Post](https://repost.aws/)、[サポートセンター](https://console.aws.amazon.com/support/home/)、[AWS ドキュメント](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)などのリソースは、技術的な課題を解決し、運用を改善するのに役立ちます。不明な点があれば、サポートセンター経由で サポートまでお問い合わせください。
AWS は、AWS のオペレーションを通じて学習したベストプラクティスとパターンを [Amazon Builders' Library](https://aws.amazon.com/builders-library/) で公開しています。また、[AWS ブログ](https://aws.amazon.com/blogs/)と[公式 AWS ポッドキャスト](https://aws.amazon.com/podcasts/aws-podcast/)でさまざまな有用な教育資料も公開します。
[AWS トレーニング および 認定](https://aws.amazon.com/training/)には、セルフペースデジタルコースによる無料トレーニングと、ロールまたはドメイン別の学習プランが含まれます。また、インストラクターが実施するトレーニングに登録して、チームの AWS スキルの開発をさらにサポートすることもできます。
**望ましい結果:** 組織はスキルギャップを常に評価し、構造化された予算と投資でそれらを解決します。チームでは、業界をリードする認定資格の取得などのスキルアップのアクティビティを行うようにメンバーを奨励しています。チームは、ランチアンドラーン、Immersion Days、ハッカソン、ゲームデーなど、専用の相互共有ナレッジプログラムを活用します。組織のナレッジシステムを常に最新の状態に維持し、新入社員のオンボーディングトレーニングなど、クロストレーニングチームメンバーとの関連性を維持します。
**一般的なアンチパターン:**
+ 体系的なトレーニングプログラムと予算がなく、チームはテクノロジーの進化に遅れずに対応しようとする際に不安を感じるため、離職率が増大します。
+ AWS への移行の取り組みの中で、組織のチーム間でスキルギャップやクラウド知識のレベルの違いがあることが判明します。スキルアップに向けた取り組みを行わなければ、チームはレガシーで非効率的なクラウド環境の管理に追われ、オペレーターの労力が増大することになります。このような燃え尽き症候群は従業員の不満を増大します。
**このベストプラクティスを活用するメリット:** 組織がチームのスキル向上に意識的に投資すると、クラウドの導入と最適化を加速し、スケールするのにも役立ちます。対象を絞った学習プログラムはイノベーションを促進し、チームがイベントを処理する準備を整えるうえでの運用能力を向上します。チームはベストプラクティスの実装と発展に意識的に投資します。チームのやる気は高く、チームメンバーはビジネスへの貢献を重要視しています。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
新しいテクノロジーを導入し、イノベーションを促進して、需要と職務の変化に対応してワークロードをサポートするために、チームのプロフェッショナルとしての成長に継続的に投資します。
### 実装手順
1. **構造化されたクラウドアドボカシープログラムを使用する:** [AWS Skills Guild](https://aws.amazon.com/training/teams/aws-skills-guild/) は、クラウドスキルの自信を高め、継続学習の文化を誘発するコンサルティングトレーニングを提供します。
1. **教育のためのリソースを提供する:** 計画された専用の時間、トレーニング資料やラボリソースへのアクセス、カンファレンスや専門家組織への参加のサポートにより、教育者と同僚の両方から学習する機会を得られます。上級チームのメンバーを下級チームのメンバーのメンターとして交流できるようにしたり、上級チームのメンバーの業務を下級チームのメンバーがシャドーイングして、手法やスキルを学ぶ機会を提供したりします。より広い視点を持つために、仕事に直接関係しないコンテンツについて学習することを奨励します。
1. **高度な技術リソースの使用を奨励する:** [AWS re:Post](https://repost.aws/) などのリソースを活用して、厳選された知識や交流が活発なコミュニティにアクセスできます。
1. **最新のナレッジリポジトリを構築して維持する:** Wiki やランブックなどのナレッジ共有プラットフォームを使用します。[AWS re:Post Private](https://aws.amazon.com/repost-private/) を使用して独自の再利用可能なエキスパートナレッジソースを作成し、コラボレーションを合理化し、生産性を向上させ、従業員のオンボーディングを高速化します。
1. **チーム教育とチーム間のエンゲージメントを実施する:** チームメンバーの継続的な教育のニーズに合った計画を立てます。チームメンバーが他のチームに (一時的または永続的に) 参加し、組織全体に役立つスキルやベストプラクティスを共有する機会を提供します。
1. **業界認証の追求と維持をサポートする:** チームメンバーが学んだことを検証し、その成果を認める業界認証を取得および維持するのをサポートします。
**実装計画に必要な工数レベル:** 高
## リソース
**関連するベストプラクティス:**
+ [OPS03-BP01 エグゼクティブスポンサーシップを提供する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_executive_sponsor.html)
+ [OPS11-BP04 ナレッジ管理を実施する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_evolve_ops_knowledge_management.html)
**関連ドキュメント:**
+ [AWS Whitepaper \$1 Cloud Adoption Framework: People Perspective](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-people-perspective/aws-caf-people-perspective.html)
+ [Investing in continuous learning to grow your organization's future](https://aws.amazon.com/blogs/publicsector/investing-continuous-learning-grow-organizations-future/)
+ [AWS Skills Guild](https://aws.amazon.com/training/teams/aws-skills-guild/)
+ [AWS トレーニング と認定](https://aws.amazon.com/training/)
+ [サポート](https://aws.amazon.com/premiumsupport/programs/)
+ [AWS re:Post](https://repost.aws/)
+ [AWS ご利用開始のためのリソースセンター](https://aws.amazon.com/getting-started/)
+ [AWSブログ](https://aws.amazon.com/blogs/)
+ [AWS クラウド コンプライアンス](https://aws.amazon.com/compliance/)
+ [AWS ドキュメント](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)
+ [The Official AWS Podcast](https://aws.amazon.com/podcasts/aws-podcast/)
+ [AWS オンライン技術トーク](https://aws.amazon.com/getting-started/)
+ [AWS イベントスケジュール](https://aws.amazon.com/events/)
+ [AWS Well-Architected Labs](https://wellarchitectedlabs.com/)
+ [Amazon Builders' Library](https://aws.amazon.com/builders-library/)
**関連動画:**
+ [AWS re:Invent 2023 \$1 Reskilling at the speed of cloud: Turning employees into entrepreneurs](https://www.youtube.com/watch?v=Ax7JqIDIXEY)
+ [WS re:Invent 2023 \$1 Building a culture of curiosity through gamification](https://www.youtube.com/watch?v=EqWvSBAmD3w)
# OPS03-BP07 チームに適正なリソースを提供する
適切な数の熟練したチームメンバーを配置し、ワークロードのニーズをサポートするツールとリソースを提供します。チームメンバーの負担が過剰な場合、ヒューマンエラーのリスクが増大します。オートメーションなどのツールやリソースへの投資を通じてチームの効率を向上すると、リソースを追加する必要なく、より多くのワークロードに対応できるようになります。
**期待される成果:**
+ 移行計画に従って AWS ワークロードを運用するために必要なスキルセットを習得できるように、チームに適切な人員を配置しています。移行プロジェクトの過程でチームがスケールアップするにつれ、チームはアプリケーション移行やモダナイズの際に企業が使用する予定の AWS のコアテクノロジーに習熟するようになりました。
+ オートメーションとワークフローを活用してリソースを効率的に使用できるように、人員配置計画を慎重に調整しています。少人数のチームでも、アプリケーション開発チームの代理で、より多くのインフラストラクチャを管理できるようになりました。
+ 業務上の優先順位が変化しても、ビジネスイニシアチブの成功を守るために、人員配置の制約が事前に特定されます。
+ 業務上の労力 (オンコールの疲労や過剰な呼び出しなど) を報告するオペレーションメトリクスの見直しを行い、スタッフに負担がかからないことを確認します。
**一般的なアンチパターン:**
+ 複数年にわたるクラウド移行計画が間近に迫っているのにもかかわらず、スタッフの AWS スキルは向上していません。このため、ワークロードのサポートがリスクにさらされ、従業員の士気が低下しています。
+ IT 組織全体がアジャイルな働き方にシフトしています。ビジネス部門は、製品ポートフォリオに優先順位を付け、どの機能を最初に開発する必要があるかについてのメトリクスを設定しています。アジャイルプロセスでは、チームが作業計画にストーリーポイントを割り当てる必要はありません。この結果、以降の労力に必要となるキャパシティレベルを把握することも、そのタスクに適切なスキルが割り当てられているかを判断することができません。
+ AWS パートナーにワークロードを移行してもらっていますが、パートナーが移行プロジェクトを完了した後のチームのサポートの移行計画が策定されていません。チームはワークロードを効率的かつ効果的にサポートするのに苦労しています。
**このベストプラクティスを活用するメリット:** 適切なスキルを持つ、ワークロードをサポートするチームメンバーが組織内にいます。リソースの割り当ては、パフォーマンスに影響を及ぼすことなく、優先順位の変化に適応できます。その結果、チームは顧客向けのイノベーションに集中する時間を最大限に活用しながら、ワークロードのサポートに習熟できるようになり、これが従業員の満足度の向上につながります。
**このベストプラクティスを活用しない場合のリスクレベル:** 中
## 実装のガイダンス
クラウド移行のためのリソース計画および実装する予定の運用モデルは、移行計画に沿った組織レベルで行う必要があります。新しいクラウド環境をサポートするために実装される望ましい運用モデルも同様です。これには、ビジネスチームとアプリケーション開発チームにどのクラウドテクノロジーがデプロイされるかを把握することも含まれている必要があります。インフラストラクチャと運用のリーダーシップは、クラウドの導入を主導するエンジニアのスキルギャップ分析、トレーニング、ロール定義を計画する必要があります。
### 実装手順
1. スタッフの生産性などの関連する運用指標 (ワークロードをサポートするためのコストやインシデント時に費やしたオペレーター時間など) を使用して、チームの成功の基準を定義します。
1. リソースキャパシティプランニングと検査のメカニズムを定義し、適切なバランスの適格なキャパシティが必要な際に利用でき、長期的に調整可能かを検証します。
1. チームに影響を及ぼす業務上の課題 (責任範囲の増大、テクノロジーの変化、人員の喪失、対応する顧客の増加など) を把握するためのメカニズムを作成します (チームに毎月アンケートを送信するなど)。
1. このようなメカニズムを使用してチームとのエンゲージメントを維持し、従業員の生産性に関する課題の一因となる可能性のある傾向を検出します。チームが外部要因の影響を受けた場合、目標を再評価し、必要に応じてターゲットを調整します。チームの進行を妨げている障害を特定します。
1. 現在提供されているリソースが十分であるか、追加のリソースが必要かどうかを定期的に確認して、サポートチームの適切な調整を行います。
**実装計画に必要な工数レベル:** 中
## リソース
**関連するベストプラクティス:**
+ [OPS03-BP06 チームメンバーがスキルセットを維持、強化することができ、それが推奨されている](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_org_culture_team_enc_learn.html)
+ [OPS09-BP03 運用メトリクスのレビューと改善の優先順位付け](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_operations_health_review_ops_metrics_prioritize_improvement.html)
+ [OPS10-BP01 イベント、インシデント、問題管理のプロセスを使用する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_event_incident_problem_process.html)
+ [OPS10-BP07 イベントへの対応を自動化する](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/ops_event_response_auto_event_response.html)
**関連ドキュメント:**
+ [AWS クラウド Adoption Framework: People Perspective](https://docs.aws.amazon.com/whitepapers/latest/aws-caf-people-perspective/aws-caf-people-perspective.html)
+ [未来に対応できる企業になる](https://aws.amazon.com/blogs/enterprise-strategy/becoming-a-future-ready-enterprise/)
+ [Prioritize your Employees' Skills to Drive Business Growth](https://aws.amazon.com/executive-insights/content/prioritize-your-employees-skills-to-drive-business-growth/)
+ [高いパフォーマンスを発揮する組織 - Amazon ピザ 2 枚チーム](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/)
+ [How Cloud-Mature Enterprises Succeed](https://aws.amazon.com/blogs/mt/how-cloud-mature-enterprises-succeed/)