既存システム改修・リプレイスを外注する時の選び方（引継ぎと移行の方法）

既存システムの改修・リプレイスで「外注先選び」が難しい理由

既存システムの改修（いまの仕組みを直しながら使い続ける）やリプレイス（作り替えて入れ替える）を外注する場面で、多くの企業がつまずくのは、開発そのものより「引継ぎ」と「移行（データ・業務・運用の切り替え）」が見えにくいことです。新規開発なら要件を決めて作れば前に進みますが、既存システムには「過去の経緯」「例外処理」「担当者しか知らない運用」が積み重なっています。外注先から見ると、仕様書がなくても動いている以上“正解が複数ある”状態になりがちです。

特に情シスや経営層が「予算は確保できるが、技術の細部までは追えない」場合、外注先の提案が正しいか判断しづらく、価格や知名度だけで決めてしまいがちです。しかし既存システムの案件は、途中で発覚する未知の仕様がコストや納期に直撃します。つまり外注先の価値は、実装力だけでなく、調査・引継ぎ・移行を計画し、リスクを先に潰す力に表れます。

この記事では、非エンジニアでも判断できるように、外注先選びの観点を「引継ぎ」「移行」の観点から整理し、契約・体制・手順に落とし込んで説明します。結論としては、見積の安さよりも「調査の進め方」「移行リハーサル」「切り戻し（戻せる設計）」を明確に提示できる会社が、結果的に安く・早く・安全です。

• 改修かリプレイスか迷っている（現場の不満はあるが、何が最適かわからない）
• 前のベンダーと関係が悪く、引継ぎが不安
• データ移行・業務切替で止まるのが怖い
• クラウド化やセキュリティ対応も一緒にやりたい

改修かリプレイスか：外注前に決めるべき判断軸

外注先を探す前に、「改修」か「リプレイス」かの方向性をある程度固めると、提案の比較がしやすくなります。ここで重要なのは、技術の流行ではなく、業務の止められなさ・将来の拡張・保守のしやすさです。

改修が向くケース

• 現行の画面・帳票・業務フローを大きく変えられない
• 一部の機能だけが課題（例：検索が遅い、特定の帳票だけ手作業が多い）
• 基盤はまだ保守可能で、障害が致命的ではない

改修は「止めずに直す」メリットがありますが、既存の設計の癖を引きずります。たとえば“その場しのぎの追加”が積み重なったシステムは、改修するほど複雑になり、将来のコストが上がることがあります。外注先には、改修の範囲を狭く見積もるのではなく、改修によって増える複雑さ（技術的負債）も含めて説明できることが求められます。

リプレイスが向くケース

• サーバーOSやミドルウェアがサポート切れ、セキュリティ上の不安が大きい
• 仕様追加を繰り返して、改修のたびに障害が出る
• 事業や業務が変わり、現行システムの前提が合っていない

リプレイスは「作り直す」分、移行が大仕事になります。データ移行だけでなく、操作教育、社内手順、権限、外部連携（会計・在庫・メール等）の切替まで含みます。だからこそ、リプレイス案件の外注先は、移行を含めて成功させるPM（進行管理）と設計力があるかで決まります。

迷う場合は、いきなり大規模発注にせず、短期間の「現状調査（アセスメント）」を先に外注するのが安全です。調査の成果物（現行の構成、課題、移行難易度、概算）を得てから本契約に進むと、比較も交渉も格段にしやすくなります。

外注先の選び方：技術より「引継ぎ・移行」に強いかで見抜く

既存システム案件で失敗が起きるのは、相手の技術が低いからだけではありません。むしろ「引継ぎの設計」と「移行の段取り」を軽く見積もった結果、後半で炎上することが多いです。非エンジニアでも評価しやすい観点を、質問例とセットで整理します。

引継ぎの進め方を“工程”として説明できるか

良い外注先は、引継ぎを「前任者から資料をもらう」程度ではなく、システムの理解を獲得するための作業計画として提示します。具体的には次のような内容が出てくるか確認しましょう。

• 現行の構成把握（サーバー、クラウド、ネットワーク、利用サービス、契約）
• ソースコード・設定・バッチ（定期処理）・ジョブの棚卸し
• データ構造（テーブル、主キー、マスタの意味）の把握
• 外部連携（API、CSV取込、SFTP、メール送信）の一覧化
• 運用手順（誰が、いつ、何を、どの画面で）の可視化

質問例：「引継ぎ期間に何を成果物として残しますか？」「現行のブラックボックスをどう解消しますか？」。ここで“担当者が頑張ります”ではなく、一覧表や図（構成図、データフロー、運用フロー）に落としてくる会社は信頼できます。

移行を「データ移行」だけでなく「業務移行」として捉えているか

