User Story Mapping in CEDEC23

Slide 1

Slide 1 text

ユーザーストーリーマッピングアジャイルなプロダクト開発

Slide 2

Slide 2 text

川口恭伸かわぐちやすのぶ Twitter: @kawaguti YesNoBut株式会社代表取締役社長アギレルゴコンサルティング株式会社シニアアジャイルコーチ株式会社ホロラボシニアアジャイルコーチ一般社団法人スクラムギャザリング東京実行委員会代表理事一般社団法人 DevOpsDays Tokyo 代表理事

Slide 3

Slide 3 text

価格：2,600円＋税刊行日：2023年7月20日

Slide 4

Slide 4 text

スクラムフェス仙台 8/25-26 スクラムフェス三河＋栃木 9/15-16

Slide 5

Slide 5 text

James Coplien 3年ぶりの来日研修認定スクラムマスター 10/5-6 個人的イチ押し! 認定スクラムプロダクトオーナー 10/2-3 Kiroも来るぅ！ CEDEC23 : 10%OFFコード 9/8までにお申し込みの方

Slide 6

Slide 6 text

ユーザーストーリーマッピング

Slide 7

Slide 7 text

ジェフ・パットン Jeff Patton ユーザーストーリーマッピング

Slide 8

Slide 8 text

Jeff との出会いは2009年のAgile Conference です。Agile UXのトラックを見に行くので、勉強会やりました。樽本徹也さんから「たぶんキーパーソンはJeff Patton」という話をいただいて、彼のセッションを聞きに行ったのがきっかけです。

Slide 9

Slide 9 text

しかし、ユーザーストーリーマッピングのセッションはプロポーザルで落選。「プラグマティックペルソナ」のセッションをやってました。しかし、OpenJamで、ゲリラ的にユーザーストーリーマッピングのセッションが行われました。

Slide 10

Slide 10 text

故David Hussman氏との共同セッションでした。英語が拙い私は、それをビデオに収めさせてもらい、 Youtubeで公開しました。それが、ユーザーストーリーマッピングの普及にも寄与したようです。両氏との交流はそこから始まりました。

Slide 11

Slide 11 text

https://youtu.be/iwJcvygxpKM Agile2009 Open Jam

Slide 12

Slide 12 text

3年後に、ついに Jeff が CSPOトレーニングを開始し、日本でも開催してくれることになりました。しかし膨大な資料の翻訳と、通訳が必要であったり、手間が多いので、困難が多かったのも事実です。コロナ後は残念ながら実現していませんが、そろそろ来日したいそうです！

Slide 13

Slide 13 text

アラン・クーパーからの序文

Slide 14

Slide 14 text

ソフトウェア設計者、プログラマであり、「Visual Basicの父」として広く認知されている。また、著書『About Face 3』、『コンピュータは難しすぎて使えない』でも知られている。インタラクションデザインコンサルティングのリーディングカンパニーであるクーパー社を創業して目的主導型設計手法を生み出し、ハイテク製品を生み出すための実用的なインタラクションデザインツールとして「ペルソナ」の活用を先駆的に提唱した。

Slide 15

Slide 15 text

ソフトウェアのふるまいの設計手法とソフトウェアの構築手法は、密接に関連し合ってはいるが、まったく別のことであり、一般には、異なるスキルセットを持つ異なる人物によって行われる。インタラクションデザイナーのように何時間もかけてユーザーを観察し、ふるまいのパターンをマッピングしていたら、ほとんどのプログラマーは頭が変になってしまうだろう。逆に、アルゴリズムのために何時間も智慧を振り絞っていたら、ほとんどのデザイナーは孤独に耐えられなくなる。アラン・クーパーによる序文

Slide 16

Slide 16 text

しかし、デザインと開発という2種類の実践者たちが協力し合えば、仕事が電気（怪物のエネルギー源）となり、呼吸をする生きた製品が生まれる可能性が出てくる。チームワークが怪物に生命を吹き込み、人々に愛されるものに変えるのだ。アラン・クーパーによる序文

Slide 17

Slide 17 text

この2つの分野の実践者たちは、一般にとても有能で、スキルがあり、信頼できるが、ある共通した弱点を持っている。プログラミングの言葉ではデザインの意向をうまく表現できず、デザインの言葉では開発の趣旨をうまく表現できないのだ。つまり、2つの分野には共通の言葉が欠けている。そして、ジェフ・パットンの立ち位置が、まさにこの2 つの分野の重なり合う場所なのだ。アラン・クーパーによる序文

