ITシステムバグ修正のRFP/要件定義書/提案依頼書について

ITシステムのバグ修正・保守を外部に委託しようとするとき、最初の関門になるのが「RFP（提案依頼書）や要件定義書に、何をどう書けば妥当な見積もりと提案を引き出せるか」という問題です。バグ修正は形のないサービスであり、対応範囲・応答時間・体制が曖昧なまま発注すると、いざ重大なバグが起きたときに「それは契約の範囲外です」と言われ、想定外の追加費用や復旧遅れに直面します。逆に、要件を数値で明確に定義できれば、ベンダー各社を同じ土俵で比較でき、後の認識齟齬も防げます。

本記事は、ITシステムのバグ修正のRFP・要件定義書・提案依頼書に何を盛り込むべきかを整理する「要件定義特化」の解説です。対応範囲と優先度区分の定義、SLA（応答時間・復旧時間・稼働率）の数値要件、クラウドの責任共有を前提とした切り分けの定義、そして隠れコストを潰す対応範囲の明文化まで、一次データとあわせて具体的に解説します。読み終えるころには、自社のRFPに転用できる要件項目のチェックリストが頭の中に整理されるはずです。なお、バグ修正の費用相場や進め方の全体像をまだ把握していない方は、まずITシステムバグ修正の完全ガイドから読むことをおすすめします。

▼全体ガイドの記事
・ITシステムバグ修正の完全ガイド

対応範囲と優先度区分をRFPで定義する

バグ修正のRFPでまず明確にすべきが、「何をバグ修正の対象とするか」という対応範囲の定義です。プログラムの不具合だけを指すのか、設定ミスやデータ不整合の修正まで含むのか、軽微な仕様変更まで対応するのか。この線引きが曖昧だと、見積もりの前提がベンダーごとにバラバラになり、比較できません。対応範囲を明文化することが、適正なバグ修正契約の出発点です。

RFPで最も揉めやすいのが、「バグ」と「仕様変更」の境界です。設計どおりに動いていないものはバグ修正の範囲ですが、「設計はその通りだが業務に合わないので変えてほしい」というのは仕様変更であり、別途見積もりの対象になるのが一般的です。この区別を要件定義書に明記しておかないと、利用者が「これもバグだから無料で直して」と求め、ベンダーが「これは仕様変更です」と返す押し問答が起き、対応が滞ります。RFPでは、バグの定義（設計・仕様との不一致）を明文化し、仕様変更との切り分け基準を示すことが重要です。

あわせて、保守費用の中でどこまでがバグ修正に含まれるかも定義します。一次データでは、年間保守費は初期開発費の15〜20%が目安とされ、開発費3,000万円なら年450万〜600万円、月額換算で37万〜50万円です。この保守費の中で、バグ修正の工数に月あたり何時間まで含むのか、その上限を超えた分はどう精算するのかを要件として定めておくと、月によってバグが多発しても費用が青天井にならず、予算管理が安定します。範囲定義は、サービスの質と費用の両面で、後のトラブルを未然に防ぐ土台になります。

すべてのバグを同じ応答時間で対応するのは現実的でも経済的でもありません。RFPでは、バグの影響度に応じた優先度区分（重大度ランク）を定義します。たとえば「重大：業務が完全に停止する／高：主要機能が一部使えない／中：回避策があり業務継続は可能／低：軽微な表示崩れ」といった区分を設け、それぞれにどの応答時間・復旧時間を求めるかを紐づけます。この区分があることで、ベンダーは優先度ごとに体制を組め、発注側も「重大なものだけ手厚く、軽微なものは計画対応」という合理的な費用配分ができます。

優先度区分を定義するときは、自社の事業影響度から逆算するのが鉄則です。どの機能が止まると、いくらの損失が出るのか。総務省2025年版では金融・医療・EC系で5分以上の停止が1回1,200万円の機会損失、Gartner 2024ではダウンタイム1分あたり5,600米ドルの損失という統計があり、これらは「どこまでを重大と位置づけるか」の根拠になります。事業影響度のアセスメントを踏まえて優先度区分を設計すれば、過剰な対応要求で費用を膨らませることも、過少な要求で損失を招くことも避けられます。RFPの優先度定義は、費用と事業継続性のバランスを取る要の項目です。

