Center 2 目次 5. まとめ 1. なぜ要求工学が大切なのか? 2. REBOK とは何か? 4. REBOK を現場で活かすには 3. REBOK に基づく要求獲得

Size: px

Start display at page:

Download "Center 2 目次 5. まとめ 1. なぜ要求工学が大切なのか? 2. REBOK とは何か? 4. REBOK を現場で活かすには 3. REBOK に基づく要求獲得"

たつやみやのじょう
8 years ago
Views:

1 Center 1 Software Engineering Center Information-technology Promotion Agency, Japan 要求工学知識体系 (REBOK) 概説独立行政法人情報処理推進機構技術本部ソフトウェアエンジニアリングセンター

2 Center 2 目次 5. まとめ 1. なぜ要求工学が大切なのか? 2. REBOK とは何か? 4. REBOK を現場で活かすには 3. REBOK に基づく要求獲得

3 Center 3 なぜ要求工学が大切なのか?

4 プロジェクトの失敗原因の多くは要求に起因する Q 品質問題の原因 ( 複数回答可 ) 要件定義が十分でなかった 35.9% 36.7% システム企画が十分でなかった 18.7% 16.7% C 予算オーバの原因 ( 複数回答可 ) 追加の企画作業が発生した 28.0% 32.6% D 納期遅れの原因 ( 複数回答可 ) 要件定義が計画より長引いた 37.7% 43.6% 企画作業が長引いた 22.7% 16.2% 2003 年 2008 年日経コンピュータ特集プロジェクト成功率は 26.7% 日経コンピュータ特集プロジェクト成功率は 31.1% Center 4

5 プロジェクトの失敗原因の多くは要求に起因する要件に問題があった場合全開発費の 30~50% を消費 Boehm,Barry W.,and Philip N.Papaccio:IEEE Transactions on (1988) 手戻り原因の 82% が要件関連の不具合である Dean Leffingwell:Calculating the Return on Investment frommore Effective Requirements Management(1997) プロジェクト中止の原因のうち要件 ( 要求や仕様 ) が不完全 13.1% 要件 ( 要求や仕様 ) の変更 8.7% Standish Group's annual CHAOS report(1995) Center 5

6 要件定義の投資効果全開発費における要件定義に割くコストの効果要件定義のコスト配分比率コスト超過比率開発コスト超過の比率 2~3% 80~200% 8~12% 0~50% 200% B. B. Roberts, et al., The Benefit of Integrated, Quantitative Risk Management, INCOSE, 要件定義が不十分 100% 0% 10% 20% 青山幹雄 : 要求工学知識体系 (REBOK) 顧客要求をシステム開発へ活かす Win-Win Way 資料を参考に作成要件定義のコスト配分比率 Center 6

7 Center 7 要件定義にコストを割くだけでよいのか要件定義を効率的効果的に実施する必要がある

8 Center 8 REBOK とは何か?

9 REBOK 公開に至る活動経緯 JISA 要求工学調査検討 WG の活動 : のべ 100 名以上が参画 2006 年度 : 要求開発の組織的取り組み 2007 年度 : 要求工学ベストプラクティスの収集と整理 2008 年度 :REBOKの検討とユーザにおける事例収集 JISA REBOK WG の設立による REBOK 策定現場の視点から要求工学のグローバルな知識ベースの活用 JISA 要求工学シンポジウムからのフィードバック学会国際会議での発表と討議によるレビュー 2010 年要求工学国際会議 REBOK 特別セッション 2011 年 6 月要求工学知識体系 (REBOK) 第 1 版刊行 - アールイーボックとお読みください Center 9

10 REBOK のミッション要求工学の全体像 ( 地図 ) を示すスコープビジネス / プロダクト要求システム要求ソフトウェア要求ビジネス要求をシステム / ソフトウェア要求へ繋げる要求展開ビジネス要求からシステム要求ソフトウェア要求へ展開人材育成初心者から高度専門家へビジネス要求システム要求ソフトウェア要求ソフトウェア開発 BABOK CBAP REBOK SWEBOK CSDP( 高度専門家 ) CSDA( 準専門家 ) Center 10

