SkillStack Lab運営者のスタックです。
Notionで社内Wikiを作ったものの、「マニュアルが増えるほど探しにくい」「結局SlackやDiscordで担当者に聞いてしまう」と悩んでいませんか。
私の会社でも、Notionを約20人で利用し、総務・労務、IT、セキュリティ、プロジェクト運用など数百ページ以上の社内Wikiを管理しています。
現在は業務に欠かせない情報基盤になっていますが、最初からうまくいったわけではありません。
むしろ初期は、元情シスの悪い癖で階層を細かく作りすぎ、「〇〇ツールの使い方_v1」「〇〇ツールの使い方_最新版」のような似たページまで乱立。検索してもどれが正解か分からない「Wikiのゴミ屋敷」を作ってしまいました。
スタック社内Wikiは、情報を「貯める」場所ではなく、古い情報を「捨てる」ための場所です。不要なページをアーカイブする責任者を決めない限り、どれだけ優秀な検索AIを入れても「最新の正解」には辿り着けません。
この記事では、その失敗を経て現在実際に運用している、浅い階層設計、管理責任者、最低限のテンプレート、権限分離、Notion AIを使った自己解決の仕組みまで解説します。
- Notionで社内Wikiを作る基本手順
- 数百ページ運用して分かった「深い階層」の失敗
- 読まれるWikiにするトップページの作り方
- 古いマニュアルを残さない運用ルール
- 全員閲覧・担当者編集を基本にした権限設計
- Notion AIで社内問い合わせを減らす方法
- Confluenceと比較してNotionを選んだ理由
結論｜Notion社内Wikiは「増やす」より「捨てる」設計が重要
社内Wikiを成功させるために、最初から大量のマニュアルを作る必要はありません。
私が現在重視しているのは、次の5つだけです。
- トップページの階層を浅くする
- 1つのテーマに「正解ページ」を1つだけ置く
- 各ページに管理責任者を決める
- 古いページはアーカイブへ逃がす
- 質問する前にNotion AIで検索する
Wikiのページ数をKPIにすると失敗しやすくなります。
重要なのは、「社員が誰かに質問しなくても、現在有効な答えまで辿り着けるか」です。
Notionで社内Wikiを作る基本手順
Notionには、通常のページをWikiとして管理するための専用機能があります。
- 社内Wikiの起点にしたいページを作る
- ページ右上の「•••」を開く
- 「Turn into wiki」を選択する
- Homeを社員向けポータルとして整理する
- All pagesでWiki内のページを一覧管理する
現在のNotion Wikiには、主に「Home」「All pages」「Pages I own」というビューがあります。
詳しい現在の仕様は、Notion公式「Wikis & verified pages」でも確認できます。
ただし、Wiki機能をオンにしただけで情報が整理されるわけではありません。
ここからの「どう分類し、誰が捨てるか」の方が重要です。
失敗例｜階層を深くすると誰もマニュアルへ辿り着けない
私が初期に最も失敗したのは、「分かりやすく分類しよう」と考えすぎたことでした。
たとえばIT関連のページを、次のように整理していた時期があります。
バックオフィス → IT部門 → SaaS管理 → Notion → マニュアル
作った本人からすると論理的です。
ところが、普通の社員は「Notionの操作方法を知りたい」と思ったときに、「これはバックオフィスなのか」「ITなのか」「SaaS管理なのか」まで考えてページを探してくれません。
結果としてWikiを探すより、SlackやDiscordで私に「マニュアルどこですか？」と聞いた方が早い状態になりました。
現在は第一階層を5つに絞っている
現在はトップページをできるだけ浅くし、第一階層を次のように整理しています。
| 第一階層 | 主な内容 |
|---|---|
| 🏢 全社ポータル | 企業理念、就業規則、全社のお知らせ |
| 📝 総務・バックオフィス手続き | 経費精算、勤怠、慶弔休暇、入退社手続き |
| 💻 IT・ヘルプデスク | PC設定、SaaS利用ガイド、セキュリティルール |
| 🚀 プロジェクト・業務別ナレッジ | マーケティング、AIツール検証、各プロジェクトの業務手順 |
| 🗑️ アーカイブ | 現在は使わないが履歴として残す過去資料 |
部署の組織図をそのままWikiの構造にするのではなく、「社員が何をしたくてページを探すか」を基準に分類する方が使いやすくなりました。
似たマニュアルを複数作らない
もう一つ大きな失敗が、同じテーマのページを増やしてしまったことです。
たとえば、
- 〇〇ツールの使い方
- 〇〇ツールの使い方_v1
- 〇〇ツールの使い方_最新版
- 〇〇ツール新運用
のようなページが検索結果に並ぶと、社員から見ればどれが正しいか判断できません。
検索精度以前に、「正解が複数存在する」状態を作らないことが重要です。
現行手順は1ページに集約し、旧手順が必要ならタイトルに「旧版」を付けてアーカイブへ移します。「最新版」という名前を増やすのではなく、現役ページそのものを更新する方が迷いません。
社内Wikiのテンプレートは4項目まで削った
社内マニュアルを書いてもらうために、最初は細かなテンプレートを作りたくなります。
私も当初は、作成日、承認者、関連部署など多くの項目を用意していました。
しかし、入力項目を増やすほど書く側が面倒に感じ、そもそもマニュアルが作られなくなりました。
現在、必須にしているのは次の4つだけです。
| 項目 | 理由 |
|---|---|
| この手順の目的 | 「なぜ行うか」が分からないと例外対応できないため |
| 対象者 | 誰が読む手順なのか明確にするため |
| 手順本文 | 実際の操作・判断を記録するため |
| 管理責任者 | 内容が古いときに誰へ確認するか明確にするため |
作成日などはNotion側でも履歴を確認できますし、「関連部署」のように実際には検索・判断にほとんど使わない項目は思い切って削りました。
管理項目を完璧にすることより、現場が更新し続けられるテンプレートにする方を優先しています。
ページオーナーは必要だがVerified pagesは無理に使わなくていい
Notionには、Wikiページへオーナーを設定し、その情報が最新であることを「Verified」として示す機能があります。
検証期限を設定すると、期限が切れた際にページオーナーへ通知することもできます。
仕組みとしては非常に合理的です。
私も導入を試しましたが、実際の運用では定着しませんでした。
現在はWikiの管理項目を、
- 最終更新日
- 管理責任者
だけに絞っています。
年1回の年末棚卸しをルールにはしていますが、それ以上に機能しているのが「使われたときに直す」方法です。
社員がNotion AIで質問した際に、古い情報や間違った回答が返ってきたら、参照元ページを確認し、その場で管理責任者へメンションして更新します。
Notion AIで「質問する前に自分で探す」文化を作る
社内Wikiを定着させるうえで、最も効果があった施策がNotion AIによる検索です。
たとえば社員が、
「結婚したときの慶弔休暇は何日？」
と質問すれば、Notion内の就業規則などをもとに回答し、参照元のページまで確認できます。
以前は「あの資料どこですか？」「この手続きはどうしますか？」という問い合わせが管理部門へ頻繁に来ていました。
そこで質問されたときに、すぐ答えを教えるのではなく、まず「Notion AIになんと聞いてみた？」と返すルールにしました。
これを繰り返した結果、社員が自分でWikiから答えを探す習慣がつき、管理部門の定型的な問い合わせ対応も減りました。
Notion AIは現在、ワークスペース内を検索して質問への回答に利用できます。
Notion AIの料金や、実際にBusinessへアップグレードしてどの程度費用対効果が出たかは、次の記事で詳しく解説しています。
チャットで決めたら発案者がWikiを更新する
SlackやDiscordなどのチャットで議論した内容を、そのまま放置しないことも重要です。
私の現場でも、
「今度から契約書のフォーマットはこれでいきましょう」
「了解です」
という会話で業務ルールが決まったものの、半年後に新しい担当者が入ると、また過去ログから同じ決定事項を探すという無駄が起きていました。
現在は、「チャットで決まった仕様変更は、発案者がWikiを更新するまでタスク完了とみなさない」というルールにしています。
| 情報の状態 | 置き場所 |
|---|---|
| 議論中 | Slack・Discordなど |
| 決定済みのルール | Notion社内Wiki |
| 過去の旧ルール | アーカイブ |
チャットを全部Notionへ自動保存するのではなく、人間が「これが現在の正解」と整理したものだけをWikiへ残す方が検索ノイズを減らせます。
失敗した施策｜全員にナレッジを書かせない
社内Wikiを活性化しようとして、逆効果だった施策もあります。
それが、「社員全員で週に1つナレッジを書こう」というキャンペーンです。
投稿数自体は増えました。
しかし、「とにかく何か書くこと」が目的になり、後から業務で再利用する価値のないページまで大量に増えてしまいました。
その結果、検索結果のノイズが増え、かえって必要な情報を探しにくくなりました。
Wikiの「ページ数」「投稿数」を成果指標にしない方が安全です。増やすことを評価すると、読まれない情報まで量産されます。
権限は「全員閲覧・担当者だけ編集」を基本にする
社内Wikiは情報共有のための場所なので、私の会社では基本的に「全員閲覧可能、担当者・リーダー層だけ編集可能」にしています。
全員が自由に編集できるようにすると更新速度は上がりますが、意図しない削除や内容の書き換えも増えます。
NotionではページごとにFull access、Can edit、Can comment、Can viewなどの権限を設定できます。
また、Business・EnterpriseではPersonプロパティなどを利用したデータベースのページレベルアクセスも利用できます。
ただし、細かな権限を一つの巨大なWiki内で積み上げすぎるより、情報の機密度そのものを分ける方が管理しやすいと考えています。
人事・給与・財務はメインWikiから物理的に分ける
私の会社では、人事・給与・財務などの機密情報を全社Wikiには入れていません。
Businessプランで利用できるPrivate teamspaceを使い、経営陣と管理部門の必要なメンバーだけがアクセスできる領域へ分離しています。
Private teamspaceは、追加されていないユーザーにはそのteamspace自体が表示されません。
「検索されないように設定する」だけではなく、そもそも一般社員がアクセス権を持たない場所へ分離する方が安全です。特に人事評価、給与、未公開財務情報などは全社Wikiと同じ権限設計で扱わないでください。
会社用・個人用アカウントや社内データの扱いについては、Notionを会社で使うときの注意点でも詳しく解説しています。
ConfluenceとNotionはどちらが社内Wikiに向く？
社内Wikiを検討するとき、Confluenceと比較する企業も多いでしょう。
Confluenceも、スペース単位やページ単位のアクセス制御、データベース、ホワイトボード、Jiraとの連携などを備えた本格的なナレッジ管理ツールです。
そのため、「Confluenceは古くてNotionの方が高機能」という単純な比較ではありません。
私も導入候補としてConfluenceをテストしました。
エンジニア主体でJiraを中心に業務を回す組織なら、Confluenceとの連携は非常に魅力的だと感じました。
一方、私の会社では一般のバックオフィスや営業など非エンジニアの利用者が多く、実際に触ったときのUIやページ編集の入りやすさを考えてNotionを選びました。
| 比較項目 | Notion | Confluence |
|---|---|---|
| 私が感じた編集の入りやすさ | ブロック操作が直感的 | やや業務システム感が強かった |
| データベース活用 | 柔軟にページとDBを組み合わせやすい | データベース機能あり |
| 権限管理 | ページ・teamspace・DBページ単位など | グローバル・スペース・ページなど |
| Jiraとの連携 | 連携可能 | Atlassian製品間の強みがある |
| 私の会社での判断 | 採用 | テスト後に見送り |
Confluenceの現在の権限機能については、Atlassian公式の権限管理ガイドでも確認できます。
最終的には機能表だけで決めず、実際にWikiを書く人へ触ってもらい、「このUIなら半年後も更新してくれそうか」で判断するのがおすすめです。
Notion社内Wikiを定着させた5つの運用ルール
ここまでの経験から、私なら新しく社内Wikiを作るときは次の5つから始めます。
1．最初から全社の情報を移さない
まずは総務手続きやITヘルプなど、問い合わせが多く効果を確認しやすい範囲から始めます。
最初から既存ファイルサーバーの全資料をNotionへコピーすると、大量の古い情報まで移行してしまいます。
2．第一階層を増やしすぎない
社員がトップページを開いたときに、「どこを見ればよいか」を数秒で判断できる程度に絞ります。
3．マニュアルの項目を増やしすぎない
テンプレートは管理者が欲しい情報ではなく、現場が継続して書ける量まで削ります。
4．チャットで決まったらWikiまで更新する
会話の中で決まっただけでは「組織のルールが変わった」とみなしません。正本となるWikiが更新されて初めて完了です。
5．古いページを削除・アーカイブする責任者を決める
新しい情報を書く担当者だけでなく、「これはもう不要」と判断する人を決めます。
情報量が増え続ける組織では、追加より削除の方が重要になります。
Notion社内Wikiでよくある質問
まとめ｜社内Wikiの価値はページ数ではなく「最新の正解」にある
Notionで社内Wikiを作ること自体は難しくありません。
難しいのは、数ヶ月・数年後も「ここを見れば正しい」と社員から信頼される状態を維持することです。
私の会社でも、最初は階層を細かくし、ページを増やし、情報をたくさん蓄積することが良いWikiだと思っていました。
しかし、実際には逆でした。
- 階層は浅くする
- 正解ページを1つにする
- テンプレートは最低限にする
- 編集責任者を決める
- 機密情報は別teamspaceへ分ける
- チャットで決まったらWikiを更新する
- 古いページを積極的にアーカイブする
社内Wikiは情報を貯める場所ではなく、古い情報を捨てながら「現在の正解」を維持する場所です。
すでに社内Wikiへ情報が蓄積されているなら、次はNotion AIによる検索で、社員が自分で答えを見つけられる状態を作ると効果を実感しやすくなります。
