老朽化したシステムをそのまま使い続けることで、業務効率の低下や障害リスクの増大、セキュリティの脆弱化が深刻化しているケースは少なくありません。しかし「どこにどう依頼すればいいのか分からない」「ベンダーに言われるがままに契約して後悔した」という声は今なお多く聞かれます。システム更改の発注は一度失敗すると数千万円規模の損失が生じる可能性があるため、事前の準備と知識が成否を大きく左右します。

この記事では、システム更改の発注・外注・委託を成功させるために必要な準備から、RFP（提案依頼書）の作成・ベンダー評価・契約交渉・プロジェクト管理まで、実務で使える具体的なノウハウを体系的に解説します。特に「予算をRFPに書くべきか」という発注側が陥りやすい判断ミスや、契約法的トラブルの実例、ベンダーロックイン防止策など、競合記事では語られていない自社独自の知見を惜しみなくお伝えします。

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

▼全体ガイドの記事
・システム更改の完全ガイド

システム更改の発注前に準備すべきこと

システム更改を外注・委託する際、最も多い失敗パターンは「準備不足のままベンダー選定に入る」ことです。ベンダーへの依頼前に社内でしっかりと課題を整理し、体制を整えておくことが、プロジェクト成功の最大の前提条件となります。ここでは、発注前に必ず実施しておくべき2つの準備について詳しく解説します。

まず着手すべきは、現行システムの「課題リスト」の作成です。単に「古い」「使いにくい」という抽象的な不満ではなく、業務別に具体的な問題点を洗い出すことが重要です。たとえば「月次締め処理に3日かかっており、そのうち2日はシステム制約による手作業」「API連携不可のため、基幹システムとExcelの二重入力が毎日2時間発生している」というように、工数やコストを数値で示せる状態に整理します。

次に「あるべき姿（To-Be）」を定義します。現行システム更改後に実現したい業務フローを描き、それを達成するために必要な機能・性能・連携要件を一覧化します。この段階では「実現可能かどうか」を気にする必要はありません。まず業務側が本当に必要としていることを漏れなく書き出すことが先決です。その後、優先順位をMust（必須）・Should（できれば）・Could（余裕があれば）の3段階に分類すると、ベンダーへの説明が格段にスムーズになります。

棚卸しの際に特に見落とされがちなのが、データ移行の要件です。現行システムに蓄積された過去データをどこまで・どの形式で移行するかは、費用と工数に直結します。「全データを完全移行する」「直近3年分のみ移行し、それ以前は参照専用の別システムに保管する」といった方針を事前に決定しておくことで、ベンダーからの見積もり精度が大幅に向上します。

中堅・中小企業でシステム更改を進める際に直面する最大の壁の一つが「社内にITプロジェクトを管理できる人材がいない」という問題です。IT部門がないか、あっても運用保守で手一杯というケースでは、外注したプロジェクトをベンダー任せにしてしまい、最終的に「要件と異なるシステムが納品された」という事態を招きがちです。

この問題への対処法として効果的なのが、非IT部門のエースを巻き込む手法です。各業務部門で最も業務理解が深く、かつロジカルに物事を考えられる人材をシステム更改プロジェクトのキーパーソンとして任命します。彼らはITの専門知識がなくても、「現場の業務がどう変わるべきか」を一番よく知っています。ベンダーとの打ち合わせに同席させることで、要件の抜け漏れを大幅に減らせます。

並行して進めたいのがリスキリングです。プロジェクトマネジメントの基礎（PMBOK、アジャイルの概念）を学べる研修やオンラインコースは充実しています。また、情報処理推進機構（IPA）が無料で公開しているシステム調達ガイドラインは、発注者側の知識向上に役立つ実践的な資料です。外注するからこそ、発注者側もある程度の知識を持っておくことが、プロジェクトをコントロールする上で不可欠です。

予算が許すなら、PMO（プロジェクトマネジメントオフィス）支援を提供するコンサルティング会社を活用する方法もあります。ベンダーとは別に、発注者側の立場でプロジェクトを管理する専門家を雇うことで、ベンダーとの交渉やリスク管理を任せられます。この費用は総プロジェクト費用の5〜10%が目安ですが、プロジェクト失敗による損失を考えると費用対効果は高いと言えます。

RFI・RFPの作成方法と実践テンプレート

