ITシステムの保守構築を外部に委託するとき、要件定義書やRFP（提案依頼書）の作り込みが、その後の保守の質と費用を大きく左右します。開発のRFPと違い、保守は「動いて当たり前」の領域なので要件が曖昧になりやすく、結果として「何かあったら見ます」という程度の薄い契約のまま、いざ障害が起きてから揉める、というケースが後を絶ちません。だからこそ、保守に求める品質を数値で定義し、責任の境界を明文化したRFPを作ることが、安心して任せられる保守体制への第一歩になります。
本記事は、ITシステム保守構築のRFP・要件定義書・提案依頼書を、発注企業の視点から実務的に解説する「要件定義特化」の内容です。クラウドの責任共有を前提とした保守要件、曖昧な要求を数値要件へ翻訳する方法、SLAと処理速度の定量要件、価格配点を抑えたベンダー評価軸まで、一次データとあわせて具体的に紹介します。読み終えるころには、自社の保守RFPに何を書き込むべきかが明確になるはずです。なお、ITシステム保守構築の全体像をまだ把握していない方は、まずITシステム保守構築の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・ITシステム保守構築の完全ガイド
クラウド責任共有を前提にした保守RFPの組み立て
保守構築のRFPで現代的に最も重要なのが、クラウドの責任共有モデルを前提に保守の範囲を定義することです。多くのシステムはAWSやクラウド基盤、外部SaaSと連携して動いており、障害の原因がどこにあるかによって責任の所在が変わります。RFPの段階でこの責任分界を整理しておかないと、運用開始後に「それはクラウド側の問題なので対象外」という想定外の空白地帯が生まれます。
責任分界点をRFPに明記する
RFPには、自社・保守ベンダー・クラウド事業者・SaaS提供元のそれぞれが、どの層の何に責任を持つかを表として示すことが望まれます。たとえば、アプリケーションの不具合はベンダー、クラウド基盤の障害はクラウド事業者、連携SaaSのAPI仕様変更は提供元、といった切り分けです。そのうえで、ベンダーのコントロール外で障害が起きたとき、保守ベンダーが「何をどこまで対応するのか」を要件として書き込みます。
たとえばクラウド基盤の大規模障害時に、原因の切り分けと暫定対応の支援、復旧後の影響確認までを保守の範囲に含めるのか、あるいは別途費用とするのかを明確にします。連携SaaSのAPI仕様変更への追従改修も、定期保守の範囲か追加開発かを定義しておきます。この責任分界の明記こそ、競合のRFPに欠けがちな視点であり、現代の保守構築で差がつくポイントです。
想定外費用をRFPで先回りして手当てする
保守の現場で発注側を悩ませるのが、契約に含まれていなかった想定外の費用です。OSやミドルウェアの大規模なバージョンアップ、サポート切れに伴う移行、外部要因による大規模なデータ復旧などは、通常の月額保守に含まれないことが多く、いざ必要になったときに高額な追加見積が出てきます。RFPの段階で、こうした非定常作業の扱いと概算費用の考え方を問うておくことが重要です。
具体的には、「想定される大型作業（OSアップグレード等）が発生した場合の費用算定方法」「外部要因による障害復旧の費用負担」「データ復旧やセキュリティインシデント対応の扱い」をRFPで明示的に質問項目に入れます。これにより、提案段階で各ベンダーの考え方が比較でき、後から想定外費用で揉めるリスクを減らせます。RFPは、平常時だけでなく非常時の費用までを設計する文書だと捉えるべきです。
こうした非定常作業は、実は構成を把握していればある程度は事前に予測できます。利用しているOSやミドルウェアのサポート期限、データ量の増加ペースを棚卸ししておけば、「来年あたりに大きな移行が必要になる」といった見通しが立ちます。RFPの段階で、ベンダーにこうした中長期のリスクの洗い出しと、それに備える計画の提案まで求めておくと、想定外を「想定済み」に変えられます。突発的な高額請求の多くは、予兆があったのに見ていなかっただけ、というケースが少なくありません。
曖昧な要求を数値要件に翻訳する要件定義
保守の要件定義でつまずきやすいのが、「安定して動いてほしい」「すぐ対応してほしい」といった曖昧な要求です。これらは気持ちは分かるものの、そのままでは提案も評価もできません。要件定義の核心は、こうした感覚的な要求を、誰が見ても同じ意味になる数値要件へ翻訳することにあります。
「安定して動いてほしい」を稼働率に翻訳する
「安定して動いてほしい」という要求は、稼働率という数値に翻訳できます。たとえば稼働率99.9%なら、月間で許容される停止時間は約43分です（出典：ripla）。99.5%まで緩めるか、99.9%を求めるかで、必要な冗長構成や監視体制、ひいては保守費が変わります。要件定義では、自社の業務にとって「どれだけの停止までなら許容できるか」を業務影響から逆算して数値を決めます。
大切なのは、過剰な稼働率を求めないことです。事業への影響が限定的なシステムに99.99%を求めれば、保守費は跳ね上がります。逆に、止まると事業が止まる基幹システムなら、相応の数値とコストを覚悟します。要件定義は、漠然とした不安をそのまま高い要求にするのではなく、業務影響に見合った数値へ落とし込む作業です。この翻訳ができると、提案の比較が一気に容易になります。
稼働率を数値化するときは、計画停止と計画外停止を区別しておくことも忘れてはいけません。定期メンテナンスのための計画的な停止まで稼働率に含めて計算すると、現実離れした厳しい数値になってしまいます。要件定義では、メンテナンス枠を稼働率の計算からどう扱うか、計画停止をいつ・どれだけ許容するかも明記します。こうした計測の前提まで揃えて初めて、各ベンダーの提案を同じ土俵で比較できるのです。
「すぐ対応してほしい」を応答・復旧時間に翻訳する
「すぐ対応してほしい」という要求は、初報応答時間・復旧時間といったSLA指標に翻訳します。要件の目安としては、重大障害の初報応答15分・通常障害2時間、エスカレーション30分、回答24時間、復旧は重大4時間・通常8時間、恒久対応5営業日といった水準があります（出典：ripla）。障害の重大度ごとに、いつまでに何をするかを段階で定義するのがポイントです。
さらに、対応の受付時間帯（平日日中のみか、24時間365日か）も要件として明記します。24時間対応は安心ですが、待機要員のコストが上乗せされるため、自社の業務時間と事業影響に合わせて選びます。要件定義で重大度の定義と対応時間を数値化しておけば、障害発生時に「これは重大か通常か」で揉めることもなくなります。曖昧な要求を放置せず、すべて数値と段階に翻訳することが、要件定義の質を決めます。
SLA・処理速度の定量要件と契約形態の設計
要件定義書では、保守の品質を数値で約束させるSLAと、システムの性能を担保する処理速度の要件、そしてそれを支える契約形態をセットで設計します。これらが揃って初めて、保守は「約束に基づくサービス」になります。逆に、ここが曖昧だと、いくら立派な提案書をもらっても、運用が始まってから期待と現実のずれに苦しみます。
処理速度を数値要件として書く
システムの使い勝手を左右する処理速度も、要件定義で数値化すべき項目です。RFPの例としては「全画面の表示を3秒以内」といった応答時間の要件が挙げられます（出典：ripla）。保守の文脈では、運用を続ける中で性能が劣化しないこと、データ量が増えても一定の速度を維持することを要件に含めます。性能が約束された数値を下回ったときの調査・改善も保守の範囲に入れておきます。
処理速度の要件は、ピーク時の同時アクセス数や、扱うデータ量の増加見込みとあわせて定義すると実効性が高まります。平常時は速くても、業務が集中する時間帯に遅くなるシステムは少なくありません。要件定義で「どの条件下で、どの速度を保つか」を数値で示すことで、保守ベンダーは監視やチューニングの体制を設計できます。性能を曖昧にせず数値で握ることが、長く快適に使えるシステムへの条件です。
準委任・請負と契約形態をRFPで設計する
保守の契約形態は、業務の性質に応じて準委任と請負を使い分けます。監視や問い合わせ対応のように、成果物が明確でない定常運用は準委任が適しており、特定の改修や移行のように成果物が明確な作業は請負が向きます（出典：ripla）。要件定義では、どの業務をどの契約形態で結ぶかを整理し、それぞれの責任と検収の考え方を明確にします。
契約形態の設計を曖昧にすると、準委任なのに成果を厳しく問われたり、請負なのに範囲が際限なく広がったりと、双方が不幸になります。RFPの段階で契約形態の方針を示し、提案時に各ベンダーの考えを確認しておくと、後の契約交渉がスムーズです。要件定義は技術仕様だけでなく、こうした法務・契約の枠組みまで含めて設計する文書であり、ここを丁寧に作ることが安定した保守関係の土台になります。
とくに注意したいのが、保証型SLAと準委任契約の整合です。準委任は善管注意義務を負うものの結果そのものを保証しない契約のため、稼働率を「保証」する条項とどう両立させるかが論点になります。要件定義では、SLAのペナルティ条項を準委任の枠内でどう機能させるか、計測と判定の方法をどう定めるかまで踏み込んで設計します。契約形態とSLAをばらばらに決めると、いざというときに条文が空回りするため、両者をセットで詰めておくことが実効性の鍵になります。
価格配点を抑えたベンダー評価軸の設計
RFPの最後の要は、提案を受けてどう評価するかという評価軸の設計です。保守はとくに、目先の安さに飛びつくと品質で痛い目を見やすい領域です。価格の配点を意図的に抑え、保守体制や技術力、過去の実績を重視する評価軸を組むことが、長期的に満足できるベンダー選定につながります。
価格の配点を下げ品質を重視する
評価軸で価格の配点を高くしすぎると、各ベンダーが体制を削って安値を提示し、結果として運用が始まってから「対応が遅い」「人が足りない」という問題に直面します。これを避けるには、価格の配点を全体の3割程度に抑え、残りを保守体制の充実度、障害対応の手順、SLA達成への具体策、技術者のスキルといった品質項目に配分します。安さではなく総合力で選ぶ設計です。
その前提として、保守費の相場観を押さえておくことが評価の助けになります。年間保守費は開発費の15〜20%が目安で、規模別の月額は小規模5〜15万円、中規模15〜50万円、大規模50〜200万円以上、運用要員の人月単価は60万〜150万円が一つの水準です（出典：ripla）。極端に安い提案は、必要な体制を備えていない可能性を疑い、内訳を確認します。
逆に、極端に高い提案も鵜呑みにせず、その金額の根拠を内訳から確かめます。多重下請けの構造や過剰な待機要員のコストが上乗せされていないか、本当に自社のシステムに必要な体制なのかを見極めます。評価軸に内訳の妥当性を組み込んでおけば、安すぎる提案と高すぎる提案の両方を、相場と照らして冷静に判断できます。価格は単独の数字ではなく、その内訳と提供される体制とセットで評価することが、後悔しない選定につながります。
移管しやすさとロックイン回避を評価に入れる
評価軸には、将来そのベンダーから乗り換える際の移管しやすさも入れておきます。ドキュメントを整備して引き継げる状態を保つか、ソースコードの著作権や独自パッケージの扱いがロックインにつながらないか、といった点です。RFPで「契約終了時の引き継ぎ方針」「ソースコードと成果物の権利帰属」を質問項目に入れ、その回答を評価に反映します。
最初の選定でロックインのリスクを評価しておくことが、数年後に保守費が高止まりしたときの交渉力を担保します。riplaはフルスクラッチ受託と国内運用保守の立場から、ドキュメントを整え、発注側が主導権を持ち続けられる保守構築を重視しています。RFPと要件定義は、目先の発注だけでなく、数年スパンで主導権を握り続けるための設計図です。価格・品質・移管しやすさをバランスよく評価軸に組み込むことが、後悔しない保守ベンダー選定の鍵になります。
保守スコープと開示資料をRFPで定義する
数値要件やSLAをいくら精緻に書いても、「どこからどこまでを保守の対象とするか」というスコープが曖昧だと、RFPは機能しません。保守は範囲がにじみやすい領域であり、どの作業が含まれ、どの作業が別費用かを最初に線引きしておかないと、運用が始まってから「それは範囲外です」「いや含まれるはずだ」という争いが絶えなくなります。RFPの段階で、保守スコープと、ベンダーへ開示する資料を明確に定義しておくことが、提案の精度と公平性を高めます。
含む作業と含まない作業を一覧で線引きする
RFPでは、保守に含む作業を具体的に列挙します。監視、定期メンテナンス、障害対応、問い合わせ対応、軽微改修、アップデート・リリース管理、定例報告といった項目を、保守費の内訳（定期保守20〜30%、監視15〜25%、障害対応25〜35%、問い合わせ10〜20%、軽微改修10〜15%、管理報告5〜10%）の考え方とあわせて整理しておくと、提案各社が同じ前提で見積もれます（出典：ripla）。曖昧な「一式」ではなく、項目ごとに範囲を示すことが重要です。
同時に、含まない作業も明記します。OS・ミドルウェアの大規模アップグレード、新機能の開発、大規模なデータ復旧、外部要因による障害対応などは、通常の月額保守に含めるか別費用とするかを線引きします。とくに軽微改修と本格開発の境界は揉めやすいため、月あたりの改修工数の上限や、それを超えた場合の単価をRFPで提示させます。含む・含まないを一覧で示すこの線引きが、運用開始後のトラブルを未然に防ぐ最大の予防策です。
正確な見積を引き出す開示資料を揃える
ベンダーから正確で比較可能な提案を引き出すには、判断材料となる資料の開示が欠かせません。システム構成図、利用しているOS・ミドルウェア・ライブラリの一覧、現在の運用手順、過去の障害件数や対応履歴、想定する利用者数やデータ量などを、RFPに添付するか開示の意思を示します。情報が乏しいと、各ベンダーはリスクを大きく見積もって高めの金額を出すか、逆に楽観的に安く出して後で揉めるかのどちらかになりがちです。
開示資料が整っていること自体が、移管のしやすさやロックインの回避にも直結します。既存ベンダーがこうした資料を残していなければ、それ自体が現状の保守体制の弱点であり、新たなRFPを機にドキュメントを整備し直す好機です。RFPは、単に提案を募る文書ではなく、自社のシステムを棚卸しし、情報を発注側の手元に取り戻す作業でもあります。正確な見積を引き出す開示資料を揃えることが、公平なベンダー選定と、その後の健全な保守関係の土台になります。
まとめ
ITシステム保守構築のRFP・要件定義書を整理すると、クラウドの責任共有を前提に責任分界と想定外費用を手当てし、「安定」「すぐ対応」といった曖昧な要求を稼働率99.9%や復旧時間といった数値に翻訳し、処理速度の定量要件と準委任・請負の契約形態を設計し、価格配点を抑えて品質と移管しやすさを重視する評価軸を組む、という流れが見えてきます。年間保守費は開発費の15〜20%という相場観も、提案を評価する物差しになります。
RFPと要件定義で大切なのは、平常時の便利さだけでなく、障害時や契約終了時という非常時まで含めて設計することです。責任分界を明記し、数値要件で品質を握り、ロックインを避ける条項を入れておけば、保守は安心して任せられるサービスになります。riplaはフルスクラッチ受託と国内運用保守を組み合わせ、発注側が主導権を保てる保守構築のRFP設計を支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。