システムリプレイスとは？進め方と判断基準、移行方式・費用の見方

拠点ごとに書式の違う Excel。担当者本人しか中身を触れないマクロ。保守の担当者が減り、ちょっとした画面の変更にも見積もりが数週間かかる基幹システム。「そろそろシステムをリプレイスしないと」——そう考え始めたとき、多くの企業が最初に手をつけるのは、製品やベンダーの比較検討です。

しかし、リプレイスがうまくいかない原因は、選んだ製品の良し悪しより手前にあることが少なくありません。そもそも作り直す必要があるのか、何を共通化し何を残すのかを決めないまま、システムの形だけを先に決めてしまうことです。順番が逆なのです。

この記事では、リプレイスとは何かという定義から、改修で足りるか・作り直すか・パッケージかの判断、失敗パターン、進め方と移行方式、見積もりと費用の見方までを順に整理します。

例として取り上げるのは、製造業(6工場・従業員約300名)の基幹業務統合プロジェクトです。置き換えの対象は、工場ごとの Excel 運用でした。42 あった拠点別の業務ロジックを 8 の共通定義に集約し、月次集計にかかる日数を4日から1.3日へ、入力工数を月140時間から40時間へ削減しました。体制は PdM(プロダクトマネージャー)1名 + エンジニア1名、期間は10ヶ月。特に、業務ロジックの洗い出しと共通化で実際に何をしたのかを具体で書きます。古い基幹システム特有の論点(データ移行や「今と同じ」の扱いなど)は、公的なガイドに基づいて解説します。

※本記事で扱う実績値は、衣株式会社(koromo)の受託開発事業(現・株式会社隼)における支援実績です。再構築の手法や移行の注意点は、独立行政法人情報処理推進機構(IPA)の「システム再構築を成功に導くユーザガイド 第2版」(2018年2月発行)と照合しています。

この記事の要点

• リプレイスは目的ではなく手段。困りごとが一部の機能や連携に限られるなら、改修・機能追加で足りることが多い
• 作り直すかパッケージにするかは、業務の中核を製品の標準に合わせられるかで決まる。その判断の前に「何を共通化するか」を決める
• 失敗の多くは製品選定の誤りではなく、「今と同じで」という曖昧な要求と、共通化の範囲を決めない設計から起きる
• 移行は一括・段階・並行稼働の組み合わせで設計する。並行稼働は無駄ではなく保険だが、終了条件を先に決めなければ終われなくなる
• 見積もりは総額より内訳を見る。現行の調査、データ移行、新旧の突き合わせ、引き継ぎが入っていない見積もりは、後から膨らむ

状況別の読み分け早見表

検討の段階によって、先に読むべき章が変わります。

当てはまる状況	次に読むところ
リプレイスという言葉や、改修・移行との違いから整理したい	「システムリプレイスとは」の章
困りごとはあるが、作り直すほどなのか分からない	「リプレイスすべきか」の章と、既存システムに機能を追加するだけで済むケース
作り直すことは決めたが、何から始めるか分からない	「作り直す前に」の章と、5つのステップ
切り替えで業務を止めたくない	「システム移行の方式」の章
見積もりを取る前、または取った見積もりを比べたい	「費用と見積もりの見方」の章と、5つの質問

システムリプレイスとは — 改修・移行・刷新との違い

システムリプレイスとは、今動いている業務システムを、新しいシステムに置き換えることです。「リプレース」とも書きます。機器や基盤(サーバー・OS・ミドルウェア)だけの入れ替えから、業務のやり方ごと作り直すものまで、範囲には幅があります。

似た言葉が多く、社内で話がかみ合わない原因にもなるので、この記事での使い分けを先に揃えておきます。

言葉	意味	典型的な例
改修・機能追加	今のシステムを使い続けながら、一部を直す・足す	帳票を1つ追加する、他システムとCSVやAPIで連携する
リプレイス	今のシステムを新しいシステムに置き換える	老朽化した基幹システムを、新しく作ったシステムやパッケージに入れ替える
システム移行	旧システムから新システムへ、業務とデータを切り替える作業	データの移し替え、切り替え日の設計、新旧の並行稼働
刷新・再構築	リプレイスとほぼ同義。業務の見直しまで含めて語られることが多い	拠点ごとの業務ルールを共通化しながら作り直す

つまり、リプレイスは「何に置き換えるか」の判断、システム移行は「どう切り替えるか」の作業です。この記事では両方を扱います。

リプレイスの中にも、どこまで作り直すかでいくつかの型があります。IPA のユーザガイドは、現行システムのどの部分を変えるかで再構築の手法を4つに分けています。

手法	業務の仕様	基盤	開発言語	向いている状況
ハードウェア更改	変えない	変えない	変えない	機器の更新が主な目的(OS 等の更新に伴う軽微な修正を含む)
リホスト	変えない	変える	変えない	業務はそのままで、動かす環境だけ移したい
リライト	変えない	変える	変える	業務はそのままで、古い言語から書き換えたい
リビルド	変える	変える	どちらでも	業務のやり方ごと見直して作り直したい

