CMU2005 海外エンジニアリングワークショップ参加報告書 1 「真の要求を見極めろ！」： teamB リクワイアメント：要求定義 １）要求定義におけ る悩み ・いかに早く要件を定義し、納期 / ｺｽﾄ / 品質 のバランスを取り、顧客が納得のいく見積 りを行うか ・前例のない要件に対するリスクを如何に 回避すべきか ユーザが真に行いたいことは何 か？ 社内規定、セキュリ ティ要件変更等によ る方針レベルでの変 更発生 決定者／相対が不明確 要求定義を行う上流 SE の人材不足 運用フェーズを視野 に入れた要求定義が なされない あまりにも期間が短 い 要求変更が多い クライアント多忙 による要求決定の 遅れ 顧客側の問題 受注側の問題 曖昧／未確定／ 設計に落とせない要 求 講義内容が ヒントになる？？

CMU2005 海外エンジニアリングワークショップ参加報告書 2 「真の要求を見極めろ！」： teamB リクワイアメント：要求定義 ２）要求定義に関する ヒント 【プロトタイプ】 不確実な要求に対するリスクを回避するには、早い段階でプ ロトタイプなどを活用し、実際に動く形でユーザに見せるこ とが有効。 【モデリング】 要求を明確化する表現方法として、ユースケースなどのモデ リングが有効である。 【メタファー】 パワーポイントなどを使用して、視覚的に顧客に訴える 【初期の段階でステークホルダ参画】 初期段階でステークホルダを関与させることにより、 ” サプ ライズ ” を回避し、ステークホルダー間の意見調整をする。 【機能要求と非機能要求】 要求には機能要求と非機能要求があり、非機能要求は事前に 想定することが難しい。 ＊非機能要求の例：コスト削減（金額に見合った要件の削 減）、 ：機能追加が容易に行えるシステム 構成の確保 ：進捗報告、テスト範囲報告 ⇒ 顧客要求事項は曖昧な表現が多い ⇒ プロジェクトは要件が膨らみ、納期が遅れ、予算が超過する ことが多い。 われわれの悩みは、システム構築プロジェクトが本質的に抱えている問題である。（アメリカでも同じこと） 予め「リスクを見越して」計画を立てるべき ※ただし発生率の低そうなリスクは考慮に入れなくてもよい ｢どこに要件の不確実性（リスク）があるか｣ 「システムを取り巻く環境や市場は今後どの様に変化 するか」 ＜具体的な解決方法例＞ 【早期情報共有】 前例のない要件については、特殊な要求である旨理解しても らい、協業での対応を依頼する、前例のある要件に、可能な 限り近づくよう変更してもらう これ重要だと思うんで すが、解決方法例では ないので。。困り中 一問一答式で なんだか木を見て森を見ずになって しまっているかんじ。。。

CMU2005 海外エンジニアリングワークショップ参加報告書 3 「真の要求を見極めろ！」： teamB リクワイアメント：要求定義 ２）学んだこと ～具体的 HowTo ＝ 顧客要求事項は曖昧な表現が多い ＝ プロジェクトは要件が膨らみ、納期が遅れ、予算が超過することが 多い。 われわれの悩み システム構築プロジェクトが本質的に抱えている問題である。（アメリ カでも同じこと） 要求事項 ・機能的要求： ・ユーザー側要求 ・システム作成側要求 ・非機能的要求：予測困難、非システム的、後続フェーズにて問題が拡大化する ＜解決案＞ステークホルダー（エンドユーザー／決済者／テスター／品質管理チーム等）を早期に参画させ、 要求が発生した際に即座に対応出来るよう、要求に答えるための仕掛けや仕組みを確立 ● 非機能的要求に対しては・・・ ● 前例のない要求に対しては・・・ ＊ユーザーに、特殊な要求である旨理解してもらい、協業での対応を依頼する ＊前例のある要件に、可能な限り近づくよう変更してもらう ＊要件を細分化し、一部ずつ実現して行く ＊開発するシステムに関係する者全てを登場させる関係図（ＭＡＰ）を作成する ● 要求定義のポイントは・・・ ＊曖昧な要求を早期に明確にする（パワーポイントなどを使用して視覚的に顧客に訴える、プロトタイプを提供し確認依頼するなど） ＊実現の厳しい要件に対する妥協点を探る ＊ステークホルダー間の意見調整をする ● 長期プロジェクトに対しては・・・ ＊常に先を見越すことが必要である。 うーんこれもつまらないですね （要求定義のセクションまとめただけですね）

CMU2005 海外エンジニアリングワークショップ参加報告書 4 「真の要求を見極めろ！」： teamB リクワイアメント：要求定義 ２）学んだこと ～要件定義で重要な考え方 これらの概念を取り込んで構成できると 面白いものになるのでは？ 特に抽象化は設計プロセスすべてを通して 当てはめることのできる概念と思い 個人的に面白く感じた部分です。 ただ、 Abstruct に関して私と川上さんの理解は 共通していたのですが、神谷さんの解釈と 違っていたようです。（＠菊 Discuss ） レポートからの情報だけでは足りないので一度 レジュメを見直す必要があります。。 ● Abstruct （抽象化） システム構築の結果は以下のサイクルを繰り返すことにより、もたらされる。 ＊１ 観察（ Observe ） ＊２ 方向性の定義（ Oriented ） ＊３ 決定（ Decide ） ＊４ 実行（ Action ） 抽象化とは、重要な部分のみを引っ張り出し、そこから詳細に落とすことであり、 レイヤー構造から成立している。的を得た的確な抽象化は（ＲＤＢの概念など）はパワフルな概念となり、 コンセプトとして理解されやすい。的を得た的確な抽象化のためには、充分対象物を理解することが必要である。 ● イノベーション 要件定義にもイノベーションが必要！（とおもう） 顧客価値を上げるイノベーションを行うプロセスとして、以下が重要である。 ＊１ 人間について勉強・理解する ＊２ ゴールを設定する（何ができればよいか、何をすべきか） ＊３ ゴールを達成するための方法を考え、その中でどれがベストかを考える ＊１ 成功する（儲かる）イノベーションのためには、技術面よりもまず顧客価値を考えることが重要である。 ＊２ 限られた情報に基づき意志決定を行う場合、ツールはあくまで意思決定の支援のために利用するものである。 ＊３ イノベーションのプロセスにおいて、目的を定めるためには、顧客（消費者）の観察が重要である。 「観察する」というプロセスの位置付けと重要性は、情報システム構築における要件定義においても同様である。

CMU2005 海外エンジニアリングワークショップ参加報告書 5 「真の要求を見極めろ！」： teamB リクワイアメント：要求定義 ３）要求定義に関する 提言 前ページの ・アブストラクト ・イノベーション の概念を持ってくる・・・とか ＜私見＞ （講義から得たものではないですが） 要件定義におけるポイントは、「目的」を明確にし、早期の段階でシェアすること。 これは河合さんが、ラージケーススタディで学んだこと、としてあげていました。