より小さなプロダクトバックログアイテムを作成する方法

大きなプロダクトバックログアイテム（PBI）を小さなアイテムに分割することは、すべてのプロダクトオーナーが身につけるべき必須のスキルだ。

前回の記事「より小さなプロダクトバックログアイテムのメリット」では、PBIを小さな価値の単位にスライスすることが重要なのかを探ったが、この記事では、その方法を探っていく。

PBIをどれくらい小さくするべきか

可能な限り小さく、だがそれでいて価値があるものに

プロダクトとは価値を提供する手段である。

スクラムガイド（2020年版）

それぞれのPBIはインクリメンタルな価値を提供するべきである。ケーキを縦にスライスするように考えるべきである。スライスが小さくてもケーキを楽しむことはできるようにだ。

プロダクトとは価値を提供することである。ユーザーや顧客に価値を提供し、ビジネスにも価値を提供するものだ。

この価値を提供するためには、多くの活動を行う必要がある。典型的なソフトウェア開発を例にとれば、次のような活動が挙げられるだろう。

• ユーザー体験（UX）のデザイン
• ユーザーインターフェイス（UI）の作成
• 機能と非機能の詳細な分析や追加
• コードを書き、ピアレビューを行う
• データベースを構築する
• 望まれる機能が期待通りに機能しているかを検証する
• フィーチャーを本番稼働環境にデプロイする
• その他

多くのチームでは、一つの価値を上記のタスクに分解して、タスクをPBIにしようと検討し始める。これはやめてほしい。

確かにこれらの活動は重要であるが、それだけではくユーザーや顧客あるいはビジネスにとって価値を提供したことにはならない。

PBIは、価値の単位であるはずだ。顧客が使うことができるアイテム、真のフィードバックを得るのに役立つアイテムであるべきだ。

プロダクトバックログアイテムを分割する５つの方法

PBIは価値のある単位だ。つまり、顧客が使うことができる具体的なアイテムであるべきであり、プロダクト開発チームが真のフィードバックを得るのに役立つように設計されているものだ。

価値を損なうことなく、小さなPBIを作る方法について説明しよう。

1. ユーザーの役割で分割

仕事を分ける一般的な方法は、異なるユーザーの役割によって分割することだ。ユーザーグループによって、ニーズや問題が違うかもしれないからだ。そうであれば、PBIもこれらを考慮して分割されるべきである。

例えば、eコマースに関連したプロダクトとプロダクトの機能を開発しているとしよう。そこで「ショッピングカート」に焦点を当てているとする。このフィーチャーを「カートを見る」と呼ぶことにする（^{訳註: 原文はBasketだが馴染みのあるカートに替えている}）。

カートの場合、顧客はチェックアウトの前に金額と数量をチェックするだろう。しかし、「カートを見る」機能は、顧客がチェックアウト中に問題を解決するのを手助けするカスタマーサービスチームも使うことができるだろう。

このシナリオでは、両方のユーザーニーズは別のものであり、異なるソリューションが存在する可能性があるのだ。これは、プロダクトチームが「カートを見る」機能を２つのPBIに分割する機会を得たことを意味している。

1. オンライン顧客として、自分のショッピングカートを見たい。それはチェックアウトの前に数量と金額を確認したいからだ。
2. カスタマーサービス担当として、ショッピングカートを見たい。それはチェックアウト時に困っている顧客を手助けするためだ。

どちらのPBIも別々のひとつの価値であり、具体的なニーズを満たすための別のソリューションであるかもしれない。小さくても価値があるのだ。

しかしながら、ここで止めてしまってはいけない。以下の質問をしてみよう。

• 顧客やユーザーには異なる種類があるのだろうか
• もしそうならば、ニーズや問題は他と比べてどうか
• 彼らがプロダクトやシステムに接する方法に違いはないか
• …

2. ワークフローのステップで分割

多くのユーザージャーニーでは、顧客やユーザーを最初から最後まで巻き込むものだ。それは「エンド・ツー・エンドのジャーニー」と呼ばれるように、複数のステップを含むものになる。しかしながら、これらの各ステップがユーザーや顧客に価値を提供し、ビジネスにも価値を提供し得ることを忘れがちでもある。

例えば、以前に学習管理システム（LMS）の開発に関わったが、そこで取り組んだのは、学習者が自分の学習を検証するための試験を受けられるようにする機能であった。

これをユーザーの役割によって分割すると以下のようになる。

• 評価をするトレーナーやコンテンツ作成者
• 知識や学習内容を検証したい学習者
• 学習者の状況について通知を受けたいラインマネージャー

ここで、「知識や学習内容を検証したい学習者」を精査してみよう。このワークフローの典型的なステップは以下になるだろう。

• LSMポータルへ学習者としてログインする
• 実施可能な試験を検索する
• 実施可能な試験に登録する
• 試験を受ける
• 試験の結果を得る

上記のすべてのステップでユーザーに価値を提供している。これらのステップはすべてそれ自体がPBIとなり、さらに分割できる可能性もある。小さくても価値があるのだ。

3. 操作で分割

