最新情報から便利な使い方まで。Notion 情報に特化した Web メディア。

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

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

今週は、会社で運用しているプロダクトバックログをテンプレート化したので、それについて書いていきたいと思います。1年以上前に「【Notion × スクラム開発】プロダクトバックログとスプリントバックログを運用する」という記事を書いたのですが、1年間運用を重ねて Notion 自体もカイゼンがかなり加わったので、今回の記事はそのレベルアップ版になります。

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

目次

Notion を用いたプロダクト開発のワークフロー・データベース構造の関連図データベース構造の関連図プロダクトバックログの解説起票:テンプレートから呼び出しリファインメント:起票確認・優先度の並び替え1. 新しく起票されたアイテムの確認2. 優先度付けプランニング開発バックログ(タスク DB)についてメンバーが開発バックログで進捗管理を行う(かんばんボード)Formula を使った進捗状況の可視化とマネジメントリリース管理 DBベロシティの計測できていないこと・今後の課題バーンダウンチャートタスク間の依存関係の整理さいごに・テンプレート配布

Notion を用いたプロダクト開発のワークフロー・データベース構造の関連図

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

Notion を使った弊社の開発ワークフローをざっくりと図にしました。この記事では、アイデアを Notion に書き起こすところ(起票)から、実際にコードを書いて実装をし、リリースするところまでを解説していきたいと思っています。スクラム開発をベースにしたワークフローになっているので、ところどころ専門用語が出てくるのですが、なるべくスクラム開発を知らない人にも理解できるように噛み砕いて解説していきます。

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

開発に使うデータベースは「プロダクトバックログ DB」「開発バックログ(タスク)DB」「リリース DB」の3つです。以下の図は、データベース間の連携を表したもので、実際の運用しているデータベースはアサインするメンバーや、チームのデータベースがリレーションでもう少し複雑絡み合っているが、今回は記事用にエッセンスのみを抽出して簡略化しました。

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

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

プロダクトバックログの解説

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

プロダクトバックログは、今後、開発予定のアイテムを全て格納したデータベースで、社員全員が起票できるような仕組みになっています。(プロダクトバックログの1つ1つのデータをこの記事では「アイテム」と呼ぶことにします)アイデアベースのアイテムから、要望ベースの抽象度が高いアイテム、実装方法までイメージがわいている具体度が高いアイテムまで様々です。そのバラバラな状態のアイテムを、開発可能な状態にするために、

  • どのくらい価値がある?
  • そもそも作るべきもの?
  • やるとしたらどのくらい時間かかる?
  • どんな UI/UX になる?

のようなことを議論して、解像度を上げて粒度を揃えていきます。粒度を揃えた上で、どのアイテムから開発に着手するのかを決定しています。この作業を「リファインメント」と呼んでいます(詳しくは後述します)

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

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

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

「New!!」というテンプレートを準備していて、ここのボタンを押すことで、テンプレートを呼び出すことが可能です。テンプレート内では、「解決したい課題」「達成したい状況・KPI」「必要な機能(How)」を入力するようにフォーマット化されていて、最低限「課題」の部分だけは記入するように運用ルールを敷いています。プロダクトバックログアイテムは、頭の中に思いついた解決策を書いてしまいがちなのですが、課題を書くのが鉄則で、テンプレートにもその旨が強く記載されています。テンプレートに沿って記入することで、粒度の統一されたプロダクトバックログになります。

PRD テンプレート
PRD テンプレート
📝

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

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

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

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

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

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

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

起票者とプロダクトマネージャーの間での課題感・解決策案の共通認識が取れたら、「インパクト」と「ポイント」を入力します。インパクトは、この課題を解決したらどのくらいの価値があるのかを表現したプロパティ、ポイントは、この解決策を実現するのにどのくらいの作業量(難易度や実装工数)がかかるのかを表現したプロパティで、それぞれ5段階で表現することにしています。ここまでの入力が完了したら、ステータスを New!! から ToDo へと変更します。

📝

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

2. 優先度付け

リファインメントのもう一つ大切な役割が優先度付けです。ここは各社色々なやり方がありますが、うちの会社では、リファインメント用のボードビューを準備していて、ドラッグ&ドロップで順番を入れ替えることで優先度の入れ替えを行います。リリース管理のデータでグループ化(縦軸:後述します)、タスクの進捗ステータスでサブグループ化(横軸)で、マトリクス形式で表現しています。

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

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

📝

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

プランニング

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

と言いつつ、都度都度考えると言うよりは、僕たちの会社は Web プロダクトの企業なのである程度型が決まっていて、「デザイン」「フロントエンド実装」「バックエンド実装」みたいな粒度のタスクになることが多いです。タスクの起票とアサイン(どのメンバーがタスクに責任を負うか)が完了したらプランニングは終了です。

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

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

開発バックログ(タスク DB)について

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

プランニングで起票されたタスクの集合体が開発バックログ(タスク DB)になります。開発バックログ DB(タスク DB)は、会社全体の全メンバーが使用するタスク用のデータベースで、開発者以外も使用するが、今回は開発者目線の話に限定して解説していきます

メンバーが開発バックログで進捗管理を行う(かんばんボード)

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

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

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

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

