コングラントのプロダクト開発におけるNotionの使い方
コングラント株式会社でプロダクトマネージャー・UIデザイナーをしている荒木（@arakiyd）です。ソーシャルセクターや企業向けに寄付DXシステム「コングラント」を開発・提供しています。
プロフィール
学生時代NPOでの広報インターンを経験。新卒でリタワークス株式会社に入社してNPO向けのWEBサイト制作のディレクターを3年経験。その後分社化したコングラント株式会社で寄付決済・CRMのSaaS「コングラント」のプロダクトマネジメントとUIデザインを担当。他社でのプロダクト開発経験がないのでインターネットに溢れる情報に感謝しながら日々試行錯誤中。
1991年、熊本生まれ・大阪在住。妻と娘と3人暮らし。
最近、重い腰を上げてコングラントの開発部で利用するNotionのDBをがっつり整備しました。まだまだ問題はありつつも、今のところ割とうまく回っている気がしています。
自分自身の振り返りとして残したい（頑張ったし）
今後新たに入るメンバーのオンボーディングに使いたい
Notionを使ったプロダクトマネジメント方法を模索している同志に
そんな想いを抱きつつ、このnoteではコングラントのプロダクト開発におけるNotion活用方法について紹介します。公開できる内容はなるべく画像付きで紹介しているので記事も少し長くなってしまいましたが、誰かの参考になれば幸いです。
今回のNotion DBの整備の際に（超）参考にした記事はこちら。
データベースの全体像
コングラント開発部のNotionではほぼ全てのページをデータベースで管理してます。
主要なDBとリレーションは次のとおりです。
スクラムでの活用
コングラントの開発にはスクラム開発を採用し、1週間スプリントで回しています。そのスクラム開発でBacklog、Release、SprintsのDBを活用しています。
Notionには「プロジェクト、タスク、スプリント」がセットになったスプリント用のテンプレートが用意されているので、それを複製してベースにしました。
もともとコングラントではドキュメントや議事録はNotion、タスクはJIRAで管理していましたが、今回思い切って開発タスク管理もNotionに移行しました。
本来、開発のタスク管理だけを行うのであればJIRAを使う方が良いと思います。しかし、今回のNotion整備のテーマは「情報をつなげて、なめらかなプロダクト開発を実現する」（あとづけ）。改善要望、事業戦略、仕様書や議事録などのさまざまな情報と開発タスクが繋がることで、開発時に「なぜやるのか」「何の課題を解決するのか」を見失わない仕組みを作りたかったのです。
✅ Backlog DB（開発タスク管理）
Backlog DBのプロパティは29個とまぁまぁ多いです。
ID：もともとNotionはID採番できなかったんですが、いつの間にかできるようになってましたね。メンバー（特に外国人メンバーと）と会話する時に便利です。
Priority（優先順位）：リファインメントの際に独断でHighest〜Lowestの5段階でつけています。ただこれはあまり良くないので、ICEスコアリングを導入するつもりでプロパティだけ用意しています。（RICEも検討したけどReachスコアをつけるのに時間がかかってしまうので断念）
Domain：後述しますが、事業領域・機能領域を管理するDomain DBとリレーションしています。コングラント開発チームは複数プロダクトを1つのチームで開発しているので、どのプロダクトのどの機能の開発なのかをわかりやすくしています。
Document：PRD（プロダクト要求仕様書）はPBIのページ内に記載するのですが、別途ドキュメントとして用意した方が良い場合があります。複数のPBIに別れるケースなどです。その場合Documents DBに別途用意してリレーションさせます。
VoC：後述するVoC DB（顧客の声）と紐づいています。どんな要望からこの開発を行うのかを見える化しています。
Backlogページの内容はテンプレート化していて構成はかなりシンプルです。ここは改善の余地ありで、他社のPRDやDesign Docsを参考にアップデートしていきたいと思ってます。
👟 Sprints DB
Sprints DBは上述したテンプレートにくっついてきます。自前でDBを用意してスプリントを頑張ることもできると思いますが、
スプリント終了時に次のスプリントを自動作成
スプリント終了時に未完了のタスクをバックログに戻す、次のスプリントに移すなどの設定ができる
なので、公式テンプレートを使う方が良いと思います。
→と思ってたけど、後からスプリントDB化することもできそう。
Sprintsのプロパティはこんな感じであまりいじってません。
Total PointsはSBIのStory Point合計、Done Pointsは完了したSBIのポイント合計（ベロシティ）です。ロールアッププロパティで出しています。
ページ本文にはスプリントレビューでの振り返りなどをメモってます
🚀 Release DB（本番リリース管理）
本番リリースを管理するためにRelease DBを新規で用意してBacklog DBにリレーションさせています。Release DBのページの中身はこんな感じ。
その日にリリースする開発内容を一覧化させて開発ステータス、QAのステータスがぱっと見でわかるようにしています。
改善要望を開発につなげる
👥 Customers DB（顧客DB）
コングラントの登録ユーザーのDBです。APIを使って自動化できると思うのですが、一旦CSVデータを定期的に一括登録して手動で回しています。後述するVoC、Research DBのページとリレーションすることで、どの団体がどんな要望を持っているのかを把握できます。
🎁 VoC DB（改善要望）
コングラントではGoogleフォームを使ってユーザーから改善要望を収集しています。フォームで改善要望が送信されるとスプレッドシート&Notion DBに自動連携＆Slack通知までを自動化しています。また、ユーザーだけでなく社員からも投稿できるようになっているので、セールス・CSが商談や打ち合わせで聞いた顧客からの要望や社内業務を効率化するための改善アイデアなど寄せられます。
改善要望は隔週で確認し、開発する可能性があるものをBacklog DBに登録して「Backlog-VoC」をリレーションさせています。この段階では「やる・やらない」は判断せず、Backlogのリファインメントをする中で開発スケジュールに載せるかどうかを決めています。
プロパティはこんな感じ。
団体：Customers DB（顧客DB）とリレーションしていて、どの団体からの要望かわかるようにしています。
ステータス：この改善要望を対応するかどうか検討したステータス
開発ステータス：リレーションしているBacklogアイテムの開発ステータスをロールアップで表示しています。Doneなら開発は完了しているということです。
リリース予定日：Backlogアイテムのリリース日（Release DBのアイテム）をロールアップで表示しています。
👀 Research DB
ユーザーインタビューやアンケートなど、ユーザーリサーチの企画、文字起こしデータ、アンケート回答データが登録されるDBです。
ページの中身はこんな感じ。インタビュー協力者の情報、質問のスクリプト、録画データ、発話記録、サマリーなどが集約されているので、インタビュー前の情報キャッチアップやインタビュー後の振り返りが容易になってます。
ユーザーインタビュー後はリサーチ担当者がインタビューで出てきた改善要望をVoC DBに登録してくれます。（ユーザーインタビューでは毎回貴重な意見が大量に出てくるので、この作業がすごくありがたい…）
事業の大きな流れを見える化する
日常的な開発、タスク管理だけではなく、中長期視点での事業戦略やプロジェクトもNotionで管理しています（と言いたいところですが、ここはまだ途中…）。
🎯 Projects（プロジェクト）
数ヶ月単位で取り組む開発（エピック）などをBacklog、Tasksの上位概念のプロジェクトとして管理しています。
一覧はこんな感じ。タイムラインビューで見ることが多いです。
プロジェクトのプロパティはこんな感じです。
プロジェクトの詳細ページは結構長いので全体のスクショは載せませんが、以下のような内容になっています。
プロジェクトの背景・目的
プロジェクトの目標
計画・方針
書く内容はプロジェクトによって様々ですが、例えばBacklogの関連アイテムをリンクドビューで一覧表示して、開発の「やる・やらない」をICEスコアをつけながら決めたりしてます。
スケジュール（Projects DBのリンクドビューを設置して子プロジェクトをタイムライン表示）
リファレンス
関連する議事録（リンクドビュー）
関連するドキュメント（リンクドビュー）
関連する改善要望（リンクドビュー）
その他Googleドライブのフォルダや資料などを設置
バックログ/タスク
関連する開発タスク（リンクドビュー）
開発以外のタスクの一覧（リンクドビュー）
これらの大量の項目もテンプレートに登録しておけば一発で出せるのがNotionの気持ちよさですよね。
🌐 Domain（事業領域）
コングラントでは現在2つのプロダクトを運営しています。
寄付募集・管理システムのコングラント
社内募金システムのコングラントforBIZ
さらに最近は新たなプロダクトを開発中で、近い将来合計3つのプロダクトを扱うことになります。まだまだメンバーも少ないのでこれらを1つのチームで開発していて、バックログも1つに集約しています（こういう場合分けるべきなのか？）。
そういった背景もあり、バックログのアイテムやプロジェクトにDomain（事業領域）のリレーションプロパティを用意して、どのプロダクトの開発なのかをフィルタできるようにしています。
Domainにはプロダクトをさらに機能ごとに分て登録しています（そういう意味では機能領域の方が正確かも？）。例えば、プロジェクト機能、決済機能、CRMなどです。
また、DomainにはVoC（改善要望）も紐づけているのでどの機能にどんな改善要望がどれだけ来ているのかを見える化できるようにしています。
🌟 Business Strategy（事業戦略）
Business Strategy（事業戦略）のDBでは事業戦略を管理していきたいと思っています。これはまだ準備中でして、11月からコングラントの下期が始まるのでそれに合わせて準備していきたいと思っています。
これができると、
事業方針から生まれるプロジェクト・開発
顧客や社内の現場メンバーからの声から生まれるプロジェクト・開発
のつながりが見えるようになって
なぜこれを開発するのか
自分たちが解くべき課題は何か
が明確になると思っています。
最後に
書き始めたら長くなってしまいました。
Meeting（議事録）
Documents（ドキュメント）
Tasks（開発以外のタスク）
について書けていないのですが、体力が尽きたのとそんなに変わった内容はないので省略します。
まだまだ試行錯誤中なので「うちはこうしてるよ！」みたいな話もぜひ教えてください。（Notionを使ったプロダクトマネジメントを語る飲み会みたいなのあったら誘ってください）
メンバー募集中！
最後に宣伝ですが、一緒にコングラントを作りませんか？
NPOや社会課題解決に興味がある
Notion好き
大阪の会社で働きたい（フルリモート可。なんならフルリモの方が多い）
みたいな人がいればぜひ気軽に声かけてください！（X：@arakiyd）