11 Center 11 REBOK の要求工学プロセス REBOK 共通知識カテゴリ要求の計画と管理要求獲得獲得要求要求開発要求の源泉 REBOK 拡張知識カテゴリ要求分析エンタープライズ分析プロダクト分析分析要求要求仕様化要求仕様化要求の検証妥当性確認評価システム構築基礎知識要求工学プロセス要求工学の基礎実践知識実践の考慮点

12 REBOK コア ( 共通知識カテゴリ ) の 8 知識領域 SWEBOK を基礎に要求工学の内容を強化した知識体系知識カテゴリ : 共通のコア知識とドメインとの接点となる拡張とに分離要求工学知識体系共通知識カテゴリ拡張知識カテゴリ 1. 要求工学の基礎 3. 要求獲得 5. 要求仕様化 7. 要求の計画と管理 2. 要求工学プロセス 4. 要求分析 6. 要求の検証妥当性確認評価 8. 実践の考慮点 Center 12

13 Center 13 REBOK コア ( 共通知識カテゴリ ) の 8 知識領域知識領域要求工学の基礎要求工学プロセス要求獲得要求分析要求仕様化要求の検証妥当性の確認評価要求の計画と管理実践の考慮点内容要求とそのスコープや性質などの基礎的な事項要求と管理のプロセスと主要なアクティビティなどに関する知識顧客を含むステークホルダーを明らかにし会議やインタビューなどを通して要求を引き出す技術に関する知識要求事項を整理しその間の関係づけ優先順位付けなどを行い実現すべき要求を明らかにして絞り込みに関する知識分析された要求を規定の書式や表記法で記述する技術に関する知識要求間の矛盾がないことや必要な顧客の要求項目を満たしていることの確認あるいはその達成の度合いを評価する技術などに関する知識要求管理を計画し遂行や成果物を管理する技術に関する知識要求工学を実践する上で知っておくべき知識やベストプラクティス

14 Center 14 REBOK に基づく要求開発要求開発 : 要求の獲得から妥当性確認に至る絞り込みと整合企業戦略製品戦略ステークホルダのビュー ( 要求の源泉 ) ステークホルダ A, X の要求既存システム製品に関する文書要求獲得要求の集まり文書化された要求の集まり要求分析要求仕様化要求の検証妥当性確認評価分析され構造化された要求仕様化された要求検証され合意された要求ベンダのビュー

15 Center 15 REBOK に基づく要求獲得

16 一回で要求は獲得できません要求はリニアなプロセスでは獲得できません要求工学プロセスを何度も繰り返すことでよい要求を作ることができます Center 16

17 Center 17 一回で要求は獲得できません要求管理要求獲得抽出変更追跡ステークホルダの識別要求抽出再利用ネゴシエーションテスト実行要求のモデル化要求検証インパクト分析技術要素分析リスク分析仕様の記述仕様化要求記述大西淳 : 要求工学ワーキンググループ活動報告情報処理学会研究会報告 2001-SE ,pp ,2001

18 Center 18 一回で要求は獲得できませんステークホルダ要求 ( ユーザ要求 ) ビジネス要求ビジネス要求定義書システム要求システム要求定義書ソフトウェア要求ソフトウェア要求定義書

19 Center 19 要求獲得プロセス 5. 課題解決に向けたゴールの抽出 4. 課題の抽出と原因分析 6. ゴールを達成する手段の抽出 3. 現状システムのモデル化 7. 実現すべき将来システムのモデル化 2. 現状システムの理解 1. ステークホルダの識別 8. 要求の記述と詳細化

20 Center 20 要求獲得プロセス 2. 現状システムの理解 3. 現状システムのモデル化 4. 課題の抽出と原因分析 5. 課題解決にむけたゴールの抽出 6. ゴールを達成する手段の抽出 7. 実現すべき将来システムのモデル化 8. 要求の記述と詳細化現行業務で実現している範囲現行システムで実現している範囲ビジネス ( プロジェクト ) の目標目的現行廃止範囲外の要求新規の要求現行変更の要求暗黙の要求 ( 現行どおり ) 改革改善が必要な領域新業務で実現している範囲新システムで実現している範囲新業務で実現する範囲新システムで実現する範囲新業務で実現する範囲新システムで実現する範囲制約により実現されない領域実現案 1 実現案 2 実現案 3 新業務で実現する範囲新システムで実現する範囲要求の実現範囲 ( 確定 ) 選択された実現案カット要求開発管理ベストプラクティスとその体系化の調査研究 CSK システムズにおける要求定義と要件定義の事例を参考に作成