いままで僕は、タスクの進捗をメンバーのタスク管理 DB を見て進捗を管理していたのですが、チームメンバーが増えていくにつれ、全員のタスク状況を確認するのには管理コストが大きくなってくるという課題が発生しました。そこで、プロダクトバックログ側でも大まかな進捗管理をできるようにして、グラフっぽい表現で見える化しました。これは、子タスクの総数と Done になった子タスクの数の割合を示したもので、Formula で実現できている(数式がちょっと複雑なのと、Notion の中でもちょっと難易度の高いロールアップ機能が含まれているので、テンプレートを複製してそのまま使うのをオススメします)

進捗率を表す Formula
進捗率を表す Formula

リリース管理 DB

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

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

このデータベースもここまでで何度か登場していますが、毎週のリリース成果物を管理するデータベースです。リリース DB とプロダクトバックログ DB は 1:N で紐付いており、たとえば、「5/4 リリースの成果物には機能A、機能B、機能C が載る」みたいな感じで管理されています。リファインメント時のドラッグアンドドロップで、自動でリリース DB と紐づくようにになっています。

ドラッグアンドドロップで入れ替えを行うと、リリース日が自動で変更される(再掲)
ドラッグアンドドロップで入れ替えを行うと、リリース日が自動で変更される(再掲)

ベロシティの計測

ベロシティの可視化
ベロシティの可視化

プロダクトバックログアイテムにポイントを付けているという話をリファインメントの解説時にしましたが、このポイントを数値に変換した値のことを「ベロシティ」と呼んでいます。そのスプリントで達成(リリース)できたタスクから Formula 機能でベロシティを算出しています。このベロシティの値がスプリントごとに安定していれば、チームの生産性は安定しているし、不安定な場合は、開発プロセスのどこかに問題があることを示すバロメータになってくれたりします。また、プランニング時にも、過去のベロシティの値からそのスプリント内でタスクが終わるかどうかの予測を立てることができます。

けっこう愚直な数式を組み立てています(使う場合はテンプレートからコピペしていただくのをオススメします)
けっこう愚直な数式を組み立てています(使う場合はテンプレートからコピペしていただくのをオススメします)

できていないこと・今後の課題

1年間の運用を通してブラッシュアップしつづけた Notion のテンプレートですが、まだ僕自身満足が行っているかと言われると全然そんなことはなく「これが実現できたら良いのにな〜」と思っているところも沢山あります。メモ的に書き残しておきます。今後の Notion アップデートや、便利なサードパーティー製のツールで実現できるようになっていくと良いなと思っている

バーンダウンチャート

バーンダウンチャートは表現することができていません。Notion 上ではグラフを描画することはできないので、サードパーティ製のツールを組み合わせればできるのかもですが、まだ試せてないのが現状です(運用してる方もしいれば教えて下さい)

タスク間の依存関係の整理

タスクA が終わらないとタスクB が着手できない、のようなタスク同士の依存関係を表現することができていません。これは Self Relation で頑張ればできるのかな(よく分かってないので詳しい方・実際に運用している方もしいれば教えて下さい)

さいごに・テンプレート配布

ということで今回は Notion を使ってプロダクトバックログを運用する記事を書いてみました。想像以上に壮大な記事となってしまいましたが、自分たちの会社でおこなっているプロダクトバックログ管理を言語化できる良い機会となりました。

僕の会社で1年以上運用に載せて、カイゼンを繰り返した現在(2022年5月時点)の状態のスナップショットを取り、テンプレート化しました。もしよければ複製して参考にしてみてください。このままテンプレートの状態で運用に載るかは会社やチームの規模感にもよると思うので、適宜修正して使ってもらえればと思います。(感想も聞かせてください!)

▷ プロダクトバックログ テンプレートページ【2022年版】

日本では Notion × プロダクトバックログの事例がまだ少ないような気がしているので、この記事が世のプロダクトマネージャー、もしくはエンジニアの方の参考になれば幸いです。同じことをしている方が周りにぜんぜんいなくて寂しいので、もし同じようなことやられている方いたら情報交換しましょう!誰のも参考にせずマイ・ウェイを突き進んできてしまったので、インプットがしたいなと最近けっこう強くおもっていますw 最後までお読み頂きありがとうございました。

💡

初学者からでも安心して Notion を学べるオンラインコミュニティ「Notion 大学」を運営中。Notion コミュニティとしては国内最大規模で、会員数は現在200名以上となっております。

  • 分からないことは24時間チャットツールでいつでも質問できる
  • コミュニティ内の限定勉強会でタスク管理や知識管理術が学べる
  • 1から学べる Notion 学習ロードマップで初心者からでも学習可能
  • Notion 大学限定の学習動画が100本以上
  • 定期的に開催している有料セミナーへの無料参加券
  • 過去の有料記事・有料テンプレートが全て閲覧可能

コンテンツや特典盛りだくさんです。参加方法は下記の記事をご覧ください。

 

この記事の執筆者

Tsuburayaのアイコン画像

Tsuburaya

Notion 公式アンバサダー(2021年〜 / 日本で7人目)。アンバサダーとして YouTube や Twitter で発信活動をおこなっている。本業は Web エンジニア。個人で Notion API を使ったアプリケーションを開発中。代表作は Fast Notion。株式会社 TEMP 代表取締役。

Twitter / YouTube