Notionのポータルを改善しようとしたら、チームワークを改善しちゃった話
こんにちは、Gaudiyのうわい（@UwaiKaz）です。どうやらお金を使う才能が半端じゃないらしく、この間の給与振込前日は口座残高が307円になりました。
※Gaudiyからちゃんと給与は振り込まれてます。僕が悪いだけです。
そんなことはさておき、NotionでチームのトップページをキレイにしようとしてまるごとDBから作り直した話を書こうかなと思っています。
この記事は「Gaudiy Advent Calendar 2022」の5日目の記事です。
ちょっとしたNotionのTipsと実際のDB設計をあわせてご紹介しようと思うので、ぜひ感想やご意見もらえたら嬉しいです。画像も入れていますが、伝わりづらい部分も多いところはご了承ください🙇♂️
誰からも見られていないダッシュボード
Gaudiyは「Gaudiy Fanlink」というワンプロダクトを現在開発しているのですが、この「Gaudiy Fanlink」は各IPごとに名称を変え、独立して存在しています。例えば「約束のネバーランド」のコミュニティである「みんなのネバーランド」のような形です。
これらの個別IPのコミュニティ運営を担当しているのが、現在僕が所属しているコミュニティチーム（以下、COMチーム）であり、職種としてはコミュニティマネージャー（以下、COMマネ）になります。
つまるところ、プロダクトとコミュニティは機能は同じであっても、それぞれのIPの性質やコミュニティの施策が全く異なるわけです。そこでコミュニティについて社内の多くの人により知ってもらうために、Notionに「Fandom Dashboard」というページを作成しています。
このFandom Dashboardは、各コミュニティの目的から過去施策まで、幅広くコミュニティ単位でまとめているページなのですが、ある日我々COMチームが気づいてしまいました。
「Fandom Dashboard、誰も見てなくない…？」
これは一見すると、Gaudiyメンバーを非難しているように見えてしまいますが、なにを隠そう管理者であるCOMチームも全く見ていませんでした。そりゃ誰も見ないよね。
そこで僕に白羽の矢が立ち、みんなが見に行きたくなるようなFandom Dashboardをつくるために、まずはチームで使いやすいポータルページに大改造する一大（？）プロジェクトが始まりました。
PRチームのトップページがすごいことに気づく
Gaudiyには、クレドのひとつに徹底的にリサーチをしようという「超守-破離」があります。ということでまずは「超守」からはじめました。そこで衝撃的な出会いをします。他社さんのNotion構成なども勉強させていただいたのですが、衝撃的だったのは弊社PRチームのページでした。
これは弊社のPRメンバーが作っていたPR関連のポータルページなのですが、とにかく見やすく美しい。noteなどの発信カレンダーやPRチームのタスク管理などもしっかりと含まれていて、情報量は多いながら圧迫感はなく、傍から見ても使いやすそうなトップページです。
せっかく社内に素晴らしい設計者がいるということで突撃インタビューを実施すると、様々な要素を含みながら、たった6つの相互に紐付いたDBで構成されているというこれまた衝撃な事実が判明。
ここで、Notionのポータルを見やすくするためには、ただ見た目を整理すればよいのではなく、DBで構造から整理する必要があることに気が付きました。ここからは、具体的にどんな課題に対してどのように設計し直したのかをお伝えしていきます。
いざCOMチーム版のNotionポータル作成へ
DBの再構築からスタートするにあたって、DBの元となる情報の管理について、まずCOMチームの課題感から整理しました。
その結果、大きく2つの課題感がありました。
情報の粒度と網羅性がまちまちなのでチームとしての連携が取りづらい
情報が人軸で蓄積されている
以下に詳しく説明します。
まず1点目の課題について。当時、COMチームでは、朝会のときにタスク管理DBを使いながら、担当者別にタスク状況を報告するスタイルをとっていました。しかし、このDBに登録するタスクが、企画のすべての情報が入ったページの場合もあれば、本当に作業をするためのTODOレベルのものまでが混在しており、あくまで個々人がそれぞれ使いやすいように活用しているものがたまたま同じDBだった、という状況になっていました。
そのため、朝会で共有を受けたとしても、他のメンバーが作業量的にどのくらい忙しいのか、またどれくらい重いタスクを持っているのかなどがわからず、チームとしてお互いに協力することが容易ではない状況でした。
次に、2点目の「情報が人軸で蓄積されている」についてです。COMチームは普段のコミュニティ運営を企画ベースで行っています。そのため、企画を実施する事前準備の段階で、過去の企画について確認したい場合がよくあるのですが、過去の企画内容や施策結果がドキュメント化されていないため、当時の企画担当者に直接確認する必要がありました。
また、このドキュメント化されない背景として、タスク管理DBと過去施策DBが完全に分かれてしまっていました。しかしながら、この2つのDBは実際には包含する形で関係性があるために、過去施策DBの1ページの中にタスク管理DBの各チケットを移管するという運用が必要でした。これが人為的に行わなければいけない作業であるために、腰が重くなったり、後回しになって忘れてしまう状況でした。
解決方針と実運用について
上記の課題感に対して、DBの設計レベルでそれぞれに解決方針を立てました。
情報を階層化して粒度をある程度の幅に収める
意識せずとも自動的に情報を蓄積できる仕組みを作る
これらを中心に設計したDBについて以下で説明します。
DBはDBでまとめつつ、重要な情報や伝えたい情報は見せ方（viewやページ）で工夫しています
情報粒度にあわせたDBとRelationの設定
まず、COMチームの業務のベースは「企画」です。タスクは企画ごとに派生します。そして企画はコミュニティに紐づいており、コミュニティが最大単位になります。つまり情報の粒度を整理すると、コミュニティ→企画→タスクのイメージです（一般的にはおそらくクライアント→プロジェクト→タスクが感覚としては近いかなと思います）。
そこで、DBとしてはシンプルに3つで、コミュニティDB、企画DB、タスクDBで構成することにしました。その他にもDBはありますが、基本的にこの3つが中心です。さらに、ここはNotionのテクニック的な部分ですが、これらをRelationとして繋ぎこむことでシームレスに行き来ができるようになりました。
このRelationを活用することで非常に便利なポイントが、事前にコンテキストを共有していない人になにか依頼するときに、逐一説明する必要がないor最小限にしつつしっかりと企画レベルから目的を共有できることです。
口頭だから伝わる熱量みたいなものもある一方、些細な表現で解釈のズレを生んでしまうことが、少なくとも僕はよくあったと思います。ちゃんと伝わるように事前に文面で用意ができることのメリットは大きいなと感じています。
完全に現在進行形ではあるものの、COMチームの朝会は企画ベースで行うようにしていて、あくまで「この企画を進行する上でブロックになっているもの」（主語が企画）を共有できるようになったため、ヘルプがしやすくなったし、ヘルプを出しやすくなりました。
以前の個人それぞれが思い思いにタスクを切っているときは、個人的には、「自分のキャパが少ないことを認めている」（主語が個人）みたいな感覚があったからだと思っていますが、なんとなく苦しいことを表現するのがはばかられていました。他にも、単純に自分たちのコミュニティや企画に集中しつつも他のチームメンバーがある程度どんなことをやっているのかを把握できる状態が作れていると思っていて、個とチームが少しずつ両立できているのではないかなと思っています。
単一DB・複数viewの活用
次に時間軸の観点から、これらのDBについて解説をします。COMチームの業務フローは、企画単位で回っていて、準備→実行→分析の流れで行います。すべての段階でタスクDBにページを立てる前提で組んでいます。各フェーズでの使い方をざっくり説明します。
＜準備フェーズ＞
準備フェーズは、主に「企画の目的の整理」「企画の大まかな流れ」「公開と終了の期限」の3つを決める部分です。すべてがタスクとして起票されますが、これらの情報は一度決まったら大きな変更がないので、決まった段階で企画DB内の企画ページに直接書くようにしています。これによって情報の一覧性と信頼性が担保できるような仕組みになっています。
また、企画の流れや期限などは、スケジュールとして「タスクDB」を「Timeline view」で見せることで、スケジュールにあわせてタスクが切れている状態にしています。複数の企画を同時並行で進めているときに、企画ごとに進行状況が一発でわかるので重宝しています。
＜実行・分析フェーズ＞
特にコラボレーション文脈で説明します。通常のタスクをタスクDBで管理するのはもちろんなのですが、企画に際しての制作物をデザイナーに依頼したり、分析をアナリストに依頼する際もタスクベースで共有しています。また、コミュニティでユーザーさんに出すお知らせ文などのピアレビューも行っていますが、このNotionのリンクをSlackのワークフローの文面に貼り付けることでスムーズな依頼ができるようにしています。
これらの作業がすべて終わると企画は終了となるのですが、ここまで一貫して企画ページに正確な情報をためているおかげで、一切手を加えずに過去事例として蓄積できている状況になります。実際には企画そのものにもステータスをつけていて、完了しているもので絞り込むことで過去事例のアーカイブとして独立しているかのように見せることができます。
まとめ
Notionのテクニックとしては主に2つで、「Relationを設定すること」と「単一DB・複数Viewで工数を減らしつつ見やすくすること」です。
チームでの運用はまだまだ走り始めたばかりですが、より楽に正しい情報を管理していけるように業務フローに合わせて改善していけたらなと思っています。
見ていただいてここ改善できるんじゃないかなとかあればぜひ教えて下さい！ついでにそんな方にはこちらから応募していただいて、ぜひ仲間になっていただけると助かります！僕をクビにしてください！
明日はアナリティクスエンジニア兼データアナリストの星野さん（@mochigenmai ）が担当します！
この記事が気に入ったらサポートをしてみませんか？