すくすくスクラム要求開発入門(公開用).Key

第４２回すくすくスクラム
スクラム実践者のための要求開発⼊入⾨門(公開⽤用)
匠BP 萩本順三
セントラルソフト林林栄⼀一
!
2013/10/31 開催
Copyright(C) 2013 Takumi Business Place Corporation,CENTRALSOFT Co., Ltd.All Rights Reserved.
1

勉強会？
みんなが集う場所　
講師も参加者も平等
気付きを共有
刺激しあう

はじめに
3

スクラム要求開発定例例セミナーのスコープ
4
匠BPとセントラルソフトの共催で有料料の定例例セミナーを開催しています。今回はその
⼀一部をご紹介致します。
このセミナーでは、スクラムのあるべき⽅方向性として新しいやり⽅方を提供しています。
•朝会柔軟体操
•スクラム⼊入⾨門
•要求開発⼊入⾨門
•スクラム要求開発曼荼羅羅で⽰示す８つのポイント
•スクラムの弱点１
•スクラム要求開発２〜～５
•ユーザーストーリーマッピングの改良良６
•プロダクトオーナーシップの４象限７
•企画編：POによる戦略略的バックログの⾒見見える
化と落落とし込み（バックログの匠）８
•開発編：スクラムチームとプロダクトオーナーの
コミュニケーション
!
•演習
•スクラム要求開発実践演習
•1 価値分析モデル
•2 要求分析ツリーの理理解
•3 要求開発版ユーザーストーリーマッピ
ング
•4 プロダクトバックログへの落落とし込み
•プロダクトオーナーシップの４象限演習
今回のすくすくスクラムでは
この範囲を扱います

スクラム要求開発⼊入⾨門
5

戦略略・要求オペレーション
ビジネス
戦略略
ビジネス
オペレーション
What How
表（価値）裏裏（実現）
裏裏（実現）
What
How
What How
!
システム要求
表（価値）
!
システム設計
6
１要求開発４象限
ビ
ジ
ネ
ス
シ
ス
テ
ム

ビジネス
戦略略
ビジネス
What How
裏裏（実現）
What
How
What How
表（価値） !
裏裏（実現）
ユーザーストーリー等
（バックログ項⽬目）
表（価値）
!
タスク
7
１要求開発４象限スクラムとの関係
ビ
ジ
ネ
ス
シ
ス
テ
ム

２コタツモデル
要求は、あるものではなく、開発するものである
業務理理念念を統制し、業務効率率率化を図るための業務と
は○○あるべきだ。
しかし現実は△△だから、それをどう改善できるか
現場と話し合ってみよう。
我々のやり⽅方がベストだと思っていたけ
ど、⾒見見⽅方を変えれば⽋欠点が多いね。
もう少し業務のあるべき姿を考えてみよ
う。
本当に求められている業務の姿を経営
や現場と、きちんと確認しないと、あ
るべき業務やシステムの要求は導き出
せない。問題の視覚化(モデル)と
改善プロセスによる活動
開発された要求
コタツ
モデル
オーナの論論理理
開発担当者の論論理理業務担当者の論論理理
8
〜～要求をコタツで形成〜～

コタツ形成は、チームの役割だけを⽰示すものではない。
参加者全員が３つの視点を持つ事。
戦略的
視点
IT活用の
視点
業務問題
解決の視点
ビジネスにとって価値のある
要求・要件
業務部門に戦略的視野
を身につけさせる。
これによって、要求（戦略略・業務・ＩＴ）を広い視野で考え、取捨選択
するための基礎が形成される。
将来の価値を
取りに⾏行行く傾向
現在の価値を
取りに⾏行行く傾向
戦略部門に現場の問題
課題を理解させる。
9

• ビジネス戦略略と業務を⾒見見える化しながらIT要求を出し、
開発を進めていく⼿手法
• 企画を⾼高速に回す
戦略的視点
IT活用の視点
戦略略・要求オペレーションビジネスシステム
業務問題解決の視点
ビジネスにとって価値のある要求・要件
戦略的視点
業務問題解決の視点
オーナ
IT活用の視点
業務担当
システム担当
10
コタツは、結果イメージの予測を加速

