ベテラン技術者と社員の知識を、定年退職の前に会社に残す

要点

会社にとって最も価値のある知識は、たいてい数人の頭の中にしかなく、その人が辞める日に一緒に出ていってしまいます。
本人にマニュアルを書いてもらうところから始めるのはやめましょう。実際に問題を解決している場面を記録するほうが、使えるものが残ります。
よいシステムは回答に必ず出典を示し、どの文書から出た答えなのかを人が確認できるようにします。

失われるリスクがあり、実際に頼られている知識から始める

自分に問いかけてみてください。20年勤めてきた技術者が明日辞めたら、すぐに止まってしまう仕事はどれでしょうか。その答えが、最初に残すべき知識のリストです。工場全体のマニュアルを片端から書くところから始める必要はありません。

ナレッジリスクマップ（Knowledge Risk Map）は、4つの問いから作ります。この人がいなくなったらどの仕事が止まるか、ミスが起きたときの影響はどれくらいか、教えるのにどれだけ時間がかかるか、代わりを務められる人は何人いるか、です。そのうえで、ベテラン技術者が何度も呼ばれるエラー、原材料が変わったときの機械の設定、大口顧客向けの例外対応、安全に関わる手順といった場面に優先順位をつけます。

専門家に「何を伝えたいですか」と漠然と聞くのは避けます。実際に起きたトラブルを1つ選び、ウォークスルー（Walk-through）で一緒にたどりながら、どんな兆候を見たか、どんな原因を考えたか、どの順番で確認したか、どこで手を止めるべきか、新人はどこでつまずきやすいかを聞いていきます。通常の手順に加えて、判断の理由と条件も記録します。

目標：「誰に聞けばいいかわからない」から、「状況に合った助言が得られ、いつエスカレーションすべきかもわかる」までの時間を縮めること。

経験をナレッジカードに変える

本人にマニュアルを書いてもらうより効果があるのは、実際に問題を解決している場面に付き添い、最初に何を見るか、何を手がかりに判断するか、そのやり方が通用しなかったのはどんなケースかを記録する方法です。

項目	必要な情報
前提条件	機械、型式、顧客、状況、制約
症状/質問	利用者が実際に検索に使う言葉と、その言い換え
確認の手順	順番、理由、基準値、画像
禁止事項	安全面、社内ルール、専門家に回すポイント
根拠	マニュアル、作業指示書（Work Order）、承認者
ライフサイクル	責任者（Owner）、バージョン、見直し日、ステータス

文字起こし、構成づくり、下書きの作成はAIに任せられますが、公開する前に専門家が内容を確認する必要があります。内容は1つの問題に答える小さな単位に分け、元のマニュアル全体へのリンクをつけます。Draft（下書き）、Approved（承認済み）、Deprecated（廃止）のステータスをはっきり使い分け、古い文書が最新版と同じように検索で出てこないようにします。

媒体を使い分ける：動作や位置は動画、症状は写真、ルールは文書が向いています。ただし、どれにもメタデータが必要です。メタデータがないと、AIが別の型式の答えを引いてくるおそれがあります。

出典を示し、「わからない」と答えられるアシスタントを設計する

システムは検索する前に、機械の型式、エラーコード、顧客、すでに試したことといった状況を聞くべきです。回答には出典、バージョン、日付を示し、確認済みの事実と提案を分けて示します。根拠が足りないときは「見つかりませんでした」と答えてエスカレーションの経路を用意し、一般的な知識から安全手順をでっち上げることはさせません。

アクセス権は、役割、拠点、機密レベルに応じて制限します。質問、使われた出典、フィードバックは、プライバシーポリシーに沿って記録します。チャットのメッセージをすべて自動でナレッジベースに戻すのはやめてください。誤解がそのまま広がってしまいます。更新案はAIに下書きさせ、責任者が承認する形にします。

公開前のテストセット

通常の質問と、さまざまな言い回し
似ているが、対処法が異なる型式や条件
答えがなく、そこで止まらなければならない質問
利用者に閲覧権限のないデータ
推奨してはいけない古い内容

ナレッジベースを最新に保ち、成果につなげる

更新は日常業務と結びつけます。重要な作業指示やトラブル対応が完了したら、AIがその記録からナレッジカードの下書きを作り、専門家が確認してから公開します。ダッシュボードには、答えられなかった質問、修正（Override）された回答、期限が近い内容、誰も使っていない記事を表示し、品質改善のバックログにします。

誰かが回答を直したり作業を完了したりするたびに、システムがその内容をナレッジベースに戻し、常に最新の状態を保つ

開発チーム向け · 技術指標

回答までの時間（Time-to-Answer）、初回で直せた割合（First-time Fix）、同じトラブルの再発（Repeat Incident）、エスカレーション、新人が独り立ちするまでの期間、安全に関わるミス（Safety Error）を合わせて測ります。回答が間違っていれば、利用率（Adoption）が高くても意味がありません。まずは20件の問題と1つのシフトのチームで始め、結果が良ければ分野と言語を広げます。

成果が出るのは、専門家の貢献が認められ、新人が早く学べて、実際のトラブルが起きるたびに組織が教訓を更新していく循環ができたときです。人から知識を吸い上げるだけでは、そこまで届きません。こうしてできたシステムは、置きっぱなしのファイル置き場とは違い、責任者のいる組織の記憶になります。

