『「babok」に学ぶ要求アナリシス』第17回 postudy...

「BABOK」に学ぶ要求アナリシス

2012年09月28日（金）第17回 POStudy

@fullvirtue

1 Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved.

POStudyのご紹介（1/5）

POStudy（プロダクトオーナーシップ勉強会）とは（1/1）

日本のITサービス業界において「プロダクトマネジメント」という分野が欠落していると言われています。そんな中で、いかに「プロダクトオーナーシップ」を発揮していくかについて、普段の生活や仕事を通して自己成長を重ねていく為のヒントを提供していきます。

– 【オフライン】

» 東京・沖縄を中心にワークショップ形式の勉強会を通じて「参加者同士で議論」を行い「情報交換」をすることで互いに有益な場を作っていきます。

– 【オンライン】

» ワークショップを中心とした動画・静止画コンテンツを配信していきます。



POStudyの情報を得るには（1/1）


Question Answer / URL

イベント情報のメール通知を受け取りたいときは？

POStudy用のDoorKeeperへメンバー登録してください！次回以降の告知やお知らせがメールで届きます。 http://postudy.doorkeeper.jp/

過去の資料を閲覧したり、参加レポートを参照したいときは？

以下のPOStudy公式サイトにて過去の資料や今後の予定等を公開しています。 https://sites.google.com/site/spostudy/

ツイートする時のハッシュタグは？

以下のハッシュタグをお使いください！ #postudy

POStudyの最新情報が欲しい、or 参加者と議論をしたいときは？

POStudyのFacebookグループへご参加ください！ https://www.facebook.com/groups/postudy/

Twitterによるお知らせを購読したいときは？

POStudyのTwitterアカウントをフォローしてください！ https://twitter.com/POStudySmile/

http://postudy.doorkeeper.jp/

http://postudy.doorkeeper.jp/

https://sites.google.com/site/spostudy/

https://twitter.com/POStudySmile/

https://twitter.com/POStudySmile/


過去に実施してきたテーマ（1/2）


実施日テーマ参加者

第1回 2011/09/16（金）アジャイルとスクラム 9名

第2回 2011/09/30（金）ユーザーストーリーマッピング ~前編~ 18名

第3回 2011/10/14（金）ユーザーストーリーマッピング ~後編~ 19名

第4回 2011/10/28（金）ユーザーストーリーマッピング ~再演~ 31名

第5回 2011/11/11（金）プラグマティック・ペルソナ 26名

第6回 2011/11/25（金）プラグマティック・ペルソナ ~再演~ 22名

第7回 2012/01/27（金）ストーリーテリング ~概要~ 16名

第8回 2012/02/10（金）体験！The Specification Exerciseで仕様伝達 18名

特別回 2012/02/13（月）体験！マシュマロ・チャレンジでチームビルディング 17名

第9回 2012/02/24（金）ストーリーテリング ~ストーリーを生み出す~ 9名

第10回 2012/03/09（金）ストーリーテリング ~ストーリーを共有する~ 11名

第11回 2012/03/23（金）ストーリーテリング ~ストーリーを作る~ 10名

第12回 2012/04/27（金）ストーリーテリング ~よい聞き手になるための学習~ 12名


過去に実施してきたテーマ（2/2）


実施日テーマ参加者

第13回 2012/05/18（金）体験！Fearless Journeyでパターンによる改善 20名

第14回 2012/07/06（金） Business Model Canvas 24名

第15回 2012/08/03（金） Business Model Canvas ~再演~ 17名

第16回 2012/09/07（金）「Moving Motivators」に学ぶモチベーション 24名

第17回 2012/09/28（金）「BABOK」に学ぶ要求アナリシス -

第18回 2012/10/25（木）「RUNNING LEAN」に学ぶLean Canvas -


IT勉強会スタンプラリーのご紹介（1/1）

6

・IT勉強会に参加してスタンプを集める

参加無料のイベントです

・詳しくは http://it-stamp.jp/