３⾒見見える化：要求の構造的な階層化
要求を上位・中位・下位で関係付けて
⾒見見える化できる枠組みがある。
戦略要求
学⽣生サービス
業務要求IT要求
業務負担の
軽減
標準業務モデル
○○による
業務システム構築
増⼤大することをシステム開発費
利利⽤用代理理店IDが
増⼤大することを利利⽤用代理理店IDが
維持費の削減
○○視点での安⼼心品質の確保
新サービスビジネスモデル
商品管理理の○○を
××に改善する
業務⽀支援
戦略・要求オペレーション
ビジネス
戦略略
ビジネス
ビジネス
表（価値）　裏（実現）
!
What How
What
How
What How
表（価値）裏（実現）
システム要求
システム
表（価値）　
裏（実現）
!
システム設計
要求分析ツリー
要求開発４象限
11

切切れていたものを、繋いで、並⾏行行でスピーディに回す。
ビジネスシステム
ビジネス戦略略企画戦略略／プロモーション
Ｈｏｗの⼿手探り
Ｈｏｗからの突き上げ
Ｈｏｗのチューニング
システム要求システム開発
企画・戦略略部⾨門
オーナ
⼈人と⼈人
業務担当
システム担当
オーナ企業
会社と会社
業務運⽤用⼦子会社
IT⼦子会社
組織と組織
営業部⾨門
開発部⾨門業務部⾨門思考と思考⽬目的
⼿手段⼿手段
戦略略
実現
実現
12
３⾒見見える化：要求開発は切切れていたものを繋げる仕組み

PO(プロダクトオーナーシップ）の４象限
13

POの４象限
Copyright(C) 2013 Takumi Business Place Corporation,CENTRALSOFT Co., Ltd.AAllll RRiigghhttss RReesseerrvveedd..
14

POの４象限
PBL Ready
（プロダクトバックログが準備できた状態）
あり方
責任、立場
時間
技術、知識
15

POの４象限
PBL Ready
あり方
責任、立場
時間
技術、知識
What
How
16

POの４象限
あり方
チームとステークホルダ
に対する立場と責任
PBLメンテナンス
チームへの表現力
技術とのバランス感覚
見通す力
PBL Ready
ステークホルダに対する
立場と責任
ユーザーストーリー
時間
技術、知識
モデリング
コミュニケーション力
17

POの４象限演習
•次からの質問に答えて、各⾃自の弱点を把握してくだ
さい。Yes＝１点（５点満点）
•プロダクトオーナーでない場合はもし⾃自分がプロダ
クトオーナーだったらどうかをみてみてください。
•⾃自分なりの対策や戦略略を考えてみてください。
Copyright(C) 2013 Takumi Business Place Corporation,CENTRALSOFT Co., Ltd.All Rights Reserved. 18

「ステークホルダに対する⽴立立場と責任」についての質問
•ビジネスに重要となるステークホルダを認識識していますか？
•今回の開発についてビジネス戦略略的な説明ができますか？
•業務部⾨門（現場）の本質的な問題、課題を説明できますか？
•プロダクトの成功に情熱をもっていますか？
•プロダクトのビジョンをステークホルダーと共有できていますか？
点

•オーナ部⾨門（企画部⾨門）としっかりとした対話ができていますか？
•業務部⾨門（現場）としっかりとした対話ができていますか？
•こたつの運営ができていますか？
•こたつの中でメンバーに協⼒力力を得て対象業務のあるべき姿を描き⾒見見え
る化することができていますか？
•新しい業務としてのIT活⽤用イメージをストーリーとしてイメージでき
ていますか？
20
モデリング、コミュニケーション⼒力力についての質問
点

•プロダクトビジョンにもとづいてメンバーの意⾒見見を聞いてプロジェ
クトビジョンを描いて共有できていますか。
•プロダクトの成功に向けて、チームを巻き込んでいますか？
•プロダクトのビジョンをチームと共有できていますか？
•プロジェクトメンバーの成⻑⾧長を意識識していますか？
•プロジェクトメンバーの⼼心⾝身の健康を意識識していますか？
21
チームとステークホルダに対する⽴立立場と責任についての質問
点

•責任をもって、PJの進⾏行行状態を確認していますか？
•PBLを開発者に価値を含めて正しく説明できていますか？
•スプリント結果をお客様と共有し戦略略的にPBL優先順位をメンテナ
ンスできていますか？
•優先順位の変更更理理由をお客様と開発メンバーに説明できています
か？
•技術的可能性（How)をメンバーから引き出し、投資対効果（ROI）
を判断しバランスよくメンテできていますか？
22
PBLメンテナンス、チームへの表現⼒力力、技術とのバランス感覚、
⾒見見通す⼒力力についての質問
点

スクラム要求開発プロセス
23