SLAの数値要件（応答・復旧・稼働率）を定める

バグ修正のRFPで提案の質を最も左右するのが、SLA（サービス品質保証）の数値要件です。「迅速に対応します」「速やかに復旧します」といった定性的な言葉は、いざというとき何の保証にもなりません。応答時間・復旧時間・稼働率を具体的な数値で定義し、それを満たせなかった場合の取り扱いまで決めておくことで、初めてSLAは機能します。ここを数値化できるかが、RFPの成否を分けます。

SLAの数値要件で核になるのが、初報応答時間と復旧時間です。バグの報告・検知から、どれだけの時間で一次応答（受付・状況連絡）を返すか、そしてどれだけの時間で復旧させるかを優先度区分ごとに定めます。実際のサービス例では、官公庁仕様で「1時間以内に現地到着・対処開始」「1時間以内に内容と予想作業時間を報告」「原則4時間以内に完全復旧」、Cloud Naviで「重大issue 15分以内一次対応保証」、シーズホスティングで「検知から60分以内通知・12時間で復旧」といった水準が示されています。RFPには、自社が求める時間をこうした実値を参考に数値で書き込みます。

数値要件を書くときの注意点は、応答時間と復旧時間を混同しないことです。応答時間は「受け付けて連絡を返すまで」、復旧時間は「実際に直って業務が再開できるまで」であり、両者は別物です。応答が速くても復旧が遅ければ業務は止まったままで、逆に応答だけ約束されていても安心はできません。RFPでは「重大障害は15分以内に一次応答、2時間以内に復旧着手、24時間以内に完全解決」のように、応答と復旧を分けて、それぞれの目標を優先度ごとに定義することが大切です。これにより、ベンダーの提案を同じ尺度で比較できます。

稼働率は、SLAの中でも費用に直結する要件です。稼働率99.9%は年間で約8.76時間、月43.8分のダウンタイムを許容しますが、99.99%にすると許容は年52.6分、月4.38分まで縮まります。「9」が一つ増えるごとに運用コストは段階的に跳ね上がるため、稼働率の要求は慎重に決めるべきです。RFPで安易に「99.99%以上」と書くと、本来は不要な高コスト体制を組まされ、保守費が膨らみます。自社の業務にとって、月に43分のダウンタイムが許容できるのか、それとも数分も許されないのかを冷静に見極める必要があります。

過剰なSLAを避けるには、要件定義の前段で事業影響度のアセスメントを行い、稼働率の根拠を社内で合意しておくことが欠かせません。情シスが「念のため高い稼働率を」と要求すると費用が跳ね上がり、ビジネス部門は「そこまで必要か」と疑問を持ちます。この社内調整を経て、業務影響に見合った適正な稼働率を要件として定めることが、無駄のないSLA設計につながります。riplaはフルスクラッチ受託と国内運用保守の立場から、過剰SLAを戒め、事業影響度に基づいた現実的な要件定義を支援しています。RFPの稼働率は、高ければ良いものではなく、業務に必要十分な水準を見極めることが肝心です。

数値目標を定めても、それを満たせなかったときの取り扱いと、達成度の測定方法を決めておかなければSLAは絵に描いた餅になります。RFPでは、目標未達時にサービスクレジット（保守費の一部減額）を適用するのか、努力目標にとどめるのかを明確にします。一般に、SLAは「保証型」と「努力目標型」に大別され、保証型はペナルティを伴う分だけ月額が高くなる傾向があります。自社の事業影響度に照らし、どの優先度区分までを保証型にするかを要件として線引きすることが、費用と安心のバランスを取る要になります。

