金属加工の現場では、作業の手順を文書にしても、異常が起きたときの判断まで引き継ぐのは容易ではありません。私たちギグワークスクロスアイティが支援した中堅金属加工会社のA社においても、マニュアルは整っていましたが、現場ではベテランに直接聞く場面が続いていました。ベテランの退職が近づく中、A社は対話型UIで既存の資料を探しやすくし、日々の業務で判断の理由や結果を残す仕組みを整えました。蓄積した事例は他部署にも共有され、社内講習でも使われ始めています。
【関連記事】既存システムを生かして情報分断を解消！AIエージェントとMCPによる業務自動化事例
マニュアルがあっても判断は引き継げない
A社の製造部には、設備の操作や加工・品質確認の手順をまとめたマニュアルがありました。品質保証部にも、検査や是正の手順書がありました。それでも現場では、目の前の問題に合う記述をすぐに見つけられず、経験のある担当者へ尋ねる場面が少なくありませんでした。
ベテランの退職を見据え、A社は手順書の数を増やす前に、すでに持っている資料がどう使われているかを調べました。私たちは両部署の業務を確認し、現場で資料を探す際の困り事と、記録しておくべき判断を整理しました。
既存の資料が現場で使われなかった理由
加工した部品の表面に、普段は見られない異常が見つかったとします。担当者は、設備の状態、材料、直前に変えた条件などを確認し、次に何を調べるかを決めなければなりません。マニュアルには確認手順が書かれていても、今回の現象がどの項目に当たるのか、どの資料を開けばよいのか、すぐには分からない場合があります。その場で複数の資料を調べるより、事情を知るベテランに聞く方が早かったのです。ただ、相談相手が不在のときには、担当者が一から資料を探さなければなりませんでした。
品質上の異常を見つけた場合も、担当者が知りたいのは手順の名前だけではありません。過去に似た異常が生じたとき、何を先に確認し、どの時点で品質保証部に相談したのかを知った上で、対応を考えたい場面があります。こうした経緯の一部は作業後のメモに残っていました。一方、記録されず、担当者の間で口頭で伝えられるだけの内容もありました。必要なときに読み返せる形には整理されていなかったのです。
マニュアルには、標準の作業や確認事項を伝える役割があります。一方、現場で起きた問題に合う情報を手順書から探そうとしても、資料の見出しと担当者が使う言葉が一致しない場合があります。例えば、担当者が普段使う言葉で異常を説明しても、手順書には別の名称で書かれている場合があります。資料の保存先が分かっても、いま起きている問題に合う記述を探す負担は残ります。A社には、担当者が普段の言葉で質問し、既存の資料から必要な情報を探せる仕組みが必要でした。
残しておきたいのは「判断の経緯」だった
ベテランは、マニュアルに記載された手順だけでなく、現場で起きている現象や設備の状態も踏まえていました。マニュアルの手順と現場の状態を照らし合わせ、何から確認するかを考えていたのです。担当者がその結論だけを聞いても、別の条件で同じ判断をしてよいかは分かりません。引き継ぎたいのは「どう対応したか」に加えて、「何を見て、なぜその対応を選んだか」です。
その判断を後から振り返るには、対応後に何が起きたかも欠かせません。条件を変えて現象が収まったのか、別の原因を調べることになったのかまで記録します。結果まで残っていれば、後から似た事例を見つけた担当者が、自分の担当する業務の状況と照らし合わせられます。対応が終わる前の記録は未確定として扱い、結果が分かった時点で追記する方が、次にその事例を読む人にも経過を正しく伝えられます。
退職を控えたベテランから、長年の経験を一度の聞き取りですべて整理するのは現実的ではありません。A社は、日々の相談にベテランが加わった際、その判断の根拠を業務の記録に残す方針を取りました。記録を積み重ね、これまで口頭で伝わっていた知識を次の担当者も参照できるようにします。業務と切り離した聞き取りだけに頼らず、実際に問題が起きたときの条件を一緒に記録することで、後から判断を学ぶ人にも経緯を伝えられます。
資料の利用状況から見えてきた現状
A社は仕組みを変える前に、現場で必要な資料をどれだけ早く見つけられるかを確認しました。導入前の3か月間に現場で資料を探した40件のうち、5分以内に関連資料へたどり着けたのは16件、40％でした。この数字は、5分以内に関連資料を見つけた割合を示しています。加工品質や判断の正確さを示すものではありません。
記録の状況も調べました。同じ3か月間に記録の対象となった判断40件のうち、発生時の状況、判断理由、対応結果の3項目がそろっていたのは12件、30％でした。現場メモが残っていても、後から読む人に判断の前提が伝わらなければ、次の業務には使いにくくなります。特に結果が書かれていない場合、判断が適切だったのか、追加の確認が必要だったのかを読み取れません。A社は、必要な資料を見つけやすくし、後から使える事例を残すことを改善の出発点にしました。
私たちは、資料の管理方法や相談の流れが製造部と品質保証部で異なることも確認しました。既存のマニュアルを生かしながら、担当者が必要な箇所を探し、実際の業務で行った判断を事例として追加できる仕組みを検討しました。製造部は加工中の確認手順を探し、品質保証部は検査や是正の経緯を調べます。同じ事例を参照する際にも、それぞれの業務に必要な情報を確認できるようにしました。資料の探し方と事例を残す手順の両方を、各部署の業務に合わせて設計しました。
「どう判断したか」を記録として残す
A社は、整備済みのマニュアルや確認済みの事例を、現場で使う言葉で探せる対話型UIを導入しました。担当者は資料の正式名称を知らなくても、起きている現象や知りたい内容を自分の言葉で入力できます。画面には関連する手順や過去の対応が、参照元の資料とともに示されます。
同時に、業務中に行った判断を、対応後に記録する仕組みも整えました。資料を探して終わりにせず、今回の対応を次の業務で参照できる事例として残すためです。誰がどの内容を見られるかも、記録の段階から決めました。
質問から「手順」と「事例」にたどり着く
例えば、作業者が加工面の異常に気づき、「似た現象では何を先に確認したか」と尋ねたとします。対話型UIは、関連するマニュアルの項目と、確認済みの過去事例を探して示します。担当者は回答と参照元の資料を読み、記載された設備や材料の条件が現在の状態に当てはまるかを確かめます。
マニュアルと事例には、それぞれ役割があります。マニュアルは標準の確認手順を示し、事例はその手順を使ったときの状況や判断の経緯を伝えます。二つを一緒に探せると、初めて遭遇した現象について調べる際も、標準手順と過去の対応を行き来できます。対話型UIは関連資料を検索し、その内容を基に回答を作ります。回答には参照元も示し、担当者が根拠を確認できるようにしました。担当者は回答が短くまとめられていても、必要に応じて参照元の手順書や事例全体を読み、確認事項が抜けていないか確かめられます。
担当者は、似た事例の対応内容だけでなく、判断理由やその後の結果も読み、今回の状況と比べます。
担当者は、過去の事例に記録された異常や設備、材料の条件を今回の現場と比べ、マニュアルを読んで確認手順を決めます。条件が異なる場合は、過去の対応をそのまま当てはめず、必要に応じて製造部や品質保証部に相談します。該当する事例がなければ、マニュアルに沿って確認を進めます。対話型UIで資料が見つかっても、作業条件や対応方法は、担当者が現場の状態を確かめた上で決めます。
部品の表面に異常が見つかった場合は、対話型UIで似た事例を探し、当時の設備や材料、直前に変えた条件を確かめます。同じ表面の異常でも条件が異なれば、確認する順序も変わります。担当者はその違いを踏まえてマニュアルを読み、何を確認するかを決めます。対応後は、事例を参考にした点、新たに確認した点、対応を選んだ理由と結果を記録します。結果がすぐに分からなければ後から追記します。確認の経緯を残しておけば、次の担当者も当時の条件と自分の現場を比べられます。
「判断の経緯」と「結果」を残す
その日の対応が終わったら、担当者は業務の種類、発生時の状況、確認した事項、選んだ対応とその理由を記録します。ベテランに相談した際は、どの点に着目して対応を選んだのかも確認し、記録します。どの原因を考え、何を確認してその対応を選んだのかが分かれば、後から読む担当者も自分の現場との共通点や違いを確かめられます。後から似た現象に出会った人が、判断の筋道を追えるようにするためです。
対応後すぐに結果が分からない場合は、結果を確認中だと記録します。確認が済んだ後に追記すれば、途中の見立てと最終的な結果を混同せずに済みます。また、対応結果だけが残り、発生時の状況が抜けている記録も、そのままでは次の業務に使いにくくなります。A社は記録に必要な項目を決め、後から読む担当者に判断の経緯が伝わるかも確認しました。
記録した事例は、内容を確認してから対話型UIの回答に利用します。製造部や品質保証部の担当者が読み、判断の経緯に説明が足りなければ記録者へ尋ねます。例えば結果が「改善した」とだけ書かれていたら、何を確認して改善と判断したのかも確かめます。判断の途中で立てた仮説や結果が未確認の対応は、確定した事例として検索結果に表示しません。担当者が内容を確認した事例から公開し、日々の業務で記録を増やしていきます。
閲覧範囲を分けて事例を共有する
A社は事例の情報を、担当部署内だけで閲覧できるものと、他部署にも共有できるものに分けました。顧客名を閲覧できるのは、その顧客を担当する部署の社員に限ります。他部署向けの画面や添付資料、社内講習の配布資料からは、顧客名など部署内だけで扱う情報を除きます。
対話型UIでは、利用者の所属部署に応じて検索できる資料を絞り、回答に表示する内容も制限しました。他部署の担当者が同じ画面から質問しても、顧客名は検索結果や回答に表示されません。
他部署へ公開する事例には、発生した現象、設備の確認結果、対応を選んだ理由を残します。公開前に本文と添付資料を確認し、顧客名など部署内だけで扱う情報を除きました。顧客名を除いても、他部署の担当者が当時の判断をたどれる内容にしています。
蓄積した事例から学びを伝える
対話型UIと判断記録の仕組みは、導入しただけでは定着しません。A社はまず製造部の対象業務から運用を始め、記録にどれほど手間がかかるか、現場で必要な資料を探せるかを確認しました。品質保証部も事例を確認し、後から読む人に判断の経緯が伝わるかを確かめました。
事例が増えるにつれ、日常業務での参照に加えて、社内講習でも使われるようになりました。講習では、ベテランの判断を結論だけで覚えるのではなく、当時の状況を踏まえて考える題材として扱っています。
使いながら記録の質を高める
記録を始めた当初は、事例によって説明の詳しさに差がありました。現象は分かっても、なぜその対応を選んだかが十分に書かれていない記録もあります。対応方法は書かれていても、後日どうなったかが未記入の事例もあります。製造部と品質保証部の担当者は、他の人が読んで経緯を追えるかを確認し、不足があれば記録者に追記を依頼しました。
マニュアルと事例の内容が食い違ったときは、事例に記録されている当時の設備や材料の条件を確認します。マニュアルを更新するべきか、個別の対応として残すべきかを担当者が判断します。更新が必要なら手順書へ反映し、個別の対応なら、その条件を事例に書き添えます。後から読む人が、手順書と事例の違いを理解できるよう、確認した内容を残しておきます。現場の経験を記録に取り込む作業は、手順書の内容を見直す機会にもなりました。
導入後の3か月間に現場で資料を探した40件のうち、5分以内に関連資料へたどり着いたのは30件、75％でした。導入前の40％から35ポイント上がっています。記録対象40件のうち、状況、判断理由、対応結果がそろった事例は32件、80％となり、導入前の30％から50ポイント上がりました。これらの数字から、必要な資料を見つけ、判断の経緯を残す取り組みが進んだことが分かります。必要な項目がそろっていない事例を調べれば、記入漏れの多い項目に合わせて、入力方法や記録の確認方法を見直せます。
過去の判断を講習の題材にする
製造部と品質保証部は、他部署の担当者も閲覧できる事例から、社内講習で扱う題材を選びました。顧客名を示さなくても、発生時の現象や確認した順序、判断理由が分かる事例なら、受講者が自分で対応を考えられます。講習では、まず受講者に当時の状況だけを示し、何を確認するか考えてもらいます。その後、受講者が考えた対応を、実際に担当者が選んだ対応や結果と照らし合わせます。
同じ加工面の異常でも、設備や材料の状態によって、確認すべき点は変わります。講習では、過去の対応を暗記するより、判断に至るまでに何を確認したかを考えてもらいます。ベテランの経験が記録に残っていれば、当時の対応に立ち会わなかった受講者も、なぜその対応を選んだのかを議論できます。品質保証部の視点を加えると、製造部だけでは気づきにくかった確認事項にも目を向けられます。製造部と品質保証部で同じ事例を検討すれば、いつ相手の部署へ情報を伝えるかも議論できます。
A社では導入後に講習を2回実施し、次回の講習で扱う事例も選んでいます。講習で受講者から出た疑問を基に、事例の説明が足りない箇所を探します。状況の説明だけでは、なぜ別の対応を選ばなかったのか分からない場合もあります。記録を作成した担当者にその点を確認し、判断の理由を補います。説明を補った事例は日常業務でも参照しやすくなり、業務で新たに残した記録が次の講習の題材になります。
継承するための仕組み作り
事例は時間がたつと、設備や手順の変更によって当時の内容がそのまま使えなくなる場合があります。A社は、講習を準備するときや現場から質問が寄せられたときに、よく参照される事例を読み直します。設備や手順の変更を反映していない記述があれば修正します。古い事例と現在の手順の違いを確認し、担当者が今回の作業に使えるか判断できるようにします。事例を実際に使う製造部と品質保証部が、内容の確認を続けています。
A社では、ベテランの退職後も技術を引き継げるよう、新しい担当者が過去の事例を参照し、自分が行った判断と結果も記録していきます。過去の対応が有効だった条件を読み、今回と異なる点を確かめた上で事例を使います。事例を更新し続ければ、過去の判断を日々の業務や社内講習でも生かせます。新しい担当者の疑問を受けて事例の説明を補えば、経験者には当たり前だった確認の順序も、次の人へ伝わりやすくなります。
導入後は、5分以内に関連資料を見つけた件数が増え、判断の経緯が残る事例も増えました。蓄積した事例を使った講習も始まっています。技術継承そのものには時間がかかります。講習や日々の質問を通じて資料の説明不足に気づいたら、必要な箇所を補います。A社は、新しい事例を増やし、既存の事例やマニュアル、講習の題材も見直しています。次の担当者が判断の理由を学べるようにするためです。
まとめ
A社ではマニュアルの整備が進んでいました。それでも現場では必要な箇所を探しにくく、ベテランが個々の状況に応じてどう判断したかも十分に記録されていませんでした。そこで対話型UIを導入して既存の資料と事例を探しやすくし、日々の業務で状況、判断理由、対応結果を記録できるようにしました。導入後は、5分以内に関連資料へたどり着いた件数と、状況・判断理由・対応結果がそろった記録の件数が増えました。
顧客名を確認できるのは担当部署の社員だけです。顧客名を除いた事例は他部署にも共有し、社内講習で活用しています。講習で出た疑問を基に事例を見直し、日々の業務から新しい記録を加えています。事例を増やしながら、後から読む担当者に当時の状況が伝わるかも確かめています。A社は資料や事例を日々の業務で使いながら更新し、担当者が替わっても過去の判断を参考にできるようにしています。既存の資料を使い、判断の背景を残し、その記録から学ぶ流れが、ベテランの退職を見据えた中長期的な技術継承を支えています。
この記事を書いた人
