情報系システムの導入を成功させられるかどうかは、開発が始まる前の「RFP（提案依頼書）」と「要件定義書」の質でほぼ決まる、と言っても過言ではありません。情報系システムは、社員の情報共有や意思決定を支える性質上、現場が何に困っていて、どう使いたいかが曖昧なまま開発に進むと、完成しても誰も使わないという最悪の結果を招きます。だからこそ、ベンダーに渡すRFPと、開発の設計図となる要件定義書を、発注企業側がどこまで解像度高く作れるかが勝負になります。
本記事は、情報系システムのRFP・要件定義書・提案依頼書を、発注企業の視点から実務的に解説する「要件定義特化」の記事です。RFPに盛り込むべき記載項目、機能要件と非機能要件の固め方、ベンダーの見積もりの妥当性を見抜くチェックの仕方、そしてAI時代特有の検収基準まで、具体的に掘り下げます。読み終えるころには、自社で質の高いRFPと要件定義書を作るための骨格が手に入るはずです。なお、情報系システムの全体像をまだ把握していない方は、まず情報系システムの完全ガイドから読むことをおすすめします。
▼全体ガイドの記事
・情報系システムの完全ガイド
情報系システムのRFPに盛り込むべき記載項目
RFP（提案依頼書）は、ベンダーに「こういうシステムを作ってほしい」という要望を伝え、提案と見積もりを引き出すための文書です。RFPの質が低いと、ベンダーは前提を勝手に補って提案するため、各社の提案がばらばらになり、比較もできなくなります。逆に、RFPで目的と要件を明確に示せば、ベンダーは同じ土俵で提案でき、自社にとって最適なパートナーを選びやすくなります。まずは、RFPに最低限盛り込むべき項目を押さえましょう。
導入目的・現状課題・背景の記載
RFPでもっとも重要なのが、「なぜこのシステムを導入するのか」という目的と、現状の課題、その背景です。情報系システムの場合、「情報共有が非効率」「意思決定が遅い」といった漠然とした課題で終わらせず、「どの業務で、誰が、どんな場面で、どう困っているか」を具体的に書くことが大切です。たとえば「月次報告の集計に担当者が3日かかり、経営判断が後手に回っている」というように、定量と具体性を持たせます。
目的と課題を明確に書くと、ベンダーは「その課題を解くにはこの機能が要る」「むしろこういうアプローチの方が安く済む」といった、本質的な提案をしてくれます。逆に目的が曖昧だと、ベンダーは無難に機能を盛り込んだ提案をするしかなく、費用が膨らみます。RFPの冒頭で目的と課題を解像度高く示すことは、その後の提案の質と費用の両方を左右する、もっとも投資対効果の高い一手です。社内で課題を洗い出すために、現場へのヒアリングを丁寧に行っておくことが前提になります。
予算・納期・体制・選定基準の記載
RFPには、目的や機能要件のほかに、予算の目安、希望する納期、自社側の推進体制、ベンダーの選定基準といった枠組みの情報も記載します。予算については「言うと足元を見られる」と隠したくなりますが、おおよその上限を示した方が、ベンダーは現実的な範囲で最適な提案をしやすくなります。予算ゼロベースだと、過剰な提案や、逆に安すぎて品質を欠く提案を招きがちです。
選定基準を明示することも重要です。価格だけで選ぶのか、同業種・同規模の実績を重視するのか、要件定義から保守まで一貫対応できる体制を求めるのか。基準を示せば、ベンダーは自社の強みをそこに合わせてアピールでき、評価もぶれません。また、自社側の体制（誰が窓口で、どこまで意思決定できるか）を書いておくと、ベンダーはプロジェクトの進め方を具体的に提案できます。RFPは要望を一方的に並べる文書ではなく、ベンダーと同じ土俵で対話するための共通言語だと捉えると、書くべき項目が見えてきます。
機能要件と非機能要件の固め方
要件定義書は、RFPで示した要望を、開発の設計図として具体化する文書です。ここでは「機能要件（システムが何をするか）」と「非機能要件（どれくらいの品質・性能で動くか）」を分けて固めていきます。情報系システムでは、機能要件にばかり目が行きがちですが、非機能要件の解像度こそがシステムの使い勝手と安全性を決めます。両者をバランスよく詰めることが、後の手戻りを防ぎます。
業務フローから機能要件を導く方法
機能要件は、いきなり「この機能が欲しい」と並べるのではなく、現状の業務フロー（AsIs）と、あるべき業務フロー（ToBe）を描いたうえで、ToBeを実現するために必要な機能として導くのが王道です。誰が、いつ、何のために、どんな操作をするのかという利用シーンを起点にすると、機能の抜け漏れが減り、不要な機能を盛り込む無駄も避けられます。情報系システムは現場が使うものなので、現場の業務フローへの寄り添いが要件の質を決めます。
機能要件を書くときは、優先順位を明確にすることも重要です。「絶対に必要（必須）」「あると良い（推奨）」「将来的に欲しい（任意）」を区別しておくと、予算や納期の制約に直面したときに、何を削り何を残すかの判断がしやすくなります。情報系システムは、MVPとして必須機能だけ先に作り、効果を見ながら推奨・任意を追加する進め方が定着率の面で有利です。要件定義の段階で優先順位をつけておけば、この段階的な開発計画もスムーズに立てられます。すべてを必須にすると、費用も期間も膨らみ、リスクが高まります。
セキュリティ・性能・データ量の非機能要件
非機能要件は、システムの品質・性能・運用に関する要件で、ここの解像度が低いと稼働後にトラブルが多発します。代表的なのが、セキュリティ（誰がどの情報にアクセスできるか、暗号化や認証をどうするか）、レスポンス（操作の応答速度をどこまで求めるか）、データ量（何件のデータ、何人の同時利用に耐えるか）です。情報系システムは社内の機微な情報を扱い、多くの社員が同時に使うため、これらの要件を曖昧にできません。
非機能要件を具体化するには、数字で語ることが欠かせません。「速くしたい」ではなく「主要画面の表示は2秒以内」、「たくさんのユーザー」ではなく「同時アクセス200名、データ件数100万件を想定」というように、測定可能な形にします。あわせて、稼働後の保守やSLA（サービス品質の保証水準）も要件として明確にしておくべきです。一般に保守費用は年間で開発費の15〜25%程度が目安とされ、これを見込まずに初期費用だけで判断すると、運用フェーズで予算が破綻します。非機能要件を数字で固めることが、安定稼働と妥当な総コストの前提になります。
見積もりの妥当性を見抜くチェックの仕方
RFPを出すと、ベンダーから提案と見積もりが返ってきます。ここで発注企業が問われるのが、見積もりの妥当性を見抜く力です。情報系システムの費用は、人月単価×工数という構造で決まるのが基本ですが、その内訳を理解せずに総額だけ見ると、安すぎる見積もりに飛びついて後で追加請求に苦しむ、といった事態を招きます。見積もりの読み方を押さえておきましょう。
人月単価と工数の内訳を読み解く
見積もりを見るときは、総額ではなく「人月単価」と「工数」の内訳を確認します。人月単価は職種や体制で幅があり、一次データではPM（プロジェクト管理者）が110万〜150万円、設計を担うSEが65万〜110万円、実装を担うPGが50万〜90万円といった水準が目安とされます。発注先の種別でも差があり、フリーランスは50万〜80万円、中小開発会社は80万〜120万円、大手SIerは150万〜200万円といった幅が一般的です。
工数の妥当性は、機能ごとにどれくらいの人月が割り当てられているかで判断します。情報系システムでは、見えやすい画面機能よりも、データ連携や権限管理といった裏側の工数が大きくなりがちです。ここが薄く見積もられていたら、要件を理解していないか、後で追加請求する前提の可能性があります。一般に、要件定義の工数は全体の約20%、設計からテストが約80%という比率が一つの目安とされます。請負契約ではリスクバッファとして人月計算に1.3〜1.5倍の係数が乗ることもあり、これを理解して内訳を見れば、極端に安い見積もりの危うさが見えてきます。
隠れコストと追加請求リスクの見抜き方
見積もりの妥当性を判断するうえで、見えにくい隠れコストへの注意が欠かせません。情報系システムでは、初期開発費だけでなく、稼働後に毎月かかる費用が積み重なります。クラウドの利用料、外部SaaSやAPIの月額、保守・運用の費用などです。保守費用は月額で初期開発費の5〜15%程度、年間で15〜25%程度が目安とされ、3年・5年と使うほど初期費用に匹敵する額になります。見積もりを比較するときは、初期費用だけでなく、数年スパンの総保有コストで見ることが重要です。
追加請求リスクを見抜くには、見積もりに含まれる範囲と含まれない範囲を明確にしておくことです。「データ移行は別途」「連携先の改修は範囲外」「仕様変更は都度見積もり」といった但し書きが、後で大きな追加費用に化けます。要件定義が曖昧なまま進むと工数が当初想定の1.3〜1.5倍に膨張するとも言われ、その膨張分が追加請求として跳ね返ってきます。だからこそ、RFPと要件定義の段階で範囲を明確にし、見積もりにどこまで含まれるかを書面で確認しておくことが、隠れコストと追加請求の最大の防御策になります。
AI時代の検収基準と要件定義の注意点
近年は、AIを使った開発や、AI機能を組み込んだ情報系システムが増えており、要件定義と検収の基準も新しい論点を抱えています。AIが生成したコードや、AIを活用した機能には、従来の検収では見落としがちなリスクが潜みます。情報系システムの要件定義では、こうしたAI時代特有の論点を押さえておくことが、これからますます重要になります。
AI生成コードの品質と検収の基準
AIにコードを生成させる開発手法が広がる一方で、生成されたコードを十分に検証せずに納品する、いわゆる丸投げ型の開発には注意が必要です。AIが生成したコードは、一見動いていても、想定外の入力で不具合を起こしたり、セキュリティ上の弱点を含んでいたりすることがあります。情報系システムは社内の機微な情報を扱うため、こうした隠れた欠陥が情報漏洩につながりかねません。
要件定義の段階で、検収基準を明確に定めておくことが防御になります。単に「動くこと」ではなく、「想定する負荷でも安定して動くこと」「セキュリティ診断をクリアすること」「コードの品質基準を満たすこと」といった検収条件を要件に盛り込みます。AIを使うかどうかにかかわらず、誰が責任を持って品質を保証するのか、生成されたコードの著作権やバグの責任は誰が負うのかを、契約と要件定義で明確にしておくことが、トラブルを避ける鍵になります。検収は形式的な確認ではなく、品質を担保する最後の砦だと位置づけてください。
AI機能を組み込む場合の許容範囲の定め方
情報系システムにAI機能（社内文書の検索を支援するAIや、問い合わせに自動回答するAIなど）を組み込むケースも増えています。こうしたAI機能は便利な反面、事実と異なる回答を生成してしまう「ハルシネーション」のリスクを抱えます。要件定義では、このAIがどこまで正確であるべきか、誤った回答が出たときに誰がどう対処するかという許容範囲を、あらかじめ定めておく必要があります。
許容範囲を定めるには、AIの回答をそのまま信じてよい業務と、必ず人が確認すべき業務を切り分けることが現実的です。たとえば、社内マニュアルの検索補助なら多少の誤りも許容できますが、契約や法務に関わる判断をAIに委ねるのは危険です。要件定義の段階で、AI機能の使いどころと、人によるチェックの仕組みをセットで設計しておくことが、AI時代の情報系システムを安全に運用する鍵になります。新しい技術を取り入れるほど、検収基準と許容範囲の明文化が、要件定義の重要な役割になっていきます。
まとめ
情報系システムのRFP・要件定義書は、開発の成否をほぼ決定づける土台です。RFPには導入目的・現状課題・予算・選定基準を解像度高く書き、要件定義では業務フローから機能要件を導き、セキュリティ・性能・データ量といった非機能要件を数字で固めることが重要です。見積もりは総額ではなく人月単価と工数の内訳で妥当性を判断し、保守費用や隠れコストを含む総保有コストで比較する。そしてAI時代には、生成コードの検収基準やAI機能の許容範囲を要件に明文化することが、新たな必須事項になっています。
要件定義で大切なのは、すべてを完璧に書き切ることではなく、目的と優先順位を明確にし、現場の業務に寄り添って要件を導くことです。必須機能をMVPとして先に固め、効果を見ながら段階的に広げる計画を、要件定義の段階で織り込んでおくと、リスクを抑えた進行ができます。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を創業。