どうも、クラシルAndroidエンジニアの@MeilCliです。記事タイトルの通りdelyではドキュメント管理ツールをNotionに移行中で、その作業の一部に関わったのでいろいろと共有しようと思います
また、Notion運用を始めたばかりでベストプラクティスにたどり着けていないところがあると思うので、よりよい運用方法の知見があればコメントで共有していただけると助かります
はじめに
delyではクラシルやTRILLなど様々なプロダクトを開発しています。今までの組織構造は歴史的経緯もあり、クラシルが複数の部門にわかれている一方、TRILLは1つの部門となっていました。そのため先日組織改編があり、カンパニー制が導入されることになりました。平たく言うとプロダクトごとに部門を再編したという感じですね
一方で各カンパニーでは様々なツールが使われています。delyは情報の透明性に力を入れており、いろんなツールに情報が分散したらアクセス性悪くなるよね、カンパニーに所属している人にしか閲覧できない情報があったらまずいよねなどといった課題感が出てきたため、このたびNotionを導入することになりました
どういう経緯で関わったか
Notionを導入すると言っても、それまで使用してきたドキュメント管理ツールから既存ドキュメントを移行しなければなりません。クラシルAndroidチームでは自分がそのあたりの作業の担当となりました
一方で全社的にドキュメントは各カンパニーごとに用意したDocumentDBで一括管理しようという話になっていました。DBの設計にはエンジニアが担当したほうがいいだろうという話になり、たまたま目に入った自分にそのDBの叩きを作ってもらおうという流れになったため、自分がクラシルカンパニーのNotion運用設計に大きく関わることになりました
そもそもNotionとはなんぞや
Notionをあまりご存知でない方向けに簡単に説明をすると、WikiとDBが融合したようなツールです
詳しくは公式ページをご覧ください
階層を作ってページを作っていける他、DBに情報を入れていくことによってタスク管理やドキュメント一覧を作ることができます。DB機能はデータとなるDB本体とそれをどうページに表示するかで別れていると言え、同じDBをソースとするけどあるページではタスクボードのように表示し、あるページではロードマップのように表示することができます。このDBをどう設計し、どう運用するかは利用者次第という感じになっています
まずは運用設計をしてみる
自分が運用を考え始めた時点ではある程度の階層構想ができていました。部門・プロジェクトによる第一階層とチームや機能などによる第二階層です。全社的にあまり階層を増やさずにDocumentDBにドキュメントを集中させることで情報へのアクセス性を担保しようという考えがありました
現在のクラシルカンパニーの領域の抜粋ですが、こういう感じの構造になっています。また、画像には写せていないですがクラシルカンパニー直下にDocumentDBが配置されています
DocumentDBに格納したドキュメントをこの各階層のところで表示する必要があるので、それを表すカラムを用意しました
また、以前までのドキュメント管理で感じていた問題として、その場その時限りのドキュメントと今後もメンテし更新していくドキュメントが混ざり、情報へのアクセス性が減っていたということもありましたので、構造としてその場限りのものと更新していくドキュメント(クラシルではWikiという表現をしました)を表すことにしました
まとめると以下のカラム構造になります
- 名前
- First layer: Linked DB Viewerのフィルタリング条件で自動設定
- Second layer: Linked DB Viewerのフィルタリング条件で自動設定
- Wiki: Linked DB Viewerのフィルタリング条件で自動設定
- Tag
- Participants
- 更新日時: DBによって自動収集
- 作成日時: DBによって自動収集
- 作成者: DBによって自動収集
このDBを各階層に配置したLinked DBのViewerでフィルタリング表示しています。また、新しくドキュメントを作成するときは配置したい階層のViewerから新規ドキュメント作成してもらうことで必要なDBプロパティが自動で入力される状態になります
利用ハードルを下げる
さて、DocumentDBの設計が概ね完了した頃にある疑念が湧いてきました。果たしてNotionをみんな使ってくれるのだろうかという疑念です
今までのドキュメント管理ツールはUIの通りにドキュメントを作成すれば良いというシンプルな使い方でした。しかし、Notionは自由度の高いツールです。自由度が高い反面、覚えることが多かったり、本来やってほしくないような使われ方も当然できたりします。特に今回はDocumentDBにドキュメントを集約させていこうという運用ですので、ある程度はクラシルカンパニーの運用に沿った使い方をしてほしいのです
また、一部マークダウン記法に互換性があるものの、完全にマークダウン記法で書けるわけでもない感じになっています。今までのドキュメント管理ツールから記法が変わったり、エンジニアの方にはマークダウンで書けるのか書けないのかよくわからないという状況に陥りそうでした
そこでまずNotionの使い方ページを作ることにしました
内容は画像のような感じです
そしてこのページや運用に関するページを含む最初に読むページをクラシルカンパニー直下の目立つところに配置し、クラシルカンパニーのNotionを初めて使う人に読んでもらい理解してもらえやすくする構成にしました
ハードルはもっと下げれる
最初に読むページにはNotion自体の使い方やクラシルカンパニーにおける運用などのページがあります。それを読んで、覚えて、新しくドキュメントを書いていける自信を持ってもらうにはまだまだハードルが高いなと感じていました
幸い、NotionはGUIだけでも装飾付けしたドキュメントを書いていけるツールです。ほとんどのメンバーは新しくドキュメントを書けるようになれればそれでいいということに気づきました*1
そこでこれさえ覚えておけばいいリストを作成することにしました
Notionは動画を埋め込むことができるので最も一般的であろう記事を書く動作は動画でわかりやすく説明を加えました*2
また、自分自身を含めて、Notionでどんなことができるかを試してみたい場面があったりするので、何でもしていい空間としてPlaygroundを用意しました。Playgroundで名前と説明のとおりに、個人領域を作成してくれたらその中なら何をやってもいいよという形にしています
みんなの使い方としてはドキュメントの下書きをしたり、DBの機能を確かめたり、移行してきた既存ドキュメントの仮置き場にしたりと、様々な使われ方をされているようです
結果
結果としては利用ハードルを下げることを頑張ったのは成功だったかなと感じています。正式なアナウンスをして使い方を案内する前から、最初に読むページを閲覧してドキュメントを書いていってくれるメンバーがいたり、正式アナウンスをした際に取ったアンケートでも今のところはNotionで新しくドキュメントは書いていってもらえそうという結果になっています
課題点
カンパニー内すべてのドキュメントを1つのDBで管理するのは現実的には厳しい部分もあります。一部ドキュメントはどうしてもDBに入れれなかったり、一部部署の運用に合わせてDBのカラムを用意したりと、例外的な運用になっています
この点は今後も柔軟に対応したいと考えていますし、そもそも1つのDBで管理するのは正しかったのかは継続的に振り返っていきたいと考えています
Notionに要望を出せるとしたら分散されたDBを見た目上は1つのDBとして扱うUnion DB的な機能が欲しいところです。各階層単位などでDBを用意し、Root DBはそれらをUnionで繋げ、各階層のDB ViewerはRoot DBを表示したり、個別最適化が必要な場面では階層特有のDBを表示するということができるようになるとNotionの強みであるDBをさらに機能的に使っていけそうな感じがします
今後について
まずは新規ドキュメントをNotionで書いていってもらえるように仕組みを整備したり、各担当者と調整をしたりしていきました。今後は既存ドキュメントを移行していく必要があるので、情報資産を失うことなくドキュメント移行をスムーズに進めていきたいと考えています
また、タスク管理なども合わせてNotionで行うようにし始めているのですが、ドキュメント管理とはまた違った属性でもあるので、そのあたりもしっかり運用できていけるようにしていきたいですね
Notionに詳しい人がいたらお力添えお願いします
