アジャイルコーチが現場で学んだ

プロダクトオーナーの実際と勘所

PO祭り2016 11月26日

Copyright© 2016 by 安井力 / やっとむ tsutomu.yasui@gmail.com

安井 力 / やっとむ

プログラマーJava Python JavaScript C++

テスト駆動開発

アジャイルコーチワークショップ 現場導入 技術支援

コンサルタントモデリング ユーザーストーリー

おねがい

•シャッター音は避けてください

•資料は公開します

•質問は随時どうぞ

•寝る、内職、退出、disるのは自由です

•周囲の迷惑になることは止してください

•世界に平和、人類に愛を

本日のテーマ本読もう、本！

裏テーマPOの二番目に大事なこと

そもそも…

POとチーム

POとチームの役割

POの役割

プロダクトオーナーは、開発チームの作業とプロダクトの価値の最大化に責任を持つ。

チームの役割

開発チームは、各スプリントの終わりにリリース判断可能な「完成」したプロダクトインクリメントを届ける……開発チームは、自分たちの作業を構成・管理する。

POとチームの役割

PO=プロダクト

チーム＝プロダクトインクリメントを届ける

POはチームに、プロダクトを理解してもらう

チームは、プロダクトインクリメントを理解して提供する

プロダクトを理解しよう！ワーク

•チームになったつもりでプロダクトを理解

•POの説明を聞いて把握する

•プロダクトを「絵」で表現する

プロダクトを理解しよう！ワーク

POが書いたストーリーカード

「こんな可愛いキャラクターがいいな」

長い胴体としっぽ短い四つ足まん丸のつぶらな眼赤っぽいエラがチャームポイント

プロダクトを理解しよう！ワーク

•周囲と見せ合ってください

•POの説明と近そうなのはどれ？

•プロダクトとして価値がありそうなのは？

チームの理解？

POが欲しかったもの

https://matome.naver.jp/odai/2138175303089975601

プロダクトを理解しよう！ワーク

•周囲と見せ合ってください

•POの意図に近い・遠い理由は？

•どうしたらPOの意図をより的確につかめるか？

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

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

•不十分な情報しか提示されない

•POが言いっ放し

•認識が合ってるか確かめるすべがない

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

•不十分な情報しか提示されない

→ カードだけでは不足

•POが言いっ放し

→ 対話と質問が必要

•認識が合ってるか確かめるすべがない

→ 確認しないとわからない

3C プロセス

•Card カード

•Conversation 会話

•Confirmation 確認

そもそもスクラムって

プロダクトオーナー•プロダクトのリーダーシップの権限を与えられている

スクラムマスター•スクラムの価値、原則、プラクティスを関係者全員が理解し、受け入れるよう手助けする

開発チーム•職能を横断する多様な人たちの集まり

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

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

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

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

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

そもそもスクラムって

https://www.safaribooksonline.com/library/view/the-professional-scrummasters/9781849688024/ch01s04.html

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

情報帯域

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

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

アジャイルの心 / Heart of Agile

http://alistair.cockburn.us/Rediscovering+the+Heart+of+Agile

例: プロダクトバックログアイテム

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

例: プロダクトバックログアイテムの扱い方

•POが全部書いて見せる→ 急に見せられてもわからん

•POが質問 → 持ち帰って確認→ 直後にチームがミーティングを持つ→ その場でソース見る

•事前に予告するように→ 軽く読んでからリファインメント

•POが全部説明 → リファインメントで把握プランニングではチームが説明•POチームのSlackにチームも入っておく

POとチームの関係

POとチームの関係

•超PO•チーム「調査の結果、難しいと…」

PO「いやそんなはずない」•マイクロマネジメントPO•「Aさんの手が空くよね、だからちょっとだけ

これやって」•弱PO①•チームの主張をぜんぶ通す

•弱PO②•チームが新機能や改善を提案して一緒に

バックログを作る

POとチームの関係

•スプリントをバーンダウンしきれない

•それが何スプリントか続く

•PO「スクラムなんだからスプリントにコミットしろお！」

•チーム萎縮 → 超過大見積もり→ モチベーションダウン → メンバー離脱

コミットメント

•従来のコミットメント•見積りが約束とみなされる•同意していないのに約束させられる•約束を達成するよう強いプレッシャーがかかる

•アジャイルのコミットメント•チームが最大限努力することに対して•チーム全員が自主的に同意する•実際の速度に則して、実績が乖離したらすぐ

知らせる（「コミットメントとは何か」？ by 吉羽龍太郎)

チームの働き方を知る

