古い基幹システムの刷新と、購買業務の見直しの順番

刷新が「現行どおり」で失敗する理由

経済産業省がまとめた「DXの現在地とレガシーシステム脱却に向けて」（レガシーシステムモダン化委員会総括レポート、2025 年 5 月 28 日）は、企業が先送りにしている既存システムの保守切れ対応や移行のタイミングで、各所で問題が続発していると書いている^[1]。同じレポートは、2024 年 12 月から 2025 年 2 月に行ったアンケートで、ユーザー企業の 61％がレガシーシステムを保有し、中小企業よりも大企業の保有率が高いとしている^[1]。

レポートがレガシーシステムの要因として挙げるのは、技術の老朽化、システムの肥大化・複雑化、ブラックボックス化といった技術面と、IT 投資がされていないこと、古い制度としがらみといった経営面である^[1]。後者の説明には「昔ながらの古い業務プロセスや制度に縛られている」「現行システムを変えることへの現場の根強い抵抗感」が並ぶ^[1]。システムの問題として始まった刷新が、実際には業務の問題になる理由がここにある。

情報処理推進機構（IPA）の「システム再構築を成功に導くユーザガイド 第 2 版」は、再構築では「現行踏襲」という要求が発生することが多いが、その「現行」が何かについてユーザ企業とベンダ企業の間でギャップが生じうると指摘している^[2]。ユーザは動いている現行システムがそのまま踏襲されることを期待するが、ベンダは開発のために「現行通り」を仕様にする必要があり、設計書やソースコードを拠り所にする。ドキュメントと実際の動きがずれていれば、誤った「現行通り」になる^[2]。同じガイドは、このギャップがシステム部門と利用部門の間にも生じうるとし、再構築と同時に業務要件を変えると、踏襲した部分と変えた部分の整合をとるのが難しくなると書いている^[2]。

購買業務は、この食い違いが起きやすい領域である。発注書の様式、単価の端数の扱い、承認の経路、締め日、仕入先ごとの例外の運用は、長年の改修の積み重ねでシステムに埋め込まれていることが多く、誰も全体を説明できないことがある。だから、製品を選ぶ前に、購買の側で「何を残し、何を変えるか」を決めておく必要がある。

見直しの順番（全体像）

以下は、上の二つの資料が示す方向に沿って、購買業務に当てはめた実務の提案である。

順番 1：業務と作り込みを棚卸しする

IPA のガイドは、要員の交代などで業務知識が断片化し、業務要件上本当に必要な機能かを誰も把握していない状態になりうると書いている^[2]。棚卸しは、この状態から抜けるための作業である。

購買で棚卸しする対象は、画面や帳票の一覧ではなく、業務の流れと、その中の例外である。見積依頼から発注、納期の確認、受入・検収、請求との照合、支払までを並べ、それぞれで「誰が・何を見て・何を決めるか」を書く。そのうえで、標準の流れから外れる処理を拾う。特定の仕入先だけ単価の端数を切り上げている、特定の品目だけ承認が一段多い、月末だけ締めの扱いが違う、といったものである。

拾った例外の一つずつについて、「なぜそうしているか」を書く。理由が今も生きているもの、理由が分からないもの、理由がすでに消えているものに分かれる。後ろの二つは、次の順番で「変えてよい側」に入る候補になる。

同時に、現行システムに施されている作り込み（アドオン）の一覧を情報システム部門から出してもらう。総括レポートは、現行システムにカスタマイズを施している企業は移行先でもカスタマイズを施す割合が高いと報告している^[1]。何を作り込んでいるかを知らないまま移行先を決めると、同じ量の作り込みが新しいシステムにも移る。

順番 2：法令で変えられない出力と、社内の慣習を分ける

棚卸しした項目を、法令や契約で決まっているものと、社内で決めているだけのものに分ける。前者は新しいシステムでも必ず満たし、後者は変えてよい。

購買で法令が決めている代表は、取適法の対象取引の発注で明示する事項と、取引の記録である。公正取引委員会・中小企業庁の取適法テキストは、委託事業者は製造委託等をした場合、記録規則で定めるところにより具体的な記録事項を記載または記録した書類または電磁的記録を作成し、2 年間保存しなければならないと説明している^[3]。同じテキストは、単価表を別に交付する場合には有効である期間を明示する必要があるとも書いている^[3]。新しいシステムが、明示すべき事項を発注書に出せるか、記録すべき事項を残せるか、単価に有効期間を持たせられるかは、製品を選ぶ前に確かめる項目になる。明示事項の一覧は発注書の 4 条明示 12 項目で扱っている。

