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