Slide 18

Slide 18 text

ジェフ・パットン Jeff Patton 両者の協調ワークショップを通じて共通理解を作る。

Slide 19

Slide 19 text

19 前書き

Slide 20

Slide 20 text

20 前書き

Slide 21

Slide 21 text

21 前書き

Slide 22

Slide 22 text

22 “どのようなソフトウェアを作るかについての議論に何度も参加して、その議論を説明するためのドキュメントを書いた場合、そこにいたほかの誰かと理解を共有することができるかもしれない。2人ともそれでいいと思うということだ。しかし、あなたたちの共通理解は、ドキュメントに含まれていない細部をたくさん含んでいる。議論の場にいなかったほかの読み手は、あなたたちと同じだけの理解に達することができない。彼女がわかったと言ったとしても信じてはいけない。私がバケーションの写真を使って自分のストーリーを話したのと同じように、場を共有して、ドキュメントを使ってストーリーを伝えるのだ。” 前書き

Slide 23

Slide 23 text

23 “ポストイットやインデックスカードを使いながら、話したり、スケッチを作成したり、書き出したりする必要がある。会話の場に持ち込んで、それを指差しながら話したり、蛍光ペンでマークしたり、注釈を書き込んだりする。インタラクティブでエネルギーにあふれたものだ。もし、全員が会議室テーブルを囲んで座り、担当者ひとりが全員の発言をストーリー管理システムに入力しているようなら、おそらくやり方を間違えている。” 前書き

Slide 24

Slide 24 text

付箋を駆使して、みんなで一緒に地図を描き、共通理解を作る。これこそが神髄 …だと思います。

Slide 25

Slide 25 text

共通理解になった地図の力を利用する

Slide 26

Slide 26 text

いったんユーザーの頭の中に入った地図の力を活用して、ユーザーの想像力を掻き立て、また、裏をかいて驚きを与える。

Slide 27

Slide 27 text

ユーザーストーリーマッピング

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

1. ストーリーを使う目的は、もっといいストーリーを書くことではない。 2. 製品開発の目標は、製品を作ることではない。 “実際、この本を読んでたった2つのことが読者のなかに残りさえすれば、私は満足だ。そして、その2つはこの章のここに書いてある。” 第0章まず最初に読んでください

Slide 41

Slide 41 text

1. ストーリーを使う目的は、もっといいストーリーを書くことではない。

Slide 42

Slide 42 text

42 Rachel Davies Connextra Format 第7章よりよいストーリーテリングのために

Slide 43

Slide 43 text

43 “1990年代の終わり頃、彼女はConnextraという会社で働いていた。Connextraは、ストーリーを生んだアジャイルプロセスであるエクストリームプログラミングをいち早く導入した会社の1つである。Connextraの人々は、ストーリーを使い始めてすぐ、ある共通する問題にぶつかった。 Connextraでストーリーを書いたのは、ほとんどが営業や販売促進の人々だった。彼らは、自分にとって必要な機能を書き出す傾向があった。しかし、開発者たちが会話をするときには、本来のステークホルダーを見つけ出し、「誰」と「なぜ」を含んだ、いい会話をはじめなければならない。機能の名前だけが書いてあっても、チームが話をすべき適切な人々を見つけ出し、適切な議論を始めるためには役に立たない。” 第7章よりよいストーリーテリングのために

Slide 44

Slide 44 text

Slide 45

Slide 45 text

“あなたがアジャイル開発プロセスを使っているなら、バックログにユーザーストーリーが含まれているだろう。ストーリーはそれだけ広く使われているのだから、この本でストーリーについて書いても時間の無駄なのではないか。しかし、それは間違っている。Kent Beckが初めてストーリーについて書いてから15年の間に、ストーリーは人気を集めるようになったが以前よりも誤解され、濫用されるようにもなった。” 、前書き

Slide 46

Slide 46 text

動作するプロダクト (の増分) 上から順に生み出していく価値があるかどうかがわかるプロダクトバックログ

Slide 47

Slide 47 text

