ContractS開発者ブログ

契約マネジメントシステム「ContractS CLM」の開発者ブログです。株式会社HolmesはContractS株式会社に社名変更しました。

顧客課題をプロダクトバックログに変換するプロセス-Alpha

株式会社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に関しては以下も参考になるかと思います。

www.atlassian.com

Epicはプロダクトマネージャー(以下PM)が管理しておりPMからPOに伝達されています。

今回記載するのはこのEpicからプロダクトバックログに変換を行う際のプロセスになります。

Epic to Product Backlog

f:id:w-miuchi:20201207140259j:plain

User

登場人物の特定を行います。
弊社プロダクトの主な利用者は、法務部や事業部、営業部となります。どの部署のどのポジションの人が利用するか、ペルソナから抽出します。
ただし、機能に特化した改善の場合は必ずしも行う必要がない場合もあります。

f:id:w-miuchi:20201207140545j:plain

Flow

課題周辺に関して、業務や運用のフローを作成します。
アクション単位で作成したり機能単位で作成したり、Epic内容によって様々です。
全体の流れを理解するのを目的としています。
(ここでのフォーマットは決めていません) 詳細はプロダクトバックログアイテム(以下PBI)で記載します。

f:id:w-miuchi:20201207140852j:plain

Data

課題に対して関連するデータの抽出を行います。
利用者数や関連機能の利用回数などを調べ、機能に対するプライオリティ付けの参考とします。
実際には欲しいデータが必ずしも抽出できないこともあり、今後の課題になっています。

Use Case

ここまでのUser, Flow, DataからUse Caseを作成します。
Use Caseは機能ではなく、利用者の課題ベースで考えます。
この理由としては、実装に自由度を持たせることが目的です。あくまでも課題を解決することがゴールであることを意味します。

例) 「リマインド機能を付ける」ではなく「利用者の確認のために再度通知をする

実際にやってみるとUse Caseを作成する際はFlowUse Case毎に分割していくことになりました。

Image, Wireframe

また同時にImageWireframeを用意します。
例えば、以下のような粒度のWireframeになります。

f:id:w-miuchi:20201207170226j:plain

弊社のようなWebアプリケーションの場合、画面イメージが必要となります。ここではデザイナーに協力頂き作成を行います。
どこまで詳細に明示するかは都度判断していますが、あくまでも実装される画面ではなくイメージであることを重要としています。
ただし、明確にUIを改善するという顧客課題であれば詳細に作る必要もあるかと考えます。 このプロセスはFlowの作成と並行して行うこともありました。

Agreement

ここまでをMVP(Minimum Viable Product)としてPMと合意をします。
あとはMVPをPBIに分割し開発チームとリファインメントを行うという流れになります。

To close

以上が現在定義しているプロダクトバックログの作成プロセスとなります。
もちろん完成ではなく今後も迷いなくプロダクトバックログを作成できるようにプロセスを改善していきたいと考えています。
今後プロダクトオーナーを目指す方の参考になればと思います。