出典: 業務の仕様・基盤・開発言語の3列は、IPA「システム再構築を成功に導くユーザガイド 第2版」 2.4節の再構築手法選択の基本パターンによる。「向いている状況」の列は、それをもとにした当社の整理。同ガイドは、これとは別に「パッケージ製品の利用」を再構築の方向性の一つとして扱っています。

同ガイドは、リビルドは保守性や業務の柔軟性を高められる一方で、費用と業務に詳しい人の関与がより多く求められ、リホスト・リライトは現行の資産を活かして業務の再現性を高められる一方で、保守性や柔軟性は現行と同等にとどまる、と整理しています。ここから言えるのは、業務の仕様を変えるかどうかが、手法と費用を大きく分けるということです。拠点ごとに Excel で回っている業務を共通化したい、というケースは、業務の仕様を変えることになるため、リビルドかパッケージの領域に入ると考えるのが自然です。

リプレイスすべきか — 改修で足りるか、作り直すか、パッケージか

「リプレイスするか」を最初の問いにすると、答えはほぼ必ず「する」になります。検討を始めた時点で、今のシステムへの不満が溜まっているからです。先に確かめるべきなのは、不満の原因がどこにあり、どこまで手を入れれば解消するのかです。

リプレイスを検討し始めるサイン

次のような状態が重なってきたら、リプレイスを検討に入れる時期です。

• 基盤(サーバー・OS・ミドルウェア)の保守期限が近い
• ソースコードや設計書が手元になく、改修のたびに想定外の不具合が出る
• 保守できる担当者が減り、小さな変更にも見積もりや対応に時間がかかる
• 拠点・部門ごとの Excel が増え、全社の数字を集めるのに日数がかかる

これらは「作り直す」合図ではなく「検討を始める」合図です。改修で足りるかどうかは、次の3つの問いで確かめます。

改修か、作り直すか、パッケージかを3つの問いで分ける

判断は、次の3つの問いを順に当てていくと整理しやすくなります。

1. 困りごとが一部の機能・画面・連携に限られ、今のシステムを直せる状態にあるか。 はいなら、まず改修・機能追加を検討する
2. 業務のやり方は変えず、基盤や言語だけを新しくすれば足りるか。 はいなら、基盤の入れ替え(リホスト・リライト等)を検討する
3. 業務の中核を、製品の標準的なやり方に合わせられるか。 はいならパッケージ・クラウドサービス、いいえなら業務に合わせて作り直す

冒頭の製造業の案件に当てはめてみます。困りごとは、6工場の Excel で原価・在庫・納期回答が属人化し、全社共通の指標が取れないことでした。一部の画面や連携の問題ではないので、1つ目の問いは「いいえ」です。また、拠点ごとに違う原価や納期回答の計算を共通の定義に揃えたい、という目的そのものが業務の仕様を変えることなので、2つ目の問いも「いいえ」になります。このように、拠点ごとの業務ルールを揃えたいという動機のリプレイスは、3つ目の問い、つまり業務の中核を製品の標準に合わせられるかの判断に行き着きます。この3つ目の問いには、拠点ごとの違いを「統一する / 残す / やめる」に仕分けてからでないと答えられません。この案件で最初にシステムを作らず、ヒアリングから始めた理由はここにあります(後の章で詳しく書きます)。

既存システムに機能を追加するだけで済むケース

困りごとが「この帳票が出せない」「会計ソフトに毎月手で転記している」「取引先ごとの単価の例外が入力できない」のように特定できるなら、リプレイスより先に改修・機能追加を検討します。手段は大きく3つです。

手段	向いている状況	事前に確認すること
CSV などのファイル連携	転記の手間を減らしたい。頻度は日次・月次で足りる	出力できる項目と形式、取り込み側の仕様、エラー時に誰が直すか
API 連携	他のシステムと、ほぼリアルタイムにデータをやり取りしたい	今のシステムに API があるか、使う権利と費用、障害時の影響範囲
既存システムへの追加開発	画面・帳票・計算ルールを一部足したい	ソースコードと設計書が手元にあるか、改修できる会社がいるか、テスト環境があるか

判断の分かれ目になるのは、機能の中身よりも今のシステムを直せる状態にあるかです。ソースコードや設計書が手元になく、保守していた会社も仕様を把握していない。改修のたびに想定外の不具合が出る。基盤の保守期限が迫っていて、直しても数年で動かなくなる。こうした状況なら、機能追加に費用をかけるより、リプレイスの検討に進んだほうが合理的です。

逆に、システム自体は安定していて、困りごとが連携や帳票に集中しているなら、リプレイスは過剰投資になり得ます。全体を作り直すと、今は問題なく回っている部分まで作り直しとテストの対象になり、そのぶん費用と期間が増えるからです。

作り直すか、パッケージ・クラウドサービスに乗り換えるか

リプレイスに進むと決めたら、次は置き換え先です。業務に合わせて作る(スクラッチ開発)か、パッケージやクラウドサービスに乗り換えるか。判断の軸は、業務の中核を、製品の標準的なやり方に合わせられるかです。

