生産技術部が新ラインを立ち上げ、品質保証部が量産品質を見る。多くの中堅製造業で当たり前のこの分担が、引き継ぎの段差で年間数千時間を失わせています。立ち上げ判定会議の議事録は残るのに、設定条件をその値にした理由、想定外パターンへの対処の判断軸、部材ロットへの感応情報といった「現場知」は、誰も書かないまま量産フェーズに渡されていきます。本稿では、この分断がなぜ構造的に発生するのか、どこをデータモデルとして共有可能にすれば組織として引き継げるのかを、業務フローで分解して整理します。

「立ち上げ→量産」で失われる4種類の現場知

立ち上げ期に生産技術部が握っていた情報のうち、量産期に品質保証部が必要とする情報は、形式的には工程設計書・初期FMEA・作業標準書として残されています。ところが現場の聞き取りをすると、品質トラブル時に効くのは「文書に書かれていない判断軸」のほうだ、という回答が驚くほど揃います。

具体的には、設定条件の背景（なぜその温度・圧力・トルクなのか、許容幅の根拠は何か）、想定外パターン（試作時に1度だけ出た不具合とその対処理由）、部材ロット感応情報（特定サプライヤーの特定ロット番号で発生した工程変動）、設備個性調整知（同型機でも号機ごとに微調整した値の意味）、仕入先対応履歴（特定の事象に対する仕入先の出方の癖）の5つは、立ち上げ期にしか言語化されにくく、量産移行後はベテランの頭の中にしか残らないケースがほとんどです。

「形式知」と「現場知」のすれ違いが起こる業務フロー

立ち上げ期には、生産技術部のリーダーが工程設計→治具設計→試作評価→初期FMEA作成→立ち上げ判定会議までを一気通貫で握ります。判定会議でOKが出ると、文書一式が品質保証部に渡され、量産フェーズに入ります。しかし、判定会議の文書は「決定事項」しか残らない構造になっており、決定に至った判断材料、棄却された代替案、再発時の見方の指針といった「過程の知」は議事録の余白にも残らないまま消えてしまいます。

図2は、この引き継ぎ点で「現場知が消える瞬間」を業務フローで表したものです。立ち上げ期から量産期への線が形式文書のみで構成されること、量産期で得た是正処置の知見が立ち上げ期の初期FMEAに戻る循環が確立されていないことが、構造的なボトルネックです。

既存解決策が頭打ちになる理由

多くの組織は、この分断を埋めるためにFMEAの厳格運用、工程設計書のテンプレ標準化、TPMによる自主保全活動、立ち上げ後3カ月のフォロー会議といった対策を打ってきました。いずれも一定の効果はありますが、どれも「文書を増やす」ことで「現場知を引き継ぐ」ことを期待する構造をしている点で頭打ちになります。

FMEAは故障モードと影響を網羅することが本旨であって、設定値の判断理由を残す器ではありません。工程設計書は手順を残しますが、なぜその手順なのかは書きません。TPMは設備の癖を握るのに適していますが、立ち上げ期から量産期への時間軸での情報移送までは責任範囲に入りません。これらを根性論で重ねていくと、最終的にベテランが案件ごとに直接話を聞きに行く運用に戻り、属人化が再生産されます。

ERPは「お金とモノの記録台帳」、PLMは「図面とBOMの保管庫」であって、業務そのものを実行する仕組みではない

業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体

「記録の仕組み」と「業務を実行する仕組み」の違いを意識せずに文書化だけ厚くしていくと、立ち上げ期と量産期の引き継ぎ問題は永遠に解けません。文書はあくまで結果の記録であり、判断の背景や経過の知をそのまま運ぶ媒体ではないからです。

業務責任マトリクスで分断点を可視化する

立ち上げ期と量産期で同じ「品質」を見ていても、見ているレイヤーは異なります。下表は、現場ヒアリングから整理した責任マトリクスの一例です。空欄になっている項目がそのまま「引き継げない領域」と一致します。

