こじれない要件定義を行う方法(顧客は何に悩んでいるのか？をU理論で紐解き、Well-Architected Frameworkに落とし込む)

顧客に寄りそった要件定義とWell-Architected Frameworkを考える(4/6)

はじめに

U理論（Theory U）は、組織変革とリーダーシップに関する理論で、MITのオットー・シャーマー（Otto Scharmer）によって提唱されました。この理論は、個人や組織が直面する深い変化のプロセスを理解し、未来の可能性を引き出すための枠組みを提供します。

今回は、ファシリテーション手法として有名なU理論を用いて、こじれない要件定義を行う方法について、模索した結果をまとめさせて頂きました。要件定義の参考になれば、幸いです。

目次

1. はじめに
2. U理論の基本的な考え方
3. 理論の応用
4. 理論を構成する5つの段階
5. 理論の特徴
6. 理論の活用例
7. 要件定義を行う
8. フレームワークで要件定義を行う　Well-Architected Framework

競争ではなく、共創である事が求めれれる事もある。

U理論の基本的な考え方

U理論は、変化のプロセスを「Uの字型」のカーブとして表現します。このカーブは、三つの主要なフェーズから成り立ちます。

ひとつめ　感じる（Sensing）

• 現状の認識を深め、周囲の環境や他者との関係性に対する深い理解を得るフェーズです。この段階では、既存の思考パターンや前提を手放し、新しい情報や視点に開かれることが求められます。過去の勝ちパターンや負けパターンに囚われず、素直に問題を見つめられるか？が問われます。

ふたつめ 凍結解除（Presencing）

• Uの底部にあたるこのフェーズでは、内省と瞑想を通じて、自己と深く向き合い、本質的な目的や使命を見出します。ここで「プレゼンシング」と呼ばれる瞬間が生じ、過去の枠を超えた新たな未来の可能性が見えてきます。過去や未来に目を向けず、一旦、現実がどうなのかにフォーカスして考えられるか？が問われます。

みっつめ 実現化（Realizing）

• 新たに得られた洞察をもとに、具体的な行動や実践に移すフェーズです。ここでは、創造的なアイデアを形にし、実際の変化を起こすためのプロジェクトやイニシアティブが展開されます。 偏見やしがらみにより、妨害を受けることを受け止め、それを乗り越えられるか？が問われます。 独りよがりにならない事が重要です。ここで求められるのは、競争ではなく、共創です。

理論の応用

U理論は、個人の成長、組織開発、社会変革など、さまざまな分野で応用されています。リーダーシップ開発においては、リーダーが自己の内面に深くアクセスし、より効果的な行動を取るための 洞察を得る ことを支援します。組織変革では、組織が直面する課題を根本から理解し、持続可能な解決策を生み出すためのプロセスとして活用されます。
U理論は、単に問題を解決するだけでなく、より深いレベルでの変化を促すことを目指しており、そのプロセスはしばしば変革的な学習やイノベーションをもたらすとされています。この理論は、個人や組織が未来を形作るための 新しい視点と方法を提供する ことを目的としています。

理論を構成する5つの段階

Ⅰ.ダウンロード

過去の経験や知識に基づいて問題を分析し、解決策を模索する段階。

Ⅱ.リフレクティング

自分の思考や感情を客観的に観察し、偏見や思い込みを認識する段階。

Ⅲ.リリージング

過去の経験や知識、思考、感情を手放し、オープンな状態になる段階。

Ⅳ.プレゼンシング

自分の思考や感情を超えた深いレベルの意識状態に入り、全体とのつながりを体感する段階。

Ⅴクリエーション

プレゼンシングを通じて得られた洞察に基づいて、新しいアイデアや解決策を生み出す段階。

U理論は、個人、チーム、組織、社会など、様々なレベルで変革を起こすために活用することができます。

理論の特徴

内面の変容を重視

問題解決よりも、まず自分自身の内面を変容させることに焦点を当てる。外的な状況を変えるのではない。

直観や内なる声に耳を傾ける

論理的な思考だけでなく、直観や感情、身体感覚なども情報として取り入れる。

多様な視点を取り入れる

異なる立場や価値観を持つ人々の意見を取り入れる。

全体性を見る

個々の要素だけでなく、全体との繋がりを意識する。

共創

関係者全員が参加し、協働して変革を起こす。

理論の活用例

理論は、様々な分野で活用されている。

企業

イノベーションの創出(社員一人ひとりが内省し、新たな視点やアイデアを導き出す)、組織変革(組織全体が共有するビジョンを描き、そこに到達するための具体的な行動計画を策定する)、リーダーシップ開発(リーダーが自分自身と向き合い、内面的な変容を起こすことで、より効果的なリーダーシップを発揮する)など

教育

学習意欲の向上(主体的に学習に取り組むため)、問題解決能力の向上(複雑な課題に直面した際に、論理的に思考し、解決策を見つける能力を養う)、創造性の育成(固定観念にとらわれず、自由に発想し、創造的な作品を生み出す力を育む)など

行政

政策立案(市民のニーズを深く理解し、より効果的な政策を立案する)、公共サービスの改善(利用者一人ひとりの声を聞き、より満足度の高い公共サービスを提供する)、市民参加の促進(市民が行政の意思決定過程に積極的に参加できる環境づくりを行う)など

地域社会

地域課題の解決(地域住民が一体となって、地域課題の解決に取り組む)、コミュニティの活性化(互いを尊重し、支え合う地域社会を築く)、持続可能な社会づくり(社会課題を解決するための新たなアイデアや仕組みを生み出す)など

U理論は、複雑な課題や変化に対応し、持続可能な未来を創造するためのパワフルなツールです。