観点	パッケージ・クラウドサービス	業務に合わせて作り直す
向いている業務	会計・給与・勤怠など、会社による違いが小さい業務	受注・生産・原価など、商習慣や設備の制約で会社ごとの違いが大きい業務
業務のやり方	製品の標準に業務を合わせる前提	業務に合わせてシステムを作る
費用の出方	初期費用を抑えやすい。利用料が継続して発生する	初期の開発費が大きい。改修は自社の判断でできる
注意点	標準に合わない部分をアドオン(独自の追加開発)で埋めると、費用が膨らみ、製品の更新のたびに影響を受ける	要件を決める負担が発注側に残る。引き継ぎを設計しないと、開発会社への依存が残る

IPA のユーザガイドも、パッケージを使う場合は企画・計画の段階で自社業務と製品機能の差を洗い出す「Fit&Gap 分析」を行うよう求めています。分析が不十分なまま進めると、要件定義の段階でカスタマイズやアドオンの規模が膨らみ、期間や費用が超過するケースが多い、と注意を促しています。

ここで見落とされがちなのが、どちらを選ぶにしても、先に「何を共通化するか」が決まっていなければ判断できないという点です。拠点や部門ごとに業務のやり方が違うまま製品を比べると、どの製品にも「うちの拠点のやり方」に合わない部分が出てきます。それがアドオンで埋めるべき正当な違いなのか、この機会にやめてよい惰性なのかを、誰も判断できません。この仕分けについては後の章で詳しく扱います。

「Excel が限界」は、Excel が悪いという意味ではない

リプレイスの検討は「Excel の運用が限界だ」という声から始まることが多いので、進め方に入る前に前提を一つ揃えさせてください。

拠点ごとに Excel が育っているのは、現場が怠けた結果ではありません。むしろ逆です。既存の仕組みでは処理しきれない例外が出てくるたびに、現場の担当者が自分たちで解決策を作ってきた——その積み重ねが、いまの Excel です。

そこには、どの製品カタログにも載っていない、その会社固有の業務知識が詰まっています。「この取引先は納期回答を2営業日前倒しで出す」「この製品ラインだけは歩留まりを別計算する」。こうした判断は、どこかに明文化されているわけではなく、シートの中の数式や、担当者の頭の中にあります。

つまり、リプレイスの本質は「Excel や古いシステムをなくすこと」ではありません。そこに溜まった業務知識を、組織で共有できる形に移し替えることです。

この違いは、言葉遊びではありません。「Excel をなくす」をゴールに置くと、現場は自分たちの仕事を否定されたと受け取ります。すると、ヒアリングで本当のことを話してもらえなくなります。話してもらえなければ、要件は不完全なまま固まります。不完全な要件で作られたシステムは、稼働後に「使えない」と言われ、現場は再び Excel に戻ります。この経路で失敗するプロジェクトは、決して珍しくありません。

システムリプレイスが失敗する4つのパターン

失敗の形はプロジェクトごとに違って見えますが、原因をたどると、よく見られるのは次の4つです。

1. 「今と同じで」を仕様だと思ってしまう

リプレイスでは「機能は今と同じでいい」という要求がよく出ます。一見すると最も手堅い要求ですが、実は最も曖昧な要求です。

IPA のユーザガイドは、この「現行踏襲」に、発注側と開発側の間でずれが生まれやすいと指摘しています。発注側は「今動いているシステム」がそのまま再現されることを期待する。一方、開発側は作るために仕様を文書にする必要があるので、設計書やソースコードに書かれている内容を拠り所にする。長年の改修で設計書とソースコードと実際の動きが食い違っていると、どれを「今」とみなすかで認識がずれ、テストの段階で「前と動きが違う」が多発します。

手当ては、「今と同じ」の中身を早い段階で言葉にすることです。どの画面・帳票・計算を、どの資料を正として再現するのか。どこは今回変えてよいのか。これを決めずに見積もりを取ると、見積もりの前提そのものが揺らぎます。

2. 一括移行で、退路を断ってしまう

全拠点・全機能を決めた日に一斉に切り替える計画は、二重運用のコストがかからず美しく見えます。問題は、想定漏れが一つでもあると、その日に業務が止まることです。基幹システムが扱うのは受注・在庫・原価・請求といった、止まると売上に直結する業務で、切り戻すか、現場が徹夜で手作業を回すかの二択になります。

そして、想定漏れはまず出ると考えるべきです。前章で書いたとおり、業務知識の一部は明文化されていないからです。一括移行は「想定漏れがゼロである」ことに賭ける進め方であり、規模が大きいほど、その賭けは分が悪くなります。

3. 現場のやり方を「間違い」として扱ってしまう

「標準化」を掲げるプロジェクトが陥りやすい失敗です。拠点ごとのやり方の違いを、なくすべき無駄・非効率として扱ってしまう。

もちろん、単なる惰性で残っている違いもあります。しかし、その中には顧客との商習慣や、設備の制約に由来する、正当な違いが混ざっています。前者と後者を区別せずに一律で潰すと、業務が回らなくなります。

そして、区別するには現場に聞くしかありません。「これは無駄ですよね」という前提で聞けば、現場は防御的になります。「なぜこうしているのか教えてください」と聞けば、理由が出てきます。ヒアリングの姿勢そのものが、要件の質を決めます。

