GCP導入・構築のRFP/要件定義書/提案依頼書について

GCP（Google Cloud Platform）の導入・構築をベンダーに依頼するとき、プロジェクトの成否を実質的に左右するのが、RFP（提案依頼書）と要件定義書の出来です。「とにかくGCPに移行したい」という曖昧な依頼では、ベンダーごとに前提がバラバラの提案が返ってきて比較できず、契約後も「言った・言わない」の認識齟齬で手戻りが続きます。逆に、要件が明確に整理されたRFPがあれば、各社の提案を同じ土俵で評価でき、構築後の品質も安定します。

本記事は、GCP導入・構築のRFP・要件定義書・提案依頼書を、発注企業の視点から整理する「要件定義特化」の解説です。可用性・性能・コスト上限・セキュリティといった非機能要件の固め方、クラウドの責任共有モデルを踏まえた役割分担の明確化、構成パターンの選定基準、そしてPoC（概念実証）でベンダーの実力を見極める評価軸の置き方まで、実務に落とし込めるレベルで解説します。なお、GCP導入・構築の全体像をまだ把握していない方は、まずGCP導入・構築の完全ガイドから読むことをおすすめします。本記事はその完全ガイドの「要件定義・RFP編」として、発注ドキュメントの作り込みを掘り下げます。

▼全体ガイドの記事
・GCP導入・構築の完全ガイド

非機能要件の固め方（可用性・性能・コスト・セキュリティ）

GCP導入のRFPで、機能要件以上に重要になりがちなのが非機能要件です。非機能要件とは、「何ができるか」ではなく「どれだけの品質で動くか」を定める要件で、可用性、性能、コスト上限、セキュリティといった項目が含まれます。これらが曖昧なまま発注すると、ベンダーは安全側に過剰スペックで見積もるか、逆に最小構成で安く見せて後から追加費用が発生するか、いずれにせよ発注側が損をする構図になります。

可用性は、「システムがどれだけ止まらないか」を稼働率（SLA）の数値で定義します。たとえば稼働率99.9%なら年間の停止許容時間は約8.8時間、99.99%なら約53分と、わずかな数字の差が許容停止時間に大きく効きます。求める可用性が高いほど、複数ゾーンや複数リージョンへの冗長構成が必要になり、コストも上がります。すべてのシステムを最高水準にする必要はなく、業務への影響度に応じて可用性目標を段階的に設定するのが現実的です。RFPでは、「24時間365日の停止が許されない業務なのか」「夜間の数時間停止は許容できるのか」を明確にし、過剰でも過少でもない可用性目標を示すことが大切です。

性能要件は、想定する同時アクセス数、レスポンスタイム、処理するデータ量を具体的な数値で示します。「ピーク時に同時1,000ユーザー」「主要画面の応答は2秒以内」「日次で処理するデータは数百万件」といった形で定量化することで、ベンダーは必要なリソースを正確に見積もれます。性能要件が曖昧だと、本番で想定外の負荷に耐えられず、リリース後に慌てて増強する事態になりかねません。現状システムの実測値があれば、それを基準に将来の伸びを見込んで設定すると、現実的な目標になります。

コスト要件では、初期構築費だけでなく、月額のランニングコストの上限を示すことが重要です。クラウドは従量課金のため、構成次第でランニングが大きく変わります。一次データでは、GCPの仮想サーバー（Linux 2コア／約8GB）の従量課金がn1-standard-2で月62.3ドル、3年契約で月40ドル前後、インフラ月額は中規模で3万〜10万円が目安とされています。これらの相場を踏まえ、「月額のインフラ費はいくらまでに収めたいか」をRFPに明記すれば、ベンダーは予算内に収まる構成を提案でき、後からの予算超過を防げます。

セキュリティ要件は、扱うデータの機密性に応じて定めます。個人情報や決済情報を扱うなら、暗号化、アクセス制御、監査ログ、脆弱性対策といった要件を具体的に記載します。さらに、業界によっては法令やガイドラインへの準拠が求められます。金融なら安全対策基準、医療なら関連ガイドラインといった業界特有の要件を、RFPの段階で明示しておくことが不可欠です。これらをベンダー任せにすると、後から大幅な作り直しが発生し、コストとスケジュールが膨らみます。セキュリティ要件は、構築の前提として早期に固めるべき項目です。

非機能要件のうち、見落とされやすいのがバックアップと災害対策（DR）の要件です。どのくらい前の状態まで復旧できる必要があるか（目標復旧時点）、障害発生からどのくらいの時間で復旧したいか（目標復旧時間）を数値で定義します。これらの目標値が高いほど、頻繁なバックアップや、別リージョンへの待機系の構築が必要になり、コストが上がります。業務が止まったときの影響額と、対策にかかる費用を天秤にかけ、自社にとって妥当な水準を見極めることが要件定義の腕の見せどころです。

