業務システム更改の発注・外注・委託は、社内の準備、RFI・RFPによる情報収集と提案依頼、ベンダーの評価・比較、契約、稼働後の管理の順で進みます。
業務システムの更改は、企業にとって数年に一度しか経験しない大規模プロジェクトです。老朽化したシステムの入れ替えや業務効率の大幅な改善を進めようとしても、「どこから手を付ければよいかわからない」「ベンダーに言われるがままになるのではないか」と不安を抱える担当者は少なくありません。中でも発注前の要件整理が、後の工程の進み方を大きく左右します。
本テーマの全体像は、以下の記事にまとめています。
▼全体ガイドの記事
・業務システム更改の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
業務システム更改の発注前の準備
業務システム更改で最も多い失敗は、発注後になって「要件が定まっていなかった」と気づくケースです。ベンダーに依頼する前に社内で準備を尽くすことが、プロジェクト全体の成否を分ける第一歩になります。
発注前の準備では、業務部門との要件調整と社内の体制づくりの2つが、特に大切になります。
業務部門との要件調整と現状業務フローの洗い出し
業務システム更改で最も大切なのは、現場の業務担当者から正確な要件を引き出すことです。情報システム部門が単独で要件をまとめようとすると、現場の実態と離れた仕様になりがちです。現場には、業務担当者でないと気づきにくい要素が数多くあり、たとえば、月末の締め処理で行う例外的な作業や、特定の顧客へのイレギュラーな対応などです。
現状業務フローの洗い出しでは、部門ごとのヒアリングをもとに「As-Isフロー図」を作るのが有効です。このとき気をつけたいのは部分最適化の弊害です。営業部門が「今のやり方に合わせてほしい」と求めた機能が、経理や物流に余分な工数をかけさせるケースもあります。
業務システム更改は、全体最適の視点で業務プロセスを見直す好機でもあります。ヒアリングは、各部門のキーパーソン（業務に精通したリーダークラス）を巻き込み、「現在の課題」「理想の状態」「必須機能」「あれば便利な機能」の4つの観点で整理することをお勧めします。この整理を怠ると、RFP作成や開発フェーズで手戻りが大量に発生し、費用と工期の両方が膨らむ原因になります。
IT人材不在の場合の体制構築
多くの中堅・中小企業では、情報システム担当者が1〜2名しかおらず、IT人材が社内にいないままシステム更改を進めることになります。この場合、発注側に技術的な判断ができる人材がいないため、ベンダーの提案を適切に評価しにくく、不利な条件で契約してしまうリスクが高まります。
IT人材不在を補う方法は、主に3つのアプローチがあります。まず、ITコンサルタントを外部から調達し、発注側の支援をしてもらう方法です。このコンサルタントは、PMO（プロジェクト管理オフィス）として機能し、RFP作成からベンダー評価、プロジェクト監理まで一貫して支援してくれるため、特にIT部門が手薄な企業に有効です。
次に、業務に精通した社内の業務改革推進リーダーを、プロジェクトマネージャーとして任命する方法です。技術的な判断はベンダーに委ね、業務要件のオーナーシップを社内で持つことで、プロジェクトの方向性をコントロールできます。さらに、SI企業を「ベンダー兼コンサルタント」として活用する方法もありますが、発注側の利益よりベンダー側の受注拡大につながる提案がされる可能性もあるため、利益相反に注意が必要です。
RFI・RFPの作成方法と実践テンプレート
ベンダー選定では、まずRFI（情報提供依頼書）で市場の情報を集め、次にRFP（提案依頼書）で具体的な提案を求める、2段階のアプローチが標準的です。
それぞれの段階で押さえるべき点は異なるため、順に見ていきます。
RFIで情報を集める段階のポイント
RFIは、特定のベンダーへの発注を前提にせず、業務システム更改に関わる市場動向や技術トレンド、ベンダーの対応可否などを幅広く集めることが目的です。この段階では、自社の課題を率直に示しながら、「どのような解決策があるか」「導入実績はどの程度あるか」「概算費用はどのくらいか」を問い合わせます。
RFIの送付先は、5社から10社程度が適切です。あまり広く声をかけすぎると回答の精査に時間がかかり、少なすぎると選択肢が狭まります。次に、RFIで得た情報をもとに、RFPを送るベンダーを3〜5社に絞り込むのが理想的な流れです。
RFI段階から積極的にベンダーと対話すると、自社が気づいていなかった課題や改善の余地が見つかることもあります。
RFPに盛り込むべき必須項目と書き方のコツ
RFPは、発注者とベンダーの間の「共通言語」になる文書です。その質が低いと、ベンダーの提案もあいまいになり、適切な比較・評価ができなくなります。
RFPには、ベンダーが比較可能な提案を作れるよう、次の5項目を必ず盛り込みます。
- 背景と現行環境：更改の目的や課題、現行の仕様、利用状況。
- 要件：必須・希望機能に加え、性能、セキュリティ、可用性、拡張性の条件。
- 連携と工程：既存システムや外部サービスとの連携、スケジュール、マイルストーン。
- 評価基準：選定の進め方と、提案の評価方法。
- 提案条件：提案書の形式と、提出期限。
書き方では、機能要件と非機能要件を明確に分けることが特に大切です。「使いやすいシステム」「安定したシステム」のようなあいまいな表現は避け、「同時接続ユーザー数200名でレスポンスタイム3秒以内」「稼働率99.5%以上を保証すること」のように、定量的に書いてください。
数値で示された要件があれば、ベンダー間の提案を横並びで比べやすくなります。
RFPへの予算の記載と発注側の駆け引き
RFPに予算を記載するかどうかは、発注側がほぼ必ず悩む問題です。一般論では「予算を明示したほうがベンダーも提案しやすい」と言われますが、実態はそれほど単純ではありません。予算を明示した場合のリスクは、ベンダーが提示された上限額に向けて提案を「水増し」することです。
たとえば「予算3,000万円」と記載した場合、実際には2,000万円でも実現できるシステムを、2,800万円〜3,000万円の見積もりで提案するベンダーが出てきます。これはベンダー側の商慣習として珍しくなく、「予算ぴったりに収めるのが礼儀」という感覚で見積もりを作るケースさえあります。
一方、予算を非提示にすると、各ベンダーが自社の原価に基づく素直な見積もりを出すため、提案内容とコストをフラットに比べられます。ただし、予算が全く読めない状態では、ベンダーが過大な提案をするリスクもあります。そのため、「○○万円から○○万円程度のレンジを想定している」のように目安だけ伝えるのが現実的です。重要なのは「上限額」を具体的に示さないことで、価格の上限合わせを防ぐ効果があります。
ベンダー提案の評価・比較手法
複数のベンダーから提案を受けたあと、どう評価して比べるかが、発注先選定の核心です。
評価を「なんとなくの印象」で決めると属人的になり、後から「あのベンダーの方がよかったのでは」という疑念が生まれ、社内の合意も取りにくくなります。
発注側は、定量評価と定性評価を組み合わせた客観的な評価体制を整えることが大切です。
定量評価（スコアリングシート）の設計方法
スコアリングシートは、評価項目・配点・評価基準を事前に定め、各ベンダーの提案を同じ基準で点数化するためのツールです。評価項目には、機能充足度や費用、納期などが一般的です。発注側は、保守体制や開発実績、セキュリティ対応にも、プロジェクトの優先度に応じた重み付けを行います。
たとえば、コスト削減が最優先の場合は「費用」の配点を30%に、セキュリティ要件が厳しい業界であれば「セキュリティ対応」の配点を20%に設定する、といった具合です。また、評点は「5段階評価×重み係数」の形式が扱いやすく、複数の評価者が個別に採点したあとに平均点を出すことで、恣意性を排除できます。
評価者には、情報システム部門だけでなく、業務部門のキーパーソンも加えることが大切です。さらに、技術的な観点だけでなく「業務担当者が使いやすいか」という視点も評価に反映させると、実際の現場への定着率が向上します。
定性評価（PMの対応力・企業文化との相性）の見極め方
スコアリングで測れない定性的な要素のなかでも、「プロジェクトマネージャー（PM）の対応力」は、プロジェクトの成否を大きく左右します。PMが変わるだけでプロジェクトの雰囲気が一変するほど、担当者の能力と姿勢の影響は大きいものです。ベンダー企業全体の評判だけでなく、「この案件を実際に担当するPMは誰か」を必ず確認してください。
PMの対応力を見極めるには、提案書のプレゼンテーション時に質問を投げかけるのが有効です。たとえば「要件定義が遅延した場合、どのような対応を取りますか」「過去のプロジェクトで最も困難だった事態とその解決策は何か」といった問いです。回答のスピード・具体性・誠実さに注目すると、PMの対応力が見えてきます。
また、企業文化との相性も見逃せない要素です。スタートアップ気質でスピード重視の自社に対して、手続きや書類を重視する大手SIerのスタイルが合わない、というミスマッチは実際に起こりえます。プロジェクト期間中のコミュニケーション頻度・報告スタイル・意思決定のスピード感などが自社と合うかどうかを、提案段階から確認しましょう。
同点時の最終判断基準
スコアリングの結果が僅差で並んだ場合、最終的な判断基準として参考にすべき観点があります。まず、「参照先（リファレンス）を提供してもらえるか」という点です。過去に類似プロジェクトを担当した顧客企業の導入事例を示し、直接ヒアリングもできるベンダーは、それだけ実績と顧客満足に自信を持っている証拠です。
また、「プロジェクト開始後に担当メンバーが交代するリスクはどの程度か」も確認すべき事項です。実際、提案時には優秀なPMが出てきても、受注後に別の担当者に替わるケースは業界内で珍しくありません。さらに、キーパーソンのアサイン継続を契約に明記することも、検討する価値があります。
契約締結時のリスクヘッジ
ベンダーを決めたあとの契約締結は、プロジェクトのリスクを法的に管理する大事な段階です。業務システム更改では、契約書の内容が後々のトラブル対応を左右します。
「言った言わない」の水掛け論を防ぐためにも、契約の段階でリスクヘッジの取り決めを、しっかり交わしておく必要があります。
請負契約と準委任契約の使い分け
業務システム開発の契約形態は、大きく「請負契約」と「準委任契約」の2種類に分かれます。請負契約は「成果物の完成」に対して報酬が発生する契約で、仕様書で定めた機能を実装するまでの責任をベンダーが負います。
一方、準委任契約は「作業の提供」に対して報酬が発生する契約です。ベンダーは誠実に作業を遂行する義務を負いますが、成果物の完成自体を保証するものではありません。一般的には、要件が固まった開発に請負契約を、要件定義やアジャイル型の開発に準委任契約を使うケースが多く見られます。
大切なのは、フェーズごとに契約形態を使い分けることです。たとえば、要件定義を準委任契約で進め、要件が固まった段階で開発を請負契約に切り替えるという二段構えの契約体制を取ると、発注側のリスクを最小化できます。
契約不適合責任・遅延損害金の取り決め
業務システム更改で契約上の最大のリスクは、「要件漏れによる追加費用」と「納期遅延」です。2020年の民法改正により、従来の「瑕疵担保責任」は「契約不適合責任」という概念に改められました。
契約不適合責任とは、引き渡されたシステムが契約内容（仕様書）と異なる場合に、発注者が修補・代金減額・損害賠償・契約解除を請求できる権利です。この責任を実効的に機能させるには、契約書に「何をもって契約不適合とするか」を具体的に定めておくことが欠かせません。
契約書には「仕様書に従うこと」と書くだけでなく、「受入テストの合格基準」や「バグの重大度分類と修正期限」を明記すると、トラブル時の判断がしやすくなります。また、遅延損害金も「1日あたり請負金額の0.1%」と具体的に定めると、ベンダー側の納期遵守への意識が高まります。実際に適用するかどうかは別として、条項として明記されていることが大切です。
ベンダーロックイン防止条項
業務システム更改で見落とされがちなのが、ベンダーロックイン（特定ベンダーへの依存状態）のリスクです。ソースコードの著作権がベンダー側に帰属していると、「他のベンダーへの乗り換えが事実上できない」「保守費用の値上げを受け入れざるを得ない」という状況に陥ることがあります。
ベンダーロックインを防ぐには、契約書に条項を盛り込むことが有効です。まず、ソースコードを含む成果物の著作権（財産的権利）を、発注者に帰属させることを明記します。次に、システムの移行に必要なドキュメント（設計書・データ定義書・操作マニュアル）の納品を義務付けます。
さらに、保守契約の終了後も一定期間は技術移行支援を提供する義務を設けておくことも欠かせません。これらの条項を契約書に入れておくと、将来のベンダー乗り換えや内製化に向けた選択肢を確保できます。
発注後のプロジェクト管理と障害対応
契約を結んだあとは、ベンダー任せにせず、発注者自身がプロジェクトを能動的に管理することが大切です。「何かあったらベンダーが対応してくれる」という受け身の姿勢では、問題が深刻になってから気づく事態を招きかねません。
特に、本番稼働後の障害対応と初期流動管理は、発注者が主体的に関わるべき局面です。
暫定対応（業務継続優先）と根本対応（バグ修正）の2段階フロー
業務システムの本番稼働直後は、規模を問わずどのプロジェクトでも障害が起こりえます。そこで大切なのは、障害時に「まず業務を止めない」という優先順位を、あらかじめ明確にしておくことです。この考え方を体系化したのが、「暫定対応→根本対応」の2段階フローです。
第一段階の暫定対応では、根本原因の解決より「業務を継続できる状態を最短で確保すること」を優先します。具体的には、障害の出た機能を止め、手作業への切り替えや旧システムでの処理で業務を続けます。たとえば、発注処理のオンライン入力でエラーが出た場合、その機能をオフラインにして担当者がCSVで手入力する暫定フローに切り替え、業務を止めないようにします。
第二段階の根本対応では、業務が続けられるようになったあと、落ち着いてバグの原因究明と修正を行います。障害の重大度に応じて対応期限を決め（例：重大バグは24時間以内、軽微バグは1週間以内）、修正後は必ずテストしてから本番に適用します。この2段階フローを事前に定めて保守条項にも反映させると、障害時の混乱やベンダーとの認識齟齬を抑えられます。
初期流動管理の導入による稼働直後の混乱の最小化
初期流動管理とは、リリース直後（一般的にはリリース後1〜3か月）に集中的にサポートを行い、現場の混乱を最小化する取り組みです。製造業のQCD（品質・コスト・納期）管理から派生した概念ですが、業務システム更改でも非常に有効です。リリース直後は、業務担当者が新システムの操作に不慣れなため、問い合わせが急増します。
「この画面の使い方」「前のシステムとの違い」といった問い合わせが連日ヘルプデスクに殺到し、生産性が一時的に下がるのは避けられません。そこで、この期間にベンダーのサポートメンバーが現場に常駐し、問い合わせにリアルタイムで答えるのが理想的です。常駐が難しい場合は、専用のチャットや電話の窓口を設け、通常より手厚いサポート期間を取るのが現実的です。
また、初期流動期間中に集めた問い合わせを分析すると、マニュアルの充実や画面改善のヒントが得られます。同じ操作について複数の担当者から問い合わせがあれば、それはUIの改善が必要なサインです。初期流動管理は、混乱を収めるだけでなく、品質向上サイクルの起点として使うことで、長期的な運用コストの削減にもつながります。
まとめ
業務システム更改の発注・外注・委託を成功させるには、発注前の社内準備からRFI・RFP作成、ベンダー評価、契約締結、稼働後の管理まで、各段階で適切な手を打つことが求められます。ここまでの内容を、段階ごとに整理します。
発注前には、業務部門を巻き込み、全体最適の視点で要件を洗い出すことが欠かせません。RFP作成では、予算の上限額を明示しないことが、ベンダーによる価格の上限合わせを防ぐ交渉術として有効です。
ベンダー評価では、スコアリングシートによる定量評価に、PMの対応力や企業文化との相性といった定性評価を組み合わせることで、後悔のない選定ができます。契約では、契約不適合責任・遅延損害金・ベンダーロックイン防止の条項をしっかり盛り込み、リスクを法的に管理します。
稼働後は、暫定対応と根本対応の2段階フローを事前に定め、初期流動管理によって現場の混乱を抑えます。こうした体制を整えておくと、プロジェクトの成果を確実なものにできます。
業務システム更改は、IT導入にとどまらず、企業の業務プロセスと競争力を根本から変える取り組みです。発注側が主体的に関わり、適切なパートナーと協力して進めることで、更改後のシステムが現場に定着し、ビジネスの成果につながります。
riplaでは、コンサルティングから開発・稼働後の定着支援まで一気通貫でサポートしています。業務システム更改の発注・外注・委託でお悩みの方は、ぜひお気軽にご相談ください。
▼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を創業。