🤷🏻 EDOCODE での Notion 運用の失敗談 😭

(c) Cover image: https://www.notion.so/Media-Kit-205535b1d9c4440497a3d7a2ac096286

こんにちは、EDOCODE で採用・組織を担当している山田です🙂

EDOCODE では 2019年7月頃から Notion を社内で取り入れはじめ、その年にはそれまで使っていた Atlassian Confluence からの移行を完了しました。社外のパートナー企業との共有ドキュメントもたくさんあったので、2020年にはそういった関係者の方たちも含めた全社的な Notion 利用がスタートしています。

もっとも古いドキュメントを発掘してみると、2019年3月のものがありました。「Notion ってツールがあるんやけど、どんな表現や書き味なんやろう？」とサンドボックスページを作って、色々試していたのを覚えています。

さて、そんな感じで Notion を使い始めてそろそろ 2年が経つ EDOCODE ですが、これまで Notion を運用してきて経験した「失敗談」を書いてみようと思います。

2021年10月9日（日本時間）には 2億7500万ドルの資金調達 を発表し、そして先日 2021年10月13日には 日本語版がリリース されてと、いま日本ではめちゃくちゃ人気の Notion なので、「どうやって使うの🙂？」「こうやって使うとええで 😎」「Notion まじ最高や🤩！！」という情報はたくさんあると思います。（コミュニティがほんと素晴らしい・・！！）

僕も愛してやまないそんな Notion ですが、Notion だからこそ気をつけたほうが良いところがあると感じています。そして、その注意点はとにかく早い時期に対処しておかないと、後で負債を返すのが大変だという問題意識も強いです。そういう気持ちから、失敗談を書くことは Notion のコミュニティへ貢献できるのではないかと思い、この記事を書くことにしました。

Notion のスゴさと反作用 🤦🏻‍♂️

Notion の運用で起こる失敗は、ほぼ一つの性質で説明することができるんじゃないかと思います。
それは「なんでも簡単に増やせる」という性質です。😵

この "なんでも簡単に増やせる" というのは、Notion の本当にスゴいところですよね。まじでスゴい・・。

これはもちろん Notion の最も魅力的なところなのですが、「なんでも簡単に増やせたらアカン！！🙅🏻‍♀️」ってこともあると思います。一方で、Notion を組織に定着させようとしている方たちは、周りが Notion を使ってコンテンツを Notion に増やしていってくれるほうが嬉しい。でもちゃんと管理していないと、秩序が乱れやすい... 😕

こんなジレンマが Notion の導入にはあるような気がします。

そこで Notion を定着させたり管理している人たちは、「コンテンツは増えても、カオスにならないようにするには、どうしたらいいんかな🤔？」と考えることになると思います。僕は考えました。みなさん考えていらっしゃると思います。

この記事では、EDOCODE での失敗を通してこの問いへの一つの答えを例示したいなと思います。観点としては、Notion の "コンテンツ" と "コンテンツ以外" という考え方です。以下の 3つのセクションでは、Notion でコンテンツが増えると "増えるもの" を説明しています。コンテンツは増やしつつ、"コンテンツ以外のもの" をどう制御するかが、Notion の秩序をつくるポイントではないかと考えています。🙂

Database が増える📈

無秩序になっている Notion では、コンテンツが増えると Database が増えます。

なぜ？

組織のなかで Notion がはじまると、勢いよくコンテンツ、つまり Page が増えていきます。Notion を使ったことのある人はみんなわかると思いますが、Page にものを書いていくと、そのあまりの手触りの良さにドキュメンテーションがどんどん進んでいくと思います。

🏃✍️🏃✍️ ...

ページではテキスト表現だけでなく、Database も使えます。まずは Table を使って二次元データを入れて・・。お、このプロジェクトにはかんばんボードが必要や！🏄

プロジェクトページを例にとると、プロジェクトマネジメントの基本的な構成要素がそのページ内に作成されていきます。例えば、この "Project management" テンプレート では、以下の Database が配置されています。

• Project Plan
• Timeline
• Updates
• Meeting Notes

これらはすべて独立した Database です。なので、仮に 5つのプロジェクトがあったとして、このテンプレートを使ってそれぞれのプロジェクトページ作成すると、まったく同じ Database が 5つずつ作成されます。🏗 🚜

どうなる？