業務領域	立ち上げ期（生産技術部）	量産期（品質保証部）	引き継ぎ可否
工程条件の決定理由	試作時の判断軸を保有	設定値のみ参照	困難
初期FMEA の前提	故障モード選定の根拠を保有	更新時に再評価が必要	部分的
4M変更の影響評価	立ち上げ時に1度実施	変更のたびに再実施	非連動
サプライヤー対応履歴	調達と直接交渉した経緯	量産後の品質会議で間接受領	遅延あり
市場品質からの学び	設計変更の起点として受け取りたい	是正処置として日常で処理	分断

「困難」「部分的」「分断」と書かれた行が、組織として引き継ぎ不全を起こしている領域です。重要なのは、これが個別担当者の能力や熱意の問題ではなく、業務基盤側の構造の問題だという点です。文書だけを増やしても、立ち上げ期の判断軸と量産期の運用知が同じデータモデルに乗らない限り、引き継ぎ点に立つ人が毎回ゼロから橋を架け直すことになります。

業務OS視点で「現場知」をデータモデルにする

業務OSという考え方の核は、文書を増やすのではなく、業務上の判断とその根拠を構造化データとして組織で共有可能にすることです。設定値の背景、棄却された代替案、想定外パターンの記述といった、これまで議事録の余白か個人のメモにしか存在しなかった情報を、誰が、いつ、何を理由に決めたかという粒度でデータベース化します。

立ち上げと量産を「ひとつの業務」として扱い、設備の癖・現場の改善知・保全履歴をエージェントが束ねて意思決定を支える基盤

生産技術OSとは——立ち上げ・保全・改善を統合する業務エージェント基盤

生産技術OSが「立ち上げ→量産→改善」を時間軸で繋ぐ役割を担うのに対し、品質OSは「FMEA→是正処置→市場品質→設計フィードバック」を空間軸で繋ぎます。両者がそれぞれ独立に動くのではなく、「現場知のデータモデル」を共有することが、立ち上げから量産への引き継ぎ不全を解く最短経路になります。

品質OSは、FMEAの個別運用ではなく「市場品質→是正処置→FMEA更新→設計改善」のループを業務基盤として組織で回すための仕組みである

品質OSとは——FMEA・是正処置・市場品質を一気通貫させる構造

引き継げる組織への移行で起こる業務の変化

「現場知のデータモデル化」が機能している組織では、量産開始から3カ月後の不具合発生時に、品質保証部の担当者が立ち上げ期の判断履歴を画面上で辿れます。「この温度を150℃にしたのは、A社のロット番号X以降で粘度が変動するから、180℃にすると別の不具合が出る、175℃で試したが歩留まりが落ちた」というレベルの判断の経過まで参照できる状態を作るのが、業務OS視点の到達点です。

これは大規模なIT投資を一発で行うという話ではありません。立ち上げ判定会議の議事録テンプレに「決定の理由欄」と「棄却した代替案欄」を必須化することから始まり、4M変更時に立ち上げ期の判断履歴を呼び出すフローを業務に組み込むこと、市場品質情報を初期FMEAの該当行に紐づけて返すルーティングを設定することと、段階的に積み上げていく性質のものです。

ROIの考え方——「引き継ぎ工数」を可視化する

ROIを試算する際は、「引き継ぎ不全による時間損失」を起点に置きます。図1で示した5要因の年間時間（合計約2,160時間／1ライン）に、平均人件時単価を掛けた金額が、現状の機会損失の下限値です。さらに、量産開始3カ月以内に発生する不具合の調査時間、是正処置の意思決定までのリードタイム、再発生時のロールバック工数を上乗せすると、組織規模によっては年間数千万円規模の損失が見えてきます。

金額の精度よりも、「自社のどの業務でどれだけ時間が失われているか」を可視化することが、業務基盤への投資稟議を組み立てる出発点になります。

自己診断ミニチェックリスト（5項目）

下記5項目のうち3項目以上に「あてはまる」と感じた場合、「立ち上げ→量産」の引き継ぎ不全が組織課題として発生している可能性があります。

