RFPや要件定義書は、開発会社へ正確に情報を伝えるために有効です。ただし、機能一覧だけを作っても、プロジェクトの目的や業務背景が伝わらなければ、提案や見積もりの前提がずれます。RFPを作る前には、なぜ開発するのか、どの業務を対象にするのか、何を判断基準にするのかを整理する必要があります。
目的と背景を言語化する
最初に書くべきなのは機能ではなく、開発の目的です。なぜ今システムが必要なのか、現状で何が問題なのか、事業や業務にどのような変化を起こしたいのかを整理します。背景が分かると、開発会社も適切な代替案やリスクを提示しやすくなります。
対象業務と対象外業務を決める
RFPでは、対象範囲だけでなく対象外も重要です。すべてを含めようとすると、提案範囲が広がりすぎます。最初の開発範囲、将来対応する範囲、今回は扱わない範囲を分けることで、比較しやすくなります。
- 今回必ず扱う業務
- 将来的に扱う可能性がある業務
- 今回は対象外にする業務
- 既存システムに残す業務
利用者と権限を整理する
誰が使うのか、誰が管理するのか、誰が承認するのかを整理します。利用者区分が曖昧だと、画面構成、権限設計、通知、承認フローの前提がずれます。
制約条件を共有する
既存システム、利用中のSaaS、セキュリティ要件、社内ルール、希望スケジュール、運用体制などの制約は早めに共有するべきです。制約が後から出ると、設計変更や追加対応につながります。
- 既存システム・外部サービス
- 社内セキュリティルール
- 運用体制
- スケジュール上の制約
提案を比較する基準を決める
複数の開発会社へ相談する場合、比較基準がないと価格や印象だけで判断しがちです。課題理解、実現方法、リスク説明、運用後の改善方針など、比較すべき観点を事前に決めておくことが重要です。