入社後に感じた課題から出発し、組織変化など会社の変化に柔軟に対応できる構造に Notion を再設計しました。運用も安定し、課題の解消にもつながったカイゼンとなったので、どなたかの役に立てばと思い、検討や整理の過程をシェアしています。

 

---

 

こんにちは！

デジタルマーケティング会社勤務を経て、2023年の11月から入社したニューピースのえくぼです！現在はDigital Transformation Unit で、ブランディングをデジタル面からサポートしています（ブランド戦略に合致した指標の設計、ワークフロー整備およびデータパイプライン設計など）。

 

突然ですが、みなさんの会社は「Notion」を使っていますか。

個人での情報管理はもちろん、組織の情報ストックやタスク管理などにも幅広く活用できる便利なサービスですよね。弊社はドキュメント管理からタスク管理まで Notion をがっつり使用しています。

 

わたしも転職してから使い倒してみましたが、Notionは便利なツールですね！同時に、キャッチアップで苦労することも多々あり、変化の激しいスタートアップで「安定的に運用」するには工夫が必要だと考えました。

 

自分が苦労した原因を探り、解決できる運用方法を設計してみたので、知見として共有します！同じ悩みをもつスタートアップの方など、どなたかの参考になれば幸いです。

第1章：Notionの概要と活用例

 

みなさんご存じかと思いますが、NotionとはアメリカのNotion Labs社が開発した万能アプリ。メモやタスク管理、Wiki、データベースなどさまざまな機能を一元的に使うことができます。

 

Notionの特徴はデータベース機能にあります。

Notionのデータベースは、ページの集合体で、① すべてのアイテムが独自の編集可能なページ ② カスタマイズ可能なプロパティ ③切り替え可能な複数のレイアウト がスプレッドシートなどとは異なる特徴です。

（詳しくはこちら：https://www.notion.so/ja-jp/help/intro-to-databases）

 

 

このデータベースはめちゃくちゃ便利で、使いこなすことで Notion 活用の幅が広がります。

 

例えば、リレーションで関連付けた項目の値が利用できる機能（[ロールアップ] https://www.notion.so/ja-jp/help/relations-and-rollups）。これを使うことで、

別のテーブルの値を参照して計算することができます。プロジェクトとメンバーでリレーションを張っておくと、メンバーごとにアサインされているプロジェクト数を計算できたり、メンバーあたりの稼働効率などを常に表示することが可能になります。

 

つまり、Notion の「便利さ」はデータベースの活用にある！と、言って良さそうです！

 

第2章：柔軟な変化に翻弄されるドキュメント管理

 

 さて、ここから本題です。

「VUCAの時代」などと言われて久しい昨今ですが、さらに ChatGPT や Midjourney など生成AIが発達し、変化の激しさは増す一方です。企業はその環境に対応しながら、変化し成長していくことが求められています。

 

特にリスクの高い挑戦をするスタートアップ企業では、その不確実性に対処するために様々なアクションを取りつづける必要があり、「柔軟な組織変更」もその1つとなっています。例えば、ユニコーン企業入りをしたSmartHRでも大きな組織変更が実施されています（参考：https://note.com/smarthr_co/n/na599510afea4）。

 

ただ、組織変更の影響は大きく、多岐に渡ります。少なくない影響をうけることの1つに「ドキュメント管理」がありますよね。

 

新しい部署の誕生や名称変更によって、存在しない部署の配下にドキュメントが残ったままになっていたり、関連するドキュメントが複数の部署配下にバラバラに置かれていたり、挙句の果てには管理ルールが部署ごとに局所最適化されている、なんて事になっていると、もう大変。求めてるドキュメントは一体どこにあるんだ！と、てんやわんやです。

 

ニューピースでも、わたしが入社した時点で、過去の部署名の配下にドキュメントがあり、「結局正しい情報はどのユニットのチームスペースにあるの？！」、「他ユニットの情報は、ユニットごとにルールが違って探しにくい！」などの困りごとに直面しました。