•チームは日々、何に時間を使っているのか？•POの期待ほどアウトプットが出ない理由は？

•プロダクト以外に使っている時間を計測、見える化する• 機能実現• 税• スパイク• 前提条件

(「25章 価値の測定と最適化」)

品質をいじるPO

•「特定の環境に適応するほど、新しい環境への適応性を失う」

(フィッシャーの基本法則)

•マネージャはパフォーマンスと変更容易性の適切なトレードオフができない

•PO「各メンバーの稼働率を100%にせよ」

•PO「絶対このスプリントで完成させて」

プログラミングの心理学

•1971年 出版※私が生まれるより前

•25周年版 1998年に出版※アジャイルより前

「プログラミングチームとは、協力してよりよい製品を開発しようとするプログラマーの集まり」

チームに判断を任せる

•技術的負債、リファクタリング、環境整備

•チームの判断に任せるPOが理解できないから…

•信頼できるチームに任せる＝ プロの投資家に運用を任せる

•わからないから任せる＝ お母さんにお年玉を預ける

効率を上げても効果は上がらない

(「23章 維持可能なペース)

効果的なレベルを維持する

(「23章 維持可能なペース)

めんどくせー!!

チームのためではないPO自身のため

•効果 ＞ 効率

•正しいものを作る ＞ 正しく作る

•価値 ＞ 生産性

•POは自分のためにチームとなる•自分のため ＝ プロダクトのため•プロダクト ＝ 価値

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

価値とは……

•製品のユーザーが何を望んでいるか知りたい

•ワクチンの効率的配送サービスを実現する

•会社の資金が底をつきそう

•製品が遅い

•開発スピードが遅い

•猫の画像でにっこりさせたい

→情報

→人命

→会社存続

→実行速度

→開発速度

→しあわせ

Jim CoplienCSPO研修より

WhatとWhy

•POはチームに、やってほしいことを伝える•その理由も伝える

モチベーションの源泉＝ ・熟達・自律

新たなる「五つの要素技術」―システム思考、自己マスタリー、メンタル・モデル、 、チーム学習

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

目的の共有の例

•PBIにビジネス目的や指標を明記•スプリントレビュー時、POが前回リリースしたPBIの

効果をチームに報告することを義務化•デイリースクラムで毎日、プロダクトKPIを確認•POがプロダクトへの愛と想いを物語る•ユーザーや顧客と直接会わせる、現場に行かせる

•単なる「情報の移動」ではない、相互に理解を深めていくコミュニケーションを実現する鍵となるのが「対話」

ビジョンに対する姿勢の七段階

•無関心 ― 興味なし

•不追従 ― やりません

•嫌々ながらの追従 ― やるだけ

•形だけの追従 ― ビジョンを理解している

•心からの追従 ― 割当以上に働く

•参画 ― できることはすべて

•コミットメント ― 心から望む

POにとってチームとは

•プロダクト実現のために不可欠

•なんでもやってくれる

•POの意図を必死に汲んでくれる

POと特別な関係にある専門家集団

例) 執事、スポーツトレーナー、顧問弁護士、栄養管理士

POにとってチームとは

•人間で生き物なので大事に扱う

•できないことはやれない

•信頼は壊れやすいので慎重に

このへんはSMの出番

経営者は「攻撃的」な人が多く、プログラマーが個人の能力を発揮しながら協力し合って良い成果を出すということを理解できない

POとチームの関係

•ケースバイケース！

•自分たちで考えよう！•SMにも手伝ってもらおう

チームの人事

メンバーはメンバーが決める

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

(「20章 新しいチームメンバー」

「21章 文化の衝突」)

チームを維持する

•実際に取り組むべき重要な問題が出てくる前にチームを発足させておくと有利

•チーム学習 ― 現代の組織における学習の基本単位は個人ではなくチームである

•誰もチームを結束させることはできない。…コントロールしようとすると、すぐにこわれてしまう。

チーム殺しの秘訣

•自己防衛的な管理

•官僚主義

•作業場所の分散

•時間の分断

•品質低減製品

•さばを読んだ納期

•チーム解体の方針

現実は厳しい

•長くつきあえるベンダーを探す 育てる•一緒に作る•自社の人間も育ててもらう

•プロジェクトを越えて組織で共有する•扱う技術の統一化•幅広いスキルを持つエンジニアの兼務•自己組織化したチーム

•そういう会社を作る

スクラムって……

•めんどくさい

•難しい

•現実の壁

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

Stacey Matrix

Stacey Matrix

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

Stacey Matrix

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

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

クネビンフレームワーク

崖

スクラムって……

• めんどくさい

• 難しい