システム更改の発注プロセスにおいて、RFI（情報提供依頼書）とRFP（提案依頼書）は発注者とベンダーのコミュニケーションを構造化する重要なドキュメントです。これらを正しく作成することで、ベンダーから質の高い提案を引き出せるだけでなく、後のトラブルを予防する法的根拠にもなります。ここでは各ステップの実践的な作成ポイントを詳しく解説します。

RFI（Request for Information）は、RFP発行前に市場のベンダーから技術情報・製品情報・概算費用感を収集するための文書です。特にシステム更改の場合、「パッケージソフトで対応するか、スクラッチ開発（ゼロから構築）するか、クラウドサービスを組み合わせるか」という方針自体を決める前の段階でも活用できます。

RFIに記載すべき主要項目は次の通りです。①自社の事業概要と現行システムの概要、②更改の目的と解決したい課題、③想定する規模感（ユーザー数・データ量・連携システム数）、④ベンダーに期待するソリューションの方向性（パッケージ型・スクラッチ型・クラウド型など）、⑤回答期限と質問受付期間の設定。RFIの回答を受け取ったら、各社の回答を比較分析し、自社の方向性をより具体化した上でRFPの作成に着手します。

RFP（Request for Proposal）は、ベンダーに具体的な提案と見積もりを求めるための文書です。RFPの品質がそのまま提案の質を左右するため、可能な限り詳細かつ構造的に記述することが重要です。以下に必須項目を整理します。

①プロジェクト概要（目的・背景・期待成果）、②現行システムの概要と問題点、③新システムの機能要件（Must/Should/Could別）、④非機能要件（性能・可用性・セキュリティ・保守性）、⑤データ移行の方針と対象範囲、⑥プロジェクトのスケジュール（マイルストーン含む）、⑦発注側の体制・役割分担、⑧提案書のフォーマット・評価基準（開示推奨）、⑨提案書提出期限・プレゼン日程、⑩守秘義務に関する取り決め。

書き方のコツとして特に重要なのは「非機能要件の具体化」です。「レスポンスは速くすること」という曖昧な記述ではなく、「ピーク時1,000同時接続において、画面遷移のレスポンスタイムは3秒以内」というように数値化します。この具体化を怠ると、ベンダーが勝手に解釈した設計で開発を進め、稼働後に「思ったより遅い」というトラブルが発生します。また、評価基準をあらかじめRFPに開示することは、ベンダー側も提案の重点を絞り込めるため、質の高い提案が集まりやすくなるメリットがあります。

「RFPに予算を記載すべきか」は、発注担当者が必ずぶつかる難問です。一般的な考え方として「予算を明示することでベンダーが要件に合った提案を出しやすくなる」とされていますが、実務ではまったく逆の現象が起きます。

予算を記載すると、ベンダーは「上限金額に合わせた提案」を作ってきます。たとえば予算を3,000万円と記載すれば、本来2,000万円で実現できるプロジェクトでも、2,800万円〜3,000万円の見積もりが集まります。これはベンダーの営利企業としての合理的な行動です。一方、予算を記載しない場合、ベンダーは競合他社との比較で選ばれるために価格競争力を発揮し、本来の適正価格に近い見積もりを提出してくる傾向があります。

ただし、予算を全く非開示にすることにもリスクがあります。ベンダーが自社の標準的な見積もりを出した結果、予算を大幅に超える提案しか集まらないという事態も起こり得ます。この場合は、「予算レンジ」を口頭で伝える、あるいはRFPに「予算規模：数千万円台」程度の幅を持たせた表現にとどめる、という折衷案が現実的です。また、別の方法として、まず予算非開示で提案をもらい、第2段階のネゴシエーションで予算に合わせた削減案を検討するという2段階プロセスも有効です。

このような予算交渉の駆け引きに不慣れな担当者が多い中小企業では、外部のコンサルタントを活用して価格の妥当性を第三者目線で確認してもらうことも選択肢の一つです。市場相場を把握しているコンサルタントがいるだけで、発注者側の交渉力が大幅に高まります。

ベンダー提案の評価・比較手法

複数のベンダーから提案を受け取った後、最終的にどのベンダーに発注するかを決める評価・比較のプロセスは、システム更改の成否を左右する重要な局面です。価格だけで選んで後悔するケースも多い一方、定性的な印象だけで決めてしまっても客観性に欠けます。ここでは定量・定性の両面から評価する実践的な手法を詳しく解説します。