あわせて、応答時間・復旧時間をどの時点から計測するかの定義も要件に含めます。障害の「検知時刻」を起点とするのか、利用者からの「報告受付時刻」を起点とするのかで、同じ目標値でも実質的な厳しさが変わります。測定の基準が曖昧だと、SLA未達かどうかの判定で揉め、サービスクレジットの精算が形骸化します。月次でSLA達成状況を報告させる運用までRFPに書き込んでおけば、契約後も品質を客観的に監視でき、ベンダーに継続的な緊張感を持たせられます。数値目標は、測定とペナルティの設計まで含めて初めて意味を持つのです。

クラウド責任共有を前提に切り分けを定義する

現在、国内エンタープライズ・システムのクラウド比率は約5割（IDC Japan、2022年）に達し、多くのシステムがクラウド基盤上で動いています。クラウド環境でのバグ修正には、自社・ベンダー・クラウド事業者の三者で責任が分かれる「責任共有モデル」という固有の論点があります。これを前提に、どこまでが誰の責任範囲かをRFPで定義しておかないと、障害時に責任の押し付け合いが起き、復旧が遅れます。

クラウド環境のバグは、原因がアプリケーションのコードにあるのか、それともクラウド基盤側の障害にあるのかを切り分けることから始まります。クラウド基盤の障害は、利用者側では手出しができず、対応はクラウド事業者を待つしかありません。一方、アプリケーションのバグは保守ベンダーが直す責任範囲です。RFPでは、この切り分けの手順と、それぞれの責任主体を明確に定義します。「基盤障害だと判明した場合の連絡と暫定対応をどう進めるか」まで要件に含めておくと、原因が基盤側だったときに発注側だけが取り残される事態を防げます。

切り分けの要件で重要なのが、判定の所要時間と判定者の明確化です。誰が、どのログや情報をもとに、どれくらいの時間で「これは基盤障害」「これはアプリ不具合」と判定するのかを定めておかないと、切り分けの段階で時間を浪費します。保守ベンダーがクラウドの監視情報にアクセスでき、基盤側の状態を確認できる体制かどうかも、RFPで問うべき要件です。クラウド前提のバグ修正では、修正そのものより切り分けの設計が、復旧スピードを大きく左右します。

クラウド基盤の障害時、クラウド事業者の補償は多くの場合「サービスクレジット（利用料の一部返金）」にとどまり、ダウンタイムによる事業損失そのものは補償されません。この現実をRFPと契約に織り込んでおく必要があります。保守契約のSLA未達時の取り扱いも同様で、多くの契約はサービスクレジットや賠償額の上限、間接損害の免責が定められています。これらの条件を要件として確認し、自社が負うリスクの大きさを把握しておくことが、意思決定の前提になります。

賠償上限と免責の条項は、見落とすと致命的です。IBM 2024の調査では、データ漏洩の被害額は平均445万米ドルにのぼり、重大なバグやインシデントが大きな損害につながり得ることを示しています。それにもかかわらず、契約上の賠償上限が月額保守費の数か月分に限定されていれば、損失の大半は自社が負うことになります。RFPの段階で「SLA未達・重大障害時の補償はどこまでか」を明文化し、自社のリスク許容度と照らして契約条件を交渉することが、賢明な発注者の姿勢です。補償の上限は、SLAの応答時間と並んで、必ず確認すべき要件項目です。

対象環境・体制・引き継ぎをRFPで定義する

SLAと責任範囲を定義したら、残る要件は「誰が、何の環境を、どんな体制で対応し、将来どう引き継ぐか」です。これらは派手さこそありませんが、抜けると後で大きな手戻りを生みます。対象環境・体制・引き継ぎ条件をRFPで明文化しておくことが、長く安定したバグ修正契約の土台になります。

RFPには、バグ修正の対象となるシステムと環境を具体的に列挙します。どのアプリケーション、どのサーバー、どのデータベース、どのクラウドサービスが対象か。本番環境だけか、検証環境も含むか。これらが曖昧だと、対応対象の認識がベンダーごとに食い違い、見積もりの前提が揃いません。あわせて、どの監視ツールを使うか（OSSのZabbixか、クラウド型のDatadog・New Relicか、サーバー監視のMackerelか）も明記すると、提案の具体性が増します。監視ツールは、ホスト数やメトリクス量に応じて中規模で月数万〜数十万円の従量課金となるため、費用の前提としても重要です。

