技術伝承のプロジェクトを任されて、調べれば調べるほど方向が定まらなくなる。
マニュアル化、動画記録、AIツールの導入。
手段は山ほど見つかるのに、どれを選んでも前に進まない。
上司は曖昧な理由で承認を渋る。
他部門の管理職は、本業の忙しさを理由にメンバーを出さない。
ベテランは「背中を見て盗め」と協力を拒む。
若手は連日の残業に疲れて、関わろうとしない。
僕は業務効率化コンサルタントとして、製造業を中心に技術伝承プロジェクトの推進者から何度も相談を受けてきた。
関わる人たちのやる気は本物だった。
それでも止まるプロジェクトには、共通する抜けがあった。
この記事では、技術伝承を「終わらないプロジェクト」にしないための進め方を、5つのステップで解説する。
- 技術伝承が止まる原因は手段の不足ではなく、「目的」「範囲」「承認」「関係者の動機」「仕組み」のどれかが抜けていること
- 「ベテランの技術を100%残す」を目標にすると終わらない。今の業務フローに必要な情報だけに絞れば、ゴールが見える
- 承認は「教育」ではなく「今流出しているコスト」の言葉で取り、関係者は立場ごとの個人的なメリットで巻き込む
技術伝承が進まない会社で起きていること
まず、よく見る失敗の流れを確認しておく。
- 「ベテランの頭の中の技術をすべてドキュメント化する」ことを目的にする
- しかし、ベテランの頭の中に何があるかがそもそも分からない
- 分からないから、何を聞けばいいか質問が出てこない
- 一部をドキュメントにしてみるが、それが本当に必要なのか判断する基準がない
- あと何が足りないのか見当がつかず、終わりが見えない
- 途方もなく感じて、推進者もベテランも若手も動けなくなる
- 別のツールを導入したり、新しいプロジェクトを立ち上げたりして、同じことを繰り返す
これは、やる気や能力の問題ではない。
「何のためにやるのか」「どこまでやれば終わりか」が決まっていないまま走り出していることが原因だ。
加えて、技術伝承は総論賛成・各論反対になりやすい。
必要性は誰も否定しないが、いざ自分の時間を割く段になると強い抵抗が出る。
次の5ステップは、この抜けを順番に埋めていく手順だ。
| ステップ | 決めること | 抜けたときの症状 |
|---|---|---|
| 1. 目的 | 5年後の事業の数字 | 手段が選べない、意見がまとまらない |
| 2. 範囲 | 今の業務フローに必要な技術情報 | 終わりが見えない |
| 3. 承認 | 放置した場合のコストと経営計画とのつながり | 「落ち着いてから」と後回しにされる |
| 4. 巻き込み | 立場ごとの個人的なメリット | 会議では賛成、現場では非協力 |
| 5. 仕組み化 | 評価制度と業務フローへの組み込み | 一時的に動いても元に戻る |
ステップ1：目的を「5年後の事業の数字」で決める
技術伝承は目的ではなく、手段にすぎない。
ところが多くの企業が「技術伝承をすること」自体を目的にしてしまう。
目的がないと、何が起きるか。
- 情報を調べ続けるが、方向性が決まらないまま時間が過ぎる
- 企画を出しても、上司が曖昧な理由で承認しない（上司にも判断基準がない）
- ベンダーからDX・AI・自動化の提案を受けても、どれを選べばいいか分からない
- 現場にアンケートを取っても、意見がバラバラでまとまらない
- 高いシステムを入れても、結局今まで通りで何も変わらない
原因は「やる気がない」ではなく「判断軸がない」ことだ。
だから最初に、事業の言葉で目的を書く。
ポイントは「技術伝承」という言葉を使わずに、売上・コスト・人員配置の言葉で書くことだ。
守りの型：今後5年でベテランの多くが退職しても、今の売上とコストを維持する。
攻めの型：5年後の売上を増やす。そのために新商品の開発人材を増やし、保守に張り付く人材を減らす。
目的が決まったら、立場ごとに測れる目標値に落とす。
| 立場 | 守りの型の目標値の例 | 攻めの型の目標値の例 |
|---|---|---|
| 経営層 | 商品ごと・顧客ごとの5年後の保守コスト | 5年後の新商品開発数 |
| 管理職 | ベテラン・若手ごとの担当商品・担当顧客 | 新商品開発の平均期間 |
| ベテラン | 自分がいなくても若手が担当できる商品・顧客 | 差し戻しの件数 |
| 若手 | ベテランがいなくても担当できる商品・顧客 | 差し戻しの件数 |
ここまで決まって初めて、ツールや手段を選べる。
ベンダーの提案も「目的の達成に直結するか」の一点で判断できるようになる。
ステップ2：範囲を「今の業務フロー」で絞る。100%を求めない
目的の次に決めるのが、何を引き継ぐかという範囲だ。
ここで一番多い失敗が「100%の技術継承」を目指すことだ。
あるレジン加工企業（店舗の看板などを一品ずつ作る会社）の技術部長から相談を受けたことがある。
数年でベテランが大量に定年を迎える。
僕は、若手がベテランの横について「なぜそう判断したか」をメモし続ける「シャドウイング」を提案した。
不具合が起きたら、なぜその場所を調べたのか、なぜそれが原因だと分かったのかを記録する。
さらに「もし別の症状だったら？」と質問を広げ、まだ起きていないことについての知識も引き出す。
「これを2年続ければ、引き継げるだけのノウハウがたまります」と伝えると、部長はこう聞いた。
「それで、100%の技術ノウハウが引き継げるのですか？」
僕は「2年間で実際に起きる業務と問題、そこから派生して聞き出したことが引き継げます。ほかにどんなノウハウが必要ですか？」と聞き返した。
部長は少し黙って、「……それだけあればいいのか」と言った。
「100%」は高い基準に見えて、実際は「何が必要か定義されていない状態」だ。
ゴールが見えないから、どこから手をつければいいかも分からない。
技術伝承の目的は、ベテランの頭の中をすべて残すことではない。
ベテランが今担当している業務を、若手もできるようにすることだ。
40年前の手計算の設計方法や、今の保守に関係しない昔のトラブル話まで残す必要はない。
今の仕事の複雑さを考えると、範囲を絞ることは妥協ではなく必須だ。
あるプリンターメーカーでは、担当機種が10を超え、機械・電子・インクの化学・ソフトウェアの知識が絡み合い、数十年前の機種の保守も続いていた。
若手1人が、ベテラン5人分の範囲を背負わされていた。
これを「全部覚えろ」で乗り切ることはできない。
範囲を絞る方法はシンプルで、やることは2つしかない。
- ベテランが担当している業務フローを書き出す
- その業務フローの工程ごとに、必要な技術情報をリストにする
「ベテランの頭から知識を引き出す」のではなく、業務フローという箱を先に用意する。
箱があれば、何を入れるべきかが見え、抜け漏れにも気づける。
設計業務の例：
| 業務フロー | 必要な技術情報 |
|---|---|
| 企画書の理解 | 企画の元になった過去の案件情報／企画書に出てくる専門用語・技術情報／成果物の書式 |
| 設計 | 流用できる過去の案件／要件・仕様・設計中の問題を解決する技術情報／過去の失敗事例 |
| セルフチェック・レビュー | チェックリスト／過去のレビューの指摘 |
| 検証 | 検証ツールの使い方／検証項目と注意点 |
保守業務の例：
| 業務フロー | 必要な技術情報 |
|---|---|
| 準備 | 導入時の仕様書／顧客ごとの運用方法・設定内容／過去の似た事象と対処報告 |
| 保守作業 | 現地で分かった事象の解決方法／連絡する部署の連絡先／社内への報告フォーマット |
| 作業完了 | 顧客への説明資料 |
保存した情報は、「この機種でこの症状が出たときの対処」のように、必要なときに検索して取り出せる形にする。
若手の頭に全部を入れるのではなく、仕組みに持たせるという発想だ。
ステップ3：承認は「教育」ではなく「今流出しているコスト」で取る
役員の指示で始まったのに、予算やリソースの段階になるとDXや設備投資に負けて先送りになる。
「技術伝承は大事だが、今は本業の短納期対応が優先だ」
これは企画力の問題ではない。
現場は「人が育たない」という教育の言葉で話し、経営層は「利益がいくら損なわれているか」という数字の言葉で判断している。
使っている言葉が違うのだ。
だから、「教育しないと将来困る」という未来の話をやめる。
代わりに「今、これだけのコストが毎月流れ出ている」という話に変える。
何もしないことで発生し続けるコスト（Cost of Inaction）だ。
- 差し戻し1回につき1週間の遅れ × 年30回 ＝ 30週分の遅れ
- 若手2人で済む仕事にベテランが付きっきりになり、人件費が2倍になっている
- ベテランが教育や不具合対応に1日3時間取られている
こう数字にすると、技術伝承は「プラスアルファの教育投資」ではなく「利益の流出を止める手当て」になる。
さらに、会社の中期経営計画と結びつける。
経営層は、自分たちが立てた計画を達成するための提案を無下にできない。
- 今のロスを金額にする：差し戻しの工数やベテランの手間から、機会損失額を出す
- 経営計画とつなぐ：そのロスが中期経営計画の利益目標や人材戦略（自立型人材の育成など）の妨げになっていることを示す
- 投資対効果を示す：プロジェクトの費用より、止められる損失のほうが大きいことを示す
ステップ1で決めた「5年後の事業の数字」が、ここでそのまま承認の根拠になる。
ステップ4：関係者は「個人的なメリット」で巻き込む
計画が正しくても、人が動くとは限らない。
人は「会社にとっての正論」では動かない。
「自分の評価が上がるか」「自分の苦痛が減るか」で動く。
公式の会議で立派な計画を発表しても、細かい反対意見が出て「時期尚早」で片付けられることが多い。
勝負の大半は、会議の前の1対1の対話で決まる。
1on1や雑談の場で「正直なところ、どうすれば手伝ってもらえますか」と本音を聞き、その人のメリットになる形をプロジェクトの中に用意する。
全員が「自分のメリット」を確信した状態で会議を開けば、承認は通る。
| 立場 | 本音 | 用意するメリット |
|---|---|---|
| 上司 | 失敗の責任を負いたくない | 複数案から「選んでもらう」。上司自身が判断・推進した形にし、進捗を上司の成果として扱う |
| 他部門の管理職 | 本業の成績しか見ていない | 役員が見ているプロジェクトでの活躍が、自分の評価や昇進につながることを示す |
| ベテラン | 技術を奪われたくない、指導は面倒 | これまでの貢献への感謝と「先生役」としての立場。休日・夜間の呼び出しがなくなる約束 |
| 若手 | 残業とベテランへの気遣いに疲れている | 残業が減ること。プロジェクト経験が自分の市場価値になること |
推進者自身の動機も確認しておきたい。
「若手が可哀想だから」という善意で進めると、推進者に切迫感がなく、目の前の実務がいつも優先される。
技術伝承で本当に困るのは若手ではない。
若手には転職という選択肢がある。
一番困るのは、利益を失う経営層と、ベテランが抜けた穴をすべてかぶる中堅だ。
技術伝承は「若手のためにやってあげること」ではなく、「数年後の自分の仕事を守る手段」だと捉え直すと、優先度が変わる。
ベテランが協力しない理由そのものについては、ベテランが技術を教えないのはなぜ？で詳しく扱っている。
ステップ5：評価制度と業務フローに組み込み、元に戻らないようにする
個人的なメリットで人を動かせても、それだけではプロジェクトが終わると元の状態に戻る。
技術伝承を「日常の業務フロー」と「人事評価の項目」に組み込む。
- 伝承した情報（マニュアルやナレッジ）の定期更新を評価基準に入れる
- ベテランの評価軸を「個人の成果」から「若手が独り立ちした数」に移す
- 業務フローの中に記録の工程を入れ、若手のやる気に関係なく情報が残るようにする
「やる気のある若手が来たら始める」のではなく、誰が担当しても回る形にしておく。
ベテランの再雇用時に役割と評価をどう契約に書くかは、技術伝承のための再雇用契約で手順を解説している。
まとめ：最初の一歩は「5年後の数字」を一文書くこと
技術伝承が止まる原因は、手段の不足ではなかった。
次のどれかが抜けていることだ。
- 目的：5年後の事業の数字
- 範囲：今の業務フローに必要な技術情報
- 承認：放置した場合のコストと経営計画とのつながり
- 巻き込み：立場ごとの個人的なメリット
- 仕組み化：評価制度と業務フローへの組み込み
最初から完璧な体制を目指す必要はない。
まずは「5年後、事業がどうなっていればいいか」を一文書き出してみてほしい。
その一文が、範囲・承認・巻き込みのすべての判断基準になる。
次に、話の通じやすい若手やベテラン1人と腹を割って話し、小さな協力を得るところから始めればいい。
技術伝承は特別な魔法ではない。
業務フローという見えている道を、一歩ずつ歩くプロセスだ。
なぜ技術が特定の人に偏ってしまうのか、その構造は技術の属人化はなぜ起きる？で整理している。