基幹システムを刷新するとき、最初の難所になりやすいのが「今のシステムが何をしているのか分からない」という状態である。長年使ってきたシステムほど、開発した会社や、当時の担当者の頭の中にしか仕様が残っていないことが多い。仕様書が古いまま放置されていたり、改修の経緯が記録されていなかったりすると、新しいシステムに何を引き継げばよいのかが見えなくなる。
本記事は、既存ベンダーや属人化したシステムから新システムへ引き継ぐ際に確認しておきたい項目を、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、DX担当、情シス担当、事業責任者である。専門的な技術判断は開発会社に任せてよいが、「何が引き継げて、何が引き継げないのか」を発注者が把握しておくことが、刷新を止めないための鍵になる。
結論：引き継げる情報を早めに棚卸しし、不足は前提として織り込む
既存ベンダーや属人化システムからの引き継ぎで、GXOが重視するのは次の3点である。
- 仕様書・ソース・データ定義など、引き継げる情報を早い段階で棚卸しする
- 引き継げない部分は「現行システムの挙動から読み解く作業」が必要だと前提に置く
- 既存ベンダーの協力が必要な範囲を明確にし、関与の取り決めを早めに行う
引き継ぎ情報が揃っていないことは珍しくない。問題は情報がないことそのものより、情報がないと分からないまま見積や計画を立ててしまうことである。早めに棚卸しをして「何が分からないか」を把握できれば、その分の調査を計画に織り込める。現行システムの全体像を把握する考え方は基幹システム刷新の進め方｜現状システムの棚卸しでも扱っている。
MANUFACTURING DX
Excel限界から受発注システムへ、同規模の概算は？
中小製造業の概算費用・導入期間・役割分担マトリクスをその場で確認。要件整理テンプレも無料提供します。
なぜ引き継ぎでつまずくのか
長く使われた基幹システムには、引き継ぎを難しくする事情が積み重なっている。稼働してから何年も改修を重ねるうちに、当初の設計と実態がずれ、誰も全体を把握していない状態に陥りやすい。発注前にこうした背景を理解しておくと、計画に無理が生じにくい。
- 仕様が文書に残っていない：稼働後の改修が記録されず、現行の挙動が唯一の仕様になっている。
- 知識が特定の人に偏っている：開発当時の担当者や、特定のベンダーしか中身を知らない。
- ソースが読み解きにくい：古い言語や独自の作りで、第三者が短時間では把握できない。
- 改修の経緯が分からない：なぜその処理があるのかが不明で、削ってよいか判断できない。
これらは、どれか一つではなく複数が重なっていることが多い。引き継ぎは「資料を受け取って終わり」ではなく、「現行システムを読み解く作業」を含むものだと捉えておきたい。
引き継げる情報を棚卸しする
引き継ぎの第一歩は、今あるものを並べて「何が引き継げて、何が足りないか」を見える化することである。
横にスクロールして確認できます
| 引き継ぎ対象 | 確認したいこと | 不足しやすい点 |
|---|---|---|
| 仕様書・設計書 | 最新の状態を反映しているか | 改修が反映されていない |
| ソースコード | 入手・閲覧できるか | 第三者が読み解けるか |
| データ定義 | 項目の意味・関係が分かるか | 命名が独自で意味が不明 |
| 改修履歴 | 変更の経緯が追えるか | 記録自体が残っていない |
| 運用手順 | 日次・月次の作業が分かるか | 担当者の頭の中にある |
この表を埋めていくと、引き継ぎの「穴」が見えてくる。穴の部分は、現行システムの挙動を調べたり、関係者へのヒアリングで補ったりする作業が必要になる。その作業量を見積に織り込むことが、後の追加費用を防ぐことにつながる。
ベンダーロックインと既存ベンダーの協力
現行システムを特定のベンダーに依存している場合、刷新には既存ベンダーの協力が欠かせない。協力の範囲と条件を、早めに整理しておきたい。
ソース・仕様の開示
現行システムのソースや仕様を開示してもらえるかは、刷新の前提を左右する。契約上、開示の取り決めがあるかを確認する。開示が難しい場合は、現行システムの挙動から仕様を読み解く前提で計画を立てる必要がある。
移行期間中の関与
既存ベンダーには、移行が完了するまで現行システムの保守や、新システム側からの問い合わせ対応で関与してもらう場面が出てくる。どこまで協力してもらえるか、その費用はどう扱うかを、早い段階で取り決めておきたい。引き継ぎを前提とした契約の考え方は、新システムでロックインを繰り返さないためにも重要である。
競合関係への配慮
新システムを別の会社が開発する場合、既存ベンダーが協力に慎重になることもある。発注者が間に入り、移行が円滑に進むよう関係を調整する役割を担うことになる。
属人化を新システムに持ち込まない
引き継ぎは、現行の属人化をそのまま新システムへ運び込む作業ではない。むしろ、属人化を解きほぐす機会である。
- 暗黙の運用を文書にする：担当者が経験で行ってきた手順を、引き継ぎの過程で書き出す。
- 理由の分からない処理を確認する：「昔からこうしている」処理は、本当に必要かを業務側に確認する。
- 新システムでは記録を残す前提にする：改修や運用の記録を残す仕組みを最初から組み込む。
属人化を持ち込まない設計にしておくと、刷新後に同じ問題を繰り返さずに済む。移行を機に、運用の知識を組織に残す形へ切り替えたい。新旧の引き継ぎ方針は、刷新後の運用体制とも関わるため、基幹システム刷新の進め方｜移行後の運用保守と内製化の論点と合わせて考えておきたい。
現行システムの挙動から仕様を読み解く
引き継ぎ資料が揃わない場合、現行システムの挙動そのものが仕様の手がかりになる。資料がないことを前提に、どう読み解くかを段取りしておきたい。
- 入力と出力を観察する：どんなデータを入れると何が出るかを記録し、処理の中身を推測する。
- 画面と帳票を起点にする：現場が使う画面や出力帳票から、必要な機能を逆算する。
- 過去データを参照する：蓄積されたデータの形から、項目の意味や関係を読み取る。
- 現場の運用に聞く：システムが何をしているかは、日々使う現場が一番知っていることが多い。
読み解きは時間のかかる作業であり、その分の工数を計画に織り込む必要がある。読み解いた内容は、そのまま新システムの仕様書の素材になる。引き継ぎの過程で得た理解を文書として残しておくと、刷新後の運用や次の改修にも生きてくる。現行システムの全体像を整理する作業は、移行方式の判断にもつながる。
引き継ぎでよくある失敗
引き継ぎでは、次のような失敗が起きやすい。いずれも発注前に方針を決めておけば避けられる。
- 資料があると思い込む：仕様書がある前提で計画を立て、実際は古くて使えなかった。
- 既存ベンダーの協力を後回しにする：協力の取り決めをせずに進め、肝心な場面で情報が得られない。
- 読み解き作業を見積に入れない：現行システムの調査工数を見込まず、途中で費用が膨らむ。
- 属人化をそのまま移す：現行の暗黙運用を新システムに持ち込み、刷新後も同じ人に依存し続ける。
これらは、引き継ぎを「資料の受け渡し」と捉えると起きやすい。読み解きと文書化を含む作業だと位置づけることで、計画の精度が上がる。
相談前に整理しておくとよい情報
引き継ぎについて開発会社に相談する前に、手元の状況を整理しておくと、話が具体的に進みやすい。専門的な内容まで把握する必要はなく、何があって何がないかが分かれば十分である。
- 現行システムを開発・保守しているベンダーと、その契約の状況
- 仕様書や設計書が残っているか、最新の状態を反映しているか
- ソースコードを入手・閲覧できる状態にあるか
- 現行システムの中身を知る担当者が、社内・社外にいるか
- その担当者が異動や退職を控えていないか
これらが整理されていなくても相談は可能である。むしろ「何が分からないか」が見えていること自体が、引き継ぎの計画を立てる出発点になる。情報が不足している前提で、どう調査を進めるかを一緒に組み立てられる。
GXOの見解
システム開発の成否は開発会社選びの前に、業務要件、既存データ、運用責任、段階移行をどこまで整理できるかで決まる。
GXOは見積比較だけでなく、発注前の論点整理とRFP設計が手戻りと追加費用を減らすと見る。
GXOは、業務整理、要件定義、RFP、開発、保守、レガシー刷新まで接続できる形で支援します。
実務判断のポイント
この記事は、経営者、情シス、業務責任者、発注担当向けです。要件定義、RFP作成、見積比較、レガシー刷新、業務システム再構築を自社で進めるか、外部の専門家と整理するかを判断する材料として使えます。
GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。基幹システム刷新の進め方｜既存ベンダー・属人化システムの引き継ぎに関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。
放置した場合と整備した場合の違い
横にスクロールして確認できます
| 観点 | 放置した場合 | 整備した場合 |
|---|---|---|
| 業務影響 | 属人的な判断が増え、対応の優先順位がぶれやすい | 影響範囲、期限、責任者を決めて進められる |
| 投資判断 | ツール導入や外注費だけが先行し、効果測定が曖昧になる | 売上、工数削減、リスク低減の指標にひも付けられる |
| 現場運用 | 例外処理や承認フローが残り、定着しにくい | 権限、ログ、教育、改善サイクルまで設計できる |
| 経営報告 | 問題が発生してから説明資料を作ることになる | 月次で状況、課題、次の打ち手を説明できる |
導入・改善前のチェックリスト
- 対象業務、対象部門、対象データを明文化しているか
- 現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
- 既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
- 例外処理、承認、差し戻し、監査証跡まで確認しているか
- 社内で判断できる範囲と外部支援が必要な範囲を分けているか
- 初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
- 成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
- 実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
- セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
- 既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
- 経営判断に必要な資料を1枚で説明できる状態にしているか
- 次の90日で検証する範囲と、やらない範囲を明確にしているか
GXOの実務補足
システム開発の成否は開発会社選びの前に、業務要件、既存データ、運用責任、段階移行をどこまで整理できるかで決まる。
GXOは見積比較だけでなく、発注前の論点整理とRFP設計が手戻りと追加費用を減らすと見る。
GXOは、業務整理、要件定義、RFP、開発、保守、レガシー刷新まで接続できる形で支援します。記事のテーマを単なる情報収集で終わらせず、相談、診断、要件定義、実装、運用改善に接続することで、要件整理から開発、保守、段階移行ロードマップへ接続。さらに、標準ヒアリングと既存診断を使い、発注前相談から開発案件へ展開。
実行までの進め方
- 現在の業務、データ、ツール、担当者を棚卸しする
- 売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
- 初期対応、90日以内の改善、半年以上の投資を分ける
- 必要な社内体制、外部支援、予算、セキュリティ確認を整理する
- 小さく検証し、効果測定後に本番化や横展開を判断する
よくある質問
Q1. 仕様書がまったく残っていなくても刷新できますか
刷新は可能である。現行システムの挙動やデータを調べて仕様を読み解く作業が増えるため、その分の工数を計画に織り込む必要がある。仕様書がない前提で、調査をどう進めるかを開発会社と相談しておきたい。
Q2. 既存ベンダーが協力してくれるか不安です
協力の範囲と費用を、契約段階で取り決めておくのが確実である。協力が得にくい場合でも、現行システムの挙動から読み解く前提で進められるが、その分の負荷は増える。発注者が間に立って調整する役割が重要になる。
Q3. 現行システムの担当者が退職予定です。先に何をすべきですか
担当者がいるうちに、暗黙の運用や改修の経緯をヒアリングして文書に残しておきたい。日次・月次の作業手順、判断の理由、過去のトラブル対応などは、本人がいなくなると再現が難しい。引き継ぎ用の聞き取りを早めに行うことを勧める。
既存システムの引き継ぎから、刷新の進め方を一緒に整理しませんか
GXOでは、仕様書のない属人化した基幹システムでも、現行の挙動やデータを調査し、引き継げる情報の棚卸しから新システムへの移行までをご支援します。既存ベンダーとの調整を含め、現実的な進め方を整理します。
※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。
参考情報
- 制度、価格、仕様、脆弱性、法務、セキュリティに関する判断は、公開時点の公式情報と一次情報を確認したうえで更新してください。
