Notionでのドキュメント管理の何がつらいか

Notionでドキュメントを書いてる。ドキュメントは書く、共有する、読むなどユーザーそれぞれ色々なシナリオがあり、そのシナリオそれぞれでつらみがある。

Notionに限らずすべてのサービスは使っていればつらいところはあると思っていて、つらいとはいえNotionから別のドキュメント管理サービスに乗り換えたいという気持ちは全くなく何がつらいのか考えNotionでなにか出来ることはないか考えたり、つらみを共有することで知見を得たい。

検索がつらい

フロー型とストック型の情報が入り乱れる

検索をする時はストック型の情報を探すことが多い。例えば、リリース作業手順ドキュメントを探したいときに「リリース 作業 手順」で検索するけど日報や議事録などは検索から除外したい。

Notionの検索には、FilterでPageの指定が出来るのでそれを駆使するしかない。Pageの指定をした場合、Pageの配下は検索対象になるので、ストック型の情報を置くPageの配下にはフロー型のドキュメントを置かないのがよい。

Filterを追加するまでの道のりが長い

command + pでQuick Findを立ち上げて検索したい文字を入力、結果が出るまで数秒待ち、結果が出たら右上のAdd Filterをマウスでクリックして、Filterを追加する。

あまりにだるすぎるのでタイトル検索をしたい時はCommand+Eを使っている。自分のアクセスした履歴から高速に検索出来る。ただCommand+Eは今インストールできなくなっているようなので、Raycastなどを使うとよさそう。またこれは自分がアクセスしたページの検索なので、新しい情報を探したい時は歯を食いしばるほかない。

Only match titlesは親のページタイトルも対象となる

これは良いのか悪いのか。僕は嬉しいと思ったことはない。例えば「SWE採用」というページの配下にある「選考内容」というページは「SWE 採用」でタイトル検索すると検索結果に出てくる。

Quick Findを開いても、検索を実行してもURLが変わらない

つまり検索結果のURLが共有出来ない。

シノニム検索が出来ない

例えば採用関連のドキュメントを探したいと思って「SWE 採用」とかでタイトル検索して全然見つからない。実はタイトルには「選考」と書かれていた時には検索結果に出てこない。まぁこれは日本語だししょうがないよねという気持ちはある。

ドキュメントを書く人間たちが利用する単語を共通化していくしかないが、そんなことを考えながらドキュメントを書くのは大変。linterなどで自動化出来れば良いが後述の通りしにくい。

自前で検索サイトを持つのはやりすぎ感ある。

遅い

検索するたびに1,2秒くらい待ってて、そのくらい待てという話だけどGoogleなどで早い検索に慣れてしまっているのでつらい

構造の管理がつらい

最高でイケてる構造がわからない

ドキュメントって会社によって内容は違うだろうしベスト・オブ・構造が存在するのかは謎ではある。会社だけではなく職種によっても違うかも。会社もフェーズによって別の会社のようになるので定期的なリファクタリングは必要そう。プログラムと一緒ですね。

ドキュメントをどこに置けばいいのかわからない

AでもあるしBでもあるみたいなドキュメントが生まれたりする。Aの配下に置くかBの配下に置くか悩む。とりあえずAの配下に置いてBのページを参照したりするけど、別の人はAとの関連性をわかっておらず、Bにあると思って探して見つからない…となる。Notionにはbacklinksというのがあって、対象のドキュメントを参照しているドキュメントを確認出来るので、Bのbacklinksを見れば発見することは出来るが、クリックしないと見れないしBにあると思ってるのでわざわざ見ない。

どこに置くべきかわからなかったらまずは「メモ」というDatabaseにページを作って書くようにしてる。でも結局書き終えたら移動する必要がありそこで困って結局メモに置きっぱなしになってしまいストックできない。

こうなるとやはり構造を見直すしかない気がする。

ドキュメントを構造化するのであれば参照関係が複雑になると大変な気がする。プログラムの設計で単一方向のデータフローがどうこうみたいな話に似てると思った。子ページは自分より上のページを参照するべきじゃないみたいな。しかし、ドキュメントって参照関係生まれがちだよなぁ

書くのがつらい

更新に意味を持たせられない

更新履歴はあるけどcommitという概念はないので変更を意味のあるひとまとまりに出来ないしcommit logが書けない。commit logがあればなぜその行を追加したのかの理由を書けるけど書けない。あとから見た時に、はて？となる時がある。

その行を追加する理由をドキュメント自体に書けばいいのかもしれないけどドキュメント自体にそれは不要で冗長になる印象

gitに慣れているからというのはありそう。

ドキュメントに対してエラーを出しにくい

GitHub Actionsみたいなのがないので変更があったらlintを実行してダメならエラーを出すみたいなのがしにくい。例えば、仕様書で特定の曖昧な言葉があった時に警告を出すみたいなの。もしかしたらNotion APIで出来るのかもしれないのでしにくいと言ってる。試していない。逆にZapierと連携出来たりするのは楽でいい

ドキュメントのステータスがわからない

タイトルにWIPをつける人もいればつけない人もいる。tagでステータスの管理をすればいいけど必須には出来ないし、ドキュメントのDatabaseによって管理されたりされなかったりするので困る。

ドキュメントのステータス管理を統一するのがいいのかもしれない。

更新しやす過ぎる

更新しやすいのでレビューを通らずに更新できたりもする。

また更新しやすいゆえに間違えて更新/削除してるときもある。こういうのは大体更新履歴を見ればわかるけど更新履歴が積み上がってわからないとき困る。

レビューがつらい

レビュープロセスが必須ではない

権限があれば誰でもどこにでもドキュメントを置ける。ドキュメントの中身のレビューもしたいが、ドキュメントをどこに置くかという観点でのレビューも当然出来ないのでカオスになりやすい。

どこが変更されたのかわからない

更新履歴はあるにはあるけど、意味があるまとまりではないし、Diffは出ないので自分の目で確認するしかない。

どこが変更されたのかわかりやすいように新たにドキュメントを書いたりするが、新しいドキュメントを書いてる途中はどっちが正しいのかわからなくなる。

変更に意味を持たせられないのでどういう意図の変更なのかわからない

書いてる通り

レビューのStatus管理などレビューの仕組み自体を自分たちで考える必要がある

書いてる通り

文章につけたコメントは文章を削除すると一緒に削除される

コメントで議論したり変更した理由を文章を引用してコメントに残しても文章を消すとコメントは消える。

まとめ

後半、つらいところだけになってしまったがいい感じになりたいのでいい感じになる方法があったら教えてください。