4. 要件定義をベンダーに丸投げしてしまう

「うちに詳しい人間がいないので、プロに任せたい」。自然な発想ですが、そのまま丸投げすると、要件は発注側の業務ではなく、受注側が作りやすい形に寄っていきます。

パッケージを選んだ場合は、判断の章で触れた Fit&Gap で見つかった差をアドオンで埋めていくと、費用も納期も膨らみます。逆に、差をすべて「業務側を変える」で処理すると、前項の失敗に直結します。どちらに倒すかは業務の重要度で判断するしかなく、その判断は業務を持っている側——つまり発注側——にしかできません。丸投げできない領域が確実に存在する、という前提でプロジェクトを設計する必要があります。

作り直す前に — 拠点ごとの「暗黙のロジック」を言語化する

失敗の型を押さえたところで、進め方に入ります。冒頭で触れた製造業の案件では、最初にシステムを作りませんでした。最初にやったのは、全拠点のヒアリングです。

なぜロジックは 42 まで増えるのか

このプロジェクトの開始時点で、原価・在庫・納期回答に関する業務ロジックは、6工場合わせて42種類ありました。同じ「原価」という言葉が、工場によって違う計算を指していたわけです。

42 という数字は、異常事態ではありません。ごく自然な経緯の結果です。工場ごとに立ち上げ時期が違い、扱う製品が違い、設備が違う。そこに個別の事情が加わるたび、ローカルな解決策が一つ増える。誰も全体を見ないまま個別事情が積み上がれば、この程度の数にはなります。同じことは、拠点が一つの会社でも、経理・購買といった部門の単位で起こります。

問題は数そのものではなく、42 のうちどれが正当な違いで、どれが単なる惰性なのかを、誰も把握していないことです。この状態でシステム化を始めると、42 をそのまま実装するか(=何も解決しない)、根拠なく一つに統一するか(=業務が回らなくなる)のどちらかになります。

言語化のコツは、「例外」から聞くこと

ヒアリングで「どうやって原価を計算していますか」と聞くと、返ってくるのは教科書的な標準手順です。それは既にマニュアルに書いてあることで、価値のある情報ではありません。

知りたいのは、標準手順から外れるケースです。したがって、聞くべきはこうした質問になります。

• この手順が通用しないのは、どういうときですか
• そのとき、誰が、何を見て判断していますか
• その判断を間違えると、何が起きますか
• この作業を、あなた以外にできる人は何人いますか

最後の質問が特に重要です。答えが「私だけです」なら、そこが属人化のリスクであると同時に、明文化されていない業務知識が眠っている場所でもあります。この聞き取りは、失敗パターンの1つ目で触れた「今と同じ」の中身を言葉にする作業そのものでもあります。

42 を 8 にする — 共通化は多数決ではない

洗い出したロジックは、次の3つに仕分けます。

仕分け	判断基準	扱い
統一する	違いに業務上の根拠がない(担当者の好み・過去の経緯のみ)	共通定義に集約する
残す	顧客との商習慣、設備・製品の制約に由来する正当な違い	共通定義のパラメータとして表現する
やめる	現在は誰も使っていない、目的が失われた手順	移行対象から外す

ここでの肝は、真ん中の「残す」です。正当な違いを、例外処理や拠点別の作り込みとして実装するのではなく、共通のロジックが持つパラメータの違いとして表現し直す。これができると、ロジックの本数は増えずに、拠点の個別事情は満たされます。

冒頭の案件で 42 が 8 になったのは、34 を切り捨てたからではありません。「この工場だけの特殊な計算」だと思われていたものの多くが、実は共通ロジックのパラメータ違いとして整理できたからです。現場のやり方を否定せずに共通の土台へ乗せられたのは、この仕分けを丁寧にやったからでした。

この仕分けは、パッケージを選ぶ場合にも効きます。「残す」に分類された違いが、製品の設定(パラメータ)で表現できるなら、アドオンは要りません。表現できない違いが業務の中核に多く残るなら、作り直す理由がはっきりします。判断の章で見た「作り直すかパッケージか」は、この仕分けの結果を見て初めて、根拠を持って決められます。

この整理は、システム開発ではなく業務設計の仕事です。この工程を飛ばして製品選定から入ると、後工程のすべてが揺らぎます。業務システムの刷新・再構築で私たちが担う範囲も、この工程を起点に組み立てています。

システムリプレイスの進め方 — 5つのステップ

前章までを踏まえて、全体の流れを5ステップに整理します。所要期間は拠点数と業務の複雑さで大きく変わるため、ここでは期間ではなく、順序と各ステップで決めるべきことに絞ります。

ステップ1: 現状ヒアリング

全拠点・全部門の対象業務の担当者に話を聞き、暗黙のロジックを洗い出します。前章の「例外から聞く」を徹底します。

このステップの成果物は、システムの要件定義書ではありません。現状の業務ロジック一覧です。まだ「あるべき姿」は書きません。現状を正確に写し取ることに専念します。あわせて、刷新前の数字(月次集計の日数や入力工数)をこの時点から測り始めます。理由は効果測定の章で書きます。

ステップ2: 共通定義

