「なぜ壊れたか」をロジックツリーで分解する——医療機器トラブルシューティングの標準化入門

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

「あの人を呼ばないと直せない」——それは技術力の差ではない。

アラームが鳴った。若手スタッフが画面を確認する。症状はわかっている。でも次の一手が出ない。「ちょっとAさんに聞いてきます」と席を立ち、15分後にベテランが来て2分で原因を特定する。

このパターン、毎週起きていないだろうか。

これは若手の勉強不足ではない。「どう考えれば原因にたどり着けるか」という診断の構造が、現場に存在していないだけだ。

よくある失敗パターン

「症状を見て、直感で対処する」

経験者にとっては自然な動きだ。でも、その判断プロセスが文書化されていない。後輩は「なぜその部品を疑ったのか」がわからないまま、結果だけを真似する。次に同じ症状が出たとき、また一から探し直す。

「修理記録に書いてあるのは結果だけ」

「ポンプ交換」「センサー清掃」とは書いてある。でも「何を確認して、どこで異常を発見したか」のプロセスが抜けている。同じ症状が再発したとき、その記録は何の役にも立たない。

「担当者が変わると、また一から調べ直しになる」

引き継ぎのとき、「このトラブルはBさんに聞いて」という暗黙のルールだけが伝わる。手順は残らない。新担当者は同じ失敗を繰り返す。

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

原因は、担当者の能力の差ではない。

故障診断のプロセスが「個人の経験と感覚」に依存した形で積み上がっているからだ。

経験豊富な人は無意識のうちに、症状→原因の候補→確認手順→判断という流れを頭の中で組み立てている。ところが、この思考プロセスを「見える形」に落とした文書が存在しない。

問題は「知識の量」ではなく「知識の構造化がされていないこと」だ。

どんなに詳細なマニュアルを作っても、それが「チェックリスト」の形だけであれば、トラブルシューティングには使えない。故障診断には「もしAなら→Bを確認する、BがNGなら→Cを疑う」という分岐が必要だからだ。

放置すると何が起きるか

まず、同じトラブルが繰り返す。

「とりあえず動いた」で終わらせると、根本の異常は残ったままだ。数週間後、また同じ症状が出る。そのたびにベテランを呼ぶ。残業が増える。

次に、ベテターへの依存が固定化する。

「あの人がいないと対応できない」という状態は、体制の脆弱性そのものだ。異動・退職・急な病欠のタイミングで現場はパニックになる。[一人依存リスクの構造はこちらで詳しく整理した。](/medical-device-maintenance-solo-dependency-risk/)

さらに、品質のばらつきが顧客対応に影響する。

対応する人によって「直るまでの時間」「説明の内容」「再発の頻度」が変わる。これは現場の信頼性に直結する。[品質のばらつきが顧客リスクにつながる仕組みはこちらも参考にしてほしい。](/maintenance-quality-variation-customer-request-risk/)

ロジックツリーで何が変わるか

ロジックツリーとは、問題を「原因の候補」に段階的に分解し、確認の優先順位と判断基準を構造化したものだ。

製造業のトラブルシューティングでは、一般にFTA（フォールトツリー解析）やなぜなぜ分析と組み合わせて活用される。医療機器の現場では、これをQMS的な手順書と連動させることで、再現性のある対応が可能になると考えられる。

ポイントは「誰が読んでも同じ判断ができる」ように書くことだ。

たとえば「異常音がする」という症状を起点に、次のように分解できる。

• モーター系の異常か？　→　ベルト・ギア・軸受の確認
• センサー系の誤検知か？　→　信号値と閾値の確認
• 電源系の不安定か？　→　電圧・ノイズの確認

この分岐を一枚の図と手順書にまとめれば、経験の浅いスタッフでも「どこを確認すればよいか」がわかる。ベテランの「頭の中」を、誰でも使えるフローに変換することが目的だ。

改善するための判断基準

まだ手作業で十分な段階がある。

トラブルの種類が少なく、発生頻度も低い現場なら、まずはA4一枚の「症状→原因候補→確認手順」の表を作るだけでよい。

