レガシーシステム刷新は、単なるシステム入れ替えではなく経営戦略そのものです。発注方法を誤ると、数億円規模の投資が無駄になるばかりか、基幹業務が停止するリスクすら抱えます。NHKと日本IBMの訴訟（2025年2月）やスルガ銀行の95億円白紙撤回事例を持ち出すまでもなく、契約段階での判断が成否を大きく分けます。

本記事では、社内準備からRFP作成、ベンダー比較、契約、プロジェクト管理、炎上時の撤退戦略まで、発注プロセスを体系的に解説します。レガシーシステム刷新の全体像については、システム刷新完全ガイドもあわせてご参照ください。発注担当者が現場で直面する実務的な判断軸を、事例と法的視点を交えてお伝えします。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド

レガシーシステム刷新を発注する前にやるべき社内準備

レガシーシステム刷新の成否は、発注前の社内準備で7割が決まるといっても過言ではありません。ベンダーに丸投げして失敗するケースの多くは、現行システムの実態把握と社内合意形成が不十分なまま発注してしまうパターンです。RFPを書き始める前に、自社のシステム現状・業務課題・到達目標を徹底的に言語化しておく必要があります。

また、レガシーシステムには属人化された業務ノウハウが埋め込まれており、これを可視化しないまま発注するとベンダーも正確な見積りが出せません。社内準備に十分時間をかけることが、結果的に発注後のトラブルとコスト超過を防ぎます。ここでは特に重要な3つの準備事項を解説します。

最初に着手すべきは、現行システムの棚卸しです。どのサーバーにどのアプリケーションが稼働し、どのデータベースと連携しているのか、インタフェース・バッチ処理・外部システム接続まで漏れなく洗い出します。多くの企業では担当者の異動や退職により、システム全体像を把握している人が誰もいないという事態に陥っています。

As-Is（現状）分析では、機能・性能・運用コスト・障害履歴・改修頻度などを定量化します。続くTo-Be（目指す姿）分析では、刷新後にどの業務をどう変えたいのかを業務フロー単位で描き出します。この2つのギャップこそがベンダーへの発注要件そのものとなります。

分析にあたっては、ソースコードの静的解析ツールを活用することもあります。外部ツールで構造を可視化することで、ブラックボックス化したロジックも明らかにできます。発注前の段階でここまで踏み込めるかどうかで、ベンダーの提案精度は大きく変わります。

レガシーシステム刷新は全社横断プロジェクトです。情報システム部門だけで進めると、現場部門から「聞いていなかった」「業務に合わない」という反発が必ず起こります。ある食品加工工場の事例では、各部署から「システムキーパーソン」を1名ずつ選出し、部門間の利害調整を行う仕組みを構築しました。

キーパーソンには、業務知識が深く、かつ部署内で発言力のある中堅層を充てるのが理想です。役職だけで選ぶと実務に明るくなく、若手だけでは部門内の調整力が不足します。複数部門のキーパーソンを集めた合同ワーキンググループを定期開催することで、要件の衝突を発注前に解消できます。

キーパーソンにはプロジェクト期間中、通常業務から一定の工数を確保することが必須です。専任化が難しい場合でも、週の20〜30%程度は刷新プロジェクトに割ける環境を整えます。ここを曖昧にすると、ベンダーから要件確認の依頼が来ても返答が滞り、プロジェクト全体の遅延につながります。

システム刷新は数千万円から数十億円規模の投資となるため、経営層の承認が不可欠です。稟議書には投資金額だけでなく、投資回収の根拠・リスク・実施しなかった場合の損失を明記します。特に「2025年の崖」で示された年間最大12兆円の経済損失など、公的資料を引用すると説得力が増します。

必須の記載項目は、現状システムの保守コスト推移・障害リスクの定量化・刷新による業務効率改善効果・競合他社の動向の4点です。金額面では初期費用だけでなく、5〜10年のTCO（総所有コスト）で比較することが重要です。初期費用は安くても運用コストが高いシステムは、中長期で見ると割高になります。

稟議書の最後には、必ず「やらないリスク」を数値化して記載します。基幹システムのハードウェア保守切れ、技術者の退職、法改正対応の不可といった事象が発生した場合の損失金額を試算します。経営層は「投資」よりも「損失回避」の方が意思決定しやすい傾向があるため、この観点は承認獲得に効果的です。

RFP（提案依頼書）の作り方と発注先の種類

