「現在の保守ベンダーに対応スピードや品質への不満がある。でも、どこから手を付ければよいか分からないし、失敗して工場のラインに影響が出たら困る」――。製造業・工場系の情シス担当者から、このような相談をよくいただきます。

保守ベンダー変更は、確かにリスクのある取り組みです。しかし、正しい手順を踏み、注意点を押さえれば、リスクをコントロールしながら進めることができます。本記事では、製造業・工場システムの保守ベンダー変更を成功させるための7ステップと、各ステップで気をつけるべきポイントを、現場の視点から具体的に解説します。

想定読者

本記事は、次のような方を対象に書いています。

• 工場の基幹システム・生産管理システムの保守を現ベンダーに任せているが、対応品質やコストに課題を感じている情シス担当者
• 保守ベンダーの変更を検討しているが、どこから始めれば良いか分からない方
• ベンダー変更のリスクを最小限に抑えながら、計画的に進めたい方
• 社内の経営層・事業部門への説明に悩んでいる方

---

保守ベンダー変更を検討する背景と「変更の軸」を決める

なぜ変更を検討するのか、まず言語化する

保守ベンダーの変更を考え始めたとき、最初にやるべきことは「なぜ変えたいのか」を具体的に言語化することです。「なんとなく不満」のままでは、新ベンダーを選んでも同じ不満が繰り返される可能性があります。

よくある変更理由を整理しておきます。

• 対応スピードへの不満：問い合わせの返答が3〜5営業日かかる、小さな改修でも見積もりに2週間、実装に2ヶ月かかる
• コストの問題：保守料が年々上がっており、相場と比較して割高感がある。改修のたびに追加費用が発生する
• 担当者の頻繁な交代：担当が変わるたびに1から説明する必要があり、引き継ぎがされていない
• 技術力・将来性の不安：レガシー技術しか対応できず、クラウドやAPI連携の相談ができない。担当者が高齢化している
• ブラックボックス化：仕様書や設計書を渡してもらっておらず、現ベンダー以外には触れない状態になっている

どれが「変更の主な理由」かを整理し、次の新ベンダー選定の「評価軸」として使います。

変更しない選択肢も検討する

変更前に、現ベンダーとの交渉や改善の余地がないかも確認しましょう。担当変更の依頼、SLA（対応時間・復旧目標）の再設定、料金の見直し交渉などで解決できるケースもあります。交渉の結果として「変更する」と判断した場合、その記録を社内の稟議資料にも使えます。

対象システムの現状棚卸し

変更対象の範囲を明確にする

「保守ベンダーを変更する」といっても、対象は1システムだけのこともあれば、複数のシステムが絡み合っている場合もあります。まず現在何を保守してもらっているかを一覧にします。

棚卸しで整理すべき項目：

• システム一覧：基幹システム、生産管理、受発注、在庫管理、帳票、連携バッチ など
• 技術スタック：言語（Java/COBOL/RPG）、DB（Oracle/SQL Server）、OS・サーバー構成
• 現行の保守範囲：障害対応のみ？改修も含む？24時間対応？
• 契約内容：保守料、改修の費用体系、契約期間・解約条件
• ドキュメント状況：要件定義書・設計書・ソースコードは自社で保有しているか
• 他システムとの接続：連携先（販売管理/会計/工場設備等）とその仕様書

この棚卸しで「ドキュメントが自社になく、現ベンダーが全部持っている」と判明するケースは少なくありません。その場合は後述の手順を丁寧に進める必要があります。

変更の優先順位を決める

製造業では、基幹システムの切替は生産に直結するリスクを伴います。一括切替が難しい場合は、影響が小さい周辺システムから順番に切り替える段階的アプローチが有効です。

• 第1フェーズ：帳票や連携バッチなど、止まっても業務でカバーできるもの
• 第2フェーズ：在庫管理・受発注など、影響はあるが対応可能なもの
• 第3フェーズ：生産計画・原価管理など、止まると即座に生産に影響するコアシステム

方針と切替スケジュールの策定

一括切替 vs 段階的切替

切替の方式には大きく2つあります。

一括切替：全システムを特定の日に新ベンダーへ移管する方式。短期間で完了するが、万が一のトラブル時のリスクが大きい。

段階的切替：システムの優先度や影響度に応じて順番に移管する方式。リスクを分散できるが、切替期間が長くなり、管理コストが増える。

製造業の工場システムでは、段階的切替を基本とし、コアシステムは最後に慎重に移管するのが現実的です。

スケジュールの組み方：製造業特有の制約

工場には「切替できない時期」が存在します。スケジュールを立てる際は、以下を必ず確認してください。

