今さら聞けない

アジャイルクラブについて

アジャイルに関わらず開発現場の改善を志す人（ひよこ）が集い、有識者（にわとり）に悩みを相談しつつ、いつの日か「にわとり」になることを目指すコミュニティです。

イベントレポート

会場スポンサートーク

今回のイベント会場はピクスタ株式会社が提供してくれています。

お酒もどうぞ！

ピクスタの李さんが自社サービスについてご紹介

メインスピーカー１

テーマ：ユーザと制服、氷山、ハンバーガー
発表者：クックさん

①　ユーザーストーリーは制服と同じで、着ているだけではなれませんよ！

この仕様で作って欲しい！とユーザーストーリーの名前で作っても、中身はユーザーストーリーになると限らない、というポイントでアピールします。
ユーザーストーリーはシステム仕様の説明ではなく、ユーザ視点で考えるべきですね。

制服の比較例は斬新でした！

②　ユーザーストーリーは氷山であるように、最初から全体像の把握はほぼ不可能です

１度書いて、開発者にまわして、おしまいじゃない！
最初から完璧な内容を書こうとしない
定期的にグルーミングが必要、分解して更に分割する

確かにユーザー視点で価値を描いて、欲しい機能をストーリー形式で表現したときに全てのケースを網羅することが難しいですね。
更に、プロダクトオーナーが持つ視点、エンジニアが持つ視点、デザイナーやQAが持つ視点、定期的にディスカッションをしながらそれぞれを合わせてユーザーストーリーと機能の要件がやっと明確になっていきますね。
ただ、それを一つのユーザーストーリーにまとめてしまうと非常に大きい作業になってしまいますので、必ず分割しましょうとアドバイスしてくれます。

③　ハンバーガーのひとくち

ハンバーガーのひとくちで味が全体的にわかる
ユーザーストーリーは同じで、サラダだけ（データベース）、お肉だけ（フロントエンド）ではプロダクトの味になっていない

では分割はどうやってやるのか、についてクックさんからまた面白い比較例で表現してくれます。
ポイントとしては、技術レイヤーで分割しないことですね。
理由としては技術レイヤーで分割してしまうと、機能の実装進捗がわからない、リリース可能な単位ができないリスクがあるからです。

ユーザーにとって価値のある単位に分割することの大事さを面白く教えてくれるクックさんでした。

メインスピーカー２

テーマ：「価値を届けるユーザーストーリーに必要な三つのこと」
発表者：関さん

ユーザーストーリーの目的は共通な理解を掴むことと説明しています。
それは作ろうとしているものではなく、誰のために、なんのためにやるかを理解するためです。つまりプロダクトオーナーを含めてチーム全員が価値を理解することがポイントですね。

では、価値はどう定義すれば良いかについて語ってくれます。

顧客価値の教科書定義がありますがそれは多量生産時代の定義で、現在通用しなくなってのではないかとアピー理します。
経営観点とプロダクトマネジメントの変容（過去10年の傾向）について解説します。

信用経済、共有経済、評価経済になっていくなか、どうプロダクトマネジメントを合わせて進化させればよいか？
誰にとっての価値か、価値をどう提供するか、共有すべきものはなにか？

作ろうとしているユーザーストーリーはどの価値の種類に当てはまるか、まず考えてみてはいかがですか？とアドバイスしてくれます。

よくいる人（運営）の森さんが同時にマインドマップに落とし込み中！

LT大会！

5分で面白い内容をプレゼンする時間です。

非技術者がどうやって大きなユーザストーリーを小さくするか考えてみた

発表者：山口さん

クックさんのトークにきれいにつながる内容で、分割が大事だとわかったときに、実際にどうやってやるのかについて山口さんが非技術者の観点で語ってくれます。

ストーリーの分割方法は、いろんな書籍で様々なアプローチが解説されているほど関心を集めている課題です。

なぜ分割が難しいか？ユーザーストーリーのWhyの理解（実現する理由）、本当のユーザー価値がしっかり掘られていないことが多いようです。

ユーザーストーリーが「INVEST」になっているのか、誰が判断すればよいか、悩むことがありましたが、その判断を開発チームに任せることにしました。

そして分割の作業自体は、とりあえず自分で分割してみて、開発チームからフィードバックをもらい精度を上げていくサイクルで行っています。

悩み相談

悩み相談会は、参加者にとって自分の現場の悩みをぶつけて、すぐに始められる改善やヒントを得るための時間です。

真面目に考えている参加者たち

こんな相談内容がありました：

Q: ユーザーストーリーが大きすぎて、スプリントに収まらない傾向があるが、適切なサイズってなんだろう？
- A: ストーリーテストを採用してみては？
Q: ユーザーストーリーって、プロダクトオーナー1人で作るのか？プロダクトオーナー、スクラムマスター、開発者みんなで作っているがすごく時間がかかるし、全員集まるのが難しい
- A1: うちでは1日を確保して、ユーザーストーリーマッピングを書くようにしている
- A2: うちではプロダクトオーナーがまず解決したい課題、解決策の仮設、ユーザーフローを書いて、それから開発者に向けて説明して、フィードバックをもらう。そのサイクルを2回くらい繰り返してやっと形になる。時間はかかるがすでに着手可能なタスクが積んであるのでボトルネックにはならない。