テンプレートが有効な段階もある。

同じ機種を複数台管理しており、類似トラブルが繰り返す場合は、機種別のロジックツリーテンプレートを整備する価値がある。一度作れば横展開が効く。

ツール導入を検討すべきタイミングは、管理台数が増え、記録・更新・共有の手間がスタッフの負担になってきたときだ。このタイミングで初めて、デジタルツールが意味を持つ。ツールを先に選ぶ必要はない。

今日できる改善手順

Step 1：直近3ヶ月の対応記録を見直す

修理・点検記録を引っ張り出し、「同じ症状が複数回出ているトラブル」を3件ピックアップする。その3件が、ロジックツリー作成の出発点になる。全部やろうとしなくていい。1件から始める。

Step 2：対応した人にプロセスをヒアリングする

「どんな順番で確認したか」「何を見て判断したか」を対話形式で聞き出す。「直感的にわかった」という答えには「なぜそこを疑ったのか」を深堀りする。この会話の記録がツリーの骨格になる。

Step 3：分岐図として1枚の紙に落とす

難しいツールは不要だ。最初はホワイトボードかExcelで十分。「症状A → 確認1がOKなら確認2へ / NGなら部品交換」という形で書く。完璧を求めず、まず1機種・1症状から始める。使いながら育てていけばいい。

ロジックツリーが1枚できたら、それを次の引き継ぎで使ってみる。[属人化が残業とどうつながるかの構造も、あわせて把握しておくと優先順位が立てやすい。](/maintenance-personalization-overtime-cause/)

—

よくある質問

ロジックツリーはどの形式で作ればよいですか？

最初はExcelかPowerPointで十分だ。フロー図のテンプレートを使えば見やすくなる。重要なのは「誰でも読んで判断できるか」であり、ツールの種類ではない。運用が定着してから、デジタル管理ツールへの移行を検討すればよい。形から入ると続かない。

なぜなぜ分析とロジックツリーの使い分けを教えてください

なぜなぜ分析は「過去の事象の原因を深掘りする」ためのツールだ。ロジックツリーは「次回以降の対応手順を構造化する」ためのツールだ。両方を組み合わせるのが有効で、なぜなぜで特定した根本原因をロジックツリーの分岐に組み込むと、再発防止の効果が高まると考えられる。

QMSとの整合はどう考えればよいですか？

医療機器の保守・修理の現場では、文書管理や変更管理に関する要求事項が関係してくる場合がある。ロジックツリーを標準手順書として位置づける場合は、文書番号・改訂管理・承認フローの設定が必要になる可能性がある。具体的な適用範囲については、QMS責任者や品質担当者に確認することを勧める。この点は組織の体制によって異なるため、断定的な判断は避けてほしい。

小規模の現場でも効果はありますか？

むしろ小規模こそ効果が出やすい。担当者が2〜3人の現場では、1人が休んだだけで対応が止まる。ロジックツリーが1枚あるだけで、別の担当者が初期確認を完結できる可能性が高まる。大規模展開より、まず1機種・1症状から始めることを勧める。[脱属人化の全体像はこちらの記事で整理している。](/medical-device-maintenance-depersonalization/)

—

ツール紹介

標準化の仕組みを整えるとき、次のツールが作業を助ける。

フロー図・業務図作成ツール

ロジックツリーの作成には、無料で使えるdraw.ioが扱いやすい。ブラウザ上で動作し、チームでの共有も可能だ。MicrosoftのVisioやLucidchartも選択肢になる。どのツールでも構わないが、まず1枚作り切ることが先だ。ツール選びに時間をかけすぎないようにしたい。

設備管理・メンテナンス記録ツール

修理記録・点検履歴をデジタルで一元管理できるツールは、ロジックツリーと組み合わせることで効果を発揮する。記録から「どの症状が多いか」「再発しているか」が可視化できれば、次にどのトラブルのツリーを整備すべきかの優先順位がつけやすくなる。[保守の現場でよくある異音対応の判断基準もあわせて参考にしてほしい。](/maintenance-quality-difference-machine-sound/)