前の記事
【無料テンプレ配布】Notionでプロダクトバックログを運用する（2022年版）
こんにちは。Notion アンバサダーの 円谷 です。
今週は、会社で運用しているプロダクトバックログをテンプレート化したので、それについて書いていきたいと思います。1年以上前に 「 【Notion × スクラム開発】プロダクトバックログとスプリントバックログを運用する 」という記事を書いたのですが、1年間運用を重ねて Notion 自体もカイゼンがかなり加わったので、今回の記事はそのレベルアップ版になります。
記事の最後には例によってテンプレートを準備しておきました。もしよろしければ複製してお使いください。
Notion を用いたプロダクト開発のワークフロー・データベース構造の関連図
Notion を使った弊社の開発ワークフローをざっくりと図にしました。この記事では、アイデアを Notion に書き起こすところ（起票）から、実際にコードを書いて実装をし、リリースするところまでを解説していきたいと思っています。スクラム開発をベースにしたワークフローになっているので、ところどころ専門用語が出てくるのですが、なるべくスクラム開発を知らない人にも理解できるように噛み砕いて解説していきます。
データベース構造の関連図
開発に使うデータベースは「プロダクトバックログ DB」「開発バックログ（タスク）DB」「リリース DB」の3つです。以下の図は、データベース間の連携を表したもので、実際の運用しているデータベースはアサインするメンバーや、チームのデータベースがリレーションでもう少し複雑絡み合っているが、今回は記事用にエッセンスのみを抽出して簡略化しました。
プロダクトバックログと開発バックログは 1:N、リリース DB とプロダクトバックログも 1:N の関係で紐付いています。それぞれの DB の解説はこのあと詳しく解説していきます。
プロダクトバックログの解説
プロダクトバックログは、今後、開発予定のアイテムを全て格納したデータベースで、社員全員が起票できるような仕組みになっています。（プロダクトバックログの1つ1つのデータをこの記事では「アイテム」と呼ぶことにします）アイデアベースのアイテムから、要望ベースの抽象度が高いアイテム、実装方法までイメージがわいている具体度が高いアイテムまで様々です。そのバラバラな状態のアイテムを、開発可能な状態にするために、
- どのくらい価値がある？
- そもそも作るべきもの？
- やるとしたらどのくらい時間かかる？
- どんな UI/UX になる？
のようなことを議論して、解像度を上げて粒度を揃えていきます。粒度を揃えた上で、どのアイテムから開発に着手するのかを決定しています。この作業を「 リファインメント 」と呼んでいます（詳しくは後述します）
起票：テンプレートから呼び出し
プロダクトバックログのアイテム起票は、エンジニア以外にもマーケ担当の方やセールス担当の方が担当することも多々あります。役割の異なる方が起票すると抽象度があまりにバラバラになってしまうので、なるべくアイテムの内容を揃えるために、テンプレートからアイテムを作る運用にしています。
「New!!」というテンプレートを準備していて、ここのボタンを押すことで、テンプレートを呼び出すことが可能です。テンプレート内では、「解決したい課題」「達成したい状況・KPI」「必要な機能（How）」を入力するようにフォーマット化されていて、最低限「課題」の部分だけは記入するように運用ルールを敷いています。プロダクトバックログアイテムは、頭の中に思いついた解決策を書いてしまいがちなのですが、課題を書くのが鉄則で、テンプレートにもその旨が強く記載されています。テンプレートに沿って記入することで、粒度の統一されたプロダクトバックログになります。
📝
ちなみにこれは Notion テンプレートギャラリーの Shin Sasaki さん作のフォーマットを参考に作成しました（ありがとうございます）
https://www.notion.so/ja-jp/templates/プロダクトマネージャー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 の中でもちょっと難易度の高いロールアップ機能が含まれているので、テンプレートを複製してそのまま使うのをオススメします）
リリース管理 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 × プロダクトバックログの事例がまだ少ないような気がしているので、この記事が世のプロダクトマネージャー、もしくはエンジニアの方の参考になれば幸いです。同じことをしている方が周りにぜんぜんいなくて寂しいので、もし同じようなことやられている方いたら情報交換しましょう！誰のも参考にせずマイ・ウェイを突き進んできてしまったので、インプットがしたいなと最近けっこう強くおもっていますｗ 最後までお読み頂きありがとうございました。