システムリニューアルの発注前に準備すべきこと

システムリニューアルの発注は、多くの企業にとって数年に一度しか経験しない大型プロジェクトです。準備不足のまま発注に踏み切ると、後から「思っていた仕上がりと違う」「費用が当初の2倍に膨らんだ」といったトラブルが続出します。発注側の担当者が事前に何をすべきか、順を追って解説します。

まず取り組むべきは、現行システムの「見える化」です。何年も使い続けてきたシステムは、業務の変遷とともに機能が継ぎ足されており、全容を把握しているメンバーが社内に誰もいないケースが珍しくありません。リニューアルを外部ベンダーに依頼するにあたって、現行システムの機能一覧・データ構造・連携先のシステム・月間利用者数・ピーク時の処理量といった情報を棚卸しする必要があります。

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

▼全体ガイドの記事
・システムリニューアルの完全ガイド

課題整理では「なぜリニューアルするのか」という問いに明確に答えられるようにします。「古いから」という理由だけでは、ベンダーに適切な提案を引き出せません。「月次の集計処理に毎回3時間かかっている」「バグ修正の費用が年間300万円を超えている」「スマートフォン対応ができていないため顧客離れが起きている」など、定量的な課題を言語化することが重要です。定量化できている課題があれば、リニューアル後の投資対効果も測定しやすくなり、経営層への説得材料にもなります。

システムリニューアルの失敗原因として最も多いのが「発注者側の体制不足」です。ベンダーに丸投げにしてしまい、気づいたら要件がずれていた、というパターンを何度も見てきました。発注者側には、最低限以下の役割を設けることをお勧めします。

プロジェクトオーナー（経営層または部門長）は最終意思決定者として機能し、予算承認・ベンダー選定の最終判断・社内調整を担います。プロジェクトマネージャー（担当者レベル）は日々のベンダーとのコミュニケーション窓口になり、議事録の作成・進捗管理・課題のエスカレーション等を行います。業務有識者（現場キーマン）は業務要件の定義と検収時の確認を担当します。専任のIT担当者がいない中小企業の場合は、外部のITコンサルタントや発注支援サービスの活用も有効な選択肢です。

システムリニューアルの予算は、開発費だけでなく、移行期間中の運用コスト・テスト費用・社員教育費・旧システムの並行稼働コストも含めて見積もる必要があります。業界の一般的な相場として、システム開発費の15〜20%程度を移行・教育関連費として追加で確保しておくと安心です。

経営層の合意形成では「リニューアルしない場合のリスク」を明示することが有効です。現行システムの保守費用の推移、障害発生リスク、競合他社との機能差、採用・人材定着への影響など、現状維持のコストを可視化した上で、リニューアルへの投資対効果を示します。稟議書には「3年間の現行維持コスト」と「リニューアル後の効率化による削減額」を並べて記載すると、経営層の判断を促しやすくなります。

RFI・RFPの作成と発注プロセス

発注プロセスの核となるのがRFI（情報提供依頼書）とRFP（提案依頼書）の作成です。この2つを正しく活用することで、ベンダーから質の高い提案を引き出し、選定ミスを大幅に減らすことができます。

RFIはRFP（提案依頼書）の前段階に実施するもので、「どんなベンダーがいるか」「どんな技術・手法で開発できるか」「大まかな費用感はどれくらいか」を把握するために活用します。RFIで収集する情報には、会社概要・開発実績・技術スタック・概算費用感・対応可能な規模・開発体制などが含まれます。

RFIを送付する先は5〜10社程度が適切です。多すぎると回答の精査に時間がかかり、少なすぎると市場の全体像が見えません。RFIへの回答期限は2〜3週間程度を設定し、回答内容を比較した上でRFPを送付する3〜5社に絞り込みます。RFIの段階では費用をかけずに幅広く情報収集できるため、スキップせずに実施することをお勧めします。

RFPは発注者がベンダーに提案を求める正式な文書です。RFPの品質がそのままベンダーの提案品質に直結するため、丁寧に作り込む必要があります。RFPに記載すべき主要項目は以下の通りです。

（1）プロジェクト概要：リニューアルの目的・背景・期待する効果。（2）現行システム概要：機能一覧・技術スタック・データ量・連携システム。（3）要件概要：機能要件・非機能要件（パフォーマンス・セキュリティ・可用性）。（4）スケジュール：全体スケジュールの希望・マイルストーン。（5）予算感：可能な範囲で明示することでミスマッチを防ぐ。（6）提案に含めてほしい事項：開発体制・使用技術・見積内訳・過去の類似実績。（7）選定基準と評価軸：ベンダーが提案を最適化するために必要。（8）質問受付と回答期限：質問の締め切りと回答予定日を明示。

