製造業システムはパッケージか個別開発か

選択肢は4つある

実務では3番目（基幹はパッケージ、現場は個別開発）に落ち着く例が多く見られます。全面刷新を避けつつ、現場の実態に合わせられるためです。

Fit/Gapの手順

1. 対象業務を工程順に分解する（受注→設計→調達→製造→検査→出荷→請求など）
2. 各業務を「必須」「あると良い」「不要」に分類する。ここを飛ばすと全部が必須になる
3. 候補パッケージの標準機能で、必須要件が満たせるかを○／△（設定で可）／×で評価する
4. ×と△の項目について、業務側を変える案と、開発で埋める案の両方を出す
5. ×を埋める改修費・アドオン費と、保守/バージョンアップへの影響を金額と手間で見積もる
6. 5年程度の総額（ライセンス＋改修＋保守＋運用工数）で比較する

機能充足率は「機能数の割合」ではなく「必須要件の充足率」で見ます。使わない機能が多いパッケージほど、一覧上の充足率は高く見えます。

パッケージが適する条件

• 必須要件の8割以上が標準機能（または標準設定）で満たせる
• 業務側を標準に合わせる意思決定ができ、現場の合意が取れる
• 制度対応・法改正など、継続的なメンテナンスが必要な領域を含む
• 連携が一般的なCSV・APIの範囲で足りる
• 導入後に社内で設定変更・運用を維持できる担当者がいる

個別開発が適する条件

• 見積・原価・工程展開のロジックが自社固有で、そこが受注力になっている
• 製品・顧客ごとに工程や必要項目が変わり、標準のマスタ構造で表現できない
• 既存の基幹・設備との連携が個別要件になり、パッケージ側で吸収できない
• アドオン見積の積み上げが、個別開発と総額で変わらない水準まで来ている
• 現場の運用を止められず、業務単位で段階的に移行する必要がある

ベンダーロックと内製性

ロックインはパッケージ固有の問題ではありません。個別開発でも、ドキュメントが無く、特定の会社しか触れない状態になれば同じことが起きます。契約時に次を確認しておくと、後の選択肢が残ります。

• ソースコードと設計書の帰属、引き渡し条件
• データのエクスポート方法（形式、全項目が出せるか）
• 一般的な技術構成か、独自フレームワークに依存していないか
• 運用に必要な権限（サーバ、クラウド、ドメイン）を発注者側で保持できるか
• 他社が保守を引き継げる程度の文書が残るか

判断フロー

1. 課題は「システムが無いこと」か、「運用が決まっていないこと」か。後者なら開発の前に運用を決める
2. 対象業務は競争力に直結するか。しないなら標準に寄せる
3. 必須要件の充足率は8割を超えるか。超えるならパッケージ優先
4. 不足分は業務変更で吸収できるか。できないならアドオンか周辺システム
5. アドオン費が個別開発と同水準になっていないか。なっているなら個別開発を再評価
6. 保守を誰が担うか決まっているか。決まっていないなら方式の前に体制を決める

よくある質問

生産管理パッケージを入れたのに、結局Excelに戻ってしまいました。

多くの場合、原因は機能不足そのものではなく、現場の入力手順が業務の実態と合っていないことです。どの画面のどの入力が省略されているかを特定し、その入力が誰の判断に使われるのかを確認してから、パッケージ側の設定変更、周辺システムの追加、運用変更のどれで解くかを決めます。

Fit/Gapは誰が行うべきですか。

業務を説明できる現場側の担当者と、システム側の担当者の両方が必要です。ベンダーだけで実施すると、標準機能に寄せた評価になりやすく、導入後に例外が噴出します。評価基準（必須／あると良い／不要）を先に社内で合意しておくと、比較がぶれません。

アドオン開発は避けるべきですか。

一律に避ける必要はありません。問題になるのは、アドオンが増えてバージョンアップのたびに再改修が必要になる状態です。標準を変えるアドオンと、外側に足す周辺システムを区別し、後者に寄せると影響を抑えられます。