【🎁 テンプレート配布】Notion でプロダクトバックログを運用する （2022年版）

こんにちは。Notion アンバサダーの 円谷 です。

今週のマガジンでは、僕の会社で運用している Notion のプロダクトバックログの解説記事です。1年以上前に「【Notion × スクラム開発】プロダクトバックログとスプリントバックログを運用する」という記事を書いたのですが、1年間運用を重ねて、データベースがブラッシュアップされ、 また、Notion 自体にも機能追加がかなり加わり、よりパワーアップしました。ということで、今回の記事は1年前の記事のレベルアップ版になります。

記事の最後には、例によってテンプレートのリンクを貼っておきました。もしよろしければ複製してお使いください。

🔥 会社で運用してるプロダクトバックログをテンプレート化してる。GW 中には整えきって解説付きで公開する予定……！！！！！やるぞ……！！！！！！！ pic.twitter.com/nQt0lK2GGL

— Yuji Tsuburaya (@___35d) May 1, 2022

Notion を用いたプロダクト開発のワークフロー

僕の会社の Notion を使った開発ワークフローをざっくりと図にしました。

Notion を用いたリリースまでのワークフローの図式化

この記事では、アイデアを Notion に書き起こすところ（起票）から、実際にコードを書いて実装をし、リリースするところまでを解説していきたいと思っています。

スクラム開発をベースにしたワークフローになっているので、ところどころ専門用語が出てくるのですが、なるべくスクラム開発を知らない人にも理解できるように噛み砕いて解説していく予定です。

データベース構造の関連図

開発に使うデータベースは「プロダクトバックログ DB」「開発バックログ（タスク）DB」「リリース DB」の3つで、以下の図は、データベース間の連携を表したものです。

実際に会社で運用しているデータベースは、アサインするメンバー・チーム名等のデータベースがリレーションでもう少し複雑絡み合っているのですが、今回は記事用にエッセンスのみを抽出して簡略化しています。テンプレートも簡略化したものを準備しました。

開発に使うデータベースの関連図

プロダクトバックログと開発バックログは 1:N、リリース DB とプロダクトバックログも 1:N の関係で紐付いています。それぞれの DB の詳しい解説はこのあとの章で詳しく解説していきます。

プロダクトバックログ：開発予定のアイテムを全て格納したデータベース

プロダクトバックログのスクリーンショット

プロダクトバックログは、今後、開発予定のアイテムを全て格納したデータベースで、社員全員が起票できるような仕組みになっています。（プロダクトバックログの1つ1つのデータをこの記事では「アイテム」と呼ぶことにします）

アイデアベースのアイテムから、要望ベースの抽象度が高いアイテム、実装方法までイメージがわいている具体度が高いアイテムまで様々です。そのバラバラな状態のアイテムを、開発可能な状態にするために、以下のような内容を議論します。

• どのくらい価値がある？

• そもそも作るべきもの？

• やるとしたらどのくらい時間かかる？

• どんな UI/UX になる？

議論を通し、メンバー間での認識ズレをなくし、アイテムの解像度を上げていきます。アイテムの解像度を上げた上で、どのアイテムから開発に着手するのかを決定しています。この作業を「リファインメント」と呼んでいます（ここも詳しくは後ほどの章で解説します）

起票：テンプレートから呼び出し

プロダクトバックログのアイテム起票は、エンジニア以外にも、マーケ・セールスの方が担当することも多々あります。役割の異なる方が起票すると抽象度があまりにバラバラになってしまうので、なるべくアイテムの内容を揃えるために、テンプレートからアイテムを作る運用にしています。

Notion の機能でワンクリックでテンプレートを呼び出すことができるようにしている

「New!!」というテンプレートを準備していて、ここのボタンを押すことで、テンプレートを呼び出すことが可能です。テンプレート内では、「解決したい課題」「達成したい状況・KPI」「必要な機能（How）」を入力するようにフォーマット化されていて、最低限「課題」の部分だけは記入するように運用ルールを敷いています。

プロダクトバックログアイテムは、頭の中に思いついた解決策を書いてしまいがちなのですが、課題を書くのが鉄則で、テンプレートにもその旨が強く記載されています。テンプレートに沿って記入することで、粒度の統一されたプロダクトバックログになります。

PRD テンプレート

📝 ちなみにこの PRD テンプレートは Notion テンプレートギャラリーの Shin Sasaki さん作のフォーマットを参考に作成しました（ありがとうございます）

https://www.notion.so/ja-jp/templates/プロダクトマネージャーWiki

Shin Sasaki さんのプロダクトマネージャー Wiki を参考にさせていただきました

リファインメント：起票確認・優先度の並び替え

起票されたプロダクトバックログアイテムを週に一度メンテナンスしています。このメンテンナスの場のことを「リファインメント」と呼んでいます。リファインメントでは主に、「1. 新しく起票されたアイテムの確認」「2. 優先度の並べ替え」の2つを実施しています。それぞれ詳しく見ていきましょう。

1. 新しく起票されたアイテムの確認

