フレームワーク活用ガイドひとことで言うと#
「あの人しか知らない」をなくし、チームの知識を全員の力に変える仕組み。野中郁次郎・竹内弘高のSECIモデルに代表されるように、暗黙知を形式知に変換し、組織全体で活用できるようにする。
押さえておきたい用語#
- 暗黙知（Tacit Knowledge）
- 言語化されていない経験や勘に基づく知識のこと。ベテランの「コツ」や「判断基準」がこれにあたり、共同化や表出化で伝達される。
- 形式知（Explicit Knowledge）
- 文書やデータとして言語化・数値化された知識のこと。マニュアル、FAQ、チェックリストなどが該当し、誰でもアクセスできる状態にある。
- SECIモデル
- 暗黙知と形式知が共同化→表出化→連結化→内面化の4プロセスで循環するナレッジ創造のモデルのこと。野中郁次郎・竹内弘高が提唱。
- 属人化
- 特定の人にしか業務の知識やノウハウがない状態のこと。その人が不在になると業務が停止するリスクを抱え、ナレッジマネジメントで最優先に解消すべき課題。
ナレッジマネジメントの全体像#
こんな悩みに効く#
- 特定のメンバーが抜けると業務が回らなくなる（属人化）
- 同じ質問が何度も繰り返され、ベテランの時間が奪われる
- 過去の失敗から学べておらず、同じミスが繰り返される
基本の使い方#
組織の知識は4つのプロセスで循環する。
- 共同化（Socialization）: 暗黙知→暗黙知。OJTや同行営業で、言語化されていない「コツ」を体験的に伝える
- 表出化（Externalization）: 暗黙知→形式知。ベテランの「勘」や「コツ」を言語化・文書化する。最も重要かつ最も難しいステップ
- 連結化（Combination）: 形式知→形式知。個別のドキュメントを体系的に整理し、マニュアルやガイドラインにまとめる
- 内面化（Internalization）: 形式知→暗黙知。マニュアルを読んだ人が実践を通じて自分のスキルにする
このサイクルが回り続けることで、組織の知識が螺旋的に拡大していく。
全ての知識を管理しようとすると破綻する。優先度の高いナレッジから着手。
- 影響度×属人度マトリクス:
- 影響度高×属人度高 → 最優先で形式知化する
- 影響度高×属人度低 → 既にある程度共有されている。整理・更新を行う
- 影響度低×属人度高 → 余裕がある時に対応
- 影響度低×属人度低 → 現状維持でOK
「この人が明日辞めたら最も困ること」をリストアップするのが手っ取り早い。
ナレッジは「作って終わり」ではなく「使われて初めて価値がある」。運用の仕組みを設計する。
- ストック型: Wiki、マニュアル、FAQ（探して見つける情報）
- フロー型: 社内ブログ、チャットでの共有、勉強会（流れてくる情報）
- 更新ルール: 四半期に1回、担当者が最新性をチェック。古い情報は害にすらなる
- インセンティブ: ナレッジ共有を評価制度に組み込む。共有したことが「良いこと」として認められる文化を作る
「誰が見ても5分で理解できるレベル」を文書の品質基準にする。
具体例#
状況: EC企業のCS部門（10名）。ベテラン3名に問い合わせ対応が集中。新人は毎回ベテランに質問し、1件の解決に平均45分かかる。ベテランは1日の40%を質問対応に費やしている。
導入ステップ:
- 優先順位付け: 問い合わせの80%をカバーする上位50パターンを特定（パレート分析）
- 表出化: ベテラン3名に1人2時間ずつインタビュー。各パターンの対応手順・判断基準・よくある落とし穴を文書化
- 連結化: 50パターンをNotionの検索可能なFAQデータベースに整理。判断フローチャートも作成
- 運用ルール: 新しいパターンが出たら即座にFAQに追加。月1回ベテランがレビューして更新
| 指標 | 導入前 | 3ヶ月後 |
|---|---|---|
| 新人の一次解決率 | 40% | 75% |
| ベテランへのエスカレーション | 1日平均18件 | 1日平均7件（60%減） |
| 1件あたりの平均解決時間 | 45分 | 18分 |
| 新人のオンボーディング期間 | 3ヶ月 | 1.5ヶ月 |
問い合わせの80%をカバーする50パターンをFAQ化しただけで、新人の一次解決率が40%→75%に向上。ベテランのエスカレーション対応が60%減少し、複雑な案件に集中できるようになった。
状況: 自社SaaSの開発チーム（15名）。本番障害の対応が特定のシニアエンジニア2名に集中。2名が同時に不在だった週末に障害が発生し、復旧に8時間かかった（通常なら30分）。
SECIモデルの適用:
- 共同化: シニアエンジニアの障害対応にジュニアメンバーが同席するペアオンコール制度を導入
- 表出化: 過去1年の障害28件を分析。対応手順・判断基準・トラブルシューティングのフローを「ランブック」として文書化
- 連結化: ランブックをGitHub Wikiに整理。障害タイプ別のインデックス、コマンド集、エスカレーション基準を体系化
- 内面化: 月1回の「障害対応ドリル」でランブックを使った模擬対応を実施
| 指標 | 導入前 | 6ヶ月後 |
|---|---|---|
| 障害の平均復旧時間（MTTR） | 52分 | 18分 |
| シニア不在時の復旧時間 | 8時間 | 35分 |
| 障害対応できるメンバー数 | 2名 | 8名 |
| ランブックの記事数 | 0 | 42記事 |
シニアエンジニア2名の頭の中にあった障害対応ノウハウをランブックに形式知化し、月1回のドリルで内面化を促進。障害対応できるメンバーが2名→8名に増え、シニア不在時のリスクが劇的に減少した。
状況: 創業50年の建設会社。ベテラン職人（平均年齢58歳）10名が3年以内に順次退職予定。若手は12名いるが、「見て覚えろ」文化で技術伝承が進んでいない。「このままではベテランの退職と共に技術が消える」という危機感。
ナレッジ継承プロジェクト（12ヶ月計画）:
| フェーズ | 期間 | 施策 |
|---|---|---|
| 棚卸し | 1-2ヶ月 | ベテラン10名の「この人しかできないこと」を全て洗い出し（合計87項目） |
| 優先順位 | 2-3ヶ月 | 影響度×属人度で分類。最優先32項目を特定 |
| 表出化 | 3-8ヶ月 | 動画撮影+インタビューで暗黙知を形式知化。「なぜそうするのか」の判断基準も記録 |
| 共同化 | 並行 | ベテラン1名+若手2名の師弟チーム制を導入。現場でのOJTを強化 |
| 運用 | 9-12ヶ月 | 技術ライブラリ（動画+テキスト）をタブレットで現場から参照可能に |
「表出化」の工夫:
- 文字だけでは伝わらない技術は動画で撮影（ベテランが作業しながら解説）
- 「なぜそうするのか」の判断基準をインタビューで深掘り（例: 「この音がしたら止める」→具体的にどんな音か、なぜかを記録）
- 若手に「自分の言葉で書き直す」ことを求め、理解度を確認
| 指標 | 導入前 | 1年後 |
|---|---|---|
| 形式知化された技術項目 | 0/87 | 62/87（71%） |
| 若手が独力で対応できる工程数 | 平均3/15 | 平均9/15 |
| 手戻り・やり直し率 | 12% | 5% |
| 技術動画ライブラリ本数 | 0 | 128本 |
「見て覚えろ」では3年以内に技術が消えるリスクがあった。動画+テキスト+OJTの三位一体で暗黙知の形式知化を進め、若手の独力対応工程が3→9に拡大。ベテラン退職前に組織として技術を守る体制が整った。
やりがちな失敗パターン#
- 作ったドキュメントが使われない — 検索できない場所にあったり、情報が古かったりすると誰も見ない。「すぐ見つかる・常に最新・5分で理解できる」を基準にする
- 全てを文書化しようとする — 優先順位をつけず全網羅を目指すと、作成が追いつかず挫折する。影響度×属人度で絞り込む
- 共有する文化がない — 「自分のノウハウを教えると自分の価値が下がる」という認識があると、ナレッジ共有は進まない。共有を評価・称賛する仕組みを先に作る
- ストック型だけでフロー型がない — Wikiに蓄積しても誰も見に来なければ意味がない。社内ブログ、勉強会、Slackでの共有などフロー型の仕組みも併用して「気づく」きっかけを作る
まとめ#
ナレッジマネジメントは、組織の知識の属人化を解消し、全員の力に変える仕組み。SECIモデルの4プロセス（共同化→表出化→連結化→内面化）を理解し、影響度×属人度で優先順位を決め、「使われる」ための運用設計まで行うことが成功の鍵。技術やツールよりも、「知識を共有することが良いことだ」という文化の醸成が最も重要。