システムを作り直すべきタイミング：改修とリプレイスの判断基準

システムを作り直すべきかどうかは、「古いかどうか」では決まりません。判断の軸になるのは、改修にかかる費用と時間が増え続けていないか、使っている技術や基盤のサポートが切れていないか、業務や事業の変化にシステムが追いつけているか、そして障害や担当者の退職といったリスクを許容できるか、という四つです。これらの兆候が一つだけなら改修や部分的な置き換えで対応できることが多く、複数が同時に強まっているならリプレイスを具体的に検討する時期だと考えられます。

作り直しの判断が難しいのは、改修とリプレイスの費用が同じ土俵で比べにくいからです。改修は一回ごとの金額が小さく見え、リプレイスは一度に大きな金額が必要に見えます。しかし、改修を続けた場合の数年分の費用と、そのあいだに失う機会やリスクを合わせて比べると、結論が変わることがあります。逆に、勢いで作り直しを決めると、現行システムが黙って支えていた業務の細部を失い、かえって混乱を招くこともあります。

この記事は、社内の業務システムや自社サービスの仕組みについて「このまま直し続けるべきか、作り直すべきか」を判断しなければならない事業責任者や情報システム担当者に向けて書いています。作り直しを考えるべき兆候、改修・部分置き換え・全面リプレイスの比較、判断の手順、よくある判断ミスを順に整理します。

「作り直すべきか」を考え始めるべき兆候

まず、作り直しを検討すべき兆候を整理します。どれか一つに当てはまったらすぐに作り直すべき、というものではありません。複数が重なっているか、年々強まっているかを見ることが大切です。

改修の費用と時間が増え続けている

同じ規模の変更なのに、以前より見積もりが高くなり、期間も長くなっている場合は注意が必要です。原因の多くは、継ぎはぎの改修が積み重なって構造が複雑になり、一か所の変更が思わぬ場所に影響するようになっていることです。開発会社が「影響範囲の調査に時間がかかる」「テストの範囲が広くなる」と説明するようになったら、構造の劣化が進んでいるサインです。

技術や基盤のサポートが切れる・切れている

OS、データベース、プログラミング言語、フレームワーク、ミドルウェアには、提供元のサポート期間があります。サポートが終わると、セキュリティ上の欠陥が見つかっても修正が提供されません。加えて、古い技術を扱える技術者が市場から減り、保守の担い手を確保しにくくなります。サポート期限は事前に分かることが多いため、期限から逆算して判断の時期を決められます。ただし、基盤を新しいバージョンに上げるだけで済むのか、プログラムの大幅な書き換えが必要になるのかは、システムによって大きく異なります。後者の場合、バージョンアップの費用が作り直しに近づくこともあるため、開発会社に影響範囲を見積もってもらい、作り直しの選択肢と並べて比べるのが賢明です。

業務や事業とシステムがずれている

業務の流れが変わったのにシステムが変わらず、現場がExcelや手作業で補っている状態は、システムが業務の足を引っ張っているサインです。新しい販売チャネル、料金体系、取引形態にシステムが対応できず、事業の打ち手が制限されている場合も同じです。このずれは費用として表に出にくいため、現場の作業時間や機会損失として意識的に拾う必要があります。具体的には、各部署に「システムから出したデータを手で加工している作業」「システムに入らない情報を別のファイルで管理している作業」「システムの制約で諦めている施策」の三つを挙げてもらうと、ずれの大きさが見えてきます。

特定の人や会社に依存している

仕様を知っているのが一人の担当者だけ、あるいは特定の開発会社しか触れない状態は、その人や会社がいなくなった瞬間に保守が止まるリスクを抱えています。いわゆるレガシーシステムの問題は、技術の古さよりもこの属人化から深刻になることが多くあります。担当者が休暇を取ると障害対応ができない、開発会社が担当者を交代させると引き継ぎに長い時間がかかる、といった出来事が増えていれば、依存の度合いが高まっている証拠です。属人化は作り直しの理由になる一方で、作り直しそのものを難しくする要因でもあるため、早めに手を打つことが重要です。

改修・部分置き換え・全面リプレイスの比較

選択肢は「直す」か「作り直す」かの二択ではありません。実務では、次の三つ、あるいはその組み合わせから選びます。

部分的な置き換えは見落とされがちな選択肢です。たとえば、画面と業務ロジックはそのままでデータベースだけを新しい基盤に移す、外部連携の部分だけを作り直す、利用者向けの画面だけを新しくする、といった方法です。問題の所在がはっきりしていれば、全面リプレイスよりも少ない費用とリスクで効果を得られます。

作り直しの判断手順

兆候に気づいたら、次の手順で判断材料をそろえます。感覚や印象ではなく、比較できる形に整えることが目的です。

