基幹システムを刷新するとき、最初の難所になりやすいのが「今のシステムが何をしているのか分からない」という状態である。長年使ってきたシステムほど、開発した会社や、当時の担当者の頭の中にしか仕様が残っていないことが多い。仕様書が古いまま放置されていたり、改修の経緯が記録されていなかったりすると、新しいシステムに何を引き継げばよいのかが見えなくなる。

本記事は、既存ベンダーや属人化したシステムから新システムへ引き継ぐ際に確認しておきたい項目を、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、DX担当、情シス担当、事業責任者である。専門的な技術判断は開発会社に任せてよいが、「何が引き継げて、何が引き継げないのか」を発注者が把握しておくことが、刷新を止めないための鍵になる。

結論：引き継げる情報を早めに棚卸しし、不足は前提として織り込む

既存ベンダーや属人化システムからの引き継ぎで、GXOが重視するのは次の3点である。

  • 仕様書・ソース・データ定義など、引き継げる情報を早い段階で棚卸しする
  • 引き継げない部分は「現行システムの挙動から読み解く作業」が必要だと前提に置く
  • 既存ベンダーの協力が必要な範囲を明確にし、関与の取り決めを早めに行う

引き継ぎ情報が揃っていないことは珍しくない。問題は情報がないことそのものより、情報がないと分からないまま見積や計画を立ててしまうことである。早めに棚卸しをして「何が分からないか」を把握できれば、その分の調査を計画に織り込める。現行システムの全体像を把握する考え方は基幹システム刷新の進め方｜現状システムの棚卸しでも扱っている。

なぜ引き継ぎでつまずくのか

長く使われた基幹システムには、引き継ぎを難しくする事情が積み重なっている。稼働してから何年も改修を重ねるうちに、当初の設計と実態がずれ、誰も全体を把握していない状態に陥りやすい。発注前にこうした背景を理解しておくと、計画に無理が生じにくい。

  • 仕様が文書に残っていない：稼働後の改修が記録されず、現行の挙動が唯一の仕様になっている。
  • 知識が特定の人に偏っている：開発当時の担当者や、特定のベンダーしか中身を知らない。
  • ソースが読み解きにくい：古い言語や独自の作りで、第三者が短時間では把握できない。
  • 改修の経緯が分からない：なぜその処理があるのかが不明で、削ってよいか判断できない。

これらは、どれか一つではなく複数が重なっていることが多い。引き継ぎは「資料を受け取って終わり」ではなく、「現行システムを読み解く作業」を含むものだと捉えておきたい。

引き継げる情報を棚卸しする

引き継ぎの第一歩は、今あるものを並べて「何が引き継げて、何が足りないか」を見える化することである。

引き継ぎ対象確認したいこと不足しやすい点
仕様書・設計書最新の状態を反映しているか改修が反映されていない
ソースコード入手・閲覧できるか第三者が読み解けるか
データ定義項目の意味・関係が分かるか命名が独自で意味が不明
改修履歴変更の経緯が追えるか記録自体が残っていない
運用手順日次・月次の作業が分かるか担当者の頭の中にある

この表を埋めていくと、引き継ぎの「穴」が見えてくる。穴の部分は、現行システムの挙動を調べたり、関係者へのヒアリングで補ったりする作業が必要になる。その作業量を見積に織り込むことが、後の追加費用を防ぐことにつながる。

ベンダーロックインと既存ベンダーの協力

現行システムを特定のベンダーに依存している場合、刷新には既存ベンダーの協力が欠かせない。協力の範囲と条件を、早めに整理しておきたい。

ソース・仕様の開示

現行システムのソースや仕様を開示してもらえるかは、刷新の前提を左右する。契約上、開示の取り決めがあるかを確認する。開示が難しい場合は、現行システムの挙動から仕様を読み解く前提で計画を立てる必要がある。

移行期間中の関与

既存ベンダーには、移行が完了するまで現行システムの保守や、新システム側からの問い合わせ対応で関与してもらう場面が出てくる。どこまで協力してもらえるか、その費用はどう扱うかを、早い段階で取り決めておきたい。引き継ぎを前提とした契約の考え方は、新システムでロックインを繰り返さないためにも重要である。

競合関係への配慮

新システムを別の会社が開発する場合、既存ベンダーが協力に慎重になることもある。発注者が間に入り、移行が円滑に進むよう関係を調整する役割を担うことになる。

属人化を新システムに持ち込まない

