Download as PDF, PPTX
Recommended
More Related Content
What's hot
Similar to ユーザーストーリー駆動開発で行こう。
More from GuildWorks
ユーザーストーリー駆動開発で行こう。
- 1.Toshihiro Ichitani AllRights Reserved.ユーザーストーリー駆動開発で行こう。Ichitani Toshihiro市谷聡啓開発を始める前にみんなで理解しておきたいユーザーストーリーを用いた開発のお作法
- 2.Toshihiro Ichitani AllRights Reserved.http://about.me/papanda0806Ichitani Toshihiro市谷聡啓@papanda
- 3.Toshihiro Ichitani AllRights Reserved.受託→SIer→サービス→受託→旗揚関西で組み込み製品のプログラマー→プロダクトオーナー(企画者)支援アジャイル開発プロジェクトマネージャアジャイル開発コンサルタントここまでのあらすじ「リーン開発の現場」
- 4.Copyright (c) 2014Guild Works Inc.ユーザーストーリーという言葉はよく聞くか、たまには聞くかと思いますがどうですか？
- 5.Copyright (c) 2014Guild Works Inc.ユーザーストーリーという言葉はよく聞くか、たまには聞くかと思いますがどうですか？「実際にユーザーストーリーでは開発したことない」「開発してたけど上手くいかなかった…」「何が良いのか分からない…」
- 6.Copyright (c) 2014Guild Works Inc.ユーザーストーリーという言葉はよく聞くか、たまには聞くかと思いますがどうですか？「実際にユーザーストーリーでは開発したことない」「開発してたけど上手くいかなかった…」「何が良いのか分からない…」気持ちは分かります！この時間では、ユーザーストーリーを使った開発の進め方について紹介したいと思います。
- 7.Copyright (c) 2014Guild Works Inc.そもそも何が課題なの？ユーザーストーリーを使う！ってことから事を始めだすとあまり良い結果は期待できかもですね。ソリューションありきではなくて、何が課題で適用するのかから考えましょう。扱う課題は「何をつくるべきかをどのようにして、関係者の 間で伝え合えば良いか？」ということです。作ってみて「コレジャナイ」なんてことになったのは、一度や二度ではないでしょう。
- 8.Copyright (c) 2014Guild Works Inc.そもそも何が課題なの？どうやって解決していますか？扱う課題は「何をつくるべきかをどのようにして、関係者の 間で伝え合えば良いか？」ということです。
- 9.Copyright (c) 2014Guild Works Inc.そもそも何が課題なの？どうやって解決していますか？扱う課題は「何をつくるべきかをどのようにして、関係者の 間で伝え合えば良いか？」ということです。ドキュメントをゴリゴリと書いて、書いたらチームにレビューしてもらって…関係者に確認してもらって…そうですね、だいたいそうしてきてますよね。
- 10.Copyright (c) 2014Guild Works Inc.そもそも何が課題なの？どうやって解決していますか？扱う課題は「何をつくるべきかをどのようにして、関係者の 間で伝え合えば良いか？」ということです。ドキュメントをゴリゴリと書いて、書いたらチームにレビューしてもらって…関係者に確認してもらって…そうですね、だいたいそうしてきてますよね。でも、ちょっと大変ですよね。
- 11.Copyright (c) 2014Guild Works Inc.動くモノを作ってしまって関係者に確認してもらえれば良いんじゃないの。
- 12.Copyright (c) 2014Guild Works Inc.良いね！それが出来たらベストだね！ただ、その作戦で行く場合気をつけて欲しいことがあるんだ…動くモノを作ってしまって関係者に確認してもらえれば良いんじゃないの。
- 13.Copyright (c) 2014Guild Works Inc.良いね！それが出来たらベストだね！ただ、その作戦で行く場合気をつけて欲しいことがあるんだ…動くモノを作ってしまって関係者に確認してもらえれば良いんじゃないの。ワークに必要なコスト + 結果認識違いを訂正するコスト取れる作戦の間でこのコストの比較を見立ておこう。
- 14.Copyright (c) 2014Guild Works Inc.動くモノを作るコスト認識違いを訂正するコストドキュメントを書くコスト認識違いを訂正するコスト＋ ＋？チームとクライアントの状況と作るプロダクトの内容からどちらの作戦が有利かトータルのコストで判断する
- 15.Copyright (c) 2014Guild Works Inc.動くモノを作るコスト認識違いを訂正するコストドキュメントを書くコスト認識違いを訂正するコスト＋ ＋？さらに、ここに動くモノならではの「発見の可能性」とドキュメントならではの「見落としの可能性」を加味する➖早期に要求を発見出来る嬉しさ要求を見落したことによる手戻り＋
- 16.Copyright (c) 2014Guild Works Inc.動くモノを作るコスト認識違いを訂正するコストドキュメントを書くコスト認識違いを訂正するコスト＋ ＋＜チーム、クライアント、作るプロダクトを踏まえて、動くモノでの検証の方が有利ならば動くモノ作戦は有効だ！➖早期に要求を発見出来る嬉しさ＋要求を見落したことによる手戻り＋
- 17.Copyright (c) 2014Guild Works Inc.動くモノを作るコスト認識違いを訂正するコストドキュメントを書くコスト認識違いを訂正するコスト＋ ＋＜動くモノを作るのに相当なコストを要のであれば、または要求を「発見できる可能性が低い」ならば常に動くモノ作戦がコスト的に有利なわけではない。➖早期に要求を発見出来る嬉しさ要求を見落したことによる手戻り＋
- 18.Copyright (c) 2014Guild Works Inc.クライアントの状況によっては、「認識違いを訂正するコストが大きくなる可能性」もあるんだ。作るモノへのイメージがクライアントの中にだけある場合とかね。そうなると、本当に動くモノベースでいきなり検証するのが効率的なのかってなる。じゃあ、やっぱりドキュメント？まずはドキュメントの場合何が大変なのか整理してみよう。動くモノを作ってしまって関係者に確認してもらえれば良いんじゃないの。
- 19.Copyright (c) 2014Guild Works Inc.ドキュメントによる要件定義の課題大量の文章や図表を書くコストがとてもかかる。更新するのにコストがとてもかかる。※仮説検証的に進めるプロジェクトだと変更が多すぎて手に負えない。文章ですべてを表現することはできない。※それはもうコードだ。書いている方は漸次的だが読む方のバッチサイズは大きくなりがちで全体像を理解し難くなる読み手の読解力に依存するため、憶測や誤解が生じやすい。会話で文脈の補完が必要になる。全体を理解しづらいので計画を立てるのも難しい。そして、誰も見なくなる。
- 20.Copyright (c) 2014Guild Works Inc.大変すぎる！
- 21.Copyright (c) 2014Guild Works Inc.大変すぎる！そこで、ユーザーストーリーですよ。
- 22.Copyright (c) 2014Guild Works Inc.大変すぎる！そこで、ユーザーストーリーですよ。というと、万能的に聞こえちゃうから、急いで補完するとドキュメントを書かなくて良いというわけではないのだよ。ユーザーストーリーはユーザーがやりたいことを簡潔にまとめつつ、詳細を補完するためにその後の会話を約束するための道具なんだ。
- 23.Copyright (c) 2014Guild Works Inc.ユーザーストーリーはドキュメントなのか？分かりやすいので、つい要件定義書と比較してしまいがちなのだけど、ユーザーストーリーはドキュメントと思わない方が良い。要求をまとめるやり方の選択肢が1つ増えたと捉えた方が良いんじゃないかな。作って欲しい人と隣同士で逐次会話しながら作るドキュメントでつくりたいものを定義してから作るユーザーストーリーで駆動する開発どのやり方が絶対的にダメって話じゃない。状況に応じて使い分けよう。
- 24.Copyright (c) 2014Guild Works Inc.では、ユーザーストーリーとはどういうものなのか、具体的にみていくことにしよう。
- 25.Copyright (c) 2014Guild Works Inc.どう書くの？ 三段構成＜ユーザー／顧客＞ として＜XXXを達成＞ をしたいなぜなら ＜理由＞ だからだ<Who>として<What>をしたいなぜなら <Why>だから別の表現としてはユーザーストーリーとは？<30代の求職者>として<年収で仕事を探>したいなぜなら<仕事選びで年収の優先度が高い>だからたとえばとも言える。という感じで書く。
- 26.Copyright (c) 2014Guild Works Inc.ユーザーストーリーにはHowを書かないんだね。
- 27.Copyright (c) 2014Guild Works Inc.ユーザーストーリーにはHowを書かないんだね。そうだね。ユーザー(Who)の望みは、理由(Why)から出てきているんだ。Whyを実現する手段(How)はむしろ、開発チームが腕を振るうところだ。例えばさっきの例「年収で仕事を検索したい」そのために検索エンジンを使うのか、SQLで直接頑張るのか、どんな手段を取るかは求職者にとっては関係ないよね。もちろん手段選択による実害があったら困るよ。
- 28.Copyright (c) 2014Guild Works Inc.ユーザーストーリーとは？対象者にとって、理解できる・評価できる内容になっていること！=対象者にとって価値がある…それって機能のこと？
- 29.Copyright (c) 2014Guild Works Inc.ユーザーストーリーとは？対象者にとって、理解できる・評価できる内容になっていること！=対象者にとって価値がある…それって機能のこと？ユーザーストーリーは機能ではない。対象者にとっての価値をあらわすものなんだ。その価値をもたらすための手段が機能になる。機能に始まり、機能で終わると、目的を見失う可能性が高くなる。機能をただつくることが目的ではないよ。目的は対象者に価値をもたらすこと。利用者に価値を届けるソフトウェアを作ることが僕達の仕事だ。
- 30.Copyright (c) 2014Guild Works Inc.ユーザーにとって理解できること…それって、どんな文章なの？
- 31.Copyright (c) 2014Guild Works Inc.ユーザーにとって理解できること…それって、どんな文章なの？ユーザーが理解できる言葉を用いる必要があるね。ただ、あいまいな文章にしてもダメだ。どうなればそのストーリーが出来たと言えるのか判断できないからね。
- 32.Copyright (c) 2014Guild Works Inc.ユーザーにとって理解できること…それって、どんな文章なの？ユーザーが理解できる言葉を用いる必要があるね。ただ、あいまいな文章にしてもダメだ。どうなればそのストーリーが出来たと言えるのか判断できないからね。「完成の条件」が言えないとダメだ。「何が出来ないければいけないのか」の定義だね。これがはっきりしないようなら、ストーリーとしてまだ、練り込みが甘いってことだ。
- 33.Copyright (c) 2014Guild Works Inc.ねえ、ストーリーを書きだしていると30も40にもなって、何が何だかわからなくなってきたよ！
- 34.Copyright (c) 2014Guild Works Inc.ねえ、ストーリーを書きだしていると30も40にもなって、何が何だかわからなくなってきたよ！ユーザーのやりたいこと構造的に捉えるために、エピックとストーリーを使い分けよう。
- 35.Copyright (c) 2014Guild Works Inc.ねえ、ストーリーを書きだしていると30も40にもなって、何が何だかわからなくなってきたよ！ユーザーのやりたいこと構造的に捉えるために、エピックとストーリーを使い分けよう。特に、開発の初期段階ではやりたいことがまだもやっとしていることがよくある。最初から答えが分かっているなんてことはあまりない。エピックというのはやりたいことを大きな粒度で捉えるためのものだ。
- 36.Copyright (c) 2014Guild Works Inc.エピックとストーリーの例<30代の求職者>として<求人を検索>したいなぜなら<自分にあった求人に応募したい>だから<30代の求職者>として<採用企業に問い合わせ>したいなぜなら<求人内容についてより深く聞きたい>だから<30代の求職者>として<求人に応募>したいなぜなら<選考をすすめたい>だからユーザーは求人に応募することができるエピックストーリーやりたいことは初めはエピックレベルかもしれないだから関係者と会話して詳しくしていくんだ。
- 37.Copyright (c) 2014Guild Works Inc.よし、いっぱいストーリーが書けた。さあ、つくるぞー！
- 38.Copyright (c) 2014Guild Works Inc.よし、いっぱいストーリーが書けた。さあ、つくるぞー！ちょっとまった。最初に言ったことを思い出そう。ユーザーストーリーはユーザーがやりたいことを簡潔にまとめつつ、詳細を補完するためにその後の会話を約束するための道具なんだ。
- 39.Copyright (c) 2014Guild Works Inc.よし、いっぱいストーリーが書けた。さあ、つくるぞー！ちょっとまった。最初に言ったことを思い出そう。ユーザーストーリーはユーザーがやりたいことを簡潔にまとめつつ、詳細を補完するためにその後の会話を約束するための道具なんだ。関係者との会話は十分にできているかな？ストーリーだけ書いて作れるほど、おそらく甘くはないよ。
- 40.Copyright (c) 2014Guild Works Inc.でも、ユーザーストーリーを書けば他のドキュメントはいらないんでしょ
- 41.Copyright (c) 2014Guild Works Inc.でも、ユーザーストーリーを書けば他のドキュメントはいらないんでしょ例えば、何らかのビジネス・ルールがあるとして抜け漏れがないかどうやって、確認する？UIのイメージは関係者とあっている？イメージをすりあわせるためにラフなスケッチくらいは書かないといけないんじゃない？目的に応じて、その手段を検討するべきだ。
- 42.Copyright (c) 2014Guild Works Inc.わかった。では、ストーリーとしてはどういうのがよく書けていると言えるの？
- 43.Copyright (c) 2014Guild Works Inc.完成の条件が言えるストーリーというのが良いストーリーの条件と言えるね。他にもいくつか特徴があるんだ。次の6つだ。I ‒ Independent (独立して優先順位がつけられる)N ‒ Negotiable (何をつくるかの案が調整可能である)V ‒ Valuable (価値のある)E ‒ Estimable (見積り可能である)S ‒ Small (チームで扱いやすい手頃なサイズである)T ‒ Testable (テストできる)頭文字をとってINVESTと呼ぶよ。わかった。では、ストーリーとしてはどういうのがよく書けていると言えるの？
- 44.Copyright (c) 2014Guild Works Inc.独立して優先順位がつけられるI ‒ Independent (独立して優先順位がつけられる)N ‒ Negotiable (何をつくるかの案が調整可能である)V ‒ Valuable (価値のある)E ‒ Estimable (見積り可能である)S ‒ Small (チームで扱いやすい手頃なサイズである)T ‒ Testable (テストできる)ストーリーの間で強い依存関係があるとスコープが調整しづらくなるし、完成の状態があいまいになってしまうね。このストーリーは完成しているように実はあっちのストーリーが終わらないと終わりにはならない…とかね。
- 45.Copyright (c) 2014Guild Works Inc.何をつくるかの案が調整可能であるI ‒ Independent (独立して優先順位がつけられる)N ‒ Negotiable (何をつくるかの案が調整可能である)V ‒ Valuable (価値のある)E ‒ Estimable (見積り可能である)S ‒ Small (チームで扱いやすい手頃なサイズである)T ‒ Testable (テストできる)やりたいことを実現する手段(How)が調整可能でなければ、相当しっかりと計画を組み立てることが求められているのと同じことになる。最初に言ったとおり、Whyを実現するための一番良いところのHowはチームから提示しよう
- 46.Copyright (c) 2014Guild Works Inc.価値のあるI ‒ Independent (独立して優先順位がつけられる)N ‒ Negotiable (何をつくるかの案が調整可能である)V ‒ Valuable (価値のある)E ‒ Estimable (見積り可能である)S ‒ Small (チームで扱いやすい手頃なサイズである)T ‒ Testable (テストできる)これはもう説明がいらないかな。僕達の目的はユーザーに価値をもたらすソフトウェアを作ることだ。一つ一つのストーリーがユーザーにとって価値をもたらすものになっていなければそれを積み重ねても目的にはたどり着けない。おそらく関係者が理解できる内容にもなっていないだろう。
- 47.Copyright (c) 2014Guild Works Inc.見積可能であるI ‒ Independent (独立して優先順位がつけられる)N ‒ Negotiable (何をつくるかの案が調整可能である)V ‒ Valuable (価値のある)E ‒ Estimable (見積り可能である)S ‒ Small (チームで扱いやすい手頃なサイズである)T ‒ Testable (テストできる)見積ができるということは、やりたいことへの実現手段がはっきりとしているということだ。逆にまだ見積ができないなら、関係者との会話が不足していそうだ。
- 48.Copyright (c) 2014Guild Works Inc.チームで扱いやすい手頃なサイズであるI ‒ Independent (独立して優先順位がつけられる)N ‒ Negotiable (何をつくるかの案が調整可能である)V ‒ Valuable (価値のある)E ‒ Estimable (見積り可能である)S ‒ Small (チームで扱いやすい手頃なサイズである)T ‒ Testable (テストできる)ストーリーを小さくできると、見積がしやすくなる。何日もかかるような壮大なストーリーは見積もったところで凄くブレが生まれる可能性が高いよね。それに小さくないと１回のイテレーションの中で終わらなくなっちゃうからね。
- 49.Copyright (c) 2014Guild Works Inc.テストできるI ‒ Independent (独立して優先順位がつけられる)N ‒ Negotiable (何をつくるかの案が調整可能である)V ‒ Valuable (価値のある)E ‒ Estimable (見積り可能である)S ‒ Small (チームで扱いやすい手頃なサイズである)T ‒ Testable (テストできる)テストができるようになっているということは、ソフトウェアがどう動けば良いか分かっているということだ。つまり、完成の条件が明確になっているということだね。
- 50.Copyright (c) 2014Guild Works Inc.ストーリーはオブジェクトに似ている高凝集!!疎結合1つのストーリーには必ず1つの価値がある十分に小さいことストーリーは可能な限り独立していること単体で完成することができる高凝集、疎結合でなければ、ユーザーストーリーだけではプロダクトとプロジェクトの状況を把握するのが難しい
- 51.Copyright (c) 2014Guild Works Inc.実は、ストーリーが足りてない気がするんだ…
- 52.Copyright (c) 2014Guild Works Inc.ユーザーストーリーはやりたいことを簡潔にまとめるための道具だ。ストーリーを洗い出すための手法は別に必要だ。いろいろなやり方があるよ。やり方は1つではない。いろいろと試してみよう。実は、ストーリーが足りてない気がするんだ…
- 53.Copyright (c) 2014Guild Works Inc.やりたいことを洗い出すさまざまな手段が取れるし、組み合せよう。・ペルソナ・インセプションデッキ・UIイメージのスケッチ・ドメインモデル・ユーザーの要望、インタビュー結果そして、ユーザーストーリーマッピングも。
- 54.Copyright (c) 2014Guild Works Inc.54ユーザーストーリーマッピングユーザーストーリーマッピングとは、時系列にユーザー行動を洗い出し、行動に基づいて要求を見立てる手法。関係者が集まり、付箋や模造紙を用いてワークショップ形式で行なう。参加者の知見を活かして、要求を発見・洗い出す。また、優先度付けを行うことでスコープ(範囲)を短時間で特定することもできる。ユーザーストーリーマッピングのイメージ
- 55.Toshihiro Ichitani AllRights Reserved.時系列定点感情ベース 行動ベースユーザーのインサイトに踏み込むための道具エクスペリエンスマップ ユーザーストーリーマッピング共感マップhttp://www.amazon.co.jp/gp/product/toc/4621088068/
- 56.Copyright (c) 2014Guild Works Inc.ユーザーストーリーで開発を駆動するユーザーストーリーだと、やりたいことの全体像を捉えやすくなる(重厚なドキュメントだとまず読み込むだけで相当なコストがかかる)。全体像が捉えられると、計画が立てやすくなる。全体として何をやらなければならないかの把握がしやすくなるからね。そして、ユーザーストーリーが中心の開発だとユーザーストーリーの開発状況を押さえることでプロジェクト全体の状況も理解できるようになるんだ
- 57.Copyright (c) 2014Guild Works Inc.では、ユーザーストーリーをつかった開発の流れを具体的に追ってみることにしよう。!※この例ではPivotalTrackerを使うよhttps://www.pivotaltracker.com/
- 58.Copyright (c) 2014Guild Works Inc.①ユーザーストーリーを洗い出す
- 59.Copyright (c) 2014Guild Works Inc.②洗い出したストーリーをPivotalに登録するひとまずiceboxに登録する。登録したら関係者でiceboxを眺めて抜け漏れをチェックしよう!ラベルをつけて管理しやすくしよう。Pivotalだとラベルをエピックにしてエピックとしてストーリーをまとめて管理することもできる。!Whyまで書くと長くなるのでdescriptionに書くと良い
- 60.Copyright (c) 2014Guild Works Inc.③ストーリーの完成の条件を定義しよう何ができればこのストーリーは終わるのか？条件が定義できるまで関係者と話し合う。内容は、descriptionに書いておく!開発が進む中で新たに分かったことが出てくればdescriptionに残していく
- 61.Copyright (c) 2014Guild Works Inc.④ストーリーをチームで見積もろう各ストーリーの規模をチームで見積もる。POINTSに見積ったポイントを入れていく。※ポイントの単位は設定で変えられる!見積りはプランニングポーカーがわかりやすくて手軽でオススメ※やり方は書籍「リーン開発の現場」に詳しい!相対的に見積もる。基準となるストーリーを決めて、それの何倍くらいの規模になるかをみたてる
- 62.Copyright (c) 2014Guild Works Inc.⑤ストーリーの順序付けを行なうiceboxからbacklogレーンに持って行き順序付けする関係者といっしょにやろう!チームのベロシティに基づきどのストーリーがどこのイテレーションになるかは自動的に決まる※チームのベロシティは倒したポイントの実績値で決まる。初期ベロシティは設定から変更できる。これまでいっしょにやってきたチームなら過去のプロジェクトのベロシティを一旦参考にしても良し。
- 63.Copyright (c) 2014Guild Works Inc.⑥プロジェクト開始！イテレーションの計画ミーティングとイテレーションレビューのタイミングを決めておこう。! 計画ミーティング … そのイテレーションでどのストーリーを対象に するか決める 必要に応じて作れるようにするために、 更にストーリーを詳しく理解する イテレーションレビュー … 開発したストーリーを動くモノにて関係者で 確認する!例えば毎週金曜日はイテレーションレビューを実施してから次のイテレーションの計画ミーティングも行なう、といったように。
- 64.Copyright (c) 2014Guild Works Inc.⑦着手するストーリーを決めて開発を始める。担当するストーリーのStartボタンを押すとFinishに変わる。!開発を終えたときにFinishを押そう。ボタンはDeliverになる!デモ環境に対象ストーリーを上げたらDeliverボタンを押す。AcceptとRejectのボタンが表示される
- 65.Copyright (c) 2014Guild Works Inc.⑧イテレーションレビューで完成を判断するイテレーションレビューで関係者に対象ストーリーをデモ環境で動かしながら確認してもらおう完成しているならばAccept、まだ完成の条件を達成していないならばReject。Rejectはストーリーとして残り続ける。!計画ミーティングで次の開発対象を確認しよう。ストーリーが積み残っていくと、すべてのストーリーが完成する着地点が変わっていくことになる※Pivotalのバーンダウンチャートで適宜確認し、必要な手を打つ!このサイクルを繰り返していく！
- 66.Copyright (c) 2014Guild Works Inc.最後にまとめておこうユーザーストーリーとは、・やりたいことをまとめる手段であり、 計画を立てるための材料であり、 実績を測るための対象である。・ユーザーストーリーとは 「プロジェクトの中心にあって(無くてはならない) 開発を駆動する手段であり(すべてストーリーから始まる) 目標になる存在である(ストーリーが完了しないと終わらない)」すべてはストーリーから始まる！