洗い出したロジックを「統一する / 残す / やめる」に仕分け、共通定義に集約します。前章の表の作業です。改修で足りるか、作り直すか、パッケージかの最終判断も、この結果を見て行います。

ここは発注側の意思決定が最も多く必要になる工程です。仕分けの判断には業務上の責任が伴うため、各拠点の責任者と経営側の合意形成が要ります。このステップに十分な時間を取れるかどうかが、プロジェクト全体の成否を決めます。

ステップ3: 移行の設計

共通定義が固まったら、次は移行の順番と方法を決めます。どの拠点から始めるか、どの業務から切り替えるか、Excel や旧システムとの並走期間をどう設計するか。次章で詳しく扱います。

この段階で、切り戻しの条件と手順も決めておきます。「何が起きたら元に戻すのか」を事前に合意しておくことで、現場は安心して新しいやり方を試せます。

ステップ4: 拠点別リリース

1拠点ずつ、段階的に切り替えます。最初の拠点は、後続すべての雛形になります。ここで見つかった想定漏れを共通定義に反映してから、次の拠点へ進みます。

重要なのは、リリースのたびに立ち止まることです。スケジュールを守るために想定漏れを放置して次へ進むと、その歪みは最後の拠点まで引きずられます。

ステップ5: 定量検証

切り替えた拠点で、効果を数字で確認します。感覚的な「楽になった」ではなく、月次集計の日数や入力工数といった指標で測ります。

この結果は、次の拠点の説得材料にもなります。先に切り替えた拠点で入力の手間がどれだけ減ったかという自社の数字は、どんな説明資料よりも具体的です。

体制は「大きくすれば速くなる」わけではない

基幹システムのリプレイスと聞くと大人数のプロジェクトを想像しがちですが、開発側の人数を増やせば期間が短くなるとは限りません。冒頭の案件も、開発側は2名でした。

この規模で成立したのは、時間の多くが実装ではなく意思決定に使われたからです。ステップ1〜2——現状の言語化と共通定義の仕分け——は、開発側の人数を増やしても速くなりません。むしろ、発注側の意思決定者を確保できているかどうかがボトルネックになります。

発注側で最低限必要なのは、次の役割です。

• 業務の意思決定者 — 「統一する / 残す / やめる」を最終的に判断できる人。拠点間で意見が割れたときに決着をつける権限が要ります
• 各拠点のキーパーソン — ヒアリングに応じ、リリース時に現場を動かせる人。兼務で構いませんが、時間の確保は必要です
• 社内の引き継ぎ担当 — 稼働後にシステムを引き取る人。後述する内製化の章のとおり、終盤ではなく開発中から関与してもらいます

この3つが埋まらないまま外部だけで進めると、先に挙げた「丸投げ」と同じ結果になります。

システム移行の方式 — 一括・段階・並行稼働の選び方

システム移行の方式は、大きく一括移行・段階移行・並行稼働の3つです。どれか一つを選ぶというより、段階移行を基本に、拠点ごとの切り替えで並行稼働を組み合わせるといった形で設計します。

方式	進め方	利点	注意点	向いている状況
一括移行	決めた日に全拠点・全機能を一斉に切り替える	二重運用が要らない。移行期間が短い	想定漏れがあると、その日に全社の業務が止まる	小規模で業務が単純、切り戻しが容易
段階移行	拠点・業務の単位で順に切り替える	問題の影響を先行した範囲にとどめられる。学びを次に活かせる	移行期間中は新旧が混在し、拠点間のデータ連携の設計が要る	拠点や業務の違いが大きい基幹システム
並行稼働	一定期間、新旧の両方で同じ業務を行い、結果を突き合わせる	業務を止めずに、新システムの誤りを見つけられる	現場の入力負担が増える。終わりを決めないと常態化する	数字の正しさが重要な原価・請求・在庫など

※IPA のユーザガイド(3.6節)も、稼働後の障害に備える対策として並行稼働と段階的リリースを挙げています。並行稼働は利用部門がどこまで負担を許容できるか、旧システムの保守期限内に実施できるかを確認すること、段階的リリースは、先行拠点で問題なく動くことを確かめてから残りに広げて影響範囲を限定する方法で、目的に応じて先行する拠点を選ぶこと(規模の違いを確かめたいなら大・中・小の拠点を選ぶ等)が注意点です。

旧システムや Excel と並走する期間を、あえて設計する

段階移行では、新システムと既存の Excel や旧システムが一定期間並走します。この二重運用を「無駄なコスト」と捉えて短縮しようとすると、一括移行に近づき、退路を失います。

並走期間は、無駄ではなく保険です。新システムの出力と旧側の出力を突き合わせられる期間があるからこそ、想定漏れを業務が止まる前に発見できます。設計時に、次を明確にしておきます。

• どちらが正なのか — 並走期間中、判断の根拠にするのはどちらの数字か。曖昧にすると現場が混乱します
• どこまで二重入力するのか — 全項目か、検証に必要な主要項目のみか。現場の負担に直結します
• 誰が突き合わせるのか — 差異が出たときに調査する担当を決めておきます

並走を終わらせる条件を、先に決める

