【TFSUG】プロダクトオーナーシップ

http://www.flickr.com/photos/plasticbag/2197013436

プロダクトオーナーシップ

柴山 洋徳 @shibao800 2012/9/20

http://www.flickr.com/photos/conchur/3358169824/

Scrum

http://www.flickr.com/photos/conchur/3358169824/

Scrumとは？

複雑なプロダクトを開発・維持

するためのフレームワーク

可能な限り価値の高いプロダクトを

生産的、創造的に届けるためのもの

シンプルでわかりやすいという特徴

Scrumのプロセス

顧客

Scrumのフレームワーク

• プロダクトオーナー

• スクラムマスター

• チームメンバ ロール

• スプリント計画

• スプリントレビュー

• ディリースクラム

• レトロスペクティブ

イベント

• プロダクトバックログ

• スプリントバックログ

• インペディメントリスト 成果物

プロダクトオーナー http://www.flickr.com/photos/28288573@N07/560101355

http://www.flickr.com/photos/28288573@N07/560101355 http://www.flickr.com/photos/saragoldsmith/2896144414

http://www.flickr.com/photos/28288573@N07/560101355

プロダクトオーナー プロダクトの責任者

スクラムマスター プロセスの責任者

http://www.flickr.com/photos/digitalcurrency/2438119267

プロダクトの価値を最大化する

http://www.flickr.com/photos/interllectual/73657348

Sprintに出来る限り詰め込もうとするPO

http://www.flickr.com/photos/kisocci/4359335672

http://www.flickr.com/photos/valeriebb/3006348550

Continuous Question

トレーニングが大切

プロジェクトの成功はPOにかかっている

特に、Scrum導入初期はPOの影響は大

スクラムマスターだけではなく、POのトレーニングも必須

POがお客様の場合は、お客様と一緒のトレーニングも

プロダクトの機能と特徴を定義する

http://www.flickr.com/photos/viagallery/4962826227

http://www.flickr.com/photos/interllectual/73657348

いろいろついてると凄いと思っているPO

http://www.flickr.com/photos/popculturegeek/5917936778

http://www.flickr.com/photos/valeriebb/3006348550

Continuous Question

POもチームメンバー

POもScrumチームのメンバーであり、協調していく

当然、チームはPOに意見してもいい

優先順位付けやフィーチャの価値について意見していこう

プロダクトオーナーチームとしてPOをサポートするのもあり

プロダクトのリリース計画をたてる

http://www.flickr.com/photos/teegardin/5912231439

http://www.flickr.com/photos/interllectual/73657348

リリースのマイルストーンしか決めないPO

http://www.flickr.com/photos/akuchling/59791505

http://www.flickr.com/photos/valeriebb/3006348550

Continuous Question

リリース計画とは戦略である

リリースとは、プロダクトの価値を高める機会

リリース計画は、プロダクトの価値を高める戦略である

価値の流れ→フィーチャの流れ→リリース計画

ユーザーストーリマッピングを使う

プロダクトバックログを管理する

http://www.flickr.com/photos/rameshng/5723481678

http://www.flickr.com/photos/interllectual/73657348

プロダクトバックログを長期間放置するPO

http://www.flickr.com/photos/kentamabuchi/4616039938

http://www.flickr.com/photos/valeriebb/3006348550

Continuous Question

定期的なバックロググルーミング

要求は劣化する。市場、環境は変化している

プロダクトバックログは、プロダクトの価値を体現するもの

しかし、バックログの管理は想像以上にハード

定期的なイベントとして、バックログのお手入れ（バックログ

グルーミング）ミーティングを設定する

成果の受け入れ可否を判断する

http://www.flickr.com/photos/usfsregion5/5808624923

http://www.flickr.com/photos/interllectual/73657348

受け入れ基準を後出しするPO

http://www.flickr.com/photos/31029865@N06/7704553226

http://www.flickr.com/photos/valeriebb/3006348550

Continuous Question

バックログアイテムをReadyにする

バックログアイテムは、スプリント計画会議までにReadyで

ある必要がある

アイテムの受け入れ基準もReadyとなる条件の一つ

受け入れ基準は、DoD(definition of Done)の一つ

DoDは、Scrumの透明性において重要な要素だ

受け入れ基準の後出しは、“無駄”につながる

プロダクトオーナーシップ http://www.flickr.com/photos/tenz1225/6217529904

Visionary

Leadership

Management Technique

プロダクトオーナーシップの4要素

http://www.flickr.com/photos/zzpza/3269784239

http://www.flickr.com/photos/nicmcphee/250890495/

http://www.flickr.com/photos/intelphotos/6763293297

Visionary

