10XのNotionを引っ越しした話
TL; DR
私の働く10Xという会社ではNotionを様々なドキュメントの格納場所としており、いわばオンライン上のオフィスになっています
2022/10から組織構造が変わったことに関連して、そのNotionの構造を見直し、引っ越しを行いました(絶賛引っ越し途上)。オフィスのレイアウトを変更し、席替えをするイメージです
引っ越しに際にしての思想や具体的にどういったことを行うかについて記載します
本編
思想・課題意識
私はちょうど1年前に10Xに30人目台として入社しました。そこから半年で1.5倍、1年経って100名近い組織になりました。半年前の時点でも、組織拡大により沢山のドキュメント(=情報)が日々生み出される状態にになっており、社内の情報流通のあるべき姿を見直さないと後で大変だな.. といううっすらした危機感を(勝手に)いだき、情報流通どうするのがいいか考えてみるべ？ということで津軽マッチョの@yamotty3、岡山のモダン情シス@m1104m、生粋の関西@udonの3人で検討をはじめました。10Xでは今年の年始からフルリモート制になっており、地方在住のメンバーがバチバチに活躍しています。
「情報流通」に含まれる論点は多く、抽出した課題(社内では「イシュー」と呼ばれている)の解決はまだまだ途上です。その中で、特にNotionにおける情報流通、特に全体の構造について手を入れた過程について記述します。
引っ越しにあたり、下記のイシューを掲げました。
各本部の活動拠点となるポータルの場所を作ることで、部門ごとの情報の保存及びアクセスの負荷を下げる
新組織の体制(本部/部)に合わせて各本部における情報管理のあり方を見直す・整理する
各本部(または役職別)のポータルの型を定義することで、報伝達のコストを下げ、本部内ならびに本部横断のコラボレーションを加速する
10Xでは「イシュー」という言葉がよく用いられますが、「〇〇をどうするか？」(疑問形)や「▲▲が最適化されていない」(問題提起形)ではなく「□□を構築する」(あるべき姿系)という形式が多くとられています。
やったこと
全体の移行方針を決める
組織の構造とNotionの構造を一致させる
その他のコンテンツの移行の方針を決める
具体的な引っ越しプランを作る
1. 全体の移行方針を決める
元々第一階層には6つ(図の一番左の項目)がありました。これらを、新設された本部ごとに分割し、合わせて元々のコンテンツの移動・整理を行っています。真ん中の薄いグレーがNotion社が直近ローンチしたteamspaceにあたる部分です。
10Xでは「チーム」「プロジェクト」という言葉を下記のように定義しています。これまで部門を横断する取り組みはざっくりこういった言葉で呼ばれてきましたが、基本は本部/部が活動の基軸となるので、あえて言葉を分けています(なので本稿でも部門と混合しないよう、「チーム」や「プロジェクト」という言葉を使わないようにしています)。
実際には「プロジェクト」という言葉はとりあえずの取り組みとしてはよく出てくる言葉であり、こうした探索的な動きは止めるものでなく、むしろ促進するものであります。ただし、実際に目的の解像度があがった段階では、そうした横断的にはきちんとリソースを投下され(ると明示され)、各個人やその周囲の人もその認識を持って進むのが健全だと考えます。「これちょっとお願い」というのは実際にはありますが、度がすぎると個人に負担がいき、10Xの目指す持続可能な働き方に少し反してしまうとも考えます。そのため、あえて「チーム」「プロジェクト」という言葉を定義しています。
2. 組織の構造とNotionの構造を一致させる
10Xは2022/10に組織の体制が変わりました。名をマトリクス組織と言います。詳細は我らが津軽マッチョ@yamotty3が書いてくれています。
組織はこんな感じになりました。箱が沢山ありますね。
これまでは、Corporateページ(社内お知らせページ)の中にコーポレート部門で進めている取り組む過程のメモがあったり、「Stailer」というページに戦略から営業パイプラインの状況、一部のチームの内部のページ等が混在している状況でした。
今回の引っ越しで一番大きいのは、本部/部という組織の体制にあわせて、それぞれページ(=「ポータル」と呼んでいます)を作成したことです。上記のように、会社の中に沢山箱ができましたが、まだその中身は1,2人だったり、兼務のメンバーがいたり、といった状況です。それでも、組織は箱を配備した上でそこから発展していくので、まずは箱を置くことは重要なのです。
と、おととい人から聞きました。
そのため、逆に言えば、1,2名しかメンバーがいない部分についてもポータルを配備しています。オフィスのシマを確保しておくイメージですね。もちろん今後運用していく中で不要になればアーカイブしていきますが、重要なのは組織の体制と沿っていて、齟齬がないということです。ちなみにSlackについても今回のタイミングで組織の体制に合うように @m1104mがほぼ全てのチャンネル名の変更/命名規則の変更をしてくれています。組織体制が変わると、Day1からすっとすべて理解するのは困難だと思います。これらは即効性があるものとは思いませんが、こうした細部での齟齬をなるべく減らすことは、長い目でじんわりと染み渡るものだと思っています(出汁みたいですね)。
本部/部ポータルの構造や工夫については後述しますが、各本部/部が、心置きなく自分の部門に関わる議論や検討、分析を進めてもらえる、いわばホームベースを確保したいという意図が大きいです。なにか思いついたとき、議事録をとるとき、「どこに書いたらいいかな？」のラグを極力減らして、そういったときに気にせず書き出せる。10Xは透明性を重要にしている会社だからこそ、内輪感を遠慮なく出せる場を作ることを意識しました。ただし、すべての本部ポータルは全社に開かれているものなので、アクセス自体は誰でもできるようになっています。
2. その他のコンテンツの移行の方針を決める
本部/部については上記で記載しましたが、社内お知らせであったり、全社的なものであったり、本部横断的なものもあります。割と素直に移していますが、引っ越しにあたり意識した部分は下記です。
[本部/部ポータルへの引っ越し] 全社お知らせページと裏側の取り組み(公開に向けてのコーポレート部門のタスク管理等)は切り分け、後者は本部/部ポータルへ。
[お知らせのマスタの管理] 全社お知らせや社内制度の案内等はお知らせページにマスタを置くのでなく、それをメンテする主体の本部/部のポータルのストックドキュメントDB内にマスタ(親)を置き、お知らせページにはmentionでアイコン or linked database(子)で置く。これにより(a)メンテの主体を明確化する (b) ふとしたことでオリジナルのドキュメントを削除しちゃうエラーを防ぐ 効能があります。
[公開範囲の制御] 社員向けのみ公開の情報は切り分ける。10Xは業務委託やトライアルで関わって頂いている方々へかなり情報をオープンにしており、その方針は変わりません。ただし、最低限制御すべき情報(例 ファイナンス関連)のみ切り分けています。
[本部横断的な取り組みのポータル] 本部横断のプロジェクト/チームのページは別途作成。
3. 具体的な引っ越しプランを作る
組織体制が変わる2022/10になる直前に全体へ方針をアナウンス、以後10月に各本部に対して引っ越しをしてくださいというアナウンスをしました(なので、これを買いている最中は進捗60%というところで、絶賛引っ越し中です)。
全社のアナウンスに加えて本部長のメンバーには個別にチェックインはしたものの、概ね方針に対してメンバーが素早く理解してくれているため、引っ越しは進んでいます。
本部/部ポータルの構造について
ざっくりこういう構造になっています。
前述したように、各本部/部で内輪感を持って作ってもらえたらという思想なので、 基本は各本部に構成をおまかせしています。以下、検討・工夫したことをいくつか記載します。
本部⇔部でのドキュメントのDBの配置
22/10の組織体制変更により10Xには9の本部が生まれましたが、各本部によって、人数も・活動の単位も様々なのです。なので、ドキュメントを作成する際に、本部単位なのか部単位なのかも様々です。今回は、ドキュメントのDBについて「各本部ポータルにマスタを置き、部ポータルはlinked databaseとしてコピペし、フィルタで部のものを表示する」ことにしました。これにより、本部(長)視点では、配下の各部主体で作成するドキュメントを見落とすことを防げますし、各部(長やメンバー)からは自分の部に関するものしか表示されないので、ノイズを防ぐことができます。
次に、ドキュメントの種別です。
ドキュメントの種別は、ざっくりいうと、(1) ストックドキュメント (2) フロードキュメント があります。全社は仕様書であったり企画書であったりするもの。後者はちょっとした作業メモや、議事録といったものが該当します。(2)は究極的には一定期間をもって、削除またはアーカイブしても良いドキュメントです。
ここの境界線は うどんvsそばくらいの論争もありそうなので今回は踏み込んでおらず、一旦各本部におまかせしています。また情報量が溜まったら考えてみたいとは思っています。一旦今回は、
10X内で「ストックドキュメント」という呼称は市民権を得ている印象があった
逆にフロードキュメントはやや曖昧で、その代表格である議事録は日々量産されている
ことから、ストックドキュメントDBと議事録DBをデフォルトで配備しました。
なお、議事録は、社内でMTGメモ、議事メモ等々呼称のゆらぎがあり、このゆらぎに特に大義はないと思ったので社内でアンケートをとった上で民主的に「議事録」となりました(ニホンゴッテイイヨネ)。
ストックドキュメントがスタックしている問題
本部によっては、ストックドキュメントの総量が多く、毎回DBから探そうとすると、たとえばプロパティでタグをつけていて大変、という部門もありました。ストックドキュメントが累積(=スタック)しているケース。
そうした部門では、すべてのドキュメントのマスタはストックドキュメントDB内においた上で、そこからmentionしてコピーして、重要 and/orよく参照されるものは平置きアイコンで置く、という取り組みをしていました。これにより、アクセスは担保した上で、ドキュメントのマスタはDB内にあるという状態を担保できます。
DBにフォーマットを標準配備
NotionにはDBごとにフォーマットを整備する機能があります(使ったことのない人はぜひ使うべき機能ベスト3にはいると思います)。これを使って、上記のストックドキュメントDB 及び 議事録DBに標準フォーマットを整備しています。
これはかなり一般的なものなので、必要があれば各本部, 部で整備してもらう想定なので絶対にこのフォーマットで、というものではありません。ただ議事録の書き方は100パターンはなくていいと思うので、思考が減るもは思考をへらす仕組みを活用するのがいいと思います。
部門外のメンバー向けのセクション
各本部/部のポータルの一番下に、部門外のメンバーに向けたセクションを設けています。これは、各本部/部に対してよく聞かれることや、よく参照されるドキュメントを置く場所です(例: PRに関わる基準)。メンバー紹介もあります。
……
以上です。
今引っ越ししたばかりなので、検証はこれからです。また続報があれば記載したいと思います。
追伸
約6,000文字の文章となりました。
最近は会社の3/4のCxOに「話が長い、文章も長い」と言われることはおろか、相方からも「相手が食べきれない肉団子をぶん投げている」と釘を刺されます。ちょっと話はそれますが、この前カナダに行って、Meat ball(≒肉団子)を食べてきて、やっぱ美味いなァと思いました。これからも懲りずに肉団子を投げていこうと思います。
上記、色々検討や実際の移行をしましたが、完璧だとは思いません。これからの数ヶ月でも、色々とフィードバックをもらって変えていく部分もあるかと思います。
Notionの工事に関心がある方はぜひお話しましょう。特大肉団子をもってお待ちしています。
10Xで実施している新メンバー向けのNotionオンボーディング(中級編)についてもまた書きたいと思います。
Appendix
余談1)
そもそも課題意識を抱いたのは、病的に(?)フォーマット化を推すコンサルでの経験によるものが多いと感じています。
フォーマット化に一定の抵抗感を示す人もいますし、私も「フォントサイズが2pt大きいとか2つのテキストボックスの左側が揃ってないだけでf***ってスライド破るなんてことある？」と思ってました。だがしかし、デザインの世界でないのであれば、16ptを使うのか17ptを使うのかでの差分はあまり意味がなく、むしろそこに思考の余地やゆらぎを与えることが無駄だということを得心しました。
個人的な経験としても、フランスやアメリカで働いたときも、Day1からインプットをもらわずに現地メンバーと資料を作成していくことができました。左に揃える必要ある？と言ってる暇があったらAlt+H+G+A+Lを体に染み付かせた方が早いし、16pt or 17ptに1秒の思考を使うのであれば、もっとクリエイティブなことに時間を使うか、ビールを飲んでる方がよっぽどいい。
余談2)
海外だと、こういう情報整理を専門とする職種があるようです。私がいたコンサルではKnowledge managerという職種があり、コンサルの中でどの案件でどういった情報があったか・どう情報を蓄積させるべきか・リサーチをどう進めるべきかについてフィードバックをくれるKnowledge managerという役職が存在していました(例)
この記事が気に入ったらサポートをしてみませんか？