INTERVIEW TECHNIQUE · 答えの裏にある考え方を引き出す

「何か教えたいことはありますか」と聞く代わりに、Decision Replay（判断の再現）を使う

最近起きたトラブルを1つ取り上げ、写真や作業指示書を開いて、何を見たか、どの選択肢を外したか、どの兆候で考えを変えたかを、専門家に1つずつ説明してもらいます。「新人ならどこで間違えると思いますか」と聞くと、白紙からマニュアルを書いてもらうより多くの暗黙知（Tacit Knowledge）を引き出せることがよくあります。

最も重要な知識は1人に集中していることが多く、記録しなければその人と一緒に失われる

架空のケース：定年退職を控えたベテラン技術者がいます。マニュアルにはバルブを順番に点検するとしか書かれていませんが、判断を再現してもらうと、本人はカバーを開ける前に音を聞き、圧力の問題かどうかを切り分けていることがわかりました。そこでチームは、音声クリップ、異常音の例、安全のために作業を止めるポイントをナレッジカードに加えました。おかげで新人は、手順に加えて、それぞれの手順の理由まで理解できるようになりました。

回答の3C

Context：どの機械や顧客に当てはまるか。Citation：出典とバージョン。Cut-off：どこで止めて専門家に回すか。3つのうち1つでも欠けていれば、その回答はまだ現場では使えません。

ヒント：ナレッジカードには、知識を伝えた人と確認した人の名前を記載します。専門家の貢献が目に見える形で評価されれば、知識の共有は職業人として後に残すものになり、自分の代わりを作るために知識を取られる、という受け止め方にはなりません。

DNA MAKER · SOLUTION BLUEPRINT

知識を、現場で使える問題解決の仕組みへ

問題の核心

よいナレッジシステムは、すべての質問に答えようとはしません。承認された情報源をもとに答え、前提となる状況を示し、どこで止めるべきかを心得ています。

段階を踏んだ解決の進め方

ナレッジリスクマップを作り、実際のトラブルからDecision Replayを集める
Context、Citation、Cut-off、責任者を備えたナレッジカードに落とし込む
権限管理、フィードバック、見直しのサイクルを備えた検索型（Retrieval）のアシスタントを作る

正しい情報の責任者を明確にしたまま、組織の知識で質問に答えられるようにする

役に立つナレッジベースは、文書を検索するだけの箱では足りません。DNA Makerはまず、組織が重要な質問を選ぶところからお手伝いし、分類体系（タクソノミー）、メタデータ、責任者、バージョン、エスカレーションすべきポイントを整えます。内容を保証するのはお客様の専門家です。私たちは収集と検索の方法を設計し、回答に前提条件と出典が表示されるようにします。利用者はAIを盲目的に信じる必要がなくなり、組織はどの質問にまだ裏づけとなる知識がないのかを把握できます。

DNA Makerは、Webやモバイルで動くナレッジポータル、社内横断検索（Enterprise Search）、RAG（検索拡張生成）型のAIエージェントを開発できます。SOP（標準作業手順書）、マニュアル、チケット、社内の資料とつなぎ、役割に応じてアクセス権を制御し、出典つきで回答し、フィードバックを受け付け、情報が足りないときは専門家に引き継ぎます。ナレッジワークショップ、会話のUX設計、データ準備、システムアーキテクチャ、開発から、評価と分析までお手伝いします。ファイルは大量にあるのに、社員が同じ人に何度も聞きに行っているなら、その知識を、探しやすく、信頼でき、運用し続けられるシステムに変えるお手伝いができますので、ご相談ください。

SOFTWARE ENGINEERING GLOSSARY

ソフトウェア開発用語集

この表は、経営層、業務の責任者、開発チームが同じ言葉を別々の意味に取らずに話し合うためのもので、暗記する必要はありません。意味と例に加えて、右端の質問も読んでください。こうした質問から、開発を始める前に隠れていた範囲、リスク、コストが見えてくることがよくあります。

用語	意味	わかりやすい例	開発チームへの質問
RAG	回答する前に、AIに組織内のデータを検索させる仕組み	承認済みのSOPをもとに、文書へのリンクつきで回答する	システムはどの情報源を検索しますか？古い文書が使われないよう、どう防いでいますか？
Embedding	意味で検索できるよう、内容を数値に変換すること	「機械が熱い」で検索すると、高温に関する文書が見つかる	タイ語の内容や専門用語でも、本当に検索できますか？
Metadata	文書に付ける管理用の情報	機械の型式、責任者、有効期限を記録する	文書を探し、管理するために欠かせない項目はどれですか？
Access Control	誰がどのデータを見られるかを制御すること	チームごとに、自分の拠点のマニュアルだけが見える	権限はどう引き継がれ、異動したときにどう取り消されますか？
Citation	回答の出どころを示すこと	マニュアルの名前、バージョン、ページを表示する	利用者は元の文書とそのバージョンを確認できますか？

明日試せること：専門家に何度も電話がかかってくる質問を10個書き出し、実際のトラブルを1件選んで、最初のナレッジカードを作ります。責任者と見直し日も決めておきます。