対象環境の定義では、システムの規模感も伝えるべきです。一次データでは、運用役務コストはサーバー1台あたり年140万円（JUAS調査の中央値）という目安があり、対象サーバーの台数は費用に直結します。RFPに対象システムの構成・規模を記すことで、ベンダーは適切な体制と工数を見積もれます。逆に規模を伝えずに見積もりを求めると、後で「想定より対象が多かった」として追加費用を請求される余地を残してしまいます。

意外に見落とされるのが、将来ベンダーを切り替えるときの引き継ぎ条件です。バグ修正を委託すると、その過程でシステムの内部知識がベンダー側に蓄積されます。もし契約終了時に、ソースコードや障害履歴、運用ドキュメントが引き渡されない取り決めだと、別のベンダーへの切り替えができず、特定のベンダーに依存し続けるロックインに陥ります。RFPの段階で「契約終了時のソースコード・アカウント・ドキュメントの引き渡し」「解約予告期間」「移行支援の有無」を要件として定めておくことが、主導権を保つ鍵です。

引き継ぎ要件は、いわば「出口の設計」です。入口（発注）の条件ばかりに目が行きがちですが、不満が生じたときにスムーズに別のベンダーへ移れるかどうかは、契約時にしか交渉できません。工数の棚卸しと引き渡しの段取りを要件に含めておけば、ベンダーは健全な緊張感を持って対応し、発注側は選択肢を確保できます。riplaはフルスクラッチ受託と国内運用保守の立場から、引き渡しを前提とした透明な要件定義を重視し、発注者が主導権を持てる契約設計を支援しています。RFPの引き継ぎ要件は、長期的なリスク管理の観点で必ず盛り込むべき項目です。

対象環境と並んで明文化すべきが、バグ発生時の対応体制と連絡経路です。誰が一次受付を担い、どのチャネル（電話・メール・チケットシステム）で報告するのか、夜間や休日は誰が待機するのかを要件として定めます。あわせて、保守ベンダー内のエスカレーション経路、つまり一次対応者で解決しない場合に上位の技術者へどうつなぐかも問うべきです。一次データでは、人月単価は監視オペレーターで60万〜80万円、運用設計・インシデント分析で80万〜120万円が目安であり、体制の厚みは費用に直結するため、求める体制を具体的に書くことが妥当な見積もりを引き出します。

発注側の体制も忘れてはいけません。バグ修正はベンダーに丸投げできても、社内の経営層や業務部門への報告、業務影響の判断は発注者の役割です。RFPには、発注側の窓口担当と、ベンダーからの報告をどう社内に展開するかの想定も記しておくと、いざというときの連携が滑らかになります。体制と連絡経路の定義は、SLAの数値目標を現場で確実に実行するための、いわば運用面の裏づけです。ここを曖昧にしたまま数値だけ立派に書いても、緊急時に機能しなければ意味がありません。

まとめ

ITシステムのバグ修正のRFP・要件定義書で押さえるべき項目を整理すると、対応範囲とバグ・仕様変更の切り分け、影響度に応じた優先度区分、応答時間と復旧時間と稼働率の数値要件、クラウド責任共有を前提とした切り分けと補償の取り扱い、という四つの柱に集約されます。稼働率は99.9%なら月43.8分・99.99%なら月4.38分の許容ダウンタイムを意味し、過剰なSLAは費用を跳ね上げます。事業影響度のアセスメントを根拠に、業務に必要十分な水準を数値で定義することが、適正な見積もりと提案を引き出す鍵です。

要件定義の目的は、形のないバグ修正サービスを数値と文章で輪郭づけ、ベンダー各社を同じ尺度で比較し、後の認識齟齬と隠れコストを未然に潰すことにあります。まずは自社の事業影響度を棚卸しし、優先度区分とSLAの目標値を社内で合意するところから始めてください。riplaはフルスクラッチ受託と国内運用保守を組み合わせ、過剰SLAを避けた現実的な要件定義から、クラウド前提の切り分け設計までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。