CMU2005 海外エンジニアリングワークショップ参加報告書 1 「真の要求を見極めろ！」： teamB 要求定義をどう捉えるか ● 要求定義とは何か？ 製品には、顧客の望むことを正しく反映させる必要がある。 そのために必要なものが要求仕様である。 すなわち、要求仕様とは、顧客と製品を結ぶものであり、これを作ることが要求定義である。 ● 要求定義プロセスにおける課題 要求を定義するプロセスにおける大きな課題として、次の二つが挙げられる。 １．各ステークホルダーからの要求の変化や曖昧さに如何に対処すべきか？ ２．様々な利害の衝突に如何に対処すべきか？ 主な対立軸の例 ・リスク／創造性／変化 VS 安定性 ・コスト VS 品質 ・コスト VS 創造性 ● システム構築を以下のサイクルを繰り返しとして捉えることが有効である。 すなわち、自分の仕事を、以下のサイクルの繰り返しとして再定義してみること。 １． 観察（ Observation ） ２． 方向付け（ Orientation ） ３． 決定（ Decision ） ４． 実行（ Action ） マクロレベル、ミクロレベルのいずれについても、 OODA のサイクルを当てはめることは出来るはずである。 PDCA が計画先行の発想であるのに対して、 OODA はデータ分析による将来予測に基づいて現在の行動を決定するという発想で あり、 リスクを軽減させることが出来る。
CMU2005 海外エンジニアリングワークショップ参加報告書 2 「真の要求を見極めろ！」： teamB 要求定義における OODA サイクル ● 観察（ Observation ） 「技術・モノ」ではなく「人」を観察する。 観察することによって、 ・顧客価値を発見（あるいは創出）する ・問題の境界が明らかになってくる（明らかにしていく） ● 方向付け（ Orientation ） 観察の結果を、システムへの要求に落とし込んでいく必要がある。 だが、ソフトウェアには制限がなく、複雑なものである。複雑なものを複雑なままで扱うのはとても難しい。 そのため、観察の結果をシステムへの要求に落とし込むためには、抽象化が役に立つ。 すなわち、観察の結果から詳細を削ぎ落として、重要なもののみを引っ張り出す。 ● 決定（ Decision ）＆実行（ Action ） ※要求定義においては、決定と実行を分離しにくいのではないだろうか？？？ システムには、数多くのステークホルダーが存在する。 それらのステークホルダーには、早い段階から意思決定のプロセスに参画して貰う。 そのプロセスに関与しなかったステークホルダーについても、早めにコミットメントを得ておくことは必要である。
CMU2005 海外エンジニアリングワークショップ参加報告書 3 「真の要求を見極めろ！」： teamB その他の重要なこと ● 抽象化 抽象化とは、詳細を見ずに重要なものだけを引っ張り出すことである。 全てを見ることが不可能である以上、何を見るかということだけではなく、何を見ないかということが非常に重要である。 すなわち、見るものと見ないものの境界を確定させて、問題の範囲を明確にするということである。 → 講義の中では、主に設計における抽象化の話が中心ではあったが、これは要求定義の中での観察や方向付けにも 役に立つ概念ではないだろうか。 ● 要求定義におけるイノベーション ＊革新的な設計はリスクを伴う。 一方、要求を明確にすることは、リスクを軽減させることにつながる。 従って、革新的な設計を実践するためにも、要求定義は重要である。 ＊ビジネスにおけるイノベーションとは、技術よりもむしろ、如何にして顧客価値を高められるか、あるいは、創出出来るか という点にかかっている。 ● 機能要求と非機能要求 ＊機能要求の他に非機能要求があるということを意識し、顧客が明示する要求以外にも、｢どこに要求の不確実性があるか」、 「システムを取り巻く環境や市場は今後どの様に変化するか」といったことを予め考慮する必要がある。 ● 各プロセスでのデータ計測および蓄積 ＊ OODA は、分析結果に基づいて現在の行動を決定する。優れた分析を行うためには、過去のプロジェクトデータの計測・蓄 積が不可欠である。 ● ソフトウェアのサプライチェーン ＊どこにどのようなステークホルダーが存在するのかを明らかにするためには、システム開発をサプライチェーンという観点 で見てみると良い。 ● プロジェクトの分割 ＊プロジェクトを短いスパンに分割し、マイルストーンを設定する。そのマイルストーン毎に、ステークホルダーのコミット メントを得ていく。