Notionマニュアルのなかに、人はいなかった
「制度の墓場」になってしまったNotionマニュアルについて。
こんにちは、シュンスケです。今日のフィールドノートは、「制度の墓場」になってしまったNotion（ノーション）マニュアルについて記します。
僕たちのSlack（スラック）には、なんとなくのルールがありました。
「記事のことで迷ったらメンションして聞く」「SEOの数字を見て判断する」──そんな暗黙の了解で、チームは回っていました。
でも、そのやり方は会話の中に埋もれて消えていく。1週間前の判断基準を思い出そうとしても、Slackの過去ログを延々とスクロールするしかない。
つまり、その場では「秩序」があるように見えても、後から「あのときはどうやったっけ？」と振り返れるような「記録」にはなっていなかった。
新しいメンバーが入ってきたとき、僕はいつも同じことを口頭で説明していました。「それ、こうやります」「この場合はこの基準で判断してください」──でも、それを書き留めた場所はどこにもない。
Notionの導入は、その空白を埋めるための最初の試みでした。
Slackとスプレッドシートの限界
「これ、どこに書いてありましたっけ？」
SlackでそんなDMが飛んでくるたびに、僕は少しだけ肩を落としていました。
記事制作のルールも、WordPressの細かい設定も、内部リンクの一覧リストも、全部、僕の頭の中にだけ存在していた。
まだうぃるさんとイチさんと僕、それに数人の業務委託だけで回していた頃のことです。
Slackとスプレッドシートがすべてのインフラで、Slackのチャンネルは必要最低限の数しかなかった。やりとりはほとんどDMで完結していました。
けれども、記事数も増え、複数サイトの運用が始まると、僕が「当たり前だと思っていたこと」が、実は他の人には分からないことだったと気づいたんです。
「この記事、ワードプレスのどのカテゴリーから入稿すればいいですか？」
「内部リンクはどこに貼ればいいですか？」
「アイキャッチ画像のサイズは？」
同じような質問が週に何度も飛んでくる。WordPressで記事を公開したあとに「画像のAltテキスト入れ忘れてました」「カテゴリを間違えました」というミスも続きました。
気がつくと、僕のメモ帳には「今度時間があるときに説明する」というリストがどんどん溜まっていく。でも、その「時間があるとき」はなかなか来ない。
ナレッジの蓄積が必要だ──そう思い始めていたとき、外貨獲得サロンのつながりで紹介されたケイスケさんとDiscordで話す機会がありました。
2時間のミーティングの中で彼が強調したのは、「Notionを使ってマニュアルをつくりましょう」という提案でした。
ベテランに囲まれた新人リーダーの不安
僕はすぐに動きました。チームのナレッジを可視化し、僕がいなくても回る仕組みを作る。
プレッシャーもありました。
ちょうどその1〜2週間前、日本の仮想通貨チームのマネージャーとして正式に任命されていました。
ボスニア人の上司とそのボスのデンマーク人、日本チームのもう一人のマネージャーとのミーティングでは、僕だけ経験不足であることが浮き彫りに。
僕は当時、仕事歴1年半のライター。5-10年選手が務めるような役職に対して、経験も実績も追いついていないまま、いきなり”チームの顔"を任されたような感覚に、どう応えていいか分からなかった。
Notionは、その不安を補う制度でした。僕が叩き台を作り、うぃるさんにフィードバックをお願いして、各サイトごとにマニュアルを整えていきました。
記事の書き方、WordPressの操作手順、内部リンクの一覧、カテゴリーごとの設定……。
運用を始めたものの、しばらくして弊害が出てきます。
当時はスプレッドシートも使っており、Slackでの会話も活発。Mondayダッシュボードの利用も会社で始まっていました。
そこにNotionが加わったことで、「どこに何が書いてあるか分からない」という"情報の断片化"がむしろ加速したのです。
記事のURLが変更されたとき、それをSlackで報告し、Mondayで更新し、Notionのマニュアルでも修正する。
この三重管理の構造が、制度を"保つ"という営みを重たくしていたのです。
結果として、「Notionに書いてあることが正しい」という前提が危うくなり、「Notionを使い始めて、便利になった一方、かえって面倒になった」と感じる場面も出てきました。
マニュアルが更新されないという問題
2024年3月頃、Notionを有料課金して、チーム全体で共有し始めました。けれど、そこで改めて気づく。
「これ、誰が更新するんだ？」
そもそも、Notionは一見すると便利だが、汎用性が高すぎて、"どこから何を読めばいいか"が直感的には伝わらない。
作っている本人にとっては意味のある構造でも、他の誰かが開いたときには目的や前提が読み取れず、迷子になってしまう。
どの情報が最新で、どこまでを信じてよいのか──そうした判断を"読み手側"に委ねてしまう点で、制度としての役割を果たしきれていませんでした。
自由度が高すぎて、どこが重要で、何のためのページなのかがわかりづらい。
ウェブサイトで何らかのアップデートが発生したときに、それをNotionに反映するという"誰のものでもない作業"が僕にのしかかった。
結果、内部リンクを貼ろうとして古いURLを引いてしまう。301リダイレクトが発生する。SEO的には致命的です。
「マニュアルに書いてあったのでその通りにやりました」
そんな言葉がSlackで飛んできたとき、僕はゾッとしました。
Notionの情報はもう正しくなかった。でも、チームメンバーにはそれを検討する手段がなかった。Notionマニュアルを信用するあまり、逆に制度の形骸化を促してしまった。
しかも、誰でも編集できる仕様は、一覧表の順番を勝手に変えてしまったり、見出しを削除してしまったり、意図しない変化を引き起こしました。
便利にはなった。けれど、"制度を保つという実践"が誰にも担われなかった。気づけば、Notionは徐々に開かない場所になっていきます。
制度が制度であることを誰も信じきれないまま、Notionマニュアルは形だけを残して、放置されていきました。
制度の残骸を眺めながら
たまたま昨日、久しぶりにNotionを開きました。
そこには当時作ったマニュアルが、まるで"制度の残骸"のようにそのまま残っていた。
ある時点からは、運営しているサイトの数だけNotionマニュアルが並ぶようになった。
それぞれのサイトに独自の入稿ルールや構造が存在していました。
マニュアルはその都度つくられ、整えられました。
でもその形式は統一されておらず、編集ルールもページ構造も、サイトごとにばらばら。
マニュアル更新の基準も、誰がどこを修正するかのルールもありません。
制度はあるように見えて、実際には"保たれて"いなかった1。このタイミングで、僕たちはMonday.comへと制度の場を移します。
Slackでの即時性、Mondayでの視認性。そのどちらにも乗れなかったNotionは、制度としてではなく、記録としてだけ、そこに残されていた。
「制度」は作れば制度になるのではない。制度は、それを"保ち続ける人と実践"がいて、初めて制度になる2。
Notionマニュアルのなかに、人はいなかったのです。
マリリン・ストラザーン『部分的つながり』（Partial Connections, 1991）では、制度や関係性は一貫した全体性ではなく、断片的かつ相対的な関係として生成される。ここでのNotionマニュアル群もまた、全体を統合する制度ではなく、各メディアの運用ごとに"部分的"に生成された記述体系であった。制度としての一貫性を欠いていたがゆえに、更新の負荷も分散されず、維持されることなく放置されていった。
アンソニー・ギデンズ『近代性と自己アイデンティティ』（1991）において提示された「構造の二重性」概念に基づけば、制度とは設計された瞬間に成立するものではなく、日々の実践によって再生産される過程において成立する。つまり、制度は物として存在するのではなく、それを生きる人々の繰り返しの中で維持される。Notionが制度として形を持っていたとしても、それを日々更新する実践が伴わなければ、制度は機能停止し、やがては"制度の墓場"と化す。ギデンズが制度の「日々の再生産」に注目するなら、ストラザーンは制度の「断片性と関係性」に光を当てる。制度は設計図ではなく、人々の継続的な関わりに宿る。その視点に立てば、Notionの静寂もまた、制度のリアルを映しているのかもしれまない。