実際に EDOCODE でもこれと似たような状況が起こり始めました。そうすると、どうなるのか・・🧐

1. 情報を統合して見られない
2. 検索性が下がる
3. ドキュメンテーションが独自に発展してしまう

各プロジェクトごとにタスクを管理する Database をつくってしまうと、それを並べて見ることができなくなります。だいたいの組織においては、複数プロジェクトを横断した管理や、把握をしたくなるものです。🙃 ... (1)

想像してみてください。ある Database の複製をたくさん作ると、同一名の Database がたくさん Workspace 上にできてしまいます。そうすると、検索をかけたときの結果には、どれがどれか全然わからない、同じように見える Database がずらっと並んでしまいます。👯 ... (2)

Notion では、Database の Page にさらに Database を持たせることができます。Notion の普及が進んだプロジェクトなんかでは、自主的にそういう使い方が発見され、進んでいきます。そうすると、どんどんそのプロジェクトのドキュメンテーションは深く深くなっていき、(1), (2) も併せて管理がさらに大変になります。🤦🏻 ... (3)

どうしたら良い？

EDOCODE では、1年ほど Notion の管理がきちんと行われていない期間がありました。そして、「さすがになんとかしないと」と、それを数ヶ月かけて構築し直しました。（まだ完全に負債は返せていませんし、プロジェクト管理に関わる部分だけですが・・。）

そこで得られたプラクティスとしては、「単一の Database で運用する」という原則です。

例えばタスクを管理したいのであれば、"Tasks" のような Database を一つ作り、それを組織内で共通で使うようにします。プロジェクトページには "Tasks" の Linked Database を配置して、そのプロジェクトに関連付けられたタスクだけを表示する Filter を設定するのが良いと思います🙂（後述の「Database の view が増える📈」で Liked Database はもう少し詳しく登場します。）

一つの Database で運用する方法は、Notion のコミュニティではすでに知られた方法論かもしれないですが、やっぱり実際に自分たちでやって失敗してみて、なぜ「一つの Database で運用するほうが良い」のか、そうしなければならないのかが言語化できた気がします。🧘🏻

学び

🔖「コンテンツが増えて Notion の規模が大きくなってきても、Database は増やさない」

Database の property が増える📈

単一の Database を組織内で共有して使っていると、その Database の property を増やしたいという声が上がってきます。

なぜ？

Notion では、Database に property が設定できますが、とても簡単に追加したり削除したりすることができます。リネームや型の変更も簡単です。ソフトウェア開発の業界にいると、個人的な感覚では「データベースのカラムをそんな簡単に変更できちゃって大丈夫😳？」と思います。そしてそれができるというのが、Notion を触ったときの最初の衝撃でした。🤯

この Database の property は、Page のメタ情報を表現するのにとても便利です。便利ではあるのですが、あまりにも追加が簡単すぎて、誰でも自分が欲しいと思ったメタ情報を追加し始めます。「どんな人でも苦労せずに使える」ことにこだわりまくった Notion の恐ろしいところですね・・。

どうなる？

共有の Database に色んな人たちが好き勝手に property を追加し始めると、あとで削除して減らすことがすごく難しくなってしまいます。だからこれ、ほんとやっちゃダメです... 🙅🏻‍♀️

例えばプロジェクトのタスクを管理する Database に、"Main Person" と "Person in Charge" があるとします（実際にあった話です）。こうした property をどっちかに統一したり、断捨離をしようにも、どちらを消しても困る人が出てきそうで手が出せません。

property が増えると、他にもいくつか困ることがあります。

• メンテナンスされていない property が発生して、ゾンビ化していく 🧟
• Page 画面に大量の property が並び見通しが悪くなる 🙈
• Filter や Sort の設定時に property を選択しづらくなる 😵‍💫

他にも挙げはじめるとキリがないのですが、メンテナンス性が下がることは確かなのではないかと思います。

どうしたら良い？

解決策としては、まず単純な話としては property の追加を禁止したり、慎重な判断を求めていくことだと思います。一つ前のセクション「Database が増える📈」でも提案しているとおり、組織の主要な Database は単一で運用し、少なくともそれら共有の Database に関しては property の追加は制限したほうが良いと思います。

また property を管理したときに起こってくる新しい問題としては、