並走期間で最も多い失敗は、終われなくなることです。現場が Excel や旧システムを手放す踏ん切りをつけられず、二重運用が常態化していきます。

これを避けるには、開始時点で終了条件を数値で決めておきます。たとえば「新旧の差異が3ヶ月連続でゼロ件」「主要帳票の出力が直近3期分一致」といった形です。条件を満たしたら旧側を止める、と事前に合意しておけば、判断が感情論になりません。

最初の拠点は「一番大きいところ」ではない

段階移行で最初に切り替える拠点の選び方には、いくつか考え方があります。実務的に機能しやすいのは、次の条件を満たす拠点です。

• 業務の複雑さが平均的であること(最も単純な拠点だと、想定漏れが十分に出ません)
• 現場に協力的なキーパーソンがいること
• 万一止まっても、全社への影響が限定的であること

最も規模が大きく重要な拠点から始めたくなりますが、それは一括移行と同じリスクの取り方です。逆に最も簡単な拠点を選ぶと、共通定義の検証が甘くなり、2拠点目で大量の手戻りが発生します。

データ移行は「全部移す」前提にしない

移行方式と並んで見落とされやすいのが、データの移し替えです。IPA のユーザガイドは、データ移行で問題が起こりやすい観点として、移行する対象の整理、データの形式(レイアウト)の確認、想定外の値を整えるクレンジング、文字コードや外字の扱い、移行方法の選定、移行結果の確認方法の合意を挙げています。

特に効くのが最初の「対象の整理」です。すべての過去データを移そうとすると作業量も費用も増えるため、どこまでの期間・種類のデータを新システムに持っていくかを先に決めます。また、同ガイドは、データ移行の問題は開発の終盤に表に出やすいので解消期間を計画に入れること、テストは実際の業務データで行えるよう、テストの前に移行データを揃えることも求めています。

費用と見積もりの見方 — リプレイスで費用が膨らむ場所

リプレイスの費用は、対象業務の範囲、拠点数、どの手法を選ぶかで大きく変わるため、一律の相場を示すことはできません。ただし、費用がどう決まるかは分解できます。

開発の費用は、基本的に人月単価 × 体制(人数) × 期間の掛け算です。単価の考え方と、体制・期間から概算を出す方法はMVP開発の費用相場の記事で詳しく扱っています。冒頭の案件で言えば、開発側は2名、期間は10ヶ月でした。自社の案件でも、体制と期間の見通しが分かれば、そこに単価を掛けて概算の桁をつかめます(実際の請求額は、契約形態や範囲で変わります)。

リプレイスでは、この開発費に、新規開発にはない作業が上乗せされます。だから総額だけ比べても判断できません。見積もりのどこを見れば、後から費用が膨らむかどうかが分かるかを整理します。リプレイスで特有に発生する次の作業が、見積もりに入っているかを確かめてください。

見積もりで確認する項目	なぜ要るのか	入っていないと起きること
現行システム・業務の調査	「今と同じ」の中身を言葉にしないと、作る範囲が決まらない	テストの段階で「前と動きが違う」が多発し、追加費用になる
業務ルールの整理(共通定義)	何を統一し、何を残すかを決める工程	拠点ごとの違いがそのまま作り込まれるか、後から作り直しになる
データ移行	対象の整理・クレンジング・移行結果の確認が必要	終盤で移行データの不備が見つかり、稼働が延びる
新旧の突き合わせテスト	新システムが旧と同じ結果を出すかを確かめる	数字の誤りが稼働後に見つかる
並行稼働・段階リリースの支援	切り替え期間の問い合わせ対応や差異の調査	現場任せになり、並走が終わらなくなる
引き継ぎ・ドキュメント	稼働後の改修を社内や別の会社でもできるようにする	改修のたびに同じ会社に頼むしかなくなる

総額より、区切り方を見る

リプレイスの企画段階では、まだ分からないことが多く、最初から精度の高い総額は出せません。IPA のユーザガイドも、企画段階の概算見積もりを工程の区切りごとに詳細化していくこと、不確定な要素を減らすために事前の検証を行い、その結果を見積もりに反映することを勧めています。経済産業省のモデル取引・契約書が示す多段階の契約と再見積もりの考え方も、同ガイドの中で紹介されています。

私たちも段階見積りを採用しており、ディスカバリー(現状把握と課題整理・1〜2週)→ PoC(小規模な実証・4〜6週)→ 要件定義(4〜8週)→ 開発(3〜6ヶ月)→ 内製化、とフェーズごとに投資判断を区切れる形にしています。最初に全体金額を確定させるのではなく、現状把握の段階から始めて、範囲が見えた段階で次を判断する進め方が現実的です。

逆に、企画段階で総額だけが一本で示され、前提条件や内訳が薄い見積もりには注意が必要です。前提が崩れたときに、どこがどう増えるのかが読めないからです。

見積もりを依頼するときに確認したい5つの質問

