ITシステムの不具合対応を外部に委託するなら、RFPや要件定義書で、対応範囲・SLA・体制・契約条件を数値と範囲で定めておくことが大切です。
金額だけで比べると、「範囲外だった」「想定より復旧が遅い」といったトラブルになりがちです。全体像はITシステム不具合対応の完全ガイドでもご確認いただけます。
▼全体ガイドの記事
・ITシステム不具合対応の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
対応範囲とエスカレーションの定義
RFPでまず明確にしたいのは、対応範囲の定義です。「不具合対応をお願いします」とだけ書くと、何を不具合とみなすのか、どこまでを委託先が担うのかが曖昧なままになります。
発注側は、アプリのバグ修正やデータ不整合の復旧を委託に含めるかどうかを決めておきます。サーバー障害の一次対応や利用者の問い合わせ対応も、線引きの対象になります。この線引きが、見積もりの金額と、いざというときの責任分界を左右します。
対象とする不具合と対象外の明記
要件定義で最も重要なのは、対象とする不具合の範囲と、明確に対象外とするものを、セットで書くことです。
たとえば、「自社開発したアプリケーションのバグに起因する不具合は対象、利用者のPC環境やネットワーク回線に起因するものは対象外」といった形で線引きします。
暫定対応までを含むのか、原因調査と恒久対応（バグ修正）まで含むのかも区別が必要です。
一次データでは、原因調査やバグ修正は工数規模に応じてスポット1件3万〜10万円といった費用が発生するため、月額に含むか別精算かを要件として定めておくべきです。
対象外まで書くのは、後のトラブルを防ぐためです。範囲を曖昧にしたまま契約すると、不具合が起きるたびに「これは含まれるのか」という押し問答になり、復旧が遅れます。
そこで、RFPの段階で「こういう症状が起きたとき、誰がどこまで対応するのか」をユースケースで列挙しておきます。対象と対象外が具体的になれば、発注者も委託先も迷わず動けます。
ベンダーに対応可否を回答させると、各社の対応範囲の差が明確になります。
対象と対象外は、症状ごとの一覧と判断理由の二つでRFPに書いておきます。
- 対象の不具合：委託先が受け持つ障害の種類を、症状ごとに並べた一覧
- 対象外の不具合：原因が委託先の管理外にある障害と、その判断理由
エスカレーション経路と責任分界点の定義
不具合対応は複数の関係者が関わるため、エスカレーション経路を定めておくことが欠かせません。
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にも限界があることは理解しておくべきです。サービスクレジットは多くの場合、当該月の料金の一部減額にとどまり、不具合による実際の事業損失までは補えません。一次データでも、損害賠償には上限が設けられ、間接損害は免責とされるのが一般的です。
そのため、SLAの保証内容だけでなく、損害賠償の上限と免責範囲も要件として確認します。過度な期待を契約に持ち込まないためにも、SLAは「速さの約束」と「未達時の扱い」の両面から定めてください。
各社の回答は、保証の型と補償の範囲の二つの面から比べます。
- 保証型と努力目標型：未達のときに補償が発生するかどうかの区別
- 損害賠償の上限と免責：補償の範囲と、間接損害の扱い
対応体制と稼働時間の要件
SLAを実現するには、それを支える対応体制と稼働時間の要件が欠かせません。24時間365日の対応を求めるのか、平日日中だけで足りるのかで、費用は大きく変わります。
自社のシステムがいつ動き、いつ止まると困るのかを起点に、必要十分な体制を決めます。そうすると、無駄な費用を避けられます。
稼働時間（営業時間内か24時間か）の要件
稼働時間の要件は、費用に直結します。一次データでは、営業時間内の障害対応が月3万〜8万円、24時間緊急対応が月10万〜20万円と、稼働時間によって数倍の差が出ます。
夜間や休日にシステムが動いていない業態であれば、営業時間内の対応で足りるケースが多く、24時間体制を過剰に求めると費用が無駄になります。逆に、ECや医療のように24時間止められないシステムでは、夜間の即応体制が必須要件になります。
稼働時間を決めるときは、「対応する時間帯」と「監視する時間帯」を分けて考えると、要件が精緻になります。たとえば、監視は24時間自動で行い、人による不具合対応は重大なものだけ夜間も即応、軽微なものは翌営業日対応、という組み合わせも可能です。
RFPでは、平日・夜間・休日それぞれの対応レベルを表形式で示し、ベンダーに費用を回答させます。そうすると、稼働時間と費用の関係が明確になります。
自社の事業時間に合わせて過不足のない要件を組むことが、費用を抑える第一歩になります。
時間帯の区分は、人の対応と自動監視の二つで整理します。
- 対応する時間帯：平日、夜間、休日それぞれで、人が対応する範囲
- 監視する時間帯：24時間の自動監視を行う範囲
担当者のスキルと体制要件
不具合対応の質は、担当者のスキルに左右されます。そのためRFPでは、一次対応を担うオペレーターと、原因調査を担う技術者の体制を明示するよう求めます。
一次データでは、監視オペレーターの人月単価が60万〜80万円、運用設計・インシデント分析が80万〜120万円です。運用管理者は120万円以上と、役割によって単価が異なります。
安すぎる見積もりは、原因調査ができるスキルの高い人材を体制に含んでいない可能性があります。そこで、体制図と要員のスキルレベルを必ず確認します。
体制要件で特に重要なのは、自社システムを理解した担当者が継続的に関与できるかです。担当者が頻繁に替わったり、毎回違う人が対応したりすると、システムの構造や過去の不具合履歴が引き継がれず、対応のたびにゼロから調べ直すことになります。
加えて、「専任または準専任の担当を置けるか」「担当交代時の引き継ぎはどうするか」を要件に入れ、属人化のリスクと引き継ぎの仕組みを両面から確認します。こうした確認が、長期的な対応品質を支えます。
体制の要件は、一次対応と原因調査の二つに分けて書いておきます。
- 一次対応：オペレーターの配置と、担当できる時間帯
- 原因調査：スキルの高い技術者が関与する範囲
隠れコストを潰す契約条件
RFPの最後に詰めたいのが、隠れコストを潰す契約条件です。月額の安さだけで選ぶと、対応のたびに追加費用が発生し、結果的に高くつくことがあります。
工数上限、追加費用の発生条件、契約解除時の引き継ぎ条件を要件として明確にしておけば、見積もり段階では見えにくいコストを事前に潰せます。
工数上限と追加費用の発生条件
月額固定の契約には、多くの場合「月◯時間まで」という工数上限が設定されています。この上限を超えた分の精算方法と超過単価をRFPで確認しておかないと、不具合が集中した月に想定外の請求が届きます。
一次データでも、スポット対応は1件3万〜10万円といった水準で、月額に含まれない対応は別精算が前提です。そのため、RFPでは「月額に含む工数」「超過時の単価」「スポット対応の料金」を明示させ、年間の総額で比べます。
追加費用の発生条件も、具体的に確認すべきです。原因調査に一定時間以上かかる場合や、バグ修正に開発が必要な場合、緊急の夜間対応が発生した場合など、どんなときに追加費用が生じるのかを列挙させます。
安すぎる見積もりは、こうした追加費用で帳尻を合わせている可能性があります。そこで、「この月額に何が含まれ、何が含まれないか」を一覧で回答させると、隠れコストを見抜く手がかりになります。総額で比べる習慣も、後悔のない委託先選びにつながります。
回答は、この二つの項目を各社とも同じ並びにそろえてもらいます。
- 月額に含む工数：上限の時間数と、超過したときの単価
- 追加費用の発生条件：原因調査の長時間化、開発を伴うバグ修正、夜間の緊急対応
契約解除時の引き継ぎ条件
意外と見落とされがちなのが、将来ベンダーを切り替えるときの引き継ぎ条件です。不具合対応を委託すると、システムの構成情報や過去の不具合履歴が委託先に蓄積されます。契約解除時にこれらが引き渡されないと、次のベンダーがゼロから調査することになり、移行コストが膨らみます。
引き継ぎ条件を決めておくことは、特定ベンダーへのロックインを避けるうえでも役立ちます。引き渡しの条件が曖昧だと、不満があってもベンダーを切り替えにくく、相手に足元を見られる関係になりかねません。
riplaは、フルスクラッチ受託と国内運用保守の立場から、運用ドキュメントや不具合記録を発注者の資産として整備し、いざというときの引き継ぎにも応じる透明性を重視しています。RFPの段階で引き継ぎ条件まで定めておくことは、長く主導権を保つための備えになります。
契約を終えるときの条件は、予告期間と引き渡すものの範囲の二つです。
- 解約予告期間：契約を終えるときに、事前に知らせる期間
- 引き渡しの範囲：ソースコード、アカウント、運用ドキュメント、過去の不具合記録
まとめ
ITシステム不具合対応のRFP・要件定義書は、対応範囲とエスカレーション、SLAの数値要件から組み立てます。対応体制と稼働時間、隠れコストを潰す契約条件を加えると、四つの要素がそろいます。
対象とする不具合と対象外を列挙し、責任分界点とエスカレーション経路を定めます。次に、初動応答15分・復旧2時間といった数値SLAを優先度別に設定し、保証型か努力目標型か、損害賠償の上限と免責まで確認します。
稼働時間は事業時間に合わせて決め、担当者のスキルと体制を明示させます。さらに、工数上限・追加費用・引き継ぎ条件で隠れコストを潰します。これらがそろって初めて、複数のベンダーを同じ条件で比べられます。
RFPづくりで大切なのは、「速さ」と「費用」のバランスを自社の事業影響から逆算することです。すべてに最高水準を求めれば費用は膨らみ、安さだけを追えば肝心のときに対応してもらえません。
riplaは、フルスクラッチ受託と国内運用保守を組み合わせ、要件定義の段階から対応範囲・SLA・費用の落としどころを一緒に整理しています。過不足のない不具合対応体制づくりも支援します。
全体像の確認には、あらためて完全ガイドをご活用ください。
▼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を創業。