社内Wikiとは、従業員が業務に必要な参考情報とプロセスドキュメントを見つけられる、共有された編集可能なナレッジの拠点です。散在する文書の入ったフォルダーとは異なり、参考知識(方針、用語集、組織図)とワークフローの内容(経理の決算の進め方、製品の立ち上げ方)の両方を扱う、単一で回遊できる仕組みとして設計されています。
目指すのは、より大きなWikiを作ることではありません。会社の知識を、信頼しやすく、見つけやすく、維持しやすくすることです。ツールそのものより、その背後にある運用の仕組みのほうが重要です。
重要なポイント
- 社内Wikiがうまくいくのは、各ページに明確なオーナー、レビュー日、一貫した構造があるときです。適切なソフトウェアを選んだから、というだけではありません。
- 役割ごとの入り口、部門ごとのハブ、作業に基づくナビゲーションを使い、従業員が情報を探すやり方に沿ってコンテンツを整理しましょう。
- 公開前に価値の高いページを用意し、従業員が初日から空の検索結果ではなく役立つ答えを見つけられるようにします。
- 投稿の流れ、予定されたレビュー、そしてすべてのページのオーナーシップによって、Wikiを最新に保ちましょう。
- 定着は、ページビューだけでなく、検索の行動、古びたページ、投稿の広がりで測定します。

