SansanプロダクトマネジメントでのNotion活用術[5] -DB編4-プロダクトバックログアイテムとタスクのデータベースの紹介[利用頻度：100%
Sansanプロダクト室でプロダクトオペレーションを担当しているPMOの尾部です。「SansanプロダクトマネジメントでのNotion活用術 -DB編-」の連載の4回目です。今回はプロダクトバックログアイテム（PBI）とタスクのデータベースを詳しく説明します。
プロダクトバックログアイテムとタスクのデータベース
構成の背景と現状
情報を集約し、PBIと紐づけて管理したかった
前述のとおりですが、企業規模の拡大と共に、部署やメンバー、そしてプロジェクトに関わるステークホルダーが増えてきたため、情報を探す手間がかかる問題が生じました。これを解決するために、Notionを導入しました。
Notion導入前から、各PdMのPBIは一元管理していました。Notionの導入とともに、PBIに加え、会議やリサーチの議事録、資料、フィードバックなど関連情報をすべてPBIと紐づけてNotion上に集約しました。
プロジェクトに紐づけてタスクを可視化したかった
上記と同様に関わるメンバーが増えたため、これまでのように阿吽の呼吸でタスクをやりとりすることが難しくなりました。タスクの漏れや誤解が頻発することで問題が生じたため、プロジェクトごとにタスクを可視化する方針を採用しました。
3年前にはPBIとタスクのデータベースは個別に2つありましたが、タスクを検索したり紐づけるのが手間だったため、タスクのデータベースを使わなくなってしまいました。そこで、PBIを管理するデータベース上で、「＋ボタン」を押すだけで簡単にPBI配下に子タスクを作れるようにしました。
残る課題
タスクの漏れや誤解を回避するために、タスクを可視化することを始めました。しかし、メンバーによって、どのようなタスクや論点を可視化すればよいのか理解が異なるため、完全には可視化できていません。もう少し工夫を凝らしてみます。
参考：テンプレートの活用を推奨
Notion製のプロジェクトテンプレートの利用が後々役立ちます。
このテンプレートはプロジェクトデータベースとプロジェクトタスクデータベースがリレーションしており、Slack連携で「Create to Notionアプリ」も使用可能です。また、プロジェクトに関連するタスクの完了率を自動で提示してくれます。
私たちはプロジェクトのテンプレートだけが必要だったため、プロジェクトデータベースだけを使用しました。既存のPBI/TaskのDBをそのまま活用したかったので、タスクのデータベースは利用せずに捨ててしまいました。その結果、それらの便利な機能が利用できなくなりました。強く困ることはありませんが、少し機会損失があったと感じています。
PBI/Taskのデータベースの構成
タスクについて
前提として、Typeのプロパティで「PBI」「Task」で種別を表現しました。Jiraでいうレコードの課題タイプに「ストーリー」と「タスク」とフラグで分けられるイメージです。
タスクは日々頻発するので、起票した際にはオートメーション機能でTypeが自動的に「Task」に設定されるようにしています。
プロパティ
「誰が（Assigned）」、「いつまでに（Date）」、「何を（完了の定義）」「ステータス」は入力を必須としています。
参考：タスクの記述方法は文章で書くことを推奨
「何を（完了の定義）」の記述については、体言止めを避けるように推奨しています。ステータスをDoneにするための基準が、誰が見ても理解できるように明記しています。プロジェクトメンバーやVPoPなど関係者が情報を理解できるようにすることで、ようやく情報の可視化が実現されたといえます。
例1）
✗ 体験設計
◯ 体験設計の初稿を完成させる
◯ 体験設計の最終版を完成させる
例2)
✗ インタビュー
◯ 5人にインタビューを実施する
◯ インタビューの議事録をまとめる
プロダクトバックログアイテム（PBI）について
PBIはその名の通り、プロダクトバックログとして活用しています。TypeをPBIに変更し、PBI専用のテンプレートを挿入して使用します。
プロパティ
”[DB]LK_PBI/Task” には約60のプロパティが存在します。Notionのヘルプで説明されているプロパティの機能の「ファイル＆メディア」を除く全てを使用しています。
これほど多くのプロパティが存在する理由は、以下のように ”[DB]LK_PBI/Task” がプロダクト室の業務の中核を担っているからです。
PBIを連携する、開発グループごとの必要とされる異なる情報を集約しています。
PBIに紐づけるべき情報がプロジェクト、機能ドメイン、フィードバックなど多様に存在します。
PBIをKPI報告、OKRなどのレポートに使用しています。
PBIを様々な視点から概観できるようなラベル付けを行っています。例えばNSM、どの部署からの依頼か、魅力的品質か当たり前品質か、ジョブパフォーマーは誰かなど。
PBIのリードタイムを計測し、改善活動を行っています。
以下にプロパティの分類と用途、プロダクトの例を示します。
入力を迷わないための3つの工夫
プロパティが多いと、どのフェーズで何を入力するかがわからなくなりがちです。以下の2つの工夫をしています。
1. 入力する必要がないプロパティにはプロパティ名の冒頭に🚫マークをつけています。
2. プロパティのインフォに説明書きをしています。
3. フェーズごとのビューを作成し、そこに入力すべきプロパティを表示しています。これにより、各フェーズにおける必要な入力項目が明確になります。以下は Design Phase の例です。このフェーズにいるときに、ここに表示されているプロパティを全て埋めるようにします。
蛇足ですが、データベースの上にいくつかのトグルが見えますが、このフェーズでのTodoや検討のポイントなどをテキストで書いています。
Notionに対する要望
上記の工夫をしてもまだ課題は存在します。PdMとしては、ページを開いた状態で、何も考えることなくプロパティを入力したいと考えています。
フェーズやステータスごとに、入力すべきプロパティを表示・非表示にしたいと思っています。また、必須プロパティがあればアラートが表示されるようなチェック機構もあれば助かります。
テンプレート
以下に示すのは、私たちが使用しているテンプレートの構成です。一般的なPRDです。
特別な利用方法1：Notion AIを用いたわかりやすさ評価
Notion AIのカスタムAIブロックを活用し、わかりやすさの評価を行っています。
プロンプトの改善により、評価の精度が向上しました。多くのPdMが生産性向上を実感しています。PRD（プロダクト要求仕様書）の品質が低いと、関係者との誤解が生じ、作業が滞ったり、確認事項が増えてしまいます。以前は他のPdMやVPoPによるレビューが必要だったのですが、その工数が削減されました。
以下に示すのが、私たちが使用しているプロンプトです。
あなたは経験豊富なプロダクトマネージャーです。開発を担当するエンジニアに提供する文書として、以下の内容がロジカルでわかりやすいかを評価してください。ただし「リリースレビュー」セクション以降は対象外です。
ロジカルでない文章、わかりにくい文章、根拠が薄い点などがあれば、セクションと該当する文章を箇条書きで抜き出し、その理由を教えてください。
評価のポイント
* ロジカルシンキング、クリティカルシンキングがなされているか
* ファクトではなく、感情や解釈になっていないか
* 因果関係がわかるか
* 専門用語や解釈が異なる言葉が使われていないか
ロジカルライティングの禁止事項があれば指摘してください。
* 名刺表現、体言止めは使用禁止とする
* 「あいまい言葉」は使用禁止とする
* メッセージはただ一つの文章で表現する
* 「しりてが」接続詞は使用禁止とする
特別な利用方法2：特定フェーズでの滞留期間の計算
私たちはオートメーション機能を使用して、フェーズが変更された日をプロパティに自動入力し、数式機能を使用してその日から現在までの期間を計算しています。例えば、Designフェーズで時間がかかっている、タスクが進行停止している等、一目で状況が理解できるようにしています。
このようなデータベースを活用したオペレーションは多岐にわたりますので、今後さらに詳しく紹介したいと考えています。
SansanプロダクトマネジメントでのNotion活用術シリーズ
この記事が気に入ったらサポートをしてみませんか？