基幹システムを刷新するとき、最初の関門は「今のシステムが何をしているか」を正確に把握することである。長く使われたシステムは、当初の設計から少しずつ機能が足され、連携先が増え、誰も全体像を把握していない状態になりやすい。この状態のまま刷新を進めると、移し忘れや想定外の連携が後から見つかり、計画が崩れる。
本記事は、刷新の前に行う現行システムの棚卸しと可視化を、発注者の視点で整理する。読者として想定しているのは、中小企業の経営者、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では、基幹システムの機能・データ・連携・依存関係を整理し、何を残し何をやめるかを切り分けるところからご支援します。設計書が残っていない場合でも、現状を読み解きながら、刷新の規模と難所を一緒に可視化します。
※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。
参考情報
- 制度、価格、仕様、脆弱性、法務、セキュリティに関する判断は、公開時点の公式情報と一次情報を確認したうえで更新してください。
