スクラム開発におけるプロダクトオーナーの役割第 1.1 版 2018 年 02 月 14 日この作品はクリエイティブコモンズ表示 - 継承 4.0 国際ライセンスの下に提供されていますプロダクトオーナーの役割 2018 TIS INC. クリエイティブコモンズライセンス ( 表示 - 継

Size: px

Start display at page:

Download "スクラム開発におけるプロダクトオーナーの役割第 1.1 版 2018 年 02 月 14 日この作品はクリエイティブコモンズ表示 - 継承 4.0 国際ライセンスの下に提供されていますプロダクトオーナーの役割 2018 TIS INC. クリエイティブコモンズライセンス ( 表示 - 継"

まれあいんそん
4 years ago
Views:

1 スクラム開発におけるプロダクトオーナーの役割第 1.1 版 2018 年 02 月 14 日この作品はクリエイティブコモンズ表示 - 継承 4.0 国際ライセンスの下に提供されていますプロダクトオーナーの役割 2018 TIS INC. クリエイティブコモンズライセンス ( 表示 - 継承 4.0 国際 )

2 目次 1. プロダクトオーナーとは 2. プロジェクトマネージャーとの違い 3. プロダクトオーナーの役割 4. 各セレモニーでの関わりについて 2

3 前提スクラムの基本的な概念セレモニーの内容を理解している認識で話を進めますスクラムガイドに記載されている内容本資料は以下の資料を基に作成しているため記載資料を読むことで理解が深まりますエッセンシャルスクラム ( 翔泳社発行 ) PMBOK ガイド ( 第 6 版 ) スクラムガイド 3

4 クレジット本資料ではスクラムガイドを引用して説明していますスクラムガイド 2017 Ken Schwaber and Jeff Sutherland. Offered for license under the Attribution Share- Alike license of Creative Commons 資料中で利用しているアイコンは Freepik( によって作成されにて公開されています 4

5 プロダクトオーナーとは 5

6 プロダクトオーナーとはスクラムチームを構成する役割の一つスクラムチームやステークホルダースクラムチーム以外のプロダクト関係者の総称との協力潜在マーケットの開拓等を通してプロダクトの価値(投資利益率=ROI)向上に責任を持つ潜在的なマーケット潜在顧客/市場スクラムチームステークホルダープロダクトオーナースクラムマスター上司/営業etc 顧客/ユーザー開発チーム 6

7 プロジェクトマネージャーとの違い 7

8 プロダクトマネージャーについてそもそもプロジェクトとは独自のプロダクトサービス所産を創造するために実施する有期性のある業務 (PMBOK 第 6 版より ) 有期性 : 始まりと終わりが存在することそのためプロジェクトマネージャーは以下を意識する必要があるプロジェクトで注視すべきは終わらせること ( 定められた条件内で ) であり最も見るべきものはスケジュールになる 8

9 プロダクトオーナーについて一方プロダクトとはマーケットのニーズを満たすことで収益を上げられるそのためプロダクトオーナーは以下を意識する必要があるプロダクト開発で注視すべきはマーケットのニーズを満たすことであり最も見るべきものはマーケットになる 9

10 マーケットの対象一般的な領域商品やサービスを購買しているあるいは購買する見込みのあるすべての個人および組織体コトバンクより顧客/ユーザープロダクトオーナー 10

11 マーケットの対象 ( プロダクトオーナーからの視点 ) プロダクトオーナー以外の全て ( 購買の有無に関わらず ) 外向き ( 社外 ) のマーケット顕在顧客エンドユーザー内向き ( 社内 ) のマーケット開発チームマネジャー営業法務時には自らリサーチを行いまだ認識していない顧客や市場といった新たなマーケットの開拓が求められる認識していない顧客 / 意思決定者潜在マーケットプロダクトオーナー 11

12 マーケットの対象注意すべき点内向き ( 社内 ) のマーケットにも目を向けること収益をあげるには外向きのマーケットのニーズを満たす必要があるがそのためのプロダクトを作成するためには内向きのマーケットのニーズも満たさないといけない例えばプロダクトの方向性や必要性を知りたいという開発者のニーズを満たせなければ何を開発すればいいか判断できなくなるマーケットのニーズは顕在化しているとは限らない外内問わずマーケットの課題は顕在化しているものとしていないもの ( 前者は顕在ニーズ後者は潜在ニーズと呼ばれる ) が存在するプロダクトオーナーは顕在ニーズばかりを追うのではなく潜在ニーズの存在にも気を使い必要ならば自ら潜在ニーズを見つけにいく姿勢が求められる 12

13 プロダクトオーナーの役割 13

14 プロダクトオーナーの役割プロダクトオーナーはマーケットのニーズに注視しプロダクトの価値の向上に責任を持つプロダクトの価値向上プロダクトバックログの管理経済性の管理スクラムチームとの協力ステークホルダーとの協力 14

15 プロダクトバックログの管理プロダクトバックログとはプロダクトに必要だと把握しているものをすべて順番に並べた一覧である ( スクラムガイドより ) プロダクトバックログ A B C プロダクトバックログを見ることでスクラムチームステーホルダーはプロダクトの現況を把握できる整理されたプロダクトバックログは開発者ステークホルダーをつなぐ共通言語になる ( つまり異なる立場の人たちがバックログを元に議論ができるということ ) 15

16 プロダクトバックログの管理プロダクトバックログの管理ができないと開発チーム側では自分たちが何を作ればいいのかわからなくなりステークホルダー側ではプロダクトの状況が分からなくなる総じてプロダクトバックログが整理されていなければプロダクトの方向性が見えなくなってしまうどんなプロダクトを作りたいのかが見えてこない開発チームステークホルダー 16

17 プロダクトバックログの管理プロダクトオーナーの責任 1プロダクトバックログアイテムの内容を明確に表現する 2プロダクトバックログアイテムの優先順位を決める 3 受け入れ条件を明確に表現する 4プロダクトバックログアイテムに関する質問に答えるプロダクトバックログ A B C 優先順位は時期需要開発期間などの要素を考慮し最も ROI( 投資収益率 ) が高まるように順位付けするスプリント開始時にすべてのアイテムの詳細化をする必要はない ( 最初のリリースに必要な機能の詳細化が完了していれば開発は可能 ) 17

18 プロダクトバックログの管理注意すべき点必ずしもプロダクトオーナーがプロダクトバックログを作成する必要はないスクラムガイドにはプロダクトオーナーが行う場合もあれば開発チームが行う場合もあるいずれの場合も最終的な責任はプロダクトオーナーが持つと記載されている通りプロダクトバックログの管理者プロダクトバックログの作成者である必要はないただしプロダクトオーナーはプロダクトバックログに関する最終的な責任者であるためプロダクトバックログについて開発者ステークホルダーからの質問には答えらえる状態になっていないといけないバックログの順番の根拠教えて望ましくない例ステークホルダーえーと開発チーム説明お願いプロダクトオーナー 18

19 経済性の管理経済性の管理とはマーケットのニーズに対する複数の解決策に対して最も経済的に合理的だと思われる意思決定を行うことマーケットのニーズ顕在ニーズ潜在ニーズプロダクトオーナー 19

20 経済性の管理経済的に合理的とはかけたコストに対して返ってくるリターンが見合っているかどうか (=ROI が高いか ) 例えば 1 週間開発期間を延長し新機能を追加することで収益が 5% 上がる可能性があった場合プロダクトオーナーは 1 週間の時間と費用というコストを犠牲にして開発期間を延長すべきか意思決定を行わないといけないコストリターン 20

21 経済性の管理マーケットには顕在ニーズ ( 主にステークホルダーからの要求 ) と潜在ニーズ ( 仮説 ) が存在するプロダクトオーナーは目に見える顕在ニーズのみに惑わされることなく経済的な観点で優先順位を付けていく必要がある潜在ニーズ実はなことができたら嬉しい値段より品質が大事顕在ニーズ ( 営業 ) 安くして ( 顧客 ) な機能をつけてプロダクトオーナー 21

22 経済性の管理 ROIについてプロダクトオーナーはROIを最大化するため Investmentをコントロールして投入する必要がある Investment Return 性質投入量について期待する結果にコントロール可能ついて予測不可能具体例円の利益を出すために円の広告費を投入する実際の利益額は結果を見ないと分からない 22

23 経済性の管理プロダクトバックログにおける経済性複数の要求の中にはトレードオフな関係もある ( 例 : 新機能をつければ開発期間は長引く ) プロダクトオーナーはその中で最優先事項を判断しプロダクトバックログに反映させなければならないプロダクトバックログ B C A プロダクトバックログ内の優先順は仮説に基づいて決められているそのため新しい情報状況によって優先順位は常に変動するプロダクトオーナーは常に適切な優先順位を確認する必要がある 23

24 経済性の管理注意すべき点開発チームから生み出されるプロダクトの価値の最大化に責任を持つことプロダクトオーナーは常に複数のマーケットの課題と向きないながら自身のミッションであるプロダクトの価値向上につなげていく必要があるまたその際リターンを 1 種類に限定せず誰に対する価値を求めるのか常に意識しないといけない経済的な観点も開発チームに共有するのが望ましい経済的な観点も踏まえて各機能の必要性を開発チームと共有することで透明性が担保され開発チームの機能への関心理解度が増しその結果チームの自律文化を醸成できるそのためプロダクトオーナーは現在の経済状況プロダクトに関する経済的な観点を積極的に共有するのが望ましい 24

25 スクラムチームとの協力プロダクトオーナーはスクラムマスター開発チームと協力しあうことでプロダクトの価値向上というミッションを果せる開発チームスクラムチームプロダクトオーナースクラムマスター 25

26 開発チームとの関わりについてトップダウン型マネージャーの場合進捗管理に重きを置いているため開発チームには進捗報告を常に求めるプロジェクト完了の計画を提示計画との差異に関しては説明を要求指示トップダウン型マネージャー報告開発チーム 26

27 開発チームとの関わりについてプロダクトオーナーの場合開発チームが自律的に開発を進めるためにマーケットの課題優先順位の判断基準スコープ範囲等の提示が求められる開発チームが自律的に開発を進められるような情報を提示することが必要提示プロダクトオーナー受け入れ確認の依頼改善案の提示開発チーム 27

28 スクラムチームとの協力スクラムマスターとの協力第三者的な立ち位置のスクラムマスターからフィードバックを受けることで自身の行動を改善する機会を作れるまたプロダクト開発における障害を相談することで支援を受けることもできる相談プロダクトオーナー支援フィードバックスクラムマスター 28

29 スクラムチームとの協力注意すべき点マイクロマネジメントをしないことスクラムでは開発チームの自己組織化に価値を置いているそのためプロダクトオーナーは開発チームを尊重し開発チーム内のやり方ベロシティに口を出すのは望ましくないそして開発チームがスプリントのゴールを達成できる計画づくりをするための能力を尊重しないといけない開発チームがプロダクトに関する理解を深めるための支援を惜しまないこと開発チームが自己組織化チームになるためにプロダクトに関する理解を深める必要があるプロダクトオーナーは開発チームへの支援として可能な限りプロダクトに関わる情報はすべてオープンすることが望ましいまた理解を促すためにもドキュメントより対面で話すことが最も効果的である 29

30 ステークホルダーとの協力ステークホルダースクラムチーム以外のプロダクト関係者の総称と協力関係を築くことでプロダクトに関する有用な情報の獲得やフィードバックをもらうことができる顧客/ユーザープロダクトオーナー上司/営業/法務etc 30

31 ステークホルダーとの協力注意すべき点ステークホルダーからプロダクトに関する有用な情報を得るための努力を行うのが望ましいステークホルダーからフィードバックを受けることでプロダクトに関する有用な情報や思いもよらないインサイトを得られる可能性があるそのため適切な経済性の管理の元スプリントレビューなどの場を通してステークホルダーからフィードバックが得られる努力を行うのが望ましいステークホルダーの要求を鵜呑みにし過ぎないことステークホルダーの要求は優先順位にも影響を与えるため尊重すべきだが慎重に検討しないといけないなぜならステークホルダーの要求を満たすことが ROI の向上につながるとは限らないためプロダクトオーナーは自身のミッションがあくまでプロダクトの価値向上であることを忘れてはならない 31

32 各セレモニーでの関わりについて 32

33 スクラムを支える 3 つの概念スクラムは以下の 3 つの概念が中心にあるなお各セレモニーはすべて 3 つの概念を体現する場である検査適応各セレモニーにおいて常に自分たちのプロセス成果を検証し新たな事実が判明するたびに適応していくことで仮説検証を行うこれら一連の流れは透明性が担保されることで初めて行うことができる透明性 33

34 各セレモニーでの関わりについてイベント名参加可否プロダクトオーナーの関わりデイリースクラム必須ではないが参加することで現在の進捗状況を把握することができるバックログリファインメントプランニングスプリントレビューレトロスペクティブ必須開発チームが見積もれるようにプロダクトオーナーは各プロダクトバックログアイテムについて情報を共有する必要がある必須現在の経済状況スプリントゴール今後の戦略について開発チームと共有することで開発チームのコミットメントを促す必須レビューで得た情報をバックログに反映させることでバックログの透明性を保つことができる必須ではないが参加することで開発チームだけでは解決困難な課題の解決を図ることができる 34

スクラムと監査についての一考システム監査人協会近畿支部近藤博則

スクラムと監査についての一考システム監査人協会近畿支部近藤博則スクラムと監査についての一考システム監査人協会近畿支部近藤博則自己紹介近藤博則 ( こんどうひろのり ) 昭和 54 年 11 月 4 日生まれ平成 27 年システム監査技術者試験合格関西支部報告 2 本支部メルマガ巻頭言寄稿など支部活動に参加アンケートスクラムを知っていますか? スクラムを使ったとがありますか? スクラムを監査した事がありますか? スクラムが生まれた背景ビジネスの不果実性の増大