社内 SNS とナレッジ共有の文化
レッスン7:社内 SNS とナレッジ共有の文化
このレッスンで学ぶこと
- 社内チャネルの性格の違いと、使い分けの発想を理解する
- 社内 SNS に書き込まれない理由と、その対策を扱う
- トーンの設計と、社内での炎上をどう防ぐかを理解する
- ナレッジが貯まる条件を扱う
前回のレッスンでは、サーベイ結果を対話に変える技術を扱いました。今回は、社員同士が日常的にやり取りする社内 SNS と、そこに蓄積されるナレッジの文化について扱います。
社内チャネルの使い分け
多くの会社では、経営からの正式な発信を行う社内報や社内ポータルに加えて、社員同士が気軽にやり取りできる社内 SNS のようなチャネルを併用しています。両者は、性格がまったく異なるチャネルです。
社内報や社内ポータルは、編集された情報を、決まった経路で届けるチャネルです。発信のタイミングや内容は、担当者があらかじめ整えたものが中心になります。一方、社内 SNS は、社員が自発的に書き込み、ほかの社員がそれに反応するという、双方向で流動的なチャネルです。編集の手が入らない分、発信の自由度は高いものの、内容の質や一貫性は保証されません。
💡 ポイント 「チャネルを増やすほど、届かなくなることがある」という本コースの中核メッセージは、社内 SNS の運用にも当てはまります。フォーマルな発信とインフォーマルな発信を、それぞれ何のために使うのかを整理しないまま両方を増やすと、社員は「どこで何を見ればよいか」がわからなくなります。
フォーマルなチャネルとインフォーマルなチャネルの役割分担を整理すると、次のようになります。
| 観点 | フォーマルなチャネル(社内報・社内ポータル) | インフォーマルなチャネル(社内 SNS) |
|---|---|---|
| 発信の主体 | 編集担当者・経営陣 | 社員一人ひとり |
| 内容の性格 | 整えられた、確定した情報 | 気づき、雑談、途中経過の共有 |
| 向いている用途 | 正式な方針や制度の周知 | 日常のやり取り、気軽な質問 |
| 求められる編集 | 丁寧な編集と確認が必要 | 最小限の編集で速さを優先 |
表 1:フォーマルなチャネルとインフォーマルなチャネルの役割分担。どちらか一方だけでは、社内コミュニケーションは成立しません。
発信したい内容が、どちらのチャネルに向いているかを判断する目安を、簡単な図にまとめました。
flowchart TD
Start[発信したい内容] --> Q1{正式な決定事項か}
Q1 -->|はい| Formal[フォーマルなチャネルで発信する]
Q1 -->|いいえ| Q2{すぐに反応や意見がほしいか}
Q2 -->|はい| Informal[インフォーマルなチャネルで発信する]
Q2 -->|いいえ| Q3{記録として残す必要があるか}
Q3 -->|はい| Formal
Q3 -->|いいえ| Informal
図 1:発信内容がどちらのチャネルに向いているかを判断する目安。正式な決定事項や記録として残す必要がある内容はフォーマルなチャネルへ、すぐに反応がほしい内容や気軽な情報共有はインフォーマルなチャネルへ、という判断の起点になります。すべての発信をどちらか一方に寄せるのではなく、内容ごとに判断する習慣が、チャネルの使い分けを機能させます。
書き込まれない理由
社内 SNS を導入したものの、書き込みが増えず、閲覧専用のような状態になっている会社は少なくありません。書き込みが増えない理由を整理します。
理由 1:評価されることへの恐れ
自分の発言が、上司や同僚からどう評価されるかを気にして、書き込みをためらう社員は多くいます。特に、間違ったことを書いてしまうのではないか、稚拙だと思われるのではないかという不安が、最初の一歩を重くします。
理由 2:最初の一歩の重さ
誰も書き込んでいないチャネルに、最初の投稿をするのは心理的な負担が大きいものです。すでに何人かが投稿していれば、それに続く形で書き込みやすくなりますが、閑散としたチャネルでは、その負担を誰かが引き受けなければなりません。
理由 3:反応が返ってこない不安
せっかく書き込んでも、誰からも反応がなければ、次第に書き込む意欲が失われます。反応の少なさは、投稿する側にとって「見てもらえていない」という感覚につながります。
⚠️ 注意 書き込みが少ないチャネルを見て「社員に関心がないから」と判断するのは早計です。多くの場合、原因は関心の低さではなく、書き込みへの心理的なハードルの高さにあります。
書き込みを増やすための対策
3 つの理由それぞれに対応する形で、対策を整理しておきます。
評価されることへの恐れに対しては、「ここでは完璧な文章でなくてよい」というメッセージを、運営側が繰り返し発信します。誤字や言い回しの粗さを指摘しない、という暗黙の了解を作ることも有効です。
最初の一歩の重さに対しては、運営側や管理職が率先して最初の投稿をする、あるいは、答えやすい簡単な問いかけ(今週嬉しかったことは何ですか、といった軽い話題)を定期的に投げかけることで、投稿のきっかけを作ります。
反応が返ってこない不安に対しては、投稿があった際に、誰かが必ず短くでも反応する運用を心がけます。内容への評価ではなく、「見た」ということが伝わるだけの短い反応でも、投稿者の安心感につながります。
📝 補足 これらの対策は、一度実施すれば終わりというものではありません。書き込みが増えてきたら、運営側の関与を少しずつ減らし、社員同士の自然なやり取りに任せていく段階に移ることも、健全な運用の一部です。
トーンの設計
社内 SNS がうまく機能するかどうかは、そこで交わされる言葉のトーンの設計に大きく左右されます。
誰が最初に書き込むか
チャネルの立ち上げ期には、誰が最初に書き込むかが、その後のトーンを決めます。管理職や経営層が最初に、堅苦しくない自然な言葉で書き込むことで、後に続く社員も気軽な言葉で書き込みやすくなります。逆に、最初の投稿が形式的で堅い文章だと、以降の投稿も同じトーンに引きずられがちです。
経営層の関わり方
経営層が社内 SNS に頻繁に登場しすぎると、社員は「見られている」という緊張感から、かえって発言を控えるようになることがあります。経営層の関わりは、監視のためではなく、対話の呼び水として、適度な頻度で行うのが実務的です。
カジュアルさの許容範囲
社内 SNS でどこまでカジュアルな言葉づかいを許容するかは、会社の文化によって幅があります。あまりに堅い言葉づかいを求めると、SNS らしい気軽さが失われ、逆にカジュアルさを許容しすぎると、後述する炎上のリスクが高まります。最低限のガイドラインを示しつつ、細かい言葉づかいまで一律に統制しない、というバランスが実務的です。
📝 補足 トーンの設計は、一度決めたら固定するものではありません。チャネルが成熟し、社員同士の信頼関係が深まるにつれて、許容されるカジュアルさの幅も自然に広がっていくことがあります。運用しながら調整する前提で設計するとよいでしょう。
トーンの違いを、実際の投稿例で見てみましょう。
堅すぎる投稿例:「本日、新しい業務フローについて周知いたします。関係各位におかれましては、内容をご確認の上、対応をお願いいたします」
この投稿は、正式な通知としては誤りではありませんが、社内 SNS の投稿としては距離感があり、社員が気軽に質問したり反応したりしにくい雰囲気を作ってしまいます。
社内 SNS に向く投稿例:「新しい業務フローができました。最初は戸惑うところもあると思うので、わからないところがあれば気軽にここで聞いてください。私も慣れるまで時間がかかりました」
同じ内容でも、話しかけるような言葉づかいと、書き手自身の経験を添えることで、読み手が反応しやすい空気を作れます。フォーマルな通知は社内報や社内ポータルに任せ、社内 SNS では、そこに至るまでの背景や、書き手の実感を添えるという役割分担も有効です。
社内での炎上をどう防ぐか
社内 SNS では、社外向けの発信とは異なる形の「炎上」、つまり特定の投稿をめぐって批判や反発が集中する状況が起こることがあります。
ガイドラインの整備
何を書いてよく、何を書いてはいけないかという最低限のガイドラインを、あらかじめ示しておきます。個人への攻撃的な言葉、差別的な表現、事実確認が取れていない噂の拡散などは、明確に禁止事項として示しておく必要があります。
モデレーションの体制
投稿された内容を、誰かが継続的に見守る体制を作ります。すべての投稿を事前に検閲するという意味ではなく、問題のある投稿が見つかった場合に、早期に気づき、対応できる体制を指します。
エスカレーションのルート
もし深刻なトラブルに発展しそうな投稿が見つかった場合、誰に、どう報告し、どう対応するかというルートをあらかじめ決めておきます。ルートが決まっていないと、対応が遅れ、問題が拡大してしまいます。
🔰 初学者の方へ ガイドラインを厳しくしすぎると、社員は萎縮し、書き込み自体が減ってしまいます。禁止事項を最小限に絞り、それ以外は自由に発言できるという設計の方が、健全な活用につながりやすいというのが実務上の傾向です。
火種が小さいうちに気づく
社内での炎上の多くは、最初から大きな騒ぎになるわけではありません。特定の投稿に対して、少数のコメントが集まり始めた段階で、内容に誤解や行き違いがないかを確認し、必要であれば早めに補足や訂正を入れることで、火種が広がる前に収められることが多くあります。モデレーションの役割は、投稿を取り締まることではなく、この初期段階での気づきと、早めの対応にあります。
対応が遅れたときの振り返り
万が一、対応が遅れて社内で大きな反発を招いてしまった場合は、その経緯を振り返り、ガイドラインやエスカレーションのルートのどこに不備があったのかを確認します。個人の対応の遅さを責めるのではなく、仕組み側の改善に焦点を当てることが、次の炎上を防ぐことにつながります。
ナレッジが貯まる条件
社内 SNS やナレッジ共有の仕組みが目指すゴールの 1 つは、社員が持つ知識や経験が、組織の資産として蓄積されることです。しかし、多くの会社で、投稿は流れていくばかりで、後から検索して役立てられる形には残っていません。ナレッジが貯まる条件を整理します。
条件 1:検索性
投稿がどれだけ蓄積されても、後から探し出せなければ資産になりません。レッスン 4 で扱った社内ポータルの検索性の工夫は、社内 SNS のナレッジにも応用できます。関連する話題ごとにまとめられた場所や、タグ付けの仕組みがあると、後から探しやすくなります。
条件 2:インセンティブ
有益な情報を共有した社員が、何らかの形で評価される仕組みがあると、投稿の質と量が上がります。金銭的な報酬である必要はなく、感謝の言葉が可視化される仕組みや、社内報での紹介など、多様な形のインセンティブが考えられます。
条件 3:属人化しない仕組み
特定の詳しい社員だけが情報を発信し続ける状態では、その社員が異動や退職をした瞬間に、ナレッジの流れが止まってしまいます。複数の社員が持ち回りで発信する仕組みや、質問への回答を特定の個人に頼らず、誰でも答えられる状態を作ることが、持続的なナレッジ共有につながります。
📖 もっと詳しく ナレッジ共有の文化は、仕組みだけでは育ちません。「知っていることを共有するのは当たり前だ」という価値観が組織に根づいて初めて、仕組みが機能します。この価値観づくりは、一朝一夕にはできず、経営層や管理職が率先して情報を共有する姿を見せ続けることが、遠回りに見えて確実な近道です。
3 つの条件がどう作用するかを、簡単な場面で考えてみます。ある部署で、同じような質問が何度も繰り返し寄せられていたとします。検索性がなければ、質問のたびに同じ回答を一から作ることになり、回答する側の負担が増え続けます。インセンティブがなければ、丁寧に回答しても評価されないため、回答する側の意欲が続きません。属人化しない仕組みがなければ、いつも同じ 1 人が回答を担い続け、その人が忙しくなった途端に、質問への回答が滞ります。逆に、よくある質問と回答をまとめたページを作り、回答した社員を社内報で紹介し、複数人で回答を分担する体制を作れば、同じ質問への対応にかかる負担は大きく減り、蓄積された回答自体が、新しく入った社員にとっての貴重な資産になります。
よくある失敗パターン
社内 SNS とナレッジ共有の運用で、繰り返し見られる失敗のパターンを整理しておきます。
第 1 に、立ち上げ直後に盛り上げすぎて、その後失速する失敗です。導入時にイベントやキャンペーンで盛り上げても、その後の運用が続かなければ、社員の関心は元に戻ってしまいます。立ち上げ時の盛り上がりよりも、日常的に無理なく続けられる運用の設計の方が重要です。
第 2 に、ルールを整備しすぎて、気軽さが失われる失敗です。炎上を恐れるあまり、投稿前の承認を必須にしたり、使える言葉を細かく制限したりすると、社内 SNS の良さである気軽さが失われ、結局使われなくなります。
第 3 に、蓄積されたナレッジを誰も見返さない失敗です。投稿や回答が蓄積されていても、検索や整理の仕組みがなければ、過去の資産は埋もれたままになります。定期的に、蓄積された情報を棚卸しし、まとめ直す作業を組み込むことが必要です。
まとめ
このレッスンでは、以下のことを学びました。
- 社内報・社内ポータルというフォーマルなチャネルと、社内 SNS というインフォーマルなチャネルは、それぞれ異なる役割を持つ
- 社内 SNS に書き込まれない理由は、評価されることへの恐れ、最初の一歩の重さ、反応が返ってこない不安にある
- トーンの設計は、誰が最初に書き込むか、経営層の関わり方、カジュアルさの許容範囲によって決まる
- 社内での炎上を防ぐには、ガイドラインの整備、モデレーションの体制、エスカレーションのルートが必要
- ナレッジが貯まるには、検索性・インセンティブ・属人化しない仕組みという 3 つの条件がそろう必要がある
- よくある失敗は、立ち上げ直後の盛り上げすぎと失速、ルールの整備しすぎによる気軽さの喪失、蓄積したナレッジを誰も見返さないことの 3 つ
次のレッスンでは、これまで扱ってきた発信と対話の取り組みを、どう測定し、どう続けていくかを扱います。本コースの最終レッスンです。
確認クイズ
このレッスンの理解度をチェックしましょう。