21 要求獲得で取り扱う技術 1. ステークホルダーの識別オニオンモデルステークホルダマトリクスペルソナ 2. 現状システムの理解シナリオユーザストーリーエスノメソドロジエスノグラフィエルゴノミクス文献調査 3. 現状システムのモデル化タスク分析ビジネスモデリングエンタープライズアーキテクチャシステムダイナミクス 4. 課題の抽出と原因分析リッチピクチャーグループインタビューインタビュー役割分析ロールプレイングブレインストーミング KJ 法 5. 課題解決に向けたゴールの抽出 CATWOE 分析 KJ 法アブダクションゴール指向分析 6. ゴールを達成する手段の抽出ゴール指向分析 7. 実現すべき将来システムのモデル化システムダイナミクス 8. 要求の記述と詳細化トローリングプロトタイピングモックアップ安全性セキュリティ要求を抽出する技術クレーム分析 Center 21

22 ステークホルダの定義 1. ステークホルダの識別ステークホルダーとはシステムに関与する個人グループ組織システムに対する要求の源泉ステークホルダーお客様のお客様お客様ベンダ外部監督者 CIO 情報システム部運用担当者エンドユーザ Center 22

23 ステークホルダの定義 1. ステークホルダの識別ステークホルダの例開発費の出資者開発されたシステムの購入者製品利用者プロジェクト管理者問題領域専門家ビジネス領域専門家開発技術者テスト担当者品質管理者利用性調査専門家開発組織の他の顧客 ( 再利用 ) 営業担当者法律専門家教育担当者標準策定委員会開発対象となる領域の専門団体政府文化慣習慣例競合他社一般大衆環境団体要件プロセス完全修得法スザンヌロバートソンジェームズロバートソンを参考に作成 Center 23

24 オニオンモデル 1. ステークホルダの識別社会環境政府行政顧客地域顧客企業株主 CEO 業務ユーザ CIO IT システムビジネスユーザ EA Rep サプライヤー社員保守者開発者ソフトウェア Functional Model Component Operational Model Model Business Process Model Business Model Economic Model Environmental Model シグネチャートランザクションオペレータユースケースシステム管理者ビジネスイベント取引法律コンプライアンス IT アーキテクトサミット 2009 日本 IBM 榊原彰氏講演資料を参考に作成 Center 24

25 ステークホルダマトリクス 1. ステークホルダの識別高見落としてはならない定期的な参加極めて重要積極的な参加お客様プロジェクトマネージャ重要性最低限の参加でよいユーザ参加がなければリスクが高くなる影響度 : 意志決定に及ぼす相対的力重要度 : 開発が成功するための必要性低 CEO 低影響力高 Center 25

26 ユーザの理解 1. ステークホルダの識別ユーザの深い理解を通して次の目標を達成コンシューマ製品におけるユーザの特定情報システムにおけるユーザビリティの向上ユーザの深い理解とはターゲットユーザ固有の情報システム / 製品に対する嗜好振る舞いユーザが情報システム / 製品を利用するコンテキストの明確化ユーザの情報システム / 製品の利用方法の詳細な理解ユーザ情報の獲得アンケートユーザプロファイリング観察ライブログユーザのモデル化ペルソナ Center 26

27 シナリオ 2. 現状システムの理解定義シナリオは使用に関する具体的なストーリーストーリーは情報システムの使用に限定されない目的を持って一定の規則に従って記述されたストーリーユーザの言葉でユーザの操作を記述目的ユーザのシステムの使用を具体的に理解するシナリオ発見の方法インタビュー観察要求ワークショップ Center 27