1. 現行の調査と業務ルールの整理は、どの工程に含まれていますか — 含まれていなければ、発注側が単独で背負うことになります
2. 「今と同じ」の範囲を、何を正として決めますか — 設計書か、ソースコードか、今の動きか。答えが曖昧なら、後の追加費用の火種になります
3. 移行方式と並行稼働の期間は、どう想定していますか — 一括移行前提の計画なら、切り戻しの設計をどう考えているかを確認します
4. データ移行の対象範囲と、移行結果の確認方法は決まっていますか — 全件移行前提か、対象を絞る前提かで作業量が変わります
5. 引き継ぎとドキュメントは、どの工程に含まれていますか — 見積もりに含まれていない場合、後から追加費用として発生します

見積もりの比較そのものや、開発会社の選び方については、開発会社の選び方の記事で詳しく扱っています。

見積もりを取る前の段階で、何を作り直すべきかがまだ見えていない場合は、現状把握だけを1〜2週のディスカバリーとして切り出して依頼することもできます。リプレイスの範囲を整理したい段階から相談する。

効果測定 — 何を測れば「リプレイスできた」と言えるのか

「システムが稼働した」はゴールではありません。業務が実際に軽くなったかどうかを、数字で確認する必要があります。

測る指標の例

指標	測り方	この案件での実測値
月次集計リードタイム	締めから全社数値が確定するまでの日数	4日 → 1.3日(-68%)
入力工数	対象業務の入力・転記にかかる月間人時	月140h → 月40h(-71%)
業務ロジック数	同一業務に存在する計算・判断ルールの本数	42 → 8
属人化度	その業務を単独で回せる人数	全社集計なし
データ鮮度	実績発生から数値が参照可能になるまでの時間	全社集計なし

月次集計リードタイム・入力工数・業務ロジック数の3指標が、冒頭で触れた製造業案件の実測値です(衣株式会社(koromo)の受託開発事業(現・株式会社隼)における支援実績)。6工場の業務ロジックを共通化した事例として、体制・期間とともに掲載しています。

属人化度とデータ鮮度は、この案件では全社共通の指標として集計していませんが、リプレイスの効果を測るうえで有効な観点です。特に「属人化度」は、担当者の異動・退職で業務が止まるリスクに直結するため、経営側にとっては工数削減以上に重要な指標になり得ます。

測定は「刷新前」に始める

見落とされがちですが、これが最も重要です。

リプレイス後にいくら測っても、リプレイス前の数字がなければ効果は語れません。「月次集計が1.3日で終わるようになりました」という報告に意味があるのは、以前が4日だったと分かっているからです。

そして、刷新前の数字は、刷新前にしか測れません。ステップ1の現状ヒアリングと同時に、対象業務の所要時間・工数を実測しておいてください。この一手間が、稼働後に追加投資の判断を仰ぐときの材料になります。

なお、指標は3〜5個に絞ることを推奨します。測る項目を増やしすぎると測定自体が負担になり、いつの間にか誰も測らなくなります。

稼働直後の数字は、一時的に悪化する

もう一点、評価のタイミングについて。切り替えた直後は、慣れない操作と並走運用の負担が重なり、工数がむしろ増えることがよくあります。ここで「リプレイスは失敗だった」と結論を出してしまうケースがありますが、判断が早すぎます。

効果を評価するのは、現場が新しい手順に慣れ、並走運用を終えた後です。経営側への説明時には、この「一時的に悪化する期間」が計画に織り込み済みであることを事前に共有しておいてください。稼働直後の混乱が想定外の失敗として扱われると、プロジェクトそのものへの支持が失われかねません。

納品して終わりにしない — 内製化と引き継ぎまで設計する

基幹システムは、作っている期間より、稼働してからの期間のほうがずっと長いものです。制度改正、組織変更、取引先の要求。変更要求は、ほぼ確実に発生します。

このとき、変更のたびに開発会社へ発注しなければ何も直せない状態になっていると、リプレイス前の「担当者しか触れない Excel」と、構造としては同じ問題を抱えることになります。属人化の対象が、社内の担当者から社外のベンダーに移っただけです。IPA のユーザガイドも、新システムが稼働後に再びレガシー化するおそれに触れ、それを防ぐ取り組みを検討する重要性を挙げています。

引き継ぎは「最後の工程」ではない

引き継ぎをプロジェクト終盤の作業として計画すると、たいていうまくいきません。納期に追われた終盤にドキュメントを書き起こす形になり、実態と乖離した資料が残ります。設計書と実際の動きが食い違う状態は、まさに失敗パターンの1つ目で見た「今と同じ」のずれを、次のリプレイスに持ち越すことになります。

現実的なのは、開発中から社内メンバーが関与し続ける形です。仕様の意思決定に社内側が参加し、変更の背景を理解した状態で稼働を迎える。ドキュメントは終盤にまとめて書くのではなく、意思決定のたびに残していく。

私たちが技術顧問・内製化支援で「引き継ぎを最初から設計する」と言っているのは、この意味です。最終的に外部パートナーへの依存がなくなる状態——つまり「卒業」——をゴールに置きます。

着手前チェックリスト

リプレイスの検討を立ち上げる前に、次の項目が埋まっているかを確認してください。埋まらない項目を残したまま製品選定や見積もり依頼に入ると、後工程で手戻りが発生しがちです。

