DevOps基盤の開発を外部に委託するときは、RFP（提案依頼書）と要件定義書で、非機能要件、責任範囲、PoC、セキュリティを順に決めます。
この順で決めておけば、開発途中の手戻りや見積もりのぶれを抑えられます。全体像はDevOps強いの完全ガイドもご覧ください。
▼全体ガイドの記事
・DevOps強いの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
非機能要件として定義すべき項目
DevOps基盤のRFPでは、機能要件以上に非機能要件が重要です。機能そのものより先に、品質・性能・信頼性の水準を決めておく必要があります。
可用性、性能、コスト上限、セキュリティを具体的に決めておくと、完成後に品質の受け止め方がずれるのを防げます。
提案と見積もりの精度も高められます。
可用性・性能の目標値とSLOの定義
可用性と性能は、ベンダーが必要な品質とリソースを見積もれるよう、RFPで具体的な指標にして示します。性能要件も数値で示すと、各社が同じ前提で見積もれます。
- 可用性：年間稼働率など、許容する停止時間の上限
- 性能：ピーク時の同時アクセス数と応答時間
- 処理量：処理すべきデータ量
- SLO：運用後も監視するサービスレベル目標
たとえば、年間稼働率99.9%以上を求めれば、許容するダウンタイムを数値で示せます。
必要な可用性は、ビジネスへの影響度から逆算します。そのうえで、冗長化の費用と停止時の損失を比べ、目標値を決めます。
SLOを要件定義の段階で合意しておくと、開発時の設計指針になるだけでなく、運用後の信頼性管理にも使えます。
コスト上限とランニングコストの明示
RFPには、初期構築費と月々の運用費の上限を要件として示します。従量課金のクラウド費用は、設計次第で大きく変わります。
- インフラ費：規模別の月額相場を踏まえた上限
- 人件費：担当人材の経験に応じた単価
- 保守運用費：開発費に対する年間の費用
インフラの月額費用の目安は、小規模で数千円〜1万円、中規模で3万〜10万円です。
大規模なエンタープライズでは、月額数十万円から100万円以上まで幅があり、構成によって桁も変わります。だからこそ上限を伝えると、ベンダーは予算内で組める構成を提案しやすくなります。
コスト要件では、人件費の比重も見ておく必要があります。クラウド開発費の約8割は人件費とされ、人月単価は初級で月25万〜50万円です。ミドル層は月50万〜80万円、シニアやアーキテクトは月65万〜120万円以上が相場とされています。
AWS認定を持ち設計経験が豊富な人材は、月100万円を超えることもあります。
保守運用費は、年間で開発費の10〜20%が目安です。こうした相場を踏まえて上限を設定すれば、現実離れした予算での提案依頼を避けられます。
初期費と運用費の両面で上限を示しておくと、見積もりの妥当性を判断する土台になります。
責任共有モデルと構成パターンの選定基準
クラウドを前提にしたDevOps基盤の要件定義では、事業者と利用者の責任の分け方を示す「責任共有モデル」の理解が欠かせません。
物理インフラは事業者が管理し、アプリケーションやデータは利用者が管理します。そこで、RFPで責任範囲を整理しておきます。
サービスモデル別の責任範囲の整理
サービスモデルごとに、事業者と利用者の担当範囲は異なります。採用するモデルを決めておくと、自社とベンダーのどちらが何を受け持つかがはっきりします。
- IaaS：OSやミドルウェアの管理も利用者の担当
- PaaS：IaaSより事業者の担当範囲が広い
- サーバーレス：マネージドサービスによる利用者の運用負荷の軽減
たとえば、マネージドサービスを活用して、インフラコストを3分の1程度に削減した事例があります。
一方で、特定のクラウド事業者から離れにくくなるロックインのリスクもあります。そのため、要件定義の段階で、運用負荷の軽減とロックインの回避のバランスを自社の方針として決めておきます。
責任範囲が曖昧なままだと、運用が始まってから役割の押し付け合いが起きるおそれがあります。責任共有モデルを理解しておくことは、適切なサービス選定の前提になります。
構成パターンの選定基準の要件化
ベンダーが自社の要件に合う構成を判断できるよう、代表的な構成案と選定の前提を示しておきます。
- 3層構成：Web、アプリケーション、データベースを分けた形
- CDN配信：静的コンテンツの配信
- サーバーレス：Lambdaなどを使う構成
- マルチAZ：複数領域に分散する高可用性構成
- ハイブリッド：オンプレミスとクラウドの併用
アクセス特性、データ量、可用性要件を伝えておくと、自社に合う構成を提案してもらいやすくなります。
AWS単一のシングル構成は、仮想サーバー1台、データベース1台、DNSの組み合わせで、構築費は20万〜30万円程度です。
次に、サーバーとデータベースを冗長化し、負荷分散装置を加えた中規模構成は、50万〜60万円程度です。さらに、分散ストレージやキャッシュも拡張する大規模構成は、70万円以上が目安です。
可用性とコストのバランスを要件にしておけば、過剰な構成による無駄や性能不足を避けられます。
判断の基準を文書にしておくことが、適正な投資につながります。
PoCの評価軸と合格基準の設計
PoC（概念実証）は、新技術やクラウド構成を本格導入する前に、小規模に試して検証することです。
PoCでは、CI/CD自動化、サーバーレス、コンテナ化が自社で機能するかを確かめます。競合する情報では、検証範囲や合格基準が浅い場合があります。だからこそ、要件定義の段階でPoC設計を詰めておくことが、後の失敗を防ぎます。
検証対象の事前定義
PoCを役立つものにするには、検証の目的を事前に明確にしておく必要があります。そのうえで、技術や構成ごとの問いを要件として定めます。
- CI/CD：デプロイ時間の目標値の達成
- 自動テスト：想定どおりの不具合の検出
- サーバーレス：想定負荷への耐性と見積もり内の費用
目的が曖昧なままの試作では、動いたかどうかの感覚的な評価で終わってしまい、本番導入の判断材料になりません。
事前のアセスメントでは、現行システムのCPU使用率やネットワークのデータ転送量を測って、前提を固めます。
次に、実測データをもとに検証シナリオを作り、利用ツール、負荷条件、測定指標を要件定義書に記載します。
検証項目を事前に言語化し、誰もが同じ検証をできる状態にしておけば、PoCを「やってみた」で終わらせずに済みます。
合格基準と検証期間の目安
PoCの結果を客観的に判定するため、合格条件と検証期間をあらかじめ定めます。
- デプロイ時間：従来の半分以下を合格とする例
- 負荷耐性：想定負荷の2倍まで耐えることを合格とする例
- 検証期間：期限内に基準を満たさない場合の判断
検証期間には目安の区切りを設けます。期限を決めずに検証を続けると、本番へ進めないままリソースを浪費するおそれがあります。
期限内に基準を満たせなかった場合は、構成を見直すか別の方法を検討する判断ルールも置いておきます。
riplaは、フルスクラッチ受託とクラウド構築・運用の伴走を通じて、PoC設計を支援しています。
PoC設計の精度は、DevOps導入の成功確率を左右します。検証項目、合格基準、期間を設計することで、根拠をもって本番導入を判断できます。
セキュリティ・業界コンプライアンス要件の落とし込み
DevOps基盤の要件定義では、セキュリティと業界特有のコンプライアンスを押さえる必要があります。金融、医療、製造などでは、基準を満たさなければ稼働できない場合もあります。
後から加えると大きな手戻りを招くため、RFPや要件定義書の段階で盛り込んでおきます。
競合する情報では業界対応が手薄になりがちで、ここを丁寧に検討すると差別化にもつながります。
業界基準とゼロトラストの要件化
業界特有の規制は業種ごとに異なります。そこで、基準への対応とアクセス制御の方針を、クラウド構成や運用の要件に落とし込みます。
- 金融：FISC安全対策基準への対応
- 医療：3省2ガイドラインへの対応
- 製造：業界特有の要件への対応
- ゼロトラスト：すべてのアクセスを検証する設計
自社に当てはまる業界規制を洗い出し、構成や運用への反映方法を要件定義書に記載します。そのうえで、データの保管場所と暗号化を定めます。アクセス制御と監査ログの保持も、要件定義書に書き込みます。
セキュリティ設計で重視されるゼロトラストアーキテクチャは、社内からの通信も含めて、すべてのアクセスを検証する考え方です。
そのため、認証・認可、通信の暗号化、最小限のアクセス権限を定めます。さらに、セキュリティチェックをパイプラインに組み込み、継続的に検証する仕組みも要件に含めます。セキュリティは、初めから要件に織り込んでおくことが重要です。
RFPに盛り込むべき必須項目の網羅
整理した要件をRFP（提案依頼書）に落とし込む際は、必須項目に抜けがないようにします。
- 目的と範囲：プロジェクトの背景、業務やシステムの対象
- 技術要件：機能・非機能要件、構成パターン、技術方針
- 検証と規制：PoCの有無と評価軸、業界要件
- 体制と計画：予算上限、スケジュール、保守・運用体制
情報が不足していると、ベンダーがリスク分を上乗せした見積もりを出したり、前提のずれた提案を返したりすることがあります。
要件が明確であれば、各社を同じ条件で比べられます。技術力やセキュリティ方針の違いも見極めやすくなります。
riplaは、フルスクラッチ受託、国内開発、クラウド構築・運用の伴走を通じて、発注者のRFP作成を支援しています。
要件を丁寧に固めておくことが、DevOps導入を成功に導くうえで最大の準備です。
まとめ
DevOpsのRFPでは、非機能要件、責任共有と構成、PoC、セキュリティや業界基準を整理します。
可用性・性能・コスト上限は数値で定め、責任分担と構成の判断を明確にします。
PoCでは検証内容と合格条件を決め、業界基準とゼロトラストも織り込みます。
要件定義の精度は、仕様変更に伴う追加コストの抑制にもつながると指摘されています。
要件定義は開発の出発点であり、後工程のコストとリスクを左右する重要な工程です。曖昧なまま進むと、手戻りで費用と期間が膨らんでしまいます。
riplaはフルスクラッチ受託、国内開発、クラウド構築・運用を組み合わせ、発注者の要件定義を支援しています。非機能要件の整理からPoC設計、業界コンプライアンスまで、一貫して伴走します。全体像は完全ガイドをご確認ください。
▼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を創業。