引き継ぎは、現行の属人化をそのまま新システムへ運び込む作業ではない。むしろ、属人化を解きほぐす機会である。

  • 暗黙の運用を文書にする：担当者が経験で行ってきた手順を、引き継ぎの過程で書き出す。
  • 理由の分からない処理を確認する：「昔からこうしている」処理は、本当に必要かを業務側に確認する。
  • 新システムでは記録を残す前提にする：改修や運用の記録を残す仕組みを最初から組み込む。

属人化を持ち込まない設計にしておくと、刷新後に同じ問題を繰り返さずに済む。移行を機に、運用の知識を組織に残す形へ切り替えたい。新旧の引き継ぎ方針は、刷新後の運用体制とも関わるため、基幹システム刷新の進め方｜移行後の運用保守と内製化の論点と合わせて考えておきたい。

現行システムの挙動から仕様を読み解く

引き継ぎ資料が揃わない場合、現行システムの挙動そのものが仕様の手がかりになる。資料がないことを前提に、どう読み解くかを段取りしておきたい。

  • 入力と出力を観察する：どんなデータを入れると何が出るかを記録し、処理の中身を推測する。
  • 画面と帳票を起点にする：現場が使う画面や出力帳票から、必要な機能を逆算する。
  • 過去データを参照する：蓄積されたデータの形から、項目の意味や関係を読み取る。
  • 現場の運用に聞く：システムが何をしているかは、日々使う現場が一番知っていることが多い。

読み解きは時間のかかる作業であり、その分の工数を計画に織り込む必要がある。読み解いた内容は、そのまま新システムの仕様書の素材になる。引き継ぎの過程で得た理解を文書として残しておくと、刷新後の運用や次の改修にも生きてくる。現行システムの全体像を整理する作業は、移行方式の判断にもつながる。

引き継ぎでよくある失敗

引き継ぎでは、次のような失敗が起きやすい。いずれも発注前に方針を決めておけば避けられる。

  • 資料があると思い込む：仕様書がある前提で計画を立て、実際は古くて使えなかった。
  • 既存ベンダーの協力を後回しにする：協力の取り決めをせずに進め、肝心な場面で情報が得られない。
  • 読み解き作業を見積に入れない：現行システムの調査工数を見込まず、途中で費用が膨らむ。
  • 属人化をそのまま移す：現行の暗黙運用を新システムに持ち込み、刷新後も同じ人に依存し続ける。

これらは、引き継ぎを「資料の受け渡し」と捉えると起きやすい。読み解きと文書化を含む作業だと位置づけることで、計画の精度が上がる。

相談前に整理しておくとよい情報

引き継ぎについて開発会社に相談する前に、手元の状況を整理しておくと、話が具体的に進みやすい。専門的な内容まで把握する必要はなく、何があって何がないかが分かれば十分である。

  • 現行システムを開発・保守しているベンダーと、その契約の状況
  • 仕様書や設計書が残っているか、最新の状態を反映しているか
  • ソースコードを入手・閲覧できる状態にあるか
  • 現行システムの中身を知る担当者が、社内・社外にいるか
  • その担当者が異動や退職を控えていないか

これらが整理されていなくても相談は可能である。むしろ「何が分からないか」が見えていること自体が、引き継ぎの計画を立てる出発点になる。情報が不足している前提で、どう調査を進めるかを一緒に組み立てられる。

よくある質問

Q1. 仕様書がまったく残っていなくても刷新できますか

刷新は可能である。現行システムの挙動やデータを調べて仕様を読み解く作業が増えるため、その分の工数を計画に織り込む必要がある。仕様書がない前提で、調査をどう進めるかを開発会社と相談しておきたい。

Q2. 既存ベンダーが協力してくれるか不安です

協力の範囲と費用を、契約段階で取り決めておくのが確実である。協力が得にくい場合でも、現行システムの挙動から読み解く前提で進められるが、その分の負荷は増える。発注者が間に立って調整する役割が重要になる。

Q3. 現行システムの担当者が退職予定です。先に何をすべきですか

担当者がいるうちに、暗黙の運用や改修の経緯をヒアリングして文書に残しておきたい。日次・月次の作業手順、判断の理由、過去のトラブル対応などは、本人がいなくなると再現が難しい。引き継ぎ用の聞き取りを早めに行うことを勧める。

既存システムの引き継ぎから、刷新の進め方を一緒に整理しませんか

GXOでは、仕様書のない属人化した基幹システムでも、現行の挙動やデータを調査し、引き継げる情報の棚卸しから新システムへの移行までをご支援します。既存ベンダーとの調整を含め、現実的な進め方を整理します。

基幹システム刷新の相談をする

※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。