システム更改の発注・外注・委託は、社内の課題と要件を整理する準備から始まり、RFI・RFPによる情報収集、ベンダー提案の評価、契約、稼働後の管理へと進みます。
老朽化したシステムを使い続けると、業務効率の低下や障害リスクの増大、セキュリティの脆弱化が深刻になるケースも少なくありません。また、「依頼先が分からない」「言われるままに契約して後悔した」という声も今も多く聞かれます。全体像は、下に挙げる全体ガイドでも確認できます。
▼全体ガイドの記事
・システム更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
システム更改の発注前の準備
システム更改を外注・委託するときに最も多い失敗は、準備が足りないままベンダー選定に入ってしまうことです。ベンダーに依頼する前に社内で課題を整理し、体制を整えておくことが、プロジェクトを成功させる前提になります。ここでは、発注前に実施しておきたい2つの準備を順に説明します。
社内の課題・要件の棚卸し方法
まず着手したいのは、現行システムの課題リストを作ることです。「古い」「使いにくい」といった抽象的な不満のままでは、ベンダーに正確に伝わりません。業務ごとに具体的な問題点を洗い出しておくことが大切です。
たとえば、「月次締め処理に3日かかり、そのうち2日はシステムの制約による手作業」「API連携ができないため、基幹システムとExcelへの二重入力が毎日2時間発生している」といった形です。工数やコストを数値で示せる状態まで整理しておきます。
棚卸しは、次の流れで進めます。
- あるべき姿（To-Be）の定義：現行システム更改後に実現したい業務フローを描き、必要な機能・性能・連携要件を一覧にします。
- 必要な要件の書き出し：実現できるかどうかはまだ考えず、業務側が必要とすることを漏れなく書き出します。
- 優先順位の設定：Must（必須）・Should（できれば）・Could（余裕があれば）の3段階に分けると、ベンダーへの説明がスムーズになります。
棚卸しの際に見落とされやすいのが、データ移行の要件です。現行システムに蓄積された過去データを、どこまで、どの形式で移行するかは、費用と工数に直結します。
「全データを完全に移行する」「直近3年分のみ移行し、それ以前は参照専用の別システムに保管する」といった方針を、事前に決めておきます。そうすると、ベンダーからの見積もりの精度が大幅に上がります。
IT人材不在の場合の体制構築（リスキリング・非IT部門の巻き込み）
中堅・中小企業のシステム更改で大きな壁になりやすいのが、「社内にITプロジェクトを管理できる人材がいない」という問題です。IT部門がないか、あっても運用保守で手一杯という会社では、外注したプロジェクトをベンダー任せにしがちです。その結果、最終的に「要件と異なるシステムが納品された」という事態を招きます。
この問題への対処として効果的なのが、非IT部門のエースを巻き込む方法です。各業務部門で最も業務理解が深く、ロジカルに考えられる人材を、プロジェクトのキーパーソンとして任命します。
ITの専門知識がなくても、彼らは「現場の業務がどう変わるべきか」を一番よく知っています。そのため、ベンダーとの打ち合わせに同席させると、要件の抜け漏れを大幅に減らせます。
- リスキリング：並行して進めたいのは、PMBOKやアジャイルの概念など、プロジェクトマネジメントの基礎を学ぶことです。研修やオンラインコースは充実しています。
- 資料での学習：情報処理推進機構（IPA）が無料で公開しているシステム調達ガイドラインは、実践的な資料です。
- 外部の専門家の活用：PMO（プロジェクトマネジメントオフィス）支援を提供するコンサルティング会社を使う方法もあります。
外注するからこそ、発注者側もある程度の知識を持っておくことが、プロジェクトを主導するうえで欠かせません。
予算が許すなら、ベンダーとは別の立場で発注者側のプロジェクトを管理する専門家を置くと、ベンダーとの交渉やリスク管理を任せられます。この費用は、総プロジェクト費用の5〜10%が目安です。プロジェクトの失敗による損失を考えると、費用対効果は高いといえます。
RFI・RFPの作成方法と実践テンプレート
システム更改の発注では、RFI（情報提供依頼書）とRFP（提案依頼書）が、発注者とベンダーのやり取りを整理する重要な文書になります。
この2つを正しく作ると、ベンダーから質の高い提案を引き出せます。加えて、後のトラブルを予防する法的根拠にもなります。ここでは、各ステップの作成ポイントを順に解説します。
RFIで情報を集める段階のポイント
RFI（Request for Information）は、RFPを出す前に、市場のベンダーから技術情報・製品情報・概算費用の感触を集めるための文書です。
特にシステム更改では、「パッケージソフトで対応するか、スクラッチ開発（ゼロから構築）するか、クラウドサービスを組み合わせるか」という方針を決める前の段階でも、RFIを活用できます。
RFIには、ベンダーが回答しやすいよう、次の5項目を記載します。
- 事業と現行環境：自社の事業概要と、現行システムの概要。
- 更改の目的：解決したい課題と、刷新の背景。
- 規模感：ユーザー数、データ量、連携システム数。
- 期待する方向性：パッケージ型、スクラッチ型、クラウド型など、想定する形態。
- 回答条件：回答期限と質問受付期間の設定。
RFIの回答を受け取ったら、各社の回答を比べて分析し、自社の方向性をより具体化します。そのうえで、RFPの作成に進みます。
RFPに盛り込むべき必須項目と書き方のコツ
RFP（Request for Proposal）は、ベンダーに具体的な提案と見積もりを求めるための文書です。RFPの品質がそのまま提案の質を左右するため、できるだけ詳しく、構造的に書くことが大切です。
RFPには、次の項目を入れます。
- プロジェクト概要：目的・背景・期待成果。
- 現行システムの概要と問題点：現状の仕組みと、抱えている問題。
- 新システムの機能要件：Must/Should/Could別に示します。
- 非機能要件：性能・可用性・セキュリティ・保守性。
- データ移行：移行の方針と対象範囲。
- プロジェクトのスケジュール：マイルストーンを含みます。
- 発注側の体制・役割分担
- 提案書のフォーマット・評価基準（開示推奨）
- 提案書の提出期限・プレゼン日程
- 守秘義務に関する取り決め
書き方のコツとして特に重要なのは、非機能要件を具体的な数値で示すことです。「レスポンスは速くすること」より、「ピーク時1,000同時接続において、画面遷移のレスポンスタイムは3秒以内」のように数値で書きます。この具体化を怠ると、ベンダーは自分なりの解釈で設計を進めてしまい、稼働後に「思ったより遅い」というトラブルが起きます。
また、評価基準をあらかじめRFPで開示しておくと、ベンダーは提案の重点を絞り込めます。その結果、質の高い提案が集まるというメリットもあります。
RFPに予算を記載するかの判断と駆け引き
「RFPに予算を記載すべきか」は、発注担当者が必ずぶつかる難しい問題です。一般には、予算を示すとベンダーが要件に合った提案を出しやすくなるといわれています。しかし実務では、まったく逆の現象が起きます。
予算を記載すると、ベンダーは上限金額に合わせた提案を作ってきます。たとえば予算を3,000万円と記載すれば、本来2,000万円で実現できるプロジェクトでも、2,800万円〜3,000万円の見積もりが集まります。これはベンダーが営利企業として取る合理的な行動です。
一方、予算を記載しない場合、ベンダーは競合他社との比較で選ばれるために価格競争力を発揮し、本来の適正価格に近い見積もりを出してくる傾向があります。ただし、予算をまったく非開示にすることにもリスクがあります。ベンダーが自社の標準的な見積もりを出した結果、予算を大幅に超える提案しか集まらないことも起こり得ます。
- 予算レンジの提示：「予算レンジ」を口頭で伝えるか、RFPには「予算規模：数千万円台」程度の幅を持たせた表現にとどめます。
- 2段階のプロセス：まず予算を非開示にして提案を受け、第2段階の交渉で予算に合わせた削減案を検討する方法も有効です。
予算レンジの提示は、現実的な折衷案です。こうした予算交渉に不慣れな中小企業では、外部のコンサルタントを活用して、価格の妥当性を第三者の目で確認してもらうことも選択肢の一つです。市場相場を把握しているコンサルタントがいれば、発注者側の交渉力は大幅に高まります。
ベンダー提案の評価・比較手法
複数のベンダーから提案を受けたら、最終的にどのベンダーに発注するかを決めます。この評価・比較の過程は、システム更改の成否を左右する重要な場面です。
価格だけで選んで後悔するケースも多い一方、印象だけで決めてしまうと客観性を欠きます。ここでは、定量評価と定性評価の両面から見る方法を解説します。
定量評価（スコアリングシート）の設計方法
スコアリングシートを使う定量評価では、評価項目ごとに重みづけを設定します。各ベンダーを5段階で評価し、重みを加味した総合スコアを算出します。重みの例では、機能要件の充足度に最も大きい25%の重みを置いています。
- 機能要件の充足度（重み25%）：RFPに記載したMust要件を、どの程度カバーしているか。
- 技術力・実績（重み20%）：同種のシステム更改での実績の豊富さと、使用技術の信頼性。
- 費用（重み20%）：初期費用だけでなく、5年間のTCO（総保有コスト）で比べる。
- スケジュール・保守・サポート（重み15%＋10%）：プロジェクト体制の充実度と、マイルストーンの現実性。
- セキュリティ対応（重み10%）：セキュリティポリシーへの対応と、脆弱性対応の実績。
稼働後の保守については、SLA（サービス品質保証）の内容、対応時間、担当者体制も見ます。
スコアリングは複数名（最低でも3名以上）が独立して採点し、その平均値を採用します。こうすることで、個人の主観的なバイアスを減らせます。
評価者には、事前に評価基準をそろえておくことが欠かせません。「5点：完全に要件を満たしている」「3点：概ね満たしているが一部懸念あり」「1点：要件を大きく下回る」といった具体的な定義を、評価者全員で共有します。
定性評価（PMの対応力・企業文化との相性）の見極め方
スコアリングで数値にしにくい部分を補うのが定性評価です。特に重要なのが、担当PM（プロジェクトマネージャー）の対応力を見極めることです。プレゼンテーションや質疑応答では、回答の仕方とリスクへの向き合い方に注目します。
まず、不確定な事項にどう答えるかを見ます。曖昧な質問に「おそらく〜と思います」と返すPMより、「その点は現時点で確認中ですが、〇〇日までに回答します」と明確に約束できるPMの方が信頼できます。
次に、リスクへの言及の積極性も重要な指標です。提案書に都合の良いことしか書かれておらず、リスクを聞いても楽観的な回答しか返ってこない場合は注意が必要です。逆に、潜在的なリスクを自ら率先して説明し、対策案まで示せるPMは、プロジェクト管理能力が高い傾向にあります。
企業文化との相性も、見落とせない要素です。
- 意思決定のスピード感
- コミュニケーションの丁寧さ
- 社内承認フローの柔軟性
企業文化は、期間中に密にやり取りする相手としての相性を左右し、長期的なプロジェクト品質に影響します。
また、Fit to Standard（業務プロセスをシステムの標準機能に合わせる）と提案できるベンダーは、高く評価できます。これは、カスタマイズを減らしてコストを抑えるだけでなく、将来のバージョンアップへの対応やベンダーロックインのリスク軽減につながる、成熟した視点の表れです。
同点時の最終判断基準
スコアリングと定性評価を経ても、複数社が拮抗するケースは珍しくありません。同点のときに判断の決め手として使えるポイントを解説します。
- 担当者の対応力と誠実さ：RFP発行後の質疑応答の段階から、質問への回答の速さ、回答の深さ、対応の丁寧さを継続して記録しておきます。
- 企業の財務健全性と継続性：帝国データバンクなどの信用調査データで、財務状況、従業員数の推移、主要取引先などを確認するのがおすすめです。
- 参照先顧客（リファレンス）の質：同種の業界・規模でのシステム更改の実績を、実際の顧客への問い合わせで確かめます。
プロジェクトが始まれば日常的に顔を合わせる相手なので、この段階で見える担当者の姿勢は、本番の進行時の対応を予測する良い指標になります。
プロジェクト期間は数ヶ月から1年以上に及ぶため、受注したベンダーが途中で経営破綻するリスクも考慮する必要があります。リファレンスを提示できないベンダーは、実績が乏しい可能性があります。
契約締結時のリスクヘッジ
ベンダーを選んだら、次は契約の締結です。システム更改の契約は、あとで重大なトラブルの火種になりやすい場面です。
発注側が知識不足のまま契約書にサインすると、「要件が漏れていた」「納期に遅延した」「稼働後にバグが多発した」といった場面で対応できず、泣き寝入りするケースが後を絶ちません。ここでは、契約に潜むリスクとその対処法を解説します。
請負契約 vs 準委任契約の使い分け
システム開発・更改の外注契約は、主に「請負契約」と「準委任契約」の2種類があります。どちらを選ぶかで、リスクを負う側が大きく変わります。
- 請負契約：成果物の完成を目的とした契約で、ベンダーは合意した仕様どおりのシステムを完成させる義務を負います。
- 準委任契約：業務の遂行を目的とした契約で、成果物の完成は保証されません。
請負契約では、完成しなければ報酬を受け取れません。発注者にとっては、成果物に対する法的な保証（契約不適合責任）があるため保護が手厚い一方、要件定義が曖昧だと「仕様どおりに作った」とベンダーと争いになりやすいという弱点があります。
準委任契約では、ベンダーは善管注意義務（善良な管理者としての注意義務）を持って業務にあたります。アジャイル開発や、要件がまだ固まっていない探索的な開発フェーズには、準委任契約が適しています。
実務では、要件定義フェーズを準委任契約で進め、開発・テストフェーズは請負契約に切り替える「フェーズ分割契約」が普及しています。これにより、要件定義段階ではベンダーと柔軟に協力して要件を作り込み、開発フェーズでは完成責任を明確にできます。
契約不適合責任・遅延損害金の取り決め
システム更改で契約上のトラブルとして最も多いのが、「要件定義書に書かれていなかった機能の追加費用」をめぐる争いです。ベンダーは「RFPに記載がなかった追加要件なので、別途費用が発生する」と主張し、発注者は「常識的に含まれているはずだ」と反論する構図になります。
この問題を防ぐには、要件の変更や追加が起きたときの変更管理プロセスを、契約書に明記しておくことが欠かせません。具体的には、「追加要件が発生したら、双方の合意のうえで変更管理書（Change Request）を作り、費用・工数・スケジュールへの影響を合意してから対応する」という手順を、契約書または別紙で定めます。
2020年の民法改正で、「瑕疵担保責任」は「契約不適合責任」に改められ、発注者の権利が拡充されました。契約不適合責任では、引き渡されたシステムが契約内容に適合しない場合、発注者はベンダーに次のことを求められます。
- 修補や代替物の引渡し
- 代金の減額
- 損害賠償
- 契約解除
ただし、この責任が有効に働くには、契約内容（仕様書）が明確であることが前提です。要件定義書、設計書、テスト仕様書を契約の附属文書として正式に組み込んでおくことが大切です。
遅延損害金については、次の内容を明記しておきます。
- 1日あたりの遅延損害金：請負金額の0.1〜0.3%/日が相場。
- 上限金額：請負金額の10〜20%。
遅延が発生した際の交渉の根拠になるとともに、ベンダー側もスケジュール管理への緊張感が高まります。
ベンダーロックイン防止条項
システム更改後の大きなリスクの一つが、ベンダーロックインです。特定のベンダーの技術・製品・保守体制に依存し、後から別のベンダーに乗り換えられない状態を指します。
ベンダーロックインが深刻になると、保守費用の値上げに対抗しにくくなります。さらに、システム改修の優先度をベンダーの都合で決められ、障害時の対応が遅れても指摘しにくくなります。
防止のための契約条項として、まず「データ所有権の明示」を盛り込むことを強く推奨します。
- データ所有権の明示：システム内に蓄積されたデータは、すべて発注者に帰属すると明記します。
- 標準形式でのデータ提供：契約終了時に、CSVやXMLなどの標準的な形式でデータを提供する義務をベンダーに課します。
- ソースコードの著作権・所有権：特注（スクラッチ）開発では、帰属先を契約書に明示しないと争点になります。
- 脱依存ステップ：契約終了の6ヶ月前に通知すれば解除でき、後継への技術引継ぎに協力する条項が有効です。
SLA（サービスレベルアグリーメント）にも、数値の目標を入れます。たとえば、障害発生から初期対応まで2時間以内、重大障害の月間発生件数が3件を超えた場合はペナルティ、といった形です。達成できない場合の損害賠償規定も合わせて設けると、ベンダーの対応水準を契約上担保できます。
発注後のプロジェクト管理と障害対応
契約を締結したら、プロジェクトの本番が始まります。外注する場合でも、発注者側が能動的に関わらなければ、希望どおりのシステムは完成しません。
なかでも、稼働直後の本番障害への対応を事前に設計しておくことは、多くの企業が見落としがちな重要な課題です。ここでは、稼働後の混乱を最小限に抑えるための方法を解説します。
暫定対応（業務継続優先）と根本対応（バグ修正）の2段階フロー
新システムの本番稼働直後に障害が起きることは、規模の大小を問わずほぼ避けられません。問題は、その障害への対応が迅速かつ適切に行われるかどうかです。
多くの企業が陥りがちなのが、「障害が起きたら、まず原因を突き止めてから対応する」という考え方です。ただ、原因の調査には時間がかかることが多く、その間も業務は止まり続けます。これを防ぐのが、「2段階フロー」という考え方です。
- 暫定対応（業務継続優先）：障害発生直後は、根本原因の特定よりも、業務を続けられる状態を作ることを最優先にします。
- 根本対応（プログラム修正）：業務継続の状態を確保してから、落ち着いて根本原因を調べ、修正・テスト・再デプロイを行います。
暫定対応では具体的に、障害が起きた機能を一時的に止めて旧システムや手作業に切り戻すなど、「今日の業務を止めない」ための措置を即座に実行します。たとえば、障害の影響を受けない一部の機能だけで業務を続けたり、バッチ処理を手動で実行して翌日分の業務データを確保したりします。
この2段階フローは、事前にベンダーと合意し、障害対応手順書として文書化しておきます。手順書には、エスカレーションフロー、連絡先、対応時間帯を明示します。
「どのレベルの障害を、どのラインで判断するか」という重大度分類（クリティカル・メジャー・マイナー）も、事前に決めておきます。そうすれば、現場が混乱せずに対応できます。
初期流動管理の導入で稼働直後の混乱を最小化
初期流動管理とは、新システムの本番稼働後の一定期間（一般的に1〜3ヶ月）を「初期流動期間」として特別に管理する運用体制のことです。この期間はバグの発生率が高く、ユーザーの操作ミスや想定外の使い方によるデータ不整合も起きやすいため、通常より手厚いサポート体制を敷きます。
稼働直後の混乱を抑えるには、ベンダーの支援を現場に近い形で手厚くし、問い合わせを毎日集めて素早く対応する体制が要ります。
- 常駐支援：ベンダーの支援エンジニアを現場に常駐させるか、毎日訪問させる形で、契約書に盛り込みます。
- 日次の問い合わせ把握：日次で問い合わせを集計・分析し、質問や不具合報告をリアルタイムで集約します。
- 同じ問い合わせへの対応：複数来ている場合は、システムの問題か、操作マニュアルの不備かを判断し、翌日中に改善措置を講じます。
常駐支援の費用は、契約交渉の段階で含めて合意しておく必要があります。
また、初期流動期間中は、月次や週次でステアリングコミッティ（経営層を含む意思決定会議）を設けると効果的です。現場では解決できない優先度の判断やリソース配分を速やかに決められるよう、エスカレーション先を明確にしておきます。
初期流動期間を乗り越えると、新システムは組織に定着し、本来の生産性向上の効果が出始めます。逆に言えば、この期間に十分なサポートを提供できなかったために「使いにくいシステム」として現場から敬遠される事例も多く、最後まで気を抜けない局面です。
まとめ
システム更改の発注・外注・委託を成功させるためのポイントを、改めて整理します。
まず発注前の準備では、業務ごとの課題を数値で示せるよう棚卸しを行い、IT人材がいない場合は非IT部門のエースを巻き込みながら体制を整えます。
RFI・RFPの作成では、予算をそのまま示すと上限に合わせた見積もりが集まりやすくなります。そのため、「予算レンジ」の表現や2段階の交渉プロセスを使い、適正価格を引き出すことを勧めます。
ベンダー評価では、スコアリングによる定量評価と、PMの対応力や企業文化との相性を見る定性評価を組み合わせることが欠かせません。
同点のときは、Fit to Standardを提案できるか、担当者の誠実さ、企業の継続性を最終的な判断基準にします。
契約締結時は、フェーズ分割契約と変更管理プロセスを必ず盛り込みます。そのうえで、契約不適合責任や遅延損害金、ベンダーロックイン防止条項を取り決め、稼働後のリスクを事前に抑えます。
稼働後は、暫定対応と根本対応の2段階フローを事前に設計し、初期流動管理で現場への定着を支えます。
これらのプロセスを一人の担当者がすべてこなすのは容易ではありません。株式会社riplaでは、システム更改のコンサルティングから開発・導入支援まで一気通貫でサポートする体制を整えています。
IT事業会社として社内DXを推進してきた実績を活かし、導入事例などの具体的な実績も確認しながら、発注者側の立場に立ってベンダー選定・契約交渉・プロジェクト管理を実務面から支援しています。
システム更改の発注に不安を感じている担当者の方は、ぜひお気軽にご相談ください。
▼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を創業。