• 棚卸時期（年2回程度）：在庫管理・基幹システムに高負荷がかかる期間
• 繁忙期（業種ごとに異なる）：生産計画の変更が頻繁に発生し、システムへの影響が大きい
• 期末・年度末（3月・9月など）：会計・原価系の処理が集中する
• 工場の定期メンテ期間：一部システムを止められる数少ないタイミング。切替に活用できる可能性あり

目安のスケジュール感：

• 小規模システム（帳票・連携）：棚卸し〜選定〜切替まで半年〜8ヶ月
• 中規模システム（在庫・受発注）：8ヶ月〜1年2ヶ月
• 基幹システム（生産計画・原価）：1年〜2年

「早くて3ヶ月」という提案をするベンダーには要注意です。引き継ぎの品質が犠牲になりやすく、切替後のトラブルにつながります。

新ベンダーの選定

選定の進め方

1. 候補リストの作成（自社のネットワーク、紹介、Webサーチ等）
2. 要件整理と問い合わせ（技術スタック対応、製造業経験、引き継ぎ姿勢など）
3. ヒアリング・提案書の取得（2〜4社程度）
4. 評価・スコアリング・選定

製造業の保守ベンダーに求める要件

一般的な評価軸（技術力・コスト・実績）に加えて、製造業では以下の確認が重要です。

• 「工場の止まらない前提」が共有できるか：障害対応の稼働時間、緊急時のエスカレーション体制
• レガシー技術への対応力：COBOL、AS/400/RPG、既存パッケージへの知見
• 引き継ぎの具体的な提案があるか：「引き継ぎはお任せください」では不十分。何をいつ受け取り、いつから保守責任が移るかを説明できるベンダーを選ぶ
• 改修リードタイムの実績：「小さな改修で平均〇週間」などの数字で確認する

契約と引き継ぎ計画の策定

現ベンダーとの契約確認

変更を決断する前に、現在の契約書で以下を確認します。

• 解約条件と解約予告期間：「3ヶ月前予告」「期末のみ解約可」など、条件はベンダーにより様々
• ソースコード・設計書の著作権と引き渡し条件：自社発注でも「納品物に含まれない」という契約になっているケースがある
• 引き継ぎ協力の義務の有無：引き渡し義務が明記されていない場合は、追加契約・覚書で合意を取る

引き継ぎ計画書の作成

新ベンダーと合意したうえで、現ベンダー・新ベンダー・自社（情シス）三者の役割とスケジュールを文書化します。

引き継ぎ計画書に含める項目：

• 引き継ぎ対象の一覧（ドキュメント、ソース、環境、ナレッジ）
• 各アイテムの引き渡し期日と担当者（現ベンダー側・受け取る側）
• 説明会・キックオフのスケジュール
• 並行稼働期間の設定（新ベンダーが問い合わせ対応を開始しつつ、現ベンダーにも確認できる期間）
• 受入完了の定義と確認方法

引き継ぎの実行

引き継ぎで渡すもの

最低限そろえたいアイテムは次の4カテゴリです。

ドキュメント類：要件定義書、基本設計書、画面/帳票一覧、DB定義書、バッチ仕様書、インターフェース仕様書（他システムとの連携仕様）

ソースコード・設定：アプリケーションのソースコード（バージョン管理リポジトリごと）、DBスクリプト、設定ファイル、リリース手順書

運用・保守の知見：よくある問い合わせのQ&A、過去の障害事例と対処内容、カスタマイズの背景・理由（「なぜこの実装にしたか」）、月次・年次の定期作業一覧

環境情報：本番・検証環境の構成図（サーバー、NW）、他システムとの接続先一覧とアカウント情報、ID・権限の管理体制

ドキュメントがない場合の対処

長年の運用でドキュメントが失われていることは珍しくありません。その場合は：

1. 現ベンダーへのヒアリング記録を残す（口頭で説明してもらいメモ・議事録化）
2. 画面・帳票・バッチの一覧を自社で作成する（動いているものを一から整理）
3. 「暗黙知」を書き出す（よくある問い合わせ、過去のトラブル対処を箇条書きでよいので記録）

完璧なドキュメントでなくてよいです。新ベンダーが「システムの概要をつかめる」レベルを目標にします。

---

ここまで読んで「自社の保守ベンダー変更、どこから相談すれば良いかわからない」と感じていたら、まずは現状のヒアリングからお気軽にお問い合わせください。

切替と安定稼働の確認

切替タイミングの選び方

本番切替は、リスクが最も高いフェーズです。製造業での切替成功率を上げるポイント：

• 棚卸・繁忙期・期末を避ける（前述のとおり）
• 切替リハーサル（モックカットオーバー）を行う：検証環境で切替手順を一通り実施し、問題がないかを確認する
• ロールバック計画を用意する：万が一のトラブル時に「元の状態に戻す」手順を事前に整備しておく
• 切替当日は両ベンダーを連絡可能な状態に：現ベンダーが即日で質問に答えられる体制を確保する

