クオカード デジタルイノベーションラボでプロダクトオーナーをしている齋藤です。
今回はどのようにプロダクトバックログを作っているかを説明します。
主に以下のような情報をもとにプロダクトバックログを作成しています。スピード感を大切にしつつ、一部の声の大きい意見のみに左右されることが無いよう、ユーザーテストなどで本当にその機能を実装した方が良いか確認しながら進めるようにしています。
生成的リサーチ
想定ターゲットにインタビューを行い、現状のペインポイントやゲインポイントとなる部分を確認し機能案を作成します。その後改めてその機能が有用なものかの調査を行う場合もあります。
狩野モデル
不定期にアンケート調査を行い、優先順位づけや実装可否など意思決定のインプットにしています。
社内からのフィードバック
経営陣や営業社員など、社内外からの要望がプロダクトオーナーにSlackで届くようになっているので、こちらもインプットとして利用しています。
エンドユーザーからのフィードバック
コールセンターやアプリのレビューなどを確認しています。
開発チームからの改善提案
テストツールの導入など、主にシステム面の改善提案が上がってきます。開発中に気づいたバグの中で、緊急度が高いもので工数が大きくかからないものはスプリント内で20%程度はスプリント外の作業をすることにしているのでそこで対応、そこで吸収できないものはプロダクトバックログに記載し優先順位を付けて対応しています。
主に上記のインプットをもとに、何をすれば競争優位性が高まるか、また自社のポジショニング的に内部化する必要があるかなどを検討し実現可否や優先順位付けを行なっています。例えばQUOカードPayは個人でも購入できますし個人の方からの購入は大歓迎ですが、メインのターゲットはセールスプロモーションを行う企業になります。その為機能の優先順位を付ける場合はまずセールスプロモーションを行う企業のペインポイントやゲインポイントを考慮し進めています。
作成したプロダクトバックログはジャストインタイムで詳細化しており、長期的なロードマップは作成しないという方針で進めています。競争環境が変化する為、随時優先順位を組み替えて行くべきという背景でそうしています。
失敗した点
「非技術系のステークホルダーにとって、バーティカルスライスは一般に理解したり確認したりするのが容易で、ビジネス価値を評価しやすいものである。バーティカルスライスはチームにとって、リリースを早め、実際のビジネス価値とリアルなユーザーフィードバックを実現するための選択肢を増やすものとなる。」
Steve McConnell. More Effective Agile ソフトウェアリーダーになるための28の道標 (Japanese Edition) (Kindle Locations 2351-2353). Kindle Edition.
上記のようにMore Effective Agileで書かれている通り、スクラム導入時にホリゾンタルスライス(エンドツーエンドで開発を進める形)で進めようとしましたが、今までの進め方がバーティカルスライスだったためスムーズに移行ができませんでした。そのためプロダクトバックログもバーティカルスライスを意識したものになってしまっていました。現在は極力バーティカルスライスで進めるようにしています。
工夫した点
全ての作業をプロダクトバックログで管理する形にすると開発中に見つけた細かいバグや問い合わせなどの対応が全て翌スプリントになってしまうので、スプリントの20%程度はそのような作業に充てる事にしています。ツールやライブラリの調査もその時間を使えるようにしています。