トラブルシューティングツリーは「作って終わり」ではない——現場で育てる更新ルールと運用フロー

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

ロジックツリーは、作った瞬間から古くなる

ツリーは共有フォルダに眠っている。

「去年の不具合対応を整理して、手順書を作りましたよね」と聞くと、「ありますよ、どこかに」という答えが返ってくる。そのファイルを開くと、担当者名は退職者、設備の型番は廃番、症状の分岐は現在の機種に対応していない。

作ったことは間違いじゃない。更新しなかったことが問題だ。これは個人の怠慢ではなく、「更新をどうするか」を決めずに運用を始めた仕組みの欠陥だ。

—

よくある失敗——「うちのことだ」と思う3つの場面

1. トラブルが再発するたびに「あ、これ前もあったな」で終わる

不具合が起きた。ベテランがすぐ対処した。「前にも同じことがあって、この部品を交換すれば直る」と言い、実際に直った。でも、その知識はロジックツリーに追記されない。次の同じ不具合で、若手は一人で迷う。

2. ロジックツリーを「参照している」のはベテランだけ

若手が「ツリーを見ながら対応した」と言っても、ベテランが横で「そこじゃなくて、こっちを先に確認するんだよ」と訂正している場面は珍しくない。ツリーの分岐と実際の判断順序がずれている。

3. バージョンが複数あって、どれが正しいかわからない

共有フォルダに「トラブルシューティング_v3.xlsx」「トラブルシューティング_最新.xlsx」「トラブルシューティング_田中確認済み.xlsx」が並んでいる。新人は3つを開いて比較し、どれを使えばいいかわからず、結局ベテランに聞く。

—

なぜ形骸化するのか——個人の問題ではなく、仕組みの問題

ロジックツリーが育たない理由は3つある。

「更新タイミング」が決まっていない。

不具合を解決したとき、誰かが「ツリーを更新しよう」と思っても、それを義務化するルールがなければ後回しになる。現場では「まず直す」が最優先で、振り返りは後回しになる。

「更新する人」が決まっていない。

みんなの仕事はだれの仕事でもない。「気づいた人が更新する」では、忙しい時期に更新は止まる。権限と責任を持つ担当者が指定されていない限り、ツリーは止まったままになる。

「承認フロー」がない、または重すぎる。

更新しようとしたら、上長の承認が必要で、その上長が多忙で2週間放置された——という経験は珍しくない。逆に、承認なしで誰でも書き換えられる状態では、ツリーの信頼性が失われる。どちらも機能しない。

—

放置すると何が起きるか

形骸化したツリーを放置すると、現場への影響は静かに広がる。

新入社員や異動者が一人でトラブルに対応できなくなる。「わからなかったのでベテランに確認しました」が常態化し、ベテランの対応工数が増え、残業につながる。これは[属人化による残業の構造](../maintenance-personalization-overtime-cause/)でも整理しているが、問題の根は「知識が移転されていない」ことにある。

品質面でも影響が出る。対応ごとに判断が微妙にぶれ、同じ症状に対して異なる処置が施される。顧客からの問い合わせに対し、担当者によって答えが違うという事態にもつながる。[品質のばらつきが顧客対応リスクになる](../maintenance-quality-variation-customer-request-risk/)のはここからだ。

また、ベテランが退職・異動するタイミングで、その経験知が丸ごと消える。[一人依存のリスク](../medical-device-maintenance-solo-dependency-risk/)は製造業全体の問題だが、ロジックツリーが機能していればそのリスクを大幅に下げられる。

—

改善するための判断基準

まず、今の状態を確認する。

まだ手作業・口頭で十分な場合は、トラブルの種類が少なく、かつ対応者が固定されていて、引き継ぎの頻度が低いとき。設備が2〜3台で、担当が長期安定しているなら、詳細なツリーより簡単なチェックリストで十分なこともある。

