AWSの導入・構築をベンダーに依頼するとき、最初の関門になるのがRFP（提案依頼書）と要件定義です。「どんな構成にしたいか」「どこまでの可用性が必要か」「セキュリティはどう担保するか」を発注側が言語化できていないと、ベンダーから出てくる提案は的外れになり、相見積もりを比較しても何が良いのか判断できません。逆に、要件をきちんと整理してRFPに落とし込めれば、提案の質は格段に上がり、後の手戻りや追加費用も防げます。AWS構築の成否は、この上流工程でほぼ決まると言っても過言ではありません。
本記事は、AWS導入・構築のRFP・要件定義書・提案依頼書の作り方を、発注企業の視点から整理する「要件定義特化」の解説です。RFPに盛り込むべき項目、可用性・性能・コスト上限・セキュリティといった非機能要件の定め方、責任共有モデルを踏まえた役割分担とPoC（概念実証）の評価軸、そして業界特有のコンプライアンス要件の落とし込みまで、一次データの費用相場とあわせて具体的に解説します。なお、AWS導入・構築の全体像をまだ把握していない方は、まずAWS導入・構築の完全ガイドから読むことをおすすめします。読み終えるころには、自社のRFPに何を書くべきかが明確になっているはずです。
▼全体ガイドの記事
・AWS導入・構築の完全ガイド
AWS構築のRFPに盛り込むべき項目
RFP（提案依頼書）は、発注側が「何を、なぜ、どこまでやってほしいのか」をベンダーに伝える文書です。AWS構築のRFPでは、技術的な希望だけでなく、その背景にある事業目的や制約条件まで含めて記述することが、質の高い提案を引き出す鍵になります。ベンダーは、発注側の意図を正しく理解できて初めて、最適な構成と現実的な見積もりを提示できるからです。
目的・現状・移行対象を明確にする
RFPの冒頭で明確にすべきは、プロジェクトの目的です。「オンプレミスの老朽化に伴う更改」「アクセス増加に対応できるスケーラビリティの確保」「インフラ費用の削減」など、なぜAWSを導入するのかを具体的に記述します。目的が曖昧だと、ベンダーは過剰な構成を提案しがちで、結果としてコストが膨らみます。目的を明確にすることが、適正規模の提案を引き出す第一歩です。
次に、現状のシステム構成と移行対象を整理します。既存のサーバー台数、OS、ミドルウェア、データ量、ピーク時のアクセス数といった現状情報は、ベンダーが移行範囲と工数を見積もるための土台です。特にデータ量とアクセス特性は、後述する費用見積もりの精度を大きく左右します。一次データでも、従業員50〜100名規模のオンプレからクラウドへの移行は、設計・構築100万〜400万円に加え、データ移行で20万〜80万円が別途かかると示されており、移行対象の規模を正確に伝えることが、見積もりのブレを抑えます。
予算・納期・体制と評価基準を提示する
RFPには、予算感、希望納期、想定する体制（自社側の関与度合い）も明記します。予算を一切示さないと、ベンダーは見積もりの方向性を定めにくく、提案の比較も難しくなります。一次データでは、クラウド開発は費用の約80%が人件費で、人月単価は初級で月25万〜50万円、ミドルで月50万〜80万円、シニア/アーキテクトで月65万〜120万円以上とされ、PM費用は開発費の10〜20%が相場です。こうした構造を理解したうえで、自社の予算レンジを示すと、現実的な提案が集まります。
あわせて、提案をどう評価するかの基準もRFPに盛り込みます。価格だけで選ぶのか、技術力やセキュリティへの取り組みを重視するのか、保守運用体制まで含めて評価するのかを明示することで、ベンダーは評価軸に沿った提案をしてきます。一次データでも、ベンダー選定では相見積もりに加え、技術力やセキュリティポリシーの確認が重要とされています。評価基準を明示することは、発注側にとっても提案を公平に比較するための物差しになり、選定の納得感を高めます。
可用性・性能・コスト上限など非機能要件の定め方
AWS構築の要件定義で、機能要件以上に重要になるのが非機能要件です。非機能要件とは、「どんな機能を作るか」ではなく「どれくらい止まらず、速く、安全に、いくらで動かすか」という品質・制約に関する要件です。クラウド構築では、この非機能要件の定め方が構成とコストを直接決めるため、RFPと要件定義書で具体的な数値として示すことが欠かせません。
可用性と性能の目標値を数値で定める
可用性の要件は、「どれくらいの停止なら許容できるか」を数値で定めます。たとえば「月間の停止時間は数分以内」といった目標を置くなら、マルチAZ構成や冗長化が必要になり、構成は中規模以上になります。一方、「夜間の数時間なら止まってもよい」業務なら、シングル構成でも要件を満たせます。可用性の目標を高くするほど構成は複雑になりコストも上がるため、業務の重要度に見合った水準を、過不足なく設定することが肝心です。
性能要件は、想定する同時アクセス数、応答時間、処理件数といった指標で定めます。ピーク時に何人が同時に使うのか、画面表示は何秒以内に返したいのか、といった目標があると、ベンダーはインスタンスタイプや台数、自動スケーリングの設定を具体的に設計できます。一次データの構成例で言えば、シングル構成（20万〜30万円）で足りるのか、EC2・RDS各2台＋WAF＋ELBの高可用性構成（50万〜60万円）が必要なのかは、この可用性・性能要件によって決まります。要件を数値で示すことが、適正な構成と見積もりの前提になります。
コスト上限と運用費用を要件に織り込む
クラウド特有の非機能要件として、コスト上限を明示することが重要です。AWSは従量課金のため、構成や使い方次第で月額が変動します。月のインフラ費用の上限を要件として定めておけば、ベンダーは過剰な構成を避け、コストを意識した設計をします。一次データでは、インフラ月額は小規模で数千円〜1万円、中規模で3万〜10万円、大規模エンタープライズで数十万〜100万円以上と幅があり、自社が許容できる上限を示すことが構成選定の指針になります。
初期構築費だけでなく、構築後の保守運用費も要件に織り込みます。一次データでは、保守運用費は年間で開発費の10〜20%が相場とされ、開発費500万円なら年50万〜100万円（月4万〜8万円）が目安です。さらに、リザーブドインスタンスの活用（t3.largeで従量$78.3が3年契約で$40.4まで低下）といったコスト最適化策を提案に含めるよう求めることも有効です。初期と運用の両面でコストを要件化することで、導入後に「思ったより高い」という事態を防げます。
責任共有モデルを踏まえた役割分担とPoCの評価軸
AWSをはじめとするクラウドでは、セキュリティや運用の責任を、クラウド事業者と利用者が分担する「責任共有モデル」が前提になります。AWS側はデータセンターや物理インフラの安全を担い、利用者側はOSの設定、アクセス権限、データの保護といった部分に責任を持ちます。この境界を要件定義で明確にし、どこまでをベンダーに任せ、どこからを自社が担うのかを決めておくことが、後のトラブルを防ぎます。
委託範囲と内製範囲を切り分ける
要件定義では、ベンダーへの委託範囲と自社の内製範囲を切り分けます。設計・構築は委託し、運用は自社で行うのか、運用も含めて任せるのか。委託のメリットは本業に集中できることですが、デメリットとして社内にノウハウが蓄積されにくい点があります。これを見越して、構築フェーズからスキルトランスファーを要件に含め、将来の内製化を見据えた役割分担を設計しておくと、長期的な自走力につながります。
運用面では、監視や障害一次対応をどこまで委託するかを定めます。一次データでは、AWS運用代行（監視・障害一次対応）は初期・月額とも数万円程度が相場とされています。自社に運用人材がいない初期段階は委託し、内製化が進むにつれて自社へ移していく、という段階的な役割移行を要件として設計できると理想的です。責任共有モデルを踏まえた役割分担の明確化は、セキュリティ事故や運用の空白を防ぐうえでも欠かせません。
PoCの検証範囲と合格基準を要件化する
大規模な構築や移行に進む前に、PoC（概念実証）で技術的な実現性を検証することが、リスク低減に有効です。ここで多くの企業が陥るのが、「PoCで何をどこまで検証し、何をもって合格とするか」の評価軸を曖昧にしたまま進めてしまうことです。評価軸が不明確だと、PoCが「なんとなく動いた」で終わり、本番化の判断材料になりません。
PoCの要件化では、検証する項目（性能が出るか、既存システムと連携できるか、想定コストに収まるか）と、それぞれの合格基準（応答時間が目標値以内か、データ移行が正確に完了するか、月額が上限内か）を具体的に定めます。あわせて、検証に使う指標（CPU使用率、ネットワークI/Oなど）と検証期間の目安も決めておきます。この評価軸の明確化こそ、競合の解説が手薄な実務上の差別化ポイントであり、PoCを「やったつもり」で終わらせず、確かな意思決定につなげる鍵です。riplaはフルスクラッチ受託とクラウド構築・運用の伴走の立場から、PoCの評価軸設計から本番化判断までを支援しています。
業界特有のコンプライアンス要件の落とし込み
業種によっては、一般的なセキュリティ要件に加えて、業界特有のコンプライアンス（法令・ガイドライン遵守）要件をクラウド構築に織り込む必要があります。これは多くの競合解説が深く触れない領域ですが、規制業種では要件定義の段階でこれを盛り込めるかどうかが、プロジェクトの成否を分けます。後から対応しようとすると、構成の作り直しや大幅な追加コストが発生しかねません。
金融・医療・製造の業界基準を要件に反映する
金融業であれば、FISC安全対策基準への適合が求められます。医療分野では、医療情報システムの安全管理に関するいわゆる3省2ガイドラインへの対応が必要です。製造業でも、取引先から求められるセキュリティ要件や、図面・技術情報の保護要件が存在します。これらの業界基準を、RFPと要件定義書に「準拠すべき基準」として明記し、ベンダーがその基準を満たす構成を設計できるかを確認することが不可欠です。
業界基準への適合は、データの保管場所（国内リージョン指定）、暗号化、アクセスログの保全、監査対応といった具体的な構成要件に落とし込まれます。RFPの段階で「自社はどの基準に従う必要があるか」を示し、ベンダーに対応実績を問うことで、コンプライアンスに強いパートナーを選べます。要件定義でここを曖昧にすると、監査で指摘を受けて作り直す、という最悪の手戻りを招きかねません。
注意したいのは、業界基準への対応がデータの保管場所や暗号化といった「設計時の構成」だけで完結しないことです。アクセスログを一定期間保全し、定期的に監査できる状態を維持する、といった運用面の要件まで含めて落とし込む必要があります。要件定義書には、構築時に満たすべき項目と、運用フェーズで継続的に満たし続けるべき項目を分けて記載しておくと、ベンダーとの認識齟齬を防げます。規制業種では、この運用面の要件化を怠ると、稼働後の監査で初めて不備が発覚し、是正に追われることになります。
ゼロトラストとセキュリティ運用を要件化する
近年のセキュリティ要件では、社内ネットワークの内側を無条件に信頼しない「ゼロトラスト」の考え方が広がっています。すべてのアクセスを検証し、最小限の権限のみを付与する、という設計思想です。要件定義では、このゼロトラストをどこまで実装するか、アクセス制御や多要素認証、通信の暗号化といった具体策を要件として定めます。クラウドはアクセス経路が多様なため、こうした認証・認可の設計が特に重要になります。
セキュリティは構築時だけでなく、運用時の継続的な監視・対応まで含めて要件化することが大切です。脆弱性のスキャン、ログの監査、インシデント発生時の対応手順を要件に盛り込み、誰がどう運用するかまで決めておきます。RFPと要件定義書にコンプライアンスとセキュリティ運用をしっかり織り込むことが、規制業種でAWS導入を成功させる前提条件です。要件が固まれば、相見積もりで各ベンダーの対応力を公平に比較でき、自社に最適なパートナーを選べるようになります。
提案の評価と保守運用・SLAの要件化
RFPを出して提案が集まったら、それらをどう評価し、契約や保守運用の条件をどう要件化するかが次の論点になります。構築だけでなく、その後の運用まで見据えた要件を最初に固めておくことが、長く安定して使えるシステムにつながります。要件定義は構築の入口であると同時に、運用の設計図でもあります。
相見積もりを正しく比較する評価項目
複数ベンダーから集めた提案を比較する際、金額だけで判断するのは危険です。安い見積もりには、必要な工程が含まれていない、保守が手薄、といった理由が隠れていることがあります。一次データでも、ベンダー選定では相見積もりに加えて、技術力やセキュリティポリシーの確認が重要とされています。提案を比較する評価項目を、価格・技術力・セキュリティ・保守体制・実績の複数軸で設定し、それぞれを点数化して総合評価するのが、納得感のある選び方です。
見積もりの内訳を要件として求めることも有効です。クラウド開発は費用の約80%が人件費であるため、どのレベルの人材が何人月かかわるのかを内訳で示してもらえば、提案の妥当性を判断できます。一次データでは、人月単価は初級で月25万〜50万円、ミドルで月50万〜80万円、シニア/アーキテクトで月65万〜120万円以上、PM費用は開発費の10〜20%が相場です。この相場と照らして、提示された工数・単価が現実的かを確認すれば、過大・過小な見積もりを見抜けます。
保守運用とSLAを要件に明記する
要件定義で見落とされがちなのが、構築後の保守運用とSLA（サービス品質保証）です。誰がどの範囲を、どのような応答時間で保守するのかを要件に明記しておかないと、運用開始後に「想定していた対応をしてもらえない」というトラブルが起きます。障害発生時の一次対応の時間、対応の連絡体制、定例の運用報告といった条件を、要件として具体的に定めることが大切です。
保守運用の費用感も要件に織り込みます。一次データでは、保守運用費は年間で開発費の10〜20%（開発500万円なら年50万〜100万円、月4万〜8万円）が相場で、AWS運用代行（監視・障害一次対応）は初期・月額とも数万円程度とされています。これらの相場を踏まえて保守の範囲と費用を要件化すれば、運用フェーズの予算も見通せます。構築から運用までを一続きで要件化することが、導入後に困らないシステムを実現する前提です。riplaはフルスクラッチ受託とクラウド構築・運用の伴走の立場から、保守運用やSLAまで含めた要件設計を支援しています。
まとめ
AWS導入・構築のRFP・要件定義では、目的・現状・移行対象・予算・評価基準といった基本項目に加え、可用性・性能・コスト上限・セキュリティといった非機能要件を数値で定めることが、適正な構成と見積もりを引き出す鍵になります。さらに、責任共有モデルを踏まえた委託範囲と内製範囲の切り分け、PoCの検証範囲と合格基準の明確化、金融FISCや医療3省2ガイドラインといった業界コンプライアンスの落とし込みまで盛り込むことで、規制業種でも安心して進められる要件定義になります。
要件定義で大切なのは、技術的な希望を並べることではなく、「自社の業務にとって、どの品質を、いくらまでで、誰が担って実現するか」を、数値と役割で具体化することです。ここを丁寧に詰めれば、相見積もりの比較も提案の評価も格段にやりやすくなり、導入後の手戻りや追加費用も防げます。riplaはフルスクラッチ受託とクラウド構築・運用の伴走を組み合わせ、非機能要件の数値化からPoC評価軸、コンプライアンス対応までを一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
株式会社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を創業。