株式会社Holmesで2020年10月よりプロダクトオーナーをしているid:w-miuchiです。
プロダクトオーナー（以下PO）としてプロダクトバックログをどういう観点、手順で作成すべきか考えました。この作成のプロセスを記載いたします。
まだまだ試行段階であることをご了承頂ければと思いますm( )m
About Product Backlog
弊社では現在、アジャイルのスクラムを適用し開発を行っております。
スクラムガイドのPOの欄にはプロダクトバックログについて以下の記述があります。
プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、
- プロダクトゴールを策定し、明示的に伝える。
- プロダクトバックログアイテムを作成し、明確に伝える。
- プロダクトバックログアイテムを並び替える。
- プロダクトバックログに透明性があり、見える化され、理解されるようにする。
https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf
ここにある「透明性」「見える化」「理解される」プロダクトバックログを作成するために、
プロセス化を行い、同じ観点で作られたプロダクトバックログとすることが目的です。
About Epic
弊社では顧客課題、解決すべき課題を記載したドキュメントをEpicと定義しています。
Epicに関しては以下も参考になるかと思います。
Epicはプロダクトマネージャー（以下PM）が管理しておりPMからPOに伝達されています。
今回記載するのはこのEpicからプロダクトバックログに変換を行う際のプロセスになります。
Epic to Product Backlog
User
登場人物の特定を行います。
弊社プロダクトの主な利用者は、法務部や事業部、営業部となります。どの部署のどのポジションの人が利用するか、ペルソナから抽出します。
ただし、機能に特化した改善の場合は必ずしも行う必要がない場合もあります。
Flow
課題周辺に関して、業務や運用のフローを作成します。
アクション単位で作成したり機能単位で作成したり、Epic内容によって様々です。
全体の流れを理解するのを目的としています。
（ここでのフォーマットは決めていません）
詳細はプロダクトバックログアイテム（以下PBI）で記載します。
Data
課題に対して関連するデータの抽出を行います。
利用者数や関連機能の利用回数などを調べ、機能に対するプライオリティ付けの参考とします。
実際には欲しいデータが必ずしも抽出できないこともあり、今後の課題になっています。
Use Case
ここまでのUser, Flow, DataからUse Caseを作成します。
Use Caseは機能ではなく、利用者の課題ベースで考えます。
この理由としては、実装に自由度を持たせることが目的です。あくまでも課題を解決することがゴールであることを意味します。
例) 「リマインド機能を付ける」ではなく「利用者の確認のために再度通知をする
実際にやってみるとUse Caseを作成する際はFlowをUse Case毎に分割していくことになりました。
Image, Wireframe
また同時にImageやWireframeを用意します。
例えば、以下のような粒度のWireframeになります。
弊社のようなWebアプリケーションの場合、画面イメージが必要となります。ここではデザイナーに協力頂き作成を行います。
どこまで詳細に明示するかは都度判断していますが、あくまでも実装される画面ではなくイメージであることを重要としています。
ただし、明確にUIを改善するという顧客課題であれば詳細に作る必要もあるかと考えます。
このプロセスはFlowの作成と並行して行うこともありました。
Agreement
ここまでをMVP（Minimum Viable Product）としてPMと合意をします。
あとはMVPをPBIに分割し開発チームとリファインメントを行うという流れになります。
To close
以上が現在定義しているプロダクトバックログの作成プロセスとなります。
もちろん完成ではなく今後も迷いなくプロダクトバックログを作成できるようにプロセスを改善していきたいと考えています。
今後プロダクトオーナーを目指す方の参考になればと思います。
