クラウド開発・構築を外部に委託するとき、プロジェクトの成否をもっとも大きく左右するのが、RFP（提案依頼書）と要件定義書の質です。「とりあえずクラウドに移行したい」という曖昧な依頼でベンダーに丸投げすると、過剰なスペックで見積もられたり、移行後に転送量や仕様変更の追加費用が次々に発生したりと、想定外のコストとトラブルに悩まされることになります。逆に、非機能要件や責任分界、評価軸を明確にしたRFPを作れれば、相見積もりの比較精度が上がり、プロジェクトの手戻りを大きく減らせます。
本記事は、クラウド開発・構築のRFP・要件定義書・提案依頼書を、発注企業が「何をどう書けば失敗しないか」という視点で整理する「要件定義特化」の解説です。クラウド特有の非機能要件（可用性・性能・コスト上限・セキュリティ）の定め方、責任共有モデルを踏まえた責任分界の明文化、構成パターンの選定基準、PoC（概念実証）の評価軸の設計、業界コンプライアンス要件の落とし込みまで、一次データとあわせて具体的に解説します。なお、クラウド開発・構築の全体像をまだ把握していない方は、まずクラウド開発/構築の完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・クラウド開発/構築の完全ガイド
クラウド特有の非機能要件の定め方
クラウド開発・構築のRFPで最初に押さえるべきが、非機能要件です。何の機能を作るかという機能要件以上に、「どれくらいの可用性で、どれくらいの性能で、いくらまでのコストで」という非機能要件が、クラウドの構成と費用を決定づけます。ここが曖昧なままだと、ベンダーごとに前提がバラバラになり、相見積もりの比較が成り立たなくなります。
可用性と性能の目標を数値で示す
可用性は「稼働率99.9%」のように数値で示すことが基本です。求める可用性が高いほど、マルチAZ構成や冗長化が必要になり、構築費用も上がります。一次データの相場では、EC2・RDSを各1台のシングル構成は20万〜30万円ですが、各2台にWAFやELBを加えた高可用性構成は50万〜60万円が目安です。「24時間365日絶対に止めてはいけない」のか「夜間メンテナンスは許容できる」のかで、構成も費用も大きく変わります。
性能要件も同様に、「同時アクセス数」「レスポンスタイム」「ピーク時の処理件数」といった指標で示します。ここを定義しておくと、ベンダーは自動スケーリングの設計やインスタンスのサイズを根拠を持って提案でき、過剰スペックも過小スペックも防げます。RFPで非機能の目標値を明示することは、見積もりの妥当性を発注側が検証できるようにするための、最低限の準備だと言えます。
コスト上限と運用費まで含めて要件化する
クラウドのRFPで見落とされがちなのが、初期構築費だけでなく、月額のインフラ費と保守運用費まで含めたコスト要件です。一次データでは、インフラの月額は小規模で数千円〜1万円、中規模で3万〜10万円、大規模エンタープライズで数十万〜100万円以上が目安です。保守運用費は年間で開発費の10〜20%が相場で、開発500万円なら年50万〜100万円、月4万〜8万円程度になります。
RFPには「月額のインフラ費と保守費を、想定アクセス量を前提に試算して提示すること」を明記しておくと、ランニングコストの不意打ちを避けられます。クラウドは初期費用が安く見えても、運用が長期化するほど月額が積み上がるため、トータルコスト・オブ・オーナーシップ（TCO）で評価する姿勢が欠かせません。構築費の安さだけで選ぶと、運用フェーズで割高になるケースがあることを、要件段階で織り込んでおくべきです。
セキュリティ非機能要件を具体的な項目で定める
可用性・性能・コストと並ぶ非機能要件の柱が、セキュリティです。クラウドの責任共有モデルでは、OSやアプリの設定、アクセス権限、データの暗号化といった上位レイヤーの責任が利用者側に残るため、これらをRFPの要件として具体的に定める必要があります。「保存データと通信経路を暗号化すること」「アクセスログを一定期間保全すること」「最小権限の原則でアクセス制御を設計すること」といった項目を明記し、ベンダーにその実装方法を提案させます。
近年は、これらの要件をゼロトラストアーキテクチャの考え方で整理するアプローチも広がっています。境界の内側を信頼する従来型ではなく、すべてのアクセスを検証する前提で、認証・認可・監視を設計する考え方です。RFPでセキュリティ非機能を曖昧にすると、ベンダーごとに前提がばらつき、稼働後に設定ミスや基準未充足が発覚するリスクが高まります。セキュリティは機能要件の後付けではなく、最初に数値や項目で定義すべき非機能要件だと位置づけ、ベンダーの認証取得状況やリージョン選択まで含めて要件化することが、安全なクラウド構築の出発点です。
責任共有モデルと責任分界の明文化
クラウド特有のRFP論点として外せないのが、責任分界の明文化です。クラウドには「責任共有モデル」があり、クラウド事業者・開発ベンダー・自社の三者で、どこまでを誰が担うかを明確にしないと、トラブル時に責任の所在が曖昧になります。「誰がOSのセキュリティパッチを当てるのか」「障害時の一次対応は誰がするのか」といった役割を、要件定義の段階で文書化しておくことが重要です。
運用・障害対応の責任範囲をSLAで定義する
運用フェーズの責任分界は、SLA（サービスレベル合意）として定義します。監視は誰がするか、障害検知の連絡フローはどうするか、一次対応・復旧の時間目標はどれくらいか、といった項目を具体的に取り決めます。一次データでは、AWSの運用代行（監視・障害一次対応）は初期・月額とも数万円程度で外部に委託でき、内製と委託を組み合わせた運用設計が可能です。
クラウド事業者のサポートプランも責任分界の一部です。一次データでは、AWSやAzureのビジネス向けサポートは月額最低$100（年$1,200）からで、エンタープライズ向けは月$15,000以上のケースもあります。重大障害時にクラウド事業者からどれだけ手厚いサポートを受けられるかは、サポートプランの選択で変わります。RFPでは、こうした運用体制とサポート水準まで含めて、提案を求めるべきです。
スキルトランスファーと内製化方針をRFPに盛り込む
競合の解説が手薄な論点として、内製化の方針をRFPに盛り込むことが挙げられます。委託の最大のデメリットは、ノウハウが社内に蓄積されず、追加改修のたびにベンダー依存とコストが続くことです。これを避けるには、RFPの段階で「設計ドキュメントの納品」「運用手順の整備」「自社エンジニアへのスキルトランスファー」を要件として明記しておく必要があります。
将来的にCCoE（Cloud Center of Excellence）を立ち上げ、内製運用へ移行したいなら、その意図をベンダーに伝え、協働の進め方を提案に含めてもらうとよいでしょう。riplaはフルスクラッチ受託と国内開発の立場から、構築して終わりではなく、社内にノウハウを残し、運用を自走できる体制づくりまで見据えた要件整理を重視しています。RFPは「作ってもらうための文書」であると同時に、「自社が将来どう運用するか」を描くための文書でもあります。
目指す運用モデルとSLOを要件として描く
責任分界とあわせて要件化したいのが、「将来どういう運用モデルを目指すか」です。従来型の「絶対に止めない」ことを至上命題とするITIL型の運用を続けるのか、SRE（Site Reliability Engineering）型の運用へ移行するのかで、求める体制も自動化の範囲も変わります。SRE型を目指すなら、SLO（サービスレベル目標）を定め、許容できる範囲で素早く改善を回し、トイル（手作業の繰り返し）を減らす運用を前提に、監視・自動化の要件をRFPに盛り込みます。
具体的には、「障害検知から一次対応までの自動化をどこまで実装するか」「デプロイやスケーリングをどこまで自動化するか」「SLO違反時のアラートと対応フローをどう設計するか」といった項目を要件として示します。ここを描いておくと、ベンダーは単に動くシステムを作るだけでなく、運用しやすい設計を意識した提案をしてくれます。運用文化の移行は、構築後に急にはできません。要件定義の段階で目指す運用像を言語化しておくことが、SRE化への移行をスムーズにする実務的な準備になります。
構成パターンの選定基準
RFPでは、求める非機能要件に対して、どの構成パターンが妥当かをベンダーに提案させ、その根拠を比較できるようにしておきます。クラウドには、Web3層構成、静的サイト+CDN、サーバーレス（Lambda+API Gateway）、マルチAZ高可用性、オンプレと併用するハイブリッドといった代表的な構成パターンがあり、それぞれコストと特性が異なります。
アクセス特性に応じた構成パターンの選び方
構成パターンの選定基準は、システムのアクセス特性です。アクセスが少〜中規模で波があるなら、アイドルコストがゼロのサーバーレス構成が向きます。常時一定の負荷がかかるなら、リザーブドインスタンスを使ったWeb3層構成が経済的です。静的コンテンツ中心なら、CDNを組み合わせた構成で高速・低コストを両立できます。RFPには自社のアクセス特性を提示し、それに最適な構成の提案を求めるのが定石です。
構成パターンの選定では、ベンダーロックインの観点も忘れてはいけません。特定クラウドの独自サービスを使いすぎると、後で他社へ移行しにくくなります。将来のマルチクラウドやポータビリティを重視するなら、コンテナ（ECS Fargateなど）を使ってアプリケーションの可搬性を確保する設計を要件に含めておくとよいでしょう。要件定義の段階でこの方針を決めておくと、構成選定の判断がぶれません。
相見積もりで技術力とセキュリティ方針を見極める
RFPを複数社に出して相見積もりを取る際は、価格だけでなく、提案された構成の妥当性、技術力、セキュリティポリシーを比較することが大切です。同じ要件でも、ベンダーによって提案する構成やマネージドサービスの使い方が異なり、その違いが運用コストや拡張性に長く影響します。なぜその構成を選んだかの説明が明確なベンダーほど、要件を正しく理解していると判断できます。
人月単価の前提も、相見積もりの比較で確認すべき点です。一次データでは、人月単価は初級が月25万〜50万円、ミドルが月50万〜80万円、シニア・アーキテクトが月65万〜120万円以上で、PM費用は開発費の10〜20%が目安です。どのスキル層が、どれだけ稼働する前提の見積もりかを確認すると、価格の妥当性を判断できます。安すぎる見積もりは、経験の浅い人材中心であったり、後の追加費用を前提にしていたりする可能性があるため、内訳まで踏み込んで見極めます。
PoC評価軸と業界コンプラ要件
本格的な構築に入る前に、PoC（概念実証）を実施することで、要件の妥当性を検証できます。ただし「とりあえず試す」だけのPoCは時間と費用の浪費になりがちです。RFPや要件定義の段階で、PoCで何を検証し、何をもって合格とするかという評価軸を、あらかじめ定めておくことが重要です。ここが競合の解説で手薄になりやすい、実務上のポイントです。
PoCの検証項目と合格基準を要件化する
PoCの評価軸は、性能・コスト・運用性といった観点で具体化します。たとえば「想定ピーク時のアクセスでレスポンスタイムが目標内に収まるか」「想定アクセス量での月額コストが上限内か」「障害を意図的に起こしたとき自動で復旧するか」といった検証項目と、その合格ラインを事前に決めておきます。アセスメントでは、既存システムのCPU使用率やネットワークI/Oといった指標を測定し、移行先の構成を裏づけます。
合格基準を決めずにPoCを始めると、「なんとなく動いたから本番化する」という曖昧な意思決定になり、後の本番運用でトラブルが噴出します。PoCの期間目安も要件に含め、検証に区切りをつけることが大切です。要件定義の精度を上げることは、後の仕様変更コストを抑えることに直結します。検証で得た知見を要件定義書に反映し、本番構築の根拠を固めるのが、失敗しない進め方です。
アセスメントの測定指標を要件に組み込む
PoCの前段として、既存システムのアセスメント（現状分析）を要件に組み込んでおくと、移行先の構成設計の精度が上がります。アセスメントでは、現行システムのCPU使用率、メモリ使用量、ネットワークI/O、ピーク時間帯のアクセス傾向といった指標を一定期間測定します。これらの実測値があれば、ベンダーは推測ではなく根拠を持ってインスタンスのサイズや自動スケーリングの閾値を提案でき、過剰スペックも過小スペックも避けられます。
RFPには「移行前にアセスメントを実施し、その測定結果を構成提案の根拠とすること」を要件として明記しておくとよいでしょう。とくにオンプレミスからの移行では、現行の負荷特性を数値で把握しないまま構成を組むと、本番で性能不足やコスト超過に直面しがちです。アセスメントの指標と期間を要件化することは、競合の解説で手薄になりやすい実務上のポイントであり、要件定義の精度を一段引き上げます。推測ではなく実測に基づいて構成を組むという姿勢が、後工程での性能不足やコスト超過といった手戻りを防ぐ、確かな土台になります。
業界別のコンプラ要件を落とし込む
金融・医療・製造といった業界では、業界特有のコンプライアンス要件を要件定義に落とし込む必要があります。金融なら金融情報システムセンターのFISC安全対策基準、医療なら厚生労働省・経済産業省・総務省による3省2ガイドライン、製造業なら自社固有のセキュリティ要件などです。これらをクラウドの構成・運用でどう満たすかを、RFPの要件として明示しておくことが欠かせません。
近年は、これらの要件をゼロトラストアーキテクチャの実装で満たすアプローチも広がっています。データの保管場所（リージョン）、暗号化、アクセスログの保全、監査対応といった項目を要件として整理し、ベンダーにその充足方法を提案させます。riplaはフルスクラッチ受託と国内開発の立場から、こうした業界コンプラ要件を構成・運用の設計へ正確に落とし込み、要件定義書として明文化する支援を重視しています。コンプラ要件は後から追加すると大幅な手戻りになるため、要件定義の最初期に組み込むことが鉄則です。
まとめ
クラウド開発・構築のRFP・要件定義書を整理すると、押さえるべき柱は4つです。可用性・性能・コスト上限・セキュリティといった非機能要件を数値や具体項目で定め、責任共有モデルを踏まえた責任分界とSLAを明文化し、目指す運用モデルとSLOまで描き、アクセス特性とロックイン回避を踏まえて構成パターンを選定し、アセスメントの測定指標・PoCの評価軸・業界コンプラ要件を要件定義へ落とし込む。この4つを丁寧に詰めることが、過剰スペックや追加費用、運用トラブルを未然に防ぎます。
要件定義で大切なのは、「作ってもらうための文書」にとどめず、「自社が将来どう運用し、ノウハウをどう蓄積するか」まで描くことです。コスト上限、責任分界、セキュリティ非機能、目指す運用モデル、アセスメント指標、PoC合格基準、コンプラ要件を曖昧にしたまま発注すると、後の手戻りとコストが膨らみます。riplaはフルスクラッチ受託と国内開発を組み合わせ、非機能要件の整理から相見積もりの見極め、目指す運用モデルの言語化、内製化を見据えた要件定義書の作成までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。