2024年6月21日・22日の2日間、Scrum Fest Osaka 2024が開催されました。Scrum Festはスクラムの初心者からエキスパート、ユーザー企業から開発企業、立場の異なる人々が集まる学びの場です。カンファレンスで登壇した伊山宗吉はNTTコムウェアで社内のアジャイル開発の推進、アジャイルコーチを務めており、社外向けエバンジェリスト活動も行っています。今回の講演ではアジャイル開発初心者向けに「プロダクトバックログアイテム（PBI）の改善」をテーマに考え方や取り組みを共有しました。
（講演資料はこちら）※外部サイト

前提

プロダクトバックログアイテム（PBI）は、プロダクトバックログ（PBL）の構成要素であり、1つひとつのPBIにはプロダクトの要求事項や実現したいことが記述されています。PBLの全体像、ビジョンやプロダクトゴールとの整合、優先順位付けなどはとても重要な概念ですが、今回の説明では取り扱いません。あくまでPBIの部分に絞り、その改善をテーマとします。

リリースしたらユーザーからクレームが！

実際の現場で起きた不具合を例に説明をしていきます（具体的なプロダクトや不具合は表現を変更しています）。

このゲームは、石（通貨に相当するもの）を3,000個使うことでガチャを回し、アイテムをゲットできるという仕様です。しかし、ユーザーがガチャを回そうとしたら、保有している石が2,000個しかないため、ガチャを回すには1,000個の石を購入しなければなりません。この場合、ガチャを回せるようになるまでの画面遷移は「ガチャ画面」⇒「ホーム画面」⇒「石の購入画面」⇒「ホーム画面」⇒「ガチャ画面」となっていました。

ユーザーからこの導線が「わずらわしい」という意見がでたので、ユーザビリティ向上の観点でシンプルな導線にするためのアイデアを出しあいました。

Product Owner （PO）からは、「ガチャ画面から石を購入できるようにし、購入後にガチャ画面に戻るようにしたい。ユーザビリティが改善され、今よりも石を購入してもらいやすくなるはず。」という提案がありました。

そして、POが以下のPBIを作成し、開発者は受入基準を明らかにして仕様を決めました。

ここで違和感を持てるかどうか、というところが1つのポイントになります。
違和感の正体については、後述いたします。

開発者は仕様にしたがって開発を進め、ガチャ画面に購入ボタンを設置しました。ユーザーはガチャ画面からすぐに購入画面へ遷移し、戻るボタンでガチャ画面へ戻ることができるようになりました。チームはPBIの受入基準を満たすことができたので、変更内容をリリースしました。しかし、ユーザーからは「石を購入したのに、ガチャ画面では石が不足したままでガチャを回すことができない」というクレームが入りました。

開発プロセスの問題点を探ろう！

では、この不具合の原因はどこにあったのでしょうか。

結論から先に述べると、「データの更新漏れ」がありました。従来の導線ではホーム画面からガチャ画面に遷移する際に、現在の石の所持数を更新していました。これはアプリ内部の変数を更新する処理として実装されていました。

しかし、開発者はこの更新処理の存在を把握していませんでした。新しい導線では、石の購入完了後は直接ガチャ画面へ遷移するため、新たに更新処理を実装する必要がありましたが、実装が漏れてしまったため、購入前の所持数で石が不足していると判定されてしまいました。

実装が誤っていたことはわかりましたが、なぜこの仕様でリリースまで進んでしまったのでしょうか。

バグの混入原因は、アプリの既存機能および仕様の理解不足による実装誤りでした。では、バグの流出原因は何でしょうか。それは、ユースケース観点の試験漏れです。すなわち、石を購入後にガチャを回すまでの試験をしていなかったのです。さらに突きつめると、本来のユーザーの目的や後続操作の考慮不足があったと言えます。

全体を俯瞰してみると、開発プロセスの問題点が見えてきます。まず、PBIを作成する段階で目的や確認範囲の認識ずれがあったと考えられます。さらには既存の仕様認識誤りや考慮漏れ、試験観点やレビュールールの不足などが問題点として挙げられます。