• 困りごとを具体的に書き出し、改修・機能追加で足りるかを検討した
• 対象業務の範囲が決まっている(受注・在庫・原価・請求のどこまでを置き換えるか)
• 全拠点・全部門のヒアリング対象者が特定できている
• 「統一する / 残す / やめる」を最終判断できる意思決定者が決まっている
• 「今と同じ」で再現する範囲と、何を正とするかの方針がある
• 刷新前の実測値(月次集計リードタイム・入力工数)を取り始めている
• 最初に移行する拠点の候補と、その選定理由を説明できる
• 並走期間と、並走を終了する条件が決まっている
• 切り戻しの条件と手順が決まっている
• 新システムに移すデータの範囲が決まっている
• 稼働後にシステムを引き取る社内担当が決まっている
• 見積もりに現行調査・データ移行・新旧の突き合わせ・引き継ぎが含まれているか確認した

よくある質問

リプレイスとリプレースは違うものですか

同じ意味です。英語の replace をカタカナにしたときの表記の揺れで、どちらも「今のシステムを新しいものに置き換える」ことを指します。社内で表記を揃えておくと、資料の検索や議事録の整理が楽になります。

既存システムに機能を追加するだけで済ませることはできますか

困りごとが特定の帳票・画面・連携に限られ、今のシステムを直せる状態にあるなら、済むことは多いです。ソースコードや設計書が手元になく改修のたびに不具合が出る、基盤の保守期限が近いといった場合は、機能追加の費用が無駄になりやすいため、リプレイスと比べて判断してください。

システムリプレイスにはどのくらいの期間がかかりますか

対象業務の範囲と拠点数によって大きく変わります。冒頭の製造業の案件(6工場、原価・在庫・納期回答が対象)では、プロジェクト期間は10ヶ月でした。一般に、期間を左右するのは実装量よりも、共通定義の合意にかかる時間です。拠点間で意見が割れる論点が多いほど長くなります。

費用はどのくらいかかりますか

一律の相場は示せませんが、開発費は人月単価×体制×期間に分解でき、そこに現行調査・データ移行・新旧の突き合わせ・引き継ぎといったリプレイス特有の作業が乗ります。見積もりは総額より内訳を見てください。私たちは段階見積りで、フェーズごとに投資判断を区切れる形にしています。

パッケージとスクラッチ、どちらを選ぶべきですか

先に決めるべきなのは、どちらを選ぶかではなく「何を共通化するか」です。共通定義が固まっていれば、その定義をパッケージの標準機能や設定で満たせるかを具体的に判定できます。共通定義がないままパッケージを選ぶと、判断基準がないまま、アドオンが際限なく増えていきます。

現場がリプレイスに反対している場合、どう進めればよいですか

反対の理由を、感情ではなく業務の問題として具体化するところから始めます。多くの場合、背景にあるのは「いまのやり方には理由があるのに、それが伝わっていない」という認識です。ヒアリングでその理由を引き出し、共通定義の中に残せる見通しを示せれば、反対は具体的な要件に変わります。

情シス担当が1人しかいなくても進められますか

進められますが、その1人を実装作業に充てないことが条件です。限られた社内リソースは、拠点間の調整と「統一する / 残す / やめる」の意思決定に充てるべきです。実装や移行作業は外部に出せますが、業務判断は外部に出せません。業務の意思決定者と各拠点のキーパーソンは、情シスとは別に確保が必要です(兼務で構いません)。

まとめ

システムリプレイスは、製品選定から始めるものではありません。整理すると、次の順序になります。

• 置き換えるかを決める — 困りごとが一部に限られるなら改修・機能追加。業務を変えずに環境だけ新しくするなら基盤の入れ替え。業務の中核を製品の標準に合わせられるならパッケージ、合わせられないなら作り直す
• 現状ヒアリングと共通定義 — 暗黙のロジックを例外から聞き出し、「統一する / 残す / やめる」に仕分ける。「今と同じ」の中身もここで言葉にする
• 移行の設計 — 段階移行を基本に、並行稼働を組み合わせる。並走の終了条件と切り戻し条件、移すデータの範囲を先に決める
• 拠点別リリースと定量検証 — 1拠点ずつ切り替え、刷新前から測った数字で効果を確かめる
• 見積もりと引き継ぎ — 総額より内訳と区切り方を見る。引き継ぎは最後の工程ではなく、開発中から設計する

そして全体を貫く前提が、現場のやり方を否定しないことです。拠点ごとに育った Excel や古いシステムは、その会社が業務の例外に対応してきた記録であり、リプレイスが引き継ぐべき資産です。42 を 8 にできたのは、切り捨てたからではなく、引き継いだからでした。

「改修で済むのか、作り直すべきなのか、まだ判断がつかない」——その段階のご相談こそ歓迎します。RFP も、固まった要件も必要ありません。1〜2週のディスカバリー単体からご依頼いただけ、現状把握と課題整理を通じて、改修・基盤の入れ替え・パッケージ・作り直しのどれを検討すべきかを一緒に整理します。契約は成果報酬型の請負を基本としています。一方で、置き換える製品がすでに決まっていて、導入の作業だけを任せたい場合は、その製品の導入支援会社のほうが適しています。システムリプレイスについて相談するからご連絡いただければ、2営業日以内にご返信します。