わかったつもりでハマりがちな罠を理解したうえで、要件定義を行う方法

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

はじめに

健康に気を付けている人でも、スーパーに行くと、健康に良くないものを購入してしまう ことがある。買い物をする時、全ての商品を比較検討することはできず、目についた商品やセール品などを購入することが多い。

渋滞にはまってしまった場合、余計なう回路を選択し、かえって、目的地に到着するのが遅くなる ことがある。常に最適なルートを選択するとは限らず、目の前の状況に合わせて行動することが多い。

投資家は全ての情報を収集することはできず、過去の経験や 直感に基づいて 投資判断を行うことが多い。

限定合理性の概念は、人間の意思決定が完全に合理的であるという従来の仮定に対するリアリスティックな代替案を提供し、多様な分野での 意思決定プロセスの改善に貢献 しています。

今回は、ハマりがちな罠を理解したうえで、要件定義を行う方法について、模索した結果をまとめさせて頂きました。要件定義の参考になれば、幸いです。

目次

1. はじめに
2. わかったつもりでハマりがちな罠
3. 限定合理性
4. 考え方
5. 満足化のプロセス
6. 理論の特徴を理解する
7. 限定合理性を理解した要件定義
8. フレームワークで要件定義を行う　Well-Architected Framework

わかったつもりでハマりがちな罠

フレーム依存

知っているフレームワークでの考え方に固執してしまい、新しい考え方を受け入れる発想を放棄してしまう。問題の捉え方によって、意思決定が変わる。

ヒューリスティック

過去の勝ちパターンに囚われてしまい、融通が利かなくなる。経験や直感に基づいて迅速に判断を下す。

サティスファイシング

やっているうちに、めんどくさくなる。完璧ではなくても、ある程度満足できる選択肢を選ぶ。

過剰な自信

人の良い意見が出ても、聞き流してしまう。自分の判断を過信し、リスクを過小評価する。

限定合理性

ハーバート・サイモン（Herbert A. Simon）は、経済学、心理学、人工知能、経営学など多岐にわたる分野で活躍したアメリカの学者であり、1978年には経済学のノーベル賞を受賞しています。彼の研究は、人間の意思決定プロセスに関するもので、特に「限定合理性（bounded rationality）」の概念で知られています。

限定合理性の考え方
サイモンが提唱した限定合理性の概念は、人間が完全な情報や無限の時間、計算能力を持っているわけではないため、完全に合理的な意思決定を行うことはできないという考え方です。代わりに、人間は利用可能な情報と自身の認知能力の限界の中で最善の選択を試みますが、それは必ずしも最適な選択とは限りません。

従来の経済学では、人は完全な情報に基づいて、論理的に最適な意思決定を行うと仮定されていました。しかし、サイモンは、人間は情報処理能力や計算能力に限界があり、現実世界では全ての情報収集や分析は不可能であることを指摘しました。

そのため、人は限られた情報や時間の中で、「十分に良い」 と判断できる選択肢を選択すると考えました。これが、限定合理性と呼ばれるものです。

考え方

サイモンの理論における「Why」、つまり「なぜ」という問いは、人間が特定の選択をする理由を理解することに関連しています。彼は、人間が目標を達成するために行動する際、完全な合理性ではなく、実際には多くの制約の中で「満足化（satisficing）」というプロセスを通じて意思決定を行うと指摘しました。

満足化のプロセス

満足化は、サイモンが提唱した意思決定の概念で、人間が完全な最適化ではなく、ある程度の満足をもたらす解決策を選択するプロセスを指します。つまり、人間はすべての選択肢を評価するのではなく、自分の基準を満たす最初の選択肢を選ぶ傾向があります。

サイモンの考え方は、人間の意思決定が合理的であるという従来の経済学の仮定に挑戦し、実際の意思決定が どのように行われるか についての新しい理解を提供しました。彼の理論は、経営学や意思決定理論、人工知能の分野で広く応用されており、現代の意思決定研究の基礎を築いたとされています。

理論の特徴を理解する

認識能力の限界

人間は、一度に処理できる情報量に限界があります。そのため、複雑な状況では、必要な情報を見逃したり、誤解したりすることがあります。例えば、多くの選択肢が提示された場合、全てを比較検討することは難しく、情報量が多いほど意思決定の質が低下する傾向があります。

計算能力の限界

人間は複雑な計算を苦手とし、最適な選択肢を導き出すことが難しい。例えば、複数の要因が複雑に絡み合った意思決定問題の場合、最適な解を導き出すための計算量が多くなり、人間にとっては処理しきれない可能性があります。

時間的制約

意思決定には時間がかかるが、常に十分な時間が確保できるとは限らない。例えば、緊急事態の場合、迅速な意思決定が求められますが、十分な情報収集や分析を行う時間が限られていることがあります。

不確実性への対応

未来は不確実であり、完全な情報に基づいて意思決定することはできない。例えば、投資判断を行う場合、将来の市場動向を完璧に予測することは不可能であり、不確実性の中で意思決定を行う必要があります。

心理的なバイアス

