LASSIC Media らしくメディア

LASSIC IT事業部｜プライムベンダーとしてシステム保守・運用を受託

基幹システム開発コスト削減とは：刷新総額を5年TCOで抑える設計判断

基幹システム開発のコスト削減とは、業務継続性を担保しながら基幹システムの総保有コスト（TCO）を抑制する設計判断の総称である。対象は会計・販売・生産・人事などの基幹業務を支えるシステムの新規開発・刷新・運用の全工程に及ぶ。基幹システムは企業の業務継続性に直結するため、初期開発費の圧縮だけでなく、長期稼働を前提とした保守体制までを含めて評価する必要がある。JUAS「企業IT動向調査2025」（東証上場企業等4,500社のIT部門長を対象、有効回答981社、2025年4月公表）では、25年度のIT予算増加理由として「基幹システムの刷新」を挙げた回答が44.5%に達しており^*1、レガシー刷新の需要が高止まりするなかで刷新総額をどう抑えるかが多くの企業の論点となっている。

定義の射程：レガシー刷新とフルスクラッチ新規開発の両方を含む

基幹システム開発の論点は、既存基幹システムの刷新と、新規企業・新規事業向けのフルスクラッチ開発の双方を含む。刷新案件では既存システムからのデータ移行・業務継続性の確保が論点となり、新規開発では要件確定の精度と業務プロセスの設計が論点となる。コスト削減のアプローチは両者で異なる。

「2025年の崖」と刷新需要の構造

経済産業省「DXレポート」が示した「2025年の崖」は、レガシー基幹システムの維持コスト増大とDX阻害を警鐘した政策提言である^*4。指摘から数年が経過し、刷新需要が継続的に発生している。刷新を先送りするほど維持コストが累積するため、刷新の意思決定タイミングがコスト総額を左右する。

コスト膨張の3要因：仕様の歴史的負債・スコープ拡大・移行リスク

基幹システム刷新で見積もりからコストが膨らむ典型は3パターンに集約される。仕様の歴史的負債・スコープ拡大・移行リスクだ。仕様の歴史的負債は、長年の改修を経て属人化したロジックの解析コストが膨らむ事象を指す。スコープ拡大は、刷新を機に新規機能を盛り込みすぎて要件が膨張する現象である。移行リスクは、データ移行・業務切替の失敗が再開発コストを発生させる事象である。

仕様の歴史的負債：属人化したロジックの解析コスト

長期稼働している基幹システムでは、設計書の更新が追いつかず、現行ロジックがソースコードのみに残存しているケースが見られる。仕様復元のためにリバースエンジニアリングが必要となり、解析工数が見積もりを超過する原因になる。

スコープ拡大：刷新を機に新規機能を盛り込みすぎる失敗

基幹システム刷新の機会に業務改革も同時に進めようとすると、要件が膨張しコストが拡大する。刷新と業務改革を切り分け、刷新は現行業務の継続性確保に絞り、業務改革はフェーズ2で扱う設計が、コスト管理上は有効である。

移行リスク：データ移行と業務切替の失敗が再開発を生む

基幹システムのデータ移行は、文字コード変換・コード体系統一・履歴データ整合性の確保など、技術的論点が多い。移行リハーサルを十分に実施しないまま本番切替を行うと、業務停止・再開発のコストが発生する。移行計画は刷新計画と同じ重みで設計する。

刷新範囲の絞り込み：全面刷新と部分刷新の判断軸

基幹システム刷新のコスト削減は、刷新範囲をどう絞り込むかから始まる。全面刷新と部分刷新（モジュール単位での段階刷新）には、それぞれメリットとデメリットがある。判断軸は、現行システムのアーキテクチャ統合度・業務継続性のリスク許容度・経営判断のタイミングの3点である。

全面刷新が適するケース：アーキテクチャ統合度が低く全社改革と連動

現行基幹システムが複数システムの寄せ集めで、アーキテクチャ統合度が低い場合は、全面刷新が適する。全社業務改革・経営統合と連動するタイミングでは、業務プロセスとシステムを同時に再設計できる利点がある。一括投資が必要だが、新旧並行運用のコストを抑えられる。

部分刷新が適するケース：業務継続性を優先し予算を分散

業務継続性のリスク許容度が低い場合や、年次予算で段階的に投資したい場合は、部分刷新が適する。モジュール単位（販売管理→在庫管理→会計など）で刷新を進めることで、業務停止リスクを分散できる。一方で新旧システム並行運用の期間が長くなり、データ連携の開発コストが追加で発生する。

