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