情報系システムのRFP/要件定義書/提案依頼書について

情報系システムの発注は、現場の課題を整理し、要件と検収条件を定め、見積もりを確認する順に進めると、業務に合う開発につながります。

情報系システムは社員の情報共有や意思決定を支えますが、現場の課題や使い方が曖昧だと、完成後も使われないおそれがあります。全体像は情報系システムの完全ガイドもご覧ください。

▼全体ガイドの記事
・情報系システムの完全ガイド

情報系システムのRFPに盛り込むべき記載項目

RFPに盛り込む目的や課題、予算、体制、選定基準を4枚のカードで示す図解
共通の前提をそろえるため、目的から選定基準まで整理します。

RFP(提案依頼書)は、ベンダーに要望を伝え、提案と見積もりを依頼する文書です。まずは、RFPに最低限盛り込む項目を押さえておきましょう。

目的や要件が曖昧だと、ベンダーごとに前提が異なり、提案を比較できません。条件を明確にすると、同じ土俵で提案を受けられます。

導入目的・現状課題・背景の記載

社内の課題を洗い出すには、現場への丁寧なヒアリングが前提になります。そのうえで、目的と課題を具体化します。課題が明確になると、ベンダーから解決策や費用を抑える案が出てきます。

  • 導入目的:システムを導入する理由
  • 現状課題:誰が、どの業務のどんな場面で困るか
  • 背景と具体例:課題の背景と、定量的に示せる事例

「情報共有が非効率」「意思決定が遅い」といった漠然とした表現だけで終わらせないことが大切です。たとえば、「月次報告の集計に担当者が3日かかり、経営判断が後手に回っている」のように書けます。

RFPの冒頭で目的と課題を明確に示すことは、提案の質と費用の両方に影響します。目的が曖昧だと、ベンダーは機能を盛り込んだ無難な提案に寄りがちで、費用も膨らみます。

予算・納期・体制・選定基準の記載

予算と納期、自社の体制を示し、選定基準も伝えると、ベンダーは実情に沿った提案をしやすくなります。

  • 予算と納期:予算の目安と希望納期
  • 自社の推進体制:窓口と意思決定できる範囲
  • ベンダーの選定基準:価格、実績、一貫対応などの重視点

予算の上限を示すと、ベンダーは現実的な提案を組み立てられます。一方で、予算がゼロベースだと、過剰な提案や品質を欠く安価な提案を招きがちです。

さらに、同業種・同規模の実績や、要件定義から保守までの対応体制も選定基準になります。基準を共有しておくと、評価がぶれにくくなります。

自社の体制を伝えることで、ベンダーは進め方を具体的に提案できます。RFPは、双方が対話するための共通言語です。

ポイント

項目で迷ったら、その記載がないと各社が同じ前提で提案できないかを基準に選びます。目的と課題は提案の質と費用の両方に影響するため、特に丁寧に書きます。

機能要件と非機能要件の固め方

現状とあるべき姿の業務フローから利用シーン、優先順位、段階的な開発へ進む図解
必須機能を先に定めると、開発の範囲を段階的に組み立てられます。

要件定義書は、RFPの要望を開発の設計図として具体化する文書です。機能要件はシステムが何をするかを、非機能要件はどれくらいの品質・性能で動くかを定めます。後者は使い勝手と安全性を左右するため、両者をバランスよく詰めることが、後の手戻りを防ぎます。

業務フローから機能要件を導く方法

機能要件は、現状(AsIs)とあるべき姿(ToBe)の業務フローを描き、ToBeに必要なものとして導きます。

  • 利用シーン:誰が、いつ、何のために、どんな操作をするかの整理
  • 優先順位:「必須」「推奨」「任意」への振り分け
  • 段階的な開発:MVP(Minimum Viable Product)として、必須機能から作る進め方

利用シーンを起点にすると機能の抜け漏れが減り、不要な機能も避けられます。現場業務に寄り添うことが要件の質を決めます。

効果を見ながら推奨・任意の機能を加える進め方は、定着率の面で有利です。また、要件定義で優先順位を付けておくと、段階的な開発計画も立てやすくなります。一方で、すべてを必須にすると、費用と期間が膨らみ、リスクが高まります。

セキュリティ・性能・データ量の非機能要件

非機能要件はシステムの品質・性能・運用に関する条件です。曖昧なままでは稼働後のトラブルにつながります。

  • セキュリティ:情報へのアクセス、暗号化、認証の条件
  • レスポンス:操作に対する応答速度
  • データ量:データ件数と同時利用者数

非機能要件を具体化するには、希望を数字で表すことが欠かせません。社内の機微な情報を扱い、多くの社員が同時に使うため、これらの要件は曖昧にできません。

「速い」「多い」といった言い方は、「主要画面の表示は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機能は、誤りを許容できない業務を人の確認に残し、許容範囲を事前に決めます。

まとめ

情報系システムのRFPと要件定義書は、開発の成否を左右する土台です。RFPに目的・課題・予算・選定基準を示し、業務フローから機能要件を導きます。

非機能要件は、セキュリティ・性能・データ量を数値で固めておきます。見積もりは、総額だけでなく単価と工数を確認し、保守や隠れコストも含む総保有コストで比べます。AIを使う場合は、生成コードの検収基準と、機能の許容範囲も文書にしておきます。

要件定義では、目的と優先順位を定め、現場の業務に沿って要件を導きます。必須機能をMVPとして先に固め、効果を見ながら段階的に広げると、リスクを抑えられます。

riplaはフルスクラッチ受託と国内開発を組み合わせ、現場ヒアリングからRFP・要件定義の整理、見積もりの精査まで一貫して支援します。

要件定義と費用構造の全体像は、情報系システムの完全ガイドをご覧ください。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。