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