業務システムの刷新は、社内準備、RFP作成、ベンダー選定、契約、プロジェクト管理、現場定着の順に進めます。大型案件の破綻事例では、発注側の準備不足と契約上のリスク管理の甘さが共通の原因として指摘されています。
概要と費用は、業務システム刷新の完全ガイドもご覧ください。
本テーマに関する全体ガイドは、以下の記事をご覧ください。
▼全体ガイドの記事
・業務システム刷新の完全ガイド
レガシーシステム刷新を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
業務システム刷新を発注する前にやるべき社内準備
発注先のベンダーを探し始める前に、まず社内で行うべき準備があります。この段階を省略すると、後から要件の追加・変更が頻発し、コスト超過や納期延伸の原因となります。経済産業省の調査では、大規模ITプロジェクトの約3割が予算超過または大幅な納期遅延を経験しています。ベンダーに「良い提案」を出してもらうには、発注側が現状を把握し、目指すべき姿を言語化しておくことが欠かせません。
現行システムの棚卸しとAs-Is／To-Be分析
現行システムの棚卸しとは、今動いているシステムの構成・機能・データ・連携先を一覧にする作業です。「どのシステムが、どの業務を、どのデータを使って処理しているか」を一覧にしておくと、刷新の範囲を定めやすくなり、ベンダーへの説明もスムーズに進みます。
キングジムの基幹システム刷新（10億円規模）では、一度プロジェクトが頓挫した後の再選定で、最終的に選ばれたベンダーが提案の冒頭で「旧システムの構成を全部洗い出す」と明言し、高く評価されました。棚卸しを徹底することが、刷新成功の第一歩です。
棚卸しの後は、次の2つの分析で現状と目指す姿を整理します。
- As-Is（現状）分析：現行システムの課題、ボトルネック、技術的負債を洗い出します。
- To-Be（あるべき姿）分析：刷新後に実現したい業務フローと、期待する効果（処理時間の削減率、エラー率の低下、コスト削減額など）を数字で描きます。
2つを並べると、プロジェクトの優先度と投資対効果が経営層にも伝わり、予算確保の稟議も通りやすくなります。As-Is／To-Be分析には2〜4週間程度かかることが多く、各部門の業務担当者へのヒアリングで現場の実態を丁寧に拾い上げることが重要です。
社内の「システムキーパーソン」の選出と部門間調整
業務システム刷新は、複数の部署にまたがる大きなプロジェクトです。そのため、各部署から「システムキーパーソン」を一名以上選び、プロジェクトチームに参加させることが成功の鍵になります。キーパーソンには、業務に詳しいだけでなく、自部署の意見をまとめてチームに伝え、プロジェクトの進捗や決定事項を自部署に橋渡しできる人が理想的です。
ある食品加工工場の刷新では、長年の慣習で形骸化した不要なチェック業務がシステムに組み込まれたまま残っていました。各部署からキーパーソンを選んでワークショップを行ったところ、「この確認作業は今の業務フローでは意味がない」という声が上がり、刷新を機に廃止できました。
こうした業務改革は、現場のキーパーソンが積極的に関わってはじめて実現します。部門間の利害が対立する場面では、経営層のスポンサーシップが調整を円滑にします。そこで、プロジェクト開始前に経営陣の関与の度合いを確認し、担保しておくことも大切です。
予算確保のための稟議書に盛り込むべき情報
業務システム刷新の稟議書では、投資対効果（ROI）を具体的な数値で示すことが欠かせません。たとえば「月次決算処理の工数は現状40人日かかっているが、10人日に削減できる見込みで、年間換算で約900万円のコスト削減効果が期待できる」という形で定量化すると、経営層の判断を後押しできます。
現行システムを維持し続けた場合のリスク（セキュリティ脆弱性、保守サポート終了、障害時の影響範囲）も試算しておくと、「やらないことのコスト」が見え、投資の必然性を説明しやすくなります。
稟議書には、次の情報を盛り込むことが推奨されます。
- プロジェクト総費用：初期開発費、ライセンス費、移行費、教育費、運用費の5年間分です。
- 導入スケジュールの概要
- リスクと対応策
- ベンダー候補の概要
判断材料がそろうと、経営層も導入の可否を検討しやすくなります。
稟議を通すには、「なぜ今やるのか」「なぜこの金額が必要なのか」「リスクはどう管理するのか」の3点に、はっきり答えられる状態にしておくことが大切です。
RFP（提案依頼書）の作り方【実務テンプレート付き】
RFP（Request for Proposal：提案依頼書）は、発注者がベンダーに対して「こういうシステムを作ってほしい」という要求をまとめた文書です。RFPの質は、ベンダーから受け取る提案の質を直接左右します。曖昧なRFPには曖昧な提案しか返ってこず、後から「言った・言わない」のトラブルに発展するリスクが高まります。
RFPに記載すべき項目と書き方のポイント
RFPに盛り込むべき主要な項目は、先頭から順に次の10項目です。
- プロジェクト概要と背景
- 現行システムの概要と課題
- 刷新後に実現したい業務フローと機能要件
- 非機能要件（性能・セキュリティ・可用性・拡張性）
- 連携が必要な外部システム一覧
- プロジェクトスケジュールの希望
- 予算の目安または上限
- 提案に含めてほしい成果物の一覧
- 評価基準と選定フロー
- 質問受付期間と回答方法
書き方のポイントは、機能要件を「〜できること」の形で書き、解釈が分かれないよう曖昧な表現を避けることです。たとえば「処理が早いこと」ではなく、「ピーク時10,000件のトランザクションを1秒以内に処理できること」のように数値で定義します。
また、RFPが規定するのは「何を作るか」です。「どう作るか」という実装の詳細はベンダーの提案に任せると、より創造的で競争力のある提案を引き出しやすくなります。
現場ニーズと業務フローの反映方法
RFP作成で最も失敗しやすいのは、情報システム部門だけで作業を完結させてしまうことです。営業、経理、製造、物流など実際にシステムを使う現場部門のニーズが反映されないと、「動くが使われないシステム」ができあがります。スルガ銀行の次期勘定系システム開発（95億円）が最終的に白紙撤回された根本原因も、自社の業務要件に合わないパッケージをベースに開発を進めたことでした。
業務フローをRFPに反映させるには、As-Is業務フロー図を添付資料として作り、各業務ステップで現在どんな課題があるかを注記する方法が有効です。さらに、To-Be業務フロー図（理想像）も作ってRFPに含めると、ベンダーが「どんな変化を実現すればよいか」を理解しやすくなります。
業務フロー図の作成にはLucidchartやMiroなどのオンラインツールを使うと、現場担当者と情報システム部門が一緒に編集しやすくなります。
比較しやすい提案を引き出すためのRFP設計
複数のベンダーから受け取った提案を横並びで比べるには、提案書のフォーマットと盛り込む内容をRFPで指定しておくことが有効です。具体的には、「費用明細は初期費用・月次運用費・ライセンス費を分けて記載すること」「開発体制図と担当者の役割を明記すること」「類似案件の実績を3件以上記載すること」のように、回答の形式をそろえます。
回答の形式がそろえば、評価担当者は各社の提案を同じ基準で比較できます。その結果、「価格だけを見てしまう」という意思決定のゆがみを防ぎやすくなります。
ベンダー比較・選定プロセスの進め方
ベンダーの選定では、見積金額に加えて、技術力、プロジェクト管理能力、コミュニケーション力、業界知識を見る必要があります。複雑なシステム刷新では、これらが費用と同じかそれ以上に重要です。
キングジムの事例では、最も見積金額が高かったベンダーを最終的に選びました。その決め手は、現行システムの構成を徹底的に調べたうえで、現実的な移行計画を示す姿勢でした。
最低3社からの提案取得と評価基準の設定
業務システム刷新の発注では、必ず3社以上から提案を取ることを推奨します。1社だけだと価格の妥当性を判断できず、交渉力も生まれません。2社では比較の軸が少なく、1社を引き立たせるための「当て馬」になりかねません。3社以上あれば市場相場が見え、各社の強みと弱みも比べられます。
評価基準は、RFPを送る前に社内で合意しておくことが大切です。一般的な基準として、技術力と業界実績（30点）、プロジェクト管理能力と体制（25点）、提案の質と現行業務への理解度（20点）のように配点を設定します。
さらに、費用の妥当性と透明性（15点）、サポート体制と保守計画（10点）を加えます。評価委員が独立して採点し、後で集計する方式を取ると、客観性を保ちやすくなります。
提案内容の比較評価マトリクス
複数のベンダーの提案を評価するには、比較評価マトリクス（スコアカード）を使います。評価項目を縦軸、ベンダー名を横軸に並べた表を作り、各項目を5段階で評価したうえで、重み付きスコアを算出します。重み付けには、先ほどの配点を使います。
重要なのは、最終スコアだけで判断せず、なぜそのスコアになったかという定性的な考察も加えることです。また、数字に表れにくい「提案ヒアリング時の担当者の質問の深さ」「プロジェクト管理ツールの見せ方」「リスクへの向き合い方」も、プロジェクトの成否に大きく影響します。
リファレンスチェックの実施手順【独自テクニック】
最終候補が絞り込まれたら、ぜひ実施してほしいのが「リファレンスチェック（参照確認）」です。候補ベンダーの過去のクライアントに直接連絡を取り、実際のプロジェクト経験を聞き出す手法です。人材採用では一般的ですが、システム開発のベンダー選定でも非常に有効です。提案書や実績一覧だけでは見えない情報を確かめられるため、選定の精度を高めたい場合に取り入れる価値があります。
ある金融機関がこの手法を実施したところ、最終段階まで残っていた有力候補のベンダーが、過去の複数のプロジェクトで大幅な納期遅延を繰り返していたことがわかりました。ベンダー自身が出した実績一覧には載っていない情報を、元クライアントへの直接ヒアリングで明らかにできたのです。
進め方は、まずベンダーに「過去のクライアント企業の担当者の連絡先を2〜3名紹介してほしい」と依頼します。正当なベンダーであれば快く応じるはずで、拒否するベンダーはそれ自体が懸念材料です。ヒアリングでは、次の4点を必ず確認します。
- 納期どおりに完成したか
- コストは当初見積もりの範囲内に収まったか
- 担当者とのコミュニケーションはどうだったか
- もう一度同じベンダーを選ぶか
契約締結のチェックリストと炎上時の撤退戦略
ベンダーを選定したら、次は契約交渉に入ります。契約書の内容は、プロジェクトが順調なうちは意識されにくいものですが、トラブルが起きたときに初めて問われます。「後でよく読めばよい」と考えて押印してしまうのは、極めて危険です。
請負契約と準委任契約の選択基準
システム開発の契約形態には、大きく「請負契約」と「準委任契約」の2種類があります。
- 請負契約：「成果物の完成」を目的とし、ベンダーは仕様に沿ったシステムを完成させる義務（完成義務）を負います。
- 準委任契約：「業務の遂行」を目的とし、ベンダーは善良な管理者の注意義務をもって作業を進め、成果物の完成責任は持ちません。
請負契約の発注側には、「動くシステムが納品されるまで費用を払わなくてよい」という安心感があります。一方で、要件の変更には柔軟に対応しにくいという弱点もあります。要件が変わりやすいアジャイル開発では、準委任契約が向いています。
実務では、要件定義の段階は準委任契約で始め、要件が固まってから開発段階を請負契約に切り替える「段階的契約」が安全です。最近は、アジャイル開発に対応した混合型の契約も増えており、ベンダーとの交渉しだいで柔軟な形を組めます。
どちらの形態を選ぶ場合でも、「仕様変更の手続き方法」「追加費用の発生基準」「進捗報告の頻度と形式」を契約書に明記しておくことが、共通して重要です。
SLA（サービスレベル合意）の具体的な設定項目
SLA（Service Level Agreement）とは、システムの性能・可用性・サポート対応について、発注者とベンダーが合意した最低保証の水準を定めた合意書です。業務システム刷新では、本番稼働後の運用保守フェーズに入る前に、必ずSLAを締結しておく必要があります。
SLAの水準は、稼働率や障害対応の時間を数値や時間で書き込み、約束の中身を具体的にしておきます。設定の例を挙げると、次の項目になります。
- 稼働率：例として99.5%以上
- 計画外ダウンタイムの上限：例として月間2時間以内
- 障害発生時の初動対応時間：例として重大障害は30分以内に第一報
- バッチ処理の完了時間：例として夜間バッチは翌営業日7時までに完了
- データバックアップの頻度とリカバリ目標時間（RTO）
SLAで特に重要なのは、違反した場合のペナルティ条項を具体的に決めておくことです。「次月の保守費用の10%を減額する」「累積違反回数が3回を超えた場合は契約解除権が発生する」といった形で抑止力を契約上に担保しておくと、ベンダーのサービス品質を保つ動機になります。
ただし、ペナルティを過大に設定すると、優良なベンダーが敬遠するおそれがあります。そのため、業界標準的な水準を参考に設定することが大切です。
プロジェクト炎上時の「撤退戦略」と契約上の身の守り方【競合にない切り口】
見落とされやすい重要なテーマは、プロジェクトが炎上したときにどう撤退するかです。スルガ銀行と日本IBMの訴訟（総額95億円規模）のように、問題が深刻化してから法廷闘争に発展するケースも少なくありません。「サンクコスト（既に投じた費用）」への執着が撤退の判断を遅らせ、最終的な損害を大きくしてしまうのです。
撤退判断の目安としてよく使われるのは、次の3つのシグナルです。
- 当初の完成予定日から30%以上の遅延が発生し、回復の見通しが立たない場合
- 追加費用の累積額が当初見積もりの20%を超え、さらに増加が続いている場合
- 成果物の品質が要件から著しく乖離し、根本的な設計のやり直しが必要になっている場合
3つのシグナルのうち複数が重なったら、感情ではなく事実に基づいて撤退を検討する時期です。
契約上の身の守り方として、請負契約の場合は、民法上の「瑕疵担保責任（契約不適合責任）」に基づき、成果物に不具合があれば是正を請求できます。ベンダーに重大な過失がある場合は、損害賠償を請求することもできます。
撤退する際は、次の手順を踏みます。
- 内容証明郵便で「是正期間（通常30日間）の通知」を行う
- それでも解消されなければ「契約解除通知」を送る
証拠として、議事録、メール、進捗報告書、成果物のすべてを日常的に保管しておくことが、後の交渉や訴訟で極めて重要になります。
準委任契約の場合は、民法上の「任意解除権」を行使することで比較的容易に解除できます。ただし、解除に伴う費用精算（既に発生した作業分の支払い義務）については争いになりやすいため、弁護士への相談が推奨されます。
発注後のプロジェクト管理と現場定着
契約を締結して開発が始まっても、発注側の役割が終わるわけではありません。プロジェクトの成否を左右するのは、開発中の発注側の関与の度合いです。「後はよろしく」と丸投げしてしまうと、現場のニーズとかけ離れたシステムができあがるリスクが高まります。定期的なステータス確認と、意思決定への積極的な参加が求められます。
チェンジマネジメントの実施方法（スポンサーロードマップ）
チェンジマネジメントとは、新しいシステムの導入にともなう組織・人・プロセスの変化を、計画的かつ戦略的に管理する手法です。どれほど優れた機能を備えたシステムでも、使う人が変化を受け入れなければ、投資は生きません。調査によれば、デジタルトランスフォーメーション（DX）プロジェクトの失敗原因の70%は、技術的な問題ではなく、人と組織の変化への抵抗だとされています。
チェンジマネジメントの中心的なツールが「スポンサーロードマップ」です。これは、プロジェクトのエグゼクティブスポンサー（多くは役員クラス）が、どのタイミングで、どの対象者（全社員、部門管理職、現場担当者）に、どのようなメッセージを発信するかを、スケジュールにした計画表です。
経営陣が「このプロジェクトは会社として重要であり、全員に参画してほしい」という明確なメッセージを適切なタイミングで出し続けると、現場の抵抗感を大きく下げられます。具体的には、次の5つのマイルストーンで、スポンサーからのメッセージ発信（全社メール、部門説明会など）を計画しておくことが推奨されます。
- プロジェクト開始時
- 要件定義完了時
- 開発着手時
- テスト開始時
- 本番稼働前
デジタルデバイドへの具体的対応策【競合にない切り口】
業務システムの刷新で見落とされがちなのが、デジタルデバイド（ITリテラシーの格差）への対応です。製造業の現場作業員や、長年紙と電話で業務を回してきたベテラン社員など、新しいデジタルツールに抵抗感や苦手意識を持つ人は、どの企業にもいます。こうした人を置き去りにして刷新を進めると、システムは動いても現場では従来どおりの紙の運用が続く「二重管理」に陥ります。
現場への定着を進める具体策は、次の3つです。
- ユーザーテスト：UI/UX設計の段階から、高齢の従業員や低ITリテラシーの層に試作画面を操作してもらい、「どこで迷うか」「何が分かりにくいか」を直接観察します。
- 並行運用：本番稼働後の一定期間（2〜4週間程度）は、紙と並べて使える期間を設けます。
- 社内インストラクター：各部署のキーパーソンを育て、困ったときにすぐ身近な人に聞ける環境をつくります。
ユーザーテストでは、フォントサイズの拡大、クリック対象の大型化、専門用語の排除、操作ステップの最小化といった配慮が、現場への定着を大きく左右します。「どうしても紙でないと不安」という従業員には、紙と並べて使える期間が安心材料になります。並行期間が終わったら、紙を少しずつ廃止していくスモールステップ方式が、現場の混乱を最小限に抑えます。
段階的移行と並行稼働によるリスクの最小化
業務システム刷新で移行リスクを抑えるための鉄則は、一気に全てを切り替えないことです。NHKの基幹システム訴訟（2025年2月提訴）が示した教訓のひとつは、100%の完全移行を目指す計画の現実的な困難さです。
全機能を一度に切り替える「ビッグバン移行」は、問題が起きたときの影響範囲が極めて大きく、事業継続に甚大なリスクをもたらします。
推奨される移行方法は、次の2つを組み合わせることです。
- フェーズドロールアウト（段階的展開）：全社展開を一部の拠点・部署・機能から始め、問題がないことを確かめてから、順に展開範囲を広げていく方法です。
- 並行稼働：旧システムと新システムを同時に動かし、同じデータで同じ処理をさせて結果を突き合わせ、整合性を確認します。
並行稼働の期間の目安は1〜3ヶ月程度で、この間に不具合や処理結果の差異を見つけて直しておくと、本番の完全移行後の重大障害リスクを大きく下げられます。
並行稼働には、コストと工数が追加でかかります。それでも、刷新に失敗したときのビジネス損失と比べれば、十分に見合う投資です。リスク管理の観点では、PoC（概念実証）を先行して実施する判断も非常に有効です。技術的な実現性と業務への適合性を小規模に検証してから、本格的な開発に入ります。
「内製化」の理想と現実：IT人材不足時代の現実的な外注戦略
近年、DXへの機運の高まりとともに、「システムは内製化すべきだ」という論調が増えています。確かに内製化には、ベンダー依存の解消、ナレッジの蓄積、スピーディーな改善サイクルといったメリットがあります。
しかし、現実の労働市場を見ると、2024年時点でIT人材の需要と供給のギャップは約43万人と推計されており（経済産業省）、採用競争は年々激しさを増しています。エンジニアの平均年収も上昇を続けています。
非IT系の中堅・大企業は、スタートアップや大手IT企業と採用で競わなければならず、内製化は想像以上に困難な道のりです。
IT人材枯渇・単価高騰の市場での現実的な外注戦略
現実的な解として、多くの企業が採用しているのは「ハイブリッド戦略」です。要件定義、プロジェクト管理、品質保証、発注者との調整といった「コントロール機能」は社内に持ち、実装、インフラ、テストなど「量と専門性が求められる作業」を外注するという分業体制です。
この戦略では、社内に「発注側PMO（プロジェクトマネジメントオフィス）」の機能を担える人材を育てることが重要です。ベンダーを管理・評価できる内部の力がないまま外注だけを増やすと、丸投げ体質が固まってしまいます。その結果、長期的には技術的負債とベンダーロックインが深刻になるおそれがあります。
ベンダーロックイン防止と長期的なコスト管理
業務システムを外注するときに必ず意識したいリスクが、ベンダーロックインです。特定のベンダーしか保守・改修できない状態になると、コストと品質について交渉力を失います。
ロックインを防ぐ基本の対策は、次の2つです。
- ソースコードの権利：著作権・所有権を発注側に帰属させる条項を、契約書に明記します。
- ドキュメント一式：設計書、仕様書、テスト仕様書などを成果物として契約に含め、将来ほかのベンダーへ移せる状態を保ちます。
クラウドサービスを使う場合は、データのエクスポート機能や標準APIへの対応を確認し、特定のクラウド基盤への依存度を適切に管理します。こうした管理が、長期的な費用を抑えることにつながります。
業務システム刷新の発注は、単純なシステム調達ではなく、企業の業務変革と競争力強化に直結する経営上の判断です。社内準備からRFP作成、ベンダー選定、契約交渉、プロジェクト管理までを丁寧に進めることで、リスクを抑えながら刷新の効果を高められます。本記事で紹介したリファレンスチェックや撤退戦略、デジタルデバイド対応といった実務の工夫を活かして、プロジェクトの成功を目指してください。
業務システム刷新の進め方を全体で確認するには、次の記事をご覧ください。
▼全体ガイドの記事
・業務システム刷新の完全ガイド
▼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を創業。