切替後の安定稼働期間

切替直後は、新ベンダーへの問い合わせが集中しやすく、初期対応の品質が問われます。最低でも1〜3ヶ月の安定稼働確認期間を設け、次の点をモニタリングします：

• 問い合わせ対応のレスポンスタイム
• 小改修の見積もりと納期の精度
• 切替後の障害発生件数と復旧時間
• 現場（キーユーザー）からの満足度フィードバック

よくある失敗事例と回避策

失敗1：引き継ぎのドキュメントが不十分なまま切替

状況：「現ベンダーが協力的でなく、ソースと口頭説明だけで切り替えた」
影響：切替後に障害が発生した際、新ベンダーが原因を特定できず復旧に数日かかった
回避策：引き継ぎ完了の定義を事前に決め（「主要機能の説明会完了」「受入テスト合格」等）、それを満たすまで切替しない

失敗2：スケジュールが繁忙期と重なった

状況：「年度末の切替を強行した結果、引き継ぎ期間が圧縮された」
影響：現場からの問い合わせが殺到したが、新ベンダーが対応できず現場が混乱した
回避策：スケジュール策定の段階で工場・経営カレンダーを必ず確認し、切替候補日を複数設定しておく

失敗3：社内合意なしに進め、変更後に責任問題

状況：「情シスだけで決定し、事業部門に事後報告した」
影響：変更後の初期不具合発生時に「なぜ変えたのか」という責任追及を受けた
回避策：早期から経営・事業部門を巻き込み、変更理由・手順・リスク対策を共有して承認を取る

よくある質問

Q. 現行ベンダーが引き継ぎに協力してくれない場合はどうすればよいですか？

A. まず契約書を確認し、ソースコードや設計書の引き渡し義務が記載されているかを確認します。義務がない場合でも、引き継ぎ作業に対する報酬や謝礼を提示し、追加契約・覚書を結ぶことで協力を引き出せることが多いです。それでも協力が得られない場合は、自社でリバースエンジニアリング（ソースコードや動作から仕様を復元する）を新ベンダーに依頼する方法もあります。

Q. 保守ベンダー変更にかかる費用の目安を教えてください。

A. 費用は対象システムの規模や引き継ぎ状態によって大きく異なります。引き継ぎ支援費用（現ベンダーへの謝礼含む）、新ベンダーの初期費用（キックオフ・体制構築）、受入テスト・並行稼働期間のコストなどが主な項目です。数十万円〜数百万円の範囲になることが多く、事前に見積もりを取ることをお勧めします。

Q. 変更後に新ベンダーが期待通りでなかった場合はどうしますか？

A. 契約前にSLA（対応時間・復旧目標）を明文化しておき、未達の場合のペナルティや協議条件を契約書に含めておくことが大切です。また、再度の変更を防ぐため、選定時に「引き継ぎのしやすさ」「ドキュメント整備の義務」を契約条件として定めておくと安心です。

Q. AS/400（IBM i）など、レガシー技術に精通したベンダーはどう探せばよいですか？

A. システム開発会社の中でも「製造業特化」「レガシーシステム刷新」を明示しているところを中心に選定します。実績について、同業種・同規模の事例を複数提示できるか確認することが重要です。また、ベンダー選定時のRFPに技術スタックを明記し、対応可否を書面で回答してもらう方法も有効です。

システムの保守・運用を任せられる体制をお探しでしたら、システム保守・運用でご相談を承っています。

まとめ

保守ベンダー変更の7ステップを振り返ります。

1. 変更の軸を言語化する（何が課題で、どうなれば良いか）
2. 現状棚卸し（対象システム、契約、ドキュメント、連携）
3. 方針・スケジュール策定（段階的か一括か、繁忙期を避けた計画）
4. 新ベンダー選定（技術力・引き継ぎ姿勢・コストのバランス）
5. 契約と引き継ぎ計画の策定（三者の役割と期日を文書化）
6. 引き継ぎの実行（ドキュメント・ソース・知識・環境の移転）
7. 切替と安定稼働確認（切替リハーサル、安定稼働モニタリング）

手順を丁寧に踏むことで、「止めてはいけない」工場システムでも、リスクをコントロールして保守ベンダー変更を進めることができます。

c3index に相談する

シースリーインデックスは、製造業のお客様の基幹システム保守・運用を専門に支援しています。現行ベンダーからの引き継ぎ支援、保守体制のセカンドオピニオン、変更プロジェクトの進め方のご相談など、幅広く対応しています。

「まず現状をヒアリングしてほしい」「どのベンダーが向いているか一緒に整理したい」という段階からでも構いません。お気軽にお問い合わせください。