ベンダーからの提案を評価する際は、あらかじめ評価シートを作成して複数の評価者で採点することを強くお勧めします。評価軸の例としては、技術力・過去実績（30点）、提案内容の具体性・課題理解度（25点）、費用の妥当性・内訳の透明性（20点）、プロジェクト体制・担当者のスキル（15点）、コミュニケーション・レスポンスの速さ（10点）などが挙げられます。

最終選定前には、提案書で不明な点をベンダーに質問するヒアリングの機会を設けます。このとき、実際にプロジェクトを担当するメンバーが同席するよう求めてください。営業担当者だけでヒアリングをして契約後に担当者が変わるケースは要注意です。ヒアリングでは「過去に同規模のリニューアルで発生したトラブルとその対処法」を具体的に聞くと、ベンダーの実力と誠実さが見えてきます。

契約締結時の重要ポイント

ベンダーを選定したら、次は契約交渉です。契約内容の理解不足がトラブルの温床になります。特に「請負か準委任か」「スコープ変更の扱い」「検収条件」の3点は必ず押さえてください。

請負契約は「成果物の完成」をベンダーが責任を持つ形式で、要件が明確に定義できる局面に向いています。一方、準委任契約は「作業の実施」を依頼する形式で、要件が流動的なアジャイル開発やコンサルティング的な関与に適しています。システムリニューアルでは、要件定義フェーズを準委任、設計〜開発〜テストフェーズを請負、保守・運用フェーズを準委任という組み合わせが一般的です。

請負契約の場合、ベンダーは完成責任を負うため、仕様変更の度に追加費用が発生しやすくなります。一方で発注者は「作ってみたら違った」というリスクを抱えにくくなります。準委任契約は月額固定でエンジニアのリソースを確保できる反面、成果物の品質保証がないため、発注者が積極的に進捗管理をする必要があります。どちらの契約形態にも一長一短があるため、プロジェクトの性質に合わせて使い分けることが重要です。

システムリニューアルプロジェクトにおけるトラブルの多くは、仕様変更（スコープ変更）の扱いをめぐる認識の齟齬から発生します。契約書には必ず「変更管理プロセス」を明記してください。具体的には、「仕様変更の申請は発注者が書面で行う」「ベンダーは変更による工数・費用への影響を5営業日以内に回答する」「発注者が承認した変更のみ作業を開始する」という流れを規定します。

口頭での仕様変更指示は厳禁です。「あのとき言ったはずだ」「そんな話は聞いていない」という対立の原因になります。メールでのやりとりでも、後から「メールを見落としていた」「見解の相違だった」という問題が起きるため、変更管理はプロジェクト管理ツール上で一元管理し、承認フローを明確に定めることが望ましいです。

検収条件は「何をもって完成とみなすか」を具体的に定義するものです。「正常に動作すること」という抽象的な表現ではなく、「RFPに記載した全機能要件を充足していること」「性能テストにおいて同時接続100ユーザーで画面応答3秒以内を達成していること」のように定量的・定性的に明記します。検収期間は納品後2〜4週間程度を設けることが一般的です。

瑕疵担保責任については、民法改正（2020年4月施行）により「契約不適合責任」として整理されています。請負契約では原則として引渡し後1年間、ベンダーは修補・代替物の引渡し・不足分の引渡しの義務を負います。特に重要な機能については、この期間を延長する特約を設けることも検討してください。また、セキュリティ脆弱性が発覚した場合の対応義務についても契約書に明記しておくことを強くお勧めします。

【独自】発注者が主導権を握るためのプロジェクト管理術

「ベンダーに任せているから大丈夫」という考え方が、プロジェクト失敗の最大のリスクです。発注者がプロジェクトの主導権を持ち、能動的に関与することが成功の鍵です。ここでは、競合記事ではほとんど触れられていない「発注者主導の進捗管理」の具体的な方法を解説します。

週次の定例ミーティングは必須です。しかし、多くの発注者が「ベンダーが報告する内容を聞くだけ」になってしまっています。発注者側から積極的に確認すべき項目を設けることで、ベンダーへの依存度を下げられます。確認すべき項目の例として、今週完了した作業と来週の作業計画（成果物レベルで確認）、現時点で発生しているリスクと対応策、遅延の予兆はないか（予定工数と実績工数の乖離）、発注者側に判断・決定を求める事項などが挙げられます。

