プロダクトオーナーが知っておくべき、チームやステークホルダーとの付き合い方、価値やリスクマネジメントの考え方を紹介しています。 PO祭り2016（2016年11月26日）での基調講演の資料です。

1. アジャイルコーチが
現場で学んだ
プロダクトオーナーの実際と勘所
PO祭り2016 11月26日
Copyright© 2016 by 安井力 / やっとむ tsutomu.yasui@gmail.com

2. 安井 力 / やっとむ
プログラマー
Java Python JavaScript C++
テスト駆動開発
アジャイルコーチ
ワークショップ 現場導入 技術支援
コンサルタント
モデリング ユーザーストーリー

4. おねがい
•シャッター音は避けてください
•資料は公開します
•質問は随時どうぞ
•寝る、内職、退出、disるのは自由です
•周囲の迷惑になることは止してください
•世界に平和、人類に愛を

5. 本日のテーマ
本読もう、本！
裏テーマ
POの二番目に大事なこと

6. そもそも…

8. POとチーム

9. POとチームの役割
POの役割
プロダクトオーナーは、開発チームの作業とプ
ロダクトの価値の最大化に責任を持つ。
チームの役割
開発チームは、各スプリントの終わりにリリー
ス判断可能な「完成」したプロダクトインクリ
メントを届ける……開発チームは、自分たち
の作業を構成・管理する。

10. POとチームの役割
PO=プロダクト
チーム＝プロダクトインクリメントを届ける
POはチームに、プロダクトを理解してもらう
チームは、プロダクトインクリメントを
理解して提供する

11. プロダクトを理解しよう！ ワーク
•チームになったつもりでプロダクトを理解
•POの説明を聞いて把握する
•プロダクトを「絵」で表現する

12. プロダクトを理解しよう！ ワーク
POが書いたストーリーカード
「こんな可愛いキャラクターがいいな」
長い胴体としっぽ 短い四つ足
まん丸のつぶらな眼
赤っぽいエラがチャームポイント

13. プロダクトを理解しよう！ ワーク
•周囲と見せ合ってください
•POの説明と近そうなのはどれ？
•プロダクトとして価値がありそうなのは？

14. チームの理解？

15. POが欲しかったもの
https://matome.naver.jp/odai/2138175303089975601

16. プロダクトを理解しよう！ ワーク
•周囲と見せ合ってください
•POの意図に近い・遠い理由は？
•どうしたらPOの意図を
より的確につかめるか？

17. なぜ認識が合わなかった？

18. なぜ認識が合わなかった？
•不十分な情報しか提示されない
•POが言いっ放し
•認識が合ってるか確かめるすべがない

19. なぜ認識が合わなかった？
•不十分な情報しか提示されない
→ カードだけでは不足
•POが言いっ放し
→ 対話と質問が必要
•認識が合ってるか確かめるすべがない
→ 確認しないとわからない

20. 3C プロセス
•Card カード
•Conversation 会話
•Confirmation 確認

21. そもそもスクラムって
プロダクトオーナー
•プロダクトのリーダーシップの権限を
与えられている
スクラムマスター
•スクラムの価値、原則、プラクティスを
関係者全員が理解し、受け入れるよう
手助けする
開発チーム
•職能を横断する多様な人たちの集まり

22. https://www.scrumalliance.org/agile-resources/scrum-roles-dem

23. https://www.kogasoftware.com/solution/system_development/development_style/agile_scrum/

24. https://www.scrum.as/academy.php?show=0&chapter=5

25. http://www.slideshare.net/braintrustgroup/scrum-alliances-certified-agile-leadership-program

26. http://mm1.com/scrum-poster-for-easy-implementation-of-scrum-published-by-mm1-consulting-management

28. そもそもスクラムって

29. https://www.safaribooksonline.com/library/view/the-professional-scrummasters/9781849688024/ch

30. https://www.braintrustgroup.com/2014/roles-scrum-attitudes-traits/

31. 情報帯域

32. ミームの伝わり方: 仕事秒

33. ミームの伝わり方: 仕事秒

34. アジャイルの心 / Heart of Agile
http://alistair.cockburn.us/Rediscovering+the+Heart+of+Agile

35. 例: プロダクトバックログアイテム
•ビジネス効果と効果測定方法・計画
•案件の価値、存在意義の説明
•必要な時期
•受け入れ条件
•ユースケースシナリオ
•機能仕様とビジネスロジック
•ワイヤフレーム、デザイン(Excelに画像)
•実装上の注意点
•実施要項

36. 例: プロダクトバックログアイテムの
扱い方
•POが全部書いて見せる
→ 急に見せられてもわからん
•POが質問 → 持ち帰って確認
→ 直後にチームがミーティングを持つ
→ その場でソース見る
•事前に予告するように
→ 軽く読んでからリファインメント
•POが全部説明 → リファインメントで把握
プランニングではチームが説明
•POチームのSlackにチームも入っておく