刷新スコープの線引き：BPRと並行設計するか分離するか

刷新範囲を絞る判断軸として、業務プロセス再設計（BPR）を刷新と並行するか分離するかの設計がある。並行設計はシステムと業務を同時に最適化できるが、要件確定の難度が上昇する。分離設計は刷新を現行業務踏襲で進め、稼働後にBPRを実施する手順で、要件確定が容易になる。

移行方式の選択：リホスト・リプラットフォーム・リライトの比較

基幹システム刷新の移行方式は、5方式が代表的である。具体的にはリホスト・リプラットフォーム・リライト・リファクタ・リプレースの5種である。各方式の意味は後述するH3で順に解説する。AWSが整理した「6R」フレームワークで広く知られる分類である^*5。総額と移行期間が方式によって大きく異なる。

リホスト：最短期間で環境のみ移行する選択

リホスト（Rehost）は、業務ロジックを変更せずに実行環境のみクラウド・新サーバーに移行する方式である。移行期間が短く、刷新コストが抑えられる利点がある。一方で業務ロジックの負債は残存するため、稼働後の改修コストは現行水準を維持する。短期に「2025年の崖」のインフラリスクを回避したい場合に選択肢として挙がる。

リプラットフォーム：基盤を変更し部分改修を伴う移行

リプラットフォーム（Replatform）は、データベース・OS・ミドルウェアなど基盤を変更し、必要に応じてアプリケーションを部分改修する方式である。リホストよりコストが上がる一方、新基盤の運用効率向上を取り込める。基盤更改と部分改修を組み合わせる判断は、稼働後の保守コスト削減に寄与する。

リライト：フルスクラッチで業務ロジックを再構築

リライト（Rebuild）は、業務ロジックを再設計してフルスクラッチで開発する方式である。最も投資額が大きく期間も長いが、長年蓄積した仕様の負債を解消し、保守コスト・改修コストを大幅に下げられる。経営判断として5年以上の長期視点で投資を回収する案件に向く。

リプレース：パッケージ・SaaS導入で業務をパッケージに合わせる

リプレース（Replace）は、商用パッケージ・SaaSを導入し、業務をパッケージ側に合わせる方式である。会計・人事・販売管理など標準化された業務領域で適する。独自業務のフィット&ギャップ作業が必要となり、業務側の運用変更コストが発生する。

リファクタ：コード構造のみを整理して保守性を上げる

リファクタ（Refactor）は、業務機能は変更せずコード構造を整理し、保守性を高める方式である。小規模な刷新案件で選択される。リファクタのみではインフラ更改の課題が残るため、リホストやリプラットフォームと組み合わせる設計が一般的である。

保守体制の設計：稼働後の運用要員と改修体制

基幹システム刷新のコスト削減は、稼働後の保守体制を初期設計に織り込むことで効果が高まる。保守体制の論点は、運用要員の確保・改修体制の柔軟性・障害対応の体制・ドキュメント整備の4点である。情報処理推進機構（IPA）が2025年6月に公表した「DX動向2025」（日本・米国・ドイツ3か国比較、日本企業1,535社対象）では、日本企業の85.1%でDXを推進する人材が不足していると示されており^*2、米国・ドイツと比較して著しく高い水準にある。基幹システムの保守要員確保は中長期の経営課題だ。

運用要員の確保：内製と外注の組み合わせで体制を構築

運用要員は内製の社員と外部パートナーの組み合わせで構成する。基幹業務知識を持つ社員が運用統制を担い、夜間運用・障害一次対応・定型運用作業を外部に委ねる構成が、要員確保コストと専門性のバランスを取りやすい。

改修体制の柔軟性：ベンダーロックインを避ける契約設計

稼働後の改修を特定ベンダーに依存すると、改修費が交渉余地のない単価で発生する。複数のパートナーが対応できるドキュメント水準・開発標準・技術スタックを採用することで、改修コストの交渉余地を確保できる。元請（プライムベンダー）として複数の下請けを統制できる体制を持つパートナーは、ロックイン回避と品質確保の両立に寄与する。

障害対応：SLAと体制を契約に明記する

基幹システムは業務停止コストが大きいため、障害対応のSLA（Service Level Agreement、サービス水準合意）を契約に明記する。一次対応時間・復旧目標時間・夜間休日対応の体制を、業務影響度に応じて設計する。

削減の落とし穴：「2025年の崖」を意識した先送りリスク

基幹システム刷新のコストを抑える判断として「先送り」を選択する企業もあるが、先送りには別のコストが発生する。維持コストの累積・保守要員の高齢化・ベンダーサポート終了・セキュリティリスクが、先送り期間に応じて拡大する。