新しく起票されたアイテムの確認を行い、課題感の共通認識を取ります。うちの会社だと基本的に、ビジネスサイドからの要望が多く、まだ要件が固まりきっていない状態なので、ざっくりとした要望をヒアリングし、具体化していくプロセスを踏んでいきます。（ここがプロダクトマネージャーの腕の見せ所）そもそもこれって何のためにやるんだっけ？（目的）を議論しつつ、どう解決していくかの認識合わせをして合意を取っていきます。ここがズレるとせっかく作っても価値が低い・もしくはないものが出来てしまうので注意が必要です。

インパクトとポイントを5段階で入力する

チーム内で課題感・解決策案の共通認識が取れたら「インパクト」と「ポイント」を入力します。それぞれ5段階で表現することにしています。ここまでの入力が完了したら、ステータスを New!! から ToDo へと変更します。

• インパクト：この課題を解決したらどのくらいの価値があるのかを表現したプロパティ

• ポイント：この解決策を実現するのにどのくらいの作業量（難易度や実装工数）がかかるのかを表現したプロパティ

📝 コラム：この段階で、会話を通して「やっぱり作らなくて良いよね」となることも多いです。何を作らないかについて合意を取るのも、リファインメントの大切な役割です。「作らなくて良い」という合意が取れたものは、ToDo ではなく Archived というステータスに変更しています。

2. 優先度付け

リファインメントのもう一つ大切な役割が優先度付けです。ここは各社色々なやり方があると思いますが、うちの会社では、リファインメント用のボードビューを準備していて、ドラッグ＆ドロップで順番を入れ替えることで優先度の入れ替えを行います。

リファインメント用ボードビューは、リリース管理のデータとタスクの進捗ステータスでそれぞれグループ・サブグループ化しており、マトリクス形式で表現しています。

ドラッグアンドドロップで入れ替えを行う

基本的に、インパクトが大きく、ポイントが小さいもの（ROI が高いもの）を優先度が高いアイテムとして早く処理していきますが、イレギュラーで、これはインパクトは小さいけど簡単（ポイントが小さい）から差し込みでやっちゃおう、みたいな意思決定をしたりもします。

コラム：1年前に Notion × スクラム開発の記事を書いたときは、サブグループ機能がなかったので、テーブルビューの順番に意味をもたせて頑張っていたのですが、いまはサブグループ機能の登場で、リファインメントの工数がぐっと減りました。（ありがとう Notion ）

👀 自分が1年前に書いた Notion 記事を読み返してるけどかなり面白いな。当時はサブグループ機能がなくて、かなりツラみ感じつつ運用で頑張って解決してる。過去の自分に伝えてあげたい、サブグループ機能が出て、、、幸せになれるよ、、、

— Yuji Tsuburaya (@___35d) May 3, 2022

プランニング

ここまでのリファインメントの作業で、どの課題を、ざっくりいつ解決するのかが決まった状態になっています。

言語化された課題を、実装可能な状態（タスク）に落とし込んでいく作業がプランニングです。プランニングでは、リファインメントで言語化された課題と解決策に対し、どのようなアクションを取れば課題が解決できるのかを考えて、タスクの作成・アサインをおこなっていきます。

と言いつつ、都度都度考えると言うよりは、僕たちの会社は Web プロダクトの企業なのである程度型が決まっていて、「デザイン」「フロントエンド実装」「バックエンド実装」みたいな粒度のタスクになることが多いです。

また、メンバーの稼働状況等を鑑みて、そのスプリント（僕たちは1週間）の間に、タスクが完了するのかのざっくり見積もりを行います。見積もりの結果、次のスプリントに回すとかの調整をこのタイミングで行います。

タスクの起票とアサイン（どのメンバーがタスクに責任を負うか）が完了したらプランニングは完了です。

課題解決に責任を負うのはプロダクトオーナーで、タスクの遂行に責任を負うのはメンバー（主に開発者）という立ち位置になります。

プランニングでは、課題と関連した子タスクを起票する

開発バックログ（タスク DB）について

プロダクトバックログと開発バックログの関係性（再掲）

プランニングで起票されたタスクの集合体が開発バックログ（タスク DB）になります。

開発バックログ DB は、うちの会社ではタスク DB とも呼ばれており、会社全体の全メンバーが使用するタスク用のデータベースと同じデータベースを使用しています。開発者以外も使う DB なのですが、今回は開発者目線の話にスコープを絞って書いていきます。

メンバー：かんばんボードで進捗管理

自分のタスクのみでフィルタをかけたかんばんボード

開発バックログ DB（タスク DB）は、エンジニアに限らず、会社の全メンバーが使用するタスク用のデータベースです。メンバーは、自分のホームページに、かんばんボード形式のリンクドビューでタスク DB を配置し、自分がアサインされているものフィルタがかけられたビューで進捗管理を行います。

マネジメント：Formula を使った進捗状況の可視化

グラフ形式で進捗率を可視化

プロダクトバックログ側でもおおまかな進捗管理をできるようにして、グラフっぽい表現で見える化しています。これは、子タスクの総数と Done になった子タスクの数の割合を示したもので、Formula で実現するようにしています。

数式が少し複雑なのと、Notion の中でも難易度の高い Rollup 機能が使われているので、ここはテンプレートを複製してそのまま使うのをオススメします

進捗率を表す Formula

リリース管理 DB

リリース管理 DB とプロダクトバックログ DB の関係図（再掲）

さいごに紹介するのが、リリース管理 DB です。