• 色んな理由で上がってくる「property を追加したい」という要望の可否判断がめっちゃむずい（簡単に許可してしまうと、制限の意味がない）
• 軽い気持ちで別の Database からアイテムを移動してしまうと、元の Database にある property が、移動先の Database に追加されてしまう（移動した本人は気づかないケースが多い😓）
• こまめにチェックしておかないと、いつ・誰が property を追加したのか履歴から追跡できなくなってしまう

ちなみに 3つ目の問題は、単一の共有 Database で運用している弊害の一つかもしれません。なぜなら、組織内の大勢の人がしょっちゅうその Database を更新することで履歴があっというまに増えてしまい、そのせいで追跡がしにくくなるからです。

学び

🔖「みんなで一つの Database を使いはじめると property を増やすニーズが高まるけれど、できるだけ property は増やさないようにする」

Database の view が増える📈

Database にコンテンツが増えてくると、Database の view が増えます。

なぜ？

Notion の優れた設計の一つに "Database views" があります。これは以下の要素をひとまとめにした表示セットです。

• データの表示レイアウト（Table, Board, Timeline, Calendar, List, Gallary）
• Properties（初期表示件数の指定、各 property の表示 ON/OFF、などの表示設定）
• Filter
• Sort

Database に対して一つの view しか設定できない場合、せっかく設定した Filter があとで他の人に変えられてしまうことがあると思います。Notion では view の作成に制限はないので、自分が見たい設定をいくらでも保存できます。

これは大変便利な機能なので、使っているうちに "自分なりのカスタマイズ感" とかも出てきて、あっという間に "Yamada's view😎" みたいなのが作成されていきます。Notion の使い勝手の良さの恐ろしいところが現れています・・。

どうなる？

EDOCODE では、1年近く利用されたタスク管理用の Database がありました。誰も手入れする人のいない庭は雑草でぼうぼうになりますが、まさにそういう状況でした。現在は「削除予定」として凍結していますが、いま確認したら view が 61個も登録されていました。まじなの・・。

どうしたら良い？

この問題は、"Linked Database" を使って解決します。Linked Database というのは、ある Database のミラーを作れるような機能です。もしかしたら、Notion のコミュニティでもこのプラクティスはよく言われているかもしれません。🙂

Linked Database には、通常の Database と同じように view を設定できます。この view は、設定した Linked Database にだけ残るため、オリジナルの Database の view は変化しません。これは逆も同じで、通常の Database に設定している view は、その Linked Database には影響しません。つまり、view はそれぞれに独立して持たれているということです。

これをうまく使うことで、一つの Database にたくさんの view が設定されることを防ぎます。例えば、以下のような運用を行い、それぞれのページに Linked Database を作れば、そこまで view が多くなってしまうことはありません。💁‍♂️

• 事業の会議体ページを作成し、週次でタスクレビューを行う📊 → "Tasks by Person", "Recently Created" などの view を設定する
• デイリースクラムのページを作成し、毎朝の進捗確認を行う📊 → "Bugs", "Engineers's Sprint" などの view を設定する
• 個人のプライベートページを作成し、個人レベルのタスク管理を行う📊 → "Yamada's Task", "ABC Project Tasks" などの view を設定する

学び

🔖「コンテンツが増えると view を使わざるを得ない、だけど一つの Database にみんなの view を設定するのはやめよう！」

コンテンツが増える前に手を打とう！👏

ということで、EDOCODE での失敗を振り返ることで、Notion ならではの性質と気をつけるべきところを書いてみました。コンテンツが増えることはとても良いことですが、コンテンツ以外のもの、つまり Database, property, view が増えるのはコントロールしたほうが良い、というのが、この記事で言いたかったことです。この 3つは、どれも「コンテンツが増えるから増える」ものです。そこを意識してマネジメントするのが良いのではないかと思います。🙂

EDOCODE での失敗を振り返っていると、Notion のスゴさを改めて感じました。せっかくこんな素晴らしいプロダクトが世の中にあるのなら、少しでも組織に広がってほしいなと思います。これだけ話題になっている Notion ですから、組織への導入はこれからもどんどん進んでいくことと思いますが、「導入してからの問題」についても、Notion のコミュニティでますます発信されていくと良いなと思っております。🤞😏

EDOCODE では、秩序をもって Notion にコンテンツを増やしてくれるメンバーを募集しています😀 Notion 好きな方とお会いできることを楽しみにしています🙌