レガシーシステム刷新の発注は、社内準備から始まり、RFP（提案依頼書）の作成、ベンダー比較、契約へと進みます。契約のあとも、発注後の管理と撤退の判断が続きます。
刷新は経営戦略そのもので、発注方法を誤ると数億円規模の投資が無駄になり、基幹業務が止まるおそれもあります。全体像はシステム刷新完全ガイドもあわせてご参照ください。
▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
レガシーシステム刷新を発注する前にやるべき社内準備
レガシーシステム刷新の成否は、発注前の社内準備で7割が決まるといっても過言ではありません。ベンダーに任せきりにして失敗するケースの多くは、現行システムの実態把握と社内の合意形成が不十分なまま発注してしまうパターンです。
RFPを書き始める前に、自社のシステム現状、業務課題、到達目標を言葉にして整理しておく必要があります。また、レガシーシステムには属人化した業務ノウハウが埋め込まれており、それを見える形にしないまま発注すると、ベンダーも正確な見積りを出せません。
社内準備に時間をかけることが、結果的に発注後のトラブルとコスト超過を防ぐ近道です。なかでも押さえたいのは、現行システムの把握、社内の調整役の選出、予算の確保です。
現行システムの棚卸しとAs-Is/To-Be分析
まず着手すべきは、現行システムの棚卸しです。多くの企業では、担当者の異動や退職が重なり、システム全体を把握している人が誰もいないという事態に陥っています。だからこそ、この作業は後回しにせず先に行うべきです。
棚卸しでは、どのサーバーでどのアプリケーションが動き、どのデータベースとつながっているのかを、インタフェース、バッチ処理、外部システムとの接続まで漏れなく洗い出します。そのうえで、現状と目指す姿を比べます。
- As-Is（現状）分析：機能や性能、運用コストなどを数字で捉え、障害履歴や改修頻度も同じように数字にして把握する
- To-Be（目指す姿）分析：刷新後にどの業務をどう変えたいのかを、業務フローごとに描く
この2つのギャップこそが、ベンダーへの発注要件そのものになります。
分析では、ソースコードの静的解析ツールを使うこともあります。外部ツールで構造を見える形にすると、ブラックボックス化したロジックも明らかになります。発注前の段階でここまで踏み込めるかどうかで、ベンダーの提案精度は大きく変わります。
社内の「システムキーパーソン」選出と部門間調整
レガシーシステム刷新は、全社にまたがるプロジェクトです。情報システム部門だけで進めると、現場部門から「聞いていなかった」「業務に合わない」といった反発が必ず起こります。
そこで有効なのが、「システムキーパーソン」の仕組みです。ある食品加工工場では、各部署から1名ずつキーパーソンを選び、部門間の利害を調整する仕組みを作りました。
- 人選：業務知識が深く、部署内で発言力のある中堅層が理想。役職だけで選ぶと実務に明るくない人が入り、若手だけでは調整力が足りない
- 合同の会議：複数部門のキーパーソンを集めた合同ワーキンググループを定期的に開き、要件の衝突を発注前に解消する
- 工数の確保：プロジェクト期間中に通常業務から一定の工数を確保する。専任が難しい場合でも、週の20〜30%程度は刷新に割ける時間を用意する
これを曖昧にすると、ベンダーからの要件確認に返答が滞り、プロジェクト全体の遅延につながります。
予算確保のための稟議書に盛り込むべき情報
システム刷新は数千万円から数十億円規模の投資になるため、経営層の承認が欠かせません。稟議書には、投資金額に加えて、投資回収の根拠、リスク、実施しなかった場合の損失を明記します。
稟議書に必ず載せる項目は、現状システムの保守コストの推移と、障害リスクの定量化です。加えて、刷新による業務効率の改善効果と、競合他社の動向も示します。
たとえば「2025年の崖」で示された年間最大12兆円の経済損失のように、公的資料を引用すると説得力が増します。
- TCO：金額は初期費用だけでなく、5〜10年のTCO（総所有コスト）で比べる。初期費用が安くても運用コストが高いシステムは、中長期で見ると割高になる
- やらないリスク：ハードウェア保守切れ、技術者の退職、法改正への対応不可といった事象が起きた場合の損失額を試算し、稟議書の最後に数値で載せる
経営層は「投資」より「損失回避」の方が意思決定しやすい傾向があるため、この観点は承認を得るうえで効果的です。
RFP（提案依頼書）の作り方と発注先の種類
RFP（Request For Proposal：提案依頼書）は、ベンダーから質の高い提案を引き出すための最も重要な文書です。RFPの完成度が低いと、ベンダーは保守的な見積りや曖昧な提案しか出せません。その結果、プロジェクト後半で大幅な追加費用や遅延が発生します。
複数のベンダーを同じ条件で比べるためにも、RFPの綿密な作成は欠かせない工程です。発注先は、種類によって得意領域や価格帯、サポート体制が大きく異なります。そのため、自社の課題に合うベンダーを選ぶには、それぞれの特徴を理解したうえでRFPの送付先を絞り込む必要があります。
RFPに記載すべき項目と書き方のポイント
RFPに必須の項目は7つあります。前半は、プロジェクト概要、現行システム情報、要件（機能・非機能）、スケジュールです。後半は、予算感、評価基準、提出書類一覧です。
- 現行システム情報：ハードウェア構成とソフトウェアのバージョンを具体的な数値で示し、データ量、ユーザー数、連携システムの一覧も添える
- 要件：What（何をしたいか）は明確に、How（どう実現するか）はベンダーに委ねる。Howを縛りすぎると、想定内の提案しか集まらない
評価基準の開示も欠かせません。価格や技術力、実績などの評価項目について、どのくらいの比率で評価するかを事前に示すと、ベンダーは自社の強みを提案書のどこに反映させるかを判断できます。評価基準を伏せて提案を受けると、ベンダーは全方位で書き込むことになり、かえって比べにくい提案書が集まります。
発注先の種類（メーカー系・ユーザー系・独立系・コンサル系・外資系）
SIer（システムインテグレーター）は、大きく5つに分類されます。
- メーカー系：富士通、NEC、日立など。自社のハード製品と結びついた提案が強みで、既存インフラとの親和性を求める案件に適する
- ユーザー系：NTTデータやSCSKなど。親会社の業務システムを源流に持ち、金融や製造といった業界に特化した深い知見がある
- 独立系：大塚商会やTISなど。資本的に独立したSIerで、特定のメーカー製品に縛られない柔軟な提案ができる
- コンサル系：アクセンチュアやアビームコンサルティングなど。経営戦略とIT実装を一体で提供する
- 外資系：IBMやOracleなど。グローバル標準の方法論を持ち込むが、日本独自の業務への対応力は案件によって差がある
レガシーシステム刷新では、単一のベンダーに頼らず、複数系統を組み合わせて発注することも検討します。たとえば、コンサル系にグランドデザインと上流設計を、独立系に開発実装を、ユーザー系に運用保守を担当させる、マルチベンダー体制です。
ただし、責任分界点の設計を誤ると、トラブル時に各社が責任を押し付け合う事態になります。そのため、プロジェクトマネジメント体制の設計は、発注側が主導する必要があります。
ベンダー比較・選定プロセスの進め方
ベンダー選定は発注プロセスの山場です。選定を誤ると、プロジェクト全体が頓挫するリスクがあります。
選定では、提案書を読み込むだけでなく、プレゼンテーションや質疑応答を組み合わせます。さらに、リファレンスチェックや現場訪問も行い、複数の方法で見極めます。
多くの企業が陥る失敗は、最安値のベンダーを選んで後悔することです。初期費用の安さだけで決めると、追加要件が出るたびに高額な請求が発生したり、品質不足でやり直しの費用が膨らんだりします。また、大手の実績を鵜呑みにするのも危険で、実績は自社案件の成功とイコールではありません。
最低3社からの提案取得と評価基準の設定
ベンダー比較は、最低3社、できれば5〜7社から提案を取ります。1社だけでは価格の妥当性や提案の品質を判断できず、2社では横並びで比べる材料が足りません。3社以上の提案がそろって初めて、価格や技術、スケジュールの現実的な相場感が見えてきます。
評価基準は点数化して、客観性を保ちます。たとえば、配点は次の5項目に割り振ります。
- 価格：30点
- 技術力：25点
- 実績：20点
- サポート体制：15点
- 企業の安定性：10点
各項目は、さらに小項目に分けて評価します。評価者も、情報システム部門だけでなく、業務部門や経営企画などの複数部門から選びます。法務や情報セキュリティの担当も加えると、多角的な視点で採点できます。
同業種・同規模の導入実績の確認は必須です。たとえば、従業員500名の製造業であれば、同規模の製造業で刷新した実績を持つベンダーを優先します。
業種や規模が違うと、業務プロセスもシステム要件も大きく異なります。そのため、違う業種や規模の実績は、直接の参考にならないケースが多くあります。
リファレンスチェック（過去クライアント直接確認）の実施手順
リファレンスチェックとは、ベンダーが過去に支援したクライアント企業に直接連絡して、プロジェクトの実情を確かめる手法です。日本ではまだ一般的ではありませんが、海外では当たり前の調査手法です。書面の実績だけでは見えないベンダーの実力も、ここで把握できます。
実施では、まずベンダーに過去プロジェクトの参照先を3〜5社紹介してもらいます。ただし、紹介されるのは成功事例ばかりなので、業界のネットワークや自社の人脈を通じて、紹介されていないクライアントにも直接連絡します。
質問は、納期とトラブル時の対応の2つの面で行います。
- 納期：遵守状況や追加費用の発生頻度を具体的に聞き取る
- トラブル時：対応の品質や担当者の質について尋ねる
ある金融機関では、有力候補ベンダーのリファレンスチェックを独自に実施しました。その結果、過去案件で大幅な納期遅延があったという事実が判明しました。
その情報は、ベンダーの提案書には一切記載がなかったものです。この発見により、そのベンダーを選定から外し、別のベンダーを採用したことで、炎上リスクを回避できました。手間はかかりますが、数千万円規模の投資を守るには費用対効果の高い調査手法といえます。
キングジム事例に学ぶ「最安値ではなく成功への道筋」での選び方
キングジムの10億円規模の基幹システム刷新は、ベンダー選定の教科書的な事例として知られています。複数のベンダーの見積りのうち最高額だったJQ社（仮称）が、最終的に選ばれました。この逆転は、価格より「成功確度」で選ぶことの大切さを示しています。
JQ社の提案が評価された理由は、旧システムの全構成を徹底的に洗い出し、移行リスクを一つひとつ潰す緻密な計画だった点です。
- 他社の提案：「標準的な移行手順」を示す
- JQ社の提案：「キングジム固有の業務プロセスをどう継承し、どこを変革するか」を具体的に示す
最高額の価格は、この緻密さを実現するための当然の工数見積りでした。この事例から学べるのは、「プロジェクト失敗のコスト」を正しく評価軸に組み込むことの大切さです。
最安値のベンダーを選んで炎上すれば、追加費用や機会損失、業務停止による損害まで含めると、最高額の数倍のコストが発生します。そのため、成功確度の高い提案を適正な価格で選ぶほうが、結果的にトータルコストを抑える選択になります。
契約締結のチェックリスト
契約書は、トラブルが起きたときに頼る最後の根拠です。口約束や曖昧な合意は、そのときに必ず紛争の火種となります。
レガシーシステム刷新のような大規模で長期のプロジェクトでは、契約の段階で想定できるリスクを、できるだけ文書にしておく必要があります。たとえば、NHKと日本IBMの訴訟（2025年2月）やスルガ銀行とIBMの訴訟（最終的に95億円の発注側支払い白紙撤回、IBM側に42億円の賠償命令）は、契約条件の重要性を示す象徴的な事例です。
いずれも、炎上後に契約の解釈をめぐって数年の法廷闘争へと発展しました。こうした事態を避けるために、契約の段階で押さえるべき3つのポイントを整理します。
請負契約と準委任契約の選択基準
システム開発の契約形態は、主に「請負契約」と「準委任契約」の2種類です。
- 請負契約：成果物の完成を約束する契約で、ベンダーは仕様どおりのシステムを納品する義務を負う
- 準委任契約：業務の遂行を約束する契約で、ベンダーは善管注意義務のもとで作業する。成果物の完成責任は負わない
レガシーシステム刷新では、フェーズごとに契約形態を使い分ける「多段階契約」が実務上の定石です。
- 設計、製造、テスト：要件が明確で仕様変更が少なく、請負契約が適する
- 要件定義、コンサルティング、運用保守：要件が流動的で、発注側と共同で進める。準委任契約が適する
契約形態を誤ると、リスクが一方に偏ります。本来は準委任が適切なフェーズに請負契約を結ぶと、ベンダーは見積りの時点で不確実性のリスクを上乗せし、結果として高額になります。逆に、請負が適切なフェーズに準委任契約を結ぶと、ベンダーに完成責任がないため、品質の確保が発注側の責任になります。
SLA・瑕疵担保・損害賠償上限の交渉ポイント
SLA（Service Level Agreement）では、稼働率、応答時間、障害対応時間などの品質基準を数値で明記します。「24時間365日対応」と書くだけでは意味がなく、具体的な応答時間（1次応答○分以内・復旧○時間以内）を定める必要があります。SLA未達時のペナルティ（利用料減額など）も、契約書に盛り込みます。
瑕疵担保責任（契約不適合責任）は、納品後に発覚した不具合について、修補の期間と範囲を規定するものです。民法改正（2020年）で呼び方が変わり、期間は1年が原則ですが、交渉で延長することもできます。重大な不具合については、発注者が追加の修補を無償で請求できる範囲を明確にしておきましょう。
損害賠償上限の交渉は、発注側とベンダー側で利害が最も対立する条項です。ベンダーは契約金額を上限にしたがりますが、業務停止や逸失利益を考えると、契約金額では到底カバーできません。現実的な落としどころとして挙がるのは、2つの条件です。
- 契約金額の1〜2倍：上限として設定する
- 故意・重過失：ベンダーに故意・重過失がある場合は、上限を撤廃する
発注側は、少なくとも後者の条件を確保する交渉が大切です。
スルガ銀行・NHK訴訟から学ぶ契約リスク
スルガ銀行と日本IBMの訴訟は、国内SI業界で最も知られた炎上事例です。約95億円で発注されたプロジェクトが頓挫し、スルガ銀行の支払義務は白紙撤回、さらにIBM側に約42億円の損害賠償が命じられました。
判決では、「IBMがプロジェクト全体をコントロールすべき専門家責任（プロジェクトマネジメント義務）を怠った」と認定されました。NHKと日本IBMの訴訟（2025年2月）でも、同様の論点が争われています。発注側が要件を適切に提示しないことの責任と、ベンダー側のプロジェクトマネジメント義務のバランスが問われています。
これらの判例は、契約書に「ベンダー側のプロジェクトマネジメント義務」を明示することの大切さを示しています。契約書に盛り込むべき具体的な条項は、3点あります。
- 進捗とリスクの管理：ベンダーがプロジェクト全体の進捗管理とリスク管理に責任を負う
- リスクの報告：発注者に対して、適時のリスク報告を行う
- 仕様変更への対応：仕様変更があった場合に、影響を評価して提案する
これらを明記すると、炎上時の責任分界が明確になり、万一訴訟になった場合も判例に沿った主張ができます。
発注後のプロジェクト管理と現場定着
契約締結はゴールではなく、プロジェクトの出発点です。発注後の管理を怠ると、予算超過、納期遅延、品質不足のどれかが必ず発生します。そのため、発注側はベンダー任せにせず、プロジェクトの共同責任者として主体的に関わる必要があります。
また、システムが完成しても、現場に定着しなければ投資は無駄になります。レガシーシステム刷新では、長年使い慣れたシステムから新しいシステムへの移行に対して、現場の抵抗が必ず生じます。したがって、技術的な構築と並行して、人と組織の変革をマネジメントすることが、プロジェクト成功の条件です。
チェンジマネジメントの実施方法
チェンジマネジメントとは、組織の変革を計画的に進めるための一連の手法です。新システムを導入すると、「チェンジモンスター」と呼ばれる抵抗勢力が必ず現れます。長年の業務習慣を変えたくない、新しい操作を覚えたくないといった感情的な反発が、実務レベルでシステムの活用を妨げます。
対応の基本は、「スポンサーロードマップ」を作ることです。経営層から現場の管理職まで、変革のスポンサー（推進役）を階層的に置き、それぞれのレベルで変革のメッセージを発信します。
トップダウンだけでは現場に届かず、現場だけでは経営へのインパクトが出にくいため、両方向からの推進が必須です。
- 施策の柱：変革ビジョンの共有、キーマンの育成、教育研修
- 施策の補強：コミュニケーション計画と成功事例の早期創出も欠かせない
- 小さな成功：特に「早期の小さな成功」を現場に示すと、変革への信頼感が育つ
- 定着の分かれ目：最初の3ヶ月で、誰か1人でも「新システムは便利だ」と言える状況を作れるかどうか
デジタルデバイドへの具体的対応
デジタルデバイド（ITリテラシーの格差）は、レガシーシステム刷新で特に表面化しやすい問題です。長年、緑色の画面で漢字変換なしの操作に慣れた従業員が、いきなりWebブラウザベースの新しい画面に切り替わると、操作ミスや作業効率の大幅な低下が起こります。中でも、高齢の従業員が多い職場では、この問題が業務停止につながることもあります。
具体的な対応策は、UI/UXを段階的に刷新することです。
- 第1段階：旧画面の配色やキー操作を踏襲し、機能だけを新システムに載せ替える
- 第2段階：慣れが進んだ次のフェーズで、現代的なUIに切り替える。この2段階により、現場の学習負荷を分散できる
紙の帳票との併用期間を設けることも有効です。新システムの稼働直後は、紙の帳票によるバックアップ運用を認め、徐々に電子化率を高めていきます。完全電子化を急ぐと、現場が混乱し、かえって業務品質が下がります。
システムの理論的な完成度と、現場の実運用の定着度は、別物として計画する必要があります。
段階的移行と並行稼働によるリスク最小化
レガシーシステムから新システムへの切り替えは、ビッグバン方式（一斉切り替え）と段階的移行方式の2つに大別されます。
- ビッグバン方式（一斉切り替え）：工数は少ない反面、切り替えに失敗したときの影響が大きく、業務全体が止まるおそれがある
- 段階的移行方式：工数はかかるが、問題が起きたときの影響を局所化できる
大規模なシステム刷新では、段階的移行が原則です。
段階的移行の具体的な手法には、並行稼働（パラレルラン）があります。新旧のシステムを一定期間同時に動かし、同じ入力に対して同じ結果が出ることを確かめながら、業務を少しずつ新システムへ移していきます。並行稼働の期間は、業務の重要度により1ヶ月〜6ヶ月程度が目安です。
並行稼働中は現場の負担が倍増するため、繁忙期を避けた計画が欠かせません。また、新旧システム間のデータ整合性チェックを自動化しておくと、差異の検出にかかる工数を大幅に減らせます。切り替えの判断は、「3日連続で整合性100%」といった客観的な基準を設けて、感覚的な判断を避けます。
プロジェクト炎上時の撤退戦略
成功のためのノウハウを語る記事は多い一方で、失敗したときにどう撤退するかを扱う情報は極めて少ないのが実情です。とはいえ、実際のプロジェクトでは、炎上や頓挫のリスクを完全にゼロにはできません。
撤退の判断を遅らせると、損失が膨らむだけでなく、発注側の経営責任の問題にも発展します。撤退は、損失を最小限に抑える合理的な経営判断です。そこで、発注前から撤退の条件を想定しておき、契約書にも撤退時の手続きを盛り込んでおくと、いざというときの意思決定を速められます。
サンクコストをいつ切り捨てるかの判断基準
サンクコスト（埋没費用）とは、すでに支出して回収できない費用のことです。炎上したプロジェクトでは、「ここまで投資したから引き返せない」というサンクコストバイアスが、意思決定を歪めます。しかし、経営判断で考えるべきなのは、これから発生する追加投資とその見返りだけです。
撤退を検討すべき状態は、残工数、要件、ベンダー体制の3つの面に表れます。
- 残工数の見積りが当初の3倍を超えたとき
- 要件の根本的な変更が必要だと分かったとき
- ベンダーのキーパーソンが離脱し、代替が難しいとき
残工数、要件、ベンダー体制のいずれかに当てはまったら、継続か撤退かを経営層で改めて判断します。
撤退の判断では、外部の第三者専門家によるアセスメントを受けることを推奨します。社内の関係者だけで判断すると、プロジェクト責任者の保身や心理的なこだわりが判断を歪めます。そこで、外部の視点で残工数や追加投資、成功確率を冷静に評価すると、合理的な撤退判断ができます。
契約解除の法務手続きと責任分解
契約解除の手続きは、契約形態によって大きく異なります。
- 請負契約：発注者は完成前であればいつでも解除できるが、ベンダーに損害賠償の義務を負う（民法641条）
- 準委任契約：双方がいつでも解除できる（民法651条）。相手方にとって不利な時期に解除すると、損害賠償の義務が生じる
ただし、請負契約では、ベンダー側の債務不履行（納期遅延や仕様不適合）があるときは、損害賠償なしで解除できます。いずれの契約形態でも、解除の意思表示は書面で行い、解除理由、解除日、最終精算金額を明記します。
責任分解では、どこまでの成果物を受け取るか、未払い金をどう精算するかを明確にします。加えて、知的財産権の帰属と、機密情報の返還・破棄も決めておきます。
特に知的財産権は、支払い済みの費用に対応する成果物について、発注側が利用できる権利を確保することが大切です。曖昧にしておくと、撤退後に別のベンダーで仕切り直す際にも支障になります。
まとめ
レガシーシステム刷新の発注は、社内準備から撤退戦略まで、一連の流れとして設計することが成功の鍵です。
社内準備では、As-Is/To-Be分析とキーパーソンの選出を進めます。RFPの質や最低3社の比較、リファレンスチェックも欠かせません。
そのうえで、契約条項の交渉と発注後のチェンジマネジメントに取り組みます。どれかを手抜きすると、必ずプロジェクト後半で代償を払うことになります。
キングジムの10億円プロジェクトは、最高額のベンダーを選んで成功した事例です。スルガ銀行が95億円の支払いを白紙撤回できた事例もあります。いずれも、契約と選定の段階の判断が、プロジェクト全体の運命を決めています。
発注は、業者を選ぶ作業にとどまらず、経営リスクを管理することそのものです。発注後も主体的に関わり続け、炎上の兆候があれば速やかに撤退を検討する姿勢が求められます。
サンクコストに縛られず、合理的な経営判断を下せる体制を発注前から作っておくことが、結果的に最大の投資保護につながります。本記事で紹介したチェックポイントを、自社の発注プロセスの設計に役立ててください。
▼全体ガイドの記事
・レガシーシステム刷新の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブックをご覧ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。