定期メンテナンスのRFP（提案依頼書）と要件定義書では、要望を測定可能な要件に置き換え、作業範囲と責任分界点、SLAの数値を書き込みます。
その出来が、ベンダー選定の成否を左右します。費用相場や契約形態の全体像は、ITシステム定期メンテナンスの完全ガイドで先に確認できます。
▼全体ガイドの記事
・ITシステム定期メンテナンスの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
曖昧な要望の測定可能な要件への翻訳
定期メンテナンスは目に見えにくいサービスのため、何をどこまで、どの品質で実施するのかを依頼側があらかじめ言語化しておく必要があります。その際に最初につまずきやすいのが、要望の曖昧さです。
「とにかく安定運用してほしい」「障害が起きたら早く直してほしい」といった漠然とした要望のまま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）の作成です。
RFPでは、責任の基本構造を踏まえて、誰が何に責任を持つかを一覧にして示すよう求めます。たとえば「OSパッチはベンダー、クラウド基盤障害はクラウド事業者、業務データのバックアップはベンダー」のように、担当を一つずつ書き分けます。
分担表があると、障害発生時の初動が速くなります。原因の切り分けの順序や、クラウド事業者への問い合わせ役、利用者への報告役があらかじめ決まっているため、混乱が起きにくくなります。RFPの段階で「クラウド側障害の場合、ベンダーはどこまで一次切り分けと連絡調整を担うか」を要件として書いておくと、提案でその対応力を比較できます。
- 分担の対象：物理インフラ、OS、業務データなど、対象ごとの担当
- 障害時の役割：一次切り分け、連絡調整、利用者への報告の担当
クラウドの責任共有モデルでは、ハードウェアより下の基盤はクラウド事業者の側にあります。一方で、その上で動くOSやミドルウェア、アプリケーションは、RFPで一つずつ確かめる必要があります。さらに、データは利用者側（およびその保守ベンダー）が責任を持つという基本構造もあります。
分担表を作るときは、どちらとも言い切れないグレーゾーンを意図的に洗い出すことが肝心です。たとえば、連携先SaaSのAPI仕様変更で自社システムが動かなくなった場合、その改修はベンダーの責任なのか、それとも追加費用なのか。
また、AIを組み込んだシステムで誤った出力が出たとき、その監視と是正は誰の役割か。こうした「どちらの責任とも言い切れない」領域は、後々のトラブルにつながりやすくなります。RFPで具体的なシナリオを示し、誰が一次対応するかを答えさせると、各ベンダーの責任意識と対応力の差が浮き彫りになります。
外部要因による障害時の費用負担
責任分界とセットで定めるべきなのが、外部要因による障害が起きたときの費用負担です。クラウド事業者の障害や、連携SaaSのAPI仕様変更への追従対応は、ベンダーの過失ではないものの、対応には工数が発生します。
この扱いをRFPで問うておかないと、いざというときに想定外の追加費用が発生します。要件定義で「外部要因起因の対応をどう扱うか」を明記することが、後の費用トラブルを防ぎます。
想定外になりがちな費用も、あわせて洗い出しておきます。OSSの保守やデータ復旧、クラウド側の構成変更に伴う再設定などは、平時には発生しませんが、起きると高額になることがあります。
RFPで「どの作業が定額外で、その単価はいくらか」を提示させると、契約後の不意打ちを避けられます。さらに、責任分界点と費用負担を要件として書き込むことは、今のIT環境における定期メンテナンス契約で欠かせない要素と言えます。
- 外部要因の対応：定額の保守費に含めるか、別途の実費精算とするか
- 想定外の費用：OSSの保守、データ復旧、構成変更に伴う再設定
SLAと処理速度の数値要件
定期メンテナンスの品質を担保する要になるのが、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時間の数値をSLAに、全画面3秒以内の応答を性能要件に落とし込むことです。
第四に、価格偏重を避け、SLA達成体制や責任分界の明確さを厚く配点する評価軸を設計することです。
要件定義の目的は、依頼側とベンダーが同じ前提に立ち、品質を約束し合える土台を作ることにあります。とくに責任分界点と外部要因の費用負担は、今のIT環境で最もトラブルになりやすい論点です。ここを丁寧に書き込んだ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を創業。