※ ニューピースは部署の単位を〈ユニット〉で管理しています。

 

 

Notion に詳しい方なら「検索機能は使わないのか？」と思うかもしれませんが、実際には重複した情報が別Unitにある場合も多く、どっちのドキュメントが公式で運用されているかなどは検索機能だけでは解消しきれません。

 

どうして、だれも悪気もないのにこうなってしまうのか。

「ドキュメントをツリー構造で表現している」のが問題なんじゃないか、と閃きました。

 

ツリー構造は各Unit配下にフォルダを格納する形なので、わかりやすく採用が容易なのは確かです。ですが、部署の配下にそれぞれのドキュメントが管理されているため、組織変更のたびに面倒な移行作業が発生（または放置）してしまい、着実な負債が積み上がっているのではないか、と。

 

当時の組織の名称やドキュメント管理ルールを知らなければスムーズに情報にアクセスすることは難しいでしょう。そもそも欲しい情報がどの時期の情報かわからない場合は、過去の部署の内容全てを確認しなければいけないかもしれません。

 

Notion もデータベースというユニークな機能があるのに、ルールがないまま使い始めてしまうと、うっかり慣れ親しんだ Google Drive や Dropbox のようなツリー構造で表現しがちです。

 

ということは、ガッツリ設計を変えつつ、会社の全員が理解できる形まで整理する必要があると思い、「Notion の思想に則りつつ運用しやすい設計」を考え、導入してみました。

 

第3章：「タグ」を活用することでSSOTを実現

 

「Notion の思想に則りつつ運用しやすい設計」とは、タグを使った仕組みです。

まず、会社の全体情報を管理するチームスペースを作成し、ドキュメントを作成するページや、タグを作成するページを会社全体のチームスペースのみに絞ります。

 

そして、Unitごとのチームスペースを作成し、会社全体のチームスペースのデータベースを引っ張ってくるような形にすれば、会社全体の情報は、会社全体のチームスペースに溜まりようになります！

 

以前はツリー構造で捉えていたものを、新しいドキュメント構造では、タグでドキュメントを繋げるイメージです。

 

 

また、Unitのタグを作成すれば、Unitごとのチームスペースで各Unitのみの情報を閲覧することができるようになります！タグは変更・追加が自由に可能なので、組織編成にも対応して会社全体の情報＝ナレッジを貯めることができるようになります！

 

タグ構造にすることで、ドキュメント種別ごとに一意に管理することができ、情報管理の原則であるSingle Source of Truth（SSOT）の実現に繋がっていると言えます。

 

 

このような設計にすることで、会社全体のチームスペースに情報が一元化されているため、情報がどこにあるかわからない！ということはなくなります。

 

 

また、他のUnitの社内議事録を探そうという場合にも、会社全体のチームスペースと同じ構成でドキュメントが溜まっているため、難なく社内議事録の場所にアクセスすることができると思います。

 

 

さらに、最新情報に関しても会社全体のチームスペースのログを見れば確認できるでしょう。

 

第4章：まとめ

 

まずは私が所属するユニットからはじめ、プロダクトやコーポレートなどに段階的に社内に浸透させていますが、第2章で示した「情報が一元化されない」、「各Unitごとにルールがあって情報がアクセスできない」という課題を解決できていると感じています。

 

今回はドキュメント管理に限定しましたが、プロジェクトやタスク管理など、まだまだ改善の余地はあるので、ユーザーの意見を汲み取りながら、カイゼンのサイクルを回していきたいと思います。

 

どなたかの参考になれば幸いですし、「もっとこうしたら良かったよ」あればぜひ教えてください！

 

---

NEWPEACEは、一緒に働くメンバーを募集しています！
募集中の職種は、こちらからご確認いただけます。

案件のご依頼や相談については、こちらのフォームよりご連絡ください。