ナレッジ共有が定着しない理由｜4つの原因と「仕事の中に置く」直し方

公開日 2026年9月20日執筆 ChordOne読了 約8分

「ナレッジ共有ツールを入れたのに、書く人が固定され、半年後には更新が止まった」。この相談で最初に疑うべきなのは、社員の意識ではありません。共有が本来の仕事とは別の追加作業になっていて、書いても読まれず、読んでも古い、という構造です。この記事では、定着しない原因を4つに分類し、それぞれに対応する直し方を「仕事の中に置く」という一つの考え方でまとめます。担当者列と権限が名簿に追従すると何が変わるか、定着を何で測るか、最初の30日で何をするかまで整理します。

ナレッジ共有が定着しないのは、社員の意識の問題ですか？

ナレッジ共有（ナレッジきょうゆう）

個人の経験や判断基準、手順といった知識を、他の人が読んで使える形（形式知）にして組織に残すこと。社内Wiki・マニュアル・議事録・FAQ などの形をとる。「共有する文化」の話として語られがちだが、実際には「どこに書くか」「誰が更新するか」「どう探すか」という運用設計の問題であることが多い。暗黙知と形式知の違いは 用語集 を参照。

「書く文化を作りましょう」と呼びかけて改善した組織は少ないはずです。呼びかけの直後は投稿が増えても、数か月で止まります。忙しいときに「時間が余れば書く」ものは、優先順位の最後尾に固定されるからです。逆に、書かなくても仕事が回る状態で共有が続くことはありません。共有が仕事の一部になっている（書かないと自分の仕事が進まない）状態を、仕組みとして作る必要があります。

この記事では、定着しない原因を4つに分類し、それぞれに対応する直し方を「仕事の中に置く」という一つの考え方でまとめます。ツールの入れ替えを前提にしない書き方をしていますので、今使っているツールのままでも試せます。

定着しない原因は、どう分類できますか？

4つは独立ではなく、1が起点になることが多いです。書く場所と仕事が離れていると、Wiki を開く頻度が下がり、更新の遅れに誰も気づかず（3）、古い情報が残り（4）、信頼を失った Wiki には大事な情報を置かなくなる（2）という順に悪化します。逆に言えば、1を直すと残りも直しやすくなります。

「仕事の中に置く」とは、具体的に何をすることですか？

入社準備表、社内依頼の受付一覧、研修計画、備品台帳。どの会社にも、担当者が毎日開いている表が1つはあります。いま表計算やチャットで回しているその表を、Wiki の中の管理表（データベース）に移します。すると、担当者は仕事のために Wiki を開くようになり、その隣にある手順書も自然に読まれ、手順が変わればその場で直されます。

移す表を選ぶ基準は3つです。(1) 担当者が週に何度も開く、(2) 行ごとに担当者と状態がある、(3) 手順書やルールが隣にあると助かる。たとえば入社準備表は、行ごとに「アカウント発行」「初日オリエン」のようなタスクがあり、それぞれに手順書があります。行から手順書へリンクしておけば、新しく担当になった人が手順を探さずに済みます。

表計算からの移行で失敗しやすいのは、全部の表を一度に移そうとすることです。最初は1つで構いません。1つの表が Wiki の中で回り始めると、「あの表もこっちに」という声が現場から出てきます。声が出てから移す方が、上から移させるより続きます。

担当者列と権限が「人」に追従すると、何が変わりますか？

ナレッジ共有が古くなる原因の一つは、人の情報が転記だからです。管理表の担当者欄に名前を手で打っていると、異動や退職があっても表は変わらず、「退職した人が担当のページ」が残り続けます。担当者列が従業員名簿を参照していれば、名簿で退職・異動が反映された時点で、その人が担当だった行を一覧で洗い出せます。所有者を引き継ぐ作業が、「思い出す」から「一覧を処理する」に変わります。

権限も同じです。人事部のメンバーにページを共有するとき、人単位で1人ずつ指定していると、入社・異動のたびに追加漏れが起きます。「人事部」という部署単位で共有し、その部署の所属が名簿に追従すれば、新しく人事部に入った人には自動で見え、異動した人からは自動で外れます。この追従があると、共有範囲の棚卸しをしなくても Wiki の権限が古くならず、人事・経営の情報を安心して置けるようになります（原因2の解消）。

