フクロウの図表ラボ

要件の実装

最後は、具体化された要件を基に、実際の開発作業に落とし込んでいくプロセスです。

開発作業なのであれば、要件定義とは別のプロセスなのでは？という印象もあるかもしれません。その捉え方ももちろん正解だと思います。

一方、アジャイル開発では、開発着手後も要件の調整・詳細化は継続されますので、広く「要件定義」と捉えて、その過程を理解しておくことも役立ちそうです。

具体的には、2つのバックログを用いて要件を調整・管理します。

プロダクトバックログ

プロダクトバックログは、対応されるべきこと・積み残し（＝バックログ）を優先順位付けしてリスト化したものです。プロダクトオーナーが管理し、常に更新され続けます。

（backlog = a large number of things waiting to be done）

まずは、すでに作成したユーザーストーリーの優先順位の高いものからプロダクトバックログとしてリスト化していきます。

ここで1点注意が必要です。プロダクトバックログに含まれるものは、実は「機能」だけではありません。

以下のように、ユーザーから見るとソフトウェア自体に変化が見られないが、プロダクトの進化にとっては必要不可欠なこと（バグ修正、技術的負債の解消、メンバーの知識獲得など）も、プロダクトバックログには含まれます。

プロダクトバックログはプロダクトオーナーが管理し、理想的には、プロダクトに関するすべての作業がプロダクトバックログを経由します。つまりここにリスト化されていないものは、プロダクトオーナーから着手の指示を得られない可能性もあるということです。

プロダクトをゼロから作るタイミングなのか、機能拡充なのか、など状況によりますが、もしこの時点で見えている「バックログ」が存在するのであれば、ユーザーストーリーに加えて、追加しておくことをおすすめします。

※経験上、機能以外のバックログは開発進行につれてあとから増えていくものなので、あくまでその時点で分かる範囲の追加でいいと思います。

スプリントバックログ

スプリントバックログは、1つのスプリント（通常2~4週間の開発サイクル）で実装する項目を詳細化したものです。具体的には、プロダクトバックログからスプリントゴールとする項目を選択し、具体的なタスクに分解します。

タスクの詳細化においては、より詳細なシステム設計が行われます。

例えば、UXと技術の両面から考えたシステム挙動に関する提案（ボタン押下をトリガーにするのではなく、プルダウンでの選択をトリガーにしたい。といったような本当に細かい内容）があれば、積極的にステークホルダーと話し合い、都度解消します。

スプリントプランニングの細かい進め方はここでは割愛しますが、スプリントバックログはスプリントゴールとセットだ、という点はぜひ共有させて下さい。

以下に例を挙げます。

• プロダクトジャンル：　B2C ソフトウェア製品 📱
• プロダクトゴール：　市場シェア10％およびNPSを5ポイント向上させることで、マーケットリーダーになる
• スプリントゴール：
  • フィーチャーの提供： “プレミアムユーザー4万人全員への一括ファイル共有機能の実装と提供をする”
  • 問題解決： “最新の分析データから、最も緊急性の高いアプリケーションのパフォーマンス問題を特定し、解決する”
  • リスク軽減：”データプライバシーを確保し、ユーザー情報を保護するために、既知の5つのセキュリティ脆弱性すべてに対処する”

引用元：スクラムにおける効果的なスプリントゴールの作成

ここで設定したスプリントゴールは、スプリントレビュー（個人的には、スプリント達成を祝う”お祭り”と思っています）での共有内容そのものです。

スクラムチームはもちろんですが、ステークホルダーにもわかりやすい内容でスプリントゴールを設定すると、成果を共有しあえる、より良いツールになると思います。