社内改善の現場では、「何もしていない状態」よりも「良かれと思って導入した施策」が組織を疲弊させてしまう場面が少なくない。
努力が足りないわけでも技術が不足しているわけでもない。それでも結果が出ない。むしろ不満だけが増えていく･･････こうした相談は珍しくない。
多くの場合、問題は技術ではなく、設計思想が存在しないまま施策が実行されていることにある。
便利そうだから導入する。役に立ちそうだから作る。正しそうだから展開する。
この順序で進んだ施策は現場で静かに使われなくなっていくものだ。実際、依頼の現場でも「ここまでやったのに改善しない」という声は頻繁に聞く。
だが、行動が変わらないのは当然でもある。多くの施策は善意から始まり、当事者の行動モデルが検証されないまま公開されているからだ。
本記事では、「社内ナレッジ共有ツールを作ったが誰も使わない」というケースを扱う。これは珍しい失敗ではない。むしろ、社内改善の現場では繰り返し観測される典型例だ。
興味深いのは、当事者は技術やUIの問題だと認識している一方、現場では「そもそも必要なのか」という疑問が生まれている点にある。ここには大きな認識の断絶が存在する。
「便利であれば使われる」という前提は一度脇に置きたい。
行動は利便性ではなく、意味によって起動するのだ。
この記事では、独自ツール導入の失敗を題材に、社内ツール活用を「機能」ではなく「意味設計」として捉え直していく。
今回の依頼について
ある中堅IT企業で「情報共有の効率化」を目的とした社内ナレッジ共有ツールが導入された。成功事例や業務ノウハウを投稿、検索できる、いわゆる社内版のSlackやNotionに近い位置づけのシステムだ。
導入時には説明会が実施され、マニュアルも配布された。操作方法は十分に共有され、技術的な障壁はほぼ存在しない状態だった。
しかし半年後、状況はほぼ動いていなかった。
投稿者は全社員100人中５名で閲覧もほとんど行われていない。社内では次第に「結局、誰も使っていない」という空気が生まれていた。
情報システム部からの相談は以下。
「ツールは使いやすく、機能的にも不足はないはずです。それでも利用が広がりません。UXの観点では何が起きているのでしょうか」
整理すると状況は非常にシンプルだ。
- 社内ツールは導入された
- 利用方法の周知も行われた
- 技術的な問題も特にない
- それでもほとんど使われていない
ここまでを読んで既視感を覚えた方も多いはずだ。この構図は決して珍しいものではなく、社内改善の現場では繰り返し観測される典型例でしかない。
本来、情報共有ツールは導入初期の１ヶ月で一定量の投稿が蓄積され、利用の慣性が生まれることで定着する、いわば「初期臨界点」が存在する。しかしこの企業では半年経ってもその水準に到達していない。
つまり今起きているのは一時的な停滞ではなく、導入段階での構造的な失敗である可能性が高い。
なぜこうなってしまったのか？
次章では、このズレがどこから生まれたのかを分解していく。
これは失敗ではなく「必然」
ヒアリングでまず見えたのは、導入基準が利用者起点ではなく供給側起点で決まっている点だった。
要するに「使ってほしい」という願望から始まっている。利用者がどの場面で、何のために使うのかという行動モデルが検証されていない。
これは本当によくある話で、社内改善では頻繁に起きる典型的な意思決定。なぜなら組織にとって「ツール導入」は非常に合理的に見える選択だからだ。
- 情報共有は重要
- 情報共有には仕組みが必要
- 仕組みとしてツールを導入
この論理は一見すると完全に正しい。しかし問題は、この合理性が「技術合理性」に閉じている点にある。
実際に人が行動するかどうかは上の都合がどうのこうのではなく、「行動合理性」で決まる。ここに断絶が生まれているのだ。
整理すると、今回のケースには複数の層で不整合が存在していた。
| 層 | 具体的な欠陥 | 解説 |
|---|---|---|
| 目的設計 | 存在意義の不在 | 「なぜ既存ツールでは不十分なのか」が定義されていない |
| 行動心理 | 投稿インセンティブが皆無 | 投稿して得られる報酬構造が存在しない |
| 組織文化 | 発信者リスクが高い | 投稿＝余計な露出という心理ブレーキ |
| 組織構造 | 評価制度が非連動 | 投稿しても評価、査定に影響しない |
| 運用 | 初動の成功体験が欠如 | 初期投稿が蓄積される設計になっていない |
| 技術 | 独自ツールの保守コスト | 長期運用の前提が成立していない |
重要なのは、これらが個別の問題ではないという点。すべてに共通しているのは「存在意義の不在」だ。
ここで必ず確認すべき問いがある。
なぜ既存のSlackやNotionではいけないのか。
これに答えられない場合、ツールの必要性そのものが成立していない可能性が高い。
実際、依頼時に共有された言葉は象徴的だった。
ツールは使いやすく、便利なはずなのに利用が広がらない。
この発言が示しているのは、問題の認識がUIや機能の層に留まっているという事実だ。しかし現実に起きているのはもっと上位の設計不整合。
いま議論すべきなのは「使いやすさ」ではない。そもそも「使う理由」が設計されているかどうかだ。
「そもそも使いたくない」という心理
ここからは少し視点を変える。
社内ツールの利用可否は技術ではなく行動の問題だ。人が動くかどうかは「機能の良さ」ではなく、「その行動が自分にとって合理的かどうか」で決まる。
社内ナレッジ共有ツールにおいて、多くの設計は技術合理性に基づいている。検索できる。整理できる。蓄積できる。しかし、利用者が評価するのは次の問いだ。
- 投稿すると自分に何が返ってくるのか
- 投稿しないことで何を失うのか
- 投稿することでリスクは増えないか
この観点で見ると、今回の設計は極めて不利な条件を抱えている。
まず、積極的に発信する層は組織全体の一部に固定されやすいという傾向がある。発信はエネルギーを要し、かつ目立つ行為だ。多くの社員にとって、目立つことは報酬ではなくリスクとなる。
社内投稿には暗黙の心理コストが存在する。
- 内容の正確性を問われる可能性
- 上司や他部署からの反応
- 「出しゃばっている」と見られる懸念
投稿が評価や報酬に直結しない場合、合理的な選択は「静観」になる。
動機が弱く、リスクが存在する行動は継続しない。これは怠慢ではなく、合理的判断だ。
さらに、投稿後に反応が返らない場合、報酬ループは成立しない。人は行動の結果が可視化されない限り、継続しないのだ。評価されない、感謝も返らない、業務負担は増える･･････この状態で利用率が伸びないのは自然な帰結。
社内SNSやナレッジ共有施策が定着しない現象は個別事例ではなく、研究領域でも繰り返し指摘されている。
たとえば、企業内SNSの活用に関する複数の調査では「導入後も投稿者が一部に固定される」「閲覧のみが大多数を占める」という偏りが継続的に観測されている。
いわゆる90-9-1の法則（１%が投稿、９%が反応、90%は閲覧のみ）だ。これはオンラインコミュニティ研究では広く知られており、企業内でも同様の傾向が見られる。
つまり、「導入したのに誰も投稿しない」は例外ではなく、設計を誤れば高確率で発生する既知の現象だ。
重要なのは、ここに「社員の意識が低い」という問題は存在しないという点だ。設計が行動合理性に沿っていないだけ。
現在のツールは、「組織にとって正しい行動」を求めている。しかし利用者は常に「自分にとって合理的な行動」を選ぶ。
このズレが解消されない限り、利用率は上がらない。今の設計は、「やる意味があるのか」という問いに答えていないのだ。
SlackやNotionでいいじゃん
ここで避けて通れない問いがある。
なぜ既存のSaaSでは不十分だったのか。
この問いに明確な答えがない場合、独自ツールを作る理由そのものが成立していない可能性が高い。
中堅企業がSlackやNotionと同等以上のUXを自社開発で実現することは現実的ではない。プロダクトとしての前提条件が大きく異なるからだ。
- Notionの年間開発費は数百億規模
- SlackのDAUは数千万、行動データは膨大
- SaaSは世界中の何万社の要望を吸い上げ、毎週改善される
- 社内独自ツールは利用者100人程度の声（望み薄）しか入らない
- 改善が遅すぎる
SaaSは世界中の利用データを基に継続的に改善される以上、改善速度、検証回数、投資額、すべての面で比較にならない。学習速度の差は時間とともに拡大していく。
さらに、内製ツールは長期運用の前提を満たしにくい。担当者の異動や退職によって維持が困難になる例は珍しくなく、個人依存の構造を持つプロダクトは組織の時間軸に耐えられないのだ。
ただし、ここで重要なのは「内製が常に誤り」という話ではない。企業が独自ツールを選択する理由にも合理性がある。
- 自社特有の業務フローに合わせたい
- 情報を外部サービスに依存したくない
- 組織独自の文化に最適化したい
これらはすべて妥当な動機だ。問題は、ツールが解決する課題が定義されないまま開発が始まることにある。
本来、ツールは課題の解決手段だ。しかし現場ではしばしば、ツール導入そのものが目的になってしまう。
利用者の課題から始まらない設計。これが社内ツール導入で繰り返される最大の失敗要因だ。
今回の案件は、UXアーキテクトとしての根幹である「設計理由の整合性」を突いている。「俺が要ると思ったから作った」は、UX設計における自己中心設計（Self-oriented Design）の典型的失敗要因だ。
ツール導入時に起こりがちな最大のUXバグは、利用者の課題を起点にしていない設計であるということ。
使ってほしいから作った。
だから使われないんです。
ただ、ここまで既存SaaSの優位性を強調してきたが、すべての組織で内製が誤りというわけではない。実際、独自ツールが合理的な選択になる条件も存在する。
代表的なのは、次のようなケースだ。
- 強いセキュリティ要件により外部SaaSを利用できない
- 業務フローが極端に特殊で既存ツールでは適合しない
- 情報の機密性が高く外部依存を避ける必要がある
- ナレッジを業務プロセスに深く統合する必要がある
しかし、重要なのは、「作れるか」ではなく「作る必要があるか」という判断軸だ。内製が合理的になるのは、既存ツールでは解決できない課題が明確に存在する場合に限られる。
そして、その場合でも本質は変わらない。内製であっても、行動設計と動機設計が欠けていれば結果は同じになる。
ツールが内製かSaaSかは本質ではない。使われるかどうかを決めるのは、あくまで行動設計だ。
導入説明会で行動は変わらない
ここでよく行われるのが説明会だ。操作方法を共有し、目的を説明し、活用を呼びかける。だが、これは行動変容としてはほとんど機能しない。
人間において「知っていること」と「実際に行うこと」は別の行動だ。理解は意図を生むが、意図は行動を保証しない。行動経済学でこの断絶は、理解と実行の乖離（Intention–Action Gap）と呼ばれている。
説明会が生み出すのは「理解」まで。しかし実際に必要なのは「継続的な行動」。この差は小さくない。
ではなぜ組織は説明会に依存するのか。理由は単純で、説明会は実施しやすく、成果が見えやすいからだ。
- 実施したという事実が残る
- 周知したと言える
- 導入プロセスが完了したと判断できる
つまり説明会は「導入作業の完了」を示す指標になりやすい。しかし、行動変容の指標ではない。
ここでも技術合理性と行動合理性のズレが現れる。理解したはずなのに使われない･･････この現象は失敗ではなく、設計の帰結だ。
行動は損得の評価関数で決まる。
意味があり、報酬があり、摩擦が小さい行動が選ばれる。残念ながら、理解はこの評価関数にほとんど影響しない。
極端な例だが、投稿に報酬が設定されれば利用率は大きく変わるだろう。人は義務では動かないが、利益には確実に反応するものだ。
現状の設計を整理すると、欠けているのは次の３層だ。
| 層 | 欠けている要素 | 補足 |
|---|---|---|
| 機能的UX | 利便性の差別化 | 既存ツールとの差が不明確 |
| 情緒的UX | 感情的報酬 | 投稿が承認や感謝につながらない |
| 意味的UX | 組織的意義 | 何を良くするのかが共有されていない |
つまり、「便利」ではなく「意味がある体験」を設計しない限り、誰も行動しない。
UXの目的は「行動変容のデザイン」であり、行動に価値を感じさせる構造（Meaning Architecture）を作る必要がある。
たしかに便利さは行動を補助する。けれど、意味だけが行動を起動するのだ。
じゃあどうすればいいのか？
ここまでの話を整理すると、問題はツールではなく行動設計にある。したがって必要なのは機能追加ではなく、行動が成立する条件の再設計だ。
人が自発的に行動するための最小条件はそれほど多くない。
- 行動の結果が即時に可視化される
- 行動が個人の利益につながる
- 行動が組織的に承認される
- 行動の摩擦が極端に小さい
抽象的に見えるかもしれないが、必要なのは大規模な制度改革ではない。行動設計は小さな仕組みの積み重ねでも成立する。実際には、次のような軽量な施策だけでも行動は大きく変わり始める。
例えば投稿のハードルを下げるだけでも効果は大きい。「何を書けばよいかわからない」は典型的な停止要因の１つだ。これを解消するために、投稿テンプレートを用意する。
- 今日解決した問題
- 試した方法
- 学んだこと
- 同じ状況の人への一言
入力欄を空白にするのではなく、最初から枠を提示するだけで投稿率は大きく変わる。
次に、反応の可視化。
投稿は反応が返って初めて報酬になる。週に一度、最も閲覧、リアクションが多かった投稿を社内で紹介するだけでも、投稿の価値は可視化される。重要なのは報酬の大きさではなく、「見られている」という事実だ。
さらに、通知の接続。
ナレッジは「探しに行く情報」ではなく「流れてくる情報」になって初めて接触が増える。Slackなど既存のコミュニケーションツールへ自動通知するだけでも、閲覧機会は大きく増える。
そして、摩擦の削減。
ログイン、カテゴリ選択、タグ入力･･････投稿までに複数ステップが存在すると、それだけで行動は止まる。そこで、ボタン１つで投稿画面が開く、あるいはSlackから直接投稿できる･･････このレベルの摩擦削減が実際の利用率を左右する。
どれも大規模な開発ではない。しかし、こうした小さな設計の積み重ねが行動を変えていく。
これらに共通する思想は１つ。
投稿を「組織のための行動」から「個人の利益につながる行動」へ変換すること。
行動は義務では継続せず、報酬で継続する。人は「正しいから」では動かない。
モチベーション研究において重要な理論として、Deci & Ryanの自己決定理論（Self-Determination Theory）がある。この研究では、人の行動継続は以下の３要素に強く依存するとされている。
- 自律性（自分の意思で選んでいる感覚）
- 有能感（役に立っている実感）
- 関係性（他者とのつながり）
逆に言えば、これらが満たされない行動は継続しにくい。
社内ナレッジ投稿をこの視点で見ると、問題は明確になる。投稿は義務でも評価対象でもなく、反応も返らない。この条件では、行動が継続しないのは自然な帰結だ。
「理解したのに行動しない」のではなく、行動を継続する心理条件が成立していないのだ。
ただし、ここで再び最初の問いに戻る。これらの設計は独自ツールでなければ実現できないのか、ということだ。
多くの場合、既存のSaaSと連携することで実現は可能だ。Slackに共有を流す、Notionに蓄積する。この構成でも行動設計は成立する。
そう考えると、独自ツールを維持する理由はさらに慎重に検討する必要がある。本当に自分でやる（開発する）必要があるのか、ということを。
リサーチなしの施策は機能しない
需要を確認せず供給だけを増やしても不一致は必ず起きる。
ツールは完成しているのに利用されない･･････この状況は珍しくないが、偶然でも例外でもない。設計の順序が逆転した「よくある結果」だ。
本来、施策は次の順番で検討されるべきだ。
- なぜ存在する必要があるのか（Why）
- どんな行動価値を生むのか（What）
- どのように体験として成立させるのか（How）
この順序が崩れたとき、ツールは「存在理由を持たないまま公開される」。そして説明や周知では、その欠落を埋めることはできない。
企業におけるプロダクトは失敗して終わるものではない。失敗したまま運用コストが積み上がり続ける。だからこそ、導入前の問いが重要になる。
社内ツールの失敗事例が繰り返されるのは、ツールが問題解決の象徴として扱われやすいからだ。
「作ること」が前進に見える。しかし実際には、行動が変わらない限り何も変わらない。
ナレッジ共有はツールでは動かない。動かすのは組織文化と動機設計だ。
ここまでの話を１つの判断基準にまとめると、確認すべき問いはそれほど多くない。
- そのツールは既存サービスでは代替できないのか
- 利用者にとっての利益は定義されているのか
- 利用しない場合の不利益は存在するのか
- 行動が評価や報酬と接続されているのか
これらに答えられないまま導入されたツールは、時間とともに使われなくなる可能性が高い。
行動変容は機能から始まらない。意味から始まる。
そのツール、どうして作ったんですか？
その理由は、「使う側のため」でしたか？
ランダム記事（表示できない場合はページを再読み込みしてください）