SE・SIerに運用保守を委託するために相見積もりを取りたいが、「何をどう書けばベンダーから比較可能な提案が返ってくるのか分からない」という壁にぶつかる情報システム担当者は少なくありません。運用保守のRFP（提案依頼書）や要件定義書は、開発のそれとは性質が異なります。作るものの仕様ではなく、「動き続ける状態をどう保証してもらうか」という、サービス品質と運用プロセスを言語化しなければならないからです。ここが曖昧なまま発注すると、各社バラバラの前提で見積もりを出してきて、金額を横並びで比べることすらできなくなります。
本記事は、SE・SIerの運用保守を委託する際のRFP・要件定義書・提案依頼書を、ユーザー企業が比較可能な提案を引き出せる形でまとめるための「要件定義特化」の解説です。クラウドの責任共有を前提とした責任分界の記述、曖昧な要求を数値要件に翻訳する方法、SLAと処理速度の定量要件の書き方、そして価格配点を抑えた評価軸の設計まで、一次データとあわせて具体的に解説します。なお、SE・SIerの運用保守の全体像をまだ把握していない方は、まずSE/SIerの運用保守の完全ガイドから読むことをおすすめします。読み終えるころには、自社のRFPに不足している項目が見えてくるはずです。
▼全体ガイドの記事
・SE/SIerの運用保守の完全ガイド
クラウド責任共有を前提にした責任分界の記述
現代の運用保守RFPでもっとも重要かつ抜けやすいのが、責任分界点の記述です。SaaS・クラウド・AI連携が当たり前になった今、障害の原因がベンダーのコントロール外にあるケースが急増しています。クラウド事業者側の障害、連携SaaSのAPI仕様変更、AIのハルシネーション——これらが起きたとき、誰がどこまで責任を負い、費用を誰が持つのかをRFP段階で定義しておかないと、いざ障害が起きてから泥沼の押し付け合いになります。
ベンダーのコントロール外障害をRFPで定義する
RFPには、「クラウド事業者側の障害が発生した場合の一次切り分け・状況報告・復旧支援の責任範囲」を明記すべきです。たとえばクラウドのリージョン障害でシステムが停止したとき、保守ベンダーには復旧の義務はなくとも、状況把握と顧客への報告、復旧後の動作確認は担ってほしいはずです。この「直せない障害でも、何をしてくれるのか」を要件として書くことで、提案各社の運用設計の差が見えてきます。連携SaaSのAPI仕様変更についても、その追従改修を月額に含めるのか、別見積もりにするのかを問う設問をRFPに入れておきます。
責任分界の記述では、稼働率SLAの「対象範囲」を明確にすることも欠かせません。稼働率99.9%（月の停止許容約43分）を要求する場合でも（出典：ripla）、それが自社開発部分のみを対象とするのか、クラウド基盤の障害も含むのかで、ベンダーが負うリスクはまったく異なります。クラウド基盤の障害まで含めて99.9%を保証させると、ベンダーは責任を取れずに高い見積もりを出すか、辞退します。責任の境界線を現実的に引くことが、適正な提案を引き出す鍵です。
準委任か請負かを契約形態としてRFPで指定する
運用保守の契約形態は、業務の性質によって準委任と請負を使い分けます。監視・障害対応・問い合わせ対応といった定常的な運用は、成果物ではなく稼働を提供する準委任が一般的です。一方、特定の軽微改修や仕様変更のように、明確な成果物を伴う作業は請負やSESで対応するのが通例です。RFPには、どの業務をどの契約形態で委託したいかを明示し、提案側に契約形態の前提を揃えさせることが重要です。
契約形態を曖昧にしたまま発注すると、後で「これは準委任の範囲なので別途見積もりです」という争いが起きます。とくに改修系の作業は、月額の準委任に含まれる範囲と、都度請負で見積もる範囲の線引きを、RFPで明確にしておくべきです。法務的にも、準委任と請負では瑕疵担保や成果責任の扱いが異なるため、契約形態の指定は単なる事務ではなく、トラブル時の責任を左右する重要な要件定義事項だと認識してください。
曖昧な要求を数値要件に翻訳する書き方
運用保守のRFPで提案がバラつく最大の原因は、要求が曖昧なことです。「迅速に対応してほしい」「安定稼働させてほしい」といった表現は、人によって解釈が異なり、各社が自社に都合のよい前提で見積もります。比較可能な提案を引き出すには、こうした曖昧な要求を、誰が読んでも同じ意味になる数値要件へ翻訳する必要があります。
SLAを数値で書く（応答・復旧・稼働率）
「迅速に対応」は、応答時間の数値に翻訳します。一次データの実務水準を参考にすると、初報応答は重大障害15分・通常障害2時間、エスカレーション30分、回答24時間、復旧目標は重大障害4時間・通常障害8時間、恒久対応5営業日といった具体値で要件化できます（出典：ripla）。「安定稼働」は稼働率の数値に翻訳し、99.9%（月の停止許容約43分）または99.5%のいずれを求めるかをRFPに明記します（出典：ripla）。これらの数値を提示すると、提案側は「その水準を満たすために必要な体制と費用」を具体的に積み上げて見積もるため、比較可能性が一気に高まります。
障害の重要度区分（重大・通常・軽微など）を定義し、区分ごとに応答・復旧時間を変えることも、現実的なRFPのポイントです。すべての障害に15分応答を求めると過剰な体制が必要になり費用が跳ね上がります。業務影響の大きさで区分し、重大障害だけ厳しいSLAを課すことで、コストと品質のバランスが取れます。曖昧な要求の翻訳とは、単に数字を入れることではなく、「どこに厳しさを集中させるか」を設計する作業でもあります。
処理速度などの性能要件もRFPで数値化する
運用保守のRFPでは、障害対応だけでなく、システムが満たすべき性能水準も数値で定義しておくと、保守の評価基準になります。実際のRFP例では「全画面の表示を3秒以内」といった処理速度の要件が設定されることがあります（出典：ripla）。この性能要件があると、保守の過程で性能が劣化した場合に「劣化した」と客観的に判定でき、改善を求める根拠になります。性能要件のないRFPでは、遅くなっても「もともとそういうものです」と言われて終わってしまいます。
数値化すべき要件は、応答時間・稼働率・処理速度だけではありません。バックアップの取得頻度と保持世代数、復元の所要時間、監視の間隔、月次報告の提出期限なども、すべて数値で書けます。RFPに数値要件のリストを設け、各社にその達成可否と前提を回答させると、提案の精度が揃います。曖昧さを残した項目こそ、後の追加費用やトラブルの火種になる、という前提でRFPを点検してください。
価格配点を抑えた評価軸の設計
RFPで集めた提案をどう評価するか、その評価軸の設計もまた要件定義の一部です。運用保守の提案を価格だけで選ぶと、安かろう悪かろうの体制に当たり、結局は障害多発や追加費用で高くつきます。価格の配点を意図的に抑え、運用設計の質や体制、ドキュメント整備の方針を重く評価する軸を、RFPの段階で示しておくことが、長期的に満足できる委託先選びにつながります。
費用内訳の提示を必須要件にする
価格を一式で出させると、各社の前提が見えず比較できません。RFPでは、費用を機能別の内訳で提示するよう義務づけます。定期保守・監視・障害対応・問い合わせ対応・軽微改修・管理報告という費目で分けて見積もらせると、相場の内訳（定期保守20〜30%、監視15〜25%、障害対応25〜35%、問い合わせ10〜20%、軽微改修10〜15%、管理報告5〜10%）と照らして妥当性を判断できます（出典：ripla）。年間保守費は開発費の15〜20%が目安であり（出典：ripla）、この相場から大きく外れる提案は、その理由を問うべきです。
運用要員の人月単価は60万〜150万円が相場とされ（出典：ripla）、提案の体制と単価を内訳から逆算すると、何人月でその金額になっているかが見えてきます。極端に安い提案は、待機要員を持たず属人的に回す薄い体制か、多重下請けで責任が曖昧になっている可能性があります。内訳の提示を必須要件にすることで、価格の安さの「中身」を評価できるようになります。
ロックイン回避をRFPの要件に組み込む
将来のベンダー乗り換えを見据えるなら、RFPの段階でロックイン回避を要件化しておくべきです。具体的には、運用手順書・障害対応履歴・構成情報といったドキュメントを成果物として定期的に納品させること、ソースコードの著作権の帰属、契約終了時の引き継ぎ協力義務を、要件として明記します。これらを後から契約に追加しようとしても、ベンダー側に交渉力が移っており、独自パッケージ派生やソースコード著作権を盾に移管を拒まれる「法的ロックイン」に陥りがちです。
評価軸としては、「契約終了時にスムーズに別ベンダーへ移管できる状態を、平時からどう維持するか」という設問を設け、その回答の具体性を評価します。ドキュメントを継続的に整備し、属人化を避ける運用を提案できるベンダーは、ロックインのリスクが低く、長期的に健全な関係を築けます。RFPは目先の委託先を決めるだけでなく、数年後に困らないための保険でもある、という視点で評価軸を設計してください。
移管・引き継ぎとドキュメント納品の要件定義
運用保守のRFPで見落とされがちなのが、「契約が始まるとき」と「契約が終わるとき」の引き継ぎに関する要件です。新規にベンダーを切り替える場合の移管受け入れ、そして将来このベンダーから別のベンダーへ移る場合の引き渡し——この入口と出口の要件を定義しておかないと、移管時の混乱や、ドキュメント不足による実質的なロックインを招きます。RFPは目先の運用だけでなく、契約のライフサイクル全体を見据えて書くべきものです。
移管受け入れ期間と二重コストをRFPで明示する
既存システムの保守を新しいベンダーに切り替える場合、RFPには「移管受け入れ（引き継ぎ）にどれだけの期間と体制をかけるか」を要件として書きます。保守移管は通常2〜3か月を要し、その間は旧ベンダーへの保守費と新ベンダーへの学習・調査費が並行して発生する二重コストが避けられません。この移管期間をRFPで明示し、提案側に移管計画と移管費用を別建てで提示させると、移管の巧拙を提案段階で評価できます。移管期間中に新ベンダーが何を理解し、どのドキュメントを引き継ぐべきかを、受け入れ要件として具体的に列挙しておくことが重要です。
移管の要件では、旧ベンダーの協力をどう取り付けるかも論点になります。新ベンダー側のRFPだけでは旧ベンダーは動かないため、現行契約に引き継ぎ協力義務がない場合は、移管そのものが難航します。RFPには「旧環境の情報がどこまで提供される前提か」を明示し、情報が不足する場合の調査工数の扱いを提案に含めさせます。年間保守費は開発費の15〜20%が相場とされますが（出典：ripla）、移管初年度はこの相場に二重コストが上乗せされることを前提に、複数年のTCOで評価する設計をRFPに織り込んでおくべきです。
ドキュメント納品の頻度と粒度を要件化する
将来の出口を確保するうえで決定的なのが、ドキュメント納品の要件です。RFPには、運用手順書・構成情報・障害対応履歴・改修の経緯といったドキュメントを、どの頻度で、どの粒度で、どの形式で納品するかを明記します。「ドキュメントは整備します」という曖昧な約束では、いざ移管しようとしたときに「最新化されていない」「担当者の頭の中にしかない」という事態に陥ります。納品物リストとして具体的な文書名と更新頻度を要件化することが、ブラックボックス化を防ぐ唯一の方法です。
ドキュメント要件は、契約終了時の引き渡し義務とセットで定義します。契約終了時に、最新のドキュメント一式と運用ノウハウを別ベンダーへ引き継ぐ協力を、提供義務としてRFPに書き込んでおくのです。あわせて、ソースコードの著作権の帰属や、契約終了後の利用・改変・第三者開示の権利も要件として明示します。これらを後から契約に追加しようとすると、ベンダー側に交渉力が移り、独自パッケージ派生やソースコード著作権を盾に拒まれる「法的ロックイン」に陥りがちです。出口の要件を入口のRFPで握ることが、数年後の自由を守る最大の防衛策になります。
運用体制・連絡体制とセキュリティの要件定義
SLAや費用の数値要件を固めても、それを実行する「体制」と「連絡の仕組み」、そして「セキュリティ」の要件が抜けていると、いざというときに機能しません。誰が、いつ、どう動くのかをRFPで定義しておかないと、障害時に「担当者が捕まらない」「夜間は対応しない」といった想定外に直面します。比較可能な提案を引き出すには、運用体制・連絡体制・セキュリティも、SLAと同じ精度で要件化しておく必要があります。
対応時間帯・エスカレーション経路をRFPで定義する
運用体制の要件では、まず「いつ対応するか」を定義します。平日日中のみか、夜間・休日も含む24時間365日か、対応時間帯によって必要な体制と費用は大きく変わります。すべてを24時間対応にすると過剰な費用になるため、重大障害だけ夜間も対応し、軽微なものは翌営業日とする、といったメリハリをRFPで指定します。運用要員の人月単価は60万〜150万円が相場とされ（出典：ripla）、対応時間帯の広さは見積もりに直結するため、自社に本当に必要な範囲を見極めて要件化することが、費用の妥当性を保つ鍵です。
連絡体制では、エスカレーション経路を要件として明示します。障害発生時に、誰が一次受けし、どの基準で誰へエスカレーションし、最終的にどこまで上げるのか——この経路が曖昧だと、初報応答15分・エスカレーション30分といったSLAを掲げても（出典：ripla）、実際には連絡が滞ります。窓口の一本化、緊急連絡先、報告のフォーマットと頻度を要件に含め、提案側に体制図とともに回答させると、各社の運用設計の実力が見えてきます。体制は「人数」だけでなく「動き方」まで要件化することが重要です。
セキュリティ・コンプライアンスの要件を明記する
運用保守のRFPでは、セキュリティとコンプライアンスの要件も欠かせません。脆弱性情報への対応、セキュリティパッチの適用基準、不正アクセス監視の有無、インシデント発生時の報告義務などを要件として定義します。OSSのサポート終了（EOL）への対応をどこまで保守でカバーするかも、ここで明確にしておくべき論点です。これらが曖昧なまま契約すると、いざ脆弱性が見つかったときに「対応は範囲外」とされ、想定外の追加費用や、最悪の場合はセキュリティインシデントを招きます。
取り扱うデータの性質によっては、個人情報保護や業界固有の規制への準拠も要件になります。アクセス権限の管理、操作ログの保全、データの保管場所や暗号化の要件を、RFPに盛り込みます。クラウド環境では、セキュリティの責任がクラウド事業者とユーザー企業・SE・SIerの間で分担される「責任共有モデル」が前提となるため、どの層のセキュリティを保守ベンダーが担うのかを要件として切り分けておく必要があります。セキュリティとコンプライアンスの要件は、平時には見えにくいものの、有事には事業の存続を左右するため、SLAと同等の重みでRFPに記述すべきです。
まとめ
SE・SIerの運用保守のRFP・要件定義書を整理すると、比較可能な提案を引き出す鍵は「責任分界をクラウド前提で明文化し、曖昧な要求を数値要件に翻訳し、価格配点を抑えた評価軸を設計する」という三点に集約されます。クラウド事業者障害やSaaSのAPI変更といったコントロール外の事象の責任範囲を定め、準委任か請負かの契約形態を指定し、初報応答15分・復旧4時間・稼働率99.9%・全画面3秒といった数値で要求を翻訳することで、各社の提案が同じ土俵に乗ります（出典：ripla）。
RFPを作るうえで大切なのは、「作るものの仕様」ではなく「動き続ける状態をどう保証してもらうか」を言語化することだという発想の転換です。費用内訳の提示を必須にし、移管受け入れとドキュメント納品の要件を入口で握ってロックイン回避を組み込めば、目先の安さに惑わされず、数年先まで健全に付き合える委託先を選べます。riplaはフルスクラッチ受託と国内運用保守の立場から、責任分界と数値SLAを織り込んだ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を創業。