アプリの運用保守を外部ベンダーに委託するなら、契約の成否を左右するのはRFP（提案依頼書）と要件定義です。業務範囲や責任分界を曖昧にしたまま進めると、障害時に責任のなすり合いへ発展しかねません。そこで要件定義に絞り、アプリ運用保守のRFP・要件定義書・提案依頼書の組み立てを、発注企業の視点から具体的に解説します。
全体像から知りたい方は、まずアプリ運用保守の完全ガイドをご覧ください。価格偏重を避ける評価軸として、価格配点を20点以下に抑える考え方も、運用保守の実務に即して掘り下げます。
スマホアプリ開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スマホアプリ開発の完全ガイドブック」で詳しく解説しています。
責任共有モデルを前提にしたRFPの組み立て方
アプリ運用保守のRFPで最初に固めるべきは、責任分界です。現代のアプリはクラウド上のサーバーやSaaSと連携して動くため、障害が起きたときには「アプリのコードの問題か」「バックエンドの問題か」「クラウド基盤の障害か」の判別が入り組みます。
クラウドの責任共有モデルでは、クラウド事業者が担う範囲と、利用者（およびその運用保守ベンダー）が担う範囲が分かれています。この前提を踏まえずにRFPを書くと、どちらも担当しない責任の空白地帯が生まれます。
アプリ・バックエンド・クラウドの責任分界
RFPでは、運用保守の対象を「アプリ本体（iOS/Androidのクライアント）」「バックエンド（APIサーバー・データベース）」「クラウド基盤（インフラ）」の層に分け、それぞれをどこまでベンダーが担うかを明記します。
たとえば、アプリ本体のクラッシュ修正とOS追従、バックエンドのアプリケーション保守はベンダーが担い、クラウドのハードウェア障害はクラウド事業者のSLAに依拠する、といった切り分けです。
この分界は表にまとめてRFPに添付しておくと、提案ベンダーは自社が担う範囲を明確に理解したうえで見積もれます。
この点は失敗の典型でもあり、関連記事『アプリ運用保守開発・導入の失敗・課題・注意点・リスクについて』もあわせてご覧ください。
責任分界で決めておく点は次の2つです。
- すき間の担当：層と層の境目で起きる障害について、一次切り分けを誰が担うか
- 問い合わせの代行：クラウド事業者への問い合わせを、ベンダーが代わりに行うかどうか
アプリからAPIへの通信が失敗したとき、原因がアプリのリトライ処理にあるのか、サーバーの設定にあるのかは、切り分けてみないと分かりません。
この切り分けの責任を決めておかないと、障害時に双方が「うちの範囲ではない」と主張しかねません。責任のなすり合いを防ぐには、RFPの段階で担当を明記しておくことが最大の予防策です。
準委任と請負の選択と契約に明記すべき免責
運用保守の契約形態には、準委任契約と請負契約があります。準委任は、定められた業務を善管注意義務をもって遂行する契約で、月額定額の運用保守に多く用いられます。
請負は、特定の成果物の完成に責任を負う契約で、機能追加開発などで使われます。
契約で必ず明記したいのは、対象範囲、含まれない業務、免責です。たとえば、「OSのメジャーアップデート対応は含むが、大規模な仕様変更を伴う改修は別途見積り」や「ストアのアカウント費用（Apple Developer Programの年会費等）は発注側負担」といった線引きです。
「クラウド事業者起因の障害はベンダーの免責」といった線引きまで文書化しておくと、後のトラブルを防げます。とくにアプリでは、OSの大規模な仕様変更によって想定外の改修工数が発生することがあります。そのため、追加対応の扱いを契約で定めておく必要があります。曖昧な「運用保守一式」では、いざというときに揉めます。
契約で決めておく点は次の2つです。
- 契約形態：業務ごとに準委任と請負のどちらを想定するか
- 免責：対象範囲、含まれない業務、クラウド事業者起因の障害の扱い
アプリ運用保守の中心は、日々の監視・障害対応という継続業務です。一方で、改修案件を請負で切り出す組み合わせも一般的です。
曖昧な要求をSLAと要件に翻訳する方法
要件定義でつまずく最大の原因は、業務部門から上がってくる要求の曖昧さです。「アプリが落ちないようにしてほしい」「困ったときにすぐ対応してほしい」「いつも快適に使えるようにしてほしい」といった要求は、気持ちは分かるものの、そのままでは契約できる要件になりません。
これらを定量的なSLAと具体的な運用要件に翻訳することが、要件定義の中核作業です。
稼働率・復旧時間のSLA数値化
「落ちないようにしてほしい」は、稼働率という数値に翻訳します。たとえば、大阪市のガイドラインに見られる実値では、稼働率99.8％以上が一つの基準とされています。また、「すぐ対応してほしい」は、障害通知30分以内、復旧6時間以内・4時間以内の遵守率95％、電話応答20秒以内といった応答・復旧時間の数値に置き換えます。
さらに、「快適に使えるように」は、応答3秒以内の達成率93％といったパフォーマンス指標に翻訳できます。こうして数値化すれば、ベンダーは何をどの水準で保証すればよいかを明確に把握でき、達成状況も客観的に評価できます。
バックエンドにデータを持つアプリでは、SLAにRTO（目標復旧時間）とRPO（目標復旧時点）も加えます。RTOは障害発生から復旧までの目標時間、RPOはどの時点のデータまで復旧させるか（許容できるデータ損失量）を指します。
これらは、バックアップの頻度や冗長構成といった非機能要件と直結するため、SLAとセットで要件化しておく必要があります。SLAの設定は、JIS Q 20000のようなITサービスマネジメントの考え方を参照すると、抜け漏れなく整理できます。
数値に置き換えられたかは、次の2点で確かめます。
- 稼働率：「落ちない」に当たる水準を、数値で示せているか
- 復旧時間：障害通知、復旧、応答それぞれの目標値
アプリ固有の運用範囲の要件化
アプリ運用保守の要件定義で、Web保守のテンプレートを流用すると必ず抜け落ちるのが、アプリ固有の運用範囲です。
これらの運用範囲は、放置すると配信停止という致命的な事態を招くため、「あれば望ましい」ではなく「必須」として要件化すべきものです。とくに証明書・鍵の期限管理は地味ですが、失念すると配信やプッシュが止まるため、誰が期限を管理し、更新作業を行うかを要件で明確にしておく必要があります。
アプリ固有の運用範囲をどう機能・役割として整理するかは、関連記事『アプリ運用保守の必要機能や標準機能の一覧について』で詳しく解説しています。要件定義と機能整理をセットで進めると、抜け漏れのないRFPになります。
運用範囲を確認するときは、次の2点を押さえます。
- OS・ストア対応：新OS対応、ストア審査への追従、リリース代行を誰が担うか
- 配信と証明書：クラッシュ監視、プッシュ通知、鍵・証明書の期限管理の担当
要件では、新OS対応がベータ段階からの検証を含むかも明記します。加えて、クラッシュフリー率の目標値と、APNs/FCMに使う鍵・証明書の扱い、Apple Developer ProgramやGoogle Play Consoleのアカウント・証明書の管理も対象になります。これらは項目ごとに、ベンダーが担うかどうかを提案で明示させます。
RFPに盛り込むべき項目と非機能要件
責任分界とSLAを固めたら、それらをRFP（提案依頼書）の形に整えます。RFPは、複数のベンダーから横並びで比較できる提案を引き出すための文書であり、必要な項目を漏れなく盛り込むことで、提案の質と比較可能性が高まります。とくに運用保守のRFPでは、機能要件以上に非機能要件と体制要求の比重が大きくなります。
RFPに必須の記載項目
アプリ運用保守のRFPに盛り込む項目を、目的から順に挙げます。
- 目的と背景：なぜ運用保守を外部委託するのか、現状の課題は何か
- 残りの項目：対象システムの概要からスケジュールまで、次の段落で示します
対象システムの概要：アプリの構成（iOS/Android/バックエンド/クラウド）、ユーザー数、主要機能を記載します。
運用範囲：監視と障害対応を含む日々の運用に加え、アプリのOS追従とストア対応を明記します。さらに、クラッシュ監視とプッシュ運用、証明書管理の範囲も示します。
SLA：稼働率、障害通知時間、復旧時間、RTO/RPOの目標値
非機能要件：セキュリティ、バックアップ、可用性、性能
体制要求：担当者の人数・スキル、連絡体制、対応時間帯
費用方式：月額定額か従量か、改修の扱い
スケジュール：契約開始時期、引き継ぎ期間
これらを網羅すると、ベンダー各社が同じ土俵で提案でき、比較が容易になります。
とくに見落とされがちなのが、引き継ぎに関する記述です。既存アプリの運用保守を新規ベンダーに切り替える場合は、現行ベンダーからの引き継ぎが必要になります。
一次データでは、安全な引き継ぎには約8週間を要し、移行先のPM0.25人月とリードエンジニア1.0人月、現行担当の週2日程度の協力が目安とされています。
RFPに引き継ぎの想定期間と必要な協力体制を記しておくと、ベンダーは引き継ぎ工数を見積もりに織り込めます。
引き継ぎを軽視すると、移行時に運用が空白になるリスクがあります。
セキュリティ・性能・可用性の非機能要件
非機能要件は、運用保守の品質を陰で支える要件です。
これらの非機能要件が曖昧だと、「障害は直したが再発防止策がない」「データ復旧に想定外の時間がかかった」といった事態を招きます。また、想定外の費用を避けるための要件記述も欠かせません。OSSライブラリの保守やデータ復旧といった特殊な作業は、通常の運用保守費に含まれないことがあります。
RFPで「OSSの脆弱性対応は範囲に含むか」「大規模なデータ復旧が必要になった場合の費用の扱い」を問うておくと、後から想定外の追加費用が発生するのを防げます。
非機能要件まで丁寧に詰めたRFPは、ベンダーの見積もりの精度を高め、リリース後の「こんなはずではなかった」を減らします。
非機能要件で確認する点は次の2つです。
- セキュリティと性能：脆弱性への対応方針、SDKの更新追従、応答時間と同時接続数の目標
- 想定外の費用：OSSの脆弱性対応やデータ復旧を、通常の運用保守費に含めるかどうか
セキュリティでは、個人情報の取り扱いも定めます。
可用性では、稼働率に加えて、バックアップ方式やデータ復旧手順（RTO/RPOと連動）を要件にします。
まとめ
アプリ運用保守のRFPと要件定義は、クラウドの責任共有モデルを前提に責任分界を定めることから始まります。業務部門の曖昧な要求は、稼働率99.8％・障害通知30分以内といった定量的なSLAに翻訳します。そのうえで、OS追従・ストア対応・クラッシュ監視・プッシュ・証明書管理というアプリ固有の運用範囲を必須要件として明記することが核心です。
RFPには、目的を示したうえで、運用範囲・SLA・非機能要件を中心に、体制、費用方式、引き継ぎを盛り込みます。評価では、価格の配点を20点以下に抑えて、品質と体制を重視します。これにより、提案を横並びで比べられ、責任の空白や安かろう悪かろうの選定を避けられます。
要件定義の質は、その後の運用保守の質をそのまま決めます。自社だけで作るのが難しい場合は、RFP作成の支援を中立的な専門家に依頼するのも有効な選択です。
riplaはフルスクラッチ受託と国内運用保守を組み合わせ、責任分界を起点とした要件整理、SLA設計、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を創業。