RFP（Request For Proposal：提案依頼書）は、ベンダーから質の高い提案を引き出すための最重要ドキュメントです。RFPの完成度が低いと、ベンダーは保守的な見積りや曖昧な提案しかできず、結果としてプロジェクト後半で大幅な追加費用や遅延が発生します。複数ベンダーを同じ土俵で比較するためにも、RFPの綿密な作成は必須プロセスです。

また、発注先ベンダーの種類によって得意領域や価格帯、サポート体制が大きく異なります。自社の課題に適したベンダーを選定するには、それぞれの特徴を理解したうえでRFPの送付先を絞り込む必要があります。ここではRFPの記載項目とベンダー5分類について解説します。

RFPに必須の項目は、プロジェクト概要・現行システム情報・要件（機能・非機能）・スケジュール・予算感・評価基準・提出書類一覧の7項目です。現行システム情報では、ハードウェア構成・ソフトウェアバージョン・データ量・ユーザー数・連携システム一覧を具体的な数値で提示します。

要件記載の注意点は、「何をしたいか（What）」と「どのように実現するか（How）」を混同しないことです。Howを指定しすぎるとベンダーの提案自由度が狭まり、結果的に自社の想定内の提案しか集まりません。Whatを明確にしつつ、Howの選択肢はベンダーに委ねる書き方が理想です。

評価基準の開示も重要です。価格・技術力・実績・サポート体制・企業安定性のどれをどのくらいの比率で評価するかを事前に示すことで、ベンダーは自社の強みを提案書にどう反映させるか判断できます。評価基準を伏せて提案を受けると、ベンダーは全方位で書き込むことになり、かえって比較しづらい提案書が集まってしまいます。

SIer（システムインテグレーター）は大きく5つに分類されます。メーカー系は富士通・NEC・日立など自社ハード製品と紐づく提案が強みで、既存インフラとの親和性を求める案件に適しています。ユーザー系はNTTデータやSCSKなど親会社の業務システムを源流とし、金融・製造といった業界特化の深い知見を持ちます。

独立系は大塚商会・TISなど資本的に独立したSIerで、特定メーカー製品に縛られない柔軟な提案が可能です。コンサル系はアクセンチュア・アビームコンサルティングなど、経営戦略とIT実装を一体で提供します。外資系はIBM・Oracleなどグローバル標準の方法論を持ち込む一方で、日本独自業務への対応力は案件により差があります。

レガシーシステム刷新では、単一のベンダーではなく複数系統を組み合わせる発注も検討します。たとえばコンサル系にグランドデザインと上流設計を、独立系に開発実装を、ユーザー系に運用保守を担当させるマルチベンダー体制です。ただし責任分界点の設計を誤ると、トラブル時に各社が責任を押し付け合う事態になるため、プロジェクトマネジメント体制の設計を発注側が主導する必要があります。

ベンダー比較・選定プロセスの進め方

ベンダー選定は発注プロセスの天王山です。選定を誤ると、プロジェクト全体が頓挫するリスクがあります。選定プロセスでは、提案書の精読だけでなく、プレゼンテーション・質疑応答・リファレンスチェック・現場訪問などを複合的に組み合わせます。

多くの企業が陥る失敗パターンは、最安値ベンダーを選んで後悔することです。初期費用の安さだけで決めると、追加要件のたびに高額請求が発生したり、品質不足でやり直しコストが膨らんだりします。大手の実績を鵜呑みにするのも危険で、実績=自社案件の成功ではありません。ここでは選定プロセスの3つの要点を解説します。

ベンダー比較は最低3社、できれば5〜7社から提案を取得します。1社のみでは価格妥当性や提案品質の判断基準が持てず、2社では横並び比較の材料不足です。3社以上からの提案があって初めて、価格・技術・スケジュールの現実的な相場感が見えてきます。

評価基準は点数化して客観性を担保します。価格30点・技術力25点・実績20点・サポート体制15点・企業安定性10点といった配点例で、各項目をさらに小項目に分解して評価します。評価者も情報システム部門だけでなく、業務部門・経営企画・法務・情報セキュリティなどの複数部門から選出し、多角的な視点で採点します。

同業種・同規模の導入実績確認は必須項目です。たとえば自社が従業員500名の製造業なら、同規模の製造業での刷新実績を持つベンダーを優先します。業種や規模が違うと業務プロセスやシステム要件が大きく異なるため、実績が直接参考にならないケースが多いためです。

