経営者のためのRFP・要件定義入門 — 完璧でなくていい、伝えるべき5項目

RFP（Request for Proposal、提案依頼書）とは、システム開発を発注する際に「何を作ってほしいか」を開発会社に伝えるための文書です。もともとは大企業や官公庁の調達で使われてきた形式ですが、近年は中小企業がシステム開発会社を選ぶ場面でも作成が推奨されるようになっています。理由はシンプルで、口頭や断片的なメールのやり取りだけでは、開発会社ごとに前提条件が異なり、見積金額や提案内容を横並びで比較できないためです。RFPは「完璧な仕様書」である必要はなく、発注側の意図を開発会社に正しく伝えるための最低限の情報整理と考えると取り組みやすくなります。詳しくはシステム開発の発注ガイドでも発注全体の流れを解説しています。

RFPという言葉から、数十ページに及ぶ体裁の整った文書や、法務・調達部門が関与する厳密な入札プロセスを想像する経営者は少なくありません。しかし中小企業の場合、そこまでの形式は多くのケースで過剰です。重要なのは分量やデザインではなく、「何のために」「誰が」「何を」使うのかという核心部分が漏れなく伝わっていることです。極端に言えば、A4用紙1〜2枚に要点を箇条書きでまとめただけでも、内容が具体的であれば十分に機能するRFPになります。形式にこだわって作成が滞るよりも、まず必要な情報を洗い出すことを優先すべきです。

開発会社は、発注側から提示された情報をもとに工数と金額を見積もります。情報が曖昧なままだと、開発会社側は独自の前提（想定される利用人数、必要な機能範囲、既存システムとの連携有無など）を置いて見積もらざるを得ません。この前提が発注側の想定とずれていると、後から「聞いていた話と違う」という追加費用や仕様変更につながりやすくなります。追加費用トラブルを防ぐ方法でも触れているように、初期段階での情報の解像度が低いことは、開発途中のトラブルの主要な原因の一つです。逆に言えば、要点を押さえたRFPを用意するだけで、複数社から精度の高い見積もりを得やすくなり、結果として不要な上振れを避けられる可能性が高まります。

- ①今の業務と困りごと: 現状のやり方と、何に困っているか
- ②誰が使うか: 利用者の人数・部署・ITリテラシーの傾向
- ③絶対に必要なこと・不要なこと: 必須要件と、あえて対象外にする範囲
- ④予算感と期限: 大まかな予算レンジと稼働希望時期
- ⑤既存システム・データ: 連携が必要な既存システムやデータの所在

まず伝えるべきは、現在どのような業務フローになっていて、どこに困りごとがあるかです。「在庫管理を効率化したい」という抽象的な要望だけでは、開発会社側は具体像を描けません。「Excelで在庫を管理しており、複数拠点間での在庫の二重入力が発生している」「月末の棚卸しに丸2日かかっている」など、具体的な業務の様子と課題感を伝えることで、開発会社は解決すべき問題の輪郭をつかみやすくなります。

システムの利用者像も欠かせない情報です。社内の限られたメンバーだけが使うのか、パート・アルバイトを含む多数の従業員が使うのか、あるいは取引先や顧客も操作するのかによって、必要な操作性やマニュアルの作り込み、権限管理の設計は大きく変わります。利用者のITリテラシーの傾向（PC操作に慣れているか、スマートフォンでの利用が中心かなど）も伝えておくと、開発会社側で使いやすさへの配慮がしやすくなります。

限られた予算の中で発注する以上、「これがなければ意味がない」という必須要件と、「あれば嬉しいが今回は不要」という要件を分けて伝えることが重要です。すべてを同列に並べてしまうと、開発会社側は優先順位を判断できず、結果として過剰な見積もりになりがちです。逆に不要な範囲を明示することで、開発会社は無駄な機能を提案から外し、コストを抑えた現実的な提案をしやすくなります。

予算をまったく開示しないまま見積もりを依頼すると、開発会社ごとに想定するグレードがばらつき、比較が難しくなります。厳密な金額でなくても、「300万円前後を想定している」といった大まかなレンジを示すだけで、開発会社は現実的な提案範囲を絞り込めます。同様に、いつまでに稼働させたいかという期限も、開発体制やスケジュールの実現可能性を判断する材料になるため、早い段階で共有しておくべき情報です。

すでに利用している会計システムや販売管理システムなどがあり、新しいシステムと連携させたい場合は、その情報も伝える必要があります。また、既存のExcelファイルや紙の台帳など、移行すべきデータがどこにどのような形で存在するかも重要な情報です。この部分の情報が不足していると、開発が進んでから想定外の連携作業や移行作業が発生し、スケジュールと費用の両方に影響することがあります。

RFPは、発注側の頭の中にある要望を開発会社と共有可能な形に整理するための道具です。大企業のような厳密な形式を目指す必要はなく、今回紹介した5項目——今の業務と困りごと、誰が使うか、必須要件と対象外、予算感と期限、既存システム・データ——をA4 1〜2枚程度にまとめるだけでも、複数社からの見積もりの精度と比較のしやすさは大きく変わります。発注準備の全体像についてはシステム開発の発注ガイド、社内で決めておくべき事項の詳細については発注前チェックリストも参考にしてください。