社内Wikiとは何ですか?
社内Wikiとは、従業員が業務に必要な参考情報とプロセスドキュメントを、会社が保管しておく共有の編集可能なナレッジの拠点です。新入社員がITのアクセス申請の手順を確認し、サポート担当者が顧客のエスカレーションの流れを確認し、マネージャーが現行の休暇制度を確認する場所です。
社内Wikiが散在する文書と違うのは、重要な一点においてです。ファイルの入ったフォルダーではなく、単一で回遊できる仕組みであることを意図している点です。全社Wikiは、参考知識(方針、用語集、組織図)とワークフローの内容(経理の決算の進め方、製品の立ち上げ方)の両方を扱えます。定義そのものは分かりやすいものです。従業員が実際にWikiを信頼し、使うかどうかを決めるのは、運用の仕組みです。
従業員ナレッジベースとしての社内Wikiの利点
うまく運営されている社内Wikiは、あれば良い程度のコンテンツ企画ではありません。人が答えを見つける速さ、互いを中断させる頻度、そして社内ドキュメントをどこまで信頼できるかを変えます。以下の利点は本物ですが、どれも同じ条件に依存します。オーナーシップと鮮度です。放置されたWikiは、そのどれももたらしません。
会社の知識の集約と、より速いオンボーディング
会社の知識が、回遊できる1か所にあれば、新入社員は当て推量をしなくなります。VPNの設定手順や経費の方針を探して同僚3人に連絡する代わりに、最初の1週間に重要なページへ導く新入社員向けの入り口をたどればよいのです。集約が最も効くのは組織の周縁部であり、暗黙知はたいていそこに隠れています。
オンボーディングを支える価値の高いページ
- アクセスとITの初期設定:初日にアカウント、VPN、SSO、役割に応じたツールのアクセス権を申請する方法。
- 方針のページ:休暇制度、経費、セキュリティの基本、行動規範。それぞれに正となる置き場所を1つ持たせます。
- チームのハブ:部門ごとの入り口ページ。新しいCSの担当者が、経理の決算ではなくエスカレーション経路にたどり着けるようにします。
- 社内用語集:新しく入った人が文脈から読み解けない略語や製品名。
オンボーディングはWikiの有力な用途の1つですが、それがすべてではありません。立ち上がり時間の指標や研修の効率については、ここで繰り返すのではなくAIを活用した社員研修とナレッジシェアリングのガイドに譲ります。重要な人が去る前に知識を記録することもまた独立した取り組みであり、組織的知識の引き継ぎプレイブックで、その引き継ぎの進め方を詳しく扱っています。
繰り返しの質問の削減と、より強い協働
どのチームにも、月に何度も答えている短い質問の一覧があります。顧客のMFAはどうリセットするのか、ブランドキットはどこにあるのか、返金の上限額はいくらか。それらの答えが検索できる全社Wikiにあれば、後から尋ねようとした人は、最初に答えた人を中断させずに見つけられます。
仕組みは単純です。一度書かれ、見つけられるようにされた良い答えは、全員の注意力にかかる繰り返しの税金を取り除きます。それが協働の利点です。知識についての会議が増えるのではなく、減るのです。落とし穴は、その場の問題は解決するものの、やがて履歴の彼方へ流れていくSlackの回答です。Wikiが機能するのは、そうした一度きりの回答を恒久的なページへ引き上げる習慣があるときであり、これは以下のベストプラクティスの節で扱う運用の問題です。
社内ドキュメントの質と統制の向上
質は、どれだけ多く書いたかで決まるものではありません。各ページにオーナー、最終レビュー日、明確なライフサイクルがあるかどうかで決まります。統制こそが、人が信頼するライブラリと、人が避けて通る山を分けるものです。
統制の構成要素
- オーナーの項目:各ページに、正確さの責任を負う個人の名前を明記します。誰も応じないチームの共通アドレスではありません。
- 最終レビュー日:読み手が一目で鮮度を判断できる、目に見える日付。
- 承認の流れ:機微なページ(セキュリティ、経理、人事)は、公開前にレビュー担当者を経由させます。
- ページのライフサイクル:ページが下書き、公開中、レビュー期限、アーカイブのいずれにあたるかを定める明確なルール。
見返りは信頼です。読み手が名前の付いたオーナーと最近のレビュー日を目にすれば、そのページを信じる可能性は高まります。どちらも見当たらなければ、代わりにSlackを開きます。統制は、従業員ナレッジベースが、人がもう信じないものへ流れていくのを防ぐものです。
全社Wikiを成功させるための社内Wikiの計画
多くの社内Wikiは、順序が逆に計画されています。チームがまずソフトウェアを選び、そのツールの既定の形にどうにか構造を押し込もうとするのです。この順序を逆にしましょう。プラットフォームを決める前に、Wikiが何のためのものか、誰が何を持つのか、コンテンツをどう形づくるのかを決めます。ツールは運用の仕組みに仕えるべきであり、それを規定すべきではありません。
目的、利用者、コンテンツのオーナーシップを定める
Wikiが果たすべき役割と、それが誰のためのものかから始めましょう。全員にとってのすべてであろうとする全社Wikiは、結局誰からも信頼されません。主な対象者(新入社員、CS、IT、経理)と、それぞれがWikiに答えてほしい主要な作業を明確にします。
そのうえで、1ページも存在しないうちにオーナーシップを割り当てます。オーナーのいないコンテンツは、Wikiが古びるよくある原因です。書いた人がすでに別のチームに移っており、内容が古くなっても誰も責任を負わないページ、というわけです。
早い段階で固めるオーナーシップの判断
- コンテンツの領域:Wikiを領域(人事、IT、CS、プロダクト)に分け、それぞれに領域のオーナーを定めます。
- ページのオーナー:すべてのページに個人のオーナーを必須とし、既定では領域から引き継がれるようにします。
- 予備のオーナー:2人目の名前を割り当て、退職によって領域全体が持ち主不在にならないようにします。
- レビューの頻度:各領域のページが、どれくらいの頻度で予定された鮮度チェックを受けるかを定めます。
これは余計な手間ではなく、運用の仕組みそのものです。オーナーシップが明確なWikiは、組織再編や退職を乗り越えやすくなります。それがないWikiは、当てにならないものになりがちです。
適切な社内Wikiのソフトウェアと権限設定を選ぶ
ここに来て初めて、ツールの問いに意味が出てきます。一般的な社内Wikiのプラットフォームは、いずれも会社の知識を十分に保管できます。以下は推奨ではなく、選択肢の紹介です。
よく使われるWikiの選択肢
- Confluence:スペース、ページのオーナーシップ、大規模チーム向けのナレッジベースの構成に強みがあります。
- Notion:柔軟なデータベースとページ構造を備え、中小規模のチームに人気があります。
- SharePoint:Microsoft 365との深い連携と、イントラネット型の権限管理が特徴です。
- Google ドライブまたはサイト:すでにGoogle Workspaceを使っているチームには導入の負担が少ない選択肢です。
選択そのものより、その上で運用する権限設計のほうが重要です。誰でも編集できるWikiは混乱へ向かい、一部の人しか編集できないWikiはボトルネックへ向かいます。最小権限を既定としたグループ単位の権限を目指しましょう。閲覧は広く、編集権限は領域ごとに絞り、誤った答えの代償が大きいページには承認の工程を設けます。機能ごとに整理された比較をご覧になりたい場合は、プロセスドキュメントソフトウェアの比較で検討すべき点を解説しています。
プラットフォームは、チームがすでに働いているやり方に合わせましょう。既存のツールと戦うことは、機能の不足よりも早く、使われなくなる道へつながります。
コンテンツの構造、分類、テンプレートを設計する
見つけやすさは、願うものではなく設計するものです。読み手が2、3回のクリックでページにたどり着けないなら、そのページは存在しないのと同じです。人が実際に答えを探すやり方、つまり役割別、部門別、作業別にWikiを構成しましょう。
見つけやすさを支える構造
- 部門のハブ:部門ごとに入り口ページを1つ置き、そのチームの正となるページへリンクします。
- 役割ごとの入り口:新入社員向けのハブと、役割別の出発点となるページを設け、まず必要なものへ導きます。
- 作業に基づく経路:組織図だけでなく、果たすべき用事(「アクセスを申請する」「決算を締める」)で整理します。
- 一貫した名前付け:トピックごとに正となるタイトルを1つにし、1つの方針がほぼ同じ名前の3ページに散らばらないようにします。
テンプレートは、デザインの取り組みではなく統制の仕組みとしてここに位置づけられます。共通のページテンプレート(オーナーの項目、最終レビュー日、目的、手順)は、すべてのページを目で追いやすくし、統制の項目を自動的に守らせます。プロセスの内容を繰り返し使える構造に変える方法については、ここで一から設計するのではなく、AIによるプロセスドキュメントが白紙に取って代わる仕組みをご覧ください。この段階での要点は単純です。テンプレートは、上で決めた構造とメタデータが実際にすべてのページに現れることを保証します。
社内Wikiの定着と社内ドキュメントのベストプラクティス
公開されたWikiは、定着したWikiではありません。定着とは、存在しているWikiと、従業員が真っ先に開くWikiとの隔たりのことです。その隔たりを埋めるには、あらかじめ用意された価値、投稿の習慣、そして何が機能しているかを把握する手段が必要です。これらを飛ばせば、よく計画されたWikiでさえ、置き換えるはずだった墓場へ静かに戻っていきがちです。
公開前に価値の高いコンテンツを用意する
空のWikiは、確認する価値がないと従業員に教えます。何も返ってこなかった最初の検索が、その人にとって最後の検索になることはよくあります。ですから期待だけで公開してはいけません。他の人がログインする前に、頻度の高い質問に答えるページを用意しておきましょう。
最初に用意すべきもの
- 繰り返しの多い質問:MFAのリセットから返金の上限額まで、チームが最も多く答えている十数件の回答。
- オンボーディングの必須事項:新入社員が最初の1週間に必要とする、アクセス、方針、初期設定のページ。
- エスカレーションとインシデントの経路:事態が急を要するとき、CSとITがどこへ向かうか。
- 正となる方針:人事、セキュリティ、経理の各方針について信頼できる版を1つ用意し、Slack上の言い伝えを置き換えます。
その最初の一群を記録することがボトルネックになりがちです。ワークフローを最もよく知っている人は、たいてい最も忙しいからです。キャプチャファーストの1つのやり方は、白紙から書くのではなく、実際の作業を記録してそれを下書きのページにすることです。この方法については入力せずにワークフローを文書化するのガイドで扱っています。最初の訪問を習慣に変えるのは、こうして用意された内容の厚みです。
投稿の流れとレビューの周期を作る
立ち上げたチームだけが維持するWikiは、早く老いていきます。目指すのは、Wikiを無法地帯にすることなく、適切な人がページを追加し修正できる、軽やかな投稿の流れです。
ページを新しく保つ習慣
- 回答を引き上げる:誰かがSlackや問い合わせで実際の質問に答えたら、そのまま流れ去らせるのではなく、Wikiのページへ引き上げます。
- 予定されたレビューの頻度:各領域のオーナーが定期的に鮮度チェックを行い、ページがまだ正確であることを確認して最終レビュー日を更新します。
レビューの頻度は、チームが飛ばしがちでありながら、最も重要な部分です。今日は誰もが信頼できるページも、まだ有効だと誰も確認しなければ、半年後には誤解を招くものになり得ます。領域ごとに頻度を定め、オーナーに責任を持たせ、期限を過ぎたレビューを形式ではなく本物の合図として扱いましょう。知識を持つ人が去る前にそれを記録する取り組みについては、属人的な知識に関するガイドで、その時期の考え方を詳しく扱っています。
利用状況、検索の行動、コンテンツの空白を測る
見えていないWikiは改善できません。定着は測定可能であり、そのデータは次に直すべきものを指し示します。最も有用な合図は、ページビューでないことがよくあります。それは検索の行動です。失敗した検索は、コンテンツの空白が手を挙げている状態だからです。
注目に値する兆候
- 結果が0件の検索:何も返らなかった検索語は、欠けているページを名指ししています。
- 検索の多い語:人が何を探しているかは、どのハブにより良い入り口が必要かを教えてくれます。
- 古びたページの一覧:レビュー日を過ぎたページを閲覧数順に並べ、最もよく読まれている古いページから直します。
- 投稿の広がり:編集が多くの領域から来ているのか、1つのチームだけなのか。オーナーシップが薄い場所が見えてきます。
これらの兆候は、対応すべき一覧として扱いましょう。結果が0件の検索はすべて書くべきページであり、閲覧数の多い古びたページはすべて実施すべきレビューです。従業員が何を探し、何を見つけられなかったのかを測ることこそ、全社Wikiが静かに古びるのではなく、その居場所を得続ける方法です。白紙からのドキュメント作成から、記録された作業への転換全般については、新しいページを支える方法を扱った分かりやすい作業手順書の記事をご覧ください。
よくある質問
社内Wikiには何を含めるべきですか?
社内Wikiには、従業員が最も必要とする参考知識とプロセスの内容を含めるべきです。方針(人事、セキュリティ、経理)、ITとアクセスの初期設定、部門のハブ、エスカレーションとインシデントの経路、社内用語集、そして繰り返し行うワークフローの正となる手順ページです。機微なデータ(給与や個人記録など)、一度きりのプロジェクトのやりとり、明確なオーナーのいないページは、Wikiに入れないでください。重要なページであれば、公開する前にオーナーを割り当てましょう。
社内Wikiと従業員ナレッジベースはどう違いますか?
この2つの言葉は重なり合い、しばしば同じ意味で使われます。従業員ナレッジベースは通常、社内の参考回答を検索できる形で集めたものを指し、社内Wikiは参考知識とプロセスドキュメントの両方を扱える、より広い共同編集の仕組みを指します。実際のところ、より大きな違いは運用の仕組み、つまりオーナーシップ、構造、レビューの頻度にあります。
全社Wikiは誰が維持すべきですか?
維持は一人が担うのではなく、領域ごとに分散させるべきです。各コンテンツ領域(人事、IT、CS、プロダクト)に領域のオーナーを置き、すべてのページに個人のオーナーを割り当て、退職によってコンテンツが持ち主不在にならないよう予備のオーナーも指定します。分類、テンプレート、レビューのプロセスは運用またはナレッジマネジメントの責任者が担えますが、実際に業務を行う人が、その業務を説明するページを担うべきです。