38. POとチームの関係

39. POとチームの関係
•超PO
•チーム「調査の結果、難しいと…」
PO「いやそんなはずない」
•マイクロマネジメントPO
•「Aさんの手が空くよね、だからちょっとだけ
これやって」
•弱PO①
•チームの主張をぜんぶ通す
•弱PO②
•チームが新機能や改善を提案して一緒に
バックログを作る

40. POとチームの関係
•スプリントをバーンダウンしきれない
•それが何スプリントか続く
•PO「スクラムなんだから
スプリントにコミットしろお！」
•チーム萎縮 → 超過大見積もり
→ モチベーションダウン → メンバー離脱

41. コミットメント
•従来のコミットメント
•見積りが約束とみなされる
•同意していないのに約束させられる
•約束を達成するよう強いプレッシャーがかかる
•アジャイルのコミットメント
•チームが最大限努力することに対して
•チーム全員が自主的に同意する
•実際の速度に則して、実績が乖離したらすぐ
知らせる
（「コミットメントとは何か」？ by 吉羽龍太郎)

42. チームの働き方を知る
•チームは日々、何に時間を使っているのか？
•POの期待ほどアウトプットが出ない理由は？
•プロダクト以外に使っている時間を計測、見え
る化する
• 機能実現
• 税
• スパイク
• 前提条件
(「25章 価値の測定と最適化」)

43. 品質をいじるPO
•「特定の環境に適応するほど、
新しい環境への適応性を失う」
(フィッシャーの基本法則)
•マネージャはパフォーマンスと変更容易性の
適切なトレードオフができない
•PO「各メンバーの稼働率を100%にせよ」
•PO「絶対このスプリントで完成させて」

44. プログラミングの心理学
•1971年 出版
※私が生まれるより前
•25周年版 1998年に出版
※アジャイルより前
「プログラミングチームとは、
協力してよりよい製品を
開発しようとする
プログラマーの集まり」

45. チームに判断を任せる
•技術的負債、リファクタリング、環境整備
•チームの判断に任せる
POが理解できないから…
•信頼できるチームに任せる
＝ プロの投資家に運用を任せる
•わからないから任せる
＝ お母さんにお年玉を預ける

46. 効率を上げても効果は上がらない
(「23章 維持可能なペース)

47. 効果的なレベルを維持する
(「23章 維持可能なペース)

48. めんどくせー!!

49. チームのためではない
PO自身のため
•効果 ＞ 効率
•正しいものを作る ＞ 正しく作る
•価値 ＞ 生産性
•POは自分のためにチームとなる
•自分のため ＝ プロダクトのため
•プロダクト ＝ 価値

50. プロダクトの価値の最大化

52. 価値とは……
•製品のユーザーが何を
望んでいるか知りたい
•ワクチンの効率的配送
サービスを実現する
•会社の資金が底をつきそう
•製品が遅い
•開発スピードが遅い
•猫の画像でにっこりさせたい
→ 情報
→ 人命
→ 会社存続
→ 実行速度
→ 開発速度
→ しあわせ

53. Jim Coplien
CSPO研修より

54. WhatとWhy
•POはチームに、やってほしいことを伝える
•その理由も伝える
モチベーションの源泉＝ ・熟達・自律
新たなる「五つの要素技術」―
システム思考、自己マスタリー、
メンタル・モデル、 、
チーム学習

55. https://www.infoq.com/jp/articles/what-are-self-organising-teams

56. 目的の共有の例
•PBIにビジネス目的や指標を明記
•スプリントレビュー時、POが前回リリースしたPBIの
効果をチームに報告することを義務化
•デイリースクラムで毎日、プロダクトKPIを確認
•POがプロダクトへの愛と想いを物語る
•ユーザーや顧客と直接会わせる、現場に行かせる
•単なる「情報の移動」ではない、相互に理解を
深めていくコミュニケーションを実現する
鍵となるのが「対話」

57. ビジョンに対する姿勢の七段階
•無関心 ― 興味なし
•不追従 ― やりません
•嫌々ながらの追従 ― やるだけ
•形だけの追従 ― ビジョンを理解している
•心からの追従 ― 割当以上に働く
•参画 ― できることはすべて
•コミットメント ― 心から望む

59. POにとってチームとは
•プロダクト実現のために不可欠
•なんでもやってくれる
•POの意図を必死に汲んでくれる
POと特別な関係にある専門家集団
例) 執事、スポーツトレーナー、
顧問弁護士、栄養管理士

60. POにとってチームとは
•人間で生き物なので大事に扱う
•できないことはやれない
•信頼は壊れやすいので慎重に
このへんはSMの出番
経営者は「攻撃的」な人が多く、
プログラマーが個人の能力を発揮
しながら協力し合って良い成果を
出すということを理解できない

