【アジャイル】アジャイルサムライを読む その6 ~ ユーザーストーリーを集める

◀︎其の1はこちら
◀︎其の2はこちら
◀︎其の3はこちら
◀︎其の4はこちら
◀︎其の5はこちら
◀︎其の6はこちら
◀︎其の7はこちら
◀︎其の8はこちら
◀︎其の9はこちら
◀︎其の10はこちら
◀︎其の11はこちら
◀︎其の12はこちら

こんにちは！
ラジコード編集部です 😊

アジャイルサムライを読む連載記事その6です！😃
前回は第2部 アジャイルな方向づけ の「第5章：具現化させる」で、「開発チーム、スポンサーや顧客全員がプロジェクトの全体像と話の流れを共有」するインセプションデッキの後半の内容について学習できました。

その6から第3部「アジャイルな計画づくり」に入ります。
それでは「第6章 ユーザーストーリーを集める」を読んでいきましょう。
よろしくお願いします！🙋‍♂️

本シリーズは「アジャイルサムライ − 達人開発者への道」を1〜5部を1~2記事に分け要点を解説していくシリーズです。全13記事を予定しています。

第3部 アジャイルな計画づくり

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

ユーザーストーリーを使った要求の集め方を学ぶと、以下のことが見えてくる。

• 契約に最新の状況を反映できるのか
• 一番新鮮で信頼のおける情報を含めることができるのか
• 時期尚早な事前分析を避けられるか

まずは従来の要求の集め方をおさらいからはじめていきましょう！

文書化の難しさ

時間をかけて顧客の要求をまとめるには多くの時間がかかる。そしてその要求は時間が経つにつれて変化していく、その度に文書を更新・整理しないといけない。
多くの文書は最初は頑張って作成されるがメンテナンスがされず必要とされなくなります。

本当に必要なのものは、顧客の要求を引き出す会話だったり、欲しいものの本質を捉えられるようになることだったり、計画を立てる際の要求が記載されている何かです。

そこでユーザーストーリー

顧客がプロダクトで実現したいと思っているフィーチャーを簡潔に書いたものが、ユーザーストーリーです。

フィーチャーの本質を捉えるキーワードを書き溜めておくだけで、その時点では要求を細かく聞くことはしません。
本当に必要になるか、思いついたときには分からないからです。
あとで本当に必要になったときに詳細に確認できるようにしておきましょう。

良いユーザーストーリーとは

顧客にとって何かしらの価値がかかれている

お客さんが対価を払ってもいいと思えるものが価値です。
ビジネスの観点から評価するために、技術用語を避け、シンプルな言葉づかいで書きましょう。
お客さんにわかってもらえる言葉づかいで表現することが大事です。

エンドツーエンドになっている

解決策を3分の1だけ示されても嬉しくない。
要求を実現するためのアーキテクチャのすべての書いておこう。

独立している

プロジェクトには変化がつきものです。
ユーザーストーリーが密接に絡みあっていればトレードオフの判断は難しくなります。
機能開発なら、完成に向けて細かくやることを示すとスコープを柔軟に調整できるようになります。

交渉の余地がある

ある程度融通が利くように幅を持たせていくつか提案しましょう。
まずは「最低限動くもの」が欲しいのか、ある程度リッチな状態で使えるようにしたいのか。

テストできる

どうなっていればちゃんと動いているのか。実際に動かしてテストができると、開発トームの作業範囲と仕事の完了基準が明確になります。

小さく、見積もれる

ストーリーを1〜5日で完了できるサイズにすれば、1週間〜2週間の範囲に収まるか分かります。
システムの完成の目処は見積もれないが、機能ごと、その機能を構成するパーツを作るといったサイズなら見積もりも正確になります

ユーザーストーリーのテンプレート

ユーザーストーリーは適切な言葉づかいで簡潔に書かれてさえいれば、具体的に何のことなのか思い出せますが、ストーリーの前提となる状況をはっきりさせた方がいい場合もあります。

• 誰の：ためのストーリーで
• 何を：したいのか
• なぜ：そうしたいのか

記述が助長になることもあるので、自分自身で試してみることが大事です。

まとめ

以上「第3部アジャイルな計画づくり：第6章 ユーザーストーリーを集める」の解説でした。
ユーザーストーリーを作ることで、顧客のニーズをさぐり、プロジェクトの全体像がつかめてきました。

次回は「第7章：見積り：当てずっぽうの奥義」を読んでいきましょう😌

月額固定・定額制でアジャイル開発を提供する「サブスクエンジニア」サービスを提供しています。よろしければご覧ください！