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