１スクラム要求開発プロセス
1. ステークホルダモデル
2. 価値分析モデル
3. 要求分析ツリーのラフスケッチ
4. ユーザーストーリーマッピング
5. 価値分析・要求分析ツリー洗練化
6. ユーザーストーリーマッピング洗練化
7. 優先順位づけ
8. ⾒見見積もり
9. 開発

ステークホルダモデル価値分析モデル
・ステークホルダ
・価値と⽬目的
・関⼼心事の理理解
要求分析ツリーユーザストーリーマッピング
プロダクトの⽬目的と
ステークホルダの価
値のデザイン
プロダクトの
ステークホルダ
関係と関⼼心事
のモデル
プロダクトの
戦略略、業務、IT
の要求のモデル
プロダクト
ステークホルダの
価値のストーリー
・価値のアイデア
・要求の⽬目的
・ストーリーの
戦略略性
・ストーリーから
⾒見見た戦略略の妥当性
25
２スクラム要求開発モデル・トレーサビリティ（PBL Rady）

ストーリーマッピング
価値
ストーリー項⽬目１
ストーリー項⽬目２
ストーリー項⽬目３
ストーリー項⽬目４
ストーリー項⽬目５
ストーリーに優先順を付けて、その中から今回開発対象
を選び、バックログに⼊入れる
価値
開発関連を抽出
価値
ストーリー項⽬目２
プロダクトバックログバックログ（PBL）に⾮非機能要求等のバックログ項⽬目を含め、スプロントバックログを作る（タスク展開）
バックログ項⽬目２
バックログ項⽬目１
バックログ項⽬目X
タスク１
タスク２
タスク３
タスク４
タスク５
タスク６
バックログ項⽬目X タスク７
要求実現
バックログ項⽬目３
優先１
優先１
優先２
26
３ユーザーストーリーマッピングからプロダクトバックログへ
プロダクトバックログスプリントバックログ

ビジネス企画フェーズ開発フェーズ
１．ステークホルダモデル
２．価値分析モデル
３．要求分析ツリーのラフスケッチ
４．ユーザーストーリーマッピング
５．⽬目的と価値・要求分析ツリー洗練化
６．ユーザーストーリーマッピング洗練化
７．優先順位づけ
８．⾒見見積もり
９．開発
１０．デモ
１１．振り返り
27
４スクラム要求開発プロセス（基本：価値主導）
PBL（プロダクトバックログ） Rady

１．ステークホルダモデル
２．価値分析モデル
３．要求分析ツリーのラフスケッチ
４．ユーザーストーリーマッピング
５．⽬目的と価値・要求分析ツリー洗練化
６．ユーザーストーリーマッピング洗練化
７．ビジネスコア項⽬目の実現優先開発
８．リリース計画
開発フェーズ
１１．開発
ビジネス企画フェーズ開発企画フェーズ
１０．プラン
９．全体⾒見見積もり把握
１２．デモ
１３．振り返り
28
５スクラム要求開発プロセス（契約主導型）
PBL（プロダクトバックログ） Rady

ToBeデスカッション
29

ToBeデスカッション
•ビジネス現場に近い所でスクラムを回すというポリシーを持つスクラム要
求開発。この考え⽅方を取り⼊入れるためには？
•どのようなメリットがあるのか？
•どのような課題があるのか？
•どのように意識識を変えた⽅方が良良いのか？
講師と参加者全員でデスカッションを⾏行行います。

匠BP, セントラルソフト定例例コース
お申込み・詳細：
31
セミナー概要⽇日程主催
スクラム要求開発
スクラム開発に要求開発の考
え⽅方を適⽤用することで、ビジ
ネス価値を⾼高める開発を促進
するための教育コースです。
12⽉月13⽇日(⾦金金)
9:00 〜～17:00
匠BP
セントラルソフト
次世代ITリーダ研修次世代ITリーダの意識識改⾰革と
基礎知識識を学ぶコースです。2014年年1⽉月匠BP
匠Think⼊入⾨門
リスクマネジメントの考え⽅方
とイノベーションの考え⽅方を
学び、要求開発の本質を理理解
することで⾏行行動への意識識付け
につなげていきます。
2014年年2⽉月匠BP
http://www.takumi-businessplace.co.jp/service/content-02.html

ありがとうございました。
32

すくすくスクラム要求開発入門(公開用).Key

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (19)

Andere mochten auch

Andere mochten auch (15)

Ähnlich wie すくすくスクラム要求開発入門(公開用).Key

Ähnlich wie すくすくスクラム要求開発入門(公開用).Key (20)

Mehr von Eiichi Hayashi

Mehr von Eiichi Hayashi (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (8)

すくすくスクラム要求開発入門(公開用).Key