「真の要求を見極めろ！」：teamB リクワイアメント：要求定義 １）要求定義における悩み 顧客側の問題 社内規定、セキュリティ 要件変更等による方針 レベルでの変更発生 決定者／相対が不明確 クライアント多忙による 要求決定の遅れ 要求変更が多い あまりにも期間が短い 曖昧／未確定／ 設計に落とせない要求 ユーザが真に行いたいことは何か？ ・いかに早く要件を定義し、納期/ｺｽﾄ/品質のバラ ンスを取り、顧客が納得のいく見積りを行うか ・前例のない要件に対するリスクを如何に回避す べきか 要求定義を行う上流SE の人材不足 受注側の問題 CMU2005海外エンジニアリングワークショップ参加報告書 講義内容が ヒントになる？？ 運用フェーズを視野に入 れた要求定義がなされ ない 1 「真の要求を見極めろ！」：teamB リクワイアメント：要求定義 ２）要求定義に関するヒント われわれの悩みは、システム構築プロジェクトが本質的に抱えている問題である。（アメリカでも同じこと） ⇒ 顧客要求事項は曖昧な表現が多い ⇒ プロジェクトは要件が膨らみ、納期が遅れ、予算が超過することが多い。 予め「リスクを見越して」計画を立てるべき ※ただし発生率の低そうなリスクは考慮に入れなくてもよい ｢どこに要件の不確実性（リスク）があるか｣ 「システムを取り巻く環境や市場は今後どの様に変化するか」 ＜具体的な解決方法例＞ 【初期の段階でステークホルダ参画】 初期段階でステークホルダを関与させることにより、”サプライズ”を回避 し、ステークホルダー間の意見調整をする。 【早期情報共有】 前例のない要件については、特殊な要求である旨理解してもらい、協 業での対応を依頼する、前例のある要件に、可能な限り近づくよう変 更してもらう 【機能要求と非機能要求】 要求には機能要求と非機能要求があり、非機能要求は事前に想定 することが難しい。 ＊非機能要求の例：コスト削減（金額に見合った要件の削減）、 ：機能追加が容易に行えるシステム構成の確保 ：進捗報告、テスト範囲報告 【プロトタイプ】 不確実な要求に対するリスクを回避するには、早い段階でプロトタイプ などを活用し、実際に動く形でユーザに見せることが有効。 【モデリング】 要求を明確化する表現方法として、ユースケースなどのモデリングが有 効である。 【メタファー】 パワーポイントなどを使用して、視覚的に顧客に訴える CMU2005海外エンジニアリングワークショップ参加報告書 これ重要だと思うんですが、 解決方法例ではないの で。。困り中 一問一答式で なんだか木を見て森を見ずになって しまっているかんじ。。。 2 「真の要求を見極めろ！」：teamB リクワイアメント：要求定義 ２）学んだこと ～具体的 HowTo システム構築プロジェクトが本質的に抱えている問題である。（アメリカでも同じこと） われわれの悩み ＝ 顧客要求事項は曖昧な表現が多い ＝ プロジェクトは要件が膨らみ、納期が遅れ、予算が超過することが多い。 ●非機能的要求に対しては・・・ ・機能的要求： ・ユーザー側要求 要求事項 ・システム作成側要求 ・非機能的要求：予測困難、非システム的、後続フェーズにて問題が拡大化する ＜解決案＞ステークホルダー（エンドユーザー／決済者／テスター／品質管理チーム等）を早期に参画させ、 要求が発生した際に即座に対応出来るよう、要求に答えるための仕掛けや仕組みを確立 ●前例のない要求に対しては・・・ ＊ユーザーに、特殊な要求である旨理解してもらい、協業での対応を依頼する ＊前例のある要件に、可能な限り近づくよう変更してもらう ＊要件を細分化し、一部ずつ実現して行く ＊開発するシステムに関係する者全てを登場させる関係図（ＭＡＰ）を作成する うーんこれもつまらないですね （要求定義のセクションまとめただけですね） ●要求定義のポイントは・・・ ＊曖昧な要求を早期に明確にする（パワーポイントなどを使用して視覚的に顧客に訴える、プロトタイプを提供し確認依頼するなど） ＊実現の厳しい要件に対する妥協点を探る ＊ステークホルダー間の意見調整をする ●長期プロジェクトに対しては・・・ ＊常に先を見越すことが必要である。 CMU2005海外エンジニアリングワークショップ参加報告書 3 「真の要求を見極めろ！」：teamB リクワイアメント：要求定義 ２）学んだこと ～要件定義で重要な考え方 ●Abstruct （抽象化） システム構築の結果は以下のサイクルを繰り返すことにより、もたらされる。 ＊１ ＊２ ＊３ ＊４ 観察（Observe） 方向性の定義（Oriented） 決定（Decide） 実行（Action） これらの概念を取り込んで構成できると 面白いものになるのでは？ 特に抽象化は設計プロセスすべてを通して 当てはめることのできる概念と思い 個人的に面白く感じた部分です。 ただ、Abstructに関して私と川上さんの理解は 共通していたのですが、神谷さんの解釈と 違っていたようです。（＠菊Discuss） レポートからの情報だけでは足りないので一度 レジュメを見直す必要があります。。 抽象化とは、重要な部分のみを引っ張り出し、そこから詳細に落とすことであり、 レイヤー構造から成立している。的を得た的確な抽象化は（ＲＤＢの概念など）はパワフルな概念となり、 コンセプトとして理解されやすい。的を得た的確な抽象化のためには、充分対象物を理解することが必要である。 ●イノベーション 要件定義にもイノベーションが必要！（とおもう） 顧客価値を上げるイノベーションを行うプロセスとして、以下が重要である。 ＊１ 人間について勉強・理解する ＊２ ゴールを設定する（何ができればよいか、何をすべきか） ＊３ ゴールを達成するための方法を考え、その中でどれがベストかを考える ＊１ 成功する（儲かる）イノベーションのためには、技術面よりもまず顧客価値を考えることが重要である。 ＊２ 限られた情報に基づき意志決定を行う場合、ツールはあくまで意思決定の支援のために利用するものである。 ＊３ イノベーションのプロセスにおいて、目的を定めるためには、顧客（消費者）の観察が重要である。 「観察する」というプロセスの位置付けと重要性は、情報システム構築における要件定義においても同様である。 CMU2005海外エンジニアリングワークショップ参加報告書 4 「真の要求を見極めろ！」：teamB リクワイアメント：要求定義 ３）要求定義に関する提言 前ページの ・アブストラクト ・イノベーション の概念を持ってくる・・・とか ＜私見＞ （講義から得たものではないですが） 要件定義におけるポイントは、「目的」を明確にし、早期の段階でシェアすること。 これは河合さんが、ラージケーススタディで学んだこと、としてあげていました。 CMU2005海外エンジニアリングワークショップ参加報告書 5
© Copyright 2024 ExpyDoc