61. POとチームの関係
•ケースバイケース！
•自分たちで考えよう！
•SMにも手伝ってもらおう

62. チームの人事

63. メンバーはメンバーが決める
•増員時 既存メンバーが新メンバーを選ぶ
•性格 指向 柔軟性 相性 文化的背景
•はじめのスプリントでは勉強と理解を中心に
•試験で理解度や強化すべき点を探る
•試験を通じてチームの文化とやり方に馴染ま
せる
(「20章 新しいチームメンバー」
「21章 文化の衝突」)

65. チームを維持する
•実際に取り組むべき重要な問題が出て
くる前にチームを発足させておくと有利
•チーム学習 ― 現代の組織における
学習の基本単位は個人ではなく
チームである
•誰もチームを結束させることはできない。
…コントロールしようとすると、すぐに
こわれてしまう。

66. チーム殺しの秘訣
•自己防衛的な管理
•官僚主義
•作業場所の分散
•時間の分断
•品質低減製品
•さばを読んだ納期
•チーム解体の方針

67. 現実は厳しい
•長くつきあえるベンダーを探す 育てる
•一緒に作る
•自社の人間も育ててもらう
•プロジェクトを越えて組織で共有する
•扱う技術の統一化
•幅広いスキルを持つエンジニアの兼務
•自己組織化したチーム
•そういう会社を作る

68. スクラムって……
•めんどくさい
•難しい
•現実の壁

69. https://www.linkedin.com/pulse/why-stacey-matrix-model-can-help-understand-agile-baf-kurtulaj-mba
Stacey Matrix

70. Stacey Matrix
https://www.linkedin.com/pulse/why-stacey-matrix-model-can-help-understand-agile-baf-kurtulaj-mba

71. Stacey Matrix
https://www.linkedin.com/pulse/why-stacey-matrix-model-can-help-understand-agile-baf-kurtulaj-mba

72. On Pioneers, Settlers, Town Planners and Theft. by Simon Wardley
http://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html

73. クネビンフレームワーク
崖

74. スクラムって……
• めんどくさい
• 難しい
• 現実の壁
スクラムとは、革新的なプロダクトやサー
ビスを開発するためのアプローチだ。
複雑で変化の激しい問題に対応するための
フレームワークであり、可能な限り価値の
高いプロダクトを生産的かつ創造的に
届けるためのものである。

75. 役割と責務と仕事

77. POのモデルのひとつ:
トヨタ主査制度
トヨタ主査制度とは、…一人の製品企画室
主査に担当車種に関する全守備範囲を委ね、
全決定権と全責任の所在とを一元化する…
主査が、担当車種に関する企画（商品計画、
製品企画、販売企画、利益計画など）、開
発（工業意匠、設計、試作、評価など）、
生産・販売（設備投資、生産管理、販売促
進など）の全般を主導し、…すべての責任
を負う。
「担当車種に関しては、主査が社長であり、
社長は主査の助っ人である」

78. THE REMARKABLE CHIEF ENGINEER by John Shook
http://www.lean.org/shook/DisplayObject.cfm?o=906
役職は判断してもらう権限をともなう
あるチーフエンジニア「私はなんの権力もない」
部門担当「チーフエンジニアの方針が間違って
いると思えば、反対できます」
チーフエンジニアが使えるのはソフトスキルだけ

79. POって……
ムリゲー？

80. 役割を混ぜる
•PO+SM＝頭が2つあるドラゴン
•チーム＋SM＝SMが全体を見なくなる
•チーム＋PO＝忙しくてムリ
•PO+顧客＝可能性はあるが、対立しがち
•「役割を混ぜてなにがいけないのか…そうい
う質問をする人は、それぞれ役割が実際に
何をするのか、…ちゃんと理解していない」
（「5章 スクラムの役割）

81. 責務と仕事
•PBIを書く
•スプリント開始時にPBIを準備するのは
POの責務
•PBIを書くのは、チームにもできる
•バックログの順序づけ
•POの責務
•提案や依頼はチームからも
ステークホルダからも
•ステークホルダーとの調整
•POの責務
•チームが対応できる分野も多い

82. 責務と仕事
•効果と効率
•誰がやるのが効率的？
•スプリントの成果に繋がるのはどっち？
•スクラムチーム全体でプロダクトを作る

83. POチーム
•大規模スクラムでなくても、POがチームを
組むケース
•専門技能のある人が組織内でアクセス
できる場合
•UIデザインをスプリント前に作成する場合
•トヨタには主査と主査付という役割がある
•「主査と主査付は同一人格（一心同体、
主査付の発言も主査の発言と扱われる）」

84. POは忙しい

86. POはステークホルダとの架け橋

