2024-11-05円谷こんにちは。今週は、会社で運用しているプロダクトバックログをテンプレート化したので、それについて書いていきたいと思います。自体もカイゼンがかなり加わったので、今回の記事はそのレベルアップ版になります。記事の最後には例によってテンプレートを準備しておきました。よろしければ複製してお使いください。使った弊社の開発ワークフローをざっくりと図にしました。書き起こすところ(起票)から、実際にコードを書いて実装をし、リリースするところまでを解説していきたいと思っています。スクラム開発をベースにしたワークフローになっているので、ところどころ専門用語が出てくるのですが、なるべくスクラム開発を知らない人にも理解できるように噛み砕いて解説していきます。以下の図は、データベース間の連携を表したもので、実際の運用しているデータベースはアサインするメンバーや、チームのデータベースがリレーションでもう少し複雑絡み合っているが、今回は記事用にエッセンスのみを抽出して簡略化しました。関係で紐付いています。解説はこのあと詳しく解説していきます。プロダクトバックログの解説プロダクトバックログのスクリーンショットプロダクトバックログは、今後、開発予定のアイテムを全て格納したデータベースで、社員全員が起票できるような仕組みになっています。(プロダクトバックログの1つ1つのデータをこの記事では「アイテム」と呼ぶことにします)アイデアベースのアイテムから、要望ベースの抽象度が高いアイテム、実装方法までイメージがわいている具体度が高いアイテムまで様々です。なる?のようなことを議論して、解像度を上げて粒度を揃えていきます。粒度を揃えた上で、どのアイテムから開発に着手するのかを決定しています。」と呼んでいます(詳しくは後述します)起票:テンプレートから呼び出しプロダクトバックログのアイテム起票は、エンジニア以外にもマーケ担当の方やセールス担当の方が担当することも多々あります。役割の異なる方が起票すると抽象度があまりにバラバラになってしまうので、なるべくアイテムの内容を揃えるために、テンプレートからアイテムを作る運用にしています。機能でワンクリックでテンプレートを呼び出すことができる「New!!」というテンプレートを準備していて、ここのボタンを押すことで、テンプレートを呼び出すことが可能です。テンプレート内では、「解決したい課題」「達成したい状況・KPI」「必要な機能(How)」を入力するようにフォーマット化されていて、最低限「課題」の部分だけは記入するように運用ルールを敷いています。プロダクトバックログアイテムは、頭の中に思いついた解決策を書いてしまいがちなのですが、課題を書くのが鉄則で、テンプレートにもその旨が強く記載されています。テンプレートに沿って記入することで、粒度の統一されたプロダクトバックログになります。参考にさせていただきましたリファインメント:起票確認・優先度の並び替え起票されたプロダクトバックログアイテムを基本的には週に一度メンテナンスしています。このメンテンナスの場のことを「リファインメント」と呼んでいます。優先度の並べ替え」の2つを実施しています。それぞれ詳しく見ていきましょう。新しく起票されたアイテムの確認を行い、課題感の共通認識を取ります。うちの会社だと基本的に、ビジネスサイドからの要望が多く、まだ要件が固まりきっていない状態なので、ざっくりとした要望をヒアリングし、具体化していくプロセスを踏んでいきます。(ここがプロダクトマネージャーの腕の見せ所)そもそもこれって何のためにやるんだっけ?(目的)を議論しつつ、どう解決していくかの認識合わせをして合意を取っていきます。ここがズレるとせっかく作っても価値が低い・もしくはないものが出来てしまうので注意が必要です。起票者とプロダクトマネージャーの間での課題感・解決策案の共通認識が取れたら、「インパクト」と「ポイント」を入力します。インパクトは、この課題を解決したらどのくらいの価値があるのかを表現したプロパティ、ポイントは、この解決策を実現するのにどのくらいの作業量(難易度や実装工数)がかかるのかを表現したプロパティで、それぞれ5段階で表現することにしています。📝コラム:この段階で、会話を通して「やっぱり作らなくて良いよね」となることも多いです。作らなくて良いものの合意を取るのも、リファインメントの大切な役割です。いうステータスに変更しています。優先度付けリファインメントのもう一つ大切な役割が優先度付けです。ここは各社色々なやり方がありますが、うちの会社では、リファインメント用のボードビューを準備していて、ドラッグ&ドロップで順番を入れ替えることで優先度の入れ替えを行います。リリース管理のデータでグループ化(縦軸:後述します)、タスクの進捗ステータスでサブグループ化(横軸)で、マトリクス形式で表現しています。ドラッグアンドドロップで入れ替えを行う基本的にインパクトが大きく、ポイントが小さいものを優先度が高いアイテムとして処理していきますが、イレギュラーで、これはインパクトは小さいけど簡単(ポイントが小さい)から差し込みでやっちゃおう、みたいな意思決定をしたりもします。スクラム開発の記事を書いたときは、サブグループ機能がなかったので、テーブルビューの順番に意味をもたせて頑張っていたのですが、いまはサブグループ機能の登場で、リファインメントの工数がぐっと減りました。)プランニングここまでのリファインメントの作業で、どの課題をいつ解決するかが決まった状態になっているので、それを実際に実装可能な状態にしていきます。リファインメントで言語化された課題と解決策に対し、どのようなアクションを取れば課題が解決できるのかを考えて、タスクを作成していくのがプランニングの役割です。プロダクトの企業なのである程度型が決まっていて、「デザイン」「フロントエンド実装」「バックエンド実装」みたいな粒度のタスクになることが多いです。タスクの起票とアサイン(どのメンバーがタスクに責任を負うか)が完了したらプランニングは終了です。課題解決に責任を負うのはプロダクトオーナーで、タスクの遂行に責任を負うのはメンバー(主に開発者)という立ち位置になります。DB)は、エンジニアに限らず、会社の全メンバーが使用するタスク用のデータベースです。配置し、自分がアサインされているものフィルタがかけられたビューで進捗管理を行います。見て進捗を管理していたのですが、チームメンバーが増えていくにつれ、全員のタスク状況を確認するのには管理コストが大きくなってくるという課題が発生しました。そこで、プロダクトバックログ側でも大まかな進捗管理をできるようにして、グラフっぽい表現で見える化しました。このデータベースもここまでで何度か登場していますが、毎週のリリース成果物を管理するデータベースです。載る」みたいな感じで管理されています。紐づくようにになっています。ドラッグアンドドロップで入れ替えを行うと、リリース日が自動で変更される(再掲)ベロシティの計測ベロシティの可視化プロダクトバックログアイテムにポイントを付けているという話をリファインメントの解説時にしましたが、このポイントを数値に変換した値のことを「ベロシティ」と呼んでいます。機能でベロシティを算出しています。このベロシティの値がスプリントごとに安定していれば、チームの生産性は安定しているし、不安定な場合は、開発プロセスのどこかに問題があることを示すバロメータになってくれたりします。プランニング時にも、過去のベロシティの値からそのスプリント内でタスクが終わるかどうかの予測を立てることができます。テンプレートですが、まだ僕自身満足が行っているかと言われると全然そんなことはなく「これが実現できたら良いのにな〜」と思っているところも沢山あります。メモ的に書き残しておきます。引用バーンダウンチャートは表現することができていません。着手できない、のようなタスク同士の依存関係を表現することができていません。使ってプロダクトバックログを運用する記事を書いてみました。想像以上に壮大な記事となってしまいましたが、自分たちの会社でおこなっているプロダクトバックログ管理を言語化できる良い機会となりました。僕の会社で1年以上運用に載せて、カイゼンを繰り返した現在(2022年5月時点)の状態のスナップショットを取り、テンプレート化しました。よければ複製して参考にしてみてください。このままテンプレートの状態で運用に載るかは会社やチームの規模感にもよると思うので、適宜修正して使ってもらえればと思います。プロダクトバックログの事例がまだ少ないような気がしているので、この記事が世のプロダクトマネージャー、もしくはエンジニアの方の参考になれば幸いです。最後までお読み頂きありがとうございました。大学」を運営しています。会員数は現在300名以上。過去の有料記事・有料テンプレートが全て閲覧可能コンテンツや特典盛りだくさんです。参加方法は下記の記事をご覧ください。発信活動をおこなっている。使ったアプリケーションを開発中。