スコアリングシートを用いた定量評価では、評価項目ごとに重みづけを設定し、各ベンダーを5段階評価した上で、重みを加味した総合スコアを算出します。一般的な評価項目と重みの配分例を示します。

①機能要件充足度（重み25%）：RFPに記載したMust要件をどの程度カバーしているか。②技術力・実績（重み20%）：同種のシステム更改実績の豊富さ、使用技術の信頼性。③費用（重み20%）：初期費用だけでなく、5年間のTCO（総保有コスト）で比較。④スケジュール・体制（重み15%）：提示されたプロジェクト体制の充実度、マイルストーンの現実性。⑤保守・サポート体制（重み10%）：稼働後のSLA（サービス品質保証）、対応時間、担当者体制。⑥セキュリティ対応（重み10%）：セキュリティポリシーへの対応、脆弱性対応実績。

スコアリングは複数名（最低でも3名以上）が独立して採点し、その平均値を採用することで個人の主観的バイアスを排除します。評価者には事前に評価基準を統一しておくことが必要で、「5点：完全に要件を満たしている」「3点：概ね満たしているが一部懸念あり」「1点：要件を大きく下回る」といった具体的な定義を共有します。

スコアリングで数値化できない部分をカバーするのが定性評価です。特に重要なのが、担当PM（プロジェクトマネージャー）の対応力の見極めです。プレゼンテーションや質疑応答を通じて以下の点を注意深く観察します。

まず「不確定事項への回答の仕方」に注目してください。曖昧な質問に対して「おそらく〜と思います」と逃げるPMより、「その点は現時点では確認中ですが、〇〇日までに回答します」と明確にコミットできるPMの方が信頼できます。次に「リスクへの言及の積極性」も重要な指標です。提案書に都合の良いことしか書かれておらず、リスクについて聞いても楽観的な回答しか返ってこない場合は注意が必要です。逆に、潜在的なリスクを自ら率先して説明し、対策案を提示できるPMはプロジェクト管理能力が高い傾向にあります。

企業文化との相性も軽視できません。意思決定のスピード感、コミュニケーションの丁寧さ、社内承認フローの柔軟性など、プロジェクト期間中は密にやり取りをするパートナーとしての相性が、長期的なプロジェクト品質に影響します。また、Fit to Standard（業務プロセスをシステムの標準機能に合わせる）という提案ができるベンダーは高評価に値します。これは単にカスタマイズを減らしてコストを下げるだけでなく、将来のバージョンアップ対応やベンダーロックインリスクの軽減につながる、成熟した視点を持っている証拠です。

スコアリングと定性評価を経ても複数社が拮抗するケースは珍しくありません。同点時の最終判断基準として活用できるポイントを解説します。

第一の基準は「担当者の対応力と誠実さ」です。RFP発行後の質疑応答の段階から、質問への回答スピード、回答の深さ、対応の丁寧さを継続的に記録しておきます。プロジェクトが始まれば日常的に顔を合わせる相手ですので、この段階で見えている担当者の姿勢は、実際のプロジェクト進行時の対応を予測する良い指標になります。

第二の基準は「企業の財務健全性と継続性」です。プロジェクト期間は数ヶ月から1年以上に及ぶため、受注したベンダーが途中で経営破綻するリスクも考慮する必要があります。帝国データバンクなどの信用調査データを活用して、財務状況・従業員数の推移・主要取引先などを確認しておくことを推奨します。第三の基準は「参照先顧客（リファレンス）の質」です。同種の業界・規模でのシステム更改実績があるかどうかを、実際の顧客への問い合わせで確認できるかどうかを確かめます。リファレンスを提示できないベンダーは実績が乏しい可能性があります。

契約締結時に押さえるべきリスクヘッジ

ベンダーを選定したら、次は契約締結です。システム更改の契約は、後になって重大なトラブルの火種になりやすい局面です。発注側が知識不足のまま契約書にサインしてしまい、「要件が漏れていた」「納期に遅延した」「稼働後にバグが多発した」といった場面で対応できずに泣き寝入りするケースが後を絶ちません。ここでは契約に潜むリスクとその対処法を詳しく解説します。

システム開発・更改の外注契約形態は主に「請負契約」と「準委任契約」の2種類があり、どちらを選ぶかによってリスクの所在が大きく変わります。