1. 現状のコストを洗い出す。直近数年の改修費用、保守費用、インフラ費用に加え、現場が手作業で補っている時間をざっくりでよいので把握する。
2. 技術と基盤のサポート期限を一覧にする。OS、データベース、言語、主要なライブラリ、利用しているクラウドサービスの期限を確認する。
3. 今後の事業計画で必要になる変更を書き出す。新サービス、取引先の増加、制度対応など、数年以内に予定している変更を並べる。
4. それぞれの変更を、改修で対応した場合の難易度と費用感を開発会社に確認する。
5. 改修を続けた場合、部分置き換えした場合、全面リプレイスした場合の三案について、数年間の費用、期間、リスク、得られる効果を並べる。
6. 業務部門と経営層で比較表を見て、方針を決める。決めた理由を記録しておく。

ここで大切なのは、比較の期間を一年ではなく数年に設定することです。一年だけで比べると、ほとんどの場合は改修が安く見えます。改修を続けた場合の費用が年々どう増えるか、そのあいだに対応できない事業上の変更がどれだけあるかを含めて比べると、判断の材料が揃います。

保守費用の内訳の見方や、見直しのポイントはシステム保守費用の考え方：月額費用の内訳と見直しのポイントも参考にしてください。

判断基準を点数で整理する

複数の観点を一度に比べるために、簡単な評価表を作ると議論が整理されます。各項目を三段階程度で評価し、どこに問題が集中しているかを見ます。

この表は機械的に点数を足して結論を出すためのものではありません。「属人化」だけが高いなら、まず仕様の文書化と担当者の追加で対応できるかもしれません。「技術のサポート」だけが高いなら、基盤の更新を中心にした部分置き換えで足りるかもしれません。どの観点が問題の中心なのかを見極め、それに合う選択肢を選ぶために使います。

具体的な場面の例：会員管理システムの改修か作り直しか

架空の一般例として、ある教育サービスの会社が、会員管理と決済を担う自社システムの扱いに悩んでいる場面を考えます。

このシステムは数年前に急いで作られ、事業の成長に合わせて改修を重ねてきました。最近は、料金プランを一つ追加するだけで数か月かかり、そのたびに思わぬ不具合が発生しています。さらに、使っているフレームワークのバージョンがサポート終了に近づいていることが分かりました。一方で、会員の登録や決済そのものは安定して動いており、利用者からの不満は多くありません。

この会社が判断手順に沿って整理したところ、問題の中心は「料金プランと決済まわりの構造」と「フレームワークのサポート期限」の二点に集中していることが分かりました。会員情報の管理画面や問い合わせ機能は、大きな問題を抱えていませんでした。そこで、全面リプレイスではなく、フレームワークの更新に合わせて料金・決済まわりを作り直す部分置き換えを選び、他の機能は段階的に新しい構造へ移す方針にしました。

この例のように、「作り直すかどうか」を全体で考えるのではなく、問題がどこに集中しているかを分解すると、より小さく確実な選択肢が見つかることがあります。

なお、この会社は部分置き換えの対象を決める際に、料金プランの追加に数か月かかっている原因を開発会社と一緒に調べ、料金の計算ロジックが複数の画面に重複して書かれていることを突き止めました。原因が具体的に分かったことで、作り直す範囲を料金計算の部分に限定でき、見積もりの根拠も明確になりました。兆候の背後にある原因まで掘り下げることが、範囲を適切に絞るための近道です。

改修を続けると決めた場合に打っておくべき手

比較の結果、当面は改修を続けると決めた場合でも、何もしなければ兆候は少しずつ強まっていきます。次に判断するときに選択肢が残っているよう、改修を続けながら打っておくべき手があります。

一つ目は、仕様の文書化です。改修のたびに、変更した機能の目的、業務ルール、影響範囲を短くてもよいので記録に残します。改修を依頼する開発会社に、変更内容の説明資料を成果物として求めるのも有効です。これを続けるだけで、属人化のリスクは確実に下がります。

二つ目は、テストの自動化です。主要な業務の流れだけでも自動テストを用意しておくと、改修のたびに起きる思わぬ不具合を早く見つけられ、影響範囲の調査にかかる時間も減ります。将来リプレイスする場合にも、新旧の動きを比べる材料として使えます。

三つ目は、基盤の更新を計画に組み込むことです。OSやデータベース、フレームワークのバージョンアップを、機能の改修とは別に定期的な作業として予算化しておくと、サポート切れに追い込まれて慌てて作り直す事態を避けられます。

四つ目は、次の判断時期を決めておくことです。「一年後に同じ比較表で見直す」「サポート期限の一年前に判断する」といった期限を決めておけば、判断の先延ばしを防げます。

作り直しを決めた場合の予算と期間の考え方

作り直しを決めた場合、予算と期間は開発費だけで考えないことが大切です。リプレイスには、現行調査、要件の整理、開発、テスト、データ移行、並行稼働、利用者の教育、切り替え後の安定化といった工程があり、開発以外の工程が全体の中で大きな比重を占めます。見積もりを比較するときは、これらの工程がどこまで含まれているかを必ず確認してください。

また、リプレイス期間中は、現行システムの保守費用と新システムの開発費用が同時にかかります。旧システムの停止時期が遅れるほど二重の費用が続くため、停止日を計画に入れ、その日に向けて移行を進める意識が必要です。

