故障対応を「経験者頼み」にしない——修理履歴を再現可能な知識として蓄積する記録設計

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

「Aさんに聞けばわかる」——その一言が、現場に何年も刷り込まれていた。

修理履歴は積み重なっている。でも開いてみると、「基板交換」「部品交換で解決」の数文字だけだ。どこを見て、何を判断して、なぜその処置を選んだのか。それがどこにも残っていない。

これは担当者の書き方の問題ではない。記録の「設計」が最初から欠けているのだ。

現場でよく見る失敗パターン

私がいた現場では、修理記録はExcelで管理していた。列は「日付」「機器名」「処置内容」の3つ。トラブルが起きるたびに1行追加する。それだけだった。

後輩が同じ症状の機器を担当したとき、記録を検索しても何も出てこない。「エラーコードE-12」で探しても、処置欄には「確認・調整」としか書いていないからだ。

こういう積み重ねから起きる失敗が、大きく3つある。

同じ故障を毎回ゼロから診断する。 過去に解決したはずの症状が再発しても、記録を参照できないためベテランが最初から考え直す。1件あたり2〜3時間の時間ロスが、月に何度も起きる。

引き継ぎが形だけになる。 ベテランが退職前に1週間ほど口頭で説明して終わる。だが口頭で伝えた知識は、引き継いだ側が同じ状況に直面するまで使い物にならない。引き継いだ後で初めて「あのとき聞いておけばよかった」となる。

対応品質がバラつく。 誰が担当するかによって、診断までの時間が3倍以上違う。顧客からすると「担当者によって直る速さが違う」という体験になる。これは[品質のばらつきが顧客対応のリスクになる](/maintenance-quality-variation-customer-request-risk/)典型的なパターンだ。

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

担当者が手を抜いているのではない。「何を書くべきか」が定義されていないまま、記録という行為だけが義務になっているからだ。

修理の現場では、診断のプロセスは頭の中で動く。「この症状ならここを見る」「このパターンのときはあそこを疑う」という経験則は、言語化されないまま体に染みついている。記録を書く時点ではすでに解決している。だから「何をやったか」だけを書いて終わる。

つまり問題は記録の「量」ではなく「構造」だ。何を書くか、どの順番で書くか、どう検索されることを想定するか——この設計が最初からなければ、記録は積み重なるだけで使えない資産になる。

放置するとどうなるか

短期的には「ベテランが頑張れば何とかなる」という状態が続く。でもその構造は、静かに限界に向かう。

ベテランの残業が常態化する。若手が同じ問題で何度も確認に来る。ベテランが休むと対応が止まる。この3つが重なったとき、現場は「一人がいなければ回らない」状態に陥る。[属人化が残業の原因になっている](/maintenance-personalization-overtime-cause/)構造そのものだ。

さらに深刻なのは、ベテランが退職したあとだ。口頭で伝えた知識は、引き継いだ担当者が同じ状況に直面して初めて「穴」として発覚する。そのとき、穴を埋める人間はもういない。

規制対象製品や医療機器を扱う現場では、[一人依存のリスク](/medical-device-maintenance-solo-dependency-risk/)が品質管理の観点からも問題になりうると一般に考えられている。記録が残っていないこと自体がリスクになる場面があるかどうかは、担当する品質責任者に確認することが望ましい。

改善するための判断基準

すべての現場がすぐにシステムを導入すべきか、というとそうではない。現状に合わせて段階を選ぶ。

まだ手作業でよい場合： 機器台数が20台以下、担当者が2〜3名、故障頻度が月5件以下。この規模なら、Excelのテンプレートを整備するだけで記録品質は大きく上がる。

テンプレートで十分な場合： 機器の種類が限られていて、故障パターンが繰り返す傾向にある。この場合、故障モードを事前に分類したチェックシートを用意するだけで記録の構造化ができる。

ツール導入を考える場合： 機器台数が50台を超え、担当者が5名以上、記録の検索や統計が必要になってきたとき。Excelの限界を感じ始めたら、専用ツールへの移行を検討するタイミングだ。

「再現可能な知識」に変える記録の構造

修理履歴を「次に使える情報」にするには、記録の項目を設計し直す必要がある。私が実際に使っていたのは、診断のプロセスをそのまま記録に落とし込む構造だ。

基本は「症状 → 疑った原因 → 確認した箇所と結果 → 特定した原因 → 処置内容 → 再発防止メモ」の6段階になる。