プロジェクト管理ツール（Backlog・Jira・Notionなど）のアカウントを発注者にも付与してもらい、タスクの進捗状況をリアルタイムで確認できるようにすることをお勧めします。「ベンダーに報告を求める」のではなく「発注者自身がいつでも確認できる」状態を作ることで、情報の非対称性を解消できます。また、マイルストーンごとに「完成の定義」を明示したチェックリストを事前に合意しておくと、検収時のトラブルを防ぐことができます。

システム開発プロジェクトにおける紛争の大半は「言った言わない」の認識の齟齬から生まれます。これを防ぐ最も効果的な手段が徹底したドキュメント管理です。以下のルールを最初に合意しておくことが重要です。

第一に、すべての口頭合意はその日中に書面化します。打ち合わせ後30分以内に議事録を作成し、参加者全員に共有・確認依頼を送ります。第二に、仕様に関わる決定事項はすべて「仕様確定ログ」として別途管理します。議事録とは別に、仕様変更・決定事項を一覧で管理するドキュメントを設けることで、後から「いつ・誰が・何を決めたか」を追跡できるようにします。第三に、メール・チャットでの指示は原則禁止とし、プロジェクト管理ツール上で管理します。メールやSlackのやりとりは散逸しやすく、後から検索・参照するコストが高くなります。

問題が発生したとき、担当者レベルで抱え込んで対応が遅れるケースが多く見られます。事前にエスカレーションのルールを定めておくことで、問題の早期解決が可能になります。エスカレーションの判断基準として、スケジュールが1週間以上遅延する見込みがある場合、予算超過が20%以上になりそうな場合、要件の解釈に発注者とベンダーで齟齬が生じた場合、セキュリティインシデントが発生した場合などを例として定めておきます。

エスカレーション先は、発注者側はプロジェクトオーナー（経営層）、ベンダー側はプロジェクトマネージャーの上位職（部長・役員）を事前に明確にしておきます。問題が発生した際に「誰に連絡すればよいかわからない」状態では解決が遅れます。また、四半期に一度、プロジェクトの健全性をレビューする「プロジェクト健康診断」の機会を設けることで、問題の予兆を早期に発見できます。

【独自】既存ベンダーからの乗り換え交渉術

システムリニューアルで最も難しい課題の一つが「既存ベンダーとの関係整理」です。特に、ベンダーが情報開示に非協力的だったり、乗り換え阻止のために法外な費用を請求してきたりするケースへの対処法は、ほとんどの発注ガイドには書かれていません。ここでは、実際に多くの企業が直面するリアルな状況への対処法を解説します。

乗り換えを決めた後、まず直面するのが「仕様書を出してもらえない」「データ移行に数百万円かかると言われた」という問題です。まず確認すべきは契約書の「成果物の帰属」に関する条項です。多くの場合、発注者が費用を支払って開発したシステムの仕様書・ソースコード・データは発注者に帰属するはずです。契約書にその旨が明記されていれば、正式に書面で開示を求めることができます。

仕様書が存在しない場合（ベンダーが作成していなかった場合）は、別途作成費用が発生することもあります。しかしこの場合でも、ソースコードとデータの引き渡しは求められます。データのエクスポートについて法外な費用を請求された場合は、「データはお客様の資産である」という原則を根拠に交渉します。それでも応じない場合は、弁護士を通じた内容証明郵便による開示請求が有効です。新規ベンダーに同席してもらい、引き継ぎミーティングを設定するという方法も交渉力を高めます。

乗り換えを告げた途端に態度が急変し、急にバグを「仕様です」と言い張ったり、以前は無償対応していた作業に突然費用を請求してきたりするベンダーへの対処は、感情的にならず「記録と法的根拠」で対応することが原則です。

まず、これまでの無償対応の証跡（メール・議事録）を整理します。次に、契約書の「保守・サポート範囲」を改めて確認し、ベンダーの対応が契約外かどうかを判断します。契約上の義務を履行しない場合は、書面で是正を求め、一定期間内に対応がない場合は契約解除の手続きに入ることができます。このような状況に備えて、契約締結時から「解約通知期間（例：3ヶ月前予告）」と「解約時のデータ引き渡し義務」を明記しておくことが重要です。既存ベンダーとの関係が悪化しても、新規ベンダーへの移行が完了するまでは一定の関係を維持する必要があるため、感情的な対立を避けつつ、法的に正当な要求を淡々と進めることが賢明です。

ベンダーロックインとは、特定ベンダーへの依存度が高くなりすぎて、乗り換えが事実上困難な状態を指します。ステップ1は「ロックインの実態把握」です。現行システムのソースコード・データ・ドキュメントの所在と、現ベンダー以外がアクセスできるかを確認します。クラウドインフラの場合は、誰がアカウントのオーナー権限を持っているかも確認してください。

