「Aさん、ちょっといいですか」が止まらない現場
ラインが止まった。原因はわかっていない。誰かが歩いていく先は決まっていた。
「Aさん、ちょっといいですか」
その一言で現場は動き出す。でも、Aさんが休んだ日は？Aさんが退職した翌月は？
これは技術の問題ではない。ナレッジの置き場所の問題だ。
—
よくある失敗——「聞けばわかる」で回し続けた代償
私がいた現場では、トラブル対応のノウハウは3人の頭の中にしかなかった。
「トラブルシューティング手順書」はあった。でも、誰も使っていなかった。
理由は単純だ。手順書を読んで解決する前に、経験者に聞いたほうが早かった。だから手順書は更新されず、ますます現実とずれていった。
失敗例を3つ挙げる。
1つ目。ベテランが異動した月、同じトラブルが3回連続で2時間以上止まった。手順書には「担当者に確認のこと」と書いてあった。
2つ目。別の現場では、新人が対応を判断できず、上司を呼ぶために30分待った。上司も「たぶんこれだと思う」という対応だった。
3つ目。トラブル記録は残っていた。Excelに。でも検索できる状態になっていなかった。ファイル名が「対応記録_最終版_修正2」だった。
どれも、悪意のある人間は一人もいない。それでも、同じトラブルが繰り返された。
—
なぜ起きるのか——ナレッジは「頭の中」にしか保存されていない
問題の構造は単純だ。
現場のトラブル対応ナレッジは、記録されていない。
記録されていても、「問い」と「答え」がセットになっていない。「アラームE-12が出たときはコネクタを確認する」ではなく、「対応履歴：2024年3月15日、E-12、コネクタ不良を発見し交換」という形で残っている。これは記録であって、ナレッジではない。
さらに、検索できない。PDFの深い階層に埋まっていたり、特定の人のPCにしかなかったりする。
個人の意識や努力の問題ではない。「誰でも引き出せる状態にする」という設計が、最初からなかっただけだ。
—
放置すると何が起きるか
短期的には残業が増える。ベテランに集中する質問対応が、定時後まで続く。
中期的には品質がブレる。同じトラブルでも、対応者によって判断が変わる。「あの人に聞いたときはこう言われた、この人はああ言った」という状況が生まれる。
長期的には引き継ぎが破綻する。退職・異動のたびに「あの人がいたから何とかなっていた」という話になる。ナレッジの空洞化は、気づいたときには手遅れになっている。
医療機器の製造・保守を扱う現場であれば、さらに深刻な問題になりうる。トラブル対応の記録が不十分だと、変更管理やCAPAの観点からも懸念が生じる可能性がある。この点は品質責任者・QMS担当者と事前に確認することを勧める。
→ [点検・保守の属人化が引き起こすリスクについては、この記事も参考になる](/medical-device-maintenance-solo-dependency-risk/)
—
改善するための判断基準——チャットボットが必要かどうか
まず確認したいのは、現在のトラブル対応の「現場での経路」だ。
まだ手作業・テンプレで十分な段階は、こういう現場だ。トラブルの種類が少ない、頻度が月数件、担当者が3人以下で引き継ぎがスムーズに回っている。この場合は、よくあるトラブルをQ&A形式でまとめた1枚のシートから始めるほうが効果的だ。
チャットボット導入を考えるフェーズは、こういう場合だ。トラブルの種類が多い・頻度が週に複数件ある・担当者が変わるたびに対応品質がブレる・ベテランへの「口頭確認」が日常的に発生している。この4つのうち2つ以上が当てはまるなら、ナレッジのデジタル化とチャット型の検索インターフェースが現実的な選択肢になる。
—
今日できる改善手順——ナレッジ収集からチャットボット化まで
Step 1：「よくある質問」を20件集める
まず、過去1年のトラブル記録を掘り起こす。記録がなければ、現場のベテランに30分インタビューする。「よく聞かれること」「自分がいないと困ること」を列挙してもらう。
この段階で大事なのは「問い」と「答え」をセットにすることだ。「コンベアが止まる」ではなく、「コンベアがセンサーエラーE-05を出して止まる場合、まず確認すること」という形式に変換する。
Step 2：Q&A形式に変換して検証する
集めたトラブルQ&Aを、現場の若手に読んでもらう。「これを見てひとりで対応できそうか」を確認する。わからないと言われた部分を書き直す。現場で通じない言葉は使わない。
この検証を1〜2回繰り返すと、実際に使えるQ&Aが残る。
Step 3：チャットボットに乗せる
Q&Aが20〜30件揃ったら、ツールに組み込む。現場でスマートフォンやタブレットから自然言語で問い合わせられる状態にする。「センサー E-05 止まる」と入力したら対応手順が返ってくる、という動きが理想だ。
最初から完璧にしようとしない。使いながら更新する前提で、まずリリースすることを優先する。
→ [現場での属人化を脱する組織設計については、この記事も参考になる](/medical-device-maintenance-depersonalization/)
—
次にやること——設計の肝は「更新される仕組み」にある
チャットボットは、作って終わりではない。使われないまま放置されると、手順書と同じ末路をたどる。
定着させるために必要な仕組みは2つだ。
1つは、「使われたか」を確認する仕組み。アクセスログや問い合わせ件数を月1回確認するだけでいい。使われていないQ&Aは削除または改訂する。
もう1つは、「新しいトラブルが入ってくる経路」を作ること。現場でトラブルが解決したら、担当者が1行の記録をチャットボットに追加できる状態にする。ここが設計の核心だ。
—
よくある質問
Q1. チャットボット導入に専門的なIT知識は必要ですか？
知識ゼロから始めることは難しいが、エンジニアが常駐していなくても導入できるツールは増えている。社内の情シスやDX担当者と1〜2回打ち合わせる機会があれば、概念の整理はできる。まずQ&Aを20件まとめる段階は、ITの知識は不要だ。
Q2. 現場スタッフが使いこなせるか不安です
チャットボットの定着は、使いやすさより「使う理由があるか」で決まる。「聞かないと仕事が進まない場面」に合わせたQ&Aが入っていれば、自然に使われる。最初は「よく聞かれる10件」だけに絞ることを勧める。
Q3. 医療機器の現場でも使えますか？
製造・保守のトラブルQ&Aをチャットボット化すること自体は、多くの現場で行われている。ただし、変更管理・バリデーション・記録管理の観点から、導入前に品質責任者・QMS担当者への確認が必要になる場合がある。規制への適合判断は、必ず組織の責任者が行う前提で設計を進めること。
Q4. 既存の手順書はどう扱えばよいですか？
手順書は「詳細資料」として残し、チャットボットは「入口」として使うのが現実的だ。現場では「まずチャットで確認、詳しくは手順書」という動線を作る。手順書をそのまま入力しても、検索精度が下がるため、要点を絞ったQ&A形式への変換が必要になる。
—
ツール紹介
社内Q&AをAIチャットボット化するツール
Difyは、ChatGPTをベースにした社内チャットボットを、ノーコードに近い操作で構築できるツールだ。Q&Aを入力してAPIキーを設定すれば、現場向けのチャット画面が作れる。無料枠もある。自社でサーバーを持つ場合はセルフホスト版も選択肢になる。
製造・保守現場でのナレッジ管理に特化したSaaSも複数出てきている。「製造業 ナレッジ管理 AI チャットボット」で検索すると、国内ベンダーのサービスが複数見つかる。比較する際は、検索精度・更新のしやすさ・現場端末（スマートフォン・タブレット）への対応を優先して確認したい。
現場に合う運用テンプレートを探す
「トラブルシューティング Q&A テンプレート」という形式は、NotionのテンプレートギャラリーやGoogle Workspaceのテンプレートとして公開されているものがある。まず自社のQ&Aをスプレッドシートで整理し、その後にチャットボットツールに移行するという順番が、現場への定着という観点では最も失敗が少ない。
→ [ベテランへの依存が残業・引き継ぎ破綻につながる構造については、この記事も参考になる](/maintenance-personalization-overtime-cause/)
コメント