移行というとデータの移し替えを想像しがちですが、実務では「業務の切替」が本体です。たとえば、締め処理のタイミング、承認ルート、権限設定、帳票の配布先などが変わると現場は混乱します。外注先が業務移行の観点（教育・手順・権限・並行稼働）を語れるかが重要です。

質問例：「切替当日の体制は？」「現場が慣れるまでの運用フォローは？」「旧システムと並行稼働は可能？」。ここに答えがない提案は、後で社内負担が爆発しやすいです。

“切り戻し”と“段階移行”の選択肢を持っているか

本番切替は、理想通りにいかない前提で設計すべきです。良い外注先は、切替方式（ビッグバンか段階か）と切り戻し（戻す手順）を必ずセットで検討します。

• ビッグバン：ある日を境に新システムへ全面切替（短期だがリスク集中）
• 段階移行：機能や部門ごとに順次切替（時間はかかるがリスク分散）
• 並行稼働：一定期間、旧新を併用して照合（コストは増えるが安全）

質問例：「切り戻しの判断基準は誰が持ちますか？」「切り戻すために旧側のデータはどう保全しますか？」。ここを曖昧にする会社は、切替当日に“気合い”で乗り切ろうとしがちです。

引継ぎを成功させる実務：資料がなくても回る「見える化」の作り方

現実には、仕様書が最新でない、ソースが古い、担当者が退職している、といった状況が珍しくありません。だからこそ外注の引継ぎは、「資料がない前提」で設計する必要があります。ここでは、外注先と一緒に進める引継ぎの実務を、成果物ベースで紹介します。成果物が定義されるほど、見積のブレとトラブルが減ります。

最低限そろえたい引継ぎ成果物（非エンジニアでも確認可能）

• システム全体図（何のためのシステムで、どことつながっているか）
• 機能一覧（現場用語と画面・帳票の対応がわかる）
• 運用カレンダー（毎日/毎月/締め日にやる作業、担当、所要時間）
• 障害・問い合わせの履歴（よくあるトラブルと対処）
• 権限・アカウント設計（誰が何をできるか）
• データ項目一覧（マスタの意味、コード体系、必須項目）

これらは「分厚い仕様書」ではなく、更新可能な形（スプレッドシートやWiki）で整えるのが現実的です。外注先に「ドキュメント作成は別料金」と言われることもありますが、既存システム案件ではドキュメントがないこと自体がリスクなので、最初から範囲に入れて交渉すべきです。

アクセス・権限・契約情報の引継ぎで詰まらないために

技術的な引継ぎ以前に、クラウドの管理画面に入れない、ドメインの契約者が前任者、メール配信サービスの請求が個人カード、といった“事務的な穴”で止まることがあります。情シスや総務が押さえるべきポイントは次の通りです。

• クラウド（AWS/Azure/GCP等）の管理者アカウントと請求先
• ドメイン/SSL証明書/DNSの契約者と更新手順
• ソースコード管理（Git等）の権限とバックアップ
• 監視・ログ（障害時に何を見るか）
• 外部SaaS（決済、メール、チャット、BI等）の契約とAPIキー

外注先には、これらを棚卸しするチェックリストを提示してもらうと良いです。「技術」ではなく「運用の入口」を握ることで、引継ぎの遅延を大幅に減らせます。

前ベンダーと揉めている場合の現実的な進め方

関係が悪化している場合でも、感情論で切ると引継ぎが破綻します。現実的には、次の優先順位で“最低限の引継ぎ”を確保します。

1. 資産（ソース、設定、データ、手順、契約）の引渡し範囲を文書で明確化
2. 管理者権限・パスワードの回収（可能なら第三者立会いで変更）
3. 質問窓口と回答期限の合意（スポットで有償にするのも可）
4. 並行期間の障害対応の切り分け（どこまで旧ベンダーが見るか）

外注先には、前ベンダーへの質問リストを作ってもらい、やりとりを議事録化する運用がおすすめです。「言った・言わない」を防ぐだけで、移行の成功確率は上がります。

移行の方法：データ移行・業務切替・テストを「リハーサル」する

移行は本番当日が勝負ではなく、事前のリハーサルでほぼ決まります。データ移行のやり方を外注先に丸投げすると、現場が求める粒度（どの帳票のどの項目が一致すべきか）が抜け落ちがちです。ここでは、移行を実務として管理するための要点をまとめます。

データ移行の基本パターンと注意点

• 一括移行：切替前に全データを移す（整合性を取りやすいが停止時間が長くなる）
• 差分移行：事前に大部分を移し、直前に差分だけ反映（停止時間を短縮）
• 段階移行：対象データを部門・拠点・期間で分けて移す（照合が複雑になりやすい）

注意点は「文字コード」「タイムゾーン」「小数・丸め」「コード体系」「重複データ」「削除扱い」など、地味なところで破綻することです。外注先には、移行ルール（例：旧の“空欄”は新ではNULLか0か、無効データはどうするか）を明文化してもらいましょう。ルールが文章になっていない移行は、再現できず、やり直しが効きません。

