基幹システムを刷新するとき、最初の関門は「今のシステムが何をしているか」を正確に把握することである。長く使われたシステムは、当初の設計から少しずつ機能が足され、連携先が増え、誰も全体像を把握していない状態になりやすい。この状態のまま刷新を進めると、移し忘れや想定外の連携が後から見つかり、計画が崩れる。

本記事は、刷新の前に行う現行システムの棚卸しと可視化を、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、DX担当、情シス担当、事業責任者である。技術的な調査はベンダーに任せる部分も多いが、何を把握すべきかの枠組みを発注者が持っておくと、調査の精度も判断の質も上がる。

結論：移すもの・やめるものを決めるために棚卸しする

棚卸しの目的は、現行をそのまま記録することではなく、「刷新後に何を残し、何をやめるか」を判断できる材料を作ることである。GXOが現状把握で重視するのは、次の3点である。

  • 機能・データ・連携・依存を、漏れなく一覧にする
  • 実際に使われている機能と、使われていない機能を切り分ける
  • 把握できていない部分（ブラックボックス）を、隠さず洗い出す

棚卸しをきちんとやると、刷新の規模が見えてくる。逆に、棚卸しを省くと、見積もりも計画も「やってみないと分からない」状態のまま進むことになる。

何を棚卸しするのか

棚卸しの対象は、システムが持つ機能だけではない。データや連携、依存関係まで含めて初めて、全体像が見える。

棚卸しの対象把握する内容見落とすと起きること
機能どんな業務処理を担っているか移行後に必要な機能が抜ける
データどんなデータを、どれだけ保持しているか移行設計が立てられない
外部連携他システムやサービスと何をやり取りしているか刷新後に連携が切れる
依存関係どの基盤・ライブラリ・機器に依存しているか刷新範囲を見誤る
利用状況誰が、どの機能を、どれだけ使っているか不要な機能まで作り込む

これらを一覧にすると、システムの「広さ」と「深さ」が見えてくる。一覧化は地味な作業だが、ここを丁寧にやるほど、後の判断が楽になる。

特に見落とされやすいのが、外部連携と依存関係である。基幹システムは単独で動いているように見えても、実際には別のシステムやサービスとデータをやり取りしていることが多い。たとえば、会計システムへの自動連携、外部の倉庫管理サービスとの在庫連携、取引先とのデータ交換などである。これらは普段は意識されないため、棚卸しのときに抜けやすい。だが、刷新後にこの連携が切れると、表面上は新システムが動いていても、業務の一部が止まってしまう。「このシステムは、どこと、何を、いつやり取りしているか」を一つずつ確認しておくことが、後のトラブルを防ぐ。

使われている機能と使われていない機能を分ける

長く使われたシステムには、過去に作られたが今は使われていない機能が残っていることが多い。これをそのまま刷新後に作り込むと、不要なものに費用と時間をかけることになる。

  • 実際の利用状況を確認する：機能ごとに、どれだけ使われているかを把握する。
  • 使われていない機能を見極める：残す価値があるか、現場に確認しながら判断する。
  • 業務側に意図を聞く：使われていないように見えても、特定の時期だけ必要、という機能もある。

刷新は、現行を丸ごと作り直す機会ではなく、業務を見直す機会でもある。使われていない機能を整理するだけで、刷新の規模を抑えられることは少なくない。何を残すかの判断は、刷新方式の選定にも直結する。

ここで気をつけたいのは、「使われていない」と「不要」は同じではないという点である。日々は使われていなくても、決算期や年に一度の特定の業務でだけ動く機能、あるいは法令対応のために残してある機能もある。利用状況のデータだけで判断すると、こうした機能を見落として削ってしまい、いざ必要になったときに困ることがある。だからこそ、利用状況の確認と、業務側への意図のヒアリングは両輪で行う。データが示す「使われていない」を、業務の知識で裏取りする、という進め方が安全である。

ブラックボックスを洗い出す

棚卸しで最も注意したいのが、誰も中身を把握していない部分、いわゆるブラックボックスである。ここを見落とすと、刷新の途中で「動いていたものが動かなくなった」という事態を招く。

  • 設計書がなく、動作を仕様から追えない処理
  • 特定の担当者やベンダーしか分からない処理
  • いつ、なぜ作られたのか経緯が失われた機能