• 全体像を見失いやすい • いつになったら完成するのか、そもそも何が作られているのかわからなくなってしまう • ストーリーを使っている人々が何も書き出さなくなる。 • チームが予定された期限内に予定した仕事を終わらせることができない。 • うちの製品にはユーザーがいないので、ユーザーストーリーは役に立たないと言い出す前書きより抜粋プロダクトバックログ

Slide 48

Slide 48 text

Slide 49

Slide 49 text

2. 製品開発の目標は、製品を作ることではない。

Slide 50

Slide 50 text

Slide 51

Slide 51 text

“私たちとしては、不満があって怒り、当惑していた人々が、ソフトウェアが出荷されることによって幸せになるようにしたい。しかし、彼らはソフトウェアが入った箱を見ても幸せにはならない（最近はソフトウェアが箱に入ってくることはあまりないが）。彼らはリリースノートを読んでも、モバイルデバイスにアプリをダウンロードしても、幸せにはならない。彼らはソフトウェア、ウェブサイト、モバイルアプリ、その他あなたが作ったものを使うことで、今までとは違う、幸せなやり方ができるから、幸せになるのだ。” 前書き

Slide 52

Slide 52 text

“その機能について会話するときには、それが誰のためのものなのか、その人たちは(その機能がない)現状ではどうやっているのか、 (その機能を提供したら)今後はその人たちを取り巻く物事がどう変わっていくのか、そういったことを話題にする。そうした将来のポジティブな変化があるからこそ、それを欲しいと思うようになるのだ。” 前書き

Slide 53

Slide 53 text

プロセス全体の流れ

Slide 54

Slide 54 text

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

ふりかえりの例で考える

Slide 69

Slide 69 text

No content

Slide 70

Slide 70 text

No content

Slide 71

Slide 71 text

No content

Slide 72

Slide 72 text

No content

Slide 73

Slide 73 text

アジャイルコーチの適用戦略として俯瞰

Slide 74

Slide 74 text

アジャイルコーチの適用戦略として俯瞰

Slide 75

Slide 75 text

アジャイルコーチの適用戦略として俯瞰

Slide 76

Slide 76 text

プロダクトバックログと開発者(たち)

Slide 77

Slide 77 text

資料を作る人会議する人ものを作る人

Slide 78

Slide 78 text

エクストリームプログラミングの原動力のひとつは、ビジネスとテクノロジーの間の溝を癒すことでした。私は、一般的に言われている2つのグループが激しく対立し、協力する方法を見つけても必要なものが得られないという状況を目の当たりにしてきました。つまり、自分には納期を決定する力があると思っている人が、その力の幻想を手放そうとしなかったのです。そこにエクストリーム・プログラミングが登場し、一連の人間関係とそれを支える儀式、そしてそれらの儀式や人間関係を支える技術的な慣習を提示しました。そして、その代償として、締め切りを指示することができなくなりました。 (Kent Beck 2021年７月のAgile 2021でのトークより) https://ja.wikipedia.org/wiki/ ケント・ベック

Slide 79

Slide 79 text

それを良しとする人もいました。そして、そのようなチームはとてもうまくいきました。しかし、一般的には、力関係は変わっていません。つまり、インセンティブが変わっていないのです。だから、行動は変わらない。だから結果も変わっていない。私は、これはペアプログラムをするかしないかという問題ではなく、意思決定をスキル・情報・結果に向けて動かす意思があるかどうかという問題だと思っています。 (Kent Beck 2021年７月のAgile 2021でのトークより) https://ja.wikipedia.org/wiki/ ケント・ベック

Slide 80

Slide 80 text

プロダクトバックログ開発者(たち)

Slide 81

Slide 81 text

プロダクトバックログ優先順位付けされた機能リスト。開発者たちが見積もる。納期は決められない。

Slide 82

Slide 82 text

自己組織的に働く人々。優先順位に合わせて出荷判断可能なプロダクトの増分を生み出していく。開発者(たち)

Slide 83

Slide 83 text

プロダクトバックログ動作するプロダクト (の増分) 上から順に生み出していく

Slide 84

Slide 84 text

動作するプロダクト (の増分) 上から順に生み出していく価値があるかどうかがわかるプロダクトバックログ

Slide 85

Slide 85 text

安定したチーム決まった期間仕掛を作らない継続的にリリース

Slide 86