請負契約は「成果物の完成」を目的とした契約です。ベンダーは合意した仕様通りのシステムを完成させる義務を負い、完成しなければ報酬を受け取れません。発注者にとっては成果物に対する法的保証（契約不適合責任）があるため保護が強い一方、要件定義が曖昧だと「仕様通りに作った」というベンダーとの争いに発展しやすいデメリットがあります。

準委任契約は「業務の遂行」を目的とした契約で、成果物の完成は保証されませんが、ベンダーは善管注意義務（善良な管理者としての注意義務）を持って業務にあたります。アジャイル開発や要件が固まっていない探索的な開発フェーズでは準委任契約が適しています。実務では、要件定義フェーズは準委任契約で進め、開発・テストフェーズは請負契約に切り替えるという「フェーズ分割契約」が普及しています。これにより、要件定義段階ではベンダーと柔軟に協力しながら要件を作り込み、開発フェーズでは完成責任を明確にできます。

システム更改における契約上のトラブルで最も多いのが、「要件定義書に記載されていなかった機能の追加費用」をめぐる争いです。ベンダーは「RFPに記載がなかった追加要件なので別途費用が発生する」と主張し、発注者は「常識的に含まれているはずだ」と主張する構図です。

この問題を防ぐには、契約書に「要件の変更・追加が発生した場合の変更管理プロセス」を明記しておくことが不可欠です。具体的には、「追加要件が発生した場合は双方合意の変更管理書（Change Request）を作成し、費用・工数・スケジュールへの影響を合意してから対応する」という手順を契約書または別紙で規定します。

2020年の民法改正により、「瑕疵担保責任」は「契約不適合責任」に改称され、発注者の権利が拡充されました。契約不適合責任では、引き渡されたシステムが契約の内容に適合しない場合、発注者はベンダーに対して修補請求・代替物引渡請求・代金減額請求・損害賠償請求・契約解除を求められます。ただし、この責任が有効に機能するためには「契約の内容（仕様書）」が明確であることが前提です。要件定義書・設計書・テスト仕様書を契約の附属文書として正式に組み込んでおくことが重要です。

遅延損害金については、「1日あたりの遅延損害金（請負金額の0.1〜0.3%/日が相場）」と「上限金額（請負金額の10〜20%）」を明記しておきます。遅延が発生した際の交渉根拠になるとともに、ベンダー側もスケジュール管理への緊張感が高まる効果があります。

システム更改後の最大リスクの一つが「ベンダーロックイン」です。特定のベンダーの技術・製品・保守体制に依存し、後から別のベンダーに乗り換えることができない状態に陥ることを指します。ベンダーロックインが深刻化すると、保守費用の値上げに対抗できない、システム改修の優先度をベンダー都合で決められる、障害時の対応が遅れても指摘しにくいといった問題が生じます。

ベンダーロックインを防ぐための契約条項として以下を盛り込むことを強く推奨します。まず「データ所有権の明示」です。システム内に蓄積されたデータはすべて発注者に帰属することを明記し、契約終了時には標準的なフォーマット（CSVやXMLなど）でデータを提供する義務をベンダーに課します。次に「ソースコードの著作権・所有権」についても契約書に明記が必要です。特注（スクラッチ）開発の場合、納品物のソースコードの著作権が発注者に帰属するのか、ベンダーに帰属するのかは契約書に明示されていなければ争点になります。

さらに「脱依存ステップ」として、「契約終了の6ヶ月前に通知することで契約を解除でき、その際ベンダーは後継ベンダーへの技術引継ぎに協力する義務を負う」という条項を入れることが有効です。また、SLA（サービスレベルアグリーメント）には「障害発生から初期対応まで2時間以内」「重大障害の月間発生件数が3件を超えた場合はペナルティが発生する」といった数値目標を設定し、達成できない場合の損害賠償規定を合わせて設けることで、ベンダーの対応水準を契約上担保できます。

発注後のプロジェクト管理と障害対応

契約を締結したら、プロジェクトの本番がスタートします。外注であっても、発注者側が能動的にプロジェクトに関与しなければ、最終的に希望通りのシステムは完成しません。特に、稼働直後の本番障害への対応を事前に設計しておくことは、多くの企業が見落としがちな重要課題です。ここでは実際に稼働後の混乱を最小化するための具体的な手法を解説します。