© 2012 IT勉強会スタンプラリー運営委員会ロゴ・イラストについて: この作品はピアプロ・キャラクター・ライセンスに基づいてクリプトン・フューチャー・メディア株式会社のキャラクター「初音ミク」を描いたものです。 (イラスト: @Ixy) IT勉強会スタンプラリーのスポンサー各社のロゴの所有権・著作権は、スポンサー各社に帰属します。

Copyright © POStudy (プロダクトオーナーシップ勉強会). All rights reserved.

http://it-stamp.jp/

http://it-stamp.jp/

http://it-stamp.jp/

http://it-stamp.jp/

http://it-stamp.jp/


今日のアジェンダ（1/1）

第16回の復習

第16回各チーム振り返り結果ご紹介

BABOKとアジャイル

ワークショップ #1



BABOKに学ぶ要求アナリシス



振り返り＆ディスカッション

まとめ 7

おことわり（1/2）

今回の資料について（1/2）

今回の資料は、以下の資料を参考にしています。私自身のオリジナルはほとんどありませんので、ご了承ください。

– Business Analysis教科書 BABOK CCBA

» http://www.amazon.co.jp/dp/4798124826/

– 「BABOK（R）」の近況～BABOK（R）のアジャイル拡張版とビジネスアナリシス（BA）の認定資格の状況～

» http://www.ogis-ri.co.jp/rad/webmaga/rwm20120204.html

8

http://www.amazon.co.jp/dp/4798124826/



http://www.ogis-ri.co.jp/rad/webmaga/rwm20120204.html



おことわり（2/2）

今回の資料について（2/2）

– アジャイルにおけるビジネスアナリスト像

» http://www.infoq.com/jp/articles/BABOK_20110818

– IIBAがBABOKのアジャイル拡張を発表

» http://www.infoq.com/jp/news/2010/09/agile-babok-announce

– BABOK入門セミナー by @darupants

» http://d.hatena.ne.jp/darupants/20091222

– 要求アナリシスとはどんなものか

» http://www.atmarkit.co.jp/im/carc/serial/babok/02/02.html

– 解決策を見つけるためにきちんと分析しよう

» http://www.atmarkit.co.jp/im/carc/serial/babok/02/02.html

9















http://www.atmarkit.co.jp/im/carc/serial/babok/02/02.html


第16回の復習

いきなり本題に入る前に、前回の復習をしましょう

10

第16回の復習（1/4）


資料公開先 https://sites.google.com/site/spostudy/list/No16_20120907

11

各テーブルごとにモチベーションの

定義を考えてもらいました。

その後、Moving Motivatorという

ワークショップを実施し、

再度モチベーションについて

考えて頂きました。

https://sites.google.com/site/spostudy/list/No16_20120907

https://sites.google.com/site/spostudy/list/No16_20120907


10個の本質的な欲求（1/1）

12

影響力熟練度周囲から受け入れられる

名誉好奇心を満たす

地位成し遂げること秩序人とのつながり自由

私には調査したいことや考えたいことがたくさんある。

私はグループに個人的な価値観を反映しつつ、私自身がグループにより

忠実になる。

私の周りにいる人たちは私のことや、私がしたいと思っていることに同意してくれる。

私の仕事は私の可能性に賭けるが、私ができる範囲内の仕事にすぎない。

私が周囲に影響を与えるには十分な部屋の

大きさである。

仕事や責任から独立している。

業務関係や業務外でもいろんな方たちと

いい繋がりを持っている。

安定した環境を維持するために必要なルールやポリシーが存在する。

私の人生の目的は、私の仕事にも

反映されている。

一緒に働いている同僚が私を評価してくれるため、私は良いポジションに

就いている。


手元のカードを並び替えてください（1/2）

13

自分にとって重要なもの

自分にとって重要ではないもの

１０９８７６５４３２１


手元のカードを並び替えてください（2/2）

14

悪い変化を与えるもの

良い変化を与えるもの


前回の振り返り結果をご紹介します

15

第16回各チーム振り返り結果ご紹介（1/7）

Aチーム（1/1） Keep

– ワークショップをやっているうちに、意味（意義）がわかってきた

– チームで話し合って結論を出す（出せてないけど）

– モチベーションに関していろいろ気づきが得られた

– モチベーションって言葉を使っているけど、人それぞれとらえ方が違う