電子帳簿保存法の検索の要件も、移行の計画に効く。国税庁の一問一答によれば、過去の電子データを旧システムで検索できる状態に保っていれば、新しく使い始めたシステムの側で検索できなくても差し支えない（問 24）^[4]。過去のデータをすべて新しいシステムに移すかどうかは、この扱いを踏まえて決められる。どのデータを移し、どれを旧システムに残すかの具体的な決め方は受発注システムへのデータ移行にまとめてあるので、この記事では繰り返さない。

一方、発注書の見た目、承認の段数、締め日、単価の端数処理の多くは社内の決めごとである。ここを「現行どおり」の対象から外せるかどうかで、作り込みの量が大きく変わる。承認の段数をどう決めるかは承認は何段必要かで扱っている。

順番 3：標準に寄せる部分と、作り込む部分を決める

総括レポートは、標準化対応の大原則として、DX の阻害要因となる現行機能保証や現行踏襲の拘りは捨て、あるべき業務の姿から検討するとし、移行先のシステムを標準的な仕様に寄せる部分と、付加価値を作り込む部分とに明確に分けることが重要だと書いている^[1]。同じ箇所は、中堅・中小企業はオーダーメイドのスクラッチ開発を避け、パッケージや SaaS を原則とすべきだとし、Fit&Gap 分析で大きなギャップがある業務は、業務の複雑さや特殊性に応じて最小限のカスタマイズで済むアプローチを検討すべきだとしている^[1]。

レポートはさらに、現場に標準化の検討を丸投げすると現行機能保証や現行踏襲の問題が残り足枷となる可能性があるため、情報システムと事業を統括する双方の経営層が検討のプロセスに関与することが重要だと書く^[1]。購買部門だけで「この例外は残す」と決めていくと、例外がほとんど残る。順番 1 で書いた「理由」をもとに、経営層の前で一つずつ判断する場を作る。

IPA のガイドも、パッケージ製品の機能を使った作り込みやアドオン開発の規模が膨大になると、作り直しと大差なくなってしまうとして、作り込みが膨張しすぎないように制御することを求めている^[2]。開発の途中で「現行通りにするための追加開発」の要求が出たときは、プロジェクト関係者だけで判断せず、意思決定のプロセスを使って経営層の参画を促し、方針を変えて追加開発をするならその決定の記録を残すことも必要だとしている^[2]。

購買で作り込む価値があるのは、自社の調達の強みに直結する部分に限られる。たとえば、特殊な品目の仕様管理や、自社独自の評価に基づく発注先の選び方である。単価表の持ち方、承認、照合のような共通の業務は、標準に寄せるほうが保守も楽になる。システムの型の比べ方は購買管理システムの比べ方、要望を要件に書き直す方法は購買部門の要望を選定に使える要件に書き直すで扱っている。

順番 4：取引先への影響と切替の時期を決める

購買のシステムは、社内だけで閉じていない。発注書の様式、送り方（紙・FAX・メール・データ）、納期回答の受け取り方、請求書の受け取り方が変われば、仕入先の作業も変わる。総括レポートも、受発注などでつながるサプライチェーンでは、中小企業を含む取引先の DX やレガシーシステム脱却の遅れが、ゆくゆくはサプライチェーン全体に影響しうると書いている^[1]。

切替の前に、仕入先ごとに「何が変わるか」を一覧にし、変わる点を事前に知らせる。発注書の番号の体系が変わるなら、仕入先の請求書や納品書に書かれる番号も変わる。仕入先が独自の受注システムに番号を取り込んでいるなら、その設定も変える必要がある。請求をデータで受け取る仕組みに切り替えるなら、刷新と同じ計画の中で決めたほうがよい（デジタルインボイス（Peppol）と受発注・請求の電子化）。

切替の時期は、締めと決算から逆算する。月の途中や決算の直前に切り替えると、旧と新の両方に記録がまたがり、照合と監査が難しくなる。発注残（発注済みで未納入のもの）を旧で最後まで流すか、新に移すかも、この時点で決める。

順番 5：変更を記録し、統制の範囲を確かめる

上場会社では、財務報告に係る内部統制の中で、IT に係る全般統制が評価される。金融庁の実施基準は、全般統制の具体例として「システムの開発、保守に係る管理」を挙げ、システムの開発または変更に際しては、既存のシステムと整合性を保っていることを十分に検討するとともに、開発・変更の過程等の記録を適切に保存することが重要だと書いている^[5]。また、リスクが発生または変化しうる状況の例として「情報システムの重要な変更」を挙げている^[5]。