テンプレートで十分な場合は、不具合パターンがある程度見えていて、新人の育成や引き継ぎが課題になり始めたとき。ExcelやNotionで骨格を作り、月1回の更新ルールを設けるだけで大きく変わる。

ツール導入を考える場合は、設備台数が多く、不具合パターンが複雑で、複数拠点や多人数で情報を共有する必要があるとき。検索性、バージョン管理、承認フローを一元化できるナレッジ管理ツールを検討する価値が出てくる。

—

今日できる改善手順

Step 1：「更新トリガー」を3つ決める

ツリーを更新するタイミングを明文化する。たとえば、「① ツリーにない不具合が発生したとき、② 既存の分岐で対応できなかったとき、③ 対応手順が変わったとき」の3つ。これをルール文書1行で書き、チームに共有するだけでいい。

Step 2：「更新担当者」と「承認者」を1人ずつ決める

担当者は「気づいた人」ではなく、特定の役職か担当者名で決める。承認者は担当の上位1名。承認期限も「3営業日以内」など具体的に決める。これで「誰がやるかわからない」「承認待ちで止まる」が解消される。

Step 3：月1回、5分の棚卸しミーティングを設ける

先月の不具合対応を振り返り、「ツリーに追記すべき内容はあったか」を確認する。5分で終わる議題にする。長くしない。継続できないルールは機能しない。

—

おすすめの次アクション

まず、今使っているトラブルシューティングの資料を1つ開いてみることを勧める。最終更新日を確認する。半年以上更新されていなければ、Step 1から始める価値がある。

[属人化の排除と現場への引き継ぎ手順](../medical-device-maintenance-depersonalization/)も合わせて読むと、ツリーの整備が全体の脱属人化計画のどこに位置するかが整理できる。

—

よくある質問

ロジックツリーの更新頻度はどれくらいが適切ですか？

不具合の発生頻度による。月に複数件のトラブルが発生する現場なら、月1回の棚卸しが現実的だ。設備が安定していてトラブルが少なければ、四半期に1回の確認でも十分なケースがある。「定期更新」と「トリガー更新」の2種類を組み合わせると漏れが減る。

誰でも編集できる状態にすべきか、権限を絞るべきか？

誰でも編集できる状態は、情報の鮮度という観点では有利だが、誤記や混乱したバージョンが生まれやすい。基本的には「提案は誰でも可、承認・反映は担当者のみ」という構造が安定する。変更履歴が残る仕組みを選ぶことが前提になる。

既存のツリーが古くなっていた場合、一から作り直すべきですか？

一から作り直す必要はない。現在のツリーの「使えている部分」と「実態と合っていない部分」を分け、後者だけを修正するほうが現実的だ。全体を作り直すと労力が大きく、完成前にまた放置されるリスクがある。小さく修正して、継続更新できる状態を作ることを優先する。

QMS省令やISO 13485が関係する現場では、ツリーの管理方法に制約がありますか？

適用される規格や省令によって、文書管理の要件は異なる。一般的に、品質マネジメントシステムに関わる文書は改訂履歴・承認記録・配布管理が求められることが多いと考えられるが、具体的な要件の解釈と対応については、自社のQMS責任者や品質責任者に確認することが必要だ。断定的な判断は本記事では行わない。

—

現場の更新運用を支えるツール

Notion / Confluence（ナレッジベース型）

ツリーをドキュメントとして管理でき、変更履歴やコメント機能が標準で備わっている。チームでの更新・確認フローを組みやすく、検索性も高い。複数拠点での共有や、新人が自己学習できる環境を作りたい場合に向いている。既存のExcel管理から移行する最初のステップとして選ばれることが多い。

Confluence + Jiraの組み合わせ（タスク連携型）

ロジックツリーの更新タスクをJiraチケットとして起票し、誰が・いつまでに・どの部分を更新するかをトラッキングできる。「更新すべき状態になっているのに誰も動いていない」を可視化したい現場に向いている。規模が大きく、承認フローを厳密に管理したい製造業の品質部門での活用例がある。