• 現実の壁

スクラムとは、革新的なプロダクトやサービスを開発するためのアプローチだ。

複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである。

役割と責務と仕事

POのモデルのひとつ: トヨタ主査制度

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

社長は主査の助っ人である」

THE REMARKABLE CHIEF ENGINEER by John Shookhttp://www.lean.org/shook/DisplayObject.cfm?o=906

役職は判断してもらう権限をともなう

あるチーフエンジニア「私はなんの権力もない」

部門担当「チーフエンジニアの方針が間違っていると思えば、反対できます」

チーフエンジニアが使えるのはソフトスキルだけ

POって……

ムリゲー？

役割を混ぜる

•PO+SM＝頭が2つあるドラゴン•チーム＋SM＝SMが全体を見なくなる•チーム＋PO＝忙しくてムリ•PO+顧客＝可能性はあるが、対立しがち

•「役割を混ぜてなにがいけないのか…そういう質問をする人は、それぞれ役割が実際に何をするのか、…ちゃんと理解していない」

（「5章 スクラムの役割）

責務と仕事

•PBIを書く•スプリント開始時にPBIを準備するのは

POの責務•PBIを書くのは、チームにもできる

•バックログの順序づけ•POの責務•提案や依頼はチームからも

ステークホルダからも•ステークホルダーとの調整•POの責務•チームが対応できる分野も多い

責務と仕事

•効果と効率•誰がやるのが効率的？•スプリントの成果に繋がるのはどっち？

•スクラムチーム全体でプロダクトを作る

POチーム

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

主査付の発言も主査の発言と扱われる）」

POは忙しい

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

リリース計画

リリース計画

成功の鍵

•包括的で頻繁なコミュニケーション

•スプリントごとのリリース計画更新

•優先順位最高のものから

•大きなものは再見積もり

•各スプリントの動作するソフトウェア提供

（「11章 リリースプランニング」）

スプリントレビュー

•ちゃんと準備 簡単なスライドを用意（1時間）•レビューでチームが説明・デモする代わりに、顧客やステークホルダーに実際に操作してもらう

成功の鍵•準備に時間をかける•決定事項を記録する•その場で受け入れる•勇気を出す （「15章 スプリントレビュー」）

ショウ＆テル: レビューの別案

「…毎週の儀式で顧客と見せ合う。その儀式をショウ＆テルと呼んでいる。ショウ＆テルでは、その週にプロジェクトに携わったチームが聞き役となる。説明役は顧客だ」

「ショウ＆テルは重要なやりとりだ。顧客は、プロジェクトを実際にやっている人たちと議論ができる。」

フィードバックを得る

•顧客やステークホルダーから― スプリントレビュー

•ユーザーから― ログ、アクセス解析、直接

•プロダクトから― モニタリング、エラーログ

•チームから― ベロシティ、技術的負債、バーンダウン

フィードバック機能を仕込む

•アクセス解析•A/Bテスト

•デモ用のサーバで起きた問題をすべてログ収集•アプリケーションクラッシュ時にコールスタックをログ出力、開発チームにメールで送付

リスクマネジメント

•機会の窓 ― •リスクという「バス」•バスが窓をくぐり抜ける•スプリントが進むと窓はだんだん狭くなる•大きなバス（リスク）は早期に通しておく

（「24章 動作するソフトウェアを届ける」）

•必要なドキュメントを、進みながら書く(「27章 スクラムにおけるドキュメント」)

•欠陥は即時に対応、1時間過ぎても解決しなかったら、PBIとして管理する(「13章 欠陥を抑制する」)

リリース計画でリスクを盛り込む

リスクを見積りの幅で表現

リリース計画でリスクを盛り込む

よい計画づくりとは、以下のような特徴を持ったプロセスのことだ。いずれも「ソフトウェア開発の問い」に対する答えを見つける手助けとなる。

・リスクを軽減する

・不確実性を減らす

・意思決定を支援する

・信頼を確立する

・情報を伝達する

スクラムのリスクマネジメント

•従来型、計画駆動のリスクマネジメント⇒ リスクは計画に組み込む⇒ リスクマネジメントは計画を作る人

＝ プロジェクトマネージャの仕事

•スクラムのリスクマネジメント⇒ 計画はみんなで作る（リリース計画は最善の予報）⇒ リスクマネジメントはみんなの仕事•プロダクトのリスク → PO•技術的リスク → チーム•プロセスのリスク → SM

なぜスクラム？

スクラム

•価値あるプロダクト

•ハイパフォーマンスなチーム

•常に改善し続ける

だから？

紹介した書籍（順不同）• “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