新システムの本番稼働直後に障害が発生することは、規模の大小を問わずほぼ避けられません。問題はその障害への対応が迅速・適切に行われるかどうかです。多くの企業が陥るのが「障害が発生したら、まず原因を突き止めてから対応する」という思考パターンです。しかし原因調査には時間がかかる場合が多く、その間も業務は停止し続けます。

これを防ぐのが「2段階フロー」という考え方です。第1段階は「暫定対応（業務継続優先）」です。障害発生直後は根本原因の特定よりも、まず業務を継続できる状態を作ることを最優先とします。具体的には、障害が発生した機能を一時的に停止して旧システムや手作業に切り戻す、障害の影響を受けない一部機能だけを使って業務を継続する、バッチ処理を手動で実行して翌日分の業務データを確保するなど、「今日の業務を止めない」ための措置を即座に実行します。

第2段階は「根本対応（プログラム修正）」です。業務継続の状態が確保できてから、落ち着いて障害の根本原因を調査し、プログラムの修正・テスト・再デプロイを行います。この2段階フローを事前にベンダーと合意し、障害対応手順書（エスカレーションフロー・連絡先・対応時間帯の明示）として文書化しておくことが重要です。「どのレベルの障害をどのラインで判断するか」という重大度分類（クリティカル・メジャー・マイナー）も事前に定義しておくことで、現場が混乱せずに対応できます。

「初期流動管理」とは、新システムの本番稼働後の一定期間（一般的に1〜3ヶ月）を「初期流動期間」として特別に管理する運用体制のことです。この期間はバグの発生率が高く、ユーザーの操作ミスや想定外の使い方によるデータ不整合が起きやすいため、通常よりも手厚いサポート体制を敷きます。

具体的な取り組みとして、まずベンダーの支援エンジニアを現場に常駐または毎日訪問させる「常駐支援」を契約書に盛り込みます。これはシステム更改の契約交渉時に費用を含めて合意しておく必要があります。次に「日次の問い合わせ集計と分析」を行い、ユーザーから上がってくる質問・不具合報告をリアルタイムで集約します。同じ問い合わせが複数件来ている場合はシステムの問題か操作マニュアルの不備かを判断し、翌日中に改善措置を講じます。

また、初期流動期間中は月次・週次のステアリングコミッティ（経営層を含む意思決定会議）を設けることも有効です。現場レベルでは解決できない優先度の判断やリソース配分の決定を速やかに行えるよう、エスカレーション先を明確にしておきます。初期流動期間を乗り越えることで、新システムは組織に定着し、本来の生産性向上効果を発揮し始めます。逆に言えば、この期間に十分なサポートを提供できなかったために「使いにくいシステム」として現場から忌避される事例も多く、プロジェクトとして最後まで気を抜けない重要な局面です。

まとめ

システム更改の発注・外注・委託を成功させるためのポイントを改めて整理します。まず発注前の準備として、業務ごとの課題を数値化した上で棚卸しを行い、IT人材不在の場合は非IT部門のエースを巻き込みながら体制を整えることが重要です。RFI・RFP作成では、予算をそのまま明示すると上限に合わせた見積もりが集まりやすくなるため、「予算レンジ」表現や2段階交渉プロセスを活用して適正価格を引き出すことを推奨します。

ベンダー評価では、スコアリングによる定量評価と、PMの対応力・企業文化との相性を見る定性評価を組み合わせることが不可欠です。同点時はFit to Standardを提案できるか、担当者の誠実さ、企業の継続性を最終判断基準とします。契約締結時は、フェーズ分割契約・変更管理プロセス・契約不適合責任・遅延損害金・ベンダーロックイン防止条項を必ず盛り込み、稼働後のリスクを事前に抑えます。そして稼働後は暫定対応と根本対応の2段階フローを事前に設計し、初期流動管理で現場の定着を支援します。

これらのプロセスを一人の担当者が全てこなすのは容易ではありません。株式会社riplaでは、システム更改のコンサルティングから開発・導入支援まで一気通貫でサポートする体制を整えています。IT事業会社として社内DXを推進してきた実績を活かし、発注者側の立場に立ちながら、ベンダー選定・契約交渉・プロジェクト管理の実務支援を行っています。システム更改の発注に不安を感じている担当者の方は、ぜひお気軽にご相談ください。

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

▼全体ガイドの記事
・システム更改の完全ガイド

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