Upcoming SlideShare
アジャイルコーチが現場で学んだプロダクトオーナーの実際と勘所 POの二番目に大事なことと
- 1. アジャイルコーチが 現場で学んだ プロダクトオーナーの実際と勘所 PO祭り2016 11月26日 Copyright© 2016 by 安井力 / やっとむ tsutomu.yasui@gmail.com
- 2. 安井 力 / やっとむ プログラマー Java Python JavaScript C++ テスト駆動開発 アジャイルコーチ ワークショップ 現場導入 技術支援 コンサルタント モデリング ユーザーストーリー
- 3. おねがい •シャッター音は避けてください •資料は公開します •質問は随時どうぞ •寝る、内職、退出、disるのは自由です •周囲の迷惑になることは止してください •世界に平和、人類に愛を
- 4. 本日のテーマ 本読もう、本！ 裏テーマ POの二番目に大事なこと
- 5. そもそも…
- 6. POとチーム
- 7. POとチームの役割 POの役割 プロダクトオーナーは、開発チームの作業とプ ロダクトの価値の最大化に責任を持つ。 チームの役割 開発チームは、各スプリントの終わりにリリー ス判断可能な「完成」したプロダクトインクリ メントを届ける……開発チームは、自分たち の作業を構成・管理する。
- 8. POとチームの役割 PO=プロダクト チーム＝プロダクトインクリメントを届ける POはチームに、プロダクトを理解してもらう チームは、プロダクトインクリメントを 理解して提供する
- 9. プロダクトを理解しよう！ ワーク •チームになったつもりでプロダクトを理解 •POの説明を聞いて把握する •プロダクトを「絵」で表現する
- 10. プロダクトを理解しよう！ ワーク POが書いたストーリーカード 「こんな可愛いキャラクターがいいな」 長い胴体としっぽ 短い四つ足 まん丸のつぶらな眼 赤っぽいエラがチャームポイント
- 11. プロダクトを理解しよう！ ワーク •周囲と見せ合ってください •POの説明と近そうなのはどれ？ •プロダクトとして価値がありそうなのは？
- 12. チームの理解？
- 13. POが欲しかったもの https://matome.naver.jp/odai/2138175303089975601
- 14. プロダクトを理解しよう！ ワーク •周囲と見せ合ってください •POの意図に近い・遠い理由は？ •どうしたらPOの意図を より的確につかめるか？
- 15. なぜ認識が合わなかった？
- 16. なぜ認識が合わなかった？ •不十分な情報しか提示されない •POが言いっ放し •認識が合ってるか確かめるすべがない
- 17. なぜ認識が合わなかった？ •不十分な情報しか提示されない → カードだけでは不足 •POが言いっ放し → 対話と質問が必要 •認識が合ってるか確かめるすべがない → 確認しないとわからない
- 18. 3C プロセス •Card カード •Conversation 会話 •Confirmation 確認
- 19. そもそもスクラムって プロダクトオーナー •プロダクトのリーダーシップの権限を 与えられている スクラムマスター •スクラムの価値、原則、プラクティスを 関係者全員が理解し、受け入れるよう 手助けする 開発チーム •職能を横断する多様な人たちの集まり
- 20. https://www.scrumalliance.org/agile-resources/scrum-roles-dem
- 21. https://www.kogasoftware.com/solution/system_development/development_style/agile_scrum/
- 22. https://www.scrum.as/academy.php?show=0&chapter=5
- 23. http://www.slideshare.net/braintrustgroup/scrum-alliances-certified-agile-leadership-program
- 24. http://mm1.com/scrum-poster-for-easy-implementation-of-scrum-published-by-mm1-consulting-management
- 25. そもそもスクラムって
- 26. https://www.safaribooksonline.com/library/view/the-professional-scrummasters/9781849688024/ch
- 27. https://www.braintrustgroup.com/2014/roles-scrum-attitudes-traits/
- 28. 情報帯域
- 29. ミームの伝わり方: 仕事秒
- 30. ミームの伝わり方: 仕事秒
- 31. アジャイルの心 / Heart of Agile http://alistair.cockburn.us/Rediscovering+the+Heart+of+Agile
- 32. 例: プロダクトバックログアイテム •ビジネス効果と効果測定方法・計画 •案件の価値、存在意義の説明 •必要な時期 •受け入れ条件 •ユースケースシナリオ •機能仕様とビジネスロジック •ワイヤフレーム、デザイン(Excelに画像) •実装上の注意点 •実施要項
- 33. 例: プロダクトバックログアイテムの 扱い方 •POが全部書いて見せる → 急に見せられてもわからん •POが質問 → 持ち帰って確認 → 直後にチームがミーティングを持つ → その場でソース見る •事前に予告するように → 軽く読んでからリファインメント •POが全部説明 → リファインメントで把握 プランニングではチームが説明 •POチームのSlackにチームも入っておく
- 34. POとチームの関係
- 35. POとチームの関係 •超PO •チーム「調査の結果、難しいと…」 PO「いやそんなはずない」 •マイクロマネジメントPO •「Aさんの手が空くよね、だからちょっとだけ これやって」 •弱PO① •チームの主張をぜんぶ通す •弱PO② •チームが新機能や改善を提案して一緒に バックログを作る
- 36. POとチームの関係 •スプリントをバーンダウンしきれない •それが何スプリントか続く •PO「スクラムなんだから スプリントにコミットしろお！」 •チーム萎縮 → 超過大見積もり → モチベーションダウン → メンバー離脱
- 37. コミットメント •従来のコミットメント •見積りが約束とみなされる •同意していないのに約束させられる •約束を達成するよう強いプレッシャーがかかる •アジャイルのコミットメント •チームが最大限努力することに対して •チーム全員が自主的に同意する •実際の速度に則して、実績が乖離したらすぐ 知らせる （「コミットメントとは何か」？ by 吉羽龍太郎)
- 38. チームの働き方を知る •チームは日々、何に時間を使っているのか？ •POの期待ほどアウトプットが出ない理由は？ •プロダクト以外に使っている時間を計測、見え る化する • 機能実現 • 税 • スパイク • 前提条件 (「25章 価値の測定と最適化」)
- 39. 品質をいじるPO •「特定の環境に適応するほど、 新しい環境への適応性を失う」 (フィッシャーの基本法則) •マネージャはパフォーマンスと変更容易性の 適切なトレードオフができない •PO「各メンバーの稼働率を100%にせよ」 •PO「絶対このスプリントで完成させて」
- 40. プログラミングの心理学 •1971年 出版 ※私が生まれるより前 •25周年版 1998年に出版 ※アジャイルより前 「プログラミングチームとは、 協力してよりよい製品を 開発しようとする プログラマーの集まり」
- 41. チームに判断を任せる •技術的負債、リファクタリング、環境整備 •チームの判断に任せる POが理解できないから… •信頼できるチームに任せる ＝ プロの投資家に運用を任せる •わからないから任せる ＝ お母さんにお年玉を預ける
- 42. 効率を上げても効果は上がらない (「23章 維持可能なペース)
- 43. 効果的なレベルを維持する (「23章 維持可能なペース)
- 44. めんどくせー!!
- 45. チームのためではない PO自身のため •効果 ＞ 効率 •正しいものを作る ＞ 正しく作る •価値 ＞ 生産性 •POは自分のためにチームとなる •自分のため ＝ プロダクトのため •プロダクト ＝ 価値
- 46. プロダクトの価値の最大化
- 47. 価値とは…… •製品のユーザーが何を 望んでいるか知りたい •ワクチンの効率的配送 サービスを実現する •会社の資金が底をつきそう •製品が遅い •開発スピードが遅い •猫の画像でにっこりさせたい → 情報 → 人命 → 会社存続 → 実行速度 → 開発速度 → しあわせ
- 48. Jim Coplien CSPO研修より
- 49. WhatとWhy •POはチームに、やってほしいことを伝える •その理由も伝える モチベーションの源泉＝ ・熟達・自律 新たなる「五つの要素技術」― システム思考、自己マスタリー、 メンタル・モデル、 、 チーム学習
- 50. https://www.infoq.com/jp/articles/what-are-self-organising-teams
- 51. 目的の共有の例 •PBIにビジネス目的や指標を明記 •スプリントレビュー時、POが前回リリースしたPBIの 効果をチームに報告することを義務化 •デイリースクラムで毎日、プロダクトKPIを確認 •POがプロダクトへの愛と想いを物語る •ユーザーや顧客と直接会わせる、現場に行かせる •単なる「情報の移動」ではない、相互に理解を 深めていくコミュニケーションを実現する 鍵となるのが「対話」
- 52. ビジョンに対する姿勢の七段階 •無関心 ― 興味なし •不追従 ― やりません •嫌々ながらの追従 ― やるだけ •形だけの追従 ― ビジョンを理解している •心からの追従 ― 割当以上に働く •参画 ― できることはすべて •コミットメント ― 心から望む
- 53. POにとってチームとは •プロダクト実現のために不可欠 •なんでもやってくれる •POの意図を必死に汲んでくれる POと特別な関係にある専門家集団 例) 執事、スポーツトレーナー、 顧問弁護士、栄養管理士
- 54. POにとってチームとは •人間で生き物なので大事に扱う •できないことはやれない •信頼は壊れやすいので慎重に このへんはSMの出番 経営者は「攻撃的」な人が多く、 プログラマーが個人の能力を発揮 しながら協力し合って良い成果を 出すということを理解できない
- 55. POとチームの関係 •ケースバイケース！ •自分たちで考えよう！ •SMにも手伝ってもらおう
- 56. チームの人事
- 57. メンバーはメンバーが決める •増員時 既存メンバーが新メンバーを選ぶ •性格 指向 柔軟性 相性 文化的背景 •はじめのスプリントでは勉強と理解を中心に •試験で理解度や強化すべき点を探る •試験を通じてチームの文化とやり方に馴染ま せる (「20章 新しいチームメンバー」 「21章 文化の衝突」)
- 58. チームを維持する •実際に取り組むべき重要な問題が出て くる前にチームを発足させておくと有利 •チーム学習 ― 現代の組織における 学習の基本単位は個人ではなく チームである •誰もチームを結束させることはできない。 …コントロールしようとすると、すぐに こわれてしまう。
- 59. チーム殺しの秘訣 •自己防衛的な管理 •官僚主義 •作業場所の分散 •時間の分断 •品質低減製品 •さばを読んだ納期 •チーム解体の方針
- 60. 現実は厳しい •長くつきあえるベンダーを探す 育てる •一緒に作る •自社の人間も育ててもらう •プロジェクトを越えて組織で共有する •扱う技術の統一化 •幅広いスキルを持つエンジニアの兼務 •自己組織化したチーム •そういう会社を作る
- 61. スクラムって…… •めんどくさい •難しい •現実の壁
- 62. https://www.linkedin.com/pulse/why-stacey-matrix-model-can-help-understand-agile-baf-kurtulaj-mba Stacey Matrix
- 63. Stacey Matrix https://www.linkedin.com/pulse/why-stacey-matrix-model-can-help-understand-agile-baf-kurtulaj-mba
- 64. Stacey Matrix https://www.linkedin.com/pulse/why-stacey-matrix-model-can-help-understand-agile-baf-kurtulaj-mba
- 65. On Pioneers, Settlers, Town Planners and Theft. by Simon Wardley http://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html
- 66. クネビンフレームワーク 崖
- 67. スクラムって…… • めんどくさい • 難しい • 現実の壁 スクラムとは、革新的なプロダクトやサー ビスを開発するためのアプローチだ。 複雑で変化の激しい問題に対応するための フレームワークであり、可能な限り価値の 高いプロダクトを生産的かつ創造的に 届けるためのものである。
- 68. 役割と責務と仕事
- 69. POのモデルのひとつ: トヨタ主査制度 トヨタ主査制度とは、…一人の製品企画室 主査に担当車種に関する全守備範囲を委ね、 全決定権と全責任の所在とを一元化する… 主査が、担当車種に関する企画（商品計画、 製品企画、販売企画、利益計画など）、開 発（工業意匠、設計、試作、評価など）、 生産・販売（設備投資、生産管理、販売促 進など）の全般を主導し、…すべての責任 を負う。 「担当車種に関しては、主査が社長であり、 社長は主査の助っ人である」
- 70. THE REMARKABLE CHIEF ENGINEER by John Shook http://www.lean.org/shook/DisplayObject.cfm?o=906 役職は判断してもらう権限をともなう あるチーフエンジニア「私はなんの権力もない」 部門担当「チーフエンジニアの方針が間違って いると思えば、反対できます」 チーフエンジニアが使えるのはソフトスキルだけ
- 71. POって…… ムリゲー？
- 72. 役割を混ぜる •PO+SM＝頭が2つあるドラゴン •チーム＋SM＝SMが全体を見なくなる •チーム＋PO＝忙しくてムリ •PO+顧客＝可能性はあるが、対立しがち •「役割を混ぜてなにがいけないのか…そうい う質問をする人は、それぞれ役割が実際に 何をするのか、…ちゃんと理解していない」 （「5章 スクラムの役割）
- 73. 責務と仕事 •PBIを書く •スプリント開始時にPBIを準備するのは POの責務 •PBIを書くのは、チームにもできる •バックログの順序づけ •POの責務 •提案や依頼はチームからも ステークホルダからも •ステークホルダーとの調整 •POの責務 •チームが対応できる分野も多い
- 74. 責務と仕事 •効果と効率 •誰がやるのが効率的？ •スプリントの成果に繋がるのはどっち？ •スクラムチーム全体でプロダクトを作る
- 75. POチーム •大規模スクラムでなくても、POがチームを 組むケース •専門技能のある人が組織内でアクセス できる場合 •UIデザインをスプリント前に作成する場合 •トヨタには主査と主査付という役割がある •「主査と主査付は同一人格（一心同体、 主査付の発言も主査の発言と扱われる）」
- 76. POは忙しい
- 77. POはステークホルダとの架け橋
- 78. リリース計画
- 79. リリース計画 成功の鍵 •包括的で頻繁なコミュニケーション •スプリントごとのリリース計画更新 •優先順位最高のものから •大きなものは再見積もり •各スプリントの動作するソフトウェア提供 （「11章 リリースプランニング」）
- 80. スプリントレビュー •ちゃんと準備 簡単なスライドを用意（1時間） •レビューでチームが説明・デモする代わりに、 顧客やステークホルダーに実際に操作して もらう 成功の鍵 •準備に時間をかける •決定事項を記録する •その場で受け入れる •勇気を出す （「15章 スプリントレビュー」）
- 81. ショウ＆テル: レビューの別案 「…毎週の儀式で顧客と見せ合う。その 儀式をショウ＆テルと呼んでいる。ショウ ＆テルでは、その週にプロジェクトに携 わったチームが聞き役となる。説明役は 顧客だ」 「ショウ＆テルは重要なやりとりだ。 顧客は、プロジェクトを実際に やっている人たちと議論ができる。」
- 82. フィードバックを得る •顧客やステークホルダーから ― スプリントレビュー •ユーザーから ― ログ、アクセス解析、直接 •プロダクトから ― モニタリング、エラーログ •チームから ― ベロシティ、技術的負債、バーンダウン
- 83. フィードバック機能を仕込む •アクセス解析 •A/Bテスト •デモ用のサーバで起きた問題を すべてログ収集 •アプリケーションクラッシュ時に コールスタックをログ出力、 開発チームにメールで送付
- 84. リスクマネジメント •機会の窓 ― •リスクという「バス」 •バスが窓をくぐり抜ける •スプリントが進むと窓はだんだん狭くなる •大きなバス（リスク）は早期に通しておく （「24章 動作するソフトウェアを届ける」） •必要なドキュメントを、進みながら書く (「27章 スクラムにおけるドキュメント」) •欠陥は即時に対応、1時間過ぎても 解決しなかったら、PBIとして管理する (「13章 欠陥を抑制する」)
- 85. リリース計画でリスクを盛り込む リスクを見積りの幅で表現
- 86. リリース計画でリスクを盛り込む よい計画づくりとは、以下のような特徴を持っ たプロセスのことだ。いずれも「ソフトウェア開 発の問い」に対する答えを見つける手助けと なる。 ・リスクを軽減する ・不確実性を減らす ・意思決定を支援する ・信頼を確立する ・情報を伝達する
- 87. スクラムのリスクマネジメント •従来型、計画駆動のリスクマネジメント ⇒ リスクは計画に組み込む ⇒ リスクマネジメントは計画を作る人 ＝ プロジェクトマネージャの仕事 •スクラムのリスクマネジメント ⇒ 計画はみんなで作る（リリース計画は最善の予報） ⇒ リスクマネジメントはみんなの仕事 •プロダクトのリスク → PO •技術的リスク → チーム •プロセスのリスク → SM
- 88. なぜスクラム？
- 89. スクラム •価値あるプロダクト •ハイパフォーマンスなチーム •常に改善し続ける だから？
- 90. 紹介した書籍（順不同） • “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
Login to see the comments