ITシステムの定期メンテナンスを外部委託する際、ベンダー選定の成否を左右するのがRFP（提案依頼書）と要件定義書の出来です。「とにかく安定運用してほしい」「障害が起きたら早く直してほしい」といった漠然とした要望のままRFPを出すと、ベンダーごとに前提がばらばらの提案が返ってきて比較できず、契約後に「思っていた保守と違う」というミスマッチが生じます。定期メンテナンスは目に見えにくいサービスだからこそ、何をどこまで・どの品質で実施するのかを、依頼側があらかじめ言語化しておく必要があります。
本記事は、ITシステム定期メンテナンスのRFP・要件定義書・提案依頼書の作り方を、発注企業の視点で具体化する「要件定義特化」の解説です。曖昧な要望をどう測定可能な要件に翻訳するか、クラウドの責任共有モデルを前提に責任分界点をどう書くか、SLAと処理速度の数値要件をどう定めるか、価格偏重を避ける評価軸をどう設計するかを、一次データとあわせて解説します。なお、費用相場や契約形態を含む全体像をまだ把握していない方は、まずITシステム定期メンテナンスの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム定期メンテナンスの完全ガイド
曖昧な要望を測定可能な要件に翻訳する
定期メンテナンスのRFPで最初につまずくのが、要望の曖昧さです。「安定して動いてほしい」「困ったらすぐ対応してほしい」という気持ちは分かりますが、これらは測定できないため、要件にはなりません。要件定義の第一歩は、こうした感覚的な要望を、誰が見ても達成・未達を判断できる定量的な指標に翻訳することです。この翻訳ができているかどうかが、後の提案比較と契約後の品質管理を大きく左右します。
業務影響度から保守要件を導く
要望を要件に翻訳する起点は、システムが止まったときの業務影響度です。「止まると即座に売上が止まる基幹システム」と「数時間止まっても業務が回る社内ツール」では、求めるメンテナンス水準がまったく異なります。まず自社のシステムを重要度で分類し、それぞれにどれだけのダウンタイムが許容できるか、いつまでに復旧できればよいかを定義します。この業務影響度の整理が、稼働率や復旧時間といった具体的な要件の根拠になります。
業務影響度を整理せずに「すべて最高水準で」と要求すると、保守費が跳ね上がります。年間保守費は開発費の15〜20%が目安とされ、規模別の月額は小規模5〜15万円、中規模15〜50万円、大規模50〜200万円以上が相場です（出典：ripla）。重要度の低いシステムにまで高い水準を求めれば、この相場の上限に張り付き、費用対効果が悪化します。要件定義とは、限られた予算をどこに重点配分するかの設計でもあるのです。
業務影響度の整理は、現場へのヒアリングから始めるのが確実です。システムを実際に使う部門に「これが何時間止まると、どんな業務が、どの程度滞るか」を具体的に聞き取り、許容できるダウンタイムを部門の言葉で把握します。IT部門だけで机上の重要度を決めると、現場の実態とずれた要件になりがちです。業務影響度を要件の根拠として明文化しておけば、後で「なぜこの水準なのか」をベンダーにも経営にも説明でき、過剰要求と過小要求の両方を防げます。
作業範囲と対応時間帯を明記する
翻訳の次のステップは、メンテナンスの作業範囲（スコープ）を具体的に列挙することです。監視・バックアップ・パッチ適用・障害対応・定期点検・軽微改修・報告のうち、どこまでを委託に含めるかを明記します。とくに軽微改修や仕様変更対応は、月何時間まで定額に含むのか、超過分は別途請求かを定めておかないと、後で費用トラブルになりやすい領域です。保守費の内訳で軽微改修は10〜15%を占めるとされ（出典：ripla）、ここの線引きは費用に直結します。
あわせて、対応時間帯も要件として明確にします。平日日中のみか、24時間365日か、夜間・休日はオンコール対応かによって、必要な体制とコストは大きく変わります。「すぐ対応してほしい」という曖昧な要望を、「平日9〜18時は即時、時間外は重大障害のみオンコールで初報2時間以内」というように、時間帯と緊急度の組み合わせで定義する。この具体化が、ベンダーに正確な見積もりを出させ、提案を横並びで比較する前提になります。
クラウド責任共有を前提にした責任分界点の要件
現代の定期メンテナンスRFPでもっとも見落とされがちで、かつもっとも重要なのが、責任分界点の明記です。多くのシステムがクラウドやSaaSを前提に動く今、障害の原因はベンダーがコントロールできる範囲だけでなく、クラウド事業者側の障害や、連携先SaaSのAPI仕様変更など「ベンダーの外側」にも存在します。この境界をRFPで曖昧にしたまま契約すると、いざ障害が起きたときに「それはうちの責任ではない」という押し付け合いが起こります。
責任共有モデルに沿った分担表を作る
責任分界点を明確にする実務的な方法が、責任分担表（RACI）の作成です。クラウドの責任共有モデルでは、物理インフラやハードウェアはクラウド事業者、OSやミドルウェア、アプリケーション、データは利用者側（およびその保守ベンダー）が責任を持つ、という基本構造があります。RFPには、この構造を踏まえ「OSパッチはベンダー、クラウド基盤障害はクラウド事業者、業務データのバックアップはベンダー」といった形で、誰が何に責任を持つかを一覧化することを求めます。
分担表があると、障害発生時の初動が速くなります。原因の切り分けの順序、クラウド事業者への問い合わせ役、利用者への報告役があらかじめ決まっているため、混乱が起きません。RFPの段階で「クラウド側障害の場合、ベンダーはどこまで一次切り分けと連絡調整を担うか」を要件として書いておくと、提案でその対応力を比較できます。責任分界点の明記は、現代の定期メンテナンスにおける最重要要件の一つです。
分担表を作るときは、グレーゾーンを意図的に洗い出すことが肝心です。たとえば、連携先SaaSのAPI仕様変更で自社システムが動かなくなった場合、その改修はベンダーの責任なのか追加費用なのか。AIを組み込んだシステムで誤った出力が出たとき、その監視と是正は誰の役割か。こうした「どちらの責任とも言い切れない」領域こそ、後にトラブルの火種になります。RFPで具体的なシナリオを示し、それぞれ誰が一次対応するかを答えさせることで、各ベンダーの責任意識と対応力の差が浮き彫りになります。
外部要因による障害時の費用負担を定める
責任分界とセットで定めるべきが、外部要因による障害が起きたときの費用負担です。クラウド事業者の障害や、連携SaaSのAPI仕様変更への追従対応は、ベンダーの過失ではないものの、対応には工数が発生します。これを定額の保守費に含めるのか、別途の実費精算とするのかをRFPで問うておかないと、いざというときに想定外の追加費用が発生します。要件定義で「外部要因起因の対応をどう扱うか」を明記することが、後の費用トラブルを防ぎます。
同様に、OSSの保守、データ復旧、クラウド側の構成変更に伴う再設定といった、想定外になりがちな費用も洗い出しておきます。これらは平時には発生しませんが、起きると高額になることがあります。RFPで「どの作業が定額外で、その単価はいくらか」を提示させることで、契約後の不意打ちを避けられます。責任分界点と費用負担を要件として書き込むことは、モダンなIT環境における定期メンテナンス契約の生命線だと言えます。
SLAと処理速度の数値要件を定める
定期メンテナンスのRFPで品質を担保する要が、SLA（サービス品質保証）と処理速度の数値要件です。前述の業務影響度の整理を踏まえ、稼働率・応答時間・復旧時間・性能といった指標に具体的な数値を入れていきます。数値があるからこそ、提案の良し悪しを定量的に比較でき、契約後も達成・未達を客観的に判断できます。曖昧な品質要望を、検証可能な約束に変えるのがこのステップです。
稼働率・応答時間・復旧時間の基準値
SLAの数値要件は、相場を基準に自社の業務影響度で調整します。稼働率は99.9%（月あたり許容ダウンタイム約43分）や99.5%が一般的な水準です。応答については、初報を重大障害15分・通常障害2時間、エスカレーションを30分、回答を24時間以内とする例があります。復旧は、重大障害4時間・通常障害8時間、恒久対応5営業日以内が一つの目安です（いずれも出典：ripla）。これらを叩き台に、自社にとって厳しすぎず緩すぎない水準を要件として設定します。
SLAを書く際は、努力目標型か保証型かも明確にします。「目指す」だけの努力目標型と、未達時にペナルティ（減額）が発生する保証型では、ベンダーの本気度もコストも変わります。保証型を求める場合は、未達時の減額相場（月額の何%か）と、外部要因による未達を除外する条件まで定義しておくことが実効性を高めます。SLAの数値要件は、ただ厳しく書くのではなく、達成可能で運用しやすい水準に落とすことが肝心です。
処理速度要件と価格偏重を避ける評価軸
性能の要件としては、処理速度を数値で書きます。RFPの例では、全画面の応答を3秒以内とする処理速度要件が示されることがあります（出典：ripla）。定期メンテナンスでは、この性能をリリースやデータ増加のなかでも維持し続けることが求められるため、性能監視と劣化時の対処までを要件に含めます。性能要件を曖昧にすると、「動いてはいるが遅い」というクレームの根拠を失うため、測定方法とセットで定義します。
性能要件で見落とされがちなのが、計測の条件です。「3秒以内」と書いても、ピーク時間帯か閑散時か、何件のデータを抱えた状態か、どの回線・端末からの計測かで結果は大きく変わります。条件を定めずに数値だけ書くと、ベンダーは自社に有利な条件で「達成している」と主張でき、発注側は反論できません。代表的な業務シナリオと負荷条件を具体的に示し、その条件下で何秒以内、という形で要件を書くことが大切です。あわせて、データ量の増加に伴う性能劣化を定期的に計測し、しきい値を超えたらチューニングする、という運用までRFPに織り込むと、リリースを重ねても性能が守られる体制になります。
最後に重要なのが、提案の評価軸の設計です。定期メンテナンスは安さで選びがちですが、価格の配点を高くしすぎると、品質や体制を犠牲にした安かろう悪かろうの提案が選ばれてしまいます。評価軸では、価格の配点を抑え、SLA達成体制・障害対応力・報告品質・責任分界の明確さといった非価格要素を厚く配点することが推奨されます。RFPに評価軸そのものを明示しておくと、ベンダーも品質で勝負する提案を出しやすくなります。要件定義の質が、結局はベンダー選定の質を決めるのです。
評価軸を設計する際は、各項目の配点と、何をもって高得点とするかの基準まで具体化しておくと、選定の客観性が高まります。たとえば障害対応力なら「初報応答の実績値」「過去の重大障害の対応事例」「夜間休日の体制」を見るといった具合です。報告品質なら、サンプルの月次レポートを提出させて中身を比べます。価格だけが数字で比較しやすいからと配点を寄せると、結局は安値競争になり、契約後の品質低下という形でツケが回ります。評価軸を先に固めてからRFPを出すことが、定期メンテナンスのベンダー選定で失敗しないための要諦です。
まとめ
ITシステム定期メンテナンスのRFP・要件定義書を整理すると、要点は四つに集約されます。第一に、曖昧な要望を業務影響度から測定可能な要件へ翻訳し、作業範囲と対応時間帯を明記すること。第二に、クラウド責任共有モデルを前提に責任分担表を作り、外部要因による障害時の費用負担まで定めること。第三に、稼働率99.9%・初報15分・復旧4時間・全画面3秒以内といった数値をSLAと性能要件に落とし込むこと。第四に、価格偏重を避け、SLA達成体制や責任分界の明確さを厚く配点する評価軸を設計することです。
要件定義の目的は、ベンダーを縛ることではなく、依頼側とベンダーが同じ前提に立って品質を約束し合える土台を作ることにあります。とくに責任分界点と外部要因の費用負担は、モダンなIT環境で最もトラブルになりやすい論点であり、ここを丁寧に書き込んだ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を創業。