外部に運用保守を委託する際、最初の関門は、RFP（提案依頼書）や要件定義書に何をどこまで書けばよいかという問題です。運用保守のRFPや要件定義書では、責任の分界と数値要件を具体的に書き、保守範囲と評価の軸も明確にします。
成果物が目に見えにくい運用保守は、ここが曖昧だと見積もりの前提がばらつき、契約後の揉め事につながります。この記事は、要件定義に特化して、発注企業が自力でRFPや要件定義書を書けるようになることを目指しています。全体像はシステム運用保守の完全ガイドで先に確認できます。
▼全体ガイドの記事
・システム運用保守の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
クラウド責任共有を前提にしたRFPの書き方
現代の運用保守RFPで、もっとも見落とされやすく、後で揉めやすいのが「責任分界点」です。多くのシステムはAWSなどのクラウド上で動き、外部SaaSとAPI連携しています。そのため、どこからどこまでが誰の責任かを、RFPで示しておく必要があります。
クラウドの障害、連携先SaaSの仕様変更、AIの誤った出力など、ベンダーのコントロール外で起きる事象があります。これらを誰がどう扱うかをRFPで明記しておかないと、障害時に責任のなすり合いが起こります。
クラウド障害・SaaS仕様変更の責任分界の明記
RFPには、想定される「ベンダーのコントロール外」の事象を列挙し、それぞれについて誰が一次対応し、誰がコストを負担するかを書きます。
たとえば、「クラウド基盤側の大規模障害が起きた場合、ベンダーは状況把握と当社への報告を行うが、復旧そのものはクラウド事業者の責任とする」といった書き方があります。同じように、「連携SaaSのAPI仕様変更への追従改修は、月額保守費と別の有償対応とする」と書けば、費用の区分が明確になります。
責任の境界を先に引いておくと、見積もりの前提がそろい、ベンダー比較が公平になります。
とくにAIを組み込んだシステムでは、AIが誤った出力をする「ハルシネーション」をどう扱うかが新しい論点になります。AIの出力品質をどこまでベンダーの責任とするか、人間による確認をどの工程に挟むかを要件として書いておかないと、「AIが間違えたのはベンダーの瑕疵か」という不毛な議論になりかねません。
モダンなIT環境の運用保守RFPでは、新しい責任分界をあらかじめ言葉にしておくことで、競合の優等生フレームの一歩先を行く要件設計になります。
- 事象の洗い出し：クラウド基盤、連携SaaS、AI機能など、構成要素ごとに起こりうる事象を挙げる
- 負担の区分：事象ごとに、ベンダーの一次対応の範囲と有償対応になる範囲を分けて書く
準委任か請負かの要件整理
運用保守のRFPでは、契約形態の前提も整理しておく必要があります。日々の監視やヘルプデスクといった定常運用は、専門的な役務を継続提供する準委任契約が一般的です。
改修プロジェクトのように明確な成果物を納める作業は、請負契約やSESが適しています（出典：ripla）。定常運用と改修を混在させたまま発注すると、責任の所在があいまいになります。
RFPでは、委託業務を「定常運用（準委任）」と「都度の改修案件（請負等）」に分け、それぞれの契約形態を明示しておくと、後の契約交渉で行き違いを減らせます。
とくに準委任では成果の完成を保証しないため、「何をもって役務提供とみなすか」をSLAなどで具体化しておくことが重要です。契約形態を要件の段階で意識しておくことが、契約後の法務上のトラブルを未然に防ぎます。
- 定常運用：監視やヘルプデスクなど、役務を継続して提供する業務は準委任の形で書く
- 都度の改修：明確な成果物を納める改修案件は、請負やSESの形で分けて書く
曖昧な要求の測定可能な要件への翻訳
運用保守の要件定義でつまずく最大の原因は、「安定して動いてほしい」「障害にはすぐ対応してほしい」といった主観的な要求が、そのまま放置されることです。
これでは測定も評価もできず、ベンダーは曖昧さを織り込んで保守的に、つまり高めに見積もります。要件定義の仕事は、こうした曖昧な要求を、誰が見ても同じ意味になる測定可能な要件へ翻訳することです。
「すぐ対応」の時間数値への落とし込み
「障害にはすぐ対応してほしい」という要求は、そのままでは要件になりません。これを「重大障害は初報応答15分以内、復旧4時間以内、通常障害は初報応答2時間以内、復旧8時間以内。また、恒久対応は5営業日以内」といった具体的な時間に落とし込みます（出典：ripla）。
具体的な数値があって初めて、ベンダーは必要な体制を見積もることができ、発注側は提案を同じ基準で比べられます。
同様に、「常に安定して」は稼働率99.9%（月あたり許容停止約43分）や99.5%という数値に、「定期的にメンテナンスを」は月次・四半期といった頻度に翻訳します（出典：ripla）。
翻訳のコツは、自社が本当に必要とする水準を見極めることです。すべてを最高水準にするとコストが跳ね上がるため、「この業務は数時間止まっても致命的ではない」といった実態を踏まえ、水準に差をつけることが、過剰品質と過剰コストを避ける鍵になります。
- 時間の数値：初報応答、復旧、恒久対応のそれぞれに、重大度ごとの時間を書く
- 稼働率と頻度：稼働率の水準と、メンテナンスの頻度を数値や周期で書く
保守範囲の内と外の一覧による線引き
要件定義でもう一つ重要なのが、保守範囲の「内」と「外」を明確に一覧化することです。監視や障害対応、定期メンテナンスといった項目ごとに、どこまでを月額保守費に含め、どこからを別途有償とするかを表にして示します。
軽微改修や問い合わせ対応も同じように区分しておくべきです。とくに軽微改修は、「○人日／月までは保守費内、それを超える改修は別途見積もり」といった上限を定めると、認識のずれを防げます。
この線引きを曖昧にすると、契約後に「これも保守に含まれると思っていた」「いや、それは範囲外だ」という食い違いが頻発します。RFPの段階で「含むもの・含まないもの・条件付きで含むもの」を表で明示しておけば、ベンダーは前提をそろえて見積もり、発注側はサービス内容を正確に比べられます。範囲の明確化は、運用保守の要件定義の中核作業といえます。
- 含むもの：月額保守費の中で対応する業務を、業務名ごとに書く
- 条件付きで含むもの：上限や条件を添えて保守費に含める業務を明記する
範囲を翻訳する際にもう一つ意識したいのが、対象システムの構成情報をRFPに添付することです。利用しているOSやミドルウェアなどのバージョン、連携している外部システムやSaaSを示すと、ベンダーは前提を正しくつかめます。また、想定される利用者数やデータ量といった前提を提示しないと、ベンダーは想像で見積もるしかなく、提案の精度が下がります。
前提情報が揃っているRFPほど、ベンダーは具体的な体制を提案でき、後から「聞いていなかった」という追加費用も生まれにくくなります。曖昧さを翻訳するとは、品質要件を数値にするだけでなく、判断材料となる前提まで漏れなく示すことを指します。
価格偏重を避ける評価軸の設計
RFPの最終段階で問われるのが、集まった提案をどう評価するかです。ここで価格の配点を高くしすぎると、品質を犠牲にして安さで勝負したベンダーが選ばれ、結果として障害の多発や追加費用で高くつくという本末転倒が起こります。
運用保守は長期の継続契約なので、評価軸の設計が長い目で見たコストと品質を左右します。
価格の配点を抑えた体制と実績の評価
運用保守のRFP評価では、価格の配点は意図的に抑え、提案体制や実績などの非価格要素に重みを置くことが推奨されます。
具体的には、対応体制（要員のスキル・人数・対応時間帯）や類似システムの運用実績などを評価項目に立て、それぞれに配点を割り振ります。SLA達成へのコミットや、ドキュメント整備・引き継ぎへの姿勢も評価の対象です。
価格はあくまで「適正範囲に収まっているか」を見る要素にとどめるのが健全です。
適正範囲の物差しには相場が使えます。一次データによると、年間保守費は開発費の15〜20%が目安で、運用要員の人月単価は60万〜150万円です（出典：ripla）。
また、極端に安い提案は「何かを削っているのではないか」と疑い、極端に高い提案は内訳の説明を求めます。価格を絶対額ではなく相場との比較で見ると、安かろう悪かろうの罠を避けられます。
- 非価格要素：体制、実績、対応品質、継続性など、配点を厚くする評価項目
- 価格の見方：絶対額だけでなく、相場と比べて適正かどうかで判断する
移管・乗り換えを見据えた継続性の評価項目
運用保守は長期契約ですが、いつか別のベンダーへ移管する可能性も見据えておくべきです。
評価軸には、「ドキュメントを整備し、第三者でも運用を引き継げる状態を保つか」「ソースコードや設定情報を発注者が把握できる形で管理するか」といった継続性・移管容易性の項目を入れておきましょう。
これにより、特定ベンダーへの過度な依存（ロックイン）を未然に防げます。将来の乗り換え時に、受け渡しが難航するリスクも下がります。
riplaはフルスクラッチ受託と国内開発の立場から、発注者がいつでも全体像を把握できる透明な運用を重視しています。こうした移管容易性の要件は、健全なベンダー関係の前提にもなります。評価軸に継続性を組み込むことが、長期の安心につながります。
- 引き継ぎの条件：乗り換えを想定し、契約終了時に渡す運用ドキュメントの範囲を決めておく
- 情報の把握：ソースコードや設定情報を、発注者が追える形で管理しているかを見る
SLAと処理速度の数値要件の書き方
RFPの心臓部となるのが、SLA（サービス品質保証）と処理速度に関する数値要件です。これらは運用保守の品質を客観的に測る基準であり、ここを具体的に書けるかどうかで、RFP全体の精度が決まります。
抽象的な言葉を避け、検証できる数値で品質を定義しましょう。
稼働率・応答・復旧のSLA条文への落とし込み
SLA要件は、稼働率・応答時間・復旧時間の三本柱で書きます。稼働率は99.9%（月あたり許容停止約43分）や99.5%といった水準を、応答時間は重大15分・通常2時間、エスカレーション30分、回答24時間と定めます。
復旧時間は重大4時間・通常8時間、恒久対応は5営業日といった数値を要件として明記します（出典：ripla）。
これらを表にまとめ、障害の重大度区分（ランク分け）の定義も添えることで、ベンダーは前提をそろえて提案できます。
SLA要件で忘れてはならないのが、未達時の扱いです。目標を達成できなかった場合に、原因報告や改善計画の提出を求めるのか、保守費の減額（ペナルティ）まで定めるのかを要件に含めます。
ペナルティは、原因がうやむやになって適用されないこともあります。そのため、「どの指標が、どの測定方法で、どの期間に未達なら適用されるか」まで具体化しておくことが、実効性を持たせる鍵になります。
- 稼働率：許容する停止の水準を、数値で示す
- 応答・復旧：重大と通常の区分ごとに、応答、復旧、恒久対応の時間を分けて書く
処理速度・性能の数値のRFPへの明記
SLAに加えて、システムの性能に関する数値要件も書いておくと、運用保守の品質基準がより明確になります。
たとえば「全画面のレスポンスは3秒以内」といった処理速度要件は、RFPでよく用いられる指標です（出典：ripla）。応答速度が劣化したときに「何をもって遅いとするか」の基準があれば、性能改善の責任範囲もはっきりします。
定義の範囲を先に決めておくと、運用フェーズでの検証の基準がぶれにくくなります。
性能は利用者数の増加とともに劣化しがちなため、「想定ユーザー数の範囲では○秒以内を維持する」という条件付きの要件にすると現実的です。
riplaはフルスクラッチ受託と国内開発の立場から、こうした数値要件を要件定義の段階で発注者と一緒に詰め、運用後の品質基準として機能させることを重視しています。数値で品質を語れるRFPこそ、良いベンダーを引き寄せる土台になります。
- 対象と条件：対象画面や処理、同時アクセス数、測定条件を定義に含める
- 利用者数の前提：想定ユーザー数の範囲を示し、その範囲内の性能を要件にする
まとめ
運用保守のRFPや要件定義書で押さえる要点は、四点に集約されます。
第一に、クラウドやSaaS連携を前提とした責任分界点を明記することです。
第二に、「すぐ対応」「安定して」といった曖昧な要求を、時間や稼働率の数値へ翻訳し、保守範囲の内と外を一覧にすることです。
第三に、価格の配点を抑えて体制・実績・継続性を評価軸に据えることです。
第四に、SLA（稼働率99.9%、初報応答15分など）と処理速度（全画面3秒以内など）を、検証可能な数値要件として書くことです。いずれも、一次データの相場を物差しにして、過剰品質と過剰コストを避けることが大切です。
要件定義で本当に大切なのは、ベンダーに丸投げできる立派な書類を作ることより、自社が本当に必要とする品質を、誰が見ても同じ意味になる言葉で定義することです。数値で品質を語れるRFPは、ベンダーの前提をそろえ、公平な比較を可能にし、契約後のトラブルを減らします。
riplaはフルスクラッチ受託と国内開発を組み合わせ、要件定義の段階から発注者の目線で品質要件を一緒に整理する支援を行っています。全体像の確認には、あらためて完全ガイドをご活用ください。
▼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を創業。