Problem

– カードのタイトルと説明の一致感が少ない関係がはっきりしないものがあった

– 次のアクションがぼんやり

– チームで議論して相手のモチベーション理解を深めていくポイントがありそうだけど、よくわかっていない

– 忘れ物をした

Try

– 会社に持ち帰ってやってみる

– 優先度付けの方法を考えたい

– チームビルディングに使ってみる

– 自分の頭にあるものを説明する練習をする

– 自分のモチベーションについてよく考える

– モチベーションが落ちている時期にやってみる ⇒復活するかも

– Moving Motivatorについて調べる

16


Bチーム（1/2） Keep

– 早く来て手伝う

– ワークショップがよい

– 新しい方法を手に入れた

– 笑いの多いワークショップだった

– 公式サイト参考になった新しく来る人にもわかりやすい

– 復習いい！

– Business Model Canvasの話も聞けて、2度美味しい

– タイマー

– 自主的なタイムキーパーがいた

– 普段なにげなく使っている言葉がテーマになった。その結果、ちゃんと考えたため、考え方が深くなった

– 途中の休憩

– Business Model Canvasのとらえ方がおもしろかった

– オフィスが快適

– グラフィカルな小道具だった。その結果、チームがわきあいあいとワークショップを楽しむのに一役買った

– 毎回の初めての人向けの説明

– お菓子

– 時間表示が良い

– プランニングポーカーの使い方がかっこいい

– 付箋を多様

– いろいろな話が聞けた

17


Bチーム（2/2） Problem

– 先の展開が読めてなかったので、ロールプレイしにくい会社を作ってしまった

– つい話してしまって、他の方の話を聞き損なう

– 発表まとまらなかった

– 様々な方向に拡散したが、まとめるプロセスがなかった。その結果、もやもやした

– 職場から遠い

– ワークショップのやることの理解が追いつかなかった

– 前回の復習は長かった。とても興味深かったのは、すごく良かったけど

– 勉強会前にお手伝いできることがあれば事前に共有して欲しい（早く来た人が手持ちぶさたになっちゃう）

Try

– 人事考課の考課側なので、メンバーにやってもらう

– ワークショップのやり方を具体的に実演して欲しかった

– 渋谷あたりでやって欲しい（自己中）

– 秋葉原あたりでやって欲しい

– また来る

– 最初の「モチベーションとは」の前に、自己紹介があった方がいいかも

– スクラムとの繋がりを持って話して欲しい

18


Cチーム（1/1） Keep

– 自分の内面が見える化された

– 1チーム4～5人、全体で20名ぐらいの人数が適切

– モチベーションの上下が見える（自分もチームも）ホットな話題をタイムリーに取り上げること

– 今、自分の抱えている問題が見えた

Problem

– カード内のタイトルと説明文の違和感があった

– よくわからなかった

– 少し講義の比率が高かったかもしれない

– モチベーションは公開するものかしないものか分からなかった

– モチベーションの多様性って何？

– どうすれば自分から変えられるのだろう

– このWSの本当のゴールまで達しなかった

– （メンバーとの対話のきっかけをつかむ）

Try

– 予習する

– たまに一列に並べてみたい

– 定期的にやってみたい

– Moving Motivatorの模範事例がある方がわかりやすかったかも

– 同じ課題を抱えた人同士でチームを組んでみるといいかもしれない

– マネージャーがメンバーと対話する段階までシミュレーションできると、実用的かもしれない

– チームのモチベーションを維持したい

19


Dチーム（1/2） Keep

– 幅のある課題だったので、より深く考えさせられました。Good！

– 挑戦的な試みが良かった（他ではなかなか体験できない）

– ワークショップなので、自分1人では想像できないような気づきが得られた

– チームが良かったいろんなパターンの考えが聞けたので、まとめがいがあった。

– 主催者すごい！準備がすごい！毎回これをやっていることがステキ

– テーブルで自己紹介したので、その後進めやすかった

– お菓子の差し入れお菓子Thanks！

– みんな前向きでやりやすかった！

– 思ったことをそのまま伝える

Problem

– 前提条件が不一致のままスタート

