全3432文字
PR

 書籍『誰も教えてくれなかったアジャイル開発』(日経BP)では、ウオーターフォール型開発が主流の「日本企業」で試行錯誤しながらアジャイル開発を成功に導いてきたコンサルタントたちが、自らの経験を体系化している。本書から抜粋し、初期計画段階で重要になる「ユーザーストーリー」の整理について解説する。(技術プロダクツユニットクロスメディア編集部)

 本書『誰も教えてくれなかったアジャイル開発』の「実践編」第1章では、アジャイル開発プロジェクトを成功に導くために、プロジェクトの「企画」工程で気を付けるべき7つのポイントを解説した。

 「実践編」第2章では、プロジェクトの「初期計画」工程における重要な7つのポイントを解説する。

本章(第2章)で説明する範囲を網掛け部分で示した
本章(第2章)で説明する範囲を網掛け部分で示した
(出所:シグマクシス)
[画像のクリックで拡大表示]

 アジャイル開発は「プロジェクト途中での変更を受け入れる」ことを前提とするが、プロジェクトのスタート段階ではその時点での「全体を見据えた初期計画」をつくる必要がある。初期計画ではプロジェクト代表者の「プロダクトオーナー(PO)」、または多忙なPOを支援して調整役やリーダー役を担う「代理プロダクトオーナー(PPO)」がリードしながらスコープ、優先順位の付け方、移行やテストといった「通常タスク」の扱い、リリース計画などを決める。

 この「初期計画」は最初から綿密に固める必要はないが、ステークホルダーと事前に合意して進めることが欠かせない。どの程度まで決めておけばよいのか、具体的に解説しよう。

ポイント(1) ユーザーストーリーを「ちょうどいい大きさ」に整える

 本書の「基礎編」では、要件定義においてシステムの全体像や機能の詳細を把握するには、エンドユーザーの要件を「役割(誰が)」「要望(何をしたい)」「理由(なぜ)」の要素で整理した「ユーザーストーリー」だけでなく、ウオーターフォール型開発でよく作成するドキュメントも積極的に採用すべきだと紹介した。具体的にはデータモデルや状態遷移図、フローチャート、画面イメージなどである。

 今回は、システムの全体感や機能開発の優先順位をステークホルダーと効率的に合意できるよう、プロジェクトの各段階におけるユーザーストーリーの「サイズ」と「粒度」について解説する。

 本題に入る前に、言葉の定義を再確認しておく。プロジェクト全体を通して、それぞれのイテレーションに割り振るタスク(作業)の塊を「プロダクト・バックログ・アイテム(PBI)」と呼び、PBIを一覧で整理したリストを「プロダクトバックログ」と呼ぶ。

エピックとユーザーストーリー、バックログの関係。要件を複数階層で表現する
エピックとユーザーストーリー、バックログの関係。要件を複数階層で表現する
(出所:シグマクシス)
[画像のクリックで拡大表示]

 ユーザーストーリーはPBIの1要素であるとともにPBIの多くを占める。ユーザーストーリーを束ねる上位概念として「エピック」という言葉を使う場合もある。開発リーダーがユーザーストーリーをタスクに分解し、「スプリントバックログ」として開発メンバーに提示する。