「あの件、誰に聞けばわかるんだっけ？」
あなたの会社で、今日一日だけでこの言葉が何回発せられたでしょうか。
従業員数が500名を超え、部門間の壁（サイロ）が厚くなると、私たちは途端に「組織の地図」を見失います。隣の部署がすでに解決したトラブルに、別の部署がゼロから頭を抱えている——そんな「車輪の再発明」が、実は毎日起きているのです。
実務の現場では、この見えない損失を解消するために、SlackやTeamsといったチャットツールの全投稿データをAIに解析させ、自動的に「誰が何の専門家か」を特定するシステムを構築するケースが増えています。
技術的には、現在のLLM（大規模言語モデル）を使えばそれほど難しいことではありません。しかし、プロジェクト開始直後に直面しやすいのは、技術的なバグではなく、現場からの強烈な反発です。
「私たちの会話を監視するつもりですか？」
「AIに評価されるなんて真っ平ごめんです」
もっともな意見です。自分の何気ない発言が常にAIに採点されているとしたら、息が詰まるのは当然の心理と言えます。
本記事では、技術的な実装の話以上に、この「従業員の心理的抵抗（監視懸念）」をどう乗り越え、プライバシーを保護しながらナレッジ活用を実現するかという、実践的なプロセスに焦点を当てて解説します。綺麗な成功事例だけでは見えてこない、現場のリアルな葛藤と解決策を共有します。
1-1. プロジェクト背景：組織拡大で失われた「あの人は何に詳しいか」の地図
今回モデルケースとして想定するのは、従業員数約1,200名規模のITサービス企業です。急激な成長に伴い、中途採用者が毎月数十名入社するような環境を例に考えます。
急成長する組織と情報のサイロ化現象
このような企業では創業期、「困ったらCTOに聞けばいい」「あの仕様は特定の担当者が詳しい」といった暗黙知が機能しています。全員の顔と名前、得意分野が一致しているからです。
しかし、組織が階層化し、拠点が分散すると状況は一変します。開発部、カスタマーサクセス部、営業部がそれぞれのチャットチャンネルに閉じこもり、情報の流通が分断されるのです。
実際の現場では、以下のような声がよく聞かれます。
- 「顧客からニッチな技術質問が来たが、社内に詳しい人がいるかわからず、結局外部のベンダーに調査を依頼した。後で知ったが、隣の部署にその技術の元開発者がいた」
- 「過去のトラブルシューティング資料を探すのに半日かかった。実はTeamsの過去ログにあったが、検索キーワードがわからずヒットしなかった」
手動更新のスキルマップが機能しない理由
もちろん、多くの企業も手をこまねいているわけではありません。人事部が全社員に「スキルマップ（技術経歴書）」の入力を義務付けるケースは多々あります。
しかし、このデータベースは形骸化しがちです。理由はシンプルです。
- 入力が面倒: 日々の業務に追われる社員にとって、プロフィールの更新は優先度が低いタスクです。
- 自己評価のバイアス: 声の大きい人は過剰に書き、謙虚な熟練者は「たいしたことない」と書かないため、データの信頼性が低い。
- 粒度の不一致: 「Javaが得意」と書いてあっても、Spring Frameworkの特定バージョンに詳しいのか、非同期処理に強いのかまではわかりません。
結果として、最終更新日が数年前のデータが並ぶ「死んだデータベース」が出来上がってしまうのです。
「誰に聞けばいいか分からない」が招く年間数千時間の損失
この課題を経営層に認識してもらうためには、損失コストの試算を行うことが有効です。
全社員1,200名が、1日あたり平均15分「情報を探す時間」や「詳しい人を探して回る時間」に使っていると仮定します。これだけでも膨大な時間ですが、さらに深刻なのは「間違った人に聞いてしまい、回答を待つ時間」や「誤った情報に基づいて作業を進めた手戻り」です。
簡易的な試算でも、年間で約75,000時間（社員約40名分の年間労働時間に相当）が、非生産的な「探索」に消えていることがわかります。
これだけの工数があれば、新製品がもう一つ作れる計算になります。このように可視化することで初めて、「社内の専門知を可視化する」という取り組みが、単なる人事施策ではなく、経営課題解決のプロジェクトとして認識されるようになります。
2. 解決策の検討と「AIによる自動特定」への舵切り
課題解決のアプローチとしては、主に二つの選択肢が比較検討されます。
一つは、既存のスキルマップ運用を厳格化し、入力キャンペーンやインセンティブ設計で「人手による更新」を促す方法。
もう一つは、SlackやTeamsといった日常業務のコミュニケーションログをAIで解析し、自動的にスキルを抽出する方法です。
タグ付け文化の定着失敗を経て
多くの組織では過去に、「有益な投稿には特定のスタンプを押してナレッジ化しよう」というキャンペーンを行ったことがあるかもしれません。しかし、これは失敗に終わる傾向があります。業務中に「これはナレッジかどうか」を判断し、タグ付けするという行為自体が認知的負荷（コグニティブ・ロード）を高めるからです。
人は、意識して知識をアウトプットするよりも、無意識の会話の中にこそ真実の知識を吐露します。
- 「このエラーログ、〇〇のライブラリのバージョン競合が原因だよ」
- 「その顧客要件なら、過去の類似案件で作った構成図が使えるはず」
こうした「文脈（コンテキスト）」を含む非構造化データこそが、宝の山です。これを人手で整理するのは不可能なため、ここでLLM（大規模言語モデル）の出番となります。
Slack/Teams上の「自然な会話」こそが真実のデータ
AI活用の仮説はこうです。
「特定のトピックについて、他者の質問に的確に回答している人、あるいは専門的な用語を用いて議論をリードしている人は、その分野の専門家である可能性が高い」
自己申告（私はこれができます）ではなく、行動履歴（実際に助けている）に基づく評価。これなら、謙虚なエースも見つけ出せますし、データはリアルタイムに更新され続けます。
技術的なPoC（概念実証）として、OpenAIのAPIを用いて過去の公開チャンネルのデータを解析させる手法があります。適切に実装すれば結果は驚くほど高精度になります。「Python」という広いくくりではなく、「Pythonの非同期処理におけるメモリリーク対策」といった具体的な粒度で、専門性を持つ人物をリストアップすることが可能です。
導入前に立ちはだかった最大の壁：従業員の心理的抵抗
しかし、導入計画を発表した直後、現場からは辛辣な意見が寄せられることが少なくありません。
- 「上司に見られていないところで愚痴も言えないのか」
- 「発言数で評価が決まるなら、無駄な発言を乱発する人が増えるだけだ」
- 「AIに監視されているようで気持ち悪い。プライバシーの侵害だ」
技術的な正解が、組織的な正解とは限りません。プロジェクトマネジメントの観点からは、この「監視社会（パノプティコン）への恐怖」こそが、AI導入プロジェクトにおける最大のリスクであると認識すべきです。
システムを導入しても、従業員が萎縮してチャットツールで発言しなくなれば、元も子もありません。技術開発を進める前に、「信頼（トラスト）の設計」に十分な時間を割くことが不可欠です。
3. 【Assurance】不安を解消するための3つの「安全装置」設計
従業員の不安の根源は、「集めたデータがどう使われるか分からない」という不透明さにあります。そこで、法務部や労務担当、そして社員代表を巻き込み、以下の3つの「安全装置」をルール化することが推奨されます。
データの匿名化処理と解析範囲の厳格な制限
まず、AIが参照するデータの範囲を明確に定義し、システム的に制限をかけます。
- パブリックチャンネル限定: DM（ダイレクトメッセージ）やプライベートチャンネル（鍵付き）は一切解析対象にしないことを宣言し、APIの接続設定でも物理的に遮断します。
- 個人情報のマスキング: 解析前にPII（個人特定情報）除去フィルタを通し、誰が発言したか分からない状態でAIにトピック抽出をさせ、最後にIDだけを紐付ける仕組みを構築します。
- ネガティブ感情の除外: 「疲れた」「辞めたい」といった感情的なワードや、業務に関係のない雑談チャンネル（#random, #club活動など）は解析対象外リスト（ブラックリスト）に設定します。
「隠れて監視するのではなく、公開された場での貢献を称賛する」というスタンスを明確にすることが重要です。
「オプトアウト方式」ではなく「オプトイン」の検討
「嫌な人は除外申請してください（オプトアウト）」という方式を採用しがちですが、これでは「申請したら会社に反抗していると思われるのではないか」という同調圧力が働きます。
そのため、「ナレッジ貢献者として認定されたい人は参加してください」というオプトインに近い形式を採用することが効果的です。具体的には、AIが候補者を特定した後、本人に「あなたは〇〇分野の専門家候補として推薦されました。プロフィールに掲載しますか？」という通知を送り、本人が承認（Approve）して初めて公開される仕組みです。
これにより、「勝手に分析された」という被害者意識を、「AIに推薦された」という承認欲求の充足へと転換することが可能になります。
評価には一切使用しないという労使協定の締結
最も重要なのがここです。多くの社員は、このデータが「人事評価（査定）」に使われることを恐れます。
そのため、経営陣と合意形成を図り、以下の条文を含むガイドラインを策定して社内に公表することが求められます。
【ナレッジ解析データの利用目的に関する規定】
- 本システムにより抽出されたデータは、社内の相互扶助およびナレッジ共有の促進のみを目的とする。
- 発言回数、回答数、特定された専門性などは、給与・賞与・昇進などの人事評価の直接的な指標としては一切使用しない。
- 従業員は、自身のデータが解析されることをいつでも拒否する権利を持ち、それにより不利益な取り扱いを受けない。
「評価に使わないなら、協力するメリットがないのでは？」という経営層からの懸念に対しては、次のように考えるべきです。
評価に使わないからこそ、純粋な『頼り、頼られる関係』が可視化されます。評価と紐付けた瞬間、データはハックされ、質より量のスパム投稿で溢れかえるリスクが高まります。
このような「不可侵条約」を結ぶことで、現場の心理的抵抗を劇的に和らげることができます。
4. 実装とチューニング：ノイズを除去し「真の専門家」を見つける技法
心理的な安全装置が整ったところで、いよいよ実装のフェーズです。ここでは、単に「キーワードを多く発言している人」を専門家と誤認しないための、AIチューニングの工夫について解説します。
単なるキーワード出現頻度では測れない「文脈」の理解
単純なキーワードマッチングを行うと、例えば「〇〇について教えてください」と質問ばかりしている初心者が、そのキーワードを連呼しているため「専門家」として誤検知されてしまいます。
これを防ぐため、LLMには以下のようなプロンプト（指示）を与え、発言の意図（インテント）を分類させます。
- Questioner（質問者）: 疑問を投げかけている
- Solver（解決者）: 具体的な解決策、コード、URLを提示している
- Discussant（議論者）: 意見や見解を述べている
このうち、SolverとDiscussantのスコアが高いユーザーのみを候補として抽出するロジックを組みます。PythonとLangChainを用いたパイプライン処理により、日次のバッチ処理でこの分類を行うのが実践的なアプローチです。
「質問者」と「回答者」の識別ロジック
さらに精度を高めるために活用できるのが、チャットツールの「スタンプ（リアクション）」と「スレッド構造」です。
誰かの発言に対して、質問者が「ありがとう」「助かりました」といった感謝のリアクションをしている場合、その発言の信頼性スコアを大幅に加点します。
また、スレッドの長さも指標になります。議論が長く続き、最終的に解決に至ったスレッドの中で、最も多くの文字数を記述したユーザーや、最後のまとめ発言をしたユーザーに重み付けを行います。
雑談チャンネルと業務チャンネルの重み付け調整
誤検出（False Positive）の削減も重要です。例えば、ゲーム部のチャンネルで「Unity」の話をしていても、それは業務上の専門性とは限りません。
チャンネル名の命名規則（prefix）を活用し、dev- proj- help- といった業務系チャンネルの重み係数を1.0とし、random- club- などの雑談系は0.1、あるいは除外設定とします。
このように、「どこで（Where）」「どのような文脈で（Context）」「誰から感謝されたか（Validation）」を掛け合わせることで、ノイズを極限まで減らすことができます。
5. 導入後の変化：埋もれていた「隠れエース」の発掘事例
システムが稼働し定着してくると、組織には静かですが確実な変化が訪れます。
組織図からは見えないインフォーマルネットワークの可視化
生成された「AIスキルマップ」を見ると、意外な事実が判明することがあります。特定の技術領域において、マネージャークラスではなく、入社数年の若手社員が「ハブ」になっているケースです。
例えば、新導入されたクラウドインフラ技術に関して、若手社員が部署を越えて多くのシニアエンジニアの相談に乗っている実態が可視化されることがあります。組織図上は末端であっても、ナレッジネットワーク上では中心にいるという発見です。
若手・中途社員のエンパワーメント
このシステムは、特に中途入社者や若手にとって強力な武器になります。
以前は「誰が詳しいかわからない」ため、とりあえず上長に聞くしかありませんでしたが、導入後は「特定の技術なら、隣の部署の専門家に聞けばいい」とピンポイントで指名できるようになります。
指名される側にとっても、これはポジティブな体験です。自分の専門性がAIによって客観的に認められ、頼られる機会が増えることで、自己効力感が高まります。
「最初は監視されるのが嫌だと思っていたが、自分の得意分野が正しく認知され、無駄な会議ではなく『答えられる質問』だけが来るようになったので、むしろ働きやすくなった」といった声が上がるようになれば、プロジェクトは成功と言えるでしょう。
問い合わせ対応時間の短縮と自己効力感の向上
定量的な効果も期待できます。適切に運用されたケースでは、「情報を探す時間」が導入前の半分程度に短縮される事例もあります。
また、「適切な回答者にたどり着くまでの人数」も大幅に改善され、たらい回しが減少します。結果として、年間数千時間のロス削減という目標の達成に大きく貢献します。
6. 担当者からのアドバイス：これから導入する企業へ
最後に、同様の取り組みを検討されているDX担当者の方へ、実践的なアドバイスをお伝えします。
技術よりも「信頼設計」に時間をかけるべき
本記事で繰り返し述べてきましたが、AIのアルゴリズム精度よりも、「従業員との信頼契約」の方が遥かに重要です。どれほど優れたAIも、従業員が「気持ち悪い」と感じてデータを隠し始めれば、無力化します。
プロジェクト期間の最初の3割は、法務・労務との調整、そして現場キーマンとの対話に使ってください。「監視ではない」というメッセージを、言葉だけでなく「システム仕様」と「運用ルール」で証明し続ける必要があります。
スモールスタートでの成功体験の作り方
いきなり全社展開するのはリスクが高いです。まずはエンジニア部門など、新しい技術への受容性が高い部署でパイロット運用を行いましょう。
そこで「AIのおかげで、すごい詳しい人を見つけられた」「自分のスキルが認められて嬉しかった」というポジティブな口コミ（成功事例）を作ってから、営業やバックオフィスへと広げていくのが定石です。
AIは「監視」ではなく「発見」のためにあるというメッセージ
導入時の社内広報では、徹底して「Discovery（発見）」という言葉を使うことを推奨します。「Monitoring（監視）」や「Evaluation（評価）」ではありません。
「組織の中に埋もれている素晴らしい知見と、それを待っている人をマッチングさせる」
このビジョンを共有し、AIを「管理職の道具」ではなく「従業員全員のための便利ツール」として位置付けることができれば、あなたのプロジェクトは必ず成功します。
まとめ
社内専門家の特定は、ナレッジマネジメントの第一歩です。しかし、そこには必ずプライバシーというセンシティブな問題が横たわっています。
- 透明性の確保: 何を解析し、何を解析しないかを明確にする。
- 目的の限定: 評価には使わず、相互扶助のためだけに使うと約束する。
- AIによる推論の検証: 文脈を理解させ、真の貢献者を抽出する。
これらを丁寧に積み重ねることで、組織は「サイロ」から脱却し、有機的につながるネットワークへと進化します。
プライバシー保護ガイドラインの策定や、導入前の社内説明用資料の準備、さらにAI解析ロジックの詳細パラメータの調整は、プロジェクト成功の鍵を握ります。
従業員の不安を払拭し、安全にプロジェクトを進めるためには、これらの要素を体系的に整理し、実践的な運用ルールを確立することが重要です。これから社内データのAI活用を検討される場合は、技術と組織心理の両面からアプローチすることをおすすめします。
コメント