• 立ち上げ判定会議の議事録に「決定の理由」「棄却した代替案」を残す欄が定型化されていない
• 量産開始3カ月以内の不具合調査で、立ち上げ期の判断履歴を辿るのに半日以上かかった経験がある
• 4M変更時、立ち上げ期の試作条件を再度ヒアリングし直すことが慢性化している
• 市場品質情報が、初期FMEAの該当行に紐づいて生産技術部に返るフローが確立されていない
• 立ち上げ期を経験したベテラン技術者の退職時に、組織として何を失うかが棚卸しされていない

反論への先回り——「FMEAを真面目に運用すればよいのでは」

本稿の主張に対しては、「結局はFMEAを丁寧に運用すれば解ける話ではないか」「現場知の暗黙化は、ある程度は属人化として割り切るのが現実的では」という反論があり得ます。

結論から述べると、FMEAの厳格運用は必要条件ですが十分条件ではありません。FMEAは故障モードを網羅するためのフォーマットであり、「設定値の判断軸」「棄却された代替案」「立ち上げ期に1度だけ観察された想定外パターン」を残す媒体としては設計されていません。これらをFMEAに無理に詰め込むと、欄が肥大化して見通しが悪くなり、結局参照されなくなる失敗パターンに陥ります。

「ある程度の属人化はやむを得ない」という割り切りについても、立ち上げ期と量産期で担当者が完全に分かれている組織構造では、属人化のコストが時間とともに累積していきます。担当者が変わるたびに、設定値の背景を辿るための時間が新たに発生し、組織として同じ問いを繰り返し解くことになります。引き継ぐべき情報をデータモデルとして握るかどうかは、属人化への姿勢の問題ではなく、業務基盤の設計判断です。

もちろん、すべての判断軸を構造化データに落とすのは現実的ではありません。当社の経験上、最初に効くのは「設定条件の背景」と「棄却した代替案」の2項目を立ち上げ判定会議の議事録テンプレに追加することです。ここを起点に、4M変更時の参照フロー、市場品質情報の初期FMEAへの紐づけ、と段階的に広げていくのが現実的なアプローチです。

FAQ

Q1. 既存のFMEA運用を捨てる必要はありますか

捨てる必要はありません。FMEAは故障モードと影響評価を網羅する用途で継続し、その横に「決定の理由」「棄却された代替案」「想定外パターン」を別データモデルで持つ構成が現実的です。両者を別々に持ち、紐づけて参照できる状態を作ることが起点になります。

Q2. 中堅企業でも導入できる規模感ですか

製造業の組織規模に関係なく、立ち上げ判定会議のテンプレ変更や、4M変更時の参照フロー追加といった、業務手順の改定から始められます。基盤投資はその後に検討する順番で、最初の3カ月は「議事録テンプレ」「参照フロー」の改定だけで2〜3割の引き継ぎ不全が解消するケースが多くあります。

Q3. 生産技術部と品質保証部の組織を統合する必要がありますか

組織統合は不要です。両部門が独立したまま、共有するデータモデルを業務基盤として持つ構成が現実的です。組織を動かす前に、業務基盤の側で「現場知の引き継ぎ」が成立する状態を作ることが優先されます。

Q4. 効果が出るまでにどの程度の期間が必要ですか

議事録テンプレと参照フローの改定だけであれば、適用開始から3カ月で立ち上げ期の判断履歴を辿る時間が半減する組織が多くあります。基盤化までを視野に入れる場合は、6〜12カ月での段階導入が目安です。

次のアクション

立ち上げ期と量産期の引き継ぎ不全がどの業務領域で発生しているかは、組織ごとに大きく異なります。当社では、貴社の業務フローに沿って「現場知のデータモデル化」が効く領域を特定する30分の業務診断を無料で提供しています。立ち上げ判定会議の議事録、4M変更時の判断履歴、市場品質情報のフローをヒアリングし、まずどこから改定すれば3カ月で引き継ぎ不全の20〜30%が解消できるかを、その場で具体的に整理します。

関連記事

• 生産技術OSとは——立ち上げ・保全・改善を統合する業務エージェント基盤
• 品質OSとは——FMEA・是正処置・市場品質を一気通貫させる構造
• 業務OSとは何か——製造業ERPでもPLMでもない、第3の業務基盤の正体