Jeff Patton さんと平鍋さんが語る「ストーリー」についてまとめてみた

2012/10/17（水）に、楽天タワーで開催された『Jeff Patton と平鍋健児が語る、価値創出のプロセス「ユーザーストーリーマッピング」』に参加してきました。

参加動機

次の日から Jeff Patton さんの CSPO 研修「情熱プロダクトオーナー研修」を受講することから、ユーザーストーリーマッピングを予習したいと思ったこと。
- 事前に「１０分でざっくり理解するユーザーストーリーマッピング」などに目を通しておいたのですが、百聞は一見に如かずなので、直接お話を伺いたいなと思いました。
日本のアジャイルの大先輩の平鍋健児さんにまだご挨拶させていただいていなかったので、これを機にご挨拶させていただきたかったこと。

まずはじめに

Jeff さんおよび平鍋さんの写真を期待された方はごめんなさい。
私の撮影能力不足＆iPhone4S の解像度の都合で、ピンボケした写真しか撮れませんでした(´･ω･)　イベントにデジカメは必須ですね。。
あと、一番前の席に座ったら、本当に Jeff さんの目と鼻の先（わずか１メートル！）で、近すぎて写真に全然おさまりませんでした。場所も重要。

代わりと言っては何ですが、次の日に撮影させてもらった Jeff さんとのツーショットをば。

setUp()

　
１００人もの受付をこなす川口さんとぱぱんださん。
１５時までに集まってね！ということだったので、１４：５０頃に楽天タワーに到着すると、Ryuzee さんらアジャイル系コミュニティでお会いしたことのある方たちで溢れんばかり！改めて今回のイベントへの皆さんの関心の高さに驚かされました。

吉岡さんに案内されたエレベーターを抜けると、そこは楽天タワーのカフェテリアでした。
タリーズとかあるんや〜

会場はこんな感じ。会場を設定する楽天期待の若手及部さんの勇姿（残念ながらピンボケ）

「日本円使えるの？Edy じゃないとダメ？」などという会話をしていたら、Jeff さんが早速いらっしゃいました。
まず "Hello! Welcome back to Japan!" とご挨拶させていただいたら、
　あぁ君のこと覚えているよ！テキサスであったよね！
…人間、嬉しくなると言葉を失うものですね。本当に頭が真っ白になってしまい、暫くお話続けられませんでした。（ここが個人的改善点かなｗ）

そうこうしていると、平鍋さんもお見えになりました。早速「はじめまして！」とご挨拶させていただくと、
　（伊藤だと）一目でわかった！
…生きてるって素晴らしいですね。AgileConference 参加して記事書いてよかったですよ〜

今回のアジェンダ

ぱぱんださんによるつつがない司会進行、やっとむさんによる適宜翻訳＆補佐で開始。
最初の説明では

Jeff さんによるストーリー・ユーザーストーリー・ユーザーストーリーマッピングのレクチャー
Jeff さんと平鍋さんとの対談

となっていましたが、後半戦は各テーブル４人で１５分ほど議論して、そこで気付いた点を質問し、Jeff さん＆平鍋さんに回答していただくという形になりました。より参加型イベントにしようという運営スタッフの皆さんの心配りのようです。

Jeff さんによるストーリー・ユーザーストーリー・ユーザーストーリーマッピングのレクチャー

◆１．「ストーリー」という考え方の起源