「症状」はエラーコードだけでなく、「どんな状況でどんなふうに異常が出たか」を書く。「疑った原因」は、診断前に立てた仮説を残す。これが次の担当者にとって最も価値がある情報になる。正解だけでなく「外れた仮説」も残しておくと、同じ誤解を繰り返さなくなる。

この6段階を埋めることで、記録はトラブルシューティングのロジックツリーとして機能し始める。「E-12エラーのとき、最初に何を疑うべきか」が記録から引き出せるようになる。

[設備の音から異常を読む技術](/maintenance-quality-difference-machine-sound/)と組み合わせると、「症状の詳細」欄の記録精度がさらに上がる。記録の質は、診断の精度に直結する。

今日からできる改善手順

Step 1：記録テンプレートを1枚作る

今使っているExcelに、「症状の詳細」「最初に疑った原因」「確認箇所・確認結果」「特定した原因」「処置内容」「再発防止メモ」の6列を追加する。まず1つの機器カテゴリだけに絞って試す。全機器に一気に展開しない。

Step 2：過去の記録を1件だけ書き直す

空欄や「調整」という記載しかない過去記録を1件選び、担当したベテランに30分インタビューして埋め直す。これを月1件続けるだけで、3ヶ月後には参照できる記録が増え始める。

Step 3：検索できる状態にする

症状や部位をキーワードとして記録に入れるルールを決める。「E-12」「電源系」「基板」などの語をどの列にどう書くかを統一する。これだけでCtrl+Fで検索できる知識ベースになる。

おすすめの次アクション

記録設計の改善は、テンプレート1枚から始められる。まずは自分の現場で最も再発頻度の高い故障モードを1つ選び、6段階の記録フォーマットを試してほしい。

[属人化を組織的に解消する](/medical-device-maintenance-depersonalization/)アプローチと並行して進めると、記録設計の取り組みが人材育成の仕組みにもつながる。記録が育てば、人が育つ。

よくある質問

Q. 記録を書く時間が取れない場合はどうすればよいですか？

記録の粒度を下げることを考える前に、書くタイミングを変えてほしい。処置が終わったあとにまとめて書くから時間がかかる。診断しながら仮説をメモし、処置後に結果だけを追記する「ながら記録」の方が、実際には短い時間で書ける。慣れると1件あたり5分以内に収まることが多い。

Q. ベテランが記録を書くのを嫌がる場合は？

「書け」という指示だけでは動かない。まず「書いてもらった記録が役に立った事例」を1件作ることが先決だ。若手が記録を参照して解決できた場面を共有すると、「自分の知識が使われている」という実感が生まれ、記録への動機が変わる。評価制度に組み込むのは、この実感が生まれてからでよい。

Q. 記録の標準化はどこから始めるべきですか？

一番再発頻度の高い故障モードから始める。全機器・全故障に一気に適用しようとすると必ず失敗する。まず1カテゴリ・1モードで「書いて、使って、改善する」サイクルを回す。3〜6ヶ月で形が見えてきたら、横展開を考える。

Q. Excelからツールへはいつのタイミングがよいですか？

「Excelが重くて開くのに時間がかかる」「複数人が同時編集してデータが壊れる」「履歴を統計的に見たい」の3つのどれかが出てきたタイミングだ。移行のコストより、現状の非効率コストが大きくなったときに動けばよい。ツールを先に選んで現場を合わせようとすると、定着しない。

修理履歴管理に使えるツール

CMMS（設備保全管理システム）の活用

Fiix、eMaintといったCMMSは、修理履歴の構造化記録・検索・統計分析を一括して扱える。機器ごとの故障履歴、処置内容、部品交換記録を紐付けて管理できるため、Excelの限界を超えたタイミングでの移行先として検討に値する。日本語対応のSaaS型サービスも増えており、導入ハードルは以前より下がっている。初期導入時には、記録テンプレートを現場で確立してからシステムに移行する順序が定着率を高める。

ナレッジベース型ツールの活用

Notion、Confluence、Sliteなどのナレッジ管理ツールは、故障モードごとにページを作り、症状・診断手順・処置例を構造化して蓄積するのに適している。設備管理特化ではないが、検索性と更新のしやすさに強みがある。現場メンバーが日常的に使い慣れているツールに記録を組み込むと、記録文化の定着が早い。何をどう書くかのテンプレートを先に設計してから導入することが、空欄だらけのページを量産しないための鉄則だ。