– チームの状況は始めから用意してあってもよかった（自由に考えるのではなく）

– 変化の前後で条件が共有できておらずキャッチアップが難しかった

– リアルな状況をどこまで思いつけるかが大事そこにもっと時間を当てるべき

– 5人分を1つにまとめるのに時間がかかる話をまとめられない

– 誰かのモチベーションの変化を見分けられるか

– 遅刻した

– 話にあまりついていけなかった

– 時間がない（頭が追いついてないだけ？）

– 発表をノリでやってしまった

20


Dチーム（2/2） Try

– 一番理解している人が発表者と詰める

– 時間通りに来る

– 自分のモチベーションを意識するそして、意識しなくなる

– 準備に時間がかかることを見越す

– もっと早く来てみんなで準備する！

– チームの各々のモチベーションを把握できるようにする！

– ワークをうまくいかせるために、想像の話はトコトン詰める

– 今回発表しなかったので、発表する

– 今回のワークショップを、どう仕事に活かすか考える

– モチベーションの上がる要素を探す

21


Eチーム（1/1） Keep

– 仮定の話が発展した

– お題良かった

– 個々の結果がまちまちでも理解しあえた

– ペルソナ書いて良かったイメージしやすい

– みんなでやるのが良い

– 発表者への拍手

Problem

– 文章化が難しい

– 男だらけ

– 要求の絵をもっと直感的なものにしようよ Appeloさん

– 1つ1つの要求が具体的に何か結びつけられなかった

Try

– 図で表現してみたい

– 自分の現状でやってみる（変化は何だ？）

– もう少し深く掘り下げたい

22


まず最初に、BABOKの用語の確認と

BABOKとアジャイルの関係を整理していきましょう

【参考】ビジネスアナリシスの役割は、プロジェクトマネージャーの仕事の前工程と考えると理解しやすいと思います

23

BABOKとアジャイル（1/9）

予備知識（1/5）

BABOKとは（Business Analysis Body of Knowledge）

– ビジネスアナリシスとして実施すべきことを体系的にまとめたもの

» 正式な読み方は「びーえーぼっく」

» 「ばぼっく」と読むのは間違い

– 現在Version2.0が公開されている

– 2012年にはVersion3.0がリリース予定

ビジネスアナリシスとは（Business Analysis）

– 顧客のビジネスニーズを満たす情報システムの構築を実現するために、業務分析や要求分析を行う専門家

24

BABOK入門セミナー by @darupants - http://d.hatena.ne.jp/darupants/20091222

Business Analysis教科書 BABOK CCBA - http://www.amazon.co.jp/dp/4798124826/

http://d.hatena.ne.jp/darupants/20091222






CCBAとは（Certification of Competency in Business Analysis）

– ビジネスアナリシスの専門知識とスキルレベルを認定する資格試験

– 国際的非営利団体IIBAが「IIBA認定」として主催（International Institute of Business Analysis）

– 2011年秋から日本語版が開始

– 2012年にCBT試験（コンピュータ試験）へ移行

CBAPとは（Certification Business Analysis Professional）

– CCBAの上位資格

25 Business Analysis教科書 BABOK CCBA - http://www.amazon.co.jp/dp/4798124826/





ESDVとは

– Elicitation (要求を)引き出して

– Structure 構造化して

– Documentation 文書化して

– Validation 検証する

[おまけ] SMARTとは

– Specific テーマは具体的か？

– Measurable 定量的に測定可能か？

– Attainable 達成可能か？

– Result-based 成果に基づいているか？

– Time-oriented いつまでにが明確か？

26

BABOK入門セミナー by @darupants - http://d.hatena.ne.jp/darupants/20091222





BABOKのアジャイル拡張レビュー用ドラフトを発表

– 2010/08/10 Agile Conference 2010 にて Kevin Brennan氏（IIBA専門性教育部門バイスプレジデント）が発表

– 発表の目的は以下の通り

» ビジネスアナリスト向けにアジャイルプラクティスを紹介すること

» アジャイルの実践者向けにビジネスアナリシスの概要を示すこと

» アジャイルプロジェクトに従事するビジネスアナリストが従うべき典型的なプラクティスを定義すること