リファレンスチェックとは、ベンダーが過去に支援したクライアント企業に直接連絡し、プロジェクトの実情を確認する手法です。日本ではまだ一般的ではありませんが、海外では当たり前に実施される調査手法で、書面上の実績だけでは見えないベンダーの実力を把握できます。

実施手順は、まずベンダーに過去プロジェクトの参照先を3〜5社紹介してもらいます。ただし紹介されるのは成功事例ばかりなので、業界ネットワークや自社人脈経由で、紹介されていないクライアントにも直接連絡します。質問項目は「納期の遵守状況」「追加費用の発生頻度」「トラブル時の対応品質」「担当者の質」などを具体的に聞き取ります。

ある金融機関では、有力候補ベンダーのリファレンスチェックを独自に実施した結果、過去案件で大幅な納期遅延があった事実が判明しました。ベンダーの提案書には一切記載がなかった情報で、この発見により選定から外し、別ベンダーを採用することで炎上リスクを回避できたのです。手間はかかりますが、数千万円規模の投資を守るには費用対効果の高い調査手法といえます。

キングジムの10億円規模の基幹システム刷新プロジェクトは、ベンダー選定の教科書的事例として知られています。複数ベンダーの見積りの中で最高額だったJQ社（仮称）を最終的に選定した逆転劇は、価格ではなく「成功確度」で選ぶ重要性を示しています。

JQ社の提案が評価された理由は、旧システムの全構成を徹底的に洗い出し、移行リスクを一つひとつ潰す緻密な計画だった点です。他社が「標準的な移行手順」を提示する中、JQ社は「キングジム固有の業務プロセスをどう継承し、どこを変革するか」を具体的に提案しました。最高額という価格は、この緻密さを実現するための当然の工数見積りだったのです。

この事例から学べるのは、「プロジェクト失敗のコスト」を正しく評価軸に組み込むことの重要性です。最安値ベンダーを選んで炎上すれば、追加費用・機会損失・業務停止損害を含めて最高額の数倍のコストが発生します。成功確度の高い提案を適正価格で選ぶ方が、結果的にトータルコストを抑える選択となります。

契約締結のチェックリスト

契約書はプロジェクト成功の最後の砦です。口約束や曖昧な合意は、トラブル発生時に必ず紛争の火種となります。レガシーシステム刷新のような大規模・長期プロジェクトでは、契約段階で想定しうるリスクを可能な限り文書化しておく必要があります。

NHKと日本IBMの訴訟（2025年2月）やスルガ銀行とIBMの訴訟（最終的に95億円の発注側支払い白紙撤回、IBM側に42億円の賠償命令）は、契約条件の重要性を示す象徴的な事例です。いずれもプロジェクト炎上後に契約解釈をめぐって数年にわたる法廷闘争となりました。こうした事態を避けるために、契約段階で押さえるべき3つのポイントを解説します。

システム開発の契約形態は、主に「請負契約」と「準委任契約」の2種類です。請負契約は成果物の完成を約束する契約で、ベンダーは仕様どおりのシステムを納品する義務を負います。準委任契約は業務遂行を約束する契約で、ベンダーは善管注意義務のもとで作業を行いますが、成果物の完成責任は負いません。

要件が明確で仕様変更が少ないフェーズ（設計・製造・テスト）は請負契約が適しています。一方、要件が流動的で発注側と共同で進めるフェーズ（要件定義・コンサルティング・運用保守）は準委任契約が適しています。レガシーシステム刷新では、フェーズごとに契約形態を使い分ける「多段階契約」が実務上の定石です。

契約形態の選択を誤ると、リスクが一方に偏ります。本来準委任が適切なフェーズに請負契約を結ぶと、ベンダーは見積り時に不確実性リスクを上乗せして高額化します。逆に請負が適切なフェーズに準委任契約を結ぶと、ベンダーに完成責任がないため品質確保が発注側の責任になります。

SLA（Service Level Agreement）では、稼働率・応答時間・障害対応時間などの品質基準を数値で明記します。「24時間365日対応」と書いても、具体的な応答時間（1次応答○分以内・復旧○時間以内）を定めなければ意味がありません。SLA未達時のペナルティ（利用料減額など）も契約書に盛り込みます。

瑕疵担保責任（契約不適合責任）は、納品後に発覚した不具合の修補期間と範囲を規定します。民法改正（2020年）により「契約不適合責任」に呼称変更され、期間は1年が原則ですが、交渉により延長可能です。重大な不具合は発注者が追加修補を無償で請求できる範囲を明確化しておきましょう。

