デザイン組織 gazのNotionお引っ越し【前編】
「Notion Community Advent Calendar 2022」に参加しています！
これは21日目の記事です！
昨日はkohkiさんの『フリーランスのための自己管理SFA/CRM/ERPをNotionで構築中』でした！
他の方の記事もぜひ読んでみてくださいね🙌
こんにちは！
福岡のデザインファーム gaz, Inc. でSTUDIOgatherというサービスの事業部長をしています、弘松リク(@rikchaso121)です。
今年ももう終わりに近づいてきているので、皆さんの勤め先でも年末の大掃除に取り掛かろうとしている時期でしょうか？
弊社gazでは少し遡って10月末、10Xさんの「10XのNotionを引っ越しした話」という記事を読んで感化された僕がNotion好きのメンバーに声をかけたのがきっかけで、Notion大掃除が始まることになりました！
メンバーそれぞれも今のNotionの設計に課題意識を持っていたようで話がトントン拍子で進み、年末〜年明けにかけてNotionお引っ越しPJがスタートし、絶賛実施中です👏
PJメンバーは、
設計が僕と弊社Notion大臣のトイくん(@toyux_18)
PMは弊社COOのYUICHIさん(@Yuichi_Y_JAPAN)です。
この記事は『デザイン組織 gazのNotionお引っ越し【前編】』になります。
『デザイン組織 gazのNotionお引っ越し【後編】』は本PJで一緒に設計をやってるトイくんがアドベントカレンダーで公開しています！
Notionお引っ越しPJの目的
まず今回のお引っ越しの目的を明示しておきたいと思います。
組織図と照らし合わせた説明は本記事の後半で行っていきます🙌
〜Notionお引っ越しPJの目的〜
1. 今とこれからの組織の体制に合わせて「各本部・事業部」や「サービス」における情報管理のあり方を見直す・整理する
2. 並列して「本部・事業部」や「サービス」やの管理を可視化する
3. 各本部・事業部の活動拠点となるポータルの場所を作ることで、本部・事業部ごとの情報の保存及びアクセスの負荷を下げる
4. 各本部・事業部のポータルの型を定義することで、情報伝達のコストを下げ、サービス内ならびに本部・事業部横断のコラボレーションを加速する
Notion導入〜今回のお引っ越しPJに至るまで
私たちgazは福岡のデザインファームで、主にWebサイトやアプリのUIデザインのクライアントワークを行なっている会社です。
そんなgazでは２年くらい前に、Notionでタイムラインビュー（クライアントワークで案件管理するにはこの機能がマストだった）がリリースされたタイミングで
案件管理
議事録管理
コーポレートWiki
などの用途で利用しようということになりました。
この頃のgazは
メンバーは10人ちょっと
事業はSTUDIOでのWeb制作事業がメインで、月額定額デザインサービスbeaverinがサブとして走っている感じ
事業ごとにチームが分かれているわけではなく、全員全部やる！といった体制
というフェーズでした。
ここから2年ほど経ち、今ではメンバーが40名近くに増えて事業も複数走るようになりまして。（ありがたい🙏）
Notionでの情報流通のあるべき姿が変わってきていると感じ、10Xさんの「10XのNotionを引っ越しした話」を参考にしながらNotionお引っ越しに取り組んでいくことになりました。
Notion導入当初の設計思想（2020.11）
→ メンバー10名前後・1事業+α
Notion導入当初のフェーズでの設計思想はシンプルなものです。
・メインDBはなるべく増やさない
・階層はできるだけ深くしない
このルールで設計したNotionの全体像がこちらです
メインDBは「案件」「gaz Documents」「gaz Member」の３つです。
※ gaz MemberのDBは各メンバーが自由に使っていいページになってるので内容説明を省略します。
案件 DB
当初はSTUDIO制作代行事業１本の事業形態だったので、全ての案件を1つのDBで管理
gaz Documents DB
「書く場所を迷わせない」ことを重要視して、MTGの議事録やメモ, 提案ドキュメントなど全てをここに内包する設計にした
当時は10人くらいで「一人一人が何をしているか徐々にわからなくなってきた」ことへの不安感がメンバー内であったので、このフロードキュメントDBが全社のタイムラインのようになればいいと思った
10X矢本さんとタイミーかめいけさんのPodcastを参考にして設計した
Notionお引っ越し前の全体像(2022.11)
→ メンバー40名前後・9事業（コーポレートやHR,バックオフィスも含む）
ここから2年経ちメンバーも事業もかなり増えました。
さて、Notionはどうなったか全体像を見てみましょう。
だいぶぐちゃぐちゃになりました…
これでも途中で可視化するのを断念したページがあったりします…
導入当初から用途も拡張して
案件管理
議事録管理
コーポレートWiki
各事業ハンドブック
社内PJ管理
ナレッジシェア
CRM（これから）
のように多様化してきたこともあり、設計の拡張と情報流通の整備を行うべきタイミングが来ているなと判断しました。
■ 初期の設計と今の会社規模のズレによって出てきた「弊害」
初期の設計の守備範囲を超えて会社規模が拡大したため、運用面で以下のような弊害が出てきました。
案件 DB
全事業のクライアントワークの管理を１つの「案件 DB」で行なっているため、各事業でビューとして切り出すために作成されたプロパティが乱立
gaz Documents DB
全てのドキュメントをこのDBに集めていたが、ナレッジや社外共有ドキュメント, 社内提案, 週報, 人事情報などのクローズドにするものなど多角化してきた
ビューとして切り出す・分類するためにプロパティやテンプレートが乱立している
Notionの全体像
各事業部やメンバーが独自に作ったページによって階層が深くなってしまい、情報へのアクセス負荷が高くなってしまった
■ 運用面での課題も発見
今回のような大きなお引っ越しではなく、日々運用していく上でこうしておけばよかった、という課題もあります。
プロパティの追加や階層の追加などに全くガバナンスを効かせていなかったし、方針も示していなかった
フローとストックのドキュメントの箱は作っていたが、フロー→ストックへの転換がうまく行われず、ストックドキュメントがあまり蓄積されなかった
これらはお引っ越し後に全社に方針を示して改善しつつ、ガバナンスを効かせなくてもうまく運用されていくようなNotionの設計にチャレンジしていきたいなー、なんて思っています。
デザイナー組織なので！やれるはず！UIデザインと一緒です。たぶん。
今とこれからの組織体制とNotionの設計を揃えていく
このように２年間で会社規模が拡大し、Notionでの情報流通に課題が出てきた中で、今回一番フォーカスすべきなのは
『今とこれからのgazの組織体制とNotionの設計を揃えること』
だと判断をしました。
なのでまず、前提としてのgazの組織体制について説明させてください。
サービスを持っている本部が「WEB・CI・UI」と３つあり、
全サービスを横串で刺すようにPRとマーケを担当する「コミュデザ本部」が存在します。
そしてコーポーレートを担う本部が「HX(人事)・バックオフィス・OrgaSt(COO室)」という組織体制です。
ここで本PJの目的を再度確認しますね。
〜Notionお引っ越しPJの目的〜
1. 今とこれからの組織の体制に合わせて「各本部・事業部」や「サービス」における情報管理のあり方を見直す・整理する
2. 並列して「本部・事業部」や「サービス」やの管理を可視化する
3. 各本部・事業部の活動拠点となるポータルの場所を作ることで、本部・事業部ごとの情報の保存及びアクセスの負荷を下げる
4. 各本部・事業部のポータルの型を定義することで、情報伝達のコストを下げ、サービス内ならびに本部・事業部横断のコラボレーションを加速する
今運用している上での弊害を取り除き、上記の目的を達成するための
Notion全体の設計
DB設計
運用方針 など
については、アドベントカレンダーで公開されるトイくんの記事『デザイン組織 gazのNotionお引っ越し【後編】』に続きます！！
さいごに
gazに共感しコミットしてくれる方を各ポジションで積極採用中です！！！
デザイナー
BizDev
マーケター
PR / 広報
バックオフィス など
ぜひ採用サイトやTwitterなどご覧ください😊
いいなと思ったら応援しよう！