「ストーリー」という考え方は、Kent Beck が２０００年にサンフランシスコで始めた XP に起源を求めることができます。
当時 Kent が悩んでいたことは、「要求」(Requirement）が大きすぎたり曖昧だったりすることで、ソフトウェア開発がスムーズにいかないということ。また、ユーザが提示してくる要求や仕様通りにソフトウェアを作ると、大概ユーザの本当の要望を満たせないということ。
※ちなみに、要求を文書で書いても伝わらないことの分かり易い例として、Jeff さんは「Cake Wrecks」というサイトを紹介されていました。確かにこれは…ｗ

こうした「要求」に端を発する問題を解決する方法として Kent は、やるべきことをカードに書き出して、カードをもとにコミュニケーションを活発にすることを考えました。これが「ストーリー」の起源です。

ちなみに色々と誤解されていますが、Kent の意図は、ソフトウェア開発でストーリーを厳密に・必ず書け！ということではなく、関係者とのコミュニケーションを増やすためにカード＆ストーリーを活用しよう！ということなのだそうです。

◆２．カード＆ストーリーの使い方

Jeff さんによると、カード＆ストーリーの使い方は次の通りだそうです。

書く
話す・議論する
- 最初に書いたものを正しいとするのではなく、ここで議論して書き直していく形になります。
やることについての認識を共有する（理解の共有、shared understanding）

要は、一度書いたものに縛られずに議論を繰り返し、何度も直しながら、最終的に関係者間で認識の共有を果たせればＯＫということです。
未だにアジャイルはドキュメントを書かないことだと誤解されていますが、ドキュメントを書いて終わりにするのではなく、コミュニケーションをより重視するためにカード＆ストーリーを必要に応じて活用するというのがアジャイルの実態です。

これを XP での開発サイクル全体にあてはめると、次の図のようになります。

ちなみにこの図は、Ron Jeffries の 3C が元だそうです。
http://xprogramming.com/articles/expcardconversationconfirmation/

また、Alister Cockburn によると、ストーリーは次のように設定すると良いとのことです。

最初に１つめのストーリーを書く
２つめのストーリーは、「１つめのストーリーをリファインする」とする
３つめのストーリーは、「２つめのストーリーをリファインする」とする

要は一度書いて終わりではなく、何度も何度も検証・修正して改善し続けようということです。

◆３．役割や階層による価値観の違いとストーリーの粒度

ストーリーを書きだすものを「カード」と表現しているのは、図書館の図書カードのメタファ・イメージを伝えたいからだそうです。図書カードは、それぞれ本の名前や著者、本のありかなどといった価値を提供できます。一方で、そのカードの価値は読者毎に異なります。
このことは、ソフトウェア開発におけるコミュニケーションの際の、役割や階層毎の価値観の違いに置き換えて考えることができます。

ソフトウェア開発を成功させるためには、役割や階層を超えてコミュニケーションを行う必要があります。
以前は、役割や階層毎に別々に仕事をしていたため、それぞれでストーリーを作れば十分でした。しかし、アジャイルで関係を密に協働する必要性から、チームメンバーとしてお互いにストーリーを共有する必要が出てきました。

とはいうものの…役割や階層毎に価値観が異なるため、各々のストーリーの粒度が合わないという別の課題が出てきます（良く「コンテキストの違い」と表現されます）。
【ストーリーの粒度が合わない例】

ROI を最大化する（ビジネスリーダー）
機能を拡張しやすいシステム構成とする（開発者）
バグ曲線を早期に収束させる（QA 担当者）

また、人・役割・階層が増えてくると、当初 Kent が想定したレベルでのコミュニケーションでは状況をコントロール・改善できなくなってきてしまいます。

要は、役割や階層毎に価値観が異なるためにコミュニケーションは必要だけれども、各々ストーリーの粒度が異なってくるため、単にストーリーを作ってシェアするだけでは不足ということです。*1

そこで役に立つのが、「collaborative workshop」と「ユーザーストーリーマッピング」です。

◆４．collaborative workshop

「collaborative workshop」とは、コンテキストの異なる人たちが、付箋紙を使って迅速に「理解の共有」（shared understanding）を実現するための手法です。
「collaborative workshop」の具体的な実施方法は、次の通りです。

まず一人一人、周りの人とは相談せずに、自分のアイデアを付箋紙に書き出す。
各人が書き出した付箋紙を模造紙などに張り出し、お互いのアイデアを見せ合う。
付箋紙の内容に類似するものがあれば、それらを１つにまとめる。
ある程度類似するアイデアのまとまり毎に、それを意味する上位概念を表す付箋紙を作成して貼る。
付箋紙のまとまりがおかしいと思ったら、都度付箋紙を移動したり張り替えたりする。
アイデアに齟齬がある箇所や詳細化が必要な箇所などが見つかったら、そこで話し合いを実施する。（但し短時間で）

※１〜５までは、いずれも黙って実施することがポイントです。

ね、簡単でしょう？

ですがこの「collaborative workshop」、説明するとやることは簡単ですが、実現できる価値は非常に多いのです。

黙って実施することで、アイデアを早く出してシェアすることができる。
黙って付箋紙を集めたり移動したりすることで、お互いの考えや思考過程の一致・相違を迅速に「体感」することができる。
- 結果的に、お互いの立ち位置が分からずに議論が紛糾する「空中戦」を避けることができます。
ゲームライクなので、楽しく前向きに実施できる。
メンバーが、お互いを理解することについて協力的になる。

やり方は非常にシンプルなのですが、これまでのミーティング中心のやり取りでは決まりにくかったことが迅速かつ恊働的に決められるようになる、とてもパワフルな手法です。

◆５．ユーザーストーリーマッピング

「ユーザーストーリーマッピング」とは、コンテキストの異なる人たちのストーリーを、

同様の粒度で
時系列かつ
価値のある順番に

整理しまとめ共有するための手法です。
※ちなみに写真のものは、後日 POStudy Conference で作成した一品です。

「ユーザーストーリーマッピング」の具体的な実施方法は、次の通りです。*2

先の「collaborative workshop」の要領で、お互いのストーリーを模造紙などに張り出し整理する。
横軸に、当該のサービスを提供するためのストーリーを時系列に整理する。
- 左から右へ、実施順にまとめます。
縦軸に、ストーリーを抽象→具体の順に整理する。
- 抽象度の高いものを上に、低いものを下におきます。
- ２層または３層で表します。（epic-feature-story の順序で）
横軸・縦軸ともに整理できたら、（具体の方の）ストーリーを、スプリント・イテレーション毎に整理し直す。
1. リリースするスプリント・イテレーション毎に、横向きのレーンを用意します。
2. レーン毎に、ストーリーを配置し直します。
3. 各レーンが、各スプリント・イテレーションでリリースする機能のまとまりになるように整理します。
  - レーンは、ユーザに価値のある順番に上から並べます。
  - レーン毎のストーリー数は、実行可能な velocity の範囲内におさめます。
  - レーン毎のストーリーは、「MVP」（Minimal Viable Product、トータルで必要十分な最小限のプロダクト）となるようにまとめます。

Jeff さんは、上述の一連の流れを、スタートレックのワープのメタファーで説明されていました。

物理構成を一旦分子レベルクラスで分解し、遠方へ転送し、転送先で再構成するという形でワープを実現します。*3
転送先の再構成時、ただ物理構成を適当にまとめておけば良いのではなく、人の形でまとめる必要があります。
- プロダクト・サービスの場合、再構成は MVP である必要がある、という話につながります。

この「ユーザーストーリーマッピング」の価値をまとめると、以下のようになります。

プロダクト・サービスを構築・提供するための各役割・階層毎のストーリーを、全体的な視点から俯瞰することができる。
- 多様な人の多様な価値を、一つにまとめて見ることができることがポイントです。
マッピングすることで、ストーリーを時系列にかつ詳細化することができる。
簡単に実施することができる。
- フォーマット自体はさほど重要ではなく、複雑なことを迅速かつ簡潔に話せることに価値があります。
マッピングを繰り返すことで、学習を繰り返すことができ、新たなゴールを再設定することができる（後述）。

◆６．ユーザーストーリーマッピングの繰り返しによるプロダクトの改善

Jeff さん曰く、ソフトウェア開発で一番難しいことは、作るべきものを正しく決めることだそうです。
このことは、最初に決めた仕様通りにシステムを作るとユーザの価値を実現できないという、日々我々が感じるジレンマそのものです。また、Kent が「ストーリー」を考えたきっかけでもありました。

そもそも、作るべきプロダクト・サービスが最初から決められることって、一体どの程度あるのでしょうか？

よく Waterfall のプロジェクトでは、失敗を「正しい要求を抽出できなかった」・「悪い要求を実現してしまった」ことと解釈します。しかし、この解釈は本当に正しいのでしょうか？
Kent は、「要求」（requirement）という言葉こそが、ソフトウェア開発で最も悪い言葉だと明言しています。なぜならば、ユーザの言った事の時点で思考停止圧力がかかってしまい、システム・プロダクト・サービスの改善が行えなくなってしまうためです。

この反省から、アジャイルでは失敗を「学び」と考えます。

この失敗を学習と解釈する考え方は、Eric Ries の『The Lean Startup』にも見ることができます。

ユーザーストーリーマッピングは、まさにこのモデルを実現する手法だと言うことができます。
そもそも、最初にユーザーストーリーマッピングを作る時点で、作るべき価値が全て見えていることはあまりありません。しかし、

ユーザーストーリーマッピングを作り、
レーンで区切り、
ストーリーの機能を実際に構築（Build）し、
スプリント・イテレーション毎に計測（Measure）を行い、
プロダクト・サービスの価値を学習・再確認（Learn）し、
ユーザーストーリーマッピングを更新し…

というサイクルをまわせば、プロダクト・サービスから学び、プロダクト・サービスを継続的に成長させていくことができます。
これこそが、アジャイル・XP のコンテキストにおける、ストーリーとユーザーストーリーマッピングの価値です。

Jeff さんが紹介されていた globo の事例では、何度も何度もユーザーストーリーマッピングを書き直していました。
何度も何度も付箋を書き直しているという意味では、トータルの文量は Waterfall とさして変わらないかも知れません。
しかし、付箋の書き直しを繰り返すことで会話が起き、プロダクト・サービスの価値の再確認・改善が行われているという意味では、Waterfall よりもはるかに高い価値を提供し得ることは一目瞭然でしょう。

◆７．「ストーリー」と「ユーザーストーリー」との違いと注意点

私も今回のイベントに参加するまでは、「ストーリー」と「ユーザーストーリー」とを混同していました。しかし、Jeff さん曰く、両者には明確な違いがあるそうです。それはフォーマット。「as a... what... why...」といったフォーマットに準拠するものが「ユーザーストーリー」だそうです。

しかし Jeff さんは、こんなこともおっしゃっていました。「ユーザーストーリー」のフォーマットに準拠すべしという考え方は、Kent の作り上げた「ストーリー」の考え方とはズレていると。
元々 Kent が言いたかったことは、フォーマットに従うことではなく、ステークホルダーとの会話をドライブする起点として「ストーリー」を使うべしということです。アジャイルの根底にある考え方は、何かのルールに厳密に従うことではなく、価値を継続的に学習していくことです。そのことを、Jeff さんのお話を伺って再確認できました。

議論＆質問タイム

周りに座っていた４〜５人でグループを作り、Jeff さんのレクチャーを受けて各自が考えたことを１５分間議論しました。
で、私たちのグループで出た疑問がこれです。

ユーザーストーリーマッピングと PBL は同じ？違う？
ユーザーストーリーマッピングと PBL が異なるものの場合、ユーザーストーリーマッピングと PBL・SBL はいつ同期を取るのか？

早速 Jeff さん＆平鍋さんにこれを質問してみたところ、

スクラムは嫌いですw（Jeff さん）
ユーザーストーリーマッピングと PBL とは分けた方が良いとは思うが、プロダクトや人によってやり方は一つではないから、自分たちに合うやり方を見つけよう。
- One size does not fit all (by A.Cockburn)

また他のチームから、手書きとツールのどちらを使うのが良いのかという質問が出ていました。
これについては、併用できればしても良いけれども、簡潔さと会話のしやすさを考えたら手書きの方が良いのでは？ということでした。

最後に

このような貴重な場を提供して下さった Jeff Patton さんと平鍋さん、つつがない進行をしていただいたスタッフの皆さん、議論させていただいた皆さん、また会場を提供して下さった楽天さん、本当にありがとうございました。

参考資料

今回のレポートにあたって、下記の資料・イベントを多いに参考にさせていただきました。ありがとうございました。

*1:それもあるので、最初のうちはカードは簡単に書いた方が良いそうです。

*2:Jeff さんは、このようなカードでプロダクト・サービスのモデルを構築する一連の作業を、「カードモデリング」と表現されていました。

*3:『ザ・フライ』という映画も、同様のコンセプトでした。

The HIRO Says

If you smell what The HIRO is cooking!!!