生産指示システムは自作か外注か ― 分かれ目は「止まり方」を設計できるか

「内製と外注、どちらがいいか」で検索すると、コスト・ノウハウ蓄積・スピード・品質という同じ4つの軸の比較記事に行き着きます。生産指示システムのように、失敗が物理的なライン停止に直結する領域では、この一般的な損得比較だけでは本当の分かれ目は見えてきません。製造ラインで最終的に効いてくるのは、異常が起きたときに「正しく止まれるか」という、比較記事にはほとんど出てこない軸です。

内製と外注、それぞれに言われるメリット・デメリット

内製の強みとしてよく挙げられるのは、外部委託費が発生しないこと、システムのノウハウが社内に蓄積されること、業務データが外部に出ないことです。一方で弱みは、担当者がPLC通信や業務知識を習得するまでに時間がかかること、そしてその担当者が異動・退職すると、蓄積したはずのノウハウごと失われることです。

外注の強みは、専門知識を持つ開発会社の経験をそのまま使えること、社内で人を育てる時間をかけずに立ち上げられることです。弱みは、開発費用がかかること、現場の細かい要望を正確に伝えるコミュニケーションコストがかかること、発注先によって品質にばらつきが出ること、そして社外に業務データを預けることになる点です。

どちらの軸も間違ってはいません。ただし、失敗のコストが物理的なライン停止に直結するかどうかには、あまり踏み込んでいません。この4軸だけでは、失敗が現場に直結する領域の判断材料としては足りません。

製造ラインで本当の分かれ目になるのは「止まり方」

私たちは大手自動車メーカーの製造ライン向けに生産指示・品質履歴システムを受託開発・保守しており、他社が開発した現場ソフトの引き継ぎ保守も行っています。この2つの経験を通じて見えてくるのは、外部で開発されたシステムであっても「動く試作」と「止まらない本番」のあいだに段差があるということです。同じ性質の段差は、開発体制を問わず起こりうると考えられます。

通信の型や桁を取り違えても、多くの場合は例外が出ません。値がそのまま黒箱の奥に沈み、誤ったデータのまま処理が進みます。接続断からの再接続、通信タイムアウト、常駐スレッドが黙って死ぬといった異常系は、開発機での試作段階では出会わず、実機が動く本番になって初めて顔を出します。試作が動いたことは、本番で止まらないことを何も保証しません。これらはそれぞれ別の対策が要る問題ですが、共通しているのは「黙って動き続けるか、正しく止まるか」という同じ問いを突きつけてくることです。

このうち、書き込むデータが番地やレイアウトの想定を超えてしまう問題については、私たちは一つの設計判断をしています。番地やレイアウトが未確定なまま書き込もうとしたとき、あるいは書き込むデータが確保した領域からはみ出すとき、黙って処理を続けさせず、例外を送出して書き込みそのものを拒否する設計です(詳しくは fail loud 設計の解説記事: /blog/plc-zr-spill-guard-fail-loud)。「止まらないシステム」より「正しく止まるシステム」を選んだのは、不確実な値のままラインを動かすことが、最終的にいちばん高くつくと判断したからです。

型の取り違えや接続まわりの異常系には、この仕組みとは別の対策(検証・監視の仕組み)が要ります。ただし考え方の芯は同じです。内製・外注のどちらであっても、異常系ごとに「黙って続けるか、正しく止めるか」を意図して設計し、開発段階で検証できる体制を持てているかどうかが、失敗のコストが物理的な現場に跳ね返る領域では決定的な差になります。

PLC通信仕様は、コードでなく紙の資料にしかない

止まり方を正しく設計するには、そもそも何が異常で何が正常なのかを知っている必要があります。ところがPLCの通信仕様は、ソースコードを読んでも分かりません。番地の割り付けやハンドシェイクの手順、ASCIIかバイナリかといった通信の型は、客先が支給する通信仕様書に書かれていて、それが唯一の一次情報です。

この一次情報が特定の担当者の頭の中だけにある状態を、私たちは属人化のリスクとして最も警戒しています。内製でこの理解を一人の担当者に依存させてしまうと、その人が異動や退職でいなくなった瞬間に、仕様の理解ごと失われます。コードは残っても、なぜその番地にその値を書いているのかという背景は残りません。これは外注でも同じで、発注先の担当者が一人に集中していれば、契約が終わったときに同じことが起こります。

自作が向くケース、外注が向くケースの整理

ここまでの2つの軸を踏まえると、内製と外注のどちらが向くかは、一方的には決まりません。

自作が向くのは、社内にPLCとPythonやC#の両方を理解する人材が複数いて、その保守を正式な業務として位置づけられる場合です。属人化のリスクは、担当者が複数いて相互にレビューできる体制があれば小さくできます。

外注が向くのは、異常系の設計・検証環境・長期保守までを、属人的な頑張りではなく仕組みとして担保したい場合です。これは「専門性がある」というだけでなく、止まり方を設計し検証する体制そのものを外部に預けるという判断です。外注先を選ぶときは、この体制を持っているかどうかが見極めの軸になります(関連記事: /blog/plc-integration-development-company)。

どちらか一方が常に正しいわけではありません。コストやノウハウ蓄積といった一般的な軸に加えて、異常系にどう止まらせるかを設計・検証できる体制を、自社の中に持てているか、それとも仕組みごと外に委ねるべきかで判断することを勧めます。

まとめ

あなたが今日から確認できるのは、今のシステム(あるいはこれから作るシステム)が、書き込み先の番地やレイアウトが想定と食い違ったときに、例外を出して書き込みを止めるか、それとも黙って書き込んでしまうかの1点です。ログを1つ追うだけで分かります。

内製か外注かという入口の選択より先に、異常系が起きたときに正しく止まれる設計を、自社の体制で作れるのか、それとも仕組みごと預ける相手が要るのかを見極めることが、失敗が物理ラインに直結する領域では優先順位の高い判断になります。

出典:

• 私たちが受託開発・保守する製造ライン向けシステムの設計判断・実装レビュー記録(社内一次情報)

※ この記事は AI を使用しています。Leadeas が自社開発した AI エージェント基盤で下書きを作成し、人間のレビューを経て公開しています。AI ネイティブ開発会社として自社の技術をそのまま実演する目的で、この手法を用いています。(詳しくは AI 利用ポリシー)