Slide 86 text

これはいつできますか？

Slide 87

Slide 87 text

これはいつできますか？たぶん３スプリント目

Slide 88

Slide 88 text

動作するプロダクト (の増分) 上から順に生み出していく価値があるかどうかがわかるプロダクトバックログ

Slide 89

Slide 89 text

マッピングの注意点

Slide 90

Slide 90 text

なんかすごい縦長

Slide 91

Slide 91 text

トップダウンで考えている可能性が高い。データを取ろう。観察しよう。意見を集めよう。

Slide 92

Slide 92 text

まず注意: 目的をブレークダウンしても詳細は描けません。まず対象を十分に知っていないと、解決策は出てきません。情報が不足していると気づいたらまず調べること。観察したり話を聞くことに時間を振り向けるときかもしれません。

Slide 93

Slide 93 text

データ構造的には木構造。シンプルで理解しやすい。例外のない世界。二分法とかもこれ。しかし、世界は複雑で、ツリーでは表現できない。

Slide 94

Slide 94 text

使う人の都合を調べていく。

Slide 95

Slide 95 text

これが地図になる。 ll 共通認識

Slide 96

Slide 96 text

Slide 97

Slide 97 text

理解にはレベルがある。横浜駅パシフィコ詳しくないとき。

Slide 98

Slide 98 text

理解にはレベルがある。横浜駅パシフィコ詳しいとき。

Slide 99

Slide 99 text

理解にはレベルがある。自分で考えないとき。ついてけばわかるだろう。

Slide 100

Slide 100 text

付箋を駆使して、みんなで一緒に地図を描き、共通理解を作る。これこそが神髄 …だと思います。

Slide 101

Slide 101 text

視点を動かす

Slide 102

Slide 102 text

https://www.1101.com/iwata/2007-09-03.html

Slide 103

Slide 103 text

その時代から、宮本さんはなんにも知らない人をつかまえてきて、ポンとコントローラー渡すんですよ。で、「さあ、やってみ」って言ってね、なんにも言わないで後ろから見てるんですよ。わたしは、それを「宮本さんの肩越しの視線」と呼んでたんですけど。その重要性というのは、いっしょに仕事するまでわからなかったんです。 https://www.1101.com/iwata/2007-09-03.html

Slide 104

Slide 104 text

いっしょに仕事してはじめて、「あ、これだ」って思うんです。つまり、ゲームをつくった人は、ゲームを買ってくれるひとりひとりのお客さんに対して「このようにして作りました。こう楽しんでください」とは、説明に行けないんですね。当然ですけど。 https://www.1101.com/iwata/2007-09-03.html

Slide 105

Slide 105 text

簡単にいえば、お客さん目線なんですけど、それをどうやって見つけるかという方法を宮本さんはすごく早くから確立していて、一方、わたしは、自分のプログラムがイケてるかどうかには興味はあっても、お客さんがどう感じるかみたいなところは考えが及んでいなかったんです。 https://www.1101.com/iwata/2007-09-03.html

Slide 106

Slide 106 text

https://www.1101.com/iwata/2007-09-04.html

Slide 107

Slide 107 text

「オレは、これをいいと思う」ってすべてのお客さんを代表するかのように、思い込みで語るつくり手が多いんですよ。 https://www.1101.com/iwata/2007-09-04.html

Slide 108

Slide 108 text

本当は「お客さんがこう反応する」っていう事実があって、「それはなぜだろう？」という仮説があって、そこではじめて「じゃあ、どうすれば、根っこの問題が解決できるだろう？」って考えなきゃいけないのに、「オレはこう思う！」という、事実と仮説をぐちゃぐちゃに混ぜた意見を押し通してしまうことが多いんですね。 https://www.1101.com/iwata/2007-09-04.html

Slide 109

Slide 109 text

つまり、宮本さんというのは視点を動かすことに長けているんですね。そのとおりですね。いままで近くで見てたのを、突然ものすごく遠くから見てやり直すというか虫メガネで見ていたかと思うと地上一万メートルからもう一回見直してみたり https://www.1101.com/iwata/2007-09-04.html

Slide 110

Slide 110 text

ユーザーストーリーマッピングアジャイルなプロダクト開発

Slide 111

Slide 111 text

みんなで一緒に地図を描き、共通理解を作る。