手戻りが発注件数を超える現場で、どこから直すか｜工程分解で解釈違いの発生源を特定する

発注1件に対して、やり直しが約5回起きている

ある製造業の大手で、金型修正指示の業務を調べたときのことです。ある年の実績で、やり直しの件数が発注件数の約5倍に達していました。1件の発注に対して、平均5回の作り直しが発生していた計算になります。

この数字が示しているのは、担当者の能力や真面目さの問題ではありません。指示が伝わる過程のどこかで、意図が別の意味に変換されているということです。

手戻りは、DXの投資対効果を説明するときに最も使いやすい題材でもあります。工数削減率のような推計値と違い、件数は台帳から数えられます。にもかかわらず、多くの改善プロジェクトは「手戻りが多い」という認識のまま、どの工程に手を入れるかを決めずに着手します。結果として、最も目立つ工程（たいていは最終工程）にツールを入れて、発生源はそのまま残ります。

本記事では、手戻りの発生源を工程分解で特定する手順と、直す順序の判断基準を整理します。あわせて、記録の置き場という見落とされやすい論点と、この種の現場に固有の調達条件を扱います。

この記事が扱う範囲と、扱わない範囲

「手戻りが多い」では、どこも直せない

手戻りの削減を掲げたプロジェクトが空回りする原因は、対象の粒度です。「手戻りが多い」は現象の記述であって、原因の記述ではありません。原因は工程の中にあります。

先の現場の工程は、こう並んでいました。製品を測定する。測定結果をExcelと図面にまとめる。NG項目をグラフ化する。修正指示を作成する。金型設計者が3Dで確認・調整する。そして加工に回す。

この6つに分けた時点で、手作業が集中していたのが中間の3工程（まとめる・グラフ化する・指示を作成する）だと分かります。そして解釈違いとヒューマンエラーも、そこに集中していました。測定は機械が読み、加工は図面どおりに削るので、意味の変換が起きる余地が小さい。変換が起きるのは、人が数値を見て文章と図で意図を伝える部分です。

この分解をしないまま「金型修正指示業務を効率化する」と設定すると、どこに手を入れるべきかは決まりません。 業務名の粒度で語ると、業務名の粒度の対策（担当者を増やす、チェックを厚くする）しか出てこないためです。

工程の分解自体は、AI適用の可否を判定する前段の作業と同じものです。判断単位まで降りる手順は業務プロセスの棚卸しの進め方にまとまっており、手戻りの分析にもそのまま使えます。

分解の粒度は「誰が何を受け取るか」で切る

工程をどこで切るかに迷ったら、成果物の受け渡しで切るのが実務的です。測定値という成果物、まとめた表という成果物、グラフという成果物、指示書という成果物。受け渡しのたびに、渡す側の意図と受ける側の解釈がずれる余地が生まれます。

逆に、同じ人が同じ道具で連続して行う作業は、途中で切っても意味がありません。ずれは人と人の境界で起きます。

直す順序は「解釈が分かれる工程」から決める

改善の優先順位を決めるとき、一般には頻度×影響のマトリクスが使われます。手戻りに関しては、この基準だけでは順序を誤ります。

理由は、手戻りが下流で発覚するためです。発覚した工程の件数を数えると、最終確認の工程に件数が集まります。そこを厚くすると、確認は増えますが原因は残り、確認工数だけが積み上がります。

順序を決める基準は、その工程で意味の変換が起きているかどうかです。

「担当者によって違う出力が出るか」は、その場で確かめられます。 同じ測定結果を複数の担当者に渡し、それぞれに指示を作ってもらう。出力が揃わなければ、その工程には明文化されていない判断が入っています。

直す手段は、変換をやめるか、変換を構造化するか

意味の変換が起きている工程への打ち手は、2方向あります。

変換をやめる。 数値を言葉に置き換えず、数値のまま次工程へ渡す。先の現場では、3Dスキャナで測定を自動化し、測定結果と製品の3Dモデルを重ね合わせて合否を自動表示し、ズレ量を指定ポイント単位で自動抽出する設計にしました。人が数値を読んで文章に翻訳する工程が消えます。

変換を構造化する。 翻訳が避けられない場合は、自由記述をやめて入力の型を決めます。同じ現場では、修正指示を画面上の点および面に対して、矢印・コメント・数値で入力する形にしました。「もう少し削る」ではなく、どの位置をどれだけ、が構造として残ります。

