記事を書いてる人：あまみ るい
「一人の若手の頭に、ベテラン5人分の知識を詰め込おうとしていた」
その言葉が出た瞬間、部長の顔が変わった。問題がなかったわけではない。ずっと問題はあった。ただ、それが何なのか、まだ「形」になっていなかった。
言葉にできないものは、引き継げない。
これは技術だけの話じゃない。問題そのものを言語化できなければ、解決も改善も始まらない。若手1人がベテラン5人分を背負わされている構造的な無理については、その実態を数字と事例で解き明かした前の記事で詳しく紹介した。ここでは、その構造をどう変えるかを話したい。
言葉にできないものは、引き継げない
なぜ「整理」だけで効率が5倍になるのか
「マニュアルを作れ」という指示を聞くと、多くの現場で拒否反応が出る。
時間がかかる。誰が作るのか。作ったところで使われないという経験がある。
でも、ここで言う「整理」は、マニュアルを量産することとは少し違う。
やることは2つだ。
まず内的要因と外的要因を「箱」に分けること。
「技術伝承がうまくいかない」という大きな問題を、外から来る圧力（少子化、ニーズの多様化、短納期）と、内側にある構造（製品の複雑化、保守範囲の広さ）に分類する。
これだけで、思考の「見通し」が劇的に変わる。
「問題がある」という状態から「A×Bの掛け合わせで問題が起きている」という状態に変わると、どこに手を打てばよいかが見えてくる。
次に、「覚えなければならないこと」と「引き出せればいいこと」を分けること。
すべてを頭に入れるのをやめる。代わりに「この場面ではこの情報にアクセスできればいい」という設計を持つ。
この2つを整理するだけで、無駄な試行錯誤（手戻り）が大幅に減る。技術の「面積」そのものは変わらないが、カバーの仕方が変わる。
マネジメント側の「OSアップデート」手順
部長がまずやるべきことは、若手への叱咤ではない。
ホワイトボードの前に立つことだ。
ステップ1：「現状の見える化」を会議にする
ベテランと若手を同じ場に集め、現在の業務負荷を並べる。
誰が何の技術を持っているか。どの機種・どの領域に、どれだけの問い合わせが来ているか。ベテランが退職したとき、どの技術が「空白」になるか。
これを「会議のアジェンダ」として共有する。感覚の話ではなく、構造として見える状態に置く。
ある研究では、問題を視覚化するだけで、チームの問題解決スピードが平均30%向上するという結果が出ている（出典：チームパフォーマンスに関する組織心理学研究）。「見える」ことは、すでに解決への入口だ。
ステップ2：整理のプロセス自体をOJTにする
部長がベテランと若手と一緒に「現状の分類」をする作業は、最高のOJTになる。
若手は、その場でベテランの思考パターンを、生きた文脈の中で学べる。「この症状が出たとき、なぜその手順で確認したのか」という判断の根拠を、その場で聞ける。
整理されていない情報の海に「飛び込め」と言うのとは、根本的に違う。
実践：技術を「検索可能な資産」に変える3つのステップ
では、具体的にどう進めるか。
STEP1：内的要因（製品の歴史・複雑さ）の可視化
まず内側を整理する。
自社製品の技術領域を書き出す。機械系、電子系、化学・材料系、ソフトウェア系。それぞれに、どの機種が関係しているかをマッピングする。
横軸：機種（古い順に） 縦軸：技術領域（機械/電子/化学/ソフト）
各セルに「対応可能な人材数」を数字で入れる。
これを作ると、数字が1または0になっている「リスクセル」が浮かび上がる。それがすなわち、ベテランの退職で失われる知識の場所だ。
STEP2：外的要因（納期・リソース）の現実的な棚卸し
次に外側を整理する。
採用状況と退職見込みのタイムラインを並べる。現在の対応件数と、各技術領域の問い合わせ比率を出す。短納期の要求がどの程度あるかを数字で把握する。
感覚ではなく、数字として見ることが重要だ。「人手が足りない」ではなく「3年後に機械系の対応者が2人から0人になる」という形で認識する。
横軸：年度（現在〜5年後） 縦軸：技術領域ごとの在籍者数
退職予定者を赤で示し、「技術の消滅時期」を可視化する。
STEP3：ベテランの脳内を「デジタル外部脳」へ切り出す
STEP1とSTEP2で「リスクセル」の優先順位がついたら、いよいよ知識の切り出しに入る。
重要なのは、記録の形式だ。
「ベテランAの技術を文書化する」という方式では続かない。それは「ベテランに自分の脳内を言語化してもらう」という多大な負荷をかける作業になるからだ。
代わりに、「事例起点」で記録する。
実際の問い合わせや不具合に対応するとき、その過程をリアルタイムで記録する。症状・仮説・調査した手順・原因・対処法。このセットを蓄積していく。
事例記録カードのフォーマット
機種：[機種名・製造年]
技術領域：[機械/電子/化学/ソフト]
症状：[具体的な症状]
仮説：[最初に疑った原因]
確認手順：[実際に調べた手順]
原因：[特定できた原因]
対処：[解決した手順]
担当者：[記録者名]このカードが100枚貯まると、ベテランの脳内の一部が、検索可能な資産として組織に残る。
ベテランが退職しても、カードは残る。
ポイントは「体系的な完成」を目指さないことだ。完璧なデータベースを作ろうとすると必ず挫折する。まず1件。次案件のときまた1件。それを習慣にする。
まとめ
プリンターメーカーの部長と話した時間で、最も価値があったのは「整理の時間」だった。
何が内的問題で、何が外的問題か。どこに知識の空白があるか。誰が何を持っていて、誰がいなくなったらどこが消えるか。
これを言葉と数字に落とし込むことで、「なんとなくやばい」という感覚が「3年後の特定の技術領域に具体的なリスクがある」という問題に変わった。
問題が変わると、解決策が変わる。
「若手をもっと鍛えろ」ではなく「このリスクセルに対して、この資料を作る」という具体的な行動が生まれる。
技術は人の頭の中だけに存在するものではない。整理し、記録し、引き出せる形にすることで、組織の資産になる。
その資産の上に立ったとき、若手はようやく「覚えること」ではなく「考えること」に集中できるようになる。本来の、創造的な開発の仕事に向き合えるようになる。
現状の言語化が、すべての出発点だ。