損害賠償上限の交渉は、発注側とベンダー側で利害が最も対立する条項です。ベンダーは契約金額を上限としたがりますが、業務停止や逸失利益を考えれば契約金額では到底カバーできません。現実的な落としどころは「契約金額の1〜2倍」「ベンダーの故意・重過失がある場合は上限撤廃」といった条件で、発注側は最低でも後者を確保する交渉が重要です。

スルガ銀行と日本IBMの訴訟は、国内SI業界で最も有名な炎上事例です。約95億円の発注後にプロジェクトが頓挫し、スルガ銀行の支払義務は白紙撤回、さらにIBM側に約42億円の損害賠償が命じられました。判決では「IBMがプロジェクト全体をコントロールすべき専門家責任（プロジェクトマネジメント義務）を怠った」と認定されました。

NHKと日本IBMの訴訟（2025年2月）でも同様の論点が争われ、発注側が適切に要件を提示しないことの責任と、ベンダー側のプロジェクトマネジメント義務のバランスが問われています。これらの判例は、契約書に「ベンダー側のプロジェクトマネジメント義務」を明示することの重要性を示しています。

契約書に盛り込むべき具体的条項は、「ベンダーはプロジェクト全体の進捗管理・リスク管理の責任を負う」「発注者に対し適時のリスク報告義務を負う」「仕様変更があった場合の影響評価と提案義務を負う」の3点です。これらを明記することで、炎上時の責任分界が明確になり、万一訴訟になった場合も判例に沿った主張が可能になります。

発注後のプロジェクト管理と現場定着

契約締結はゴールではなく、プロジェクトのスタート地点です。発注後の管理を怠ると、予算超過・納期遅延・品質不足のいずれかが必ず発生します。発注側はベンダー任せにせず、プロジェクトの共同責任者として主体的に関与する姿勢が求められます。

また、システムが完成しても現場に定着しなければ投資は無駄になります。レガシーシステム刷新では、長年使い慣れたシステムから新システムへの移行に対する現場抵抗が必ず発生します。技術的な構築と並行して、人的・組織的な変革をマネジメントすることがプロジェクト成功の条件です。

チェンジマネジメントとは、組織変革を計画的に推進する一連の手法です。新システム導入時には「チェンジモンスター」と呼ばれる抵抗勢力が必ず現れます。長年の業務習慣を変えたくない、新しい操作を覚えたくない、といった感情的な反発が、実務レベルではシステム活用を阻害します。

対応の基本は「スポンサーロードマップ」の構築です。経営層から現場管理職まで、変革のスポンサー（推進役）を階層的に配置し、それぞれのレベルで変革メッセージを発信します。トップダウンだけでは現場に届かず、現場だけでは経営インパクトが出ないため、両方向からの推進が必須です。

具体的な施策は、変革ビジョンの共有・キーマン育成・教育研修・コミュニケーション計画・成功事例の早期創出です。特に「早期の小さな成功」を現場に示すことで、変革への信頼感が醸成されます。最初の3ヶ月で誰か1人でも「新システムは便利だ」と言える状況を作れるかが、定着の分岐点となります。

デジタルデバイド（ITリテラシー格差）は、レガシーシステム刷新で特に顕在化する問題です。長年緑色の画面で漢字変換なしの操作に慣れた従業員が、いきなりWebブラウザベースの新UIに切り替わると、操作ミスや作業効率の大幅低下を引き起こします。高齢従業員の多い職場では、この問題が業務停止につながることすらあります。

具体的な対応策は、UI/UXを段階的に刷新することです。たとえば最初のフェーズでは旧画面の配色・キー操作を踏襲し、機能だけを新システムに載せ替えます。慣れが進んだ次のフェーズで現代的なUIに切り替えるという2段階アプローチで、現場の学習負荷を分散できます。

紙の帳票との併用期間を設けることも有効です。新システム稼働直後は、紙の帳票でのバックアップ運用を許容し、徐々に電子化率を高めていきます。完全電子化を急ぐと現場が混乱し、かえって業務品質が低下します。システムの理論的完成度と、現場の実運用定着度は別物として計画する必要があります。

レガシーシステムから新システムへの切替は、ビッグバン方式（一斉切替）と段階的移行方式の2つに大別されます。ビッグバン方式は工数が少ない反面、切替失敗時の影響が甚大で、業務全停止のリスクがあります。段階的移行は工数がかかるものの、問題発生時の影響を局所化できるため、大規模システム刷新では段階的移行が原則です。