28 業務実地調査 / 現場観察 2. 現状システムの理解定義業務を実際に体験したり現場に出向いて調査を実施目的現在の業務のムダを見つける現在の業務フローの問題を見つける既存システムの活用度を見る現在の業務をシステムでサポート出来るかどうかみる業務知識の習得するために行うメリット資料や面接では得られない情報の入手デメリット実地調査の前に業務フローや作業マニュアルなどに目を通しておかないと単なる見学会に終わってしまうことがある Center 28

29 業務実地調査 / 現場観察 2. 現状システムの理解業務実地調査の方法業務フロー追跡型仕事の流れに沿って順を追って観察定点観測型始業時終業時昼食前など作業がピークになるときを観察短期体験型お客様に変わって業務を短期間体験 Center 29

30 インタビュー 4. 課題の抽出と原因分析定義ステークホルダの中からキーパーソンを選び出し現状の問題点や新規システムに対する要望などを聞き出すポイントキーパーソンを選ぶことが重要業務に精通している人問題意識がある人意思決定に関して ( 表の ) 権限がある人裏の権限インタビューの目的を明らかにしてインタビュー相手に伝える IC レコーダを使う場合には予め伝える必要がある予め質問事項の周辺知識を仕入れておくことインタビュー終了時に今後の協力を依頼する Center 30

31 インタビュー 4. 課題の抽出と原因分析メリット直接一次情報を聞くことができるので回答の背景や理由を聴き出せる想定していなかったこと気づいていなかったことも発見できる個人の価値観など抽象的で答えにくいことでも話として聴き出しやすい柔軟性に富み深い情報も入手しやすいデメリット例外事項や問題点などインタビュー対象者の心の中に強く印象づけられている事柄に影響される自分にとって不都合なことなど意識的に説明を省いたり強調したりして事実の判断を誤らせることがある人手がかかる時間と空間の制約をうける Center 31

32 リッチピクチャー 4. 課題の抽出と原因分析漫画と吹き出しを用いてどのような意見があるのかを俯瞰する絵直感的な現状把握を行うことが目的である公式なテクニックや定まった形式はないステークホルダの意見世界観問題意識を把握することに意義がある発言者の位置にも意味があり描き手の意図が反映される近い遠い中央周辺 Center 32

33 Center 33 リッチピクチャーの例 4. 課題の抽出と原因分析中谷多哉子 : 情報処理学会 2008 年度会誌特集 : 要求工学から引用

34 問題連関図 4. 課題の抽出と原因分析システム化テーマ影響問題原因タイムリーで訴求力のある営業活動が行えない新車購入タイミングで他社他店に訪問される顧客が来店した際に商談対応できない場合がある ( カード No.9~11) 別の顧客と商談しているとき突然来店されることがある ( カード No.9,10) 購入見込み顧客と次回のアポイントメントをとっていないことがある ( カード No.10,11) 課題 A: 購入見込み顧客に次回のアポイント獲得の連絡を確実に取る新車購入のタイミングでは目当ての車を急に見に来る傾向がある担当営業員でなければ顧客の商談対応ができない顧客担当制によって担当営業員を固定している課題 B: 担当営業員でなくても商談対応ができるようになる他の営業員が受け持つ顧客との関係が構築されていない他の営業員が担当する顧客の情報や折衝状況が分からない効率的な提案や見積もりが行えない顧客に自社の商品を購入するメリットを訴求できていない ( カード No.12~14) 顧客ニーズを踏まえた自社商品の PR を行えていない ( カード No.13~15) 新車購入に対する顧客のニーズを十分に把握できていない課題 C: 顧客ニーズを踏まえて自社商品の PR を行えるようにする商品の特徴を顧客ニーズに対するメリットとして説明できない ( カード NO.14) 凡例解決すべき問題顧客の要望に合致する商品の提供条件を提示できない顧客の予算に合致する見積もり価格を提示できない ( カード No.16,17) 顧客の希望する車種仕様の納期回答に時間がかかる ( カード No.18,19) 商談のタイミングを踏まえた適正な価格決定が行えない ( カード No.16,17) 本部に在庫のない商品の入庫予定が分からない (1~2 日かかる )( カード No.18) 課題 D: 商談のタイミングを踏まえて適正な価格を提示できるようにする本質的な原因水田哲郎手戻りなしの要件定義実践マニュアルを参考に作成めったに売れない仕様を要求されると納期が分からない ( カード No.19) Center 34