ステップ2は「段階的な権限回収」です。まずドメイン・DNS管理権限、クラウドサービスのオーナー権限、リポジトリ（ソースコード）へのアクセス権を発注者が直接管理できる状態に変更します。多くのベンダーはこれを快諾しますが、抵抗するベンダーがいれば要注意です。ステップ3は「新規ベンダーによる並行稼働期間の設定」です。旧ベンダーの保守契約が終了する前に、新規ベンダーが現行システムを理解し、運用できる状態を作ります。理想的には2〜3ヶ月の並行稼働期間を設けて、システムの知識が完全に引き継がれたことを確認してから旧ベンダーとの契約を終了します。

チェンジマネジメント：現場を巻き込む発注者の役割

システムリニューアルの技術的な成功は、現場への定着なしには意味がありません。「新しいシステムを使いたくない」「前のほうが良かった」という現場の抵抗によって、せっかくのリニューアルが形骸化してしまうケースは珍しくありません。発注者の役割は単に発注するだけでなく、組織変革を推進するチェンジマネジメントにも及びます。

現場のキーマンとは、非公式ながら他のメンバーに影響力を持つ人物です。肩書きと関係なく、「この人が反対したら現場全体が動かない」「この人が賛成してくれれば周囲もついてくる」という存在を特定し、プロジェクトの早い段階から巻き込むことが重要です。

キーマンには、要件定義の段階からヒアリングを行い、業務上の課題を丁寧に聞き取ります。「現行システムの何が不便か」「理想の業務フローはどういうものか」という問いに真摯に向き合うことで、キーマンの当事者意識を引き出せます。UAT（ユーザー受け入れテスト）にキーマンを参加させることで、リリース前から新システムへの理解と納得感を醸成することができます。IT部門が主導するリニューアルでは、現場の業務部門が「やらされている」と感じがちです。キーマンをプロジェクトの「共同オーナー」として位置づけることで、この構図を変えることができます。

リニューアルに関する情報は「適切なタイミング」に「適切な範囲」で共有することが重要です。プロジェクト初期に全社に広報しすぎると、要件が固まっていない段階で不確定情報が広まり、不必要な不安を生みます。一方、直前まで何も知らされないと、現場からの反発を招きます。

一般的には、要件定義フェーズ（キーマンのみ関与）、基本設計完了後（関係部署に概要共有）、開発完了・UAT前（全社向けにリリース予告と操作トレーニングの案内）、リリース1ヶ月前（全社向け詳細説明会・マニュアル配布）という段階での情報共有が有効です。フィードバック収集では、UAT参加者からの意見を集めるアンケートを設計し、優先度をつけて対応します。全ての要望に応える必要はありませんが、「なぜ対応しないのか」を丁寧に説明することが現場の納得感につながります。リリース後3ヶ月間は「定着支援期間」と位置づけ、操作に困ったユーザーが気軽に質問できる窓口を設けることで、移行後の現場混乱を最小化できます。

まとめ

システムリニューアルの発注は、RFPを書いてベンダーを選べば終わりではありません。発注前の課題整理から始まり、RFI・RFP作成、契約交渉、プロジェクト進行中の管理、既存ベンダーとの関係整理、そして現場への定着まで、発注者が主体的に関与すべき局面が数多くあります。

特に本記事で強調したいポイントは3つです。第一に、「ベンダー任せ」は失敗の最短ルートです。発注者が進捗管理・ドキュメント管理・課題のエスカレーションを主体的に行うことで、プロジェクトの成功確率が大幅に上がります。第二に、既存ベンダーとの乗り換えには事前の準備と「法的根拠に基づく交渉」が必要です。感情的な対立を避けつつ、データ・仕様書・権限の回収を段階的に進めてください。第三に、技術的な完成だけでは意味がありません。チェンジマネジメントを通じて現場を巻き込み、新システムが日々の業務に定着して初めてリニューアルの成果が生まれます。

システムリニューアルは経営課題です。IT部門だけの問題ではなく、経営層・業務部門・IT部門が一体となって取り組む必要があります。本記事で解説した準備・発注・管理・乗り換え・定着のプロセスを参考に、自社のシステムリニューアルを成功へと導いていただければ幸いです。発注に関してご不明な点がある場合は、プロの発注支援サービスを活用することも、プロジェクト成功の大きな後押しになります。

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

▼全体ガイドの記事
・システムリニューアルの完全ガイド

株式会社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を創業。