要件定義を行う

U理論（Theory U）を使って要件定義を行う場合、プロセスは内省的であり、組織やプロジェクトチームが深いレベルでの変化を経験し、未来の可能性を引き出すことを目指します。

U理論を用いた要件定義のステップ

感じる（Sensing）

この段階では、プロジェクトチームは現状を深く観察し、顧客や利害関係者のニーズや課題を感じ取ります。チームは、外部の声に耳を傾け、市場の動向や技術の進歩、競合の状況などを理解することから始めます。

• 要件定義のための質問
  • 顧客は何に悩んでいるのか？
  • 現在の市場で満たされていないニーズは何か？
  • 利害関係者はどのような解決策を求めているのか？

凍結解除（Presencing）

チームは内省し、自身の経験や直感から得られる洞察を通じて、プロジェクトの本質的な目的やビジョンを明確にします。この段階で、チームは「なぜこのプロジェクトが重要なのか」という根本的な質問に答えます。

• 要件定義のための質問
  • このプロジェクトを通じて達成したいことは何か？
  • プロジェクトの成功がもたらす影響は何か？
  • プロジェクトの深い意義や目的は何か？

実現化（Realizing）

チームは得られた洞察をもとに、具体的な要件やアクションプランを策定します。この段階では、プロジェクトの目的に沿った機能、性能、デザインなどの要件を定義し、それを実現するための戦略や計画を立てます。

• 要件定義のための質問
  • どのような機能や特性がプロジェクトの目的を実現するのに必要か？
  • どのような技術やリソースが必要か？
  • どのようなタイムラインやマイルストーンを設定するべきか？

U理論を用いた要件定義は、単に技術的な要件をリストアップするのではなく、プロジェクトの深い目的や意義を理解し、それに基づいて要件を策定するプロセスです。このアプローチは、チームがより意味のある、影響力の高いプロジェクトを実現するための基盤を築くのに役立ちます。

フレームワークで要件定義を行う

AWS Well-Architected Frameworkを用いた要件定義の例を示します。このフレームワークは、クラウドアーキテクチャの設計におけるベストプラクティスを提供し、信頼性、セキュリティ、効率性、コスト最適化、持続可能性の5つの柱に基づいています。

要件定義のステップ

1. 信頼性（Reliability）

   • 目的: システムが意図したとおりに機能し、障害から迅速に回復する能力を確保する。
   • 要件: 自動フェイルオーバー、バックアップとリカバリプロセス、マルチAZデプロイメント。

2. セキュリティ（Security）

   • 目的: システムとデータを保護し、脅威から守る。
   • 要件: IAMポリシー、暗号化、ネットワークセキュリティ、アクセス制御、監査ログ。

3. パフォーマンス効率（Performance Efficiency）

   • 目的: コンピューティングリソースを最適に使用し、システムのスケーラビリティを確保する。
   • 要件: 適切なインスタンスタイプの選択、オートスケーリング、負荷分散、キャッシング戦略。

4. コスト最適化（Cost Optimization）

   • 目的: コストを最小限に抑えつつ、ビジネス価値を最大化する。
   • 要件: リソースの使用状況とコストの監視、リザーブドインスタンスやスポットインスタンスの利用、不要なリソースの削減。

5. 持続可能性（Sustainability）

   • 目的: 効率の良いリソースを使用する。
   • 要件: 効率の高いサービスの選択、リソースの最適化、環境に配慮した運用。

具体的な要件定義の例

• 信頼性 自動バックアップを行うAmazon RDSインスタンスをデプロイし、アプリケーションの状態を監視するAmazon CloudWatchアラームを設定します。
• セキュリティ Amazon S3バケットにサーバーサイド暗号化を適用し、Amazon VPC内での通信を制限するセキュリティグループとネットワークACLを設定します。
• パフォーマンス効率 Amazon EC2 Auto Scalingを使用して、トラフィックの増減に応じてインスタンス数を自動調整します。
• コスト最適化 AWS Cost Explorerを使用してコストを監視し、使用されていないEC2インスタンスを特定して停止します。
• 持続可能性 AWSの持続可能性のベストプラクティスに従い、リージョン選択やサービス選択を行います。

AWS Well-Architected Frameworkを用いた要件定義は、クラウドリソースの選択と設計において、最適なパフォーマンスとコスト効率を実現するためのガイドラインを提供します。これにより、ビジネスのニーズに合わせた持続可能で効率的なクラウドアーキテクチャを構築することができます。

読んで頂きまして、ありがとうございました。

顧客に寄りそった要件定義とWell-Architected Frameworkを考える(1/6)　
https://qiita.com/kimuni-i/items/aff6339130f160de16af

顧客に寄りそった要件定義とWell-Architected Frameworkを考える(2/6)
https://qiita.com/kimuni-i/items/4da6a2c91a5ecdf2c526

顧客に寄りそった要件定義とWell-Architected Frameworkを考える(3/6)
https://qiita.com/kimuni-i/items/1760874d6eec96fe75d7

顧客に寄りそった要件定義とWell-Architected Frameworkを考える(4/6)
https://qiita.com/kimuni-i/items/496ae4d41c8098f32f21

顧客に寄りそった要件定義とWell-Architected Frameworkを考える(5/6)
https://qiita.com/kimuni-i/items/a893228ce1ab52d3133e

顧客に寄りそった要件定義とWell-Architected Frameworkを考える(6/6)
https://qiita.com/kimuni-i/items/8dadc65f38d06a960f1a

AWS Well-Architected アーキテクチャのベストプラクティスを使う
https://qiita.com/kimuni-i/items/9f08f382ad73a03f601d