昨年、Scrum Gathering Tokyo で来日した Jeff Patton さんのセッション。今回は特定の技法ではなく、文化とかプロセス全体の話。
the product owner is a stupid idea by Jeff Patton
2000年からアジャイルをやっている。 (中略) 私が参加した最初のXPチームはドリームチームで、素晴しいコーチ、素晴しいデベロッパーが参加していた。ソフトウェアプロダクトを作っていた。デベロッパーは顧客とユーザーと直接話していた。元々のテーマは、"How whole teams work together to create successful products ( "全部入り"のチームが成功する製品をつくる)" だ。Scrumにおけるプロダクトオーナー、XPにおける顧客プロキシ。
こういった一人のプロダクトオーナーシップモデルが機能しないということを話したい。
まず会場に集まった人々を属性でクラスタリング。200名くらいいるのに、どんどん動く。
アジェンダは以下の通り
- 1. Safety isn't success 安全＝成功ではない
- 2. Velocity isn't value ベロシティに価値はない
- 3. Balanced team not Client-Vender 発注者-受注者ではなく、バランスドチーム
- 4. Deliberate discovery drive delivery 入念な発見がデリバリーを駆動する
- 5. Life is better here (even though we're failing most of the time) よりよい人生 (ほとんどの時間は失敗しているにしても)
1. Safety isn't success 安全＝成功ではない
Royceが提唱したウォータフォール。しかし、Royce自身も工程間のフィードバックサイクルが必要だといっている。(訂正: Royceはウォーターフォールは提唱してなくて批判した人だそうです。原田さんご指摘感謝)
- 理解しやすい
- 計画しやすい
- 経過を把握しやすい
- 明確な役割分担
- 責任が明確
伝統的なシーケンシャルな工程は個人にとって安全だ。個人の役割は守られる。2011版のスクラムガイドでプロダクトオーナーは単一障害点だと言っている。これはよくないアイデアだと思う。そうであるなら、アジャイルはシンプルなウォーターフォールといっていい。
（この点は Cope と Jeff Patton で議論するところを見たい気がする！ ）
2. ベロシティに価値はない
現在のユーザーの痛み-解決のアイデア-機能-イテレーティブな開発-デリバリー-アウトカム(ユーザーがハッピーになる)-インパクト(世界がよりよい場所に)
妖精の靴下泥棒の話。靴下を盗んで集めている妖精を捕まえて話を聞く。これはビジネスだという。ビジネスモデルは .. 1.靴下を集める 2.なにかする 3.儲かる ...。実際は、この「2.なにかする」の部分の仮説が重要。
3. Balanced team not Client-Vender 発注者-受注者ではなく、バランスドチーム
発注者-受注者の関係だと、うまく行くことにどちらも責任を持てない。
元eBayのマーティ・ケーガンが定義したモデルは
- Valuable 価値がある
- Usable 使用可能
- Feasible 実現可能
のそれぞれの責任を持てる人々が共同作業をして、理想的なプロダクトを考えていく。これがバランスドチーム。一人の人間が全ての質問に答えられる訳ではない。技術的なこと、顧客のこと、分かる人たちが協力して働き、意思決定をしていく。co-create。
4. Deliberate discovery drive delivery 入念な発見がデリバリーを駆動する
しかし、異なる人たちが一緒に働くことは一種の読心術のような難しさがある。だから、見える化を使って共通理解を作っていく。プラグマティックペルソナを共同で作り、顧客からともに学ぶ。本物のユーザーに直接会う。ユーザーストーリーマップはプロダクトの全体像を示す共通理解。全員で作り上げていく。言葉と絵で共通理解をつくりあげていく。ペーパープロトタイプでイメージを共有する。ストーリーボードで実際に利用者が使うシーンを再現し、問題を発見する。プロダクトのストーリーを共有し、探索と発見を繰り返す。ペーパープロトタイプを使ってユーザーテストをすることもできる。
MVP1=minimal viable product 対象の市場で生き残れる最少のプロダクト。新しいバージョンのMVPはリーンスタートアップで定義された。MVP2 = minimal viable product [experiment] プロダクトのコンセプトを示すことができる最少の実験。
Build - Measure - Learn のサイクルの先に、Release - Measure - Earn がある。リリースし、計測し、利益を得る。計測は非常に重要なので、各リリースステップに対応する計測の方法を定義する。そして、それぞれ必ず「私たちは何を学んだか」を議論する。
5. Life is better here (even though we're failing most of the time) よりよい人生 (ほとんどの時間は失敗しているにしても)
マーティ・ケーガンは言う「だいたい50-80%のソフトウェアは当初考えていた成果を得ることができない」。スタンディッシュグループの調査結果は有名。このクリップなキャラクターに見覚えが...。
ここで紹介した３つの事例の企業はどんどんトライしている。
- 「誰もが直接顧客といっしょに働いている」
- 「本当の問題に取り組んでいる」
- 「毎年数百万ドルの売り上げを生み出すようなシンプルなアイデアを発見してきた」
- 「問題があれば、チームが飛びつき、スケジュールをとって、問題の解決をする。誰かが依頼するまでもなく」
- 「新しいサイトは機能もコード量も少ないが、同じ売り上げをもたらし、ユーザーに支持されている」
