こんにちは!開発チームのナレッジを誰よりも美しく、そして機能的に整理することに情熱を燃やす先輩エンジニアです。
日々のプロジェクト管理で、こんなモヤモヤを抱えていませんか?
「タスクのツリー構造を作りたいだけなのに、親と子で別々のデータベースを作ってしまい、リレーションがスパゲッティ状態になっている…」
「承認フローを回したいだけなのに、誰が承認者で、次に誰に回すべきか分からなくてチャットが荒れる…」
もしあなたが「Notionはただのメモ帳だ」と思っているなら、それは非常にもったいない。Notionのデータベースが秘める真の狂気、もとい「自己参照リレーション(Self-referential filters)」を使いこなせば、たった一つのデータベース内で「無限の階層構造」と「動的な承認ワークフロー」を完全にノーコードで構築できます。
これをマスターすれば、毎日の煩雑なステータス確認や「次の承認者誰だっけ?」という無駄なコミュニケーションが劇的に消え去りますよ。さあ、一緒にNotionの奥深い世界へ飛び込みましょう!
—
1. ツールの役割と「自己参照リレーション」の正体
まず、今回私たちが武器にする Notionデータベース とは何者なのか。
単なる表計算ソフトの代替ではありません。Notionのデータベースは、「リレーショナル・データベースのパワーを、誰もがブラウザ上で直感的に扱えるようにした究極のナレッジ管理エンジン」です。
そして、その真骨頂が「自己参照リレーション(Self-referential relation)」です。
通常、リレーションとは「プロジェクト DB」と「タスク DB」のように、異なるデータベース同士を繋ぎます。しかし、自己参照とは「同じデータベースの中にある別のレコード同士を繋ぐ」という変態的な(褒め言葉です)設定です。
これによって、以下の2つの奇跡が起きます。
1. 階層型組織図・タスクツリー: 「親タスク」の下に無限に「子タスク」をぶら下げられる。
2. 動的承認ワークフロー: 「起票者」→「一次承認者」→「最終承認者」というチェーンを、データベースのフィルター機能だけで自動制御できる。
—
2. 基礎セットアップ:まずは「最強のタスク&承認DB」を作ろう
百聞は一見にしかず。手を動かしながら構築していきましょう。
まずはNotionで新しいページを開き、インラインデータベース(テーブルビュー)を作成します。名前は「🚀 プロジェクト・承認マスター」としましょう。
必須プロパティの定義
このデータベースに、以下のプロパティ(列)を正確に追加してください。ここが土台となります。
| プロパティ名 | プロパティの種類 | 設定のポイント |
| :— | :— | :— |
| タスク名 / 申請名 | タイトル | そのまま案件名やタスク名が入ります。 |
| ステータス | ステータス | `未着手` `承認待ち(一次)` `承認待ち(最終)` `完了` など。 |
| 担当者 | ユーザー | 実際に作業や承認をする人。 |
| 親タスク / 上位承認 | リレーション | ←ここがキモ!自分自身(同じDB)とリレーションを結びます。 |
💡 最重要:自己参照リレーションの設定手順
1. プロパティの追加で「リレーション」を選択する。
2. 接続先として、今まさに作業しているこのデータベース自身を選択する。
3. リレーションの名前を「親タスク / 上位承認(親)」とし、逆方向の名前を「サブタスク / 被承認案件(子)」に設定する。
4. 「制限の設定」は「双方向(Two-way)」にしておきます。
これだけで、一つの行(レコード)から、同じデータベース内の別の行へ「あなたは私の親です」と指し示すことができるようになります。
—
3. 精度高い「HelloWorld」:親子関係と承認フローの動作確認
さあ、正しく設定できているか、最小限のデータ(HelloWorld)を入れてテストしてみましょう。
ステップ1:タスクの親子関係(ツリー構造)を作ってみる
1. レコードAを作成します:`[大タスク] 新規事業の立ち上げ`
2. レコードBを作成します:`[子タスク] マーケットリサーチの実施`
3. レコードBの「親タスク / 上位承認」プロパティを開き、レコードA(新規事業の立ち上げ)を選択します。
【確認】
レコードAを開いてみてください。「サブタスク」の欄に自動的にレコードBが表示されていますか?おめでとうございます!これで無限階層の第一歩が踏み出せました。
ステップ2:自動フィルターで「自分の承認待ち案件」を抽出する
ここからが本番です。チームメンバーが「自分が今、何を承認しなければならないか」が一目でわかるビューを作ります。
1. データベースの上に新しいタブ(ビュー)を追加し、「ボードビュー」または「テーブルビュー」を選びます。名前を「🔴 私の承認待ち」にします。
2. そのビューの「フィルター」機能を開きます。
3. 条件を以下のように設定します:
- `担当者` = `[ログイン中のユーザー (Me)]`
- かつ `ステータス` = `承認待ち`
このビューを開いた瞬間、チームメンバー全員にとって「自分宛ての承認タスクだけが自動的にフィルタリングされて表示される神ビュー」が完成します。もうSlackで「ねえ、承認してくれた?」と聞く必要はありません。Notionを見れば一目瞭然です。
—
4. 現場で震えるほど役立つ応用:動的承認チェーンの構築
さらに踏み込みましょう。「一次承認者が承認ボタンを押したら、自動的に最終承認者にタスクがパスされる」ようなワークフローを、Notionの自動化(Automations)とリレーションで実現します。
1. Notionオートメーションの設定
データベースの右上にある雷マーク(⚡️ データベースの自動化)をクリックします。
- トリガー(いつ実行するか):
- プロパティ `ステータス` が `一次承認完了` に変わったとき
- アクション(何をするか):
- `担当者` を 「最終承認者(特定のマネージャーなど)」に変更する
- `ステータス` を `承認待ち(最終)` に変更する
2. セルフリファレンスを活かした「差し戻し」のループ
もし最終承認者が「差し戻し」とした場合、親タスク(起票者)へ簡単にジャンプバックできるように、リレーションのリンクがそのまま「監査証跡(ログ)」として機能します。誰がどこで止めているのか、ツリー構造をたどるだけで一瞬で特定できるのです。
—
5. おわりに:ナレッジのサイロ化を防ぐために
いかがでしたでしょうか?
今回紹介した「自己参照リレーション」を使いこなすと、Notionは単なるメモのゴミ溜めから、「自律的に回る組織の神経回路」へと進化します。
情報をバラバラの場所に散らばらせず、一つのデータベースに関係性を美しく閉じ込めること。それこそが、情報のサイロ化を防ぎ、開発チームのベロシティを極限まで高めるナレッジマネジメントの極意です。
「これをこう変えたらもっと便利になるのでは?」という好奇心を大切に、ぜひあなたのチームのワークフローに組み込んでみてください。毎日の作業が劇的に、そして圧倒的に楽になりますよ。それじゃあ、また次の知見でお会いしましょう!