人間の認知には様々なバイアスがあり、合理的な意思決定を妨げる。例えば、確証バイアス（自分の意見を裏付ける情報ばかりを集めてしまう）、アンカリングバイアス（最初の情報に引きずられてしまう）、現状維持バイアス（変化を避ける傾向がある）などが挙げられます。

満足探索

人は必ずしも最適な選択肢を選択するわけではなく、ある程度満足できる選択肢を見つければ、そこで意思決定を終了してしまうことがある。例えば、買い物をする場合、全ての選択肢を比較検討するのではなく、ある程度気に入った商品を見つければ、そこで購入してしまうことがあります。

手段の合理性

人は必ずしも目的を達成するための最善の方法を選択するわけではなく、自分が知っている方法や慣れている方法を選択してしまうことがある。例えば、新しいソフトウェアを使う場合、最も効率的な方法ではなく、自分が慣れている方法を選択してしまうことがあります。

限定合理性を理解した要件定義

限定合理性を理解した要件定義とは、意思決定者が完全な情報や無限の時間、計算能力を持っていないという前提に立ち、実際の制約の中で最善の選択を試みるプロセスを指します。このアプローチは、意思決定者が直面する情報の不完全性、認知の制約、時間の制約を認識し、それらを考慮に入れた上で要件を定義することを意味します。

限定合理性を理解した要件定義のステップ

1. 情報の限界を認識する

   • 利用可能な情報に基づいて要件を定義し、不確実性や未知の要素を認識する。情報収集は完全ではないため、変更や調整が必要になる可能性を受け入れる。

2. 認知の制約を考慮する

   • 意思決定者の認知能力には限界があるため、複雑な要件を単純化し、理解しやすい形で定義する。重要な要件に焦点を当て、優先順位を設定する。

3. 時間の制約に対応する

   • 意思決定には時間的な制約があるため、迅速な要件定義を行い、必要に応じて追加の情報を取り入れることができる柔軟性を持たせる。

4. 満足化（Satisficing）を目指す

   • 最適な解決策ではなく、「十分に良い」解決策を目指す。プロジェクトの目的を満たし、実現可能な要件を定義する。

5. 目標指向性を維持する

   • プロジェクトの目的やビジョンを明確にし、それに基づいて要件を定義する。目標を達成するための実用的な要件に焦点を当てる。

6. 適応性を確保する

   • 環境や状況の変化に応じて要件を適応させる能力を持つ。要件定義プロセスにおいて、フィードバックループを設け、継続的な改善を行う。

限定合理性を理解した要件定義の例

プロジェクト: 新しいソフトウェアアプリケーションの開発

• Why（目的） ユーザーの作業効率を向上させるためのソフトウェアを開発する。
• How（方法） 利用可能な技術とリソースを考慮し、ユーザーフレンドリーなインターフェースを持つアプリケーションを設計する。
• What（具体的な要件） 基本的な機能を備えたプロトタイプを開発し、ユーザーテストを通じて要件を洗練させる。

このアプローチにより、プロジェクトチームは現実的な制約の中で効果的な要件定義を行い、プロジェクトの成功に向けて柔軟かつ実践的な戦略を立てることができます。

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

AWS Well-Architected Frameworkを用いて限定合理性を理解した要件定義を行う

情報の限界を認識する

• 利用可能なAWSのドキュメント、ベストプラクティス、ケーススタディを参照しながら、クラウドアーキテクチャの要件を定義します。
• 完全な情報が得られない場合は、AWSのサポートやコミュニティフォーラムで追加の情報を求めます。

認知の制約を考慮する

• AWSのサービスとツールの複雑さを理解し、チームの技術的な能力に合わせて適切なサービスを選択します。
• AWS Well-Architected Toolを使用して、アーキテクチャのレビューを行い、改善点を特定します。

時間の制約に対応する

• プロジェクトのタイムラインに基づいて、実行可能な要件を優先します。
• AWSのマネージドサービスを活用して、インフラの構築と管理にかかる時間を短縮します。

満足化（Satisficing）を目指す

• 最適なソリューションではなく、プロジェクトの目的を満たす「十分に良い」ソリューションを選択します。
• AWSのコスト効率の良いサービスを利用して、コスト最適化を図ります。

目標指向性を維持する

• プロジェクトのビジネス目標とAWS Well-Architected Frameworkの5つの柱（運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化）を照らし合わせて要件を定義します。

適応性を確保する

• AWSのサービスが提供するスケーラビリティと柔軟性を活用して、変化するビジネスニーズや市場の動向に迅速に対応します。
• 定期的なアーキテクチャのレビューを行い、必要に応じて要件を調整します。

具体的な要件定義の例

プロジェクト: 新しいウェブアプリケーションの開発

• Why（目的） 顧客にオンラインでのシームレスなサービス体験を提供するために、スケーラブルなウェブアプリケーションを開発する。
• How（方法） AWS Elastic Beanstalkを使用してアプリケーションのデプロイを自動化し、Amazon RDSでデータベースを管理する。
• What（具体的な要件） ユーザーがリアルタイムで情報を交換できるインタラクティブなインターフェースを持つウェブアプリケーションを提供する。また、Amazon CloudFrontを使用してコンテンツ配信を最適化し、グローバルなユーザーに対応する。

このアプローチにより、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