» ビジネスアナリストの新しい変更された役割、技能、コンピテンシの概要を示すこと

27 アジャイルにおけるビジネスアナリスト像 - http://www.infoq.com/jp/articles/BABOK_20110818

IIBAがBABOKのアジャイル拡張を発表 - http://www.infoq.com/jp/news/2010/09/agile-babok-announce

http://www.infoq.com/jp/articles/BABOK_20110818

http://www.infoq.com/jp/articles/BABOK_20110818

http://www.infoq.com/jp/news/2010/09/agile-babok-announce








BABOKのアジャイル拡張版(The Agile Extension to the BABOK(R)

Guide(November 2011 Draft for Public Review))を発表

– 2011/11 パブリックレビュー用ドラフト版

– アジャイルライフサイクルにおけるビジネスアナリシスと題して、以下の内容に言及

【第2章】

» Scrum, XP, Kanbanにおけるビジネスアナリシス

【第3章】

» アジャイルにおけるビジネスアナリシステクニックについて、BABOK(R)の知識エリアのタスクにマッピング

【第4章】

» アジャイルビジネスアナリシスの７つの原則とテクニックのマッピング、そして各テクニックを説明

28 「BABOK（R）」の近況 - http://www.ogis-ri.co.jp/rad/webmaga/rwm20120204.html






Scrumにおけるビジネスアナリシス（1/1）

使用するテクニック

– Backlog Management、Retrospectives

ビジネスアナリシスが関与する工程

– プロダクト・バックログの作成および保守「Enterprise Analysis」と「Solution Assessment and Validation」

– プロダクト・バックログへのフィードバック「Solution Assessment and Validation」

– 各スプリントの内でのバックログ項目の要求定義「Requirement Analysis」(just-in-time requirement gathering)

– スプリント・バックログの保守「Solution Assessment and Validation」

29

「BABOK（R）」の近況 - http://www.ogis-ri.co.jp/rad/webmaga/rwm20120204.html






XPにおけるビジネスアナリシス（1/1）


– UserStories、StoryMapping、StoryDecomposition、StoryElaboration

ビジネスアナリシスとして期待する役割

– 顧客がフィーチャーの価値について明確なビジョンを描けていない時、ステークフォルダーが最大価値の共通認識を持つようにファシリテート

– 潜在的な問題の明確化

– ステークフォルダーとの合意形成

– 最大の価値を生み出すために本来的な価値に欠けるストーリーをブロック/フィルター







Kanbanにおけるビジネスアナリシス（1/1）


– 要求の引き出し、スコープ決め、要求の管理、優先順位づけ

ビジネスアナリシスの振る舞い

– 他のアクティビティと同様にライフサイクルを通じて継続的に実施

– キューにある仕事の優先順位づけおよびその保守などにビジネスアナリシスのテクニックを活用







アジャイルビジネスアナリシスの７つの原則（1/1）

32

分類原則使用するテクニック

Discover プロダクトの what&why

See The Whole Business Capability Analysis, Personas, Value Stream Mapping

Think as a Customer Story Decomposition, Story Elaboration, Story Mapping, User Story, Storyboarding

Analyze to Determine What is Valuable

Backlog Management, Business Value Definition, Kano Analysis, MoSCoW Prioritization, Purpose Alignment Model

Delivery プロダクトのhow&when

Get Real Using Examples Behaviour Driven Development

Understand What is Doable Estimation, Planning Workshop, Real Options

Stimulate Collaboration & Continuous Improvement

Collaborative Games, Retrospectives

Avoid Waste Light Weight Documentation 「BABOK（R）」の近況 - http://www.ogis-ri.co.jp/rad/webmaga/rwm20120204.html






アジャイルビジネスアナリシスの７つの原則（1/1）

33

分類原則使用するテクニック

Discover プロダクトの what&why

See The Whole Business Capability Analysis, Personas, Value Stream Mapping

Think as a Customer Story Decomposition, Story Elaboration, Story Mapping, User Story, Storyboarding

Analyze to Determine What is Valuable

Backlog Management, Business Value Definition, Kano Analysis, MoSCoW Prioritization, Purpose Alignment Model

