

# 組織
<a name="a-organization"></a>

**Topics**
+ [OPS 1 優先順位はどのように決定すればよいですか?](w2aac19b5b5b5.md)
+ [OPS 2 ビジネスの成果をサポートするために、組織をどのように構築すればよいですか?](w2aac19b5b5b7.md)
+ [OPS 3 組織の文化はビジネスの成果をどのようにサポートしますか?](w2aac19b5b5b9.md)

# OPS 1 優先順位はどのように決定すればよいですか?
<a name="w2aac19b5b5b5"></a>

 だれもが、ビジネスを成功させるうえで自分が果たす役割を理解する必要があります。リソースの優先順位を設定するため、共通の目標を設定してください。これにより、取り組みから得られるメリットが最大化されます。 

**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-BP07 メリットとリスクを管理する](ops_priorities_manage_risk_benefit.md)

# OPS01-BP01 外部顧客のニーズを評価する
<a name="ops_priorities_ext_cust_needs"></a>

 ビジネス、開発、運用チームを含む主要関係者と協力して、外部顧客のニーズに対する重点領域を決定します。これにより、望ましいビジネス成果を達成するために必要なオペレーションサポートについて十分に理解できます。 

 **一般的なアンチパターン:** 
+  あなたは、営業時間外にカスタマーサポートを設けないこととしましたが、サポートリクエストの履歴データを確認していません。あなたには、これが顧客に影響を与えるかどうかはわかりません。 
+  あなたは、新しい機能を開発していますが、当該機能が望まれているかどうか、望まれている場合はどのような形式なのかを見出すために、顧客に関与してもらっておらず、また、提供の必要性および提供方法を検証するための実験も行っていません。 

 **このベストプラクティスを活用するメリット:** ニーズが満たされている顧客は、顧客のままでいる可能性が高くなります。外部の顧客のニーズを評価し、理解することで、ビジネス価値を実現するためにどのような優先順位で注力すべきかを知ることができます。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  ビジネスニーズの理解: ビジネスの成功は、ビジネス、開発、運用チームを含む関係者全体で目標と理解を共有することで実現できます。 
  +  外部顧客のビジネス目標、ニーズ、優先順位の確認: ビジネス、開発、運用の各チームを含む主要関係者と外部顧客の目標、ニーズ、優先順位について議論します。これにより、ビジネスおよび顧客成果を達成するために必要なオペレーションサポートについて十分に理解できます。 
  +  共通理解の確立: ワークロードのビジネス機能、ワークロードの運用における各チームの役割、およびこれらの要因が内部および外部顧客の共通のビジネス目標をどのようにサポートするかについて、共通の理解を確立します。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Well-Architected Framework の概念 - フィードバックループ](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.feedback-loop.en.html) 

# OPS01-BP02 内部顧客のニーズを評価する
<a name="ops_priorities_int_cust_needs"></a>

 ビジネス、開発、運用チームを含む主要関係者と協力して、内部顧客のニーズに対する重点領域を決定します。これにより、ビジネス成果を達成するために必要なオペレーションサポートについて十分に理解できます。 

 確立された優先順位を使用して、改善の努力を最も影響があるところに集中させます (チームのスキルの開発、ワークロードのパフォーマンスの改善、コストの削減、ランブックの自動化、モニタリングの強化など)。必要に応じて優先順位を更新します。 

 **一般的なアンチパターン:** 