http://www.flickr.com/photos/nicmcphee/250890495/

http://www.flickr.com/photos/nicmcphee/250890495/

Visionary

プロダクトのビジョンを描く

「何を作りたいか」ではなく

「なにを解決したいか」

人々の心を動かすのはビジョンと情熱

プロダクトは変化しても、ビジョンは通

常、変化しない

ゴールデンサークル

Why

How

What

ゴールデンサークル～ダメなケース

Why

How

What

ゴールデンサークル～良いケース

Why

How

What

某ALM製品のケース

Why

How

What 我々のALM製品は素晴らしく

自動ビルドからCIまで、なんでもでき、インストールも簡単で、ユーザフレンドリーです。

おひとついかがですか？

TFSのケース

Why

How

What

我々のすることはすべて、ビジネス価値を最大化する開発環境 を実現することが重要だという信念のもとで行っています。

私たちがビジネス価値を最大化する手段は、価値の流れの中で継続的フィードバックを実現する、ソフトウェアライフサイクル全体を統合管理できる製品なのです。

おひとついかがですか？

その結果、こうして素晴らしいALM製品ができあがりました

ゴールデンサークルとビジョン

Vision

Product

Strategy

Management

Management

従来のPMスキルも必須スキル

コントロールパラメータが変わるため、

マネジメント方法の転換が必要

定義済みプロセス制御 VS 経験的

プロセス制御

顧客がいる場合には、リスクの考え方

が変わる

マネジメントトライアングル Fixed Parameter

Variable Parameter

Scope

Time Resource Scope

Time Resource

デスマーチ Fixed Parameter

Variable Parameter

Scope Time Resource

PM PO

スコープマネジメント

予測駆動

ビジネス価値

タイムマネジメント

計画駆動

プロダクト品質

マネジメントの転換

Business

Risk

System

Risk

リスクの変化

明確な「ビジネスリスク」と「システムリスク」の責任分担から、

相互のリスクの共有へ

真のビジネスパートナーシップ

Business

Risk

System

Risk

品質管理の話

内部品質や外部品質のやり方にこだわる前に、やることが

あるんじゃないでしょうか？

Process

Quality

Internal

Quality

External

Quality

Quality

in Use

Leadership

http://www.flickr.com/photos/nicmcphee/250890495/

http://www.flickr.com/photos/nicmcphee/250890495/

Leadership

プロダクトの成功はPOの責任

ビジョンによってチームを強力にリード

協調によりステークホルダーと対話

POはプロダクトに責任はあるが、

チームへ指示することは許されない

勇気 信頼

謙虚 追究

Leadershipの4要素

勇気

TOCの心1：ものごとはそもそもシンプルである

POの意思決定のスピードがビジネスのスピード

POは、大胆な意思決定があらゆる局面で求められる

複雑に思える状況も、紐解けばシンプルと信じ、勇気ある

意思決定を行おう

信頼

TOCの心2：人はもともと善良である

信頼関係の前提は、性善説

POは、チームのパフォーマンスを最大化させねばならない

ビジョンと信頼関係により、自己組織化を促す

追究

TOCの心3：対立には、常に、妥協なき解決方法がある

品質vsデリバリー、計画的なリリースvsプロダクトの適応と

柔軟性、など様々な局面で対立に妥協なき解決をはかる

ビジョン達成のために、妥協のない最高のプロダクトを追究

する

謙虚

TOCの心4：わかっているとは決して言わない

自分の考えていること、知っていることが全て、正しいと思っ

た瞬間から、思考停止が始まる

POは全知全能ではない。本当のユーザは誰ですか？

失敗から学ぶ

Technique

http://www.flickr.com/photos/zzpza/3269784239

http://www.flickr.com/photos/zzpza/3269784239

Technique

POの活動は多岐にわたる

さまざまな活動をサポートするための

テクニックを活用しよう

ビジネスモデルキャンパス

プラグマティックペルソナ

インセプションデッキ

ユーザーストーリーマッピング etc

Technique

詳しく知りたい方は・・・

@fullvirtue さん主催の「プロダクトオーナー勉強会」へ

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

自己紹介 柴山 洋徳 （Twitter:shibao800）

仕事

CCPM/TOC コンサルティング

組織変革コンサルティング

社内システム開発のスクラムマスター

社内システム開発のプロダクトオーナー

社内アジャイルコーチ

Fin. TFS , Team Foundation ServerおよびVisual Studio は、米国 Microsoft CORPORATIONの米国およびその他の国における登録商標または商標です。

その他、記載されている会社名、商品名、サービス名等は、各社の商標または登録商標です。

さあ、今日から、

楽しいプロダクトオーナーライフを送りましょう！