購買の刷新では、順番 2 と 3 で決めたこと、つまり「何を残し、何を変え、なぜそう決めたか」がそのまま変更の記録になる。棚卸しの表に判断と理由を書き足していけば、後から監査や引き継ぎで問われたときに説明がつく。IPA のガイドが求める、方針を変えて追加開発をしたときの決定の記録^[2]も、同じ表に残すとよい。上場会社でない場合も、税務や取適法の記録を残す仕組みが変わることに違いはないので、同じ考え方で記録を残す。

実務で起きやすい失敗

製品を先に決めてしまう。製品の提案を受けてから業務を当てはめると、合わない部分がすべて作り込みの要求になる。順番 1〜3 を終えてから選定に入れば、比べる軸が自社の業務になる。

「全部現行どおり」で要件をまとめる。IPA のガイドが指摘するとおり、「現行」の中身が人によって違うので^[2]、この書き方では要件にならない。何を現行どおりにするかを、項目ごとに書く。

業務の見直しとシステムの移行を同時に大きく変える。IPA のガイドは、再構築と同時に業務要件を変えると、踏襲した部分と変えた部分の整合をとるのが難しくなり、品質保証の難易度が上がるとしている^[2]。変えるものは、順番 3 で絞った範囲にとどめる。

取引先への連絡が切替の直前になる。仕入先にも準備の時間が要る。様式や番号が変わることは、少なくとも 1〜2 回の締めの前に伝える。

よくある質問

業務の見直しを先にやると、刷新が遅れないか

棚卸しと判断にかかる時間は増える。ただし、総括レポートは大規模システムのモダン化は数年計画に及び、着手後に問題化や停滞で計画が見直されるとさらに長期間を要するとしている^[1]。後で計画が崩れるより、前で時間を使うほうが全体は短くなりやすい。

購買だけ先に別のシステムに移してよいか

できる。ただし会計や生産管理とのつなぎ方が新たに必要になる。考え方は購買システムと会計・生産管理のつなぎ方を参照してほしい。

旧システムの過去の記録は、いつまで残せばよいか

取適法の対象取引の記録は 2 年間の保存が必要である^[3]。税法上の帳簿書類の保存期間は別に定められているので、どの記録を何年残すかは経理と決める。旧システムで検索できる状態を保つ方法もある^[4]。

取引先のセキュリティも刷新のときに見直すべきか

取引先とデータでつながる範囲が広がるなら、見直す機会になる。仕入先に求めるセキュリティの水準をどう決めるかはサプライチェーンのセキュリティ対策評価制度と、仕入先への求め方で扱っている。

まとめ

古い基幹システムの刷新は、多くの企業が抱える課題で^[1]、つまずく理由の多くは「現行どおり」の中身が定まらないことにある^[2]。購買業務は、業務と作り込みの棚卸し、法令で変えられない出力^[3][4]と社内の慣習の切り分け、標準に寄せる部分と作り込む部分の判断^[1]、取引先への影響と切替の時期、変更の記録^[5]、の順で見直す。製品を選ぶのはその後にする。判断と理由を一つの表に残していけば、それがそのまま要件の根拠と変更の記録になる。

出典・参考資料

1. DXの現在地とレガシーシステム脱却に向けて レガシーシステムモダン化委員会総括レポート（経済産業省 商務情報政策局 情報産業課 情報処理基盤産業室／2025 年 5 月 28 日）
2. システム再構築を成功に導くユーザガイド 第 2 版〜ユーザとベンダで共有する再構築のリスクと対策〜（独立行政法人情報処理推進機構（IPA）ソフトウェア高信頼化センター／2018 年 2 月）
3. 中小受託取引適正化法テキスト「下請法」から「取適法」へ（公正取引委員会・中小企業庁／令和 7 年 11 月）
4. 電子帳簿保存法一問一答【電子取引関係】（国税庁／令和 7 年 6 月）
5. 財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準（金融庁 企業会計審議会／令和 5 年 4 月 7 日改訂）

WHITE PAPER

この記事の理解を深める
無料ホワイトペーパーをプレゼント

製造業の現場で使える実務資料（PDF）を無料でお届けします。"こんな資料が届きます" ↓ 下のボタンからどうぞ。

🔒 全文は無料ダウンロードで