ベテランの故障診断ロジックを次の世代へ渡す——ロジックツリーを使った技術伝承と新人教育プログラムの設計

※本記事には広告・アフィリエイトリンクを含みます。

ベテランが「音を聞けばわかる」と言った瞬間、現場の技術は個人の中に閉じ込められる。

新人はその横でメモを取る。でも書き取れるのは結果だけだ。「異音がしたらこのユニットを疑う」という判断の道筋は、言葉になっていない。

半年後、そのベテランが異動した。同じ機種の故障が来た。新人は最初から手探りでやり直すことになる。これは新人の理解力の問題ではない。診断ロジックを外に出す仕組みがなかっただけだ。

よくある失敗

現場でよく見る光景が三つある。

一つ目は、ベテランに聞けば5分で終わる診断に、新人が2時間かかるケースだ。手順書には「異常を確認し、原因を特定する」としか書かれていない。特定の仕方が抜けている。

二つ目は、同じ故障でも担当者によって診断ルートが違うケースだ。あるベテランはセンサーから疑う。別のベテランは電源系から疑う。どちらも結果は合っているが、新人はどちらを真似ればいいか分からない。

三つ目は、マニュアル改訂のたびにベテランの頭の中身が反映されないケースだ。マニュアルは更新されるのに、実際の判断は相変わらず「あの人に聞かないと分からない」まま止まっている。

なぜその問題が起きるのか

原因は新人の努力不足ではない。診断プロセスを構造化して残す仕組みがないことにある。

ベテランの診断は、経験によって枝分かれした条件分岐の集合体だ。「Aの兆候があればBを確認し、Bが正常ならCに進む」という流れが、頭の中で自動的に処理されている。

本人にとっては当たり前すぎて、言語化する必要を感じない。だから聞かれても「感覚でわかる」としか答えられない。これは属人化ではなく、情報が構造化されていないだけの状態だ。構造さえ与えれば、経験の浅い人間でも同じ判断ルートをたどれる。

この構造化の欠如は、[機械音の違いを聞き分ける判断](/maintenance-quality-difference-machine-sound/)のような感覚的な技術伝承の場面でも同じ形で表れる。

放置すると何が起きるか

診断ロジックが個人の中に留まったままだと、影響は品質だけにとどまらない。

診断に時間がかかれば、修理全体の納期が伸びる。納期が伸びれば顧客対応にしわ寄せが行く。「なぜこんなに時間がかかるのか」というクレームは、現場の技術力の問題ではなく仕組みの問題として発生する。

さらに、ベテラン一人に判断が集中すると、[その人が休めない状態](/medical-device-maintenance-solo-dependency-risk/)が固定化する。休暇を取ろうにも、対応できる人間が他にいない。これは本人にとっても組織にとってもリスクだ。

引き継ぎの場面ではさらに深刻になる。退職や異動の直前に慌てて聞き取りをしても、断片的な情報しか残せない。診断ロジックの大部分は、結局失われたまま次の担当者に渡される。

改善するための判断基準

すべてをすぐにロジックツリー化する必要はない。優先度を判断する基準を持つことが先だ。

発生頻度が低く、影響も小さい故障は、当面は手作業のヒアリングメモで十分だ。無理に体系化するコストの方が高くつく。

発生頻度が中程度で、対応者によって診断時間や精度にばらつきが出ている故障は、テンプレート化の対象になる。決まった質問と分岐をシートに落とすだけで、新人の判断速度は大きく上がる。

発生頻度が高く、診断ミスが顧客対応や修理品質に直結する故障は、ロジックツリーとして正式に構造化し、教育プログラムに組み込む対象になる。ここまで来ると、紙のテンプレートだけでは更新も検索も追いつかなくなり、ツールでの管理を検討する段階に入る。

今日できる改善手順

Step 1:ベテランの診断を「質問」として書き出す

ベテランに「どうやって直すか」ではなく「どういう順番で何を確認するか」を聞く。答えは「はい/いいえ」で分岐できる質問の形にする。これがロジックツリーの最小単位になる。

Step 2:分岐を図にして、新人にレビューさせる

書き出した質問を樹形図に並べる。ここで重要なのは、新人にそのツリーだけを見て診断させてみることだ。詰まった箇所こそ、暗黙知が言語化できていない部分になる。

Step 3:詰まった箇所をベテランに聞き直し、ツリーを更新する

新人が迷った分岐点をベテランに戻す。「なぜそこでその判断になるのか」を掘り下げる。この往復を2〜3回繰り返すと、実務で使えるレベルのツリーになる。

おすすめの次アクション

ロジックツリーが一つできたら、それを教育プログラムの核に据える。新人はまずツリー通りに診断し、慣れてきたら理由を自分の言葉で説明できるかを確認する評価に移す。

診断ロジックの属人化は、対応品質のばらつきや[残業の偏り](/maintenance-personalization-overtime-cause/)にもつながっている。あわせて、[顧客対応の個人差がリスクになる場面](/maintenance-quality-variation-customer-request-risk/)や、[属人化そのものを解消する視点](/medical-device-maintenance-depersonalization/)も確認しておくと、今回の取り組みを組織全体の改善につなげやすい。

よくある質問

ロジックツリーは全故障パターンに作るべきですか

すべてに作る必要はない。発生頻度と影響度で優先順位をつけ、対応者によってばらつきが大きい故障から着手するのが現実的だ。

ベテランが協力的でない場合はどうすればいいですか

「マニュアルを作る」ではなく「新人が迷った質問に答えてほしい」という形で依頼すると協力を得やすい。自分の経験を否定されるものではなく、活かす場として伝えることが大切だ。

医療機器の保守点検でロジックツリーを使う際の注意点はありますか

診断ロジックの整理自体は有用だが、点検記録や是正措置に関わる部分は、一般に社内のQMS運用や関連法令の要求事項を踏まえた確認が必要になる。最終的な判断は品質保証部門や責任者に委ねる前提で進めることが望ましい。

ロジックツリーは紙とデジタルどちらで管理すべきですか

対象範囲が小さいうちは紙やスプレッドシートで十分だ。ツリーの数が増え、検索性や更新履歴の管理が必要になった段階で、デジタルツールへの移行を検討するとよい。

ツール紹介

ロジックツリーを紙やExcelで管理していると、更新のたびに版がずれたり、どのツリーが最新か分からなくなったりする。故障診断のように更新頻度が高い情報は、検索性と更新履歴を持つ仕組みに乗せた方が長く使える。

ナレッジベース型の業務ツール

診断ツリーや手順を階層構造で保存でき、キーワード検索で目的のツリーにすぐたどり着けるツールは、複数拠点で同じ診断基準を共有する場合に向いている。更新履歴が残るため、誰がいつ分岐を修正したかも追跡できる。

教育・OJT管理ツール

新人がどのツリーをどこまで習得したかを可視化できる教育管理ツールを併用すると、伝承の進捗が「なんとなく育った」ではなく数字で確認できるようになる。評価基準とセットで運用することで、教育プログラム自体の改善にもつなげやすい。