ナレッジトランスファー（knowledge transfer、略称KT）は、ある人や部署が経験から得た知識を別の人や部署へ移し、受け手の仕事で使える状態にすることです。日本語では「知識移転」と言い換えられます。
移転がうまくいかない理由は、社員のやる気より、受け手の前提知識や送り手とのやり取りのしにくさといった知識に関わる要因にある、という研究結果があります。この記事では、用語の意味と類語との違い、システム運用の事業者交代で求められる引継ぎ、移転を止める3つの障壁と4段階の進め方を、論文と政府ガイドラインを根拠に整理します。
まとめ：ナレッジトランスファーの意味と進め方の要点
- ナレッジトランスファーは、ある単位（グループ・部門・事業部）の経験が別の単位の仕事に影響する過程。日本語では知識移転、略称はKT。
- ナレッジシェアは知識を共有する行為、ナレッジマネジメントは知識を扱う経営の仕組み全体を指す。ナレッジトランスファーは、受け手が使えるようになるまでを含む点が違う。
- 8社122件の社内移転を分析したSzulanski（1996）は、主な障壁を「受け手の吸収能力の不足」「因果曖昧性」「送り手と受け手の関係の難しさ」とし、動機の問題より大きいと結論づけた。
- 進め方は「開始→実施→立ち上げ→統合」の4段階。資料を渡した時点ではなく、受け手の業務に定着した時点を完了とする。
- 政府情報システムでは、運用・保守の事業者が交代するとき、作業経緯と残存課題の引継ぎと、新しい事業者の習熟度の確認が求められている。
以下、定義から順に根拠を示します。
ナレッジトランスファーの意味と言い換え
組織研究での定義：別の単位の経験に影響を受ける過程
組織学習の研究者Linda ArgoteとPaul Ingramは、2000年の論文で、組織におけるナレッジトランスファーを「ある単位（例えばグループ、部門、事業部）が、別の単位の経験によって影響を受ける過程」と定義しました。
この定義の要点は、移転の成否を受け手側の変化で判断することです。マニュアルを配った、説明会を開いたという送り手の行為だけでは、移転が起きたとは言えません。受け手の判断や作業のやり方が変わって初めて、知識が移ったと判断できます。
日本語の言い換えと略称（知識移転・KT・ナレトラ）
日本語では「知識移転」がもっとも直訳に近く、職場では「ノウハウの継承」「業務の引き継ぎ」と言い換えられる場面もあります。英語の頭文字を取った「KT」や、カタカナを縮めた「ナレトラ」という略し方も使われます。
transferは「移す・移転する」という意味で、技術移転（technology transfer）と同じ語です。共有にとどまらず、持ち主が替わる・使い手が増えるところまでを含むニュアンスがあります。
ナレッジシェア・ナレッジマネジメント・スキルトランスファーとの違い
似た用語は、何を指すかで区別すると混乱しません。
| 用語 | 指すもの | 完了の目安 |
|---|---|---|
| ナレッジシェア | 知識を共有する行為 | 他者が参照できる状態 |
| ナレッジトランスファー | 知識を別の単位へ移す過程 | 受け手の業務で使われる |
| スキルトランスファー | 技能を別の人へ移す過程 | 受け手が同じ水準で作業できる |
| ナレッジマネジメント | 知識を扱う経営の仕組み全体 | 継続的な運用 |
ナレッジシェアは社内Wikiへの投稿やチャットでの共有など、行為そのものを指します。共有した記事が読まれなくても、共有自体は成立します。ナレッジトランスファーは、その知識が受け手の仕事を変えたかまで問います。
技能を「できる」状態まで移すことに焦点を当てるのがスキルトランスファーで、詳しくはスキルトランスファーの意味と5つの移転タイプで扱っています。ナレッジマネジメントはこれらを含む上位の枠組みで、国際規格ISO 30401:2018（2022年と2024年に追補を発行、改訂版ISO/DIS 30401を策定中）もあります。全体像はナレッジマネジメントの意味とSECIモデルを参照してください。
システム運用の事業者交代で求められる引継ぎ
IT部門で知識移転が避けられない場面の代表が、運用・保守の委託先の交代です。デジタル庁の「デジタル・ガバメント推進標準ガイドライン」（DS-100、2026年6月12日改定）は、情報システムの更改を伴わずに運用事業者や保守事業者が交代するとき、PJMO（プロジェクト推進組織）は交代前の事業者から交代後の事業者へ「作業経緯、残存課題等について確実に引継ぎがなされるよう求める」と定めています。
同ガイドラインの解説書（DS-110）は、PJMOが現行事業者に引継書を作成させ、新しい事業者の作業経緯や残存課題への習熟度を確認して、引継ぎが確実に行われたかを確かめるよう求めています。事業者どうしが直接引き継ぐ場合もPJMOが必ず関与すること、とも書かれています。
設計・開発事業者から運用・保守事業者への引継ぎでは、DS-110の表7-7が引き継ぐ資料の例を挙げています。
- 引継書：引継ぎ資料一覧、課題・リスク、案件やシステムの特性に伴う個別の引継ぎ事項
- 設計・開発関連資料：要件定義書、設計書、テスト結果報告書、移行結果報告書など
- 運用設計及び保守設計関連資料：運用計画書（案）、保守計画書（案）、運用手順書、保守手順書、ヘルプデスク運用マニュアル、FAQ
- 現物関連：ソースコード一式（IaC設定ファイル類を含む）、実行プログラム一式
民間の委託でも、この枠組みはそのまま使えます。特に「残存課題」と「習熟度の確認」は、資料の受け渡しだけで済ませると漏れる部分です。発注側は、引継ぎ期間の終わりに新しい担当者へ実際の障害対応や定例作業を説明させ、答えられない項目を残存課題として記録しておくと、後から「聞いていない」を防げます。手順書そのものの整え方はシステム運用保守ドキュメントの整備手順にまとめています。
移転を止める3つの障壁：Szulanskiの「粘着性」研究
8社122件の移転で分かった「やる気より知識の問題」
経営学者のGabriel Szulanskiは、社内で優れた業務のやり方（ベストプラクティス）を移そうとしてもなかなか移らない現象を「内部の粘着性（internal stickiness）」と呼びました。1996年にStrategic Management Journalに発表した論文では、8社・122件の移転について集めた271件の観測データを分析しています。
論文は、移転の失敗は主に動機の問題だとする通説に反し、主な障壁は知識に関わる要因だったと結論づけています。「教えたがらない」「学びたがらない」といった態度より、次の3つのほうが移転を強く妨げていました。
受け手の吸収能力の不足
吸収能力（absorptive capacity）は、Cohen and Levinthal（1990）が示した概念で、外部から得た新しい情報の価値を見極め、自分のものにし、事業に使う能力を指します。前提知識が足りない受け手には、どれだけ丁寧な資料を渡しても中身が定着しません。
対策は、移転の前に受け手の前提知識を確認し、足りない基礎を先に埋めることです。システム引継ぎなら、業務知識やアーキテクチャの概要を先に説明してから個別の手順に入ります。
因果曖昧性：成果の理由を送り手も説明できない状態
因果曖昧性（causal ambiguity）は、ある業務がなぜ成果を出しているのか、送り手自身も正確には説明できない状態です。ベテランの判断が経験則に頼っていると、手順だけ移しても同じ結果になりません。
この障壁に対しては、送り手に「なぜその手順なのか」を言葉にしてもらう対話から始めます。暗黙知を言葉や図にする方法は暗黙知と形式知の違いと形式知化の手順で解説しています。
送り手と受け手の関係の難しさ
論文は、送り手と受け手の関係が「困難（arduous）」であることも主な障壁に挙げています。暗黙知の多い知識ほど何度もやり取りが必要になるため、連絡が取りにくい、関係が疎遠といった状態では移転が進みません。
移転期間中は、送り手の工数を正式に確保し、受け手が気軽に質問できる窓口を決めておきます。「誰が何を知っているか」を組織で把握する考え方はKnow Who（ノウフー）の定義と意義やトランザクティブ・メモリーの基本が参考になります。
ナレッジトランスファーの進め方：4段階と各段階の作業
Szulanskiは、移転を4つの段階に分けています。どの段階で止まっているかを見れば、打つべき手が決まります。
| 段階 | 始まる条件 | この段階の作業 |
|---|---|---|
| 開始（initiation） | ニーズと、それを満たす知識の存在 | 対象の知識と受け手を決める |
| 実施（implementation） | 移転の実行を決めた時点 | 資料・説明を受け手向けに調整して渡す |
| 立ち上げ（ramp-up） | 受け手が知識を使い始めた時点 | 想定外の問題を解消し成果を上げる |
| 統合（integration） | 受け手が満足できる成果を出した時点 | 日常業務として定着させる |
開始段階では、組織の中にニーズと知識が同時にあっても、互いに気づいていないことがあります。まず「どの業務の、誰の知識を、誰に移すか」を決め、属人化している業務から優先順位をつけます。属人化の見つけ方は属人化の原因と脱属人化を進める仕組み化で扱っています。
実施段階では、送り手の知識をそのまま渡すのではなく、受け手の業務や前提知識に合わせて資料と説明を調整します。立ち上げ段階について、Szulanskiは先行研究を引いて「予期しない問題を直すための比較的短い機会」だと述べています。受け手が使い始めた直後に送り手が付き添い、つまずいた箇所をその場で直します。
統合段階では、移した知識の使い方が徐々に決まった手順になっていきます。資料を渡した実施段階で完了扱いにすると、立ち上げ段階で出る想定外の問題を拾えません。完了の判定は統合段階で行うべきです。受け手が送り手に聞かずに業務を回せているか、問い合わせの内容が変わったかを確認します。
移転の効果は、送り手に聞かずに回せる業務の範囲で測れます。Argote and Ingram（2000）は、移転は受け手の知識または成果の変化として現れ、その変化を測ることで移転を測定できるとしています。引継ぎ後の問い合わせ件数や、同じ作業にかかる時間の変化を記録しておくと、効果を数字で示せます。
ナレッジトランスファーの手法の選び方：形式知と暗黙知で分ける
形式知の移し方：文書・Wiki・FAQ
手順書・設定値・過去の障害記録など、言葉や数値で書ける形式知は、文書にして検索できる場所へ置くのが基本です。DS-110の表7-7も、引継ぎ資料の筆頭に引継書と設計書・テスト結果報告書を挙げています。社内Wikiの構築方法は社内wikiの作り方、ツールの選び方はナレッジ管理ツールの比較と選び方を参照してください。
ただし文書化は因果曖昧性を解消しません。書けるのは「何をするか」までで、「なぜそうするか」を送り手が説明できなければ、文書にも残りません。
暗黙知の移し方：同行・対話・メンタリング
判断のコツや顧客ごとの勘所など、言葉にしにくい暗黙知は、送り手の作業に受け手が同行する、送り手が受け手の作業を見て助言するといった、人と人のやり取りで移します。暗黙知と形式知が変換されていく過程は、野中郁次郎らのSECIモデルが説明しています。
この方法は送り手の時間を多く使います。移す知識が一部の人にしか必要ない場合や、業務自体を近く廃止・自動化する予定がある場合は、移転に工数をかけず、手順の簡素化を先に検討したほうが合理的です。
Dixonの5類型を使うときの注意
国内の解説記事でよく紹介される「連続移転・近接移転・遠隔移転・戦略的移転・専門知移転」は、Nancy M. Dixonの著書『Common Knowledge』（2000年）が出典です。原典の連続移転は、同じチームが前回の経験を次の機会に使う移転を指し、「別の部署へ段階的に広げる」ことではありません。戦略的移転も、時間や場所を隔てたチームへ、組織の広い範囲に影響する複雑な知識を移すことを指します。
各類型の原典での定義と使い分けは、スキルトランスファーの記事で比較表にしています。
ナレッジトランスファーが失敗する典型パターン
- 資料を渡した時点で完了にする：立ち上げ・統合段階を追わないため、受け手がつまずいても誰も気づかない。
- 送り手の工数を業務時間に組み込まない：通常業務の合間に任せると、関係の難しさという障壁がそのまま残る。
- 受け手の前提知識を確認しない：吸収能力が足りず、資料が読まれても使われない。
- ツール導入を目的にする：投稿数は増えても、受け手の業務が変わったかを誰も測らない。
- 残存課題を引き継がない：解決済みの手順だけが渡り、未解決の問題が交代後に再発する。
いずれも、送り手の行為で完了を判定していることが共通の原因です。完了の判定を送り手の行為から受け手側の変化に置き換えると、上の5つはいずれも途中で気づけるようになります。
よくある質問
ナレッジトランスファーを日本語で言い換えると何ですか？
直訳は「知識移転」です。職場では「ノウハウの継承」「業務の引き継ぎ」と言い換えることもあります。
KTとはどういう意味ですか？
knowledge transfer（ナレッジトランスファー）の頭文字を取った略称です。意味は知識移転で、担当者や委託先の交代に伴う引継ぎも含みます。
ナレッジトランスファーとスキルトランスファーの違いは何ですか？
ナレッジトランスファーは知識・情報を別の人や部署へ移すことを広く指し、スキルトランスファーは作業を「できる」状態まで技能を移すことに焦点を当てます。
ナレッジシェアとナレッジトランスファーの違いは何ですか？
ナレッジシェアは知識を共有する行為で、他者が参照できれば成立します。ナレッジトランスファーは、その知識が受け手の業務で使われるところまでを含みます。
Knowledge Transferは英語でどう使いますか？
「We held a knowledge transfer session before the handover.」（引継ぎの前に知識移転の会を開いた）のように、引継ぎや研修の場面で名詞として使います。