段階的移行の具体的手法として、並行稼働（パラレルラン）があります。新旧システムを一定期間同時稼働させ、同じ入力に対して同じ結果が出ることを確認しながら、徐々に業務を新システムに寄せていきます。並行稼働期間は業務の重要度により1ヶ月〜6ヶ月程度が目安です。

並行稼働中は現場の負担が倍増するため、繁忙期を避けた計画が必須です。また、新旧システム間のデータ整合性チェックを自動化しておくと、差異検出の工数を大幅に削減できます。切替判断は「3日連続で整合性100%」などの客観基準を設定し、感覚的な判断を排除します。

プロジェクト炎上時の撤退戦略

多くの記事が「成功のためのノウハウ」を語る一方、「失敗時にどう撤退するか」を扱う情報は極めて少ないのが実情です。しかし実際のプロジェクトでは、炎上や頓挫のリスクを完全にゼロにはできません。撤退判断を遅らせると損失が膨らむだけでなく、発注側の経営責任問題にも発展します。

撤退は後ろ向きの判断ではなく、損失を最小化する合理的な経営判断です。発注前から撤退条件を想定しておき、契約書にも撤退時の手続きを盛り込んでおくことで、いざという時の意思決定を迅速化できます。ここでは撤退判断と実務手続きの2つの観点を解説します。

サンクコスト（埋没費用）とは、すでに支出して回収不能な費用です。炎上プロジェクトでは「ここまで投資したから引き返せない」というサンクコストバイアスが意思決定を歪めます。しかし経営判断において考慮すべきは、これから発生する追加投資とその見返りのみです。

撤退判断の客観基準として、以下の3つのチェックポイントを設定します。第1に、残工数の見積りが当初の3倍を超えた場合。第2に、要件の根本的変更が必要と判明した場合。第3に、ベンダーのキーパーソンが離脱し代替が困難な場合。これらのいずれかに該当したら、継続か撤退かを経営層で再判断します。

撤退判断を下す際には、外部の第三者専門家によるアセスメントを受けることを推奨します。社内関係者だけで判断すると、プロジェクト責任者の保身や心理的コミットメントが判断を歪めます。外部視点で残工数・追加投資・成功確率を冷静に評価することで、合理的な撤退判断が可能になります。

契約解除の手続きは、契約形態により大きく異なります。請負契約の場合、発注者は完成前であればいつでも解除できますが、ベンダーに対して損害賠償義務を負います（民法641条）。ただし、ベンダー側の債務不履行（納期遅延・仕様不適合）がある場合は、損害賠償なしで解除可能です。

準委任契約の場合、双方がいつでも解除可能です（民法651条）。ただし、相手方にとって不利な時期に解除する場合は損害賠償義務が生じます。いずれの契約形態でも、解除の意思表示は書面で行い、解除理由・解除日・最終精算金額を明記します。

責任分解においては、「どこまでの成果物を受領するか」「未払い金の精算方法」「知的財産権の帰属」「機密情報の返還・破棄」の4点を明確にします。特に知的財産権は、既に支払った費用に対応する成果物について発注側が利用できる権利を確保することが重要です。曖昧にしておくと、撤退後に別ベンダーで仕切り直す際にも障害となります。

まとめ

レガシーシステム刷新の発注は、社内準備・RFP作成・ベンダー選定・契約・プロジェクト管理・撤退戦略までを一体のプロセスとして設計することが成功の鍵です。発注前のAs-Is/To-Be分析とキーパーソン選出、RFPの質、最低3社比較とリファレンスチェック、契約条項の交渉、発注後のチェンジマネジメント――どれかを手抜きすると必ずプロジェクト後半で代償を払うことになります。

キングジムの10億円プロジェクトが最高額のベンダーを選んで成功した事例、スルガ銀行が95億円支払いを白紙撤回できた事例、いずれも契約・選定段階の判断がプロジェクト全体の運命を決めています。発注は単なる「業者選び」ではなく、経営リスクマネジメントそのものです。

発注後も主体的な関与を続け、炎上の兆候があれば速やかに撤退判断を検討する姿勢が求められます。サンクコストに縛られず、合理的な経営判断を下せる体制を発注前から整えておくことが、結果的に最大の投資保護につながります。本記事で紹介したチェックポイントを、自社の発注プロセス設計にお役立てください。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また「Boxシリーズ」による、受発注管理・在庫管理・配送管理・業務システム・生成AI・SaaS・マッチングサイト・EC・アプリ・LINEミニアプリなどの標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」を活用することで、低コスト・短期間でのスクラッチ開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。