+  あなたは、ネットワーク管理を容易にするため、製品チームの IP アドレスの割り当てを変更することとしました。あなたは、これが製品チームに与える影響を知りません。 
+  あなたは、新しい開発ツールを実装しようとしていますが、当該ツールが必要とされているかどうか、または既存のプラクティスと互換性があるかどうかを知るために、社内クライアントを関与させていません。 
+  あなたは、新しいモニタリングシステムを実装しようとしていますが、検討されるべきモニタリングまたはレポートのニーズがあるかどうかを把握するために社内クライアントに問い合わせていません。 

 **このベストプラクティスを確立するメリット:** 社内の顧客のニーズを評価し、理解することで、ビジネス価値を実現するためにどのような優先順位で注力すべきかを知ることができます。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  ビジネスニーズの理解: ビジネスの成功は、ビジネス、開発、運用チームを含む関係者全体で目標を共有し、理解を深めることで実現できます。 
  +  内部顧客のビジネス目標、ニーズ、優先順位の確認: ビジネス、開発、運用の各チームを含む主要関係者と連携し、内部顧客の目標、ニーズ、優先順位について議論します。これにより、ビジネスおよび顧客成果を達成するために必要なオペレーションサポートについて十分に理解できます。 
  +  共通理解の確立: ワークロードのビジネス機能、ワークロードの運用における各チームの役割、およびこれらの要因が内部および外部顧客の共通のビジネス目標をどのようにサポートするかについて、共通の理解を確立します。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Well-Architected Framework Concepts – Feedback loop (AWS Well-Architected Framework の概念 - フィードバックループ)](https://wa.aws.amazon.com/wellarchitected/2020-07-02T19-33-23/wat.concept.feedback-loop.en.html) 

# OPS01-BP03 ガバナンス要件を評価する
<a name="ops_priorities_governance_reqs"></a>

 特定のことに焦点を置くように求め、その焦点を強調する組織の定義したガイドラインや義務を把握します。組織のポリシー、標準、要件などの内部要因を評価します。ガバナンスへの変更を識別するメカニズムがあることを検証します。ガバナンス要件が特定されていない場合は、必ずこの決定にデューデリジェンスが適用されていることを確認してください。 

 **一般的なアンチパターン:** 
+  あなたは、監査中であり、社内のガバナンスへのコンプライアンスの証拠を提供するよう求められています。あなたは、自らのコンプライアンス要件が何かを評価したことがないため、遵守しているかどうかがわかりません。 
+  あなたはセキュリティ侵害の被害に遭い、その結果、金銭的な損失が発生しました。あなたは、金銭的な損失をカバーしたであろう保険が、未実施の、またはガバナンスによって要求されていない、特定のセキュリティに関する統制の実施を条件としていることがわかりました。 
+  あなたの管理アカウントが侵害され、その結果、会社のウェブサイトが改ざんされ、顧客の信頼が損なわれました。社内のガバナンスでは、管理アカウントのセキュリティを確保するために多要素認証 (MFA) の使用が要求されています。あなたは、管理アカウントを MFA で保護していなかったため、懲戒処分の対象となりました。 

 **このベストプラクティスを活用するメリット:** 組織がワークロードに適用するガバナンス要件を評価し、理解することで、ビジネス価値を実現するためにどのような優先順位で注力すべきかを知ることができます。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  ガバナンス要件の理解: プログラムまたは組織のポリシー、プログラムポリシー、問題またはシステム固有のポリシー、標準、手順、ベースライン、ガイドラインなどの社内のガバナンスの要素を評価します。ガバナンスへの変更を識別するメカニズムがあることを検証します。ガバナンス要件が特定されていない場合は、必ずこの決定にデューデリジェンスが適用されていることを確認してください。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS クラウド コンプライアンス](https://aws.amazon.com/compliance/) 

# OPS01-BP04 コンプライアンス要件を評価する
<a name="ops_priorities_compliance_reqs"></a>

 法令遵守の要件や業界標準などの外的要因を評価して、特定の重点領域の必須化や重視が必要となる可能性のあるガイドラインや義務についてしっかりと認識してください。コンプライアンス要件が特定されていない場合は、必ずこの決定にデューデリジェンスを適用してください。 

 **一般的なアンチパターン:** 
+  あなたは、監査中であり、業界規制へのコンプライアンスの証拠を提供するよう求められています。あなたは、自らのコンプライアンス要件が何かを評価したことがないため、遵守しているかどうかがわかりません。 
+  あなたの管理アカウントが侵害され、その結果、顧客データがダウンロードされ、顧客の信頼が損なわれました。業界のベストプラクティスでは、管理アカウントのセキュリティを確保するために MFA の使用が要求されています。あなたは、管理アカウントを MFA で保護していなかったため、顧客によって訴訟が提起されました。 

 **このベストプラクティスを確立するメリット:** ワークロードに適用されるコンプライアンス要件を評価し、理解することで、ビジネス価値を実現するためにどのような優先順位で注力すべきかを知ることができます。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  コンプライアンス要件の理解: 法令遵守の要件や業界標準などの外的要因を評価して、特定の重点領域の必須化や重視が必要となる可能性のあるガイドラインや義務についてしっかりと認識してください。コンプライアンス要件が特定されていない場合は、この決定にデューデリジェンスが適用されていることを確認してください。 
  +  規制コンプライアンス要件の理解: 適合が法的に義務付けられている法令遵守の要件を確認してください。これらの要件に基づいて取り組みに注力してください。例として、プライバシーおよびデータ保護法による義務などがあります。 
    +  [AWS コンプライアンス](https://aws.amazon.com/compliance/) 
    +  [AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/) 
    +  [AWS コンプライアンスの最新ニュース](https://aws.amazon.com/compliance/compliance-latest-news/) 
  +  業界標準とベストプラクティスの理解: Payment Card Industry Data Security Standard (PCI DSS) など、ワークロードに適用される業界標準とベストプラクティスの要件を確認してください。これらの要件に基づいて取り組みに注力してください。 
    +  [AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/) 
  +  内部コンプライアンス要件の理解: 組織で確立されているコンプライアンス要件とベストプラクティスを確認してください。これらの要件に基づいて取り組みに注力してください。例としては、情報セキュリティポリシーやデータ分類基準などがあります。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS クラウド コンプライアンス](https://aws.amazon.com/compliance/) 
+  [AWS コンプライアンス](https://aws.amazon.com/compliance/) 
+  [AWS コンプライアンスの最新ニュース](https://aws.amazon.com/compliance/compliance-latest-news/) 
+  [AWS コンプライアンスプログラム](https://aws.amazon.com/compliance/programs/) 

# OPS01-BP05 脅威の状況を評価する
<a name="ops_priorities_eval_threat_landscape"></a>

 ビジネスに対する脅威 (競合、ビジネスリスクと負債、運用リスク、情報セキュリティの脅威など) を評価し、リスクのレジストリで現在の情報を維持します。注力する場所を決定する際に、リスクの影響を考慮します。 

 それらの [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/) は、優先順位をさらに高めることができるセキュリティ、信頼性、パフォーマンス、コストの最適化に重点を置いた追加のチェックにアクセスできます。 

 **一般的なアンチパターン:** 
+  あなたは、製品に古いバージョンのソフトウェアライブラリを使用しています。あなたは、ワークロードに意図しない影響を及ぼす可能性のある問題について、ライブラリのセキュリティ更新が必要なことを認識していません。 
+  最近、競合他社は、あなたの製品に関する顧客からの苦情の多くに対処する製品のバージョンをリリースしました。あなたは、これらの既知の問題の対処について優先順位付けを行っていません。 
+  規制当局は、法規制コンプライアンス要件を遵守していない企業の責任を追求してきました。あなたは、未対応のコンプライアンス要件への対応に優先順位を付けていません。 

 **このベストプラクティスを確立するメリット:** 組織とワークロードに対する脅威を特定して理解することで、どの脅威に対処すべきか、その優先度、およびそれに必要なリソースを判断できます。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  脅威の状況の評価: ビジネスに対する脅威 (競合、ビジネスリスクと負債、運用リスク、情報セキュリティの脅威など) を評価し、重点領域を決定する際にその影響を織り込めるようにします。 
  +  [AWS セキュリティ速報](https://aws.amazon.com/security/security-bulletins/) 
  +  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 
  +  脅威モデルの維持: 潜在的な脅威、計画および実施された軽減策、またその優先順位を特定する脅威モデルを確立し、維持します。脅威がインシデントとして出現する確率、それらのインシデントから回復するためのコスト、発生が予想される損害、およびそれらのインシデントを防ぐためのコストを確認します。脅威モデルの内容の変更に伴って、優先順位を変更します。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS クラウド コンプライアンス](https://aws.amazon.com/compliance/) 
+  [AWS セキュリティ速報](https://aws.amazon.com/security/security-bulletins/) 
+  [AWS Trusted Advisor](https://aws.amazon.com/premiumsupport/trustedadvisor/) 

# OPS01-BP06 トレードオフを評価する
<a name="ops_priorities_eval_tradeoffs"></a>

 競合する利益または代替アプローチ間のトレードオフの影響を評価し、重点領域を決定するか、一連のアクションを選択する際に十分な情報に基づいて意思決定を下せるようにします。たとえば、新しい機能の市場投入までの時間を短縮することは、コストの最適化よりも重視されることがあります。または、非リレーショナルデータ用にリレーショナルデータベースを選択すれば、データ型に合わせて最適化されたデータベースに移行してアプリケーションを更新するよりも、システムの移行が簡素化されます。 

 AWS サポート は、AWS とそのサービスについてチームを教育し、選択がどのようにワークロードに影響を与えるかについての理解を深める支援を行います。チームを教育するには、 [AWS サポート](https://aws.amazon.com/premiumsupport/programs/) ([AWS ナレッジセンター](https://aws.amazon.com/premiumsupport/knowledge-center/)、 [AWS ディスカッションフォーラム](https://forums.aws.amazon.com/index.jspa)、および [AWS サポート センター](https://console.aws.amazon.com/support/home/)) および [AWS ドキュメント](https://docs.aws.amazon.com/) が提供するリソースを使用する必要があります。AWS に関しての質問に対する支援については、AWS サポート センターを利用して 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/)。 

 **一般的なアンチパターン:** 
+  あなたは、リレーショナルデータベースを使用して、時系列と非リレーショナルデータを管理しています。使用しているデータ型をサポートするように最適化されたデータベースオプションがありますが、あなたはソリューション間のトレードオフを評価していないため、そのメリットを認識していません。 
+  投資家からは、Payment Card Industry Data Security Standards (PCI DSS) への準拠を実証することが求められています。あなたは、投資家の要求に応えることと、現在の開発活動を継続することとのトレードオフについて検討しません。代わりに、準拠を実証することなく、開発作業を進めます。あなたの投資家は、プラットフォームのセキュリティと、投資の是非に懸念を抱いて、あなたの会社に対する支援を停止します。 

 **このベストプラクティスを活用するメリット:** 選択した影響と結果を理解することで、選択肢に優先順位を付けることができます。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  トレードオフの評価: 競合する利益間のトレードオフの影響を評価し、重点領域を決定する際に十分な情報に基づいて意思決定を下せるようにします。たとえば、新しい機能を市場に出す速度を上げることが、コストの最適化より重視されることがあります。 
+  AWS サポート は、AWS とそのサービスについてチームを教育し、選択がどのようにワークロードに影響を与えるかについての理解を深める支援を行います。チームを教育するには、AWS サポート (AWS ナレッジセンター、AWS ディスカッションフォーラム、AWS サポート センター) および AWS ドキュメントが提供するリソースを使用する必要があります。AWS に関しての質問に対する支援については、AWS サポート センターを利用して AWS サポート に連絡してください。 
+  また、AWS は Amazon Builders' Library の AWS の運用を通じて学んだベストプラクティスとパターンも共有しています。AWS ブログと公式の AWS ポッドキャストでは、その他のさまざまな有益な情報を入手できます。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS ブログ](https://aws.amazon.com/blogs/) 
+  [AWS クラウド コンプライアンス](https://aws.amazon.com/compliance/) 
+  [AWS ディスカッションフォーラム](https://forums.aws.amazon.com/index.jspa) 
+  [AWS ドキュメント](https://docs.aws.amazon.com/) 
+  [AWS ナレッジセンター](https://aws.amazon.com/premiumsupport/knowledge-center/) 
+  [AWS サポート](https://aws.amazon.com/premiumsupport/) 
+  [AWS サポート センター](https://console.aws.amazon.com/support/home/) 
+  [Amazon Builders’ Library](https://aws.amazon.com/builders-library/) 
+  [公式の AWS ポッドキャストで入手できます](https://aws.amazon.com/podcasts/aws-podcast/) 

# OPS01-BP07 メリットとリスクを管理する
<a name="ops_priorities_manage_risk_benefit"></a>

 メリットとリスクを管理し、重点領域を決定する際に十分な情報に基づいて意思決定を下せるようにします。たとえば、重要な新機能を顧客に公開できるように、未解決の問題を記録するワークロードをデプロイしておくと便利な場合があります。関連するリスクを軽減できる場合もあれば、リスクが残るのを容認できない場合もあります。その場合、リスクに対処するための措置を講じることになります。 

 ある時点で、優先順位の小さなサブセットに注力したい場合に遭遇するかもしれません。必要な機能の開発とリスクの管理を確実にするために、長期的にバランスのとれたアプローチを使用します。必要に応じて優先順位を更新します。 

 **一般的なアンチパターン:** 
+  あなたは、開発者の 1 人が「インターネットで見つけた」「あなたが必要とするすべてのこと」を行うライブラリを含めることにしました。あなたは、不明なソースからこのライブラリを採用するリスクを評価しておらず、脆弱性や悪意のあるコードが含まれているかどうかはわかりません。 
+  あなたは、既存の問題を修正する代わりに、新しい機能を開発およびデプロイすることに決めました。あなたは、この機能がデプロイされるまで問題をそのままにしておくことのリスクを評価しておらず、顧客への影響がわかりません。 
+  あなたは、コンプライアンスチームから詳細不明の懸念が寄せられたため、顧客から頻繁にリクエストされる機能をデプロイしないことに決めました。 

 **このベストプラクティスを活用するメリット:** 選択肢のメリットを特定し、組織のリスクを認識することで、十分な情報に基づいて意思決定を行うことができます。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  メリットとリスクの管理: 決定のメリットと関連するリスクのバランスを取ってください。 
  +  メリットの特定: ビジネスの目標、ニーズ、優先順位に基づいてメリットを特定します。例として、市場投入までの時間、セキュリティ、信頼性、パフォーマンス、コストなどがあります。 
  +  リスクの特定: ビジネスの目標、ニーズ、優先順位に基づいてリスクを特定します。例として、市場投入までの時間、セキュリティ、信頼性、パフォーマンス、コストなどがあります。 
  +  リスクに対するメリットの評価と情報に基づく意思決定: ビジネス、開発、運用を含む主要関係者の目標、ニーズ、優先順位に基づいてメリットとリスクの影響を決定します。メリットの価値を、リスクが現実化する可能性とその影響のコストに照らして評価します。たとえば、信頼性よりも市場投入までのスピードを重視すると、競争上の優位性が得られます。ただし、信頼性の問題がある場合、稼働時間が短くなる場合があります。 

# OPS 2 ビジネスの成果をサポートするために、組織をどのように構築すればよいですか?
<a name="w2aac19b5b5b7"></a>

 チームはビジネスの成果を達成するうえでの役割を理解する必要があります。チームは他のチームが成功するためのそれぞれの役割を理解し、自分たちのチームが成功するための他のチームの役割を理解し、目標を共有する必要があります。責任、所有権、意思決定方法、意思決定を行う権限を持つユーザーを理解することは、労力を集中的に投入し、チームの利点を最大化するのに役立ちます。 

**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_know_my_job.md)
+ [OPS02-BP05 責任と所有権を特定するためのメカニズムが存在する](ops_ops_model_find_owner.md)
+ [OPS02-BP06 追加、変更、例外をリクエストするメカニズムが存在する](ops_ops_model_req_add_chg_exception.md)
+ [OPS02-BP07 チーム間の責任は事前定義済みまたは交渉済みである](ops_ops_model_def_neg_team_agreements.md)

# OPS02-BP01 リソースには特定の所有者が存在する
<a name="ops_ops_model_def_resource_owners"></a>

 各アプリケーション、ワークロード、プラットフォーム、インフラストラクチャコンポーネントの所有権を持つユーザーが誰か、そのコンポーネントによって提供されるビジネス価値、およびその所有権が存在する理由を理解します。これらの個々のコンポーネントのビジネス価値、およびそれらがビジネスの成果をどのようにサポートするかを理解すると、それらに適用されるプロセスと手順がわかります。 

 **このベストプラクティスを活用するメリット:** 所有権を理解すると、改善の承認者、改善を実装する者、またはその両方がわかります。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  リソースには特定の所有者が存在する: 環境内のリソースユースケースにおける所有権の意味を定義します。最小限の名前、連絡先情報、組織、チームなどでリソースの所有者を指定し、記録します。タグやリソースグループなどのメタデータを使用して、リソース所有権情報をリソースに保存します。AWS Organizations を使用してアカウントを構築し、ポリシーを実装して、所有権と連絡先情報が確実にキャプチャされるようにします。 
  +  所有権の形態と割り当て方法の定義: 所有権は、異なるユースケースにおいて、組織内で複数の定義を持つ場合があります。ワークロード所有者は、ワークロード運用のリスクと責任を所有し、最終的にワークロードに関する決定を行う権限を持つ個人として定義できます。所有権が親組織にロールアップされる場合における財務責任または管理責任の観点から、所有権を定義することができます。開発者は開発環境の所有者であり、運用によって発生するインシデントに責任を負う者とすることができます。製品リーダーは、開発環境の運用に関連する財務コストについて責任を負う者とすることができます。 
  +  組織、アカウント、リソースのコレクション、または個々のコンポーネントの所有者の定義: 検出をサポートするために整理され、適切にアクセス可能な状態となっている場所に所有権を定義し、記録します。変更に伴って、定義と所有権の詳細を更新します。 
  +  リソースのメタデータの所有権のキャプチャ: タグやリソースグループなどのメタデータを使用してリソースの所有権をキャプチャし、所有権と連絡先情報を指定します。AWS Organizations を使用してアカウントを構築し、所有権と連絡先情報がキャプチャされるようにします。 

# OPS02-BP02 プロセスと手順には特定の所有者が存在する
<a name="ops_ops_model_def_proc_owners"></a>

 個々のプロセスと手順の定義を誰が所有しているか、特定のプロセスと手順が使用されている理由、およびその所有権が存在する理由を理解します。特定のプロセスと手順が使用される理由を理解することで、改善の機会を特定できます。 

 **このベストプラクティスを確立するメリット:** 所有権を理解すると、改善の承認者、改善を実装する者、またはその両方がわかります。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  プロセスや手順には、その定義に責任を持つ所有者が存在する: お客様の環境で使用されているプロセスや手順、およびその定義に責任を持つ個人またはチームを把握します。 
  +  プロセスと手順の特定: ワークロードのサポートにおいて実施される運用アクティビティを特定します。これらのアクティビティを検出可能な場所に文書化します。 
  +  プロセスまたは手順の定義の所有者の定義: アクティビティの仕様に責任を有する個人またはチームを一意に特定します。当該個人またはチームは、適切なアクセス許可、アクセス、およびツールを持つ適切なスキルを持つチームメンバーが正常に実行できるようにする責任があります。そのアクティビティの実行に問題がある場合、アクティビティの改善に必要となる詳細なフィードバックを提供する責任はそのチームメンバーにあります。 
  +  アクティビティアーティファクトのメタデータの所有権のキャプチャ: AWS Systems Manager (ドキュメント)、および AWS Lambda (関数) などのサービスで自動化されている手続きは、メタデータ情報をタグとしてキャプチャするのをサポートしています。タグまたはリソースグループを使用してリソースの所有権をキャプチャし、所有権と連絡先情報を指定します。AWS Organizations を使用してタグ付けポリシーを作成し、所有権と連絡先情報がキャプチャされるようにします。 

# OPS02-BP03 パフォーマンスに責任を持つ所有者が運用アクティビティに存在する
<a name="ops_ops_model_def_activity_owners"></a>

 定義されたワークロードに対して特定のアクティビティを実行する責任を持つ者と、その責任が存在する理由を理解します。運用アクティビティを実行することに責任を負う者を理解すると、誰がアクティビティを実行し、結果を検証し、アクティビティの所有者にフィードバックを提供するかを通知します。 

 **このベストプラクティスを活用するメリット:** アクティビティを実行する責任を負う者を理解すると、アクションが必要になったときに誰に通知し、誰がアクションを実行し、結果を検証し、アクティビティの所有者にフィードバックを提供するかがわかります。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  運用アクティビティのパフォーマンスに責任を持つ所有者の存在: 環境で使用されるプロセスと手順を実行する責任を明確にする 
  +  プロセスと手順の特定: ワークロードのサポートにおいて実施される運用アクティビティを特定します。これらのアクティビティを検出可能な場所に文書化します。 
  +  各アクティビティを実行する責任者の定義: アクティビティに責任を有するチームを特定します。アクティビティの詳細と、アクティビティを実行するために必要なスキルと適切なアクセス許可、アクセス、ツールがあることを確認します。チームは、当該アクティビティが実行される条件 (イベントやスケジュールなど) を理解する必要があります。この情報を検出可能にして、組織のメンバーが、特定のニーズに合わせて連絡する必要があるチームまたは個人を特定できるようにします。 

# OPS02-BP04 チームメンバーが自らの責任範囲を把握する
<a name="ops_ops_model_know_my_job"></a>

 役割の責任と、ビジネスの成果にどのように貢献するかを理解することで、タスクの優先順位付けと役割が重要である理由を知ることができます。これにより、チームメンバーはニーズを認識し、適切に対応できます。 

 **このベストプラクティスを活用するメリット:** 責任を理解すると、決定する事項、実行するアクション、および適切な所有者に引き渡すべきアクティビティがわかります。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  チームメンバーに自らの役割と責任を確実に理解させる: チームメンバーの役割と責任を特定し、そのチームメンバーが自らの役割に期待されている事項を理解できるようにします。この情報を検出可能にして、組織のメンバーが、特定のニーズに合わせて連絡する必要があるチームまたは個人を特定できるようにします。 

# OPS02-BP05 責任と所有権を特定するためのメカニズムが存在する
<a name="ops_ops_model_find_owner"></a>

 個人またはチームが特定されない場合、対処される必要がある事項についての所有権または計画を割り当てる権限を持つ者へのエスカレーションパスが定義されています。 

 **このベストプラクティスを活用するメリット:** 責任者または所有者を理解すると、適切なチームまたはチームメンバーに連絡して、リクエストし、またはタスクを移行することができます。責任や所有権を割り当て、またはニーズに対処する計画を立てる権限を持つ個人を特定することで、不作為のリスクや対応されないままとなるリスクを軽減できます。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  責任と所有権を特定するためのメカニズムの存在: 組織のメンバーが所有権と責任を知り、特定するために、メンバーがアクセス可能なメカニズムを提供します。これらのメカニズムにより、メンバーは、特定のニーズについて、連絡すべきチームまたは個人を特定できます。 

# OPS02-BP06 追加、変更、例外をリクエストするメカニズムが存在する
<a name="ops_ops_model_req_add_chg_exception"></a>

 プロセス、手順、およびリソースの所有者にリクエストを送信できます。利点とリスクを評価した後、実行可能で適切であると判断されたリクエストを、十分な情報に基づいて承認します。 

 **このベストプラクティスを確立するメリット:** チームの活動のサポートに対する追加、変更、例外をリクエストするメカニズムを持つことは重要です。このオプションがなければ、現在の状態はイノベーションの制約になります。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  追加、変更、例外をリクエストするメカニズムの存在: 規格が硬直化すると、イノベーションが制約されます。組織のメンバーのために、ビジネスニーズをサポートするプロセス、手順、およびリソースの所有者にリクエストを行うメカニズムを提供します。 

# OPS02-BP07 チーム間の責任は事前定義済みまたは交渉済みである
<a name="ops_ops_model_def_neg_team_agreements"></a>

 チーム間には、チームがどのように連携し、互いにサポートするかを説明する、定義済みまたは交渉済みの契約があります (応答時間、サービスレベル目標、サービスレベルアグリーメントなど)。チームの仕事がビジネスの成果に及ぼす影響、および他のチームや組織の成果を理解することで、タスクの優先順位付けを知り、適切に対応できるようになります。 

 責任と所有権が未定義または不明な場合、必要な活動をタイムリーに処理できず、これらのニーズへの対応が重複し、競合する可能性のある作業が生じるリスクがあります。 

 **このベストプラクティスを活用するメリット:** チーム間の責任、目的、およびニーズを伝達する方法を確立することで、リクエストの流れがスムーズになり、必要な情報が確実に提供されます。これにより、チーム間の移行タスクによって生じる遅延が軽減され、ビジネス成果の達成をサポートします。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  チーム間の責任は事前定義済みまたは交渉済み: チームがやり取りする方法と、互いにサポートするために必要な情報を指定することで、リクエストが反復的にレビューおよび明確化されることに伴う遅延を最小限に抑えることができます。期待される事項 (応答時間や履行時間など) を定義する具体的な契約があることで、チームは効果的な計画とリソースを適切に作成することができます。 

# OPS 3 組織の文化はビジネスの成果をどのようにサポートしますか?
<a name="w2aac19b5b5b9"></a>

 チームメンバーにサポートを提供することで、チームメンバーがより効果的に行動し、ビジネスの成果をサポートできるようにします。 

**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-BP08 チーム内やチーム間でさまざまな意見が推奨され、求められる](ops_org_culture_diverse_inc_access.md)

# OPS03-BP01 エグゼクティブスポンサーシップ
<a name="ops_org_culture_executive_sponsor"></a>

 シニアリーダーシップは、組織に対する期待を明確に設定し、成功を評価します。シニアリーダーシップは、ベストプラクティスの採用と組織の進化の協賛者、支持者、および推進者です。 

 **このベストプラクティスを確立するメリット:** 熱心なリーダーシップ、期待事項の明確な伝達、目標の共有により、チームメンバーは、何が期待されているのかを知ることができます。成功を評価することで、成功に至るまでの障壁を特定でき、支持者や権限を与えられた者の介入を通じて対処できます。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  エグゼクティブスポンサーシップ: シニアリーダーシップは、組織に対する期待値を明確に設定し、成功を評価します。シニアリーダーシップは、ベストプラクティスの採用と組織の進化の協賛者、支持者、および推進者です。 
  +  期待値の設定: 測定方法を含め、組織の目標を定義し、公開します。 
  +  目標の達成の追跡: 目標の段階的な達成度を定期的に測定し、結果を共有して、結果にリスクがある場合に適切なアクションが講じられるようにします。 
  +  目標達成に必要なリソースの提供: 新しい情報、目標、責任、ビジネス環境の変化などに基づいて、リソースが適切かどうか、また追加のリソースが必要であるかどうかを定期的に見直します。 
  +  チームの支援: チームと常に関わり、彼らがどのような状態にあるのか、また彼らに影響を与える外的要因があるのかを理解します。チームが外部要因の影響を受けた場合、目標を再評価し、必要に応じてターゲットを調整します。チームの進行を妨げている障害を特定します。チームのために障害に対処し、不要な負担を取り除きます。 
  +  ベストプラクティスの導入の促進: 定量的な利益をもたらしたベストプラクティスを認定し、その考案者と採用者を評価します。さらなる導入を推奨して、得られるメリットを拡大します。 
  +  チームの進化の推進: 継続的な改善の文化を生み出します。個人と組織の両者の成長と発展を奨励します。時間の経過とともに段階的な達成を求める長期的なターゲットを提供します。ニーズ、ビジネス目標、ビジネス環境の変化に応じて、これらを補完するために、このビジョンを調整します。 

# OPS03-BP02 チームメンバーに、結果にリスクがあるときにアクションを実行する権限が付与されている
<a name="ops_org_culture_team_emp_take_action"></a>

 ワークロード所有者は、結果にリスクがあるときにチームメンバーが対応できるようにするためのガイダンスと範囲を定義しています。エスカレーションメカニズムは、イベントが定義された範囲外にある場合に対応の方向性を取得するために使用されます。 

 **このベストプラクティスを活用するメリット:** 変更を早期にテストして検証することで、コストを最小限に抑えて問題に対処し、顧客への影響を抑えることができます。デプロイ前にテストすることで、エラーの発生を最小限に抑えることができます。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  結果にリスクがあるときにアクションを実行する権限が、チームメンバーに付与されている: 効果的に対応するために必要なスキルを実践するためのアクセス許可、ツール、機会をチームメンバーに提供します。 
  +  対応するために必要なスキルを訓練する機会をチームメンバーに提供する: プロセスと手順のテストとトレーニングを安全に実行できる、安全な代替環境を提供します。ゲームデーを実施して、チームメンバーがシミュレートされた安全な環境で現実世界のインシデントに対応する経験を積むことができるようにします。 
  +  アクションを実行するチームメンバーの権限を定義および認識する: チームメンバーがサポートするワークロードとコンポーネントにアクセス許可とアクセス権を割り当てることで、アクションを実行するチームメンバーの権限を具体的に定義します。チームメンバーが、結果にリスクがあるときにアクションを実行する権限を付与されていることを認識します。 

# OPS03-BP03 エスカレーションが推奨されている
<a name="ops_org_culture_team_enc_escalation"></a>

 チームメンバーにはメカニズムがあり、結果にリスクがあると思われる場合は、意思決定者や利害関係者に懸念をエスカレートすることが推奨されます。エスカレーションは、リスクを特定し、インシデントの発生を防ぐために、早く、頻繁に実行する必要があります。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  早期かつ頻繁なエスカレーションを奨励する: 早期かつ頻繁なエスカレーションがベストプラクティスであることを組織的に認識します。エスカレーションに理由がないとされる場合があること、そして、エスカレーションしないことによって、インシデントを阻止する機会を逃すよりも、インシデントを阻止する機会が得られる方がよいことを組織的に認識し、受け入れます。 
  +  エスカレーションメカニズムの存在: エスカレーションをいつどのように行うかを定義する手順を文書化します。アクションを実行したり、アクションを承認したりする強い権限を持つ人々とその連絡先情報を文書化します。リスクに対処できる人物に当該リスクが引き渡されたとチームメンバーが満足するまで、またはワークロードの運用に関するリスクと責任の所有者に連絡するまで、エスカレーションを続行する必要があります。当該者がワークロードに関するすべての決定を最終的に所有します。エスカレーションには、リスクの性質、ワークロードの重要度、影響を受ける者、影響の内容、緊急性 (予想される影響の時期など) を含める必要があります。 
  +  エスカレーションする従業員の保護: 無策の意思決定や利害関係者などにエスカレーションする場合にチームメンバーを報復から保護するポリシーを備えます。これが発生しているかどうかを特定し、適切に対応するメカニズムを備えます。 

# OPS03-BP04 タイムリーで明確、かつ実用的なコミュニケーション
<a name="ops_org_culture_effective_comms"></a>

 メカニズムが存在し、 チームメンバーに既知のリスクや計画されたイベントをタイムリーに通知するために使用されます。アクションが必要かどうか、どのようなアクションが必要かを判断し、タイミングよくそのアクションを実行するために、必要なコンテキスト、詳細、および時間 (可能な場合) が提供されます。たとえば、パッチ適用を迅速に行えるようにソフトウェアの脆弱性を通知したり、サービス中断のリスクを回避するために変更のフリーズを実装できるように計画された販売プロモーションの通知を提供したりします。 

 計画されたイベントは変更カレンダーまたはメンテナンススケジュールに記録できるため、チームメンバーが保留中のアクティビティを特定できます。 

 AWS では、 [AWS Systems Manager 変更カレンダー](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-change-calendar.html) を使用してこれらの詳細を記録できます。カレンダーのステータスのプログラムによるチェックをサポートし、特定の時点でカレンダーがアクティビティに対して開いているか閉じているかを判断します。運用アクティビティは、障害となり得るアクティビティのために確保された *特定の「承認済み」の* 時間枠を中心に計画できます。AWS Systems Manager メンテナンスウィンドウは、アクティビティを自動化し、それらのアクティビティを検出可能にするために、 [インスタンスやその他のサポートされているリソースに対し](https://docs.aws.amazon.com/ARG/latest/userguide/supported-resources.html#supported-resources-console) アクティビティをスケジュールできるようにします。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** 高 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  タイムリーで明確、かつ実用的なコミュニケーション: リスクや計画されたイベントの通知を明確かつ実用的な方法で提供し、適切な対応を可能にするのに十分な通知を提供するメカニズムが設けられています。 
  +  計画されたアクティビティを変更カレンダーに記録し、通知する: 計画されたイベントを知ることができる、アクセス可能な情報ソースを提供します。同じシステムから計画されたイベントを通知します。 
  +  ワークロードに影響を与え得るイベントとアクティビティを追跡する: 脆弱性の通知とパッチ情報をモニタリングして、ワークロードコンポーネントに関連する野放し状態の脆弱性と潜在的なリスクを理解します。チームメンバーがアクションを実行できるように通知を送信します。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS Systems Manager 変更カレンダー](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/systems-manager-maintenance.html) 

# OPS03-BP05 実験の推奨
<a name="ops_org_culture_team_enc_experiment"></a>

 実験は、学習を加速し、チームメンバーが関心と当事者意識を持ち続けることの一助となります。望ましくない結果は、成功につながらないパスを特定することに成功した実験です。望ましくない結果が得られた実験が成功してもチームメンバーが罰せられることはありません。イノベーションを起こし、アイデアを成果に変えるには、実験が必要です。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  実験の推奨: 学習とイノベーションをサポートする実験を奨励します。 
  +  さまざまなテクノロジーを試す: ビジネス上の成果を達成するために、現在または将来的に適用可能なテクノロジーを用いた実験を奨励します。この知識は、将来のイノベーションに役立つ可能性があります。 
  +  目標を念頭に置いて実験する: チームメンバーが到達すべき具体的な目標や、近い将来に適用可能となり得るテクノロジーを使って実験することを奨励します。この知識はイノベーションに役立つ可能性があります。 
  +  実験のための時間を計画的に確保する: チームメンバーが実験に集中できるよう、通常の業務から解放される時間を確保します。 
  +  実験をサポートするためのリソースを提供する: 実験に必要なリソース (ソフトウェアやクラウドリソースなど) に予算を割り当てます。 
  +  成功を認める: 実験によって得られた価値を評価します。望ましくない結果を得られた実験は、成功につながらないパスを特定できた成功した実験であることを理解します。チームメンバーは、実験から望ましくない結果を得たことについて罰せられることはありません。 

# OPS03-BP06 チームメンバーがスキルセットを維持、強化することができ、それが推奨されている
<a name="ops_org_culture_team_enc_learn"></a>

 チームは、ワークロードに対応するに際して、新しいテクノロジーを採用し、需要と責任の変化をサポートするために、スキルセットを強化する必要があります。新しいテクノロジーにおけるスキルの発達は、多くの場合、チームメンバーの満足度の源となり、イノベーションをサポートします。チームメンバーが強化している自らのスキルを検証および認識し、業界認証を追求および維持できるように支援します。組織の知識とスキルを持ち、熟練したチームメンバーを失った場合は、クロストレーニングによって知識の伝達を促進し、重大な影響のリスクを緩和します。学習のために専用の時間を割り当てます。 

 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/)などのリソースを提供しており、チームを教育するためのガイダンス、事例、詳細なチュートリアルを提供しています。 

 また、AWS では、 [Amazon Builders' Library で AWS の運用を通じて学んだベストプラクティスと](https://aws.amazon.com/builders-library/) パターン、 [AWS ブログ](https://aws.amazon.com/blogs/) や [公式 AWS ポッドキャストを通じて幅広い有益な教材を共有しています。](https://aws.amazon.com/podcasts/aws-podcast/). 

 AWS が提供する Well-Architected ラボ、 [AWS サポート](https://aws.amazon.com/premiumsupport/programs/) ([AWS ナレッジセンター](https://aws.amazon.com/premiumsupport/knowledge-center/)、 [AWS ディスカッションフォーラム](https://forums.aws.amazon.com/index.jspa)、および [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 サポート センターを利用して AWS サポート に連絡してください。 

 [AWS トレーニング と認定](https://aws.amazon.com/training/) では、AWS の基礎に関するセルフペースデジタルコースを通じて無料のトレーニングを提供しています。また、インストラクターが実施するトレーニングに登録して、チームの AWS スキルの開発をさらにサポートすることもできます。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  チームメンバーはスキルセットの維持と成長が可能で推奨されている: 新しいテクノロジーを採用し、イノベーションをサポートし、ワークロードのサポートにおける需要と責任の変化に対応するためには、継続的な教育が必要です。 
  +  教育のためのリソースを提供する: 構造的に設けられた専用の時間、トレーニング資料へのアクセス、ラボリソース、カンファレンスや専門家組織への参加のサポートにより、教育者と同僚の両方から学習する機会を得ることができます。下級チームのメンバーが、上級チームのメンバーをメンターとするためにアクセスできるようにしたり、上級チームのメンバーの業務をシャドーイングして、自らの手法やスキルを評価してもらえるようにしたりします。より広い視点を持つために、仕事に直接関係しないコンテンツについて学習することを奨励します。 
  +  チーム教育とチーム間のエンゲージメント: チームメンバーの継続的な教育のニーズに合った計画を立てます。チームメンバーが他のチームに (一時的または永続的に) 参加し、組織全体に役立つスキルやベストプラクティスを共有する機会を提供する 
  +  業界認証の追求と維持をサポートする: チームメンバーが学んだことを検証し、その成果を認める業界認証を取得および維持するのをサポートします。 

## リソース
<a name="resources"></a>

 **関連するドキュメント:** 
+  [AWS ご利用開始のためのリソースセンター](https://aws.amazon.com/getting-started/) 
+  [AWS ブログ](https://aws.amazon.com/blogs/) 
+  [AWS クラウド コンプライアンス](https://aws.amazon.com/compliance/) 
+  [AWS ディスカッションフォーラム](https://forums.aws.amazon.com/index.jspa) 
+  [AWS ドキュメント](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) 
+  [AWS オンラインテックトーク](https://aws.amazon.com/getting-started/) 
+  [AWS イベントとオンラインセミナー](https://aws.amazon.com/events/) 
+  [AWS ナレッジセンター](https://aws.amazon.com/premiumsupport/knowledge-center/) 
+  [AWS サポート](https://aws.amazon.com/premiumsupport/programs/) 
+  [AWS トレーニング と認定](https://aws.amazon.com/training/) 
+  [AWS Well-Architected ラボ](https://wellarchitectedlabs.com/)、 
+  [Amazon Builders’ Library](https://aws.amazon.com/builders-library/) 
+  [公式 AWS ポッドキャストを通じて幅広い有益な教材を共有しています。](https://aws.amazon.com/podcasts/aws-podcast/). 

# OPS03-BP07 チームに適正なリソースを提供する
<a name="ops_org_culture_team_res_appro"></a>

 チームメンバーのキャパシティを維持し、ワークロードのニーズを満たすツールとリソースを提供します。チームメンバーに過剰な負荷がかかることは、人為的ミスに起因するインシデントのリスクを高めます。ツールやリソースへの投資 (頻繁に実行されるアクティビティのオートメーションなど) によって、チームの有効性を高め、より多くの活動をサポートすることを可能にします。 

 **このベストプラクティスが確立されていない場合のリスクレベル:** ミディアム 

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  チームに適正なリソースを提供する: チームの成功、および成功または失敗の要因を確実に把握します。チームに適正なリソースを提供してサポートします。 
  +  チームのパフォーマンスを理解する: チームによる業務成果の達成度や アセット開発の成果を測定します。時間の経過とともに成果とエラー率の変化を追跡します。チームと協力して、チームに影響する業務に関する課題 (責任の増加、テクノロジーの変化、人員の喪失、サポート対象の顧客の増加など) を理解します。 
  +  チームのパフォーマンスへの影響を理解する: チームと常に関わり、彼らがどのような状態にあるのか、また彼らに影響を与える外的要因があるのかを理解します。チームが外部要因の影響を受けた場合、目標を再評価し、必要に応じてターゲットを調整します。チームの進行を妨げている障害を特定します。チームのために障害に対処し、不要な負担を取り除きます。 
  +  チームの成功に必要なリソースを提供する: リソースが適切かどうか、追加リソースが必要かどうかを定期的に検証し、チームをサポートするために適切な調整を行います。 

# OPS03-BP08 チーム内やチーム間でさまざまな意見が推奨され、求められる
<a name="ops_org_culture_diverse_inc_access"></a>

 組織間の多様性を活用して、複数のユニークな視点を追求します。この視点を使用して、イノベーションを高め、想定に挑み、確証バイアスに傾くリスクを軽減します。チーム内のインクルージョン、多様性、アクセシビリティを向上させ、有益な視点を得ます。 

 組織文化は、チームメンバーのジョブに対する満足度と定着率に直接影響します。チームメンバーのやる気と能力を引き出して、ビジネスの成功につなげます。 

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

## 実装のガイダンス
<a name="implementation-guidance"></a>
+  多様な意見や視点を求める: すべてのメンバーからの貢献を求めます。立場の弱いグループの意見に耳を傾けます。ミーティングでは、役割と責任の割り当てを定期的に変更します。 
  +  役割と責任を拡張する: チームメンバーが通常引き受けることのないであろう役割を引き受ける機会を提供します。その役割から、そして、通常はやり取りしない新しいチームメンバーとのやり取りから、経験や視点を得ることができます。また自分の経験と視点を、やり取りをする新しい役割やチームメンバーにもたらします。視点が増えるにつれて、追加のビジネスの機会が得られたり、改善のための新しい機会が見出されたりすることがあります。チーム内のメンバーに、他のメンバーが通常実行する一般的なタスクを交替で担当してもらい、当該タスクの実行の需要と影響を理解してもらいます。 
  +  安全で温かい環境を提供する: 組織内のチームメンバーの精神的および物理的な安全を確保するポリシーと統制を備えます。チームメンバーは、報復を恐れずにやり取りできる必要があります。チームメンバーが安心し、温かい気持ちになると、当事者意識が高まり、生産性が向上する可能性が高くなります。組織がより多様になるほど、顧客を含め、サポートする人々に対する理解が深まります。チームのメンバーが快適で、自由に話し、自分の話を聞いてもらえることを確信すると、自らの貴重な洞察 (マーケティングの機会、アクセシビリティのニーズ、未開拓の市場セグメント、環境内の認識されていないリスクなど) を共有する可能性が高まります。 
  +  チームメンバーが完全に参加できるようにする: 従業員がすべての業務関連活動に完全に参加するために必要なリソースを提供します。日々の課題に直面するチームメンバーは、それを回避するためのスキルを身に付けています。これらの独自に開発したスキルは、組織に大きなメリットをもたらします。チームメンバーに必要な配慮をしてサポートすることで、貢献から得られるメリットが大きくなります。 