Delivery プロダクトのhow&when

Get Real Using Examples Behaviour Driven Development

Understand What is Doable Estimation, Planning Workshop, Real Options

Stimulate Collaboration & Continuous Improvement

Collaborative Games, Retrospectives

Avoid Waste Light Weight Documentation

今日の範囲

「BABOK（R）」の近況 - http://www.ogis-ri.co.jp/rad/webmaga/rwm20120204.html





ワークショップ#1

各テーブルごとに、自己紹介を行ってください

（チームワークショップ）

34


テーブル内で

「自分の興味のある/やりたいビジネス・事業・サービス・企画」

を、1人1分でピッチ（発表）してください

全員がピッチを行ってください


35


テーブル内全員のピッチの中から、人気投票で1位を決めてください

1位になった方はこの後のワークショップでは「ステークホルダー」役になってください

残りの方は「プロダクトオーナー」役とします


36


BABOKの良さは「ビジネスニーズに紐付いたソリューション」を提供することです

そこで、ビジネスニーズに基づいた要求の優先順位付けや要求の体系化などについて、

BABOKの要求アナリシスから学んでいきましょう

37

BABOKに学ぶ要求アナリシス（1/10）

要求アナリシスとは（1/1）

要求アナリシスとは

– ステークホルダーの要求を分析/整理/可視化し、優先順位をつけて要求を実現する解決策をまとめる

» ソリューションが何をするべきか(WHATに相当)を明確化

– 具体的には、以下の6つのタスクを実行

1. 要求に優先順位をつける

2. 要求を体系化する

3. 要求の仕様化とモデリングを行う

4. 前提条件と制約条件を定義する

5. 要求を検証する

6. 要求を妥当性確認する




39

解決策を見つけるためにきちんと分析しよう – http://www.atmarkit.co.jp/im/carc/serial/babok/02/02.html





1.要求に優先順位を付ける（1/2）

優先順位付けの判定基準 1. 各要求について費用対効果を分析し、

もたらされる価値が最も高い要求を優先

2. 実装後に進捗や成功が早く確認できる要求を優先

3. 各要求を実現するプロジェクトについて、失敗するリスクが高いものを優先

4. 最も簡単に実装できそうな要求を優先

5. 法規制やポリシーを遵守する必要があるものについて、それに関する要求を優先

6. 他の要求との関係上、分析や実装が急がれる要求を優先

7. ステークホルダーの合意がとれた要求から順に分析、実装

8. 緊急性の高い要求を優先





1.要求に優先順位を付ける（2/2）

優先順位付けにおいて注意すべきこと 1. 交渉の余地のない要望に対して、優先順を高く

つけてしまいがち

2. ステークホルダーが、難しい選択を嫌がったり代替案を検討する必要性を認めない場合、また、要求すべてに高い優先順位をつけるよう強いてきた場合、ステークホルダーの意見に従わざるを得なくなることがある

3. 非現実的な代替案が出された場合、選択の余地がなく優先順位の付けようがなくなる

4. ソリューション開発チームが、ある要求に対して実装の難易度や複雑さを過大評価してしまう

41





2.要求を体系化する（1/2）

状況や内容に適したモデルを選択

– どのモデルを使うか

– どのように相互依存関係を表すか

– 要求と要求の相互関係や依存関係を明確化

要求を体系化する際に考慮する要素

1. 抽象化レベル

» 「何をすべきか(What)」と「どうやって実施するか(How)」を区別

» 抽象度を下げていく

2. モデルの選択

» 状況や内容に適したモデルを決める

» ある要求を分析して文書化するために複数のモデルを作成





2.要求を体系化する（2/2）

モデリングの考え方と5種類の視点

43

5種類の視点モデルの説明

ユーザークラス / プロファイル / ロール

このモデルは、ソリューションと直接に相互作用する人を分類して表現。ロールとは、類似したニーズと期待と目標を持つ人々をグループ化したもの。それぞれのロールはステークホルダーに対応すると考えられ、要求の発生源として調査が必要

コンセプトと関連

一般にコンセプトとは、場所、人、物、組織といった、現実世界にあるモノに対応。これらがビジネスドメインに関連するオブジェクトやエンティティ、あるいは事実を定義し、さらに他のコンセプトとどんな関連があるかも定義。

