ITシステムの不具合対応を外部に委託する際、見積もりを取って金額だけを比べてしまうと、後で「この対応は範囲外だった」「想定より復旧が遅い」といったトラブルに直面しがちです。それを防ぐ唯一の方法が、委託前にRFP（提案依頼書）や要件定義書で「どこまでの不具合を、どれだけの速さで、どう対応してほしいか」を数値と範囲で明確に定義しておくことです。曖昧なまま発注すると、安い見積もりに飛びついた結果、肝心のときに対応してもらえない、という最悪の事態を招きます。
本記事は、ITシステム不具合対応のRFP・要件定義書・提案依頼書をどう作るかを、発注企業の視点から実務的に解説します。対応範囲とエスカレーションの定義、SLA（対応時間・復旧時間）の数値要件、対応体制と稼働時間の要件、そして隠れコストを潰す契約条件まで、一次データのSLA実値や費用相場とあわせて具体的に掘り下げます。読み終えるころには、複数のベンダーを同じ土俵で比較できるRFPの骨格が描けるはずです。なお、不具合対応の全体像をまだ把握していない方は、まずITシステム不具合対応の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム不具合対応の完全ガイド
対応範囲とエスカレーションを定義する
RFPでまず明確にすべきが、対応範囲の定義です。「不具合対応をお願いします」だけでは、何をもって不具合とし、どこまでを委託先が担うのかが曖昧なままになります。アプリのバグ修正、データ不整合の復旧、サーバー障害の一次対応、利用者の操作問い合わせ対応のうち、どれを含めるのか。この線引きが、見積もりの金額と、いざというときの責任分界を決めます。
対象とする不具合と対象外を明記する
要件定義で最も重要なのが、対象とする不具合の範囲と、明確に対象外とするものをセットで書くことです。たとえば「自社開発したアプリケーションのバグに起因する不具合は対象、利用者のPC環境やネットワーク回線に起因するものは対象外」といった形で線引きします。さらに、暫定対応までを含むのか、原因調査と恒久対応（バグ修正）まで含むのかも区別が必要です。一次データでは、原因調査やバグ修正は工数規模に応じてスポット1件3万〜10万円といった費用が発生するため、月額に含むか別精算かを要件として定めておくべきです。
対象外を明記する意義は、後のトラブル防止にあります。範囲を曖昧にしたまま契約すると、不具合が起きるたびに「これは含まれるのか」という押し問答が発生し、復旧が遅れます。逆に、対象と対象外を具体的に列挙しておけば、発注者も委託先も迷わず動けます。RFPの段階で「こういう症状が起きたとき、誰がどこまで対応するのか」をユースケースで列挙し、ベンダーに対応可否を回答させると、各社の対応範囲の差が明確になります。
エスカレーション経路と責任分界点を定める
不具合対応は複数の関係者が関わるため、エスカレーション経路の定義が欠かせません。一次対応窓口で解決できない不具合を、いつ・誰に・どう引き継ぐのか。委託先の一次対応から開発元へ、あるいは委託先から発注者の情報システム部門へ、という経路と判断基準をRFPで明示します。とくに自社開発システムでは、保守ベンダーと開発元が異なる場合、両者の責任分界点を曖昧にすると不具合が宙に浮きます。
責任分界点の定義では、発注者側の役割も明確にしておくことが大切です。委託先に丸投げできない領域として、業務影響の判断、経営層への報告、業務部門との調整は発注者が担う、と整理しておくと、不具合発生時の動きがスムーズになります。RFPには「重大不具合が発生した際の連絡フロー」を図やタイムラインで示し、各関係者の役割と連絡先、判断権限を記載すると、対応の空白を防げます。エスカレーションの設計は、対応スピードを左右する要件です。
SLA（対応時間・復旧時間）の数値要件を決める
RFPの核心は、SLA（サービスレベル合意）の数値要件です。不具合を受け付けてから何分以内に着手し、何時間以内に復旧するのか。この応答時間と復旧時間を数値で定義しなければ、対応の速さを客観的に比較できません。SLAは費用に直結する要件であり、要求する水準を上げるほどコストも跳ね上がるため、自社の事業影響と照らして適正値を見極める必要があります。
初動応答時間と復旧目標時間の具体値
SLAの数値を決めるには、業界の実値を参考にするのが近道です。一次データでは、官公庁仕様の例として「1時間以内に現地到着・対処開始」「1時間以内に内容と予想作業時間を報告」「原則4時間以内に完全復旧」といった基準が示されています。民間のサービス例では、重大issueに15分以内の一次対応を保証するもの、検知から60分以内に通知し12時間で復旧するもの、一般目標として重大障害は2時間以内に対応開始・24時間以内に完全解決、といった水準が見られます。
これらの実値を参考に、自社のRFPでは不具合の優先度ごとに数値を分けて定義します。たとえば重大不具合は「初動応答15分以内・暫定復旧2時間以内・恒久対応1営業日以内」、軽微な不具合は「初動応答1営業日以内・対応3営業日以内」といった形です。すべての不具合に最高水準を求めると費用が膨らむため、業務を止める不具合だけ厳しいSLAを設定し、軽微なものは緩める、というメリハリが現実的です。SLAは要求と費用のバランスを取る、最も重要な数値要件です。
保証型SLAと努力目標型SLAの違いを要件化する
SLAを要件化するとき、見落としてはならないのが「保証型」か「努力目標型」かの区別です。努力目標型は「○時間以内の復旧を目指す」という姿勢の表明にすぎず、未達でもペナルティはありません。一方、保証型は未達の場合にサービスクレジット（料金減額）などの補償が発生します。RFPでは「提示するSLAは保証型か努力目標型か」「未達時の補償はどうなるか」を必ず回答させ、各社の本気度を見極めます。
ただし、保証型SLAにも限界がある点は理解しておくべきです。サービスクレジットは多くの場合、当該月の料金の一部減額にとどまり、不具合による実際の事業損失を補填するものではありません。一次データでも、損害賠償には上限が設けられ、間接損害は免責とされるのが一般的です。RFPでは、SLAの保証内容だけでなく、損害賠償の上限と免責範囲も要件として確認し、過度な期待を契約に持ち込まないことが重要です。SLAは「速さの約束」と「未達時の扱い」の両面で定義してください。
対応体制と稼働時間の要件を固める
SLAを実現するには、それを支える対応体制と稼働時間の要件が必要です。24時間365日の対応を求めるのか、平日日中だけで足りるのか。この稼働時間の要件が、費用を大きく左右します。自社のシステムがいつ動いていて、いつ止まると困るのかを起点に、必要十分な体制を要件化することが、無駄な費用を避ける鍵になります。
稼働時間（営業時間内か24時間か）を要件化する
稼働時間の要件は、費用に直結します。一次データでは、営業時間内の障害対応が月3万〜8万円、24時間緊急対応が月10万〜20万円と、稼働時間によって数倍の差が出ます。夜間や休日にシステムが動いていない業態であれば、営業時間内対応で十分なケースが多く、過剰に24時間体制を求めると費用が無駄になります。逆に、ECや医療のように24時間止められないシステムでは、夜間の即応体制が必須要件になります。
稼働時間を要件化するときは、「対応する時間帯」と「監視する時間帯」を分けて考えると精緻になります。たとえば、監視は24時間自動で行い、人による不具合対応は重大なものだけ夜間も即応、軽微なものは翌営業日対応、という組み合わせも可能です。RFPでは、平日・夜間・休日それぞれの対応レベルを表形式で示し、ベンダーに費用を回答させると、稼働時間と費用の関係が明確になります。自社の事業時間に合わせた過不足のない要件設計が、コスト最適化の第一歩です。
担当者のスキルと体制要件を明示する
不具合対応の質は、担当者のスキルに大きく依存します。RFPでは、一次対応を担うオペレーターと、原因調査を担う技術者の体制を明示するよう求めます。一次データでは、監視オペレーターの人月単価は60万〜80万円、運用設計・インシデント分析は80万〜120万円、運用管理者は120万円以上と、役割によって単価が異なります。安すぎる見積もりは、原因調査ができるスキルの高い人材を体制に含んでいない可能性があるため、体制図と要員のスキルレベルを必ず確認します。
体制要件で特に重要なのが、自社システムを理解した担当者が継続的に関与できるかです。担当者が頻繁に交代したり、毎回違う人が対応したりすると、システムの構造やこれまでの不具合履歴が引き継がれず、対応のたびにゼロからの調査になります。RFPでは「専任または準専任の担当を置けるか」「担当交代時の引き継ぎはどうするか」を要件化し、属人化のリスクと引き継ぎの仕組みを両面から確認しておくことが、長期的な対応品質を担保します。
隠れコストを潰す契約条件を要件化する
RFPの最後に詰めるべきが、隠れコストを潰す契約条件です。月額の安さだけで選ぶと、対応のたびに追加費用が発生し、結果的に高くつくことがあります。工数上限、追加費用の発生条件、契約解除時の引き継ぎ条件を要件として明確にしておくことで、見積もり段階では見えにくいコストを事前に潰せます。
工数上限と追加費用の発生条件を明確にする
月額固定の契約には、多くの場合「月◯時間まで」という工数上限が設定されています。この上限を超えた分がどう精算されるのか、超過単価はいくらかをRFPで確認しないと、不具合が集中した月に想定外の請求が来ます。一次データでも、スポット対応は1件3万〜10万円といった水準で、月額に含まれない対応は別精算が前提です。RFPでは「月額に含む工数」「超過時の単価」「スポット対応の料金」を明示させ、年間の総額が見える形で比較します。
追加費用の発生条件も具体的に確認すべきです。原因調査に一定時間以上かかる場合、バグ修正に開発が必要な場合、緊急の夜間対応が発生した場合など、どんなときに追加費用が発生するのかを列挙させます。安すぎる見積もりは、こうした追加費用で帳尻を合わせている可能性があるため、「この月額に何が含まれ、何が含まれないか」を一覧で回答させることが、隠れコストを見抜く最大のポイントです。総額で比較する習慣が、後悔のない委託先選定につながります。
契約解除時の引き継ぎ条件を盛り込む
意外と見落とされるのが、将来ベンダーを切り替えるときの引き継ぎ条件です。不具合対応を委託すると、システムの構成情報や過去の不具合履歴が委託先に蓄積されます。契約解除時にこれらが引き渡されないと、次のベンダーがゼロから調査することになり、移行コストが膨らみます。RFPには「解約予告期間」「ソースコード・アカウント・運用ドキュメントの引き渡し」「過去の不具合記録の提供」を引き継ぎ条件として盛り込みます。
引き継ぎ条件を要件化することは、特定ベンダーへのロックインを避ける意味でも重要です。引き渡し条件が曖昧だと、不満があってもベンダーを切り替えられず、足元を見られる関係になりかねません。riplaはフルスクラッチ受託と国内運用保守の立場から、運用ドキュメントや不具合記録を発注者の資産として整備し、いざというときの引き継ぎにも応じる透明性を重視しています。RFPで引き継ぎ条件まで定義しておくことが、長期的に主導権を握り続けるための備えになります。
まとめ
ITシステム不具合対応のRFP・要件定義書は、対応範囲とエスカレーション、SLAの数値要件、対応体制と稼働時間、隠れコストを潰す契約条件という四つの軸で組み立てます。対象とする不具合と対象外を列挙し、責任分界点とエスカレーション経路を定める。初動応答15分・復旧2時間といった数値SLAを優先度別に設定し、保証型か努力目標型か、損害賠償の上限と免責まで確認する。稼働時間を事業時間に合わせて要件化し、担当者のスキルと体制を明示させ、工数上限・追加費用・引き継ぎ条件で隠れコストを潰す。これらを揃えて初めて、複数のベンダーを同じ土俵で比較できます。
RFPづくりで大切なのは、「速さ」と「費用」のバランスを自社の事業影響から逆算することです。すべてに最高水準を求めれば費用は膨らみ、安さだけを追えば肝心のときに対応してもらえません。riplaはフルスクラッチ受託と国内運用保守を組み合わせ、要件定義の段階から対応範囲・SLA・費用の落としどころを一緒に整理し、過不足のない不具合対応体制づくりを支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。