更新の責任は、所有者列と次回確認日列で持たせます。確認日が来たら所有者に通知が届き、確認して日付を先に送るだけで「最終確認日」が更新されます。所有者が異動・退職していれば、名簿の追従でそれが分かります。「みんなで書く」を「この人がこの日に確かめる」に変えるのが原因3の直し方です。

定着しているかは、何で測ればよいですか？

• リンクで答えた回数: チャットで「〜はどこ？」に Wiki のリンクで答えた回数。増えていれば、探せる・信頼されている証拠です
• 所有者・確認日の付与率: 全員向けページのうち、所有者と次回確認日が付いている割合。8割を超えると古いページが目立たなくなります
• 毎日開く表の数: 担当者が仕事のために毎日開く管理表が Wiki の中に何個あるか。1つ目が最も重要です
• 半年以上更新の無いページ: 月1回の棚卸しで、所有者に「まだ正しいか」を確認して減らします
• フォーム経由の依頼の割合: 社内依頼のうち、Wiki の受付フォームから届いた割合。チャットの依頼が減っていれば、仕事が Wiki の中に移っています

ページ数や投稿数を目標にすると、目標のために薄いページが増え、探しにくくなります。「投稿を人事評価に組み込む」という方法も語られますが、20〜300人規模の会社では、評価制度をいじる前に「仕事の中に置く」方が早く効きます。

最初の30日で、何をすればよいですか？

この30日で意識したいのは、人事や総務が全部やらないことです。管理表はその表の担当者が、手順書はその手順を知っている人が書きます。人事の役割は、置き場所と共有範囲の型を決め、所有者と確認日の列を用意することです。

ChordOne Note で「仕事の中に置く」を実装すると？

原因1（書く場所と仕事が離れている）には、データベースを使います。業務テンプレートの「プロジェクト管理」「社内依頼受付」から列・ビュー・フォームが揃った状態で始められ、行を横のパネルでページとして開いて本文や添付を持たせられます。ページ本文で /データベース と入力すれば、手順書の中に管理表を置くこともできます。

原因2（置けない情報がある）には、ページ単位の共有です。新しいページは作成者だけが読める状態から始まり、管理者であっても非公開ページの本文は読めません。共有先は「ワークスペース全員」「指定した人・部署」「自分だけ」からページごとに選び、部署を指定した共有は異動・入社に追従します。権限の決め方は 社内Wikiの権限設計 にまとめています。

原因3（責任者と期限が無い）には、列の種類「従業員」で所有者を名簿から選び、次回確認日の列と組み合わせます。退職した所有者には打ち消し線が付き、引き継ぎ漏れに気づけます。状態を「要確認」に変えたら所有者にアプリ内・Slack で通知するオートメーションを付ければ、更新は「届いた通知を処理する」作業になります。実行結果は「正常に実行」「確認が必要」で確認できます。

原因4（探せない・古い）には、セマンティック検索とバックリンクです。「有給の申請方法」で探しても「休暇取得の手順」が見つかり、データベースの行も検索対象です。手順書がどの議事録から参照されているかは バックリンク で確認できます。従業員20名までは無料で、21名以上は月200円/人です。詳しくは 機能ページ と 導入の流れ をご覧ください。

よくある質問

共有を人事評価に組み込むべきですか？

20〜300人規模では、評価制度を変える前に「仕事の中に置く」方が早く効きます。管理表が Wiki の中で回り始めてから、必要なら評価に反映することを検討してください。

今のツールのままでも直せますか？

原因1と3（管理表を Wiki の中に置く、所有者と確認日を付ける）は、多くのツールで工夫すれば実現できます。原因2（ページ単位の共有、管理者にも見えない非公開）と、担当者・部署の名簿追従はツールの仕様に依存するので、確認してください。

少人数でも同じ進め方でよいですか？

10〜20人でも同じです。むしろ人数が少ないうちに「毎日開く表を Wiki の中に置く」型ができていると、人が増えても崩れません。

関連記事

• 社内Wikiとは？ 定着しない3つの理由と続く運用の型
• 社内マニュアルの作り方｜7項目の型・書く順番・更新が止まらない運用
• 社内Wikiの権限設計｜ページ単位共有・部署・ゲスト・非公開の決め方