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