どちらも、AIを後から足す発想ではありません。工程そのものを組み替えて、変換が起きる場所を減らしています。 個別の工程を自動化する話と、業務を再設計する話の違いはここにあります。全体の工程設計から入る場合はAI×BPRの進め方（9工程）、As-Is/To-Beの整理から入る場合はBPRの進め方が対応します。

履歴の置き場が無いと、直した知見が組織に残らない

工程を直しても、手戻りが再発する現場があります。原因の多くは、記録の置き場です。

先の現場では、修正指示の履歴が部署内に分散していて、過去の経緯を追えませんでした。同じ品番で以前どう直したか、なぜその判断をしたかが残っていないため、担当者が代わるたびに同じ試行が繰り返されます。

ここで失われているのは個人の記憶ではありません。置き場が無いのだから、書く意思があっても組織には溜まりません。 この違いは打ち手を変えます。属人化の原因を「ベテランが教えてくれない」に置くと教育の課題として扱うことになりますが、実際には情報構造の課題です。

したがって、工程を組み替えるときは、指示そのものをタスクとして進捗管理し、修正履歴をバージョン管理する設計を同時に入れます。後から足す機能ではなく、工程の一部として設計します。 知見の種類ごとに置き場と手段を選び分ける枠組みは現場知見の継承をAIでどう設計するかにまとめてあり、ここでいう履歴は例外知に相当します。

実績が計画の粒度で返ってこないと、改善が測れない

もう一点、記録に関する落とし穴があります。指示は工程単位で出しているのに、実績は日単位でしか取れていない、という状態です。この粒度では、どの工程で手戻りが起きたかを後から数えられません。

改善の前後比較をするつもりなら、着手時点で手戻りの件数を工程単位で数えられる状態を作っておきます。設備側からデータが上がってこない場合は、PLC・SCADAからのデータ収集方式の選定が先に必要になります。

調達の条件を先に確かめる ― 買い切り希望・保守契約なし

最後に、提案側が見落としやすい論点です。

先の現場から出ていた条件は、買い切りモデルを希望（サブスクリプションは不可）、保守運用契約は結ばず都度サポートを希望、というものでした。開発方式はスクラッチでも既存カスタマイズでも問わない。社内に開発体制は無く、既存サービスの利用も無い、完全な新規立ち上げでした。

この条件が意味することは重要です。サブスクリプション前提・継続的な保守前提で設計した提案は、この現場では検討に乗りません。 生産技術部門の設備投資として稟議を通す枠組みでは、資産計上できる買い切りのほうが通しやすい、という事情が背景にあります。

一般に語られる「良いプロダクトを作れば導入される」という前提は、ここでは成り立ちません。製造業の現場に入る仕事では、機能要件と同じ重さで調達の作法を確かめる必要があります。 投資判断の枠組みから逆算して提案を組む観点はDX投資の稟議の組み立て方に、本番運用に移す局面での要件はPoCを本番化する条件チェックリストに整理してあります。

まとめ：手戻りは「工程の粒度」で見ると直せる

• 「手戻りが多い」は現象の記述。成果物の受け渡しで工程を切り、どこで意味の変換が起きているかを特定する
• 直す順序は頻度×影響ではなく、変換が起きている工程から。下流で発覚するため、件数だけを見ると最終確認工程に手を入れてしまう
• 変換が起きているかは、同じ入力を複数の担当者に渡して出力が揃うかで確かめられる
• 打ち手は2方向。変換をやめる（数値のまま渡す）か、変換を構造化する（自由記述をやめて入力の型を決める）
• 直しても再発する場合は記録の置き場を見る。置き場が無ければ、書く意思があっても組織には溜まらない
• 改善を測るなら、着手時点で手戻りを工程単位で数えられる状態を作る
• 機能要件と同じ重さで調達の作法を確かめる。 買い切り希望・保守契約なしという条件は珍しくない

やり直しが発注件数を超えている状態は、異常ではありますが原因不明ではありません。工程を成果物の受け渡しで分解し、意味の変換が起きている工程を1つずつ数えれば、手を入れる場所は絞れます。着手の第一歩は、直近の工程を紙に並べて「ここで何が何に置き換わっているか」を書き込むことです。

次に読む記事