システムリニューアルの発注は、課題整理、RFI・RFP、契約、進行管理、既存ベンダーとの交渉、現場定着まで、発注者が主導して進める一連の流れです。
準備と合意形成を重ねることが、費用や仕上がりのトラブルを防ぐ基本です。全体像は下記の完全ガイドでも詳しく扱っています。
▼全体ガイドの記事
・システムリニューアルの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
システムリニューアルの発注前の準備
多くの企業にとって、システムリニューアルの発注は数年に一度しか経験しない大型プロジェクトです。準備不足のまま発注に踏み切ると、後から「思っていた仕上がりと違う」「費用が当初の2倍に膨らんだ」といったトラブルが続出します。発注側の担当者が事前に何をすべきかを、順を追って解説します。
現行システムの可視化と課題整理
まず取り組むべきは、現行システムの「見える化」です。何年も使い続けたシステムは、業務の変遷とともに機能が継ぎ足されていきます。そのため、全容を把握しているメンバーが社内に誰もいないケースも珍しくありません。
依頼の前に、機能一覧、データ構造、連携先のシステム、月間利用者数、ピーク時の処理量を洗い出しておきます。ベンダーが提案と見積もりを組み立てる材料になるためです。課題整理では、「なぜリニューアルするのか」に明確に答えられるようにしておきます。
「古いから」という理由のままでは、ベンダーは適切な提案を組み立てにくくなります。「月次の集計処理に毎回3時間かかっている」「バグ修正の費用が年間300万円を超えている」「スマートフォン対応ができていないため顧客離れが起きている」のように、課題は数字を含めて言葉にします。数字で示せた課題は、リニューアル後の投資対効果を測る基準になり、経営層への説得材料にもなります。
社内体制の構築（プロジェクトオーナー・推進チーム）
システムリニューアルの失敗原因として最も多いのが、「発注者側の体制不足」です。ベンダーに丸投げにしてしまい、気づいたときには要件がずれていた、というパターンを何度も見てきました。発注者側には、最低限、3つの役割を設けることをお勧めします。
プロジェクトオーナー（経営層または部門長）は、最終の意思決定者として、予算の承認、ベンダー選定の最終判断、社内調整を担います。プロジェクトマネージャー（担当者レベル）は、日々のベンダーとのやりとりの窓口になります。議事録の作成、進捗管理、課題のエスカレーションなども担います。
業務有識者（現場キーマン）は、業務要件の定義と検収時の確認を担います。専任のIT担当者がいない中小企業では、外部のITコンサルタントや発注支援サービスを使う方法もあります。
予算確保と経営層の合意形成
予算は、開発費に加えて、移行期間中の運用コストやテスト費用も見積もる必要があります。社員教育費や旧システムの並行稼働コストも、忘れずに計上します。業界の一般的な相場としては、システム開発費の15〜20%程度を移行・教育関連費として追加で確保しておくと安心です。
経営層の合意を得るには、「リニューアルしない場合のリスク」を示すのが有効です。保守費用の推移や障害発生リスク、競合他社との機能差を挙げて、現状維持にかかるコストを見える形にします。採用・人材定着への影響も加えたうえで、リニューアルへの投資対効果を示します。
稟議書には、「3年間の現行維持コスト」と「リニューアル後の効率化による削減額」を並べて書くと、経営層が判断しやすくなります。
RFI・RFPの作成と発注プロセス
発注プロセスの核になるのが、RFI（情報提供依頼書）とRFP（提案依頼書）の作成です。この2つを正しく活用すると、ベンダーから質の高い提案を引き出せて、選定ミスを大幅に減らせます。
RFI（情報提供依頼）による市場の把握
RFIは、RFP（提案依頼書）の前段階で、「どんなベンダーがいるか」「どんな技術・手法で開発できるか」「大まかな費用感はどれくらいか」を把握するために行います。RFIでは、会社概要、開発実績、技術スタックを集めます。加えて、概算費用感、対応可能な規模、開発体制も回答に含めてもらいます。
RFIの送付先は5〜10社程度が適切です。多すぎると回答の精査に時間がかかり、少なすぎると市場の全体像がつかめません。RFIの回答期限は2〜3週間程度に設定し、回答内容を比べたうえで、RFPを送る3〜5社に絞り込みます。
RFIは費用をかけずに幅広く情報を集められるため、スキップせずに実施することをお勧めします。
RFP作成の具体手順と記載テンプレート
RFPは、発注者がベンダーに提案を求める正式な文書です。RFPの品質がそのままベンダーの提案の質に直結するため、丁寧に作り込む必要があります。記載する項目は、発注者が各社を比べられる形で整理します。
- プロジェクト概要：目的・背景・期待する効果。
- 現行システム概要：機能一覧・技術スタック・データ量・連携システム。
- 要件概要：機能要件・非機能要件（性能・セキュリティ・可用性）。
- スケジュール：全体スケジュールの希望・マイルストーン。
- 予算感：可能な範囲で明示し、ミスマッチを防ぐ。
- 提案事項：開発体制・使用技術・見積内訳・過去の類似実績。
- 選定基準：提案内容を評価する際の軸。
- 質問受付と回答期限：質問の締め切りと回答予定日。
提案評価と最終選定の進め方
提案を評価するときは、あらかじめ評価シートを作り、複数の評価者で採点することを強くお勧めします。評価軸の例として、技術力と過去実績に30点、提案内容の具体性と課題理解度に25点を配ります。残りは、費用の妥当性と内訳の透明性に20点、プロジェクト体制と担当者のスキルに15点、コミュニケーションとレスポンスの速さに10点です。
最終選定の前には、提案書で不明な点をベンダーに質問するヒアリングの場を設けます。その際は、実際にプロジェクトを担当するメンバーの同席を求めてください。営業担当者だけでヒアリングを済ませ、契約後に担当者が変わるケースには注意が必要です。
ヒアリングでは、「過去に同規模のリニューアルで発生したトラブルとその対処法」を具体的に聞くと、ベンダーの実力と誠実さが見えてきます。
契約締結時の重要ポイント
ベンダーを選定したら、次は契約交渉に進みます。契約内容の理解が不足したまま進むと、トラブルの温床になります。特に、「請負か準委任か」「スコープ変更の扱い」「検収条件」の3点は、必ず押さえておく必要があります。
請負契約 vs 準委任契約の使い分け
請負契約は、「成果物の完成」をベンダーが責任を持つ形式で、要件を明確に定義できる局面に向いています。一方、準委任契約は「作業の実施」を依頼する形式で、要件が流動的なアジャイル開発やコンサルティング的な関与に適しています。
システムリニューアルでは、要件定義は準委任、設計から開発、テストは請負、保守・運用は準委任という組み合わせが一般的です。請負契約では、ベンダーが完成責任を負うため、仕様変更のたびに追加費用が発生しがちです。一方で発注者は、「作ってみたら違った」というリスクを抱えずに済みます。
準委任契約は、月額固定でエンジニアのリソースを確保できる反面、成果物の品質保証がありません。そのため、発注者が積極的に進捗を管理する必要があります。どちらの契約形態にも一長一短があるため、プロジェクトの性質に合わせて使い分けます。
スコープ変更時の取り決め
システムリニューアルのトラブルの多くは、仕様変更（スコープ変更）の扱いをめぐる認識のずれから起きます。そのため、契約書には「変更管理プロセス」を必ず明記してください。
具体的には、仕様変更の申請は発注者が書面で行います。次に、ベンダーが変更による工数・費用への影響を5営業日以内に回答します。そのうえで、発注者が承認した変更のみ作業を開始します。
口頭での仕様変更指示は、「あのとき言ったはずだ」「そんな話は聞いていない」という対立を生むため厳禁です。メールでのやりとりでも、「メールを見落としていた」「見解の相違だった」という問題が後から起きがちです。そのため、変更管理はプロジェクト管理ツールでまとめて扱い、承認の流れを明確に定めておくことが望ましいです。
検収条件と瑕疵担保の設定
検収条件は、「何をもって完成とみなすか」を具体的に定めるものです。「正常に動作すること」のような抽象的な表現は避けます。代わりに、「RFPに記載した全機能要件を充足していること」「性能テストにおいて同時接続100ユーザーで画面応答3秒以内を達成していること」のように、定量的・定性的に明記します。
検収期間は、納品後2〜4週間程度を設けることが一般的です。また、瑕疵担保責任は、民法改正（2020年4月施行）により「契約不適合責任」として整理されています。
請負契約では原則として、引渡し後1年間、ベンダーに修補、代替物の引渡し、不足分の引渡しの義務があります。特に重要な機能については、この期間を延長する特約を設けることも一案です。さらに、セキュリティ脆弱性が発覚した場合の対応義務についても、契約書に明記しておくことを強くお勧めします。
【独自】発注者が主導権を握るためのプロジェクト管理術
「ベンダーに任せているから大丈夫」という考え方こそ、プロジェクト失敗の最大のリスクです。発注者が主導権を持ち、能動的に関わることが成功の鍵になります。
発注者主導の進捗管理は、競合記事ではほとんど触れられていない部分です。具体的な方法を、順に見ていきます。
ベンダー任せにしない進捗管理の仕組み
週次の定例ミーティングは必須です。しかし、多くの発注者が「ベンダーの報告を聞くだけ」になってしまっています。発注者側から確認すべき項目を持つことで、ベンダーへの依存度を下げられます。
確認項目の例は、今週完了した作業と来週の作業計画（成果物のレベルで確認）、現時点のリスクと対応策です。加えて、遅延の予兆（予定工数と実績工数の乖離）や、発注者に判断を求める事項も確認します。プロジェクト管理ツール（Backlog・Jira・Notionなど）のアカウントを発注者にも付与してもらい、タスクの進捗をリアルタイムで見られるようにすることをお勧めします。
発注者自身がいつでも確認できる状態を作れば、ベンダーとの情報の差を縮められます。また、マイルストーンごとに「完成の定義」を書いたチェックリストを事前に合意しておくと、検収時のトラブルを防げます。
「言った言わない」を防ぐドキュメント管理
システム開発の紛争の大半は、「言った言わない」の認識のずれから生まれます。これを防ぐ最も効果的な手段が、徹底したドキュメント管理です。そこで、次のルールを最初に合意しておくことが大切です。
- 口頭合意は当日中に書面化：打ち合わせ後30分以内に議事録を作成し、参加者全員に共有して確認を依頼します。
- 仕様決定の記録：仕様変更や決定事項はすべて、いつ・誰が・何を決めたかを後から追えるよう、議事録とは別の「仕様確定ログ」で一覧管理します。
- メール・チャットでの指示：原則禁止とし、プロジェクト管理ツール上で扱います。
メールやSlackのやりとりは散らばりやすく、後から検索・参照する手間がかかります。
問題発生時のエスカレーションルール
問題が起きたとき、担当者レベルで抱え込んで対応が遅れるケースが多く見られます。事前にエスカレーションのルールを定めておくと、問題を早く解決できます。
判断基準の例は、スケジュールが1週間以上遅れる見込みのときや、予算超過が20%以上になりそうなときです。加えて、要件の解釈が発注者とベンダーで食い違ったとき、セキュリティインシデントが起きたときも、基準として定めておきます。
エスカレーション先は、発注者側はプロジェクトオーナー（経営層）、ベンダー側はプロジェクトマネージャーの上位職（部長・役員）と、事前に明確にしておきます。誰に連絡すればよいかわからないままでは、解決が遅れます。また、四半期に一度、プロジェクトの健全性をレビューする「プロジェクト健康診断」を設けると、問題の予兆を早く見つけられます。
【独自】既存ベンダーからの乗り換え交渉術
システムリニューアルで最も難しい課題の一つが「既存ベンダーとの関係整理」です。特に、ベンダーが情報開示に非協力的だったり、乗り換え阻止のために法外な費用を請求してきたりするケースへの対処法は、ほとんどの発注ガイドには書かれていません。
実際に多くの企業が直面する状況への対処法を、順に見ていきます。
データ・仕様書の引き出し方
乗り換えを決めた後、まず直面しやすいのが、「仕様書を出してもらえない」「データ移行に数百万円かかると言われた」という問題です。最初に確認すべきは、契約書の「成果物の帰属」に関する条項です。多くの場合、発注者が費用を支払って開発したシステムの仕様書、ソースコード、データは、発注者に帰属するはずです。
契約書にその旨が明記されていれば、正式に書面で開示を求められます。仕様書が存在しない、つまりベンダーが作成していなかったときは、別途作成費用が発生することもあります。ただし、この場合でも、ソースコードとデータの引き渡しは求められます。
データのエクスポートに法外な費用を請求された場合は、「データはお客様の資産である」という原則を根拠に交渉します。それでも応じない場合は、弁護士を通じた内容証明郵便で開示を請求するのが有効です。さらに、新規ベンダーに同席してもらい、引き継ぎミーティングを設定すると、交渉力を高められます。
非協力的なベンダーへの対処法
乗り換えを告げた途端に態度が急変し、バグを「仕様です」と言い張ったり、以前は無償だった作業に突然費用を請求したりするベンダーがいます。こうしたベンダーには、感情的にならず「記録と法的根拠」で対応するのが原則です。まず、これまでの無償対応の証跡（メール・議事録）を整理します。
次に、契約書の「保守・サポート範囲」を改めて確認し、ベンダーの対応が契約の範囲外かどうかを見極めます。契約上の義務を果たさない場合は、書面で是正を求めます。一定期間内に対応がなければ、契約解除の手続きに進めます。
こうした事態に備えて、契約締結時から「解約通知期間（例：3ヶ月前予告）」と「解約時のデータ引き渡し義務」を明記しておくことが大切です。既存ベンダーとの関係が悪化しても、新規ベンダーへの移行が完了するまでは、一定の関係を保つ必要があります。そのため、感情的な対立は避け、法的に正当な要求を淡々と進めるのが賢明です。
ベンダーロックイン脱却の3ステップ
ベンダーロックインとは、特定ベンダーへの依存度が高くなりすぎて、乗り換えが事実上困難な状態を指します。ステップ1は「ロックインの実態把握」で、現行システムのソースコード・データ・ドキュメントの所在と、現ベンダー以外がアクセスできるかを確認します。クラウドインフラの場合は、誰がアカウントのオーナー権限を持っているかも確認してください。
ステップ2は「段階的な権限回収」です。まず、ドメイン・DNS管理権限、クラウドサービスのオーナー権限、リポジトリ（ソースコード）へのアクセス権を、発注者が直接管理できる状態に変更します。多くのベンダーはこれを快諾しますが、抵抗するベンダーがいれば要注意です。
ステップ3は「新規ベンダーによる並行稼働期間の設定」です。旧ベンダーの保守契約が終了する前に、新規ベンダーが現行システムを理解し、運用できる状態を作ります。理想的には2〜3ヶ月の並行稼働期間を設けて、システムの知識が完全に引き継がれたことを確認してから、旧ベンダーとの契約を終了します。
チェンジマネジメント：現場を巻き込む発注者の役割
システムリニューアルの技術的な成功も、現場に定着しなければ意味がありません。「新しいシステムを使いたくない」「前のほうが良かった」という現場の抵抗で、せっかくのリニューアルが形だけのものになるケースは珍しくありません。発注者の役割は、発注にとどまらず、組織変革を進めるチェンジマネジメントにも及びます。
キーマン特定と早期巻き込み
現場のキーマンとは、非公式ながら他のメンバーに影響力を持つ人物です。肩書きと関係なく、「この人が反対したら現場全体が動かない」「この人が賛成してくれれば周囲もついてくる」という存在を特定し、プロジェクトの早い段階から巻き込むことが大切です。
キーマンには、要件定義の段階からヒアリングを行い、業務上の課題を丁寧に聞き取ります。「現行システムの何が不便か」「理想の業務フローはどういうものか」という問いに真摯に向き合うことで、キーマンの当事者意識を引き出せます。
また、UAT（ユーザー受け入れテスト）にキーマンを参加させることで、リリース前から新システムへの理解と納得感を育てられます。IT部門が主導するリニューアルでは、現場の業務部門が「やらされている」と感じがちです。キーマンをプロジェクトの「共同オーナー」として位置づけることで、この構図を変えられます。
段階的な情報共有とフィードバック収集
リニューアルの情報は、「適切なタイミング」に「適切な範囲」で共有することが重要です。プロジェクト初期に全社へ広報しすぎると、要件が固まっていない段階で不確定な情報が広がり、不必要な不安を生みます。一方、直前まで何も知らされないと、現場の反発を招きます。
一般的には、要件定義フェーズではキーマンのみが関わり、基本設計が完了したら関係部署に概要を共有します。開発完了とUAT前には、全社向けにリリース予告と操作トレーニングを案内し、リリース1か月前には、全社向けの詳細説明会とマニュアル配布を行う流れが有効です。フィードバック収集では、UAT参加者からの意見を集めるアンケートを設計し、優先度をつけて対応します。
全ての要望に応える必要はありませんが、「なぜ対応しないのか」を丁寧に説明することが、現場の納得感につながります。また、リリース後3ヶ月間は「定着支援期間」と位置づけ、操作に困ったユーザーが気軽に質問できる窓口を設けることで、移行後の現場の混乱を抑えられます。
まとめ
システムリニューアルの発注は、RFPの作成とベンダー選定の後も、発注者が関わり続ける仕事です。発注前の課題整理から始まり、RFI・RFPの作成、契約交渉へと進みます。さらに、進行中の管理、既存ベンダーとの関係整理、現場への定着まで、発注者が主体的に関わるべき場面が数多くあります。
特に強調したいのは、3つの点です。
- 発注者の主体的な関与：進捗管理、ドキュメント管理、課題のエスカレーションを発注者が主体的に行うと、成功の確率が上がります。
- 既存ベンダーとの乗り換え：事前準備と「法的根拠に基づく交渉」を行い、感情的な対立を避けながら、データ・仕様書・権限を段階的に回収します。
- 現場への定着：技術的な完成だけでは不十分で、チェンジマネジメントで現場を巻き込み、新システムを日々の業務に根づかせる必要があります。
「ベンダー任せ」は失敗への最短ルートです。システムリニューアルは経営課題であり、経営層、業務部門、IT部門が一体となって取り組む必要があります。本記事で解説した流れを参考に、自社のシステムリニューアルを成功へ導いていただければ幸いです。
発注で不明な点があれば、プロの発注支援サービスを使うことも、プロジェクトの成功を大きく後押しします。
▼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を創業。