こちらは corp-engr 情シスSlack（コーポレートエンジニア x 情シス）#2 Advent Calendar 2021 - Adventar の 12/8 の記事となります。
最近仕事でNotionを使っています。
Confluenceを長く使っていた身としては、俯瞰して全体を見ることができるようになった反面、どう情報を置くのがいいのでよく悩んでいます。
社内Wikiあるあるなんですが、会社ごとに組織構造や取り扱う情報・業務が異なるため どういう構成がいいかはケース・バイ・ケースなんですよね。
でもケースごとの情報があるというのも大切だと思うので、いろんなパターンで良し悪しを考えてみました。
定義
-
ワークスペースページ- 第一階層のページ
-
サブページ- 第二階層以降のページ
パターン１：Notionで紹介されている構成例
Notionのチュートリアルにある構築例です。
- How to build a wiki for your company
- How to build a wiki for your product team
- How to build a wiki for your engineering team
ワークスペースページ構成
スタートアップのようにひとつの事業やサービスが主力でそれに集中している会社向き。
- 会社のホーム
- 各職種 * n
- 各プロダクト * n
- 共有データベース * n（議事録やタスク、ドキュメントなど）
良い点・悩ましい点
- 良い点
- ワークスペースページからすぐアクセスできる
- One Product, One Team と相性がいい
- 悩ましい点
- チームやプロダクトが増えていくとワークスペースページが増えてサイドバーが見づらくなる
- 全チーム全プロダクトが同じDBでタスク管理するとプロパティがカオスになりそう
リンクされたデータベースなら、本体データベースに影響を与えずにリンクされたデータベース側のプロパティ表示・非表示は制御できますが、データベースアイテム側のプロパティ表示・非表示は本体と共通なのが辛い。
一応データベースアイテムのページカスタマイズで 未入力時は非表示 で回避はできますが。
パターン２：ワークスペースページを少なくする構成案
第一階層をなるべくシンプルにしてみる。
ワークスペースページ構成
- 会社のホーム
- 職種
- 各職種 * n
- プロダクト
- プロダクトDB
- 各プロダクト * n
- タスク・ドキュメントデータベース
- 共有データベース
- 各データベース * n（議事録など）
良い点・悩ましい点
- 良い点
- プロダクトが増えてもワークスペースページが混雑しない
- タスクデータベースを分離したのでプロパティの自由度が高い
- 悩ましい点
- タスクやドキュメントをプロダクト単位で分けると、場所を見つけにくくなりそうだしコラボレーション起きにくくなりそう
パターン３：1チームが複数事業の複数プロダクトに関わる場合の構成案
One Product, One Team ではない場合を考える。
ワークスペースページ構成
- 会社のホーム
- 職種
- 各職種 * n
- チーム
- チームDB
- 各チーム * n
- タスク・ドキュメントデータベース
- プロダクト
- プロダクトDB
- 各プロダクト * n
- タスク・ドキュメントデータベース
- 共有データベース
- 各データベース * n（議事録など）
良い点・悩ましい点
- 良い点
- Confluenceのスペースに近い区切りでわかりやすそう
- 悩ましい点
- タスク管理DBが乱立して迷子になりそう
- ここまで分けると集約したくなってくる
- どこになにを書くか定義しておかない混乱しそう
- タスク管理DBが乱立して迷子になりそう
パターン４：ナレッジを分離して検索しやすさを上げる構成案
プロダクト管理や運用方法と混ざらないようにナレッジやFAQを分離してみる。
ワークスペースページ構成
- 会社のホーム
- 職種
- 各職種 * n
- チーム
- チームDB
- 各チーム * n
- タスク・ドキュメントデータベース
- プロダクト
- プロダクトDB
- 各プロダクト * n
- タスク・ドキュメントデータベース
- ナレッジ
- ナレッジDB
- 各ナレッジ * n
- 共有データベース
- 各データベース * n（議事録など）
良い点・悩ましい点
- 良い点
- 職種やプロダクトからナレッジを分割することでページ作成者を限定しない運用にもできそう（希望的観測）
- ナレッジ配下だけ検索すれば高い精度の結果が返ってくる
- 悩ましい点
- お気に入りや各サブページのナビを工夫しないと目的のページに辿り着くためのステップ数が多い
- どこになにを書くか定義しておかない混乱しそう
パターン５：事業部で分ける構成案
事業部で組織がうまく分かれていたら、事業部単位で分割するのがちょうどよさそう。
ワークスペースページ構成
- 会社のホーム
- 各職種 * n
- 事業部 * n
- 各チーム * n
- 各プロダクト * n
- 共有データベース * n（議事録やタスク、ドキュメントなど）
良い点・悩ましい点
- 良い点
- 事業部で分かれているので理解がしやすい
- タスクやドキュメントを事業部単位で分けるのはちょうど良さそう
- 悩ましい点
- 事業部再編が起きたときに大変そう
- 事業部横断チームやプロジェクトの扱いどうしよう
- プロダクトに関わる人がいろんな事業部にいると逆にわかりにくい
おまけ：複数ワークスペースを使う構成案
ワークスペース自体の構成も考えてみます。
NotionはSlackと同じようにワークスペースで環境を分離できます。
契約はひとつで複数ワークスーペースを使いたいという方はNotionに問い合わせてみましょう。
ワークスペースは分割すべきか
個人的には以下のようにまとめるのがいいかと思っています。
-
メインワークスペース
- 生きている情報を格納
-
アーカイブワークスペース
- 普段使わない情報を格納
- （検索対象にさせないためにゴミ箱に入れる運用は嫌なので分離）
-
ゲストワークスペース
- ゲストを招く場合に利用
- （メインワークスペースに招くことに問題なければ必要なし）
-
グローバルワークスペース
- WEBに公開する情報を格納
- （オペミス防止のため分離）
大きい会社だとメインワークスペースが大きくなりすぎるので、事業やグループ会社単位で分けるのもいいと思います。
-
メインワークスペース
- 会社もしくはグループ全体の情報を格納
- 事業に左右されない共通のナレッジを格納（人事、総務、経理、セキュリティ、各種Onboardingなど）
- 事業Aワークスペース
- 事業Bワークスペース
分割すると情報がまとめやすく検索もしやすくなりますが、サイロ化するデメリットもありますので分割し過ぎには注意。
最後に
いろいろなパターンで考えてみましたが、まさにケース・バイ・ケースですね。
個人的にはパターン４を改変したものを今は使ってみています。
使いながらやっぱりこっちのほうがよかっただろうかと頭の中で再構築してる毎日です。
なかなか自分の組織にピッタリ合った事例は出てこないものですが、Notionのユーザー事例 や各国の Notion Community を今後もウォッチしていいところを取り入れていこうと思います。