2012/10/17に開催された『Jeff Pattonと平鍋健児が語る、価値創出のプロセス「ユーザーストーリーマッピング」』のノートです。
◆開催概要
◇登壇者
・Jeff Patton氏
・平鍋健児氏
◇会場提供
・楽天
◇共催
・アギレルゴコンサルティング
◇提供
・永和システムマネジメント
◇本日のアジェンダ
・Jeff Patton Lecture(50min)
・Conversation! Jeff & Kenji(60min)
◆はじめに
◇Jeff Patton氏
・デザインとソフトウェアにはただ1つ正しい道は存在しないと思っていて、活動している。
→20年以上にわたって活動
・ユーザーストーリーマッピングの考案者
→2001年から12年以上やっている
◇平鍋健児氏
・20年以上オブジェクト指向ソフトウェア開発の経験
・10年以上アジャイルソフトウェア開発の経験
・チェンジビジョンでastahを開発して提供
・「Jeffとは長い付き合い。今日は楽しみにしている」
◇Jeff Patton氏の経歴と今日の話について
・アジャイル界ではアジャイルユーザエクスペリエンスの人だと認識されている
・80年代、美術学校に通っていたことがあった
→ソフトウェア開発業界にいったらユーザインタフェースのデザインの仕事を任された
・ストーリーマッピングの実践について話をしている
→12年前(2001年)から
・ソフトウェアを理解するための有意なやり方 = ストーリー
・ストーリーマップの話をする為には、まずユーザストーリーを理解してもらう必要がある
◆ユーザーストーリーの話
◇導入
・2000年、サンフランシスコでKent Beckとプロジェクト
→xpを教えてもらった
・xpでは伝統的な要求は使わない
→ストーリーを使う
・Kentは伝統的なソフトウェア開発の大きな問題に対してストーリーを使おうとした
→うまく書かれていない仕様はソフトウェア開発を阻害する
→→ストーリーは効果的にコミュニケーションするためのもの
◇ケーキの話
・cakeWrecksというウェブサイト
→ケーキに書かれた文字を写真にしたもの
・間違った指示がどれだけ面白いケーキを作るか、というサイト
・ケーキに書いてある文字の例
→best wishes suzanne / under neat that / we will miss you
（underneath = 下線を引いてという指示）
→Congraturations / Three Times
（3回繰り返して）
→I want Sprinkles
（カラフルなトッピングをかけて）
→Nuts Allergy / Happy Birthday Peter
（ナッツアレルギーです）
→Leave Blank
（何も書かないで）
・ケーキの間違いは面白い
◇面白いではすまないものもある
・Mars Climate Orbiterという火星探査機
→火星の軌道にのらずに爆発
・ポンドとメートルの単位換算をしなかったという失敗
→コミュニケーションミスが原因で起こった
◇このような問題についてKent Beckは考えた
・解決策はシンプル
→「さあ、ドキュメントを書くことはやめて、話すことから始めよう」
◇ストーリーのアイデアはシンプル
・欲しいソフトウェアのことを何かカードに書く
→何を書いてもよい
・それを見て話しあう(conversation)
→どんなソフトウェアが必要か正確に決められる
・"We should get together and I want to hear your story"
・ストーリーをカードに書く
→互いに言い合うため
・書くのではなく語ろう
・アイデアはシンプル
→だからといって簡単なわけではない
◇ストーリーのフローはシンプル
・カードには何が書いてあってもいい
1. 会話する
2. 何か気がついたら書く
3. それを説明する
4. 聞いた人は相手が欲しいものをイメージする
5. そして質問する
→会話は質問すること
6. ユーザーとデベロッパーは理解を共有する
・"何を作るか？"を共有するということ
→開発者が独自に想像してものを作るのとは全く異なる
・共通の理解を通じて、何が欲しいのかの理解に達する
→ユーザー「何を作るかについて詳細に話すことはできない。でも何が欲しいのかはある」
→デベロッパー「何が欲しいかは分からない。でも作り方を詳細に話すことはできる」
◇ストーリーのシンプルなアイデア
・動かないものを書いたり描いたりすることはしない
→Conversationする
・アジャイルプロセスでは少ないドキュメントで行う
→Conversationして少しの絵や単語を書く
→→そうして「何を作るのか？」という理解を促進する
◇プロセスの始まり
1. カードによるConversation
2. Confirmation
3. そしてカードを書く
→作るものの詳細について沢山ディスカッションする
・Ron Jeffriesの3C
→『XPエクストリーム・プログラミング導入編』に書いてある
→→Card
→→Conversation
→→Confirmation
◇開発の流れはこんな感じ
1. ソフトを作り始める
2. 話しあった2人以外も見る
3. それを見てもっと話し合いこと・疑問や答えがでてくる
4. 完全じゃないことや変えたいことが出てくる
5. それをカードに書く
◇アリスター・コーバーンが言っていたこと
・「ストーリーは3枚書け」
1枚目 : 必要なもの
2枚目 : 1枚目をFIX（直す）するもの
3枚目 : もう一回FIXするためのもの
→3回書かないとストーリーにはならないということ
◇今までのソフトウェア開発とアジャイルなソフトウェア開発の違い
1. ソフトウェアを作る
2. 後から変更の必要がわかる
→今まで：悪い要求で失敗とされる
→アジャイル：学びとされる
◇Kent Beckが書いたこと
・「ソフトウェア開発にもっとも大きなダメージを与える最悪の単語は"requirement"である」
・だから話をして学び、作るべきソフトウェアについて書く、というサイクルを行う
→問題に対するパーソナル(?)な解決策である
◇ストーリーの壁
・Conversationは2人で話しをするもの
→「私が必要なもの」
→「私が作れるもの」
・でも周りにはたくさんのステークホルダーがいる
→それぞれの観点から話しをする
→→「リターンはどのくらい？」
→→「ビジネスの何を改善する？」
→→「進捗はどうなっている？」
・実際にはたくさんのステークホルダーがいる
◇カードの最初のアイデア
・「カードは会話のきっかけ」
→詳しく書くのではなく、会話を発生させるもの
→話して出てきた詳細はカードの裏に書く
→→でもステークホルダーがたくさんいると裏側ではすまない
◇カードは「何について話すか？」のためのもの
・図書館にある"カード目録"を考える
→本自体は別のところにある
・カードは会話を引き出すためのもの
・沢山の人との会話の結果はカードに書けない
→wiki, sharepointでもオンラインのドキュメンテーションに書く
→→少し複雑。当初のものよりちょっと悪くなってしまった
◇ストーリーの大きさ
・「大きさ」はいつでも大切
・ユーザーは気に入ったものを書く
→ユーザーに大きさは関係ない
→開発者は正確な大きさを知りたがる
→→イテレーションに収まるよう細かくする
・ビジネスリーダーは、ビジネスの効果が分かるものを好む
→ロードアップにフィットするサイズになる
・ストーリーは1つのサイズで書けるものではない
→それぞれのステークホルダーにナチュラルなサイズがある
→それぞれに必要なサイズが違うということ
◇みんなストーリーが嫌い
・開発者なら開発できる、QAならテストなど、それぞれ自分の欲しがる形がある
→専門家にはそれぞれのやり方があるということ
→それぞれ必要なサイズが違う
・ストーリーの登場によって皆が同じ話しができるようになった
→ストーリーは、誰から見ても『自分が欲しいものとはちょっと異なる』ということ
→→皆に対して不完全になっている
◇ストーリーの大きさと価値
・ストーリーはそれぞれ価値がないといけない
→でも1つ1つは出荷可能ではないし完全でもない
・集まって1つになって、デリバリ可能となる
・ユーザーストーリーはより小さいストーリーに分割される
→全体になってはじめて1つの価値があるということ
・より上位の視点からユーザストーリーを見る手法が必要だということ
◇ストーリーと開発サイクル
1. 最初は大きな機能の話
2. 沢山の会話をして小さいパーツとしてのストーリに分解する
→ユーザストーリをパイプライン(sprint)を通れるくらいにシュリンクさせる
3. 優先順位をつける「これは最初のリリース」「これは次」
→ここでUIや受け入れテストなどの細かい話がでてくる
4. ここから開発者が出てきて「まだ大きい。イテレーションに入らない」
→もっと細かくする
5. 小さいストーリーが完了する
→価値のあるパーツ（ユーザに見せて正しさを検証できるくらいのもの）ができる
→→でも、チェックボックスが付いた、なんてものをユーザは見たくない
6. ユーザの目からみて価値のある大きさにまとめてから、見てもらう
→それを一つ一つ検証(validate)
7. 最後の大きな1つのソフトウェアになる
◇ストーリー = 岩みたいなもの
・割ると沢山の岩になる
→でも頻繁には砕かない
◇ゲーム : アステロイド
・ルール
0. 宇宙を岩が飛んでいる
1. 岩を打つと砕けてあちこちに飛んでいく
2. 砕けた岩を打つと、それもくだけて飛んでいく
3. 何回か細かくすると石は消滅する
4. そうやって全ての石（岩）を消滅させればおｋ
5. 岩にぶつかるとゲームオーバー
・このゲームでは、大きい石を何回も打つのは悪いやり方
→小さい石がたくさんでてきてすぐゲームオーバー
→大きなストーリを早いうちに細かくくだくのも同じ
◇ストーリーは素晴らしい発明
・Conversationで共通の理解をするためのもの
・書類は間違いがち
◇ソフトウェア開発でもっとも難しいもの
・「そもそも何が作りたいのか」ということを理解すること
→フレデリック・ブルックス（人月の神話の人）が言っていた
・コミュニケーションは難しいがそれ以上
・「何を作るか」と言うことは「人が欲しいもの」「作るものが何なのか」を理解すること
→それが一番難しいこと
◆ユーザーストーリーマッピングの話
◇ユーザーストーリーマップとは何か
左右：Workflow ワークフロー
上下：Details 詳細やオプションとなるストーリー
・構造上の特徴は2つ
1. 左右はユーザの視点からみた物語
2. 上下はバリエーションやオプション
・一番上が一番大きな岩
→話の背骨になっている
→細かいものはその石に紐付けられて下にいる
・上（ユーザのアクティビティ）
→タスク（背骨）をいくつかまとめたもの
・書いて動かしているうちに会話が生まれる
→それが重要
・マップができるということは会話ができたということ
→マップは会話の足跡
・マップにシールでタグ付けすることもできる
→リスクに対する評価や、やる/やらないなど
◇ユーザーがストーリーマップから見るもの
・「この機能は2日」とかそんなものは見ない
・ユーザーはもっと大きなストーリーの流れを見る
→使っている様子が分かるように書く
→→そこから会話が生まれ、Detailsに新たなカードが加わっていく
◇ストーリマップはシンプルさを保っている
・ストーリマップはとてもシンプル
→そこに何を書いてもいい
・「UMLにして他の情報かけるようにしろ」という人もいる
→そうはしない。そうしてシンプルさを保っている
◇ストーリーのスライス
・基準となる線を用意し、ストーリーを上下にスライスする
→スライスにカードを割り当てその中でカードを動かし、各スライスのゴールを決める
1. 機能単位で分割線を引き（スライスの作成）、ストーリーを各スライスに割り当てていく
2. 重要な機能のスライスからこなす
（3. スライスが完了すれば、ユーザに価値のある大きさで提供ができる）
青い線がスライス
◇ユーザーストーリーマッピングとは何か？
・ストーリーはバラバラになるので、以下の難しいことをやる必要が生じる
→全体を考える
→小さいものを組み合わせて1つにする
→→これは難しい
・これも難しい
→全体としてどういう機能があるか
→細かいアイテムってどういう価値があるものなの？
→→バックログアイテムを細かく見ていくときにここで苦労する
・解決策としてストーリマッピングを提唱している
◇世界中から写真を送ってもらっている
・いろいろな世界から「クールだろ」と写真が送られてくる
・本どおりではなく、それぞれにあったやり方でやっている
◇平鍋さんの気付き
・ケントベックが提唱していたストーリーとは
→話すこと
→「As a xxx In order to...」というフォーマットのことではない（それが悪いわけではない）
・アジャイルに見せるときに、ビジュアルが持っている強さ
Jeff Patton様, 平鍋健児様, 永和システムマネジメント様, ・アギレルゴコンサルティング様, 楽天様、ありがとうございました。
