架空のQ017は、商品Aを10個、10月20日までに出荷してほしいという見積依頼です。営業は受付表とメールを行き来し、現場の担当や回答状況を調べています。

目的は「営業と現場が、同じ依頼番号から担当・元資料・確認状況を見られること」です。営業が1件を開くと、材料と製作予定の確認を誰に頼み、回答が届いたかが分かる状態を目指します。

営業・現場・責任者が現在の道順と資料を確かめ、経営者が目的と予算を判断します。RFPは提案依頼で、仕様や契約の確定ではありません。提案後に、実現方法と役割・取引条件を双方で合意します。

今回作るのは、手入力の受付、現場への確認依頼、回答と状態、番号検索、変更履歴です。価格は営業が社内ルールで決め、責任者が確認し、営業が顧客へ送る今の仕事を残します。

メールの自動読取り、価格・値引きの自動決定、顧客への自動送信、受注・会計・請求との連携は今回含めません。追加提案は基本の見積と分けてもらいます。

依頼メールや見積案は、許可された社内の保存場所へのリンクを持つ案です。リンク先の閲覧権限も条件にします。新しい仕組みへ資料を保管する案なら、容量・権限・運用を別に確認します。

既存ソフトの設定で目的を満たす案も、同じ範囲で求められます。使える機能や契約を確認し、安い・早いと先に決めないでください。

下の表は、Q017を使った提案依頼書の記入例です。依頼・回答・見積案などの資料は架空の想定。実資料を渡す場合は、顧客情報や金額を必要な範囲に絞り、社内の許可と扱い方を確認します。

人数・同時利用人数・依頼件数・資料量は現場の記録から確認します。未確認なら、確認する担当と時期を残します。架空の人数や相場を自社の予算・性能条件として使いません。

完成後の設定変更、異動時の引継ぎ、保存場所の変更、使えないときの仕事の続け方も書きます。自社の担当と開発会社へ頼むことを分けて提案してもらいます。

予算や開始日が未定なら、同じ範囲の費用と段階別の日程を求めます。前提が未確認の提案は確定見積として比べず、再見積に必要な条件を聞いてください。

受入条件は、できあがったものを受け取る前に確かめる条件です。試す資料・操作・期待結果・確認者を組にすると、発注側と開発会社が同じ結果を見られます。

この例では営業が受付、現場が回答、責任者が内容確認の状態を記録する案です。実際の閲覧・編集権限は社内ルールから合意します。資料リンクの先も、必要な人が開け、権限のない人は開けないことを確認します。

正常な登録だけでなく、番号空欄、未回答、権限なしも試します。下図と表は試験条件の案で、製品の標準機能や検証済みの結果ではありません。試した版・操作・実際の結果・確認者を残し、修正後は再確認します。

バックアップ・復旧・引継ぎ・問い合わせも別に条件を詰めます。保存対象、復元できる時点、担当と手順を提案してもらい、合意した試験データで確かめます。画面が動くだけで運用の完成とはしません。

各社へ同じRFPの版を渡し、項目ごとに標準・追加開発・非対応・未確認を答えてもらいます。下図のX社とY社の回答は架空の比較例です。未確認を「できる」「費用ゼロ」と解釈しません。

初期・月額・保守と、人数や件数が増えた場合の条件を分けます。操作説明・データ移行・障害連絡・データ取出しを含むかも確認し、現場の試験と修正後の再確認を含めて日程を比べます。

写真添付を追加したい場合は、理由と保存する資料・権限・費用・日程・受入条件への影響を回答してもらいます。発注側の判断者が今追加するか後で検討するかを決め、元の範囲へ黙って足しません。

質問回答や追加で前提を変えたら、各社へ同じ更新版を渡します。双方で採用する依頼書・提案・見積・仕様と役割の版を確かめ、未決事項には担当と決める時期を残します。