イベントイベントとは、ビジネスシステムや組織に何かをするように求めるもの。組織はイベントに応答しなければならない。多くの場合、イベントがビジネスプロセスを起動するか、または影響を及ぼす。イベントは、ビジネス領域の外から来ることも、中から起こることもあり、さらに、予定した時間に発生することもある。

プロセスプロセスとは、組織内で実行される一連の反復可能なアクティビティ。プロセスは、イベントに完全に対応するために、誰または何が参加しなければならないか、あるいは、目的を達成するために企業の人々がどうやって協力して働くかを記述。

ルールルールとは、企業がその目的を周知徹底し、意志決定の指針とするために仕様。エンティティと関連する情報がいつ変更されるのか、どんな価値を持つ情報が有効なのか、プロセスの中でいかに決定が下されるのか、そして組織がどんな優先順を持つかは、ルールによって決められる。





3.要求の仕様化とモデリングを行う（1/1）

要求の仕様化とモデリングを行う際に考慮する要素

1. 文章（テキスト）

» 要求は、次の3つの形式で文章表現する

2. マトリクス表現

» 状況や内容に適したモデルを決める

» ある要求を分析して文書化するために複数のモデルを作成

3. モデル

» 文章モデルや図形モデルを使って状況やフローを記述

4. 要求の属性の捕捉

» 参照番号、情報源、ステータス、複雑性、緊急性、安定性

5. 改善の機会

» 現行の業務運用の改善点を識別可能にする





4.前提条件と制約条件を定義（1/1）

前提条件と制約条件を定義する際に考慮する要素

1. 前提条件

» プロジェクトの潜在的なリスク発生源として常に認識

» 先例や単なる思い込みによって定義されていることも

2. ビジネス上の制約条件

» 予算、時間、リソース、スキル、組織上の制約

3. 技術上の制約条件

» 開発言語、仕様が義務づけられているアプリケーション、リソースの稼働率、メッセージの長さやタイミング、ファイルの最大数とサイズなど





5.要求を検証する（1/2）

要求を検証する際に考慮する要素（1/2）

1. 要求品質の特性

1. 凝縮性が高い

2. 完全である

3. 一貫性がある

4. 正確である

5. 実現可能である

6. 修正が容易である

7. 曖昧さがない

2. 検証アクティビティ

（次ページ）





5.要求を検証する（2/2）

要求を検証する際に考慮する要素（2/2）

1. 要求品質の特性

（前ページ）

2. 検証アクティビティ

1. モデルの表記ミスがない

2. 表記の一貫性

3. 要素の網羅性

4. 要素間の因果関係

5. 表現や用語のわかりやすさと一貫性

6. 例を示す





6.要求を妥当性確認する（1/1）

要求を妥当性する際に考慮する要素

1. 前提条件の識別

» リスクを適切に管理、妥当性を確認

2. 測定可能な評価基準の定義

» 成功の度合いを評価するための評価基準の妥当性を確認

3. ビジネスバリューの決定

» ステークホルダーに価値を提供する要求が定義

4. 便益を実現する依存関係の決定

» 要求間の依存関係や関連が適切に記述されているか確認

5. ビジネスケースと機会費用の整合性の評価

» 最終的にビジネスケースの目標まで遡ることが可能か確認





「プロダクトオーナー」役の方は、「ステークホルダー」役の方に

実現したい機能をヒアリングしてください

ヒアリングをした内容はポストイットに機能単位で書き出してください


49


ワークショップ#4で出てきた要求に対して、

優先順位を付けてください

優先順位が高いものには赤いペンで丸をつけてください


50


今日気づいたことをテーブルごとに共有してください

各チームでの振り返り結果を、配布したA3用紙に記載してください

次回、全チームの振り返り結果をまとめたものをご連絡します

51

まとめ今日お話したことを振り返ってみましょう

52


今日お話したこと（1/1）

第16回の復習










まとめ 53

お知らせ皆様にお知らせがあります

54

『「babok」に学ぶ要求アナリシス』第17回 postudy...

Technology