# 人と文化
<a name="people-and-culture"></a>

 すべてのワークロードには所有者が必要であり、多くの人やチームがワークロードのライフサイクルに関与している可能性があります。ただし、WAFR を実行する前に、ワークロードのシングルスレッドオーナー (STO) を定義します。

 この担当者は、意思決定を行い、予算、人員、ロードマップを管理できる必要があります。このロールの例は、プロダクトオーナー、プロダクトマネージャー、ヘッドアーキテクト、またはエンジニアリングマネージャーです。

 最終的に、ワークロードが意図したとおりに機能しなくなった場合、このロールが責任を負います。

 成果を向上させるには、STO と共に WAFR を実行することが重要です。例えば、ワークロードの改善項目が見つかったものの、製品ロードマップで優先順位付けがうまくいかない場合があります。または、作業を実行するための資金やリソースの取得に苦労することがあります。

 これは多くの場合、達成不可能なバックログ項目のリストを収集する結果となります。STO は、WAFR を所有し、プロセスに投資しているため、この結果を回避するのに役立ちます。

![シングルスレッドオーナー](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/userguide/images/STO.png)


## 必要なステークホルダー
<a name="required-stakeholders"></a>

 STO はすべての質問に答えることはできません。多くの人々やチームが、ワークロードの設計、開発、保護、運用に関与しています。ワークロードの組織とサイズに応じて、関係するステークホルダーとチームの数は異なります。

![提案された WAFR 参加者の上位に位置するシングルスレッドオーナーを示すチーム構造図](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/userguide/images/WorkloadTeam.png)


 ステークホルダーに関する以下の質問を検討してください。

1.  質問の各カテゴリに回答するために、誰が出席する必要がありますか?

1.  WAFR のどの部分にどのステークホルダーが出席する必要がありますか?

1.  さまざまなステークホルダーに質問について事前に通知するにはどうすればよいですか?

## 柱スポンサー
<a name="pillar-sponsors"></a>

 Well-Architected フレームワークは [6 つの柱](https://docs.aws.amazon.com/wellarchitected/latest/framework/the-pillars-of-the-framework.html)で構成されています。STO の定義は重要ですが、WAFR プロセスの価値を加速および向上させるには、柱固有のスポンサーや推進者からサポートを集めることが重要です。

![6 つの柱固有の推進者の上にシングルスレッド所有者を示すチーム構造図](http://docs.aws.amazon.com/ja_jp/wellarchitected/latest/userguide/images/Champions.png)


 以下のことができる柱のスポンサーまたは推進者を定義します。
+  WAFR の特定部分に参加して情報またはガイダンスを提供する 
+  対象領域の結果を所有する 
+  組織間の戦略的変更を定義、伝達し、効果を挙げる 

 組織には Cloud Center of Excellence または Cloud Community of Practice がありますか? 小規模から始めて、アーキテクチャの健全性に関する議論と改善でお互いをサポートできる同じ考え方の人々のグループを増やします。

## 安全なスペースを作成する
<a name="create-a-safe-space"></a>

 テクノロジーの選択に関する健全で生産的な議論を行うには、健全な組織文化を育むことが不可欠です。WAFR に関与する人々のグループには、ワークロードに新しい人または古い人、在職期間や年功の異なる人、パートナーや第三者として関与しているもいます。永続的で有用な改善の可能性を向上させるには、ワークロードについて健全で敬意のある対話を育むことが重要です。

 最初からポジティブな意図を設定し、全体で再度強調して整合性を維持し、改善の機会の発見に集中します。テクノロジーとベストプラクティスは進化するため、WAFR は改善点を発見する機会として捉える必要があります。

 WAFR は監査ではありません。結果はさまざまなコンプライアンス基準を満たすのに役立ちますが、ワークロードを「スコア化」するプロセスは存在しません。アーキテクチャの健全性の向上に焦点を当てます。

 WAFR は「私たちはどこにいるのか」と問いかけ、ワークロードの特定の時点でのビューをキャプチャする機会です。その後、検出結果を使用して、情報に基づいた意思決定を行い、「どこへ行くべきか」という問いに答えることができます。

 アーキテクチャの改善は、AWS Well-Architected がガイドするジャーニーです。WAFR プロセスを開始するときは、次の質問を考慮してください。

1.  WAFR を実行する理由は何ですか?

1.  そこから何を得たいですか?

1.  エクスペリエンスは全員にどのようなメリットをもたらしますか?

1.  現在どこにいて、どこに行きたいですか?

## リソース
<a name="resources-1"></a>
+  [Accountability Blog Post](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/) 
+  [Amazon Two Pizza Teams](https://aws.amazon.com/executive-insights/content/amazon-two-pizza-team/)