87. リリース計画

88. リリース計画
成功の鍵
•包括的で頻繁なコミュニケーション
•スプリントごとのリリース計画更新
•優先順位最高のものから
•大きなものは再見積もり
•各スプリントの動作するソフトウェア提供
（「11章 リリースプランニング」）

89. スプリントレビュー
•ちゃんと準備 簡単なスライドを用意（1時間）
•レビューでチームが説明・デモする代わりに、
顧客やステークホルダーに実際に操作して
もらう
成功の鍵
•準備に時間をかける
•決定事項を記録する
•その場で受け入れる
•勇気を出す （「15章 スプリントレビュー」）

90. ショウ＆テル: レビューの別案
「…毎週の儀式で顧客と見せ合う。その
儀式をショウ＆テルと呼んでいる。ショウ
＆テルでは、その週にプロジェクトに携
わったチームが聞き役となる。説明役は
顧客だ」
「ショウ＆テルは重要なやりとりだ。
顧客は、プロジェクトを実際に
やっている人たちと議論ができる。」

91. フィードバックを得る
•顧客やステークホルダーから
― スプリントレビュー
•ユーザーから
― ログ、アクセス解析、直接
•プロダクトから
― モニタリング、エラーログ
•チームから
― ベロシティ、技術的負債、バーンダウン

93. フィードバック機能を仕込む
•アクセス解析
•A/Bテスト
•デモ用のサーバで起きた問題を
すべてログ収集
•アプリケーションクラッシュ時に
コールスタックをログ出力、
開発チームにメールで送付

94. リスクマネジメント
•機会の窓 ―
•リスクという「バス」
•バスが窓をくぐり抜ける
•スプリントが進むと窓はだんだん狭くなる
•大きなバス（リスク）は早期に通しておく
（「24章 動作するソフトウェアを届ける」）
•必要なドキュメントを、進みながら書く
(「27章 スクラムにおけるドキュメント」)
•欠陥は即時に対応、1時間過ぎても
解決しなかったら、PBIとして管理する
(「13章 欠陥を抑制する」)

95. リリース計画でリスクを盛り込む
リスクを見積りの幅で表現

96. リリース計画でリスクを盛り込む
よい計画づくりとは、以下のような特徴を持っ
たプロセスのことだ。いずれも「ソフトウェア開
発の問い」に対する答えを見つける手助けと
なる。
・リスクを軽減する
・不確実性を減らす
・意思決定を支援する
・信頼を確立する
・情報を伝達する

97. スクラムのリスクマネジメント
•従来型、計画駆動のリスクマネジメント
⇒ リスクは計画に組み込む
⇒ リスクマネジメントは計画を作る人
＝ プロジェクトマネージャの仕事
•スクラムのリスクマネジメント
⇒ 計画はみんなで作る（リリース計画は最善の予報）
⇒ リスクマネジメントはみんなの仕事
•プロダクトのリスク → PO
•技術的リスク → チーム
•プロセスのリスク → SM

98. なぜスクラム？

99. スクラム
•価値あるプロダクト
•ハイパフォーマンスなチーム
•常に改善し続ける
だから？

101. 紹介した書籍（順不同）
• “The Nature of Software Development” Ron Jefferies http://amzn.to/2gqUkPR
• 『プログラミングの心理学 25周年記念版』 G.M.ワインバーグ http://amzn.to/2geCRHx
• 『実践アジャイルテスト』Janet Gregory, Lisa Crispin http://amzn.to/2gpXtM6
• 『アジャイルソフトウエア開発』アリスター・コーバーン http://amzn.to/2geK36j
• 『スクラム現場ガイド』Mitch Lacey http://amzn.to/2gvusQw
• 『スクラムガイド』Jeff Sutherland, Ken Schwaber http://bit.ly/1MHj3Ev
• 『モチベーション3.0』ダニエル・ピンク http://amzn.to/2g1fDa3
• 『 Joy, Inc. 』Richard Sheridan http://bit.ly/2gvsWhj
• 『Ultimate Agile Stories Iteration 1』 http://bit.ly/2g1diMe
• 『 「納品」をなくせばうまくいく！』倉貫義人 http://amzn.to/2gIH5uv
• 『ピープルウェア 第3版』トム・デマルコ、ティモシー・リスター http://amzn.to/2firDom
• 『ドキュメント トヨタの製品開発』安達瑛二 http://amzn.to/2fxyIgn
• 『 Joel on Software』Joel Spolsky http://amzn.to/2gqTYIY
• 『学習する組織』ピーター・M・センゲ http://amzn.to/2g1hM5D
• 『エッセンシャルスクラム』Kenneth S. Rubin http://amzn.to/2g1guI0
• 『アジャイルな見積りと計画づくり』Mike Cohn http://amzn.to/2fiuRbu