内製化の範囲を先に定義する──4レベルのどこを目指すか
「運用の内製化」という言葉の中身は、企業によってまったく違います。まず自社が目指すレベルを決めないと、製品に何を要求すべきかが定まりません。
| レベル | 自社でできること | 必要な人材像 |
|---|---|---|
| L1：マスタ運用 | 品目・工程・作業者マスタの追加変更、権限設定 | 現場管理者＋簡単な教育 |
| L2：画面・帳票の変更 | 入力画面の項目追加、帳票レイアウト変更、通知条件の設定 | 情シスまたはキーユーザー |
| L3：業務ロジックの変更 | 工程フロー・チェックロジック・簡単な連携の追加変更 | ローコード開発ができる社内技術者 |
| L4：拡張開発 | API連携の開発、外部システムとの統合、独自機能の追加 | プログラミングができる社内技術者 |
多くの企業が現実的に目指すべきはL2〜L3です。L1すらベンダー作業になる製品は論外として、L4まで自社で担う体制は、MES専任者を継続的に確保できる企業に限られます。人材面の現実はMES技術者を社内で育てるで扱っています。
重要なのは、目指すレベルまでの変更が「設定」で届く製品を選ぶことです。同じ「対応可能」でも、設定で届くのか、ベンダー専用ツールでの開発になるのかで、内製化の成否は決まります。
4つの選定条件
条件1：設定変更の到達範囲。 デモで「画面項目の追加」「チェックロジックの変更」「帳票の修正」を実演させ、それぞれが設定か開発かを記録します。L2〜L3の変更が管理画面から届く製品が内製化の候補です。ローコード／ノーコード開発環境の実力と限界はローコード／ノーコードMESの実力と限界を参照してください。
条件2：開発環境が顧客ライセンスに含まれるか。 設定・開発ツールがベンダー（SI）専用ライセンスの製品では、構造上内製化できません。開発環境・テスト環境が顧客契約に含まれるか、追加費用はいくらかを確認します。
条件3：学習リソースの公開度。 マニュアル・技術ドキュメント・トレーニングが顧客に公開されているか。オンライン教材や認定資格制度、ユーザーコミュニティの有無は、担当者が交代しても内製体制を維持できるかを左右します。「ドキュメントはNDA後に開示」「研修はSI経由のみ」という製品は、内製化の難度が一段上がります。
条件4：SI依存度の実態。 その製品の導入・保守を担えるSIが複数社あるか、ベンダー1社（または特定SI 1社）に集中しているか。内製化しても、手に負えない変更は外部に頼ることになります。頼り先が1社しかない製品は、内製化の目的の一つである交渉力の回復が果たせません。この論点はMESのベンダーロックインをどう避けるかと地続きです。
内製化に向く製品タイプの例
プラットフォーム＋モジュール型。 サーバ単位の無制限ライセンスで開発環境（Designer）も無制限のIgnitionと、その上でMES機能を提供するSepasoft MES Modulesの組み合わせは、ドキュメントとトレーニングがオンライン公開されており、条件2・3を構造的に満たしやすい系統です。
ノーコードアプリ型。 Tulipのようにアプリを現場・情シスが自作する前提の製品は、内製化がそもそも製品コンセプトです。アプリの乱立を防ぐガバナンス設計が、逆に導入側の宿題になります。
ローコード設定型・ソース公開型。 中国系ではローコードの製造プラットフォームを掲げる摩尔元数や、商用オープンソースとしてソースコード提供まで行う万界星空のような系統があり、「ベンダーに依存しない」方向の極にあります。ただしソースを渡されることと保守できることは別問題で、L4人材の確保が前提です。
パッケージを買うか作るかという原点の判断はMESは内製かパッケージかで扱っていますが、本記事の文脈で言えば、内製化に向くのは「作る製品」ではなく「顧客が変えられるように作られたパッケージ」です。
契約前にベンダーへ投げる質問
- 画面項目の追加・チェックロジックの変更・帳票修正のそれぞれについて、顧客側での実施可否と必要なスキルを示してください。
- 開発・テスト環境は契約に含まれますか。含まれない場合の年額はいくらですか。
- 技術ドキュメントとトレーニングは、契約前にどこまで確認できますか。
- 貴社製品の設定・開発ができる技術者を、当社が採用または育成する場合、認定制度や教材はありますか。
- 御社以外でこの製品の保守を担えるパートナーは国内に何社ありますか。
よくある質問
内製化すると、ベンダーの保守契約は不要になりますか？
不要にはなりません。製品本体の不具合対応・バージョンアップ・セキュリティパッチはベンダーにしか提供できないため、保守契約は維持した上で、変更対応の外注費が減るという構造になります。保守契約の範囲から「軽微な設定変更」を外して料率を下げる交渉は成立し得ます。確認項目はMESの保守契約で確認すべき8項目を参照してください。
内製の担当者が退職したら、と考えると踏み切れません。
そのリスクは製品選定で下げられます。条件3（学習リソースの公開度）が高い製品なら、後任の育成コストは属人化した内製システムより大幅に低くなります。また担当者を1名にせず、L1〜L2の変更は現場キーユーザー2〜3名に分散させる体制にすれば、退職が空白に直結しません。「1人のスーパーユーザー」ではなく「層」を作ることが、内製化を続ける唯一の方法です。
開発環境・ドキュメント公開・SI依存度など、内製化に関わる確認項目を含む87項目の選定チェックシートを公開しています。
