フィードバックは選別して一旦プロダクトバックログの末尾に入れる

みなさんこんにちは。@ryuzeeです。

ここに新しくECサイトを作ろうとしているアジャイル開発チームが2つあったとします。期間はどちらも同じです。 1つめのサイトAは、商品を探すための機能として、商品名による検索、価格による検索、発売元メーカーによる検索、評価順による検索、あいまい検索などさまざまな検索機能を用意しましたが、もう1つのサイトBには商品名による検索しかありませんでした。さてどちらが良いでしょうか。

答えは当然ですが、「これだけでは分からない」になります。

ちょっと条件を追加しましょう。サイトAは、いろいろな検索方法で商品を探せますが、残念ながら決済機能の開発が間に合わなかったので、まだ商品の購入はできません。一方で、サイトBはクレジットカード（JCBとVISAだけ）は決済できるようになっています。さて、こうなるとどちらが良いでしょうか。

答えは明確にサイトBになります。サイトAでは、そもそも利用者が商品を買いたいというニーズを解決できていません。

サイトA（特定の機能は充実しているが全体としては役にたたない）

サイトB（機能は少ないが全体としては役にたつ）

つまり重要なのは、個々の機能の深掘りの度合いや詳細さや便利さではなく、そもそも全体としてみたときに解こうとしていた問題を解決できるかどうかです。

（上の図はユーザーストーリーマッピングという見える化の方法です。詳しくは書籍が出ているので読んでみるとよいと思います。）

スプリントレビューでのフィードバックの捉え方

スクラムではスプリントごとにスプリントレビューを行います。スプリントレビューにはプロダクトの関係者をあつめて、作っているものに対するフィードバックを貰ったり、今後の戦略や見通しを共有したりします。

このとき、実際に動作するプロダクトを見ると、さまざまな意見が出ます。このプロダクトには無くて競合プロダクトにある機能についての指摘、機能の改善の提案、操作性やデザインに対する提案、場合によっては、これじゃ使いにくいというクレームのようなものも出るでしょう。

ステークホルダーが上司やほかの部門の偉い人だったり、経営者だったり、発注者だったりすると、「これらのフィードバックにすぐに対応しなければいけない」と思い込んでしまう力がプロダクトオーナーに対して働きやすくなります（残念ながら、なぜかレビューの場でプロダクトオーナーが「すぐ直します」などと宣言してしまうのを見かけることもあります）。

しかし、直近に作ったものに対するフィードバックに対してすぐにとりかかることは危険です。理由は最初に出した例のとおりで、こういったフィードバックを真に受けて着手の順番を上げてしまうと、いつまでたっても全体として役にたつ状態にはならず、リスクだけが積み上がっていくからです。

フィードバックは選別が必要

プロダクトにはプロダクト固有の考え方があります。やること・やらないことについての思想を決めておくこともあります。フィードバックは重要ですが、すべてのフィードバックが役に立つというのは幻想です。立場が上の人が出したフィードバックだからといって価値があるとは限りません。お金を出している人のフィードバックだからといって価値があるとは限りません。つまり、フィードバック自体の中身を踏まえて、必要なものと不要なものとに選別する必要があります。

プロダクトオーナーの仕事は、限られた時間やリソース、予算の中で、最大の成果をあげることです。 プロダクトオーナーは無駄なものを作らないようにし、はっきりと「No」を言うことが重要になります。

選別したフィードバックはまずプロダクトバックログの末尾に入れる

選別したフィードバックはプロダクトバックログアイテムとして追加しますが、一旦はすべて末尾に入れます（INBOXという領域を作って、そこに入れることもあります）。そのあとにプロダクトバックログの全体を見ながら、どの程度の順位にするか考えます。

人間の習性として「いま思いついたアイデアは良いものに見える」という傾向があります。したがって、選別の結果残ったフィードバックは妥当なものとしてすぐに取り入れたくなります。しかし**「いま思いついたアイデアが後になっても良いアイデアだった」ことは少ないので、冷静な判断が必要**です。デフォルトでしばらく寝かせておくくらいで丁度よいはずです。

あとは、プロダクトバックログリファインメントなどで、全体をみながら適宜順番を見直していくと良いでしょう。

並び順の考え方は、以下の観点の組み合わせになります。