バックアップやDRは、平常時には目に見えない投資のため軽視されがちですが、いざデータ消失やリージョン障害が起きたときに、事業継続を左右します。GCPはマネージドな自動バックアップやレプリケーション機能を備えているため、自前で複雑な仕組みを作らなくても、設定によって一定水準のDRを実現できます。RFPの段階で復旧目標を数値で示しておけば、ベンダーは適切なバックアップ構成を提案でき、いざというときに「想定より復旧に時間がかかる」という事態を避けられます。

責任共有モデルと役割分担の明確化

クラウドの要件定義で見落とされがちなのが、「どこまでがクラウド事業者の責任で、どこからが利用者の責任か」を定める責任共有モデルの理解です。GCPのようなクラウドでは、物理的なインフラやハードウェアの管理はクラウド事業者が担いますが、その上で動くアプリケーションやデータ、アクセス権限の設定は利用者側の責任になります。この境界を曖昧にしたまま発注すると、トラブル時に責任の所在が不明確になり、対応が遅れます。

GCP導入では、クラウド事業者（Google）、構築を委託するベンダー、そして自社という三者の役割を明確に切り分ける必要があります。インフラの物理層はGoogleが、構築や設定はベンダーが、運用時の意思決定や承認は自社が担う、というように、各フェーズで誰が何に責任を持つかをRFPと契約で定義します。とりわけ、構築後の運用を誰が担うのか、障害時の一次対応は誰が行うのかは、契約段階で必ず詰めておくべき論点です。

役割分担を考えるうえで重要なのが、内製と委託のバランスです。すべてをベンダーに委託すれば自社の手間は減りますが、ノウハウが社内に残らず、運用や改修のたびに外部依存が続きます。一次データでも、クラウド開発は費用の約80%が人件費を占め、シニアやアーキテクトの単価は月65万〜120万円以上とされるため、委託を続けるほど運用コストは膨らみます。構築段階でスキルトランスファーを契約条件に組み込み、定常運用は段階的に内製化する、という役割設計が、中長期のコストを抑える鍵になります。

RFPでは、構築だけでなく、その後の運用・保守の範囲も明記すべきです。監視、障害対応、バックアップ、セキュリティパッチの適用、定期的なコスト最適化など、運用フェーズで誰が何をどこまでやるのかを定義します。一次データでは、保守運用費は年で開発費の10〜20%（開発500万円なら年50万〜100万円、月4万〜8万円）が目安とされ、運用代行（監視・障害一次対応）は初期・月額とも数万円程度とされています。これらの相場を踏まえ、運用の範囲と費用を最初から見積もりに含めることが大切です。

運用スコープを曖昧にしたまま構築だけを発注すると、リリース後に「これは保守契約の範囲外です」と言われ、追加費用や対応の遅れに悩まされます。とくにクラウドは、構築して終わりではなく、稼働状況の監視やコスト最適化を継続することで価値が出る性質を持ちます。RFPの段階で、運用に求めるサービスレベル（対応時間、復旧目標、報告頻度など）を定義し、構築から運用までを一貫して任せられる体制を確認しておくことが、安定稼働への近道です。

構成パターンの選定基準

非機能要件と役割分担が固まったら、次に決めるのが構成パターンです。GCPには、仮想サーバーを中心とした構成、サーバーレス中心の構成、コンテナ基盤を使う構成など、複数のアーキテクチャの選択肢があります。どれを選ぶかは、要件次第で最適解が変わります。RFPでは、自社が想定する構成の方向性を示しつつ、ベンダーから最適な構成パターンの提案を引き出せるように要件を整理することが大切です。

構成パターンの選定軸は、ワークロードの性質です。常時高負荷で動き続けるシステムや、特殊なミドルウェアが必要なシステムは、仮想サーバー（Compute Engine）が適しています。アクセスが断続的で「動くときだけ動けばよい」処理は、アイドルコストが発生しないサーバーレス（Cloud Run、Cloud Functions）が有利です。複数のサービスを組み合わせる複雑なシステムは、コンテナ基盤（GKE）でオーケストレーションするのが定石です。要件定義では、システムを構成する要素ごとに、どのパターンが適するかを切り分けて考えます。

重要なのは、一つの構成パターンにすべてを当てはめようとしないことです。実際のシステムは、常時稼働の基盤部分と、断続的に動く処理部分が混在しているのが普通です。常時稼働部分は確約利用割引付きの仮想サーバー、断続処理はサーバーレス、というハイブリッド構成にすることで、コストとパフォーマンスを両立できます。RFPで「すべてサーバーレスで」「すべて仮想サーバーで」と決め打ちするのではなく、ワークロードごとの最適な振り分けを提案できるベンダーを選ぶことが、無駄のない構成への近道です。

構成パターンを決めるうえで、将来のベンダーロックイン回避という観点も要件に含めておくべきです。GCP独自のサービスを使いすぎると、便利な反面、将来別のクラウドへ移行したくなったときに作り直しのコストが大きくなります。コンテナ技術を活用して移行可能性を担保する、標準的な技術を優先する、といった方針を要件として示しておくと、ロックインのリスクを抑えた構成を選べます。もちろん、独自サービスの便利さとロックインのリスクはトレードオフであり、どこまで割り切るかは自社の方針次第です。