ブラックボックスは、「分からない」と認めることから対処が始まる。隠したり後回しにしたりせず、棚卸しの段階で「ここは把握できていない」と明示しておくことが大切である。把握できていない部分が多いほど、刷新の不確実性は高くなるため、見積もりや計画にもその前提を反映させたい。属人化の背景は刷新を判断するタイミングでも扱っている。

ブラックボックスへの向き合い方として、すべてを完全に解明してから刷新に進む必要はない、という点も知っておきたい。把握できていない部分があると分かっていれば、その部分は慎重に扱い、移行のときにリハーサルで重点的に確かめる、といった対処ができる。問題なのは、ブラックボックスの存在を把握しないまま進めることである。「分からない部分がある」と認識しておくだけで、計画の立て方も、リスクへの備え方も変わる。棚卸しの目的の一つは、この「分からない部分」を見える化することにある。

データの棚卸しは特に丁寧に

機能と並んで重要なのが、データの棚卸しである。データは刷新後の業務にそのまま引き継がれるため、量も種類も品質も把握しておく必要がある。

  • どんなデータがあるか：マスタ、取引履歴、ログなど、種類ごとに整理する。
  • どれだけあるか：量を把握しないと、移行にかかる手間が見積もれない。
  • 品質はどうか：重複や欠損、表記ゆれなど、そのまま移すと支障が出るものはないか。

データの状態は、移行の難しさを大きく左右する。品質が悪いまま移行すると、刷新後に問題が表面化する。データ移行そのものの進め方はデータ移行の進め方とリスクで詳しく扱う。

データの棚卸しでもう一つ把握しておきたいのが、データの「つながり」である。基幹システムのデータは、単独で存在するのではなく、互いに関係し合っている。たとえば、注文のデータは顧客や商品のデータとひも付いており、このつながりが業務の意味を支えている。棚卸しの段階で、どのデータがどのデータと関係しているかを大まかに把握しておくと、移行設計のときに「このつながりをどう保つか」という検討がしやすくなる。データの種類と量だけでなく、関係性まで見ておくことが、後の移行を楽にする。

棚卸しのチェックリスト

  • システムが担う機能を一覧にしたか
  • 各機能の利用状況（使われているか）を把握したか
  • 保持しているデータの種類と量を整理したか
  • データの品質（重複・欠損・表記ゆれ）を確認したか
  • 外部システムやサービスとの連携を洗い出したか
  • 依存している基盤・ライブラリ・機器を把握したか
  • 把握できていない部分（ブラックボックス）を明示したか
  • 業務側に、機能やデータの意図を確認したか

棚卸しが一通りできれば、刷新の規模と難所がかなり見えてくる。

よくある質問

Q1. 棚卸しは社内でやるべきですか、ベンダーに任せるべきですか

両方の役割がある。機能や連携の技術的な調査はベンダーが得意だが、「なぜこの機能があるか」「実際に使っているか」は業務側でないと分からない。発注者は業務の意図を、ベンダーは技術的な構造を担う、という役割分担が現実的である。

Q2. 設計書がほとんど残っていませんが、棚卸しできますか

可能である。設計書がない場合は、実際の動作や画面、データから現状を読み解く調査を行う。手間はかかるが、刷新を進めるうえで避けて通れない作業であり、ここを省くと後で必ず問題が出る。

Q3. 棚卸しにはどのくらいの精度が必要ですか

刷新の判断に必要な範囲で十分である。すべてを完璧に文書化する必要はなく、「移すもの・やめるもの・把握できていないもの」を切り分けられれば、刷新の検討は前に進められる。

現行システムの棚卸しから、刷新の準備を始めませんか

GXOでは、基幹システムの機能・データ・連携・依存関係を整理し、何を残し何をやめるかを切り分けるところからご支援します。設計書が残っていない場合でも、現状を読み解きながら、刷新の規模と難所を一緒に可視化します。

現行システムの棚卸しを相談する

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