予算の確度を上げるには、最初に現行調査だけを小さく発注し、その結果をもとに全体の見積もりを取る進め方が有効です。調査を経ずに全体を見積もると、開発会社は不確実性を上乗せせざるを得ず、金額の幅が大きくなります。調査の成果物は発注側の資産として残るため、仮に依頼先を変えることになっても無駄になりません。

作り直しの判断でよくある失敗と避け方

技術の古さだけで作り直しを決める。 古い技術でも、安定して動き、保守の担い手がいて、業務に合っているなら、急いで作り直す必要はありません。作り直しの目的が「新しい技術にしたい」だけになっていないかを確認してください。

改修の費用を一年分だけで比較する。 前述のとおり、短期間で比べると改修が常に安く見えます。数年単位で、改修費用の増え方と対応できない変更の影響を含めて比べます。

現行システムの価値を過小評価する。 長く使われたシステムには、例外処理や業務上の工夫が埋め込まれています。作り直しを決める前に現行の機能を棚卸しし、何を引き継ぐ必要があるかを把握しておかないと、リプレイス後に「前はできたのに」という不満が噴き出します。

判断を先延ばしにし続ける。 「もう少し様子を見る」を繰り返すうちに、サポートが切れ、担当者が辞め、選択肢が狭まっていきます。判断の期限と、判断に必要な材料を決めて動くことが大切です。

リプレイス中の改修を止められない。 作り直しを決めても、現行システムへの改修要望は続きます。リプレイス期間中は現行システムへの変更を必要最小限にするルールを決めておかないと、新旧両方で同じ変更を行う二重の負担が生じます。

判断前のチェックリスト

作り直しの方針を決める前に、次の項目を確認してください。

• 直近数年の改修費用・保守費用の推移を把握している
• 現場がシステムの外で補っている作業を洗い出している
• OS・データベース・言語・主要ライブラリのサポート期限を一覧にしている
• 現行の仕様を説明できる人が誰か、何人いるかを把握している
• 数年以内に予定している事業上の変更を書き出している
• 改修・部分置き換え・全面リプレイスの三案を同じ期間で比較している
• 問題が全体に広がっているのか、特定の部分に集中しているのかを見極めている
• 現行システムの機能棚卸しを、少なくとも概要レベルで行っている
• リプレイス期間中の現行システムへの改修ルールを考えている
• 判断の結論と理由を記録し、関係者と共有できる状態にしている

現行の仕様を説明できる人がいない場合は、判断の前に現状把握が必要です。方法は仕様書がないブラックボックス化したシステムの現状把握の方法で解説しています。

よくある質問

Q. 作り直しを判断するのは誰がよいですか？

最終的な判断は、費用と事業への影響の両方に責任を持てる人が行うべきです。情報システム部門だけで判断すると技術の観点に偏り、業務部門だけで判断すると目先の使い勝手に偏りがちです。比較表を作るのは担当者でも、結論は経営層を交えて出すのが望ましいでしょう。

Q. 現行の開発会社に相談すると、作り直しを勧められないか心配です。

現行の会社は仕様を最もよく知る相手なので、意見を聞く価値は十分にあります。そのうえで、判断材料を発注側で整理し、必要に応じて別の会社にも意見を求めると、偏りのない判断がしやすくなります。

Q. 作り直すと決めたら、何から始めればよいですか？

最初は現行システムの調査と機能の棚卸しです。何を引き継ぎ、何をやめるかが決まらないと、見積もりも計画も立てられません。具体的な進め方はシステムリプレイスの進め方：現行調査から切り替えまでの手順で解説しています。

Q. 作り直しの費用を抑える方法はありますか？

使われていない機能を対象から外す、汎用的な業務は既製サービスに任せる、問題が集中している部分から段階的に置き換える、といった方法があります。範囲を絞り込むほど、費用だけでなく移行のリスクも小さくなります。

Otsumuに相談できること

兆候がまだ一つ程度で、改修の費用も安定しており、現行の開発会社と良好な関係が続いているなら、この記事の比較表とチェックリストで定期的に状況を点検しながら、改修を続ける判断で問題ないことも多くあります。社内に業務とシステムの両方が分かる担当者がいれば、判断材料の整理も自社で進められます。

一方で、改修の見積もりが妥当かどうか分からない、現行の仕様を説明できる人がいない、作り直すとしてどこから手をつけるべきか判断できない、といった状況では、第三者の視点を入れたほうが早く結論にたどり着けます。作り直しの判断を誤ると、費用だけでなく数年分の事業の動きやすさに影響するからです。

Otsumuは、自らも事業を手がける実践者の視点から、事業計画とシステムの制約を突き合わせ、改修・部分置き換え・全面リプレイスのどれが合うかを一緒に整理します。作り直す場合は、目的から逆算して必要な機能に絞り、AIを活用した少人数・短期間の開発で進めます。進め方はシステムリプレイスのページで紹介しています。費用は範囲に応じて個別にお見積もりします。

判断材料をどう揃えればよいか分からない段階でも構いません。30分の無料相談で、いまのシステムの状況と悩みをお聞かせください。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01