RFPの段階でこの観点を明示しておくことで、ベンダーの提案にも「なぜこの構成を選んだのか」「ロックインのリスクをどう考えているか」という説明が含まれるようになり、提案の質を見極めやすくなります。ロックイン回避は、コストや可用性ほど目立たない要件ですが、システムを長く使ううえでの柔軟性に直結します。複数のクラウドを併用するマルチクラウドを視野に入れる場合は、統合的な監視やセキュリティ管理をどう実現するかも、あわせて要件として整理しておくと、運用フェーズで困りません。短期の構築コストだけでなく、中長期の選択肢の広さまで見据えて構成パターンを選ぶことが、賢い投資判断につながります。

PoCの評価軸とベンダー選定

大規模な投資の前に、小さく試して実現性を確かめるのがPoC（概念実証）です。GCPは無料枠が手厚いため、PoCのコストを抑えやすく、本格構築の前に「本当に要件を満たせるか」を検証するのに適しています。ただし、PoCを「とりあえず動かしてみる」で終わらせると意味がありません。何をどこまで検証し、何をもって合格とするかという評価軸を、事前に定義しておくことが不可欠です。

PoCの評価軸として定めるべきは、検証する項目と、その合格基準です。たとえば「想定するピーク負荷で応答時間が目標値内に収まるか」「既存システムとのデータ連携が正しく動くか」「想定コストが予算内に収まるか」といった具体的な項目を設定し、それぞれに数値の合格ラインを置きます。検証期間も、だらだらと続けず、数週間といった区切りを設けます。合格基準が曖昧だと、PoCが「なんとなく動いたから本番化」となり、本番で問題が噴出するリスクが残ります。検証で見るべき指標としては、CPU使用率やネットワークI/Oといったリソースの使われ方も含め、本番想定の負荷で無理なく動くかを確かめます。

PoCで見るべきは、技術的な実現性だけではありません。ベンダーがどれだけ自社の要件を理解し、的確に検証を進められるか、というベンダーの実力を見極める機会でもあります。コミュニケーションの質、ドキュメントの丁寧さ、想定外の事態への対応力を、PoCを通じて評価します。検証で出た課題に対し、どう原因を切り分け、どんな代替案を提示してくるかを見れば、本番でトラブルが起きたときの対応力も推し量れます。PoCを発注先選定の判断材料に組み込むことで、本契約後のミスマッチを大きく減らせます。小さく試してから大きく投資する、という段階主義が、GCP導入のリスクを抑える王道です。

ベンダー選定では、複数社からの相見積もりが基本です。ただし、金額だけで比較するのは危険です。一次データでも、構築相場は規模によって大きく幅があり、同じ「GCP構築」でも前提次第で金額が変わります。安い見積もりが、必要な作業を含んでいないだけかもしれません。相見積もりを比較するときは、同じRFPに基づいているか、見積もりに含まれる作業範囲が同じか、を必ず確認します。RFPがしっかりしていれば、各社の前提が揃い、フェアな比較ができます。

金額に加えて確認すべきが、技術力とセキュリティポリシーです。GCPの認定資格や構築実績、自社業界での経験、セキュリティに対する体制やポリシーを確認します。とくにセキュリティは、安かろう悪かろうでは済まされない領域です。ベンダーが自社のセキュリティ基準をどう担保しているか、過去にどんな実績があるかを見極めることが、長く付き合えるパートナー選びの要点になります。あわせて、構築後の運用や改修まで継続して支援できる体制があるかも確認しておくと、リリース後の保守で困りません。RFP・要件定義書を起点に、PoCで実力を確かめ、相見積もりで条件を比較する。この一連のプロセスが、GCP導入を成功に導く土台です。発注ドキュメントへの投資は、構築後の手戻りを防ぐもっとも確実なリスクヘッジだと言えます。

まとめ

GCP導入・構築のRFP・要件定義書を整理すると、成否を分けるのは「非機能要件を数値で定義し、責任分担と運用スコープを明確にし、ワークロードに即した構成パターンを選び、PoCで実力を確かめてから本契約する」という一連の作り込みです。可用性・性能・コスト上限・セキュリティを定量化し、クラウド事業者・ベンダー・自社の役割を切り分け、仮想サーバーとサーバーレスをハイブリッドに振り分け、PoCの合格基準を事前に置く。これらを丁寧に進めることで、過剰でも過少でもない、自社に最適な構築が実現します。

RFP作成で大切なのは、ベンダーに丸投げするのではなく、自社の要件を起点に判断軸を持つことです。要件が明確なRFPは、フェアな相見積もりを可能にし、構築後の手戻りを防ぎ、長く使えるシステムの土台になります。riplaはフルスクラッチ受託と国内開発の立場から、要件整理からPoC、構築、運用までを一貫して支援します。要件定義を全体像とあわせて確認したい方は、あらためて完全ガイドをご活用ください。

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。