今回はこの事例をもとに、目的や確認範囲の認識ずれを防止することに焦点をあてて、PBIの改善を紹介します。

PBIの問題点とは？

さて、PBIの受入基準確認のプロセスまで戻って、問題点を検証してみましょう。

この事例のPBIでは、目的にあたる「何のために（Why）」が「購入画面へ遷移できること」になっています。そして、「何をしたいか（What）」が「購入ボタンを設置すること」になっており、開発者目線になっているのです。この違和感にPO、開発者が気づいていないことがポイントです。これはさまざまな案件でありがちな状況です。

ユーザーの本来の目的が「ガチャを回す」ことであるが、その目的達成を確認できるような受入基準になっていません。石を購入後にガチャ画面に遷移すれば受入基準を満たし、後続処理は確認不要という認識につながっています。

目的を明らかにすることはとても重要なことであり、PBIで実現したいこと、その理由が明確になっていないと、この事例のようなことが起こります。

PBIを改善しよう！

具体的なPBIの改善ポイントを紹介していきます。

1）ユーザーストーリーの改善

参加しているメンバーがPBIの問題点に気づかなかった原因は、PBIの書き方に問題があったことです。

この事例のPBIで記述したユーザーストーリーは、「誰が」、「何のために」、「何をしたいか」という記述になっています。

しかし、本来のユーザーストーリーは、以下のようなフォーマットで記述することが推奨されています。

あらためてPBIで記述したユーザーストーリーを見直すと、開発者目線でありユーザー目線になっていないことに気づきます。ユーザーの本来の目的は何か、ということを認識して表現することが大切です。

関係者の間で「何のために」という目的を正しく認識し、議論できるようになれば、誤解なくプロダクトバックログの品質が向上します。

さらに、改善後のユーザーストーリーには具体的な実装内容が記述されていないことに注目してください。目的が明確であれば、「購入ボタンの設置」「購入画面へ遷移」以外の手段や、既存の実装を考慮した低コストでの実現方法も提案しやすくなります。

PBIには「本来の目的」を正しく認識し、議論できるようにする重要な働きがあるのです。

2）受入基準等の改善

受入基準や機能を明確化することで、適切な試験範囲や試験方法が見えてきます。

この事例の受入基準を改善すると、次のようになるでしょう。

受入基準だけでなく、デモ内容や試験範囲も具体化することが望ましいと考えます。そのために、最も大切なことは関係者と対話して認識齟齬・考慮漏れを防ぐことです。どこまでの内容を記載するかはチームの成熟度によって異なります。

アジャイル開発では対話が重要！

この事例のような事態を防ぐために、プロダクトバックログの質の向上が重要であることをユーザーストーリー中心に紹介しました。

アジャイルでは対面での対話が非常に重要とされています。そして良い対話を行うためには、PO、開発者、スクラムマスター（SM）との関係が良いことが前提になります。関係が悪いと対話したくない、という状態になり、紹介したような改善が行われづらい状況を生み出します。

現場でありがちなのが、「POからの要求過多により、開発者が開発作業を優先し、議論に時間を割かない」、「不具合が起こった時に責任を押しつけ合う」、「言われたことをやっていれば自分たちの責任にはならないので、自分たちから踏み込まない」といったことです。このような当事者意識の欠如が関係を悪くし、対話をしないことにつながっていきます。

ユーザーへの価値提供、ビジネスやチームの成長には適切な対話が必要であり、メンバー全員がチームの雰囲気作りに気を配ることの大切さを改めて認識していく必要があります。

今回は初心者向けに事例を紹介しましたが、長く開発しているチームでもPBIの質が低い事例が見受けられます。その場合も多くは適切な対話ができていません。今一度、自分たちのチームでも適切な対話ができているか、振り返ってみてほしいと思います。

繰り返しになりますが、重要なのは対話を通じて内容を具体化し、関係者間で共通認識をもつことです。そのためには日頃から現場で良好な関係を構築していかなければなりません。特にSMはチームの状況に気を配り、改善に取り組むことが期待されます。