セッション:The Product Partnership: Using Structured Conversations to Deliver Value

スピーカー:Mary Gorman, Ellen Gottesdiener

Agile2012初日は、午前午後ともに3時間のセッションがひとつずつというワークショップ中心の一日です。
一発めのセッションとして「The Product Partnership: Using Structured Conversations to Deliver Value」に参加したので、レポートいたします。英訳が多いため、意味が分かりにくい部分は意訳しています。ご了承ください。

 

■Product Partnership

直訳すると「製品との友好的な協力関係」というこのセッションでは、デリバリの価値のために構造化された会話手法を利用する方法を、テーブルごとのワークショップを通して学ぶセッションでした。

スピーカーは、EBG Consultingの創設者であるEllen Gottesdiener氏と同社のVice PresidentであるMary Gorman氏です。お二人は『Discover to Deliver』という本を最近書いており、カンファレンスの書籍コーナーで先行販売されているようです。

セッションは、Concepts、Value、Structured Conversation、Allocate、まとめという構成になっており、スピーカーの二人が実際に会話を繰り広げながら、プロダクトのコンセプトや価値を探求していきます。

 

■コンセプト – 価値を発見し届けること

ここでは、Discover(発見)と Deliver(届けること)を繰り返すことの重要性が語られ、プロダクトの価値を決定していきます。

プロダクトの終わりの意味はなんでしょう?
その終わりとはビジョンであり、ビジョンには定量化できるObjective(目的)があり、ゴールにより発展させられる(amplified)ものであると言えます。このビジョンを基に開発されたプロダクトが提供されることが理想です。デリバリまでには、ユーザ、ビジネス、テクノロジーのパートナーシップが必須でしょう。


この活動の中で、バックログは重要な位置を占めています。
ストーリーは徐々に細分化され、探求、評価、確認、開発、デリバリによる気づきといったライフサイクルを繰り返しながら、プロダクトをデリバリする必要があるからです。

バックログがReady(準備OK)な状態とは、見積もることができ、テスト可能で、ドキュメント化(おそらく文字に書き起こせるという意味だと思う)できていることであり、その状態になって初めて作業に取り組むことができるようになります。


顧客(Customer)にとっての価値とは?ビジネスとしての価値は?テクノロジーとして必要な要素は何か?
それぞれの視点から価値を書きだしてみましょう。


価値を得るためには、コスト(時間、お金、機会損失)のリスクを考える必要があり、これらについても顧客、ビジネス、テクノロジーの3面で考える必要があります。それぞれの視点での価値が、意思決定の要因としての利益(Benefit)やリスクに影響を与え、それらの重み(Weight)が価値の意思決定を支えます。

どれか一つの視点で考えてしまいがちなので、この3つの視点を合わせて考えるという行為は、フレームワークのように活用できそうに思いました。

 

■Structured Converesation


ワークショップのほとんどは、7 Product Dimentions(プロダクトの7つの要素)に従いながら会話を行うことで、製品を明確に仕上げていきます。それぞれの要素を見ていきましょう。

1. User

ユーザは、プロダクトと相互作用する。

2. Interface

プロダクトは、システムやユーザ、デバイスと接触する(Interface)。

3. Action

プロダクトは、ユーザのために能力(Capability)を提供する。

4. Data

プロダクトは、データや便利な情報を含んでいる。

5. Control

プロダクトは、制約を強制する。

6. Environment

プロダクトは、物理的な属性や技術プラットフォームに従う。

7. Quality Attribute

プロダクトは、品質や運用、開発といった確かな属性を持っている。

まずは、UserからControlまでの会話を行います。
セッションでは一人がプロダクトチャンピオン、もう一人がエンジニアとして対話を行ないましたが、それぞれのコンテキストによって参加する人間は変わります。またこの会話は、新規開発のときだけではなく、イテレーションごとの計画ミーティングなどで行なってもよいでしょう。

この会話のときにスピーカーから注意があったのですが、決してコンテンツについて話しているわけではありません。プロダクトを中心として考え、会話することが大切だとおっしゃっていました。コンテンツメイキングしているわけではなく、コンセプトやバリューを考えているからだと思います。


7 Dementionsを使うと、受け入れテストも簡単に定義できるようになります。
それぞれの色の部分に、対話によってまとめた内容を書きだしていくだけです。

 

■Allocate


ここまでの会話をストーリーにまとめ、優先順位をつけていくことで計画を作ることができます。リリースごとのテーマを決め、さらにイテレーションごとのテーマも考えます。

 

■まとめとセッションの所感


このセッションを通して感じたのは、ストーリーを作るまでの過程がとても分かりやすく説明されており、実際に二人の会話を聞きながら、会話の中の疑問を見極め、質問を繰り返してその差分を埋めていく形を見ることができたのは、とてもよかったです。

よく「ストーリーの書き方が難しい」という質問を受けることがあり、教科書どおりの回答(INVESTだよーとか)をできても、実際の仕事に今ひとつフィットしない気がしていました。しかし、このセッションでの会話の実演によって、仕様を決めるときに質疑応答するやりとりを再確認でき、さらにそこからプロダクトの価値を中心に考える方法を知り、さまざまな気づきがありました。

お二人の本は出版されたばかりですが、プロダクトオーナーのような仕事をしている方にはとても役に立つと思います。

 

■PS…

夜、開催された恒例のパーティー「ICE BREAKER RECEPTION」で、Ellenと話すことができました。ちょうどインセプションデッキとストーリーの間のプラクティスだねと伝えると、とてもうれしそうに笑っていました。

日本ではストーリーという言葉はあるのに、その実例が乏しいように思っていたので、彼女たちのセッションはとてもしっくりきました。記事が公開されたらリンクを教えてくれと言われたので、この記事をシェアしようと思います。


一緒に参加した及部くんはサインをゲットしたみたいです。


Agile2012現地レポーター隊「アジャイルクローバーZ藤原 大及部 敬雄