http://www.flickr.com/photos/plasticbag/2197013436 プロダクトオーナーシップ 柴山 洋徳 @shibao800 2012/9/20
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の米国およびその他の国における登録商標または商標です。
その他、記載されている会社名、商品名、サービス名等は、各社の商標または登録商標です。
さあ、今日から、
楽しいプロダクトオーナーライフを送りましょう!