維持コストの累積：稼働年数が長いほど改修1件あたりが高騰

稼働年数が長い基幹システムは、改修1件あたりの工数が増加する傾向がある。設計書の不整合解消・周辺システムとの連携確認・テスト範囲の確認に追加工数が発生する。維持コストは線形ではなく逓増的に膨らむ。

保守要員の高齢化：固有技術人材の枯渇

レガシー基幹システムを支える固有技術（特定の言語・ミドルウェア・メインフレーム）の経験を持つ要員は、市場全体で減少している。要員確保が市場で困難になるほど、保守単価が上昇する。要員枯渇は刷新を強制するタイミングを規定する。

ベンダーサポート終了：OS・ミドルウェアの保守期限

OS・データベース・ミドルウェアのベンダー保守期限は、刷新スケジュールを規定する。保守期限を超えた環境はセキュリティパッチが提供されないため、業務継続性のリスクとなる。製品ライフサイクルを把握し、刷新計画に組み込む。

外部パートナー選定の判断軸：移行実績・業務知識・元請体制

基幹システム刷新の外部パートナー選定は、コスト削減の成否を決定する。判断軸は、移行実績・業務知識・元請体制・保守実績・契約形態の5点だ。

移行実績：類似規模・類似業種のレガシー移行経験

移行実績の確認では、システム規模（画面数・帳票数・データ件数）・業種・移行方式の3軸で照合する。類似条件の移行経験を持つパートナーは、移行リスクを早期に識別できる。実績件数のみでなく、失敗事例から得た学びの言語化を聞き取ると、対応力の判断材料になる。

業務知識：基幹業務（会計・販売・生産・人事）の業務理解

基幹システムは業務知識が要件定義の質を決める。会計・販売管理・生産管理・人事給与など、対象業務の業務理解を持つ要員が提案チームに含まれているかが、要件定義の手戻りを左右する。業務知識のあるコンサルタントとシステムエンジニアの両方を含む体制が望ましい。

元請体制：再委託の階層と責任範囲

元請（プライムベンダー）として一貫した責任を負うパートナーは、品質管理と契約責任の所在を明確化できる。再委託（下請け）の階層が深い案件は、コミュニケーションコストと品質リスクが上昇する。自社要員比率と再委託の有無を確認する。

保守実績：長期稼働システムの保守経験

基幹システムは長期稼働が前提のため、外部パートナーが長期稼働システムの保守経験を持つかを確認する。稼働中の保守案件の業種・期間・規模を確認すると、保守力の判断材料になる。新規開発のみの実績では、保守フェーズで発生する課題への対応力が見えない。

失敗のリスクを最小化する内製と外注の比率設計

基幹システム刷新を内製で完結させる判断は、要員確保コストと業務知識の蓄積の両面でメリットがあるが、現在のIT人材市場では実現が難しい。経済産業省が2019年4月に公表した「IT人材需給に関する調査」では、IT人材不足が2030年に高位シナリオで最大約79万人に拡大すると試算している^*3。要件定義は業務知識を持つ内製チーム、設計・実装は外部パートナー、運用は両者の共同体制という配分が、リスクと要員確保コストの最小化に寄与する。

まとめ：基幹システム開発コスト削減の3つの判断軸

基幹システム開発のコスト削減は、刷新範囲の絞り込みを起点に、全面刷新と部分刷新の判断軸をアーキテクチャ統合度・業務継続性・予算配分の3点で設計することから始まる。移行方式の選択はリホスト・リプラットフォーム・リライト・リプレース・リファクタの5方式から、現行システムの負債水準と業務改革の必要性に応じて決定する。保守体制の設計は稼働後の運用要員・改修体制・障害対応SLAを初期設計に織り込む。先送りのコスト累積と要員枯渇のリスクを踏まえ、刷新の意思決定タイミングを経営課題として位置づけることが、5年TCO最適化に直結する。

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：一般社団法人日本情報システム・ユーザー協会「企業IT動向調査2025」（2025年）
2. *2　出典：独立行政法人情報処理推進機構「DX動向2025」（2025年）
3. *3　出典：経済産業省「IT人材需給に関する調査（概要）」（2019年）
4. *4　出典：経済産業省「DXレポート〜ITシステム「2025年の崖」克服とDXの本格的な展開〜」（2018年9月）
5. *5　出典：Amazon Web Services「Migration strategies（6R）」AWS Prescriptive Guidance

Tweet