第9回読書会

• 2011年11月22日 19:00-21:00
• エスプランニング開発室
• 参加者 3人
• 6.3 ～

第6章 ユーザーストーリーを集める

6.3 よく書けているユーザーストーリーとは

ユーザーストーリーの特徴

• ユーザーストーリーに関わらず、プロジェクトでこのようなことを考える時に大事になることが書いてあるよね
  • お客さんの言葉で話す、テストができるように、など
    • 特に「お客さんの言葉で話す」はどんな形のプロジェクトであっても大事
• 「交渉の余地がある」はアジャイルらしいね
• 独立している、テストできる、小さい・見積もれる
  • これは達人プログラマにも書いてあった！（直交性など）
• ケーキを一つの会社で作れないのはなかなかつらい
  • 永続化層、ビジネスロジック層、ユーザーインターフェイス層がそれぞれ違う会社
    • この分業自体は悪いことではないはずなのだけど・・・
    • スポンジならスポンジ、と分かれているわけでもない
      • インターフェースを先に決めればうまくいきそうだけど、インターフェースがなかなか決まらないんだよね
  • できないことはできないという大切さ

112ページ のユーザーストーリーと要件定義書の比較について

• 「よい」ユーザーストーリーと「よくない」要件定義書の比較だよね
• そもそもユーザーストーリーと要件定義書を比較しているのがおかしい気がするんだよね
  • 比べる次元が違う気がするなぁ
  • 言いたいことはわかるのだけどね
• 1個目「正確」− ユーザーストーリーって正しい、正しくないの話をしてはいけないのではないかな
• 見える化しているか、していないかが重要なんじゃないのかな
• 要件定義書と仕様書が「陥りがちなこと」だとまだしっくりくるかな
• 見積もりの精度や協調作業がどうユーザーストーリーに関わってくるのだろう

ビッグウェイブ・デイブのサーフィンショップへようこそ

113ページのデイブの言葉から、ユーザーストーリーを作ってみよう。

＜やってみた＞

• 開催予定のイベントをチェックできる
• Webカメラでビーチを動画配信する
• どこからでも見ることができるWebサイトにする、モバイル端末からも見れる
• ウェットスーツなどのサーフ用品をウェブサイトを通じて販売できる
• サーファーがデイブの店の場所や回転時間を見ることができる
• デイブがウェブサイトを最新のものに更新できる
• サーフィン大会の過去の様子や選手を知ることができる
• 服などの商品を一覧で表示できる
• 初心者が講習に安心して参加できるように価格や内容を紹介する
• スーツやサーフ用品をサイトでコーディネートできる
• 誰にでも読めるようにウェブサイトを外国語に対応する
• 地元でないサーファーや、サーファーでない人がデイブの地元の海の様子を知ることができる
• 海の様子がわかるよう天気予報が表示される

＜感想＞

• 難しい、そんなに出てこない
• デイブがこの場にいないので話を聞き出せない
  • いなくても出せるよ
  • それがなぜ出せるのかわからない
• 少なくてもこっちからアイデアを出さないと対話にならない
  • 「ニーズをさぐる」とはそういうこと
• デイブが話してないことも書いてしまっていいのかがわかんない
• 何が価値があるのかはこの時点ではわからないという前提
• 「ユーザーストーリー」ってなんなんだろう
  • やりたいことを出す、必要なことを引き出す、というのはわかるのだけど、この本に書いてることだけでどうしてそこまで引き出せるのか
  • ある程度こうだろうなあと想像しながら書いていくっていうのがいいと思うよ（本のデイブと会話はできないから）
• ユーザーストーリーなのにアクターがない
  • 誰の価値になるのかをユーザーストーリーに書いてないのはおかしい
  • 「誰が」は必ず必要

今すぐやってみよう

• 「デザインはマジかっこよく」の定義ってはっきりさせなくちゃいけないんだよね
  • これはそのまま残っていたらダメ
  • 測定できるものにしなければお客さんの価値はない
  • これが不正確な状態のまま残っているのはダメなプロジェクト
  • 定義できる形に直すのは難しいけれど
  • 落とせるものはすべて数値に落とすこと
    • 選択肢を与えるだけでも数値に落としたことになるのか
      • なる（1票を投じるという判断が入るから）
• 制約カードとは何か
  • 毎週形として届けるものじゃないもの
  • 直接的/間接的
  • 間接的なものも計測可能な判断を持っておかなければならない
• 「なぜ」というのを書くかどうかについて「好きな方を選べと」書いてあるけれど絶対書かなければならないと思う
  • そうなのかな、6.2とかのユーザーストーリはそうではない書き方になっている気がする
  • 6.3とかに書いてあるストーリーは片手落ちだと思う、誰にとってのどんな価値か書かれていないから
    • そうなのかな
    • そこからお客さんと話が膨らめば全部書く必要はないのではないかな
    • 書いておかないと失敗したアジャイルになる
      • あとから話せばいい、は書かない言い訳にしかならないんじゃないかな
• ユーザーストーリーって受け入れテストでエビデンスとして使うものなの？
  • そうではないけど、別に話し合ってわかったことを書かないでおかない理由はない
• どうも自分のユーザーストーリーについての考え方は間違っていたのかな
• ユーザーの価値を把握するための方法の一つなので手段はそこまで重要じゃない
  • ユーザーストーリが何かという答えや正解はない
• 人には2種類のタイプがある
  • 2種類のタイプがいた
    • 結論は覚えているけど過程を忘れている
    • 過程を覚えているけど結論をはっきり覚えてない
  • それによって何を「見える形で残しておきたいか」が違うのかも
• よいウィーターフォールを知らない人がアジャイルを勉強する場合と、ウォーターフォールを改善しようという試みや勉強をしてからアジャイルを勉強している人とでは捉え方が全然違う
  • アジャイルVSウォーターフォールという考え方はちょっと違う
  • ウォーターフォールを改善すればアジャイルじゃなくてよいことだってたくさんある
  • PMがプロジェクトをしっかりまわせばアジャイルな手法じゃなくてよい
    • そういう意味で「アジャイル」として書かれていることのほとんどはウォーターフォールでも同じことを言っているし当てはまることが多い
  • 正しいウォーターフォールを知らずにアジャイルだけを学んでも正しい理解ができないんじゃないかな

---

次回は6.4から 12/6(火）開催です。