35 ゴール指向 5. 課題解決に向けたゴールの抽出 6. ゴールを達成する手段の抽出ゴール (Goal)[ 目標 (Objective) 目的 (Purpose)] システムのあるべき姿ゴールは状態や振る舞いとして定義するゴールの例 : 常時顧客の欲しい品を提供できる理由 (Why): なぜその要求が必要か? 理由として表現した例 : 常時顧客が欲しいから顧客が欲しい商品をタイムリーに提供したいからゴールの意義課題解決とはゴールの達成である機能 / 非機能要求はゴールの達成手段であるゴールを定義しステークホルダー間で合意することが重要である青山幹雄 : 要求工学知識体系解説セミナー資料を参考に作成 Center 35

36 ゴールモデル 5. 課題解決に向けたゴールの抽出 6. ゴールを達成する手段の抽出ゴール指向分析で得られるゴールモデルは Why What How の関係を可視化するソフトゴール [ 戦略的抽象的 ] 戦略的目標システムが持つべき定性的な特性ハードゴール [ 戦術的具体的 ] システム ( ビジネス ) のもつべき望ましい状態到達可否や達成の定量的評価可能タスクゴールの達成手段青山幹雄 : 要求工学知識体系解説セミナー資料を参考に作成 Center 36

37 ゴールモデルの例 5. 課題解決に向けたゴールの抽出 6. ゴールを達成する手段の抽出常時顧客の欲しい品を提供できる全国規模の店舗網があるリアルタイム商品確保ニーズに即応する仕入れ顧客需要予測サプライチェイン管理店舗のリアルタイム在庫管理ソフトゴールリアルタイム棚卸し店舗毎商品毎顧客行動情報収集ハードゴール入荷商品情報送信顧客のプロファイルと売り上げデータタスク顧客情報達成顧客の性別年齢層の入力 37 POS での商品情報の入力青山幹雄 : 要求工学知識体系解説セミナー資料を参考に作成 Center 37

38 Center 38 REBOK を現場で活かすには

39 REBOK 活用の例要求工学とは何かを知りたい REBOK 要求工学の基礎を読む要求工学の導入を推進したい REBOK で要求工学の全体像を掴む要件定義に必要な役割と行うべきアクティビティを理解する要求工学を活用してより良い要求を獲得したい REBOK の中から必要な技術を選択する全ての技術を適用する必要は無い要求工学を実践できる人材を育成したい REBOK を活用して要求工学の人材育成コースを作成する青山幹雄 : 要求工学知識体系 (REBOK) 顧客要求をシステム開発へ活かす Win-Win Way 資料を参考に作成 Center 39

40 REBOK 活用の例現在実施している要件定義のやり方が適切か知りたい現行の要件定義プロセスと要求工学プロセスを比較しプロセスと成果物を評価する開発規模等を考慮して適切なプロセスと成果物を定義する青山幹雄 : 要求工学知識体系 (REBOK) 顧客要求をシステム開発へ活かす Win-Win Way 資料を参考に作成 Center 40

41 Center 41 まとめ

42 まとめ要件定義がプロジェクト成功の鍵ただし要件定義工程の工数と期間を単純に増やしただけでは望む効果を得られない要求工学の研究が進み現場に活用できる程度まで成熟してきた要求工学要件定義の書籍は国内だけでも 40 冊以上ある要求工学の書籍は大著 (700~800 ページ超 ) のものもある REBOK を活用することで要求工学の成果を享受できる多くの書籍を読む前に要求工学の全体像を把握する Center 42

43 Center 43 以上ですご静聴ありがとうございました

Microsoft PowerPoint - REBOK-ReqSympo Final

Microsoft PowerPoint - REBOK-ReqSympo Final 第 6 回要求シンポジウム要求工学知識体系 (REBOK) 顧客要求をシステム開発へ活かす Win-Win Way 青山幹雄南山大学情報理工学部ソフトウェア工学科 JISA REBOK 企画 WG 座長 [email protected] www.nise.org シナリオ 5. さあ,REBOK で Win-Win Way へ for Success 1. 要求工学が成功の鍵 2. REBOK