ICTシステムの開発・導入を外部に委託するとき、成否の8割を決めるのがRFP（提案依頼書）と要件定義書の質です。
「何を、どこまで、どの品質で作るか」が曖昧だと、見積もりがばらつき、追加費用も膨らみます。全体像は、ICTシステムの完全ガイドで先に掴んでおくと理解が深まります。
▼全体ガイドの記事
・ICTシステムの完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
非機能要件（可用性・性能・コスト・セキュリティ）の書き方
ICTシステムのRFPでもっとも差がつくのが、非機能要件の記述です。機能要件（何ができるか）は比較的書きやすい一方、可用性・性能・コスト・セキュリティといった非機能要件は曖昧になりやすいものです。
ここが甘いと、見積もりが跳ね上がったり、後から仕様変更で揉めたりします。逆に、非機能要件を数値で明示できれば、各社の提案を同じ条件で比較でき、適正な費用で発注できます。
可用性・性能のSLAレベル定義
基幹に近い、止められないシステムでは、マルチAZやEFS、ElastiCacheを活用した高可用性構成が必要になり、構築相場は70万円以上です。一方、止まっても短時間なら許容できる社内ツールであれば、シングル構成の20万〜30万円で済みます（出典：ripla）。
要件次第でコストが数倍変わるため、過剰にも過少にもしないことが肝心です。
性能の数値が分かれば、開発会社は自動スケーリングやインスタンスサイズを適切に設計できます。
性能要件が曖昧なままだと、過剰なスペックで無駄なコストを払うか、逆に本番でパンクするか、どちらかになりがちです。
仮想サーバーの料金は構成によって変わり、たとえばLinux 2コア約8GBで月60〜80ドル前後です（出典：ripla）。こうしたコスト感を持ったうえで、必要十分なスペックを要件として示すのが理想です。
可用性と性能は、次の2点を要件に数値で書いておくと、提案を比べやすくなります。
- 可用性：年間の稼働率と、障害時に何時間以内に復旧するかの目標
- 性能：想定の同時アクセス数、ピーク時のリクエスト量、応答時間の目標
稼働率は、たとえば99.9%なら年間の停止許容が約8.7時間です。停止の上限が見えていれば、開発会社はそれに見合った構成を提案できます。
性能とコストは表裏一体なので、要件には「将来の拡張余地」も含めて書いておきます。立ち上げ当初は小さく、利用が伸びたら無理なくスケールできる構成を求めるのか、最初からピークを見込んだ構成にするのかで、初期費用も運用費も変わります。
クラウドの強みは、後からスペックを柔軟に変えられる点です。そのため、多くの場合は「小さく始めて段階的に拡張する」方針を要件に示したほうが、無駄な初期投資を避けられます。
コスト上限とランニング費用の要件化
RFPには、初期構築費の上限だけでなく、運用後のランニング費用の上限も要件として含めるべきです。
ICTシステムは構築費だけを見て発注すると、運用フェーズで想定外のインフラ費や転送量課金に苦しむことがあります。
インフラ月額は、小規模で数千円〜1万円、中規模で3万〜10万円、大規模で数十万〜100万円以上が相場です。保守運用は、年間で開発費の10〜20%が目安です（出典：ripla）。
発注側は、相場を踏まえて月額コストの上限を要件に書いておくと、開発会社はコストを意識した構成を提案します。
コスト要件を書くうえで効くのが、クラウド各社の料金特性を踏まえた指定です。たとえば、3年契約のリザーブドで仮想サーバーを割安に確保する方針（Azureハイブリッド特典なら月29.9ドルまで下がる）や、サーバーレスでアイドルコストをゼロにする方針があります。
こうした方針を要件として示せば、提案の精度が上がります（出典：ripla）。コストは、運用で下げ続けるものです。その前提を、要件定義の段階から開発会社と共有することが大切です。
ランニング費用は、次の2点を分けて要件に書きます。
- 月額インフラ費：小規模から大規模までの相場を踏まえた上限
- 保守運用費：開発費に対する年間の割合を踏まえた見込み額
クラウド責任共有モデルの要件化
クラウドを使うICTシステムでは、「どこまでをクラウド事業者が守り、どこからを自社・開発会社が守るのか」という責任共有モデルの理解が欠かせません。
ここを曖昧にしたまま要件定義を進めると、セキュリティ対策の抜け漏れが生じ、後から重大な事故につながります。そのため、RFPには、どこまでを誰が担うかを明確にしたうえで、自社・開発会社側が担うべき対策を要件として書き込みます。
責任分界点と自社が担うセキュリティ要件
責任共有モデルでは、おおまかに「クラウド事業者は基盤（データセンター・物理サーバー・ネットワーク）の安全を守り、利用者はその上に載せるデータ・アプリケーション・アクセス権限を守る」という分担になります。つまり、クラウドを使ってもセキュリティが丸ごと事業者任せになるわけではありません。
近年は、すべての通信・アクセスを信用せず都度検証する「ゼロトラスト」の考え方を、要件に組み込むケースも増えています。ゼロトラストでは、社内ネットワークなら安全という前提を置かず、誰が、どの端末から、どのデータにアクセスするかを常に検証します。
責任共有モデルと組み合わせ、自社が守るべき範囲でゼロトラストをどう実装するかを要件に明示すると、セキュリティの抜け漏れを構造的に防げます。
RFPには、自社・開発会社が担う対策の範囲を具体的に列挙します。主な対策は次の2つです。
- データの保護：データの暗号化、アクセス制御
- 認証の設計：利用者をどう認証するか
業界別コンプライアンス要件の落とし込み
業界によっては、満たすべき固有のコンプライアンス基準があります。これを要件定義に落とし込まないと、構築後に作り直しが発生します。
たとえば、金融分野ならFISC（金融情報システムセンター）の安全対策基準、医療分野なら3省2ガイドライン、製造業なら業界固有の要件などがあります。こうした領域は、競合の解説でも手薄になりがちで、要件化できているかどうかが提案の質を分けます。
自社の情報システム部門や監査部門と連携して、基準に沿った要件をRFPに反映します。そのうえで、クラウドがその基準を満たせる構成かどうかも、提案段階で開発会社に確認できる粒度まで書き込むことが、後戻りを防ぐ要点です。
業界コンプラ要件では、次の2点を押さえます。
- 基準と条項：満たすべき条項までの特定
- データの扱い：種類、保存場所、アクセス記録の具体化
基準名だけでは、開発会社が解釈を誤ったときに充足できません。
コンプラ要件と並んで、データの保管場所（リージョン）も要件に含めておくと安心です。業界や扱うデータの種類によっては、国内のデータセンターへの保管が求められる場合があります。
クラウド事業者がどのリージョンを提供しているか、自社の要件を満たすリージョンで構築できるかを、要件定義の段階で確認しておくことが大切です。これを後回しにすると、構築後に「規制上、この保管場所では運用できない」という事態に陥り、移設という大きな手戻りが発生します。
責任共有、コンプラ、データ保管場所を一体で要件化することが、セキュリティ面の失敗を防ぐうえで有効です。
構成パターン選定基準の要件化
ICTシステムの要件定義では、どんなアーキテクチャ構成で作るかの選定基準も整理しておくと、提案を評価しやすくなります。
代表的な構成パターンには、Web3層、静的サイト＋CDN、サーバーレスがあります。さらに、マルチAZ高可用性やハイブリッドもあり、それぞれ得意領域とコスト特性を持っています。
発注側が、要件として「どの特性を重視するか」を示せば、開発会社は最適なパターンを提案でき、各社の提案を比べる観点も明確になります。
ワークロード特性から構成を選ぶ判断基準
構成の選定基準は、システムのワークロード特性から逆算します。
常時高負荷で安定稼働が必要なら、コンテナ（ECS Fargate）や仮想サーバーが候補になります。止められない基幹なら、マルチAZの高可用性構成が必要です。
判断基準を要件として共有すると、開発会社の提案が的を射たものになります。
構成パターンの選定では、ベンダーロックイン（特定クラウドへの依存）の回避方針も要件に含めると、将来の自由度を確保できます。クラウド独自のマネージドサービスを多用すると便利な反面、他社クラウドへの移行が難しくなります。
コンテナを使ってアプリケーションの可搬性を保つ、マルチクラウドを見据えて標準的な技術で組む、といった方針を要件に書いておけば、長期的なロックインリスクを抑えた構成を引き出せます。
どこまでロックインを許容するかは、コストと自由度のトレードオフとして、要件定義で意思決定すべき論点です。
構成を選ぶときは、次の2つの観点で業務の性質を整理しておきます。
- アクセスの変動と処理の長さ：サーバーレスが有力かどうかの判断材料
- 常時の負荷と停止の可否：コンテナ、仮想サーバー、マルチAZ構成の選び分け
サーバーレス（Lambda＋API Gateway＋DynamoDB）は、アクセスの変動が大きく処理が短い場合に向いていて、アクセスが少〜中程度なら月数百円〜に収まります（出典：ripla）。
相見積もりで比較する観点のRFPでの統一
RFPの目的の一つは、複数社の相見積もりを同じ条件で比較することです。比較では、提案内容の妥当性のほか、技術力、セキュリティポリシー、過去の類似実績などを確認します。
ICT開発は費用の約80%が人件費を占めるため、見積もりの内訳を正しく評価するには、その中身まで見る必要があります（出典：ripla）。
見積もりを比較するときは、PM（プロジェクトマネージャー）費用が開発費の10〜20%（300万円案件なら30万〜60万円）含まれているかも確認します（出典：ripla）。
この費用が計上されていない安い見積もりは、進行管理が手薄になるリスクをはらみます。安さだけで選ぶのではなく、要件をどこまで正確に理解しているかも比べる材料にします。
非機能要件への対応が具体的かを、RFPで揃えた条件のもとで見極めることが、適正な発注につながります。
見積もりを比べるときは、次の2点を揃えて確認します。
- 前提と範囲：各社が同じ条件で見積もっているか
- 人材構成：工程ごとに、どの人材を何人月充てるか
各社が独自の前提で見積もると、金額を並べても比べられません。
見積もりの内訳を読むうえでは、人月単価の構成も確認します。人件費が費用の大半を占めるため、初級（経験1年）は月25万〜50万円、ミドルは月50万〜80万円です。
シニア・アーキテクト（経験5年以上）は月65万〜120万円以上で、AWS認定を保有し設計経験が豊富な場合は、月100万円超になることもあります（出典：ripla）。
RFPでスコープと前提を揃えたうえで、この体制まで含めて各社を比較することが、安かろう悪かろうを避ける要点です。
PoCの評価軸の決め方
大規模なICTシステムや新しい技術を採用する場合、いきなり本番構築に進む前に、PoC（実証実験）で技術的な成立性を確かめる進め方が有効です。
ただし、PoCは「何をどこまで検証し、何をもって合格とするか」を要件定義の段階で決めておかないと、漫然と試して終わってしまいます。評価軸を事前に言語化することが、PoCを意思決定につなげるうえで欠かせません。
合格基準・期間・検証範囲の事前定義
PoCの要件定義では、まず検証したい論点を絞り込みます。性能が出るか、既存システムと連携できるか、コストが想定内に収まるかといった、本番化の可否を左右する論点に限定します。
そのうえで、それぞれに合格基準（例：想定負荷で応答時間が目標値以内、連携データの整合率が一定以上）と検証期間の目安を定めます。
アセスメントで見る指標は、CPU使用率やネットワークI/Oといった具体的な数値にしておくと、判断がぶれません。合格基準を事前に決めておくと、PoCの結果を「本番に進む／進まない／構成を見直す」の意思決定に直結できます。
基準なきPoCは、技術検証のつもりが「なんとなく動いたから本番化」という曖昧な判断を招き、後の失敗につながります。そのため、PoCの評価軸、期間、検証範囲を要件定義書に明記することは、本番投資の前にリスクを見極めるうえで、費用対効果の高い工程設計だと言えます。
PoCの要件定義では、次の2点を先に決めておきます。
- 検証の論点：本番化の可否を左右する性能、連携、コストに絞る
- 合格基準：想定負荷での応答時間など、数値で示せる条件
PoCの前段として、現状のアセスメント（現状調査）を要件に位置づけることも有効です。既存システムのCPU使用率やネットワークI/Oといった稼働指標を測り、どこに負荷が集中し、どのリソースが過剰か過少かを把握しておくと、移行後の構成を根拠を持って設計できます。
アセスメントなしに「だいたいこれくらい」で構成を決めると、過剰スペックで無駄な費用を払うか、本番でパンクするかのどちらかに陥ります。要件定義では、アセスメントで何を測り、PoCで何を検証し、何をもって合格とするかを一連の流れとして設計することが、本番化の確度を高めます。
要件定義の精度と仕様変更コストの抑制
要件定義に時間をかける最大の理由は、後工程の仕様変更コストを抑えるためです。開発が進んでから要件の漏れや認識違いが発覚すると、設計のやり直しや追加開発が発生し、費用も納期も膨らみます。
逆に、要件定義の段階で非機能要件・担当範囲・構成方針・PoC基準まで詰めておけば、仕様変更を最小化でき、当初の見積もりに近い形でプロジェクトを着地させられます。要件定義の精度こそ、ICTシステムのコストコントロールの出発点です。
自社だけで非機能要件や業界コンプラ、PoCの評価軸まで網羅的に書き切るのは、容易ではありません。
riplaは、フルスクラッチ受託とクラウド構築・運用の立場から、RFP・要件定義書の作成段階を伴走し、非機能要件の数値化、責任共有の整理、構成パターンの選定基準づくりを支援しています。
要件を発注前に固め切れるかが、ICTシステム導入の成否を分けます。
要件定義で詰めておく事項は、次の2つです。
- 非機能要件と担当範囲：可用性や性能、セキュリティの数値と、担当の範囲
- 構成方針とPoC基準：構成パターンの選び方と、PoCの合格条件
要件定義書には、運用・保守の体制要件も忘れずに含めます。誰が監視を担い、障害時にどう対応し、改修をどう回すのかを発注前に決めておかないと、構築後に「作ったのに運用できない」という事態に陥ります。
保守運用は、年間で開発費の10〜20%（開発500万円なら年50万〜100万円）かかる前提です（出典：ripla）。そのうえで、運用代行を使うか、内製で回すかを決めます。
スキルトランスファー（技術移転）をどこまで求めるかまで要件に書き込めば、長期にわたって価値を保てるシステムになります。
要件定義は、構築の設計図であると同時に、運用の設計図でもあると捉えることが大切です。
まとめ
ICTシステムのRFP・要件定義書では、非機能要件（可用性・性能・コスト上限・セキュリティ）を数値で書くことが大切です。その理由は、可用性要件によって構築費が20万〜30万円から70万円以上まで変わり、業界によってはFISCや3省2ガイドラインといったコンプラ基準の充足も必要になるためです。
要点は、クラウドの責任共有モデルを理解して自社が守るべき範囲を明示し、構成パターン選定の基準とロックイン回避方針を示すことです。さらに、PoCの合格基準、期間、検証範囲を事前に定義しておくことも欠かせません。
これらを発注前に固め切ることが、適正なコストと品質につながります。要件定義の精度は、後工程の仕様変更コストを直接左右します。
発注の段階で非機能要件・担当範囲・構成方針・PoC基準まで詰めておけば、追加費用を抑え、当初見積もりに近い形でプロジェクトを着地させられます。
riplaは、フルスクラッチ受託とクラウド構築・運用の伴走を組み合わせ、RFP作成から要件の数値化・整理まで一貫して支援します。全体像の確認には、あらためて完全ガイドをご活用ください。
▼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を創業。