移行テストで必ずやるべき「照合」と「受入基準」

移行が正しいかどうかは、単にレコード数が合っただけでは判断できません。業務上の正しさ（売上合計、在庫残、請求残）で確認する必要があります。おすすめは次の三層チェックです。

1. 技術照合：件数、必須項目欠損、外部キーの整合
2. 業務照合：主要KPIの合計値、締め処理結果、帳票の金額一致
3. 現場確認：代表ユーザーが実際の操作で違和感を洗い出す

ここで重要なのは、受入基準を事前に決めることです。たとえば「主要帳票10種の金額一致」「締め処理が旧と同じ時間内で完了」「検索結果の並びが業務上問題ない」など。外注先が受入基準づくりを支援できると、社内合意がスムーズになります。

切替当日の運用：体制表とタイムテーブルが品質を決める

切替当日に必要なのは、技術力よりも段取りです。外注先に求めたいのは、次のような「当日台本」です。

• 切替タイムテーブル（何時に何を止め、何を確認し、いつ公開するか）
• 担当者と連絡手段（誰が判断し、誰が作業し、誰が現場対応するか）
• 判定ポイント（この時点でNGなら切り戻す、などの基準）
• 障害時の一次対応フロー（ログ採取、影響範囲、暫定対応）

情シスが全部を仕切る必要はありませんが、「意思決定者（切り戻し判断）」だけは社内で明確にしておくと混乱を防げます。外注先には、判断材料を即時に提示できる監視・ログ設計まで含めて依頼すると安心です。

契約・見積・体制で失敗を防ぐ：非エンジニア向けチェックリスト

既存システムの改修・リプレイスは、やってみないと分からない部分が残ります。だからこそ、契約と体制で“ブレ”を吸収できるようにしておく必要があります。見積が固定でも、範囲が曖昧なら後で追加費用になります。ここでは、発注側が押さえるべきポイントを具体化します。

見積の内訳に「調査・引継ぎ・移行」が明示されているか

見積書が「開発一式」になっている場合、後から揉めやすいです。最低でも以下が分かれているか確認します。

• 現状調査（アセスメント）
• 要件定義（業務要件・非機能要件：性能/セキュリティ/運用）
• 設計・実装・テスト
• 移行設計・移行ツール作成・移行リハーサル
• 切替支援・並行稼働支援
• 運用保守（監視、障害対応、改善）

「移行は別途」「引継ぎは協力いただければ」など曖昧な表現は、リスクが発注側に寄っているサインです。逆に、外注先が「不確実性があるので、調査フェーズを先に切り出しましょう」と言ってくる場合、誠実な可能性が高いです。

契約形態の使い分け：一括請負と準委任

日本の開発契約は大きく分けて「請負（成果物完成責任）」と「準委任（作業提供）」があります。既存システム案件では、フェーズで使い分けるのが現実的です。

• 調査・要件定義：準委任（不確実性が高く、成果物の範囲を柔軟に）
• 実装・移行ツール作成：請負または準委任（範囲の明確さで決定）
• 運用保守：準委任（継続的改善や障害対応）

重要なのは、どちらが良い悪いではなく、不確実性の高い領域を無理に請負で固定しないことです。固定すると、外注先はリスク回避で調査を浅くしたり、変更を渋ったりして、品質が落ちることがあります。

体制の見極め：担当者の経験と権限を確認する

提案資料が良くても、実際に動くのが経験の浅いメンバーだと、引継ぎ・移行で詰まります。次を確認しましょう。

• PM（進行管理）の実績：既存システムの移行経験があるか
• アーキテクト/リードエンジニア：設計を判断できる人が誰か
• 移行担当：データ移行の設計・照合を主導できるか
• 連絡体制：平日夜間・切替休日の対応可否

面談では「想定外が出たとき、誰がどう判断しますか？」と聞くのが有効です。ここで曖昧なら、炎上時に判断が遅れます。“人”の解像度を上げることが、最強のリスク対策です。

まとめ

既存システムの改修・リプレイスを外注するとき、成功の鍵は技術スタックの華やかさではなく、引継ぎと移行を「工程として設計」できる外注先を選ぶことです。特に非エンジニアの発注側が押さえるべきは、(1)改修かリプレイスかの判断軸を持つ、(2)引継ぎ成果物を定義してブラックボックスを減らす、(3)移行をリハーサルして受入基準を合意する、(4)契約と体制で不確実性を吸収する、の4点です。

外注先の比較では、見積金額だけでなく、「引継ぎの進め方を説明できるか」「切り戻し・段階移行の選択肢があるか」「移行照合と受入基準を作れるか」を質問してみてください。そこで具体的な成果物や手順が返ってくる会社は、現場の痛みを分かっている可能性が高いです。