6-4. フラットな構造体

Notionはツリー状にほぼ無限に構造体を入れ子（ネスト）にすることができます。 適度な構造体は有意義ですが、乱用しすぎるとせっかく作った情報にたどり着けなくなり、情報が死んでしまいます🤯

また、ページを入れ子にしてしまうと、単一のページで表示されうる情報が絞られます。

見る頻度が低いかつ、情報の量の増減が見込まれないような情報、たとえば告知などは、１枚のページに収めるのが良いでしょう。

ページをツリー状構造にした場合の例

ページをツリー状に構造する場合には、右図のような構造体であることを意識し、親で書いている内容の粒度、子で書いている内容の粒度、孫で書いている内容の粒度がそれぞれ合わせるように配置することで、閲覧者に混乱を与えずにスムーズに整理することが出来ます。

ツリー状に配置する、ということはすなわち、情報を得るまでのクリックが増えるといったデメリットも理解する必要があります。 複数のページに見たい情報が散らばっている場合は、クリック、戻る、の手間が多く閲覧者にストレスを与えがちです。

そのため、ページをネストするという行為には自身の整理にはマッチしているが、他人から見たとき、または忘れた自分が見返す時には、大きなデメリットがあることを理解しましょう。

上記を考慮したときに、たとえビジーなページになったとしても結果的にページ遷移のストレスが無いことによって目的のコンテンツへたどりつく方が早い場合が多いです。

ビジーになりすぎないように、カラムを分ける、アイコンを利用する等様々なデザイン観点での方法がありますので、ここは自己流を見つけるのが良いと思います。

Notionでの情報のまとめ方

一例ですが、筆者の業務上に必要となる情報をまとめているページをサンプルとして公開します。

このページに落ち着くまで３回ほど改編期を迎えています。もちろん完成ではありません。 当初はツリー上に構成して、構造化を中心に実施していましたが、直ぐに破綻しました。

ツリー構造では目的にたどりつくまでに５回以上クリックが必要であったり、他のツリーに戻るのも同様のてまが発生します。またツリーに仕切れない情報もあるため、情報をもっと上の構造に押し上げるようにしました。 この状態ではツリービューはほぼ機能していませんが、俯瞰して、目でみやすいために結果的に情報にたどりつくスピードがあがりました。

参考文献などはWebクリップとして対象の近くにページを配置して、後で自身のブックマークを関連して見つけることができるようにしています。

データベースではなくページで表現する

データベースも、もちろん検討しましたが、データ構造が表現できないため最初から利用は諦めました。 データベースに格納することが目的となり、情報を呼び出すことも手間で、カラムにデータをいれることも手間になるためです。

あくまで自身が情報をあとで取り出すことが目的だったので、データベースは用途とは違うと肌感覚で体感しましたが、運用していくなかでも実際にデータベースにしなくて良かったと感じています。 何よりもデータベースはロードが遅く、ストレスも大きいです。ページビューはキャッシュがうまく効くので、読込がとても早いです。

“個人的なイメージですが、↑の構造体は様々な情報の形に対応できるドキュメント型DBのような整理だと感じています。データベースはそのままRDB。メリデメはどっちも同じような体感を感じています。 わかる人が少ないかもしれませんが、、”

また、データベースのみを、利用する形も有用かと思います。 オリジナルメモboxを作ろう でもあげた、データベースを利用してトップレベルのページをデータベースのみに絞る方法です。

この方法であればフラットで管理することが比較的強制することが可能です。

アンチパターン

• データベース を入れ子にする。

DBの中にDBを作って配置する場合、今後一生コンテンツにたどりつかないでしょう。 天才が一人で利用しているNotionであれば、良いのですが、チームでは一生たどりつかないです。

ベストプラクティスは利用メンバー規模、ITスキル、利用用途、プロジェクトスタイルによって様々な形態が存在すると考えています。 組織の特性にあった、最適な管理方法を是非見つけ出してください。