業務システム刷新は、保守費の高騰、セキュリティリスクの拡大、エンジニア人材の枯渇という三つのリスクを防ぐための取り組みです。
刷新の全体像から進め方、開発会社の選び方、費用、発注方法、失敗を避けるポイントまで、発注側が押さえておきたい流れを順に見ていきます。
この記事で扱う進め方、開発会社、費用、発注の四つは、それぞれ次の記事で詳しく解説しています。
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
業務システム刷新の全体像
レガシーシステムの定義と放置するリスク
レガシーシステムとは、構築から長年が経過し、現在の技術水準や業務要件に合わなくなった情報システムの総称です。単に「古い」というだけでなく、維持や変更のコストが現実的なビジネス価値を大きく上回る状態に陥っているものを指します。
技術面では、担当者の退職や高齢化により、COBOLや旧式のJava・VBで書かれたシステムを保守できるエンジニアが急速に減っています。
経済産業省の試算では、2025年以降にレガシーシステムの刷新が進まない場合、国全体で年間最大12兆円の経済損失が生じる可能性があると報告されています。この試算は、「2025年の崖」として広く知られるようになりました。放置して生じるリスクは、大きく三つに分類できます。
- 技術的なリスク：保守の担い手が失われ、誰も触れないブラックボックス化が進みます。
- ビジネス上のリスク：インボイス制度や電子帳簿保存法などの法制度の変更、市場の変化に対応した改修が、困難かつ高額になります。
- セキュリティリスク：サポート切れのOSやミドルウェアを使い続けると、サイバー攻撃の標的になりやすくなります。
刷新の手法（7Rフレームワーク概要）
業務システムの刷新手法は、クラウド移行の文脈でAWSが提唱した「7Rフレームワーク」で整理されることが多いです。基本の7つのうち前半は、「Retire（廃棄）」「Retain（現状維持）」「Rehost（インフラのみ移行）」「Replatform（部分的な最適化）」です。
残る3つは、「Repurchase（SaaS等への乗り換え）」「Refactor（再設計・再構築）」「Relocate（ハイパーバイザー移行）」です。
刷新の実務では、業務上の重要度とシステムの劣化度の二軸で各機能を評価し、機能ごとに最適な手法を選びます。たとえば汎用的な経費精算業務は「Repurchase（クラウドサービスへの乗り換え）」が費用対効果に優れ、独自のオペレーションが競争優位の源泉である基幹業務は「Refactor（スクラッチ再構築）」を選ぶ場合があります。この判断を誤ると、刷新後にまた新たな技術的負債を生み出します。
▶ 詳細はこちら：業務システム刷新の進め方（No.1941）
業務システム刷新の進め方
要件定義・企画フェーズの重要性
業務システム刷新プロジェクトの成否を決める最大の要因は、要件定義と企画フェーズにあります。実際には、多くのプロジェクトが計画段階で行き詰まったり、途中で大幅なコスト超過を招いたりしています。
- コストの増え方：要件定義の手戻りによるコスト増は、開発フェーズの手戻りと比べて10倍以上になるという研究データもあります。
- 失敗後に聞かれる声：「要件が曖昧なまま開発に着手した」「現場の業務フローを正確に把握していなかった」という声が、事後分析で繰り返し聞かれます。
- 企画時の合意：経営層・IT部門・現場部門の三者が足並みを揃えることが不可欠です。
- 役割分担：経営層は刷新の目的を明確に言語化し、現場部門は現行システムの支障を具体的に洗い出す必要があります。
- 後工程への影響：RFP（提案依頼書）の精度もこのフェーズの品質に大きく依存するため、手を抜けない工程です。
このフェーズでよく用いられる「As-Is / To-Be分析」では、現状の業務プロセスを図式化し、あるべき姿と対比させて刷新の優先度を一覧にします。
データクレンジングという現実の壁
多くのプロジェクトで想定外の時間とコストを消費するのが、データ移行、とりわけデータクレンジングの工程です。長年使い続けた業務システムには、入力ルールを守らないデータや重複登録された顧客マスタ、廃番なのに残る商品コード、担当者しか意味を知らない独自の略称などが大量に蓄積されています。データクレンジングの作業は、技術的な問題であると同時に、業務ルールの洗い出しでもあります。
特に、「このコードは何を意味するのか」「この顧客はA社と同一法人か別法人か」という判断は、ITエンジニアではなく業務担当者にしか下せません。そのため、現場担当者が継続的に関与する体制が必要で、プロジェクト工数の20〜30%をデータ移行関連作業が占めるケースも珍しくありません。この現実を軽視してスケジュールを組むと、カットオーバー直前に深刻な手戻りが発生します。
刷新の進め方は、業務システム刷新の進め方（No.1941）で詳しく解説しています。
開発会社の選び方
SIerの種類と特徴（メーカー系・独立系等）
業務システム刷新の発注先となるSIer（システムインテグレーター）は、大きく四つの種類に分類されます。第一は「メーカー系SIer」で、富士通・NEC・日立製作所などハードウェアメーカーを母体とする企業群です。自社ハードウェアとの親和性が高く、大規模な基幹系システムに強みを持ちますが、一般的に単価が高く、提案内容が自社製品に偏りやすい傾向があります。
第二は「ユーザー系SIer」で、特定の業界・企業グループ向けに特化した業務知識を持つ企業群です。業界固有の業務フローを深く理解している一方で、グループ外の案件は優先度が下がる場合があります。第三は「独立系SIer」で、特定のメーカーやグループに属さず、幅広い技術・製品を扱える柔軟性が特長です。
この独立系SIerは、規模が大きいものから中小まで多様で、中小はコストを抑えやすい反面、大規模プロジェクトの対応力や品質保証の仕組みに差があります。第四は「コンサルティングファーム系」で、戦略立案から実装まで一貫して担える企業群ですが、費用は最も高くなる傾向があります。いずれも一長一短があるため、自社のシステム規模・業務の特殊性・予算に合わせて選ぶことになります。
ベンダー選定で失敗しないための基準
ベンダー選定では、提案書の見栄えや見積金額の安さだけでなく、実力を見て判断することが欠かせません。この点を端的に示すのが、キングジムのシステム刷新事例です。同社は複数のベンダーの提案のうち、見積金額が最も高かったJQ社をあえて選び、プロジェクトを成功に導きました。決め手は「技術力の高さ」「プロジェクト管理の実績」「担当者との信頼関係の構築可能性」であったと報告されています。
また、安さを優先した選定がプロジェクトの失敗につながる事例は、枚挙にいとまがありません。そこで、実務的な基準は、同規模・同業種の導入実績、プロジェクトマネジメントの方法論と体制、要件定義への関与姿勢（丸投げを受け入れるか、一緒に考えるか）、保守・運用の対応力、担当者レベルのコミュニケーション品質です。
ベンダーの選定プロセスは、複数のベンダーにRFPを送付してRFP応答を評価し、2〜3社に絞り込んだうえでプレゼンテーション審査を行うのが一般的です。
▶ 詳細はこちら：業務システム刷新でおすすめの会社（No.1942）
費用相場
規模別の費用目安
業務システム刷新の費用は、システムの規模・複雑性・利用ユーザー数・カスタマイズの深度によって大きく異なります。一般的な目安として、中小企業が対象とする中規模システム（社員数50〜300名程度）の場合は、500万円〜3,000万円に収まることが多いです。一方で、大企業の基幹系システム刷新では、1億円〜数十億円規模に及ぶプロジェクトも存在します。
費用の内訳は大きく「初期開発費用」「インフラ・ライセンス費用」「データ移行費用」「教育・研修費用」「保守運用費用」に分類されます。このうち見落とされがちなのが保守運用費用で、一般的に年間保守費用は初期開発費用の15〜20%が相場とされています。たとえば初期開発費用が3,000万円のシステムであれば、毎年450万〜600万円の保守費用が発生する計算になります。
刷新の判断は、刷新前の現行システムの保守費用と比べ、TCO（総保有コスト）ベースで行うことが大切です。
費用を左右する主な要因（エンジニア単価・オフショア活用）
システム開発費用の大部分はエンジニアの人件費で、国内フリーランスエンジニアの平均月単価は78.3万〜80万円程度で推移しています。SIerに発注する場合は、これに管理費・利益マージンが乗るため、さらに高くなります。一方で、コスト削減の選択肢として注目されるオフショア開発は、国・時期によって単価が大きく変動します。
2026年現在の参考値として、中国オフショアの平均月単価は約58.3万円（前年比+31.3%と上昇傾向）、インドは約37.5万円（前年比-29.6%と下落傾向）というデータがあります。オフショア活用はコスト面では魅力的ですが、次のようなリスクを伴います。
- 言語・文化の壁：コミュニケーションコストがかかります。
- タイムゾーンの違い：意思決定の遅延を招きます。
- 品質管理の難しさ：成果物の品質を一定に保つことが難しくなります。
特に要件定義や設計は国内でしっかり固め、実装・テストの一部をオフショアに振る「ハイブリッド型」が現実的な選択肢になっています。
近年は生成AIの活用によってエンジニアの生産性が向上しつつあり、開発費用の見積もり水準が今後変化する可能性も視野に入れておく必要があります。
▶ 詳細はこちら：業務システム刷新の費用（No.1943）
発注・外注方法
発注前に準備すべきドキュメント（RFP等）
業務システム刷新の発注を成功させるうえで最も重要な準備物が、RFP（Request for Proposal：提案依頼書）です。RFPとは、発注者がベンダーに対して「何を・どのように・どの品質で・いつまでに・どの予算範囲で」実現してほしいかを明文化した文書です。複数のベンダーから横並びで比較可能な提案を得るための、共通仕様書として機能します。
RFPの品質が高いほど、受け取るベンダー提案の精度も上がり、選定判断の確度が高まります。
RFPには、ベンダーが同じ前提で提案を組み立てられるよう、発注側の状況と求める内容を書き込みます。
- プロジェクトの背景と目的：なぜ刷新するのか、何を実現したいのか
- 現行システムの概要と課題：今の仕組みの全体と、そこで困っている点
- 新システムに求める機能要件・非機能要件：必要な機能と、品質などの条件
- スケジュールの大枠：いつまでに何を進めるかのおおまかな計画
残りは、予算規模の上限目安、ベンダーに求める体制・実績、提案フォーマットと選定プロセスの3つです。
RFP作成に先立って用意しておくドキュメントには、現行システムの業務フロー図、システム構成図（インフラ・ネットワーク）、データ項目定義書があります。さらに、主要な業務要件のユーザーストーリーリストも用意しておきます。
これらを整備すると、ベンダーとの認識齟齬が減り、見積精度を高められます。
請負契約 vs 準委任契約の使い分け
発注者が必ず理解すべきなのは、「請負契約」と「準委任契約（SES契約）」の違いです。請負契約は、完成を約束する契約形態です。
契約の種類によって、ベンダーが負う義務の中身は変わります。
- 請負契約：ベンダーは仕様どおりのシステムを納品する義務（完成義務）を負い、納品物に瑕疵があれば無償修正を求めることができます。
- 準委任契約：ベンダーが業務遂行に向けた「善管注意義務」を負うものの、完成は保証しない契約です。
完成責任がベンダー側にあるため、発注者のリスクは小さい反面、詳細な仕様を事前に確定しなければならず、仕様変更が発生すると追加費用の交渉が必要になります。
どちらを選ぶかは、要件の確定度合いとプロジェクト管理リソースのバランスで判断します。
こうした性質から、準委任は要件が不確定な段階や、アジャイル型開発でスプリントを重ねながら仕様を固める場合に適しています。発注者側のコントロールが強い反面、コスト管理の責任も発注者側に移ります。実際には、要件定義を準委任で進め、詳細仕様が固まった開発・テストフェーズを請負に切り替える組み合わせが有効なケースも多いです。
▶ 詳細はこちら：業務システム刷新の発注方法（No.1944）
業務システム刷新で失敗しないためのポイント
実名から学ぶ失敗パターン（スルガ銀行・みずほ銀行事例）
業務システム刷新の失敗事例として最も知られているのが、スルガ銀行と日本IBMの法廷闘争です。スルガ銀行は次期勘定系システムを日本IBMに発注したものの、プロジェクトは難航を極め、総額95億円を投じながらシステムの稼働を断念するという前例のない事態に発展しました。裁判の過程で明らかになったのは、次の三つの複合的な原因でした。
- 要件の無限の追加・変更：仕様の追加や変更が際限なく続き、開発の範囲が定まらない
- 意思決定の遅延：判断が遅れ、後続の作業に影響が及ぶ
- 発注者側のプロジェクト管理能力の欠如：発注側が進行を十分に管理できなかった
判決ではIBM側の瑕疵が認定されましたが、発注者側にも相当の責任があると判断されています。このケースは、「発注者も当事者として積極的にプロジェクトに参加しなければ失敗する」という教訓を示しています。みずほ銀行のATM障害は、技術的な問題以上に組織文化に起因するシステムリスクを示した事例として、記憶に残っています。
一連の障害を調査した第三者委員会は、根本的な原因として「失点を恐れて積極的行動を取らない」という企業風土を指摘しました。問題の予兆を察知したメンバーが声を上げづらい組織では、小さな不具合が積み重なり大規模障害へと発展します。業務システム刷新でも同様で、「報告しやすい文化」「問題を早期にエスカレーションできる仕組み」がなければ、リスクは水面下で増大し続けます。
技術的な刷新と並行して、組織のガバナンスや意思決定文化を見直すことが、真の意味でのシステム刷新につながります。
プロジェクト炎上時の「撤退の作法」
業務システム刷新プロジェクトが炎上した際の撤退は、日本のビジネス界ではタブー視されがちなテーマですが、現実には避けられない選択を迫られるケースがあります。プロジェクトの継続に固執するあまり、追加投資を続けて損失を拡大させる「コンコルドの誤謬（サンクコスト効果）」に陥るケースは少なくありません。そこで、機能不全に陥った早期のサインを見逃さないことが大切です。
主なサインとしては、次のような例が挙げられます。
- 遅延の累積：「当初スケジュールから3カ月以上の遅延が累積している」
- 要望件数の急増：「仕様変更要望の発生件数が当初見積比150%を超えている」
- 体制の不安定化：「ベンダーの担当者が頻繁に入れ替わっている」
撤退を決断する場合は、まず契約上の権利を確保する必要があります。請負契約であれば、民法上の「契約解除権」と「損害賠償請求権」が発注者側に存在します。
ただし、ベンダーに債務不履行を主張するには、「何を・いつまでに・どの品質で」という合意が文書として残っていることが不可欠です。この観点から、要件定義書・仕様書・議事録・メールのやりとりを日常的に正確に記録しておくことは、単なる情報管理ではなく「プロジェクトのリスクヘッジ」として位置づけるべきです。
発注者は、撤退後の再起動を見据えて、知的財産権（ソースコードの帰属）と開発途中の成果の引き渡し条件を、契約段階で明確にしておく必要があります。
まとめ
業務システム刷新は、単なるITプロジェクトではなく、経営変革の一部です。
ここまで見てきたように、刷新の手法選択（7Rフレームワーク）から始まり、要件定義・データクレンジングという地道な工程まで、検討すべき要素は多岐にわたります。開発会社の選定基準、費用の目安、発注形態の違い、そして失敗事例から学ぶ教訓も、欠かせない要素です。
スルガ銀行の事例では、95億円を投じても失敗するプロジェクトが存在します。一方、キングジムの事例では、最高額のベンダーを選んでも、適切な判断と関係構築によって成功を収めることができます。
成功する刷新プロジェクトに共通するのは、「ベンダーに任せきりにしない」「経営レベルの関与を維持する」「問題を早期に表に出す組織文化をつくる」の三点です。
各トピックの詳しい内容は、以下の子記事で解説しています。
自社の状況に合わせた情報収集には、次の記事を役立ててください。
相談前には、レガシーシステム刷新の完全ガイドブックと【2026年最新版】AI駆動開発の完全ガイドブックをご覧ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。