さまざまなアクションや操作ルールも、多くのフィーチャーに影響を与える。操作ルールは、データやリソースの保存や管理方法に適用することができるからだ。

典型的な操作ルールは以下である。

• Create (C): 新しいレコードを追加する
• Read (R): 既存のレコードを更新せずに取得する
• Update (U): 既存のレコードを更新する
• Delete (D): 既存のレコードを削除する

例えば、人事（HR）システムを開発しているとする。ビジネス操作ルールとポリシーは、PBIを分割する際に役にたつだろう。以下は、より多くの価値の単位につながる質問の例だ。

• 新しい従業員レコードを作成する
  • 誰が行えるか
  • どのように行えるか
  • レコードの作成方法は複数あるのか
  • 一括で作成できるのか
• 従業員レコードを読み取る
  • 誰が従業員レコードを見ることができるのか
  • ラインマネージャーだけが見られる詳細情報とは何か
  • 人事管理者だけが見られる詳細情報とは何か
• 既存の従業員レコードを更新する
  • 従業員レコードを更新できるのはどの役割か
  • ラインマネージャーが更新できるレコードはどこまでか
  • 人事管理者だけが更新できるレコードはどこまでか
• 既存の従業員レコードを削除する
  • 誰が従業員レコードを削除できるのか
  • レコードが削除されるとどうなるのか

上記は、すべて別のPBにすることができる。いくつかの質問に対する回答は、さらに多くのPBIを生み出す可能性がある。小さくても価値があるのだ。

4. シナリオやユースケースで分割

これまで見てきた多くのPBIでは、受入基準が非常に大きく、１つのPBI自体で複数のシナリオやユースケースをカバーしているものがあった。このような大きなPBIには、さらに別の価値の単位に分割する機会があるだろう。

例えば、システムへのログイン機能を開発するとしよう。このタスクは、ユーザーの役割ごとに、そしてさらにシナリオごとに分割することができる。一つのシナリオとしては、ハッピーシナリオだ。つまり、適切なユーザー名とパスワードの組み合わせによってうまくいったログインのケースである。しかし、複数のハッピーシナリオやアンハッピーなシナリオだってある。

• ユーザー名は正しいが、パスワードが間違っている
• ユーザー名が間違っており、パスワードが正しい
• パスワードを忘れてしまった
• 不正な認証情報で複数回試行された
• ログイン情報を記憶する機能
• Googleアカウントでのログイン
• ソーシャルメディア（SNS）でのログイン
• シングルサインオン（SSO）でのログイン

これらのすべてが開発の初期に求められているわけではない。もしかしたら、ほとんど求められないかもしれない。しかし、これらは小さくてもPBIであり、プロダクトオーナーが作業の優先順位をつけるのに役にたつ。小さくても価値があるのだ。

5. ビジネスルールで分割

多くのビジネスやプロダクトでは、さまざまなビジネスルールのもとで仕事が行われている。これらのビジネスルールは別々に実装することもできる。これらすべてのビジネスルールを同時に実装する必要がない場合もあるのだ。

例えば、ユーザーが私のウェブサイト（www.edgeagility.com）でコースを購入したいとする。チェックアウトの際に、英国の付加価値税（VAT）登録業者としては、顧客が英国在住の場合のみ付加価値税（VAT）を請求する必要がある。

これは２つのPBIに分割することできる。

• 付加価値税非課税の顧客のためのジョブストーリー
  • 自分の会社で毎月の経費精算をして財務記録を更新するときに
  • 付加価値税が適用されないことが明記された請求書を受け取りたい
  • それによって、経理プロセスを効率的に行い、財務報告の正確性を確保し、納税義務に関する混乱を避けることができるからだ
• 付加価値税課税の顧客のためのジョブストーリー
  • 自分の会社の仕入れをレビューして、税務申告の準備をするときに
  • 付加価値税の内訳が包括的に記載された請求書を受け取りたい
  • それによって、付加価値税経費を正確に計算し、報告することができ、税務規制を尊重し、財務監査を合理化できるからだ

小さくても価値があるのだ。

ジョブストーリーについては、この記事を参考にしてほしい。

まとめ

プロダクト開発において、PBIを効果的に分割する技術は、単なるスキルではなく、必要不可欠なものだ。大きなアイテムをより小さく、管理しやすい塊に分割することで、明確さと焦点が定まり、よりスムーズなワークフローを促進することができる。

PBIを分割する議論を通じて、主な戦略が明らかになったが、重要なテーマは、「小さくても価値があるのだ」であった。

要するに、PBIの分割をマスターすることは、単にタスクを管理することではなく、チームにチカラを与え、コラボレーションを強化し、最終的には、時間と変化への試練に耐えうる優れたプロダクトを提供することにつながるのだ。だから、リファインメントを続け、イテレーションを繰り返すのだ。プロダクトバックログを皆さんのアジャイルジャーニーを導いてくれる道標にするのだ。

ニュースレター「Vision To Value」を購読して、ユーザー、チーム、組織と、価値を提供するための小さなヒントを毎週共有しましょう。