こんにちは。 shiotsuです。
この記事はSocial Databank Tech Blog Advent Calendar 2023の11日目です。
私は、ソーシャルデータバンク株式会社で開発チームメンバーと、社内IT担当を兼任しています。
利用者兼、管理者の目線で、社内でも重要なツールになっているNotionについて書いていきます。
弊社では、一部のゴリゴリのスプレッドシートやプレゼン資料以外は、基本的にプロジェクト管理、タスク管理、社内のマニュアルなど、多くの情報をNotionで管理しています。
今回は、運用する中で「これは基本ルールにしていこう」「この使い方は継続したい！」と思ったいくつかの運用方法を紹介します。
基本的なNotionの使い方については触れていませんが、チームでの運用を検討している方の参考になれば幸いです。
データベースは1箇所にまとめて管理する
1つ目の運用ポイントは、やはりデータベースです。
データベースをうまく使えるかが、Notionが便利になるかの鍵だと考えています。
具体的には、Linked Databaseの機能をうまく使えるかどうか。
Notionにはデータベースを/linked database で別のページでも呼び出すことができます。
それぞれのページでは別のフィルターをかけて、用途に合わせて見たい情報だけを絞ることができます。
たとえば、タスク管理ならプロジェクトのページではプロジェクトに紐づくタスクだけを表示するし、自分専用のダッシュボードでは自分のタスクだけを表示する、という形です。
（弊社でのタスク管理の詳しい使い方については後述します）
もう1つのNotionの大きな特徴として、どこでも新たなページを新たな階層に作ることができるという点があります。
これはとても便利な一方、データベースを扱う上では、運用を難しくする部分が出てきました。
「このデータベース、本体なのかlinked databaseなのかわからん」
「なんかテーブル消えちゃった！！」
「なんか似たようなテーブルなかったっけ？」（大量のテーブルからそれらしい名前を探す）
みたいなことがちょこちょこ起きるのです。
そこで、弊社ではみんなで使うデータベースは、チームスペースの最上階層に「データベース」のページを作ってまとめておく、ということにしています。（一時的に使うようなテーブルは除く）
主には、
- 課題管理
- チケット管理
- タスク管理
- 会議ログ
- Sprint管理
- 社員名簿
- 社内マニュアル
おまけとしてはオフィス付近のおすすめご飯スポットなどもあります。
運用をシェアしないといけないという点はあるものの、100人未満の弊社であればほぼ問題なく運用できています。
ありとあらゆるページにデータベースがあっても、本体ではないことがほぼ確実なので、タイトルを非表示にしていても恐れずに消したり足したりできます。
「こんな情報まとまっていないかな」と思った時には、まずデータベースのページを見ることで、重複した資料を作成するリスクも減りました。
タスクはありとあらゆるところから紐づけられるようにする
そんなデータベースで管理されているもののなかでも弊社で重要なのは
「課題管理」「チケット」「タスク管理」「プロジェクト管理」です。
ここでNotionの推しポイント3つ目、「リレーション」が重要な役割を果たしています。
「タスクをシンプルに管理したいけど、なににかかわるタスクなのかが複雑」という問題を、リレーションに解決してもらいます。
普段の仕事を紐解いていくと、こんなタスクたちがあります。
- プロジェクト運営に関するタスク
- 開発チケットに紐づくタスク（実装など）
- 課題管理に紐づくタスク（ユースケースの調査、利用実態の調査など）
- その他何にも紐づかない事務タスク
弊社のデータベースの構造はこんな感じになっています。
「課題管理」のテーブルからも、「チケット」のテーブルからも、「プロジェクト管理」のテーブルからもタスクが紐づけられるようになっています。
プロジェクトからは、プロジェクトに紐づくチケット、タスクを見ることができます。
個人の単位では、プロジェクトや事務作業を含む自分のタスクを全て見ることができます。
とにかくすべてのタスクはタスク管理にある、どこからでもタスクが追加できるし、後からでも紐付けられる。
これはNotionだからこそできる構成だと思います。
プロジェクト目線での見積もりにも役立ちますし、プロジェクトを跨いで、だれかが仕事を抱えすぎていないかもわかります。
Sprintもデータベースで管理してみる
タスクに関して、もう1点取り組んでいることがあります。
弊社のプロジェクトは完全なアジャイルで開発をしているわけではないのですが、アジャイルっぽい仕組みがあります。
その週にやるタスクには、Sprint Numberをつける、という運用です。
（開発以外のタスクにもSprint Numberをつけるし、バックログから取ったものを1週間で消化して…というサイクルにはならないことも多いので、Sprintという概念を借りたという点でのアジャイルっぽさです）
今週やることにはSprint Numberを紐付けておくと、その分で絞り込んだ表示もできます。
ポイントは、Sprintもリレーションでできていて、Sprintを管理するテーブルがあることと、SprintにはSprint番号と自分の名前もついていることです。
Sprintには、yy週番号-自分の名前 を設定します。
※画像ではサンプルとして99を設定していますが、通常はその年の週番号を入力しています。
これは実際、毎週自分のSprintを作らないといけなかったり、重複して作ってしまったりというミスも発生するので、より良い運用を探していきたいところではあります。
ですが、メリットも大いにあります。
ナンバーを入力する欄を設けるだけだと、先週やろうとして後回しになっているタスクなどが可視化されません。
リレーションになっていれば、先週のSprintがついていても、追加で今週のSprintをつけられるので、見積もりとのずれを認識できます。
ちなみに弊社では、後ろ倒し回数が増えると絵文字がだんだんと圧をかけてきます…。
たくさん先送りにしてしまった事務作業とか↓
さらには、自分のSprintで、タスク何件中何件を消化したのか、集計できます。
Notionの好きな機能4つ目、関数の機能をゴリゴリと使っていますが、エンジニアのチームでは特段抵抗なく書ける内容です。
1週間の振り返りとして活用しています。
👹を見るとうっ…という気持ちに…。
（記事を書こう書こうと思って書いてなかったりとかね…）
まとめ
今回ご紹介したように、いろんな運用知見が溜まってきていて、Notionをチームで便利に活用できるようになってきました。
Notionの機能を使いこなすというのとは別に、チームとして便利に使うためには、運用の検討は欠かせません。
今後もチームメンバーには付き合ってもらいながら、試行錯誤繰り返していきたいなと思います！
しかし、まだまだ課題もあります。
次の目標は、プロジェクト管理と社内ポータルのベスト運用を見つけること！
そんな記事を次はご紹介できることを目指します💪
Discussion