デザイン組織 gazのNotionお引っ越し【後編】
これは「Notion Community Advent Calendar 2022」の22日目の記事です！
前回のリクさんの「gazのNotionお引っ越しPJ【前編】」と連作になっています！
他の方の記事も超良いので是非読んでみてください！
こんにちは。トイです。
福岡のデザインファームgazでUI Designerをしています。
今回、社内で「ワイも社内Notionもっといじりたい！」って騒いでたらgazのNotionお引っ越しPJに招待されました。歓喜。
その後、Notion担当大臣を引き継ぎました。歓喜。
ということで前回のリクさんの記事のまとめから書いていきます。
【前回のまとめ】弊社Notionの課題
データベース(以下、DB)の課題
弊社では、全社で使うDBは「案件DB」「ドキュメントDB」のふたつで運用していました。(他に細かいのもあるけど使用頻度の高いものはこの二つ！)そこで出た課題は下記の通りです。
WEB制作やCI制作、準委任型のUI制作事業など契約携帯の違う案件を一つのDBのプロパティで管理していたことによる「案件DB」のプロパティの複雑化
全てのドキュメントを一つのDBに集めていたが、ナレッジや社外共有ドキュメント, 社内提案, 週報, 人事情報などのクローズドにするものなど多角化してきたため整理が必要になったこと
運用の課題
プロパティの追加や階層の追加などに全くガバナンスを効かせていなかったし、方針も示していなかった
フローとストックのドキュメントの箱は作っていたが、フロー→ストックへの転換がうまく行われず、ストックドキュメントがあまり蓄積されなかった
Notion全体の課題
各事業部やメンバーが独自に作ったページによって階層が深くなってしまい、情報へのアクセス負荷が高くなってしまった
課題の発見や今までのNotion構築の経緯の詳細は【前編】の記事をお読みください。
では、こんな課題あるよね〜ってことがわかったので実際にどうやってリニューアルのプランを練ったのかをお話ししていきゃす。
最初にやったこと
まずCOO室のメンバーと課題からリニューアルの目的と手順を決めました。
この時、いつ引っ越すのかの期限は1月くらいとやんわり決めています。僕も他のメンバーも案件をしながらのサブプロジェクト的な立ち位置のプロジェクトだったので負担にならないようにするためです。
リニューアル目的
1. 今とこれからの組織の体制に合わせて「各本部・事業部」や「サービス」における情報管理のあり方を見直す・整理する
2. 並列して「本部・事業部」や「サービス」やの管理を可視化する
3. 各本部・事業部の活動拠点となるポータルの場所を作ることで、本部・事業部ごとの情報の保存及びアクセスの負荷を下げる
4. 各本部・事業部のポータルの型を定義することで、情報伝達のコストを下げ、サービス内ならびに本部・事業部横断のコラボレーションを加速する
手順
1. 全体の移行方針を決める
2. 組織の構造とNotionの構造を一致させる
3. その他のコンテンツの方針を決める
4. 具体的な引っ越しプランを作る
以上をキックオフMTGで決め、その後は週一で各々のタスクの確認や議論したいことを持ちよる定例を設け、お引っ越しの構想を固めていきました。
以下、手順にそってどうのようにお引っ越ししたのかを書いていきます。
全体の方針を決める
こちらは先程のキックオフMTGでほとんど終わっています。
課題の整理、参考Notion収集などをし、今後どのようなプランで進めていくのかを話しました。
結果、最初にFigjamで組織構造の整理やNotionの設計を行い、その後に主要DB構築、全体のページデザインをしていくプランとなりました。
組織の構造とNotionの構造を一致させる
次に弊社の組織構造を整理しました。下の図がそれです。この組織図は10X udonさんの「10XのNotionを引っ越しした話」のnoteを参考に作成しています。
7つの本部があり、その中に事業部があります。そしてそれを横断するようにサービスが存在しています。
これを元にNotionの構造を整理したものが下の図です。
弊社のNotion設計の思想として、ガバナンスを効かせなくてもうまく運用されていくようなNotionの設計を目指します。つまりどういうことかと言いますと、ガバガバガバナンス運用ということです。
teamspaceの活用
上の図はteamspace、第一階層、第二階層に分けて設計しました。
引っ越し前の弊社のNotionはteamspaceリリース前に作成されたので、teamspaceを活用しきれていませんでした。teamspaceはページのカテゴリ分けが容易にできるので是非導入したく、このような階層分けにしています。
teamspaceにポータルを設置
基本構造は、teamspaceの中に各事業部のポータル(各事業部のHOME)を配置し、プロジェクトDBとドキュメントDBを事業部ごとにフィルターしたものを配っておき、その他のカスタマイズは事業部ごとに委ねます。
新たにハンドブックを設置
今までgaz Homeというページの中に各事業部ページが子要素で配置してあり、その中の総務や労務などにハンドブックの内容が入っていました。しかし、業務に使うページと閲覧するのが目的のwikiのようなページは分けたほうが良いという思想の元、新たにハンドブックを作成しました。
目指すはゆめみさんのオープン・ハンドブック！(久しぶりに見たら進化してた！すげえ！)
Cultureページはハンドブックとは別のページとして扱う
弊社は会社独自のカルチャーを大切にしている会社です。ということで、ハンドブック内のではなくそのままサイドバーから直接アクセスできるように
ハンドブックとは独立させています。
データベースについて
今回、ドキュメントなどの全社で扱うDBの設計も大きく変えました。
以前までの全社で使うDBは2つ「案件DB」と「ドキュメントDB」のみと課題のところで書いたのですが、リニューアルでDBを以下の４つに分けようということになりました。
「プロジェクトDB」
「クライアントDB」
「ドキュメントDB」
「ナレッジ/社内報DB」
具体的には、「案件DB」を「プロジェクトDB」「クライアントDB」に分岐させ、「ドキュメントDB」は「ドキュメントDB」「ナレッジ/社内報DB」に分岐させるという構造です。
案件DBを分けた理由
案件DBに基本的にはクライアントさんの名前を記入していましたが、同じクライアントさんで違うプロジェクトが走ることがあるので、その際に命名規則がズレることがありました。それで請求が発生するタイミングにバックオフィスのメンバーが困ってしまう場合があったので、プロジェクト管理とクライアント管理は分けて管理しようとなりました。
また、案件DBではステータスプロパティでの営業管理とページ内でのプロジェクト管理を同時に行っていたので、1つのオブジェクトに2つの機能を持たせてしまっていました。この機能を分断させることでDB構造がきれいになります。
ドキュメントDBを分けた理由
これは単にプロパティの乱立がすごいことになっていたからですね。業務関連のドキュメントと、ナレッジや弊社でときどき誰かが勝手に発信している社内報は別の方が管理しやすいということでこのようにしました。
リレーションで各DBを繋げる
「プロジェクトDB」は「クライアントDB」「ドキュメントDB」とリレーションで繋げて運用します。
ざっくりとこんな感じ。
まず、クライアントDBは正式名称(株式会社は省略)で入力してもらいます
そしてプロジェクトDBのタイトルはプロジェクト名を記入してクライアント名は含ませないようにします。どのクライアントさんと何のプロジェクトをしているのかがわかりやすいです。
ドキュメントDBでは、プロジェクトDBとリレーションしてプロジェクト名を表示させます。ついでにロールアップでプロジェクトDBにあるクライアント名を引っ張ってきます。
各DBのテンプレ設計とかも書きたいのですが流石に長すぎるのでまたの機会に書きます。
DBについては以上です。
続いて運用面をちょこっとだけお話しします。
運用について
・DBは少なく運用
DBを少なくすることで、新メンバーが弊社Notionを最初に見たときに何がどこに書いてあるのか、どこに書いていいのかが瞬時に判断できます。また、テンプレートの運用がしやすいです。
「さっきDB増やしてたよなあ…！」
「いや、そうなんですが、流石に増やした方が運用しやすいなあ思うて、、」
好きに使ってもらう
トップダウンでページ規則や運用方法をガチガチに決めてガバナンスを効かせるというよりかは好きに使ってもらう運用にします。それがgazっぽいし使ってて楽しいと思うからです。これがガバガバガバナンス運用です。
全社で展開しているDBの「プロパティが消えた！」「Rollupが解除されてる！」などの緊急事態にはNotion強強人間が対応するようにして、セーフティネットは引きます。
最後に
実際に設計してみて、Notionの設計は楽しいな〜って感じました。(浅い)
注意点と言うかしょうがないことではあるんですが、Notionを全社的に様々な用途で使おうとすると、Notionに詳しい人が一人は居る必要がありそうだなと思いました。これは、先日のNotion Meetup Kyoto でTsuburayaさんもお話ししており、うんうん頷きながら聞いてました。
🤔 Notion を複数人で運用するときのコツとかってある？自分が思ってるところだと、
— Tsuburaya | Notion 公式アンバサダー (@___35d) November 28, 2022
・Notion 大臣を決める
・ページの管理人を書いておく
・ページ配置のルールは予め設計しておく
とかかなって思ったけど、他こういうの工夫してるよってある？
なるべくテンプレを設定したりシンプルにすることで運用負荷を下げたり、そもそも公開されているテンプレなどを使用することでうまく運用できるかもしれません。
以上で終わりです。
ありがとうございました( ^ω^ )
この記事が気に入ったらサポートをしてみませんか？