テスト代行のRFP・依頼書の書き方｜記載10項目と提案の比較方法

2026 8/11

2026年8月11日 2026年8月11日

テスト代行の見積もりが、会社ごとに大きく違う。
その原因の多くは、依頼内容の書き方にあります。

条件が曖昧だと、各社は違う前提で見積もります。
結果として、金額の比較そのものが成立しません。

依頼書は、各社に同じ前提を渡すための道具です。
整えるほど、提案の差が実力の差として見えてきます。

この記事では、記載する10項目と書き方を解説します。
提案の比較方法と、発注までの進め方も整理しました。

依頼書を整えると、見積もりの精度が上がる

テスト代行会社は、情報が足りない部分を推測で埋めます。
推測にはリスクが乗るため、金額は高くなります。

逆に、安く見せるために範囲を狭く解釈する会社もあります。
この場合、着手後に追加費用が発生します。

依頼書がない場合	依頼書がある場合
各社が別々の前提で見積もる	同じ条件で比較できる
金額の差の理由が分からない	体制や進め方の差として読み取れる
着手後に範囲の認識違いが出る	合意した範囲が文書に残る
社内の稟議で根拠を示しにくい	目的と効果を説明しやすい

形式は、正式なRFPでなくても構いません。
A4で2〜3枚の依頼書でも、効果は十分にあります。

依頼書に書く10項目

次の10項目を埋めれば、提案に必要な情報がそろいます。
分からない項目は「未定」と書き、決める時期を添えます。

項目	書く内容
1．目的と背景	なぜ委託するか、解決したい課題
2．対象システム	種類、規模、技術構成、利用者数
3．テストの範囲	対象の機能と工程、対象外とその理由
4．依頼する作業	設計、実行、報告のどこを任せるか
5．品質の目標	完了条件、残存欠陥の扱い
6．スケジュール	開始日、リリース日、報告の頻度
7．環境と資料	提供できる環境、資料の有無
8．体制と連絡	自社の窓口、連絡手段、稼働時間
9．制約条件	情報の取り扱い、作業場所、再委託
10．提案してほしい内容	見積もりの内訳、体制、リスクと対策

特に重要なのは、3番と4番です。
この2つが曖昧だと、見積もりは必ずぶれます。

項目別の書き方と記入例

目的と背景｜課題を具体的に書く

「品質を上げたい」だけでは、提案が絞れません。
困っている事象を、数字を添えて書きます。

例：直近3回のリリースで、本番障害が計5件発生した。
原因の多くは、既存機能への影響確認の不足だった。

テストの範囲｜対象外も明記する

対象の機能を一覧で示します。
同時に、含まない範囲も書きます。

例：会員登録、商品検索、注文、決済の4機能を対象とする。
管理画面と帳票出力は対象外。理由は、今回の改修範囲に含まれないため。

対象外を書くと、認識違いの大半が防げます。
理由も添えると、代行会社から不足の指摘を受けられます。

依頼する作業｜工程で切り分ける

「テストをお願いしたい」では、範囲が定まりません。
工程ごとに、依頼の有無を示します。

工程	依頼	備考
テスト計画	自社	方針は社内で決定済み
テスト設計・ケース作成	依頼	レビューは自社が実施
テストデータ準備	依頼	生成データのみ使用
テスト実行	依頼	証跡は指定形式で提出
欠陥の起票	依頼	優先度の判定は自社
完了報告	依頼	リリース判定は自社

工程別の切り分け方は、内製とテスト代行の役割分担｜責任範囲を決める5ステップで詳しく解説しています。

品質の目標｜完了条件を数値で示す

何をもって終わりとするかを決めます。
ここが曖昧だと、検収の場で揉めます。

計画したテストケースをすべて実行済みとする
重大な欠陥は、すべて修正と再確認を完了する
軽微な欠陥は、対応方針を合意したうえで残してよい

完了基準の決め方は、テスト計画の立て方｜計画と計画書の違いから解説も参考になります。

環境と資料｜現状をそのまま書く

資料が不足していても、隠さずに書きます。
実態と違う前提で見積もると、後で必ず調整が入ります。

例：基本設計書はあるが、最新化されていない。
画面仕様は現行システムの動作が正となる。

資料が少ない場合の進め方は、資料なしのテスト代行は可能｜依頼前の準備と進め方にまとめています。

制約条件｜費用に効く条件を先に出す

情報の取り扱いや作業場所は、費用に直結します。
後出しにすると、見積もりのやり直しになります。

個人情報を含むデータは提供しない
作業は国内に限定し、再委託は事前承認とする
環境への接続は、指定した経路のみ許可する
成果物は指定の形式で提出し、終了後に削除する

曖昧なまま出すと起きること

依頼書の不備は、契約後に問題として表面化します。
典型的な4例を挙げます。

不足している情報	起きること
対象範囲が曖昧	着手後に「その機能は範囲外」と言われる
完了条件がない	検収の判断がつかず、リリースが遅れる
環境の制約が未記載	接続できず、作業が待機状態になる
報告の頻度が未定	進捗が見えず、遅れの発見が遅れる

いずれも、書いておけば防げた問題です。
依頼書の作成にかける半日は、後の数週間を守ります。

提案を比較する評価表の作り方

提案が集まったら、金額だけで並べません。
評価軸を先に決め、点数をつけて比べます。

評価軸	見るところ	比重の目安
範囲の理解	依頼内容を正しく捉え、不足を指摘しているか	高
体制	要員の経験、交代時の引き継ぎ方法	高
進め方	報告の頻度と形式、課題の上げ方	中
金額	内訳の妥当性、追加費用の条件	中
リスクの提示	想定される問題と、その対策を示しているか	中

依頼書の不足を指摘してくる会社は、有力な候補です。
言われたとおりに見積もるだけの提案より、実務が読めています。

比較の観点は、テスト代行の見積もりの取り方｜失敗しない依頼前チェックリストもあわせて確認してください。

金額の内訳を必ず確認する

総額だけでは、何にいくらかかるか分かりません。
作業別か要員別かで、内訳の出し方が変わります。

料金体系の違いは、テスト代行の料金体系｜3つの型と選び方で整理しています。

依頼から発注までのスケジュール

依頼書を出してから契約まで、一定の期間が必要です。
逆算しないと、テスト開始日に間に合いません。

段階	期間の目安	内容
依頼書の作成	数日	社内で範囲と制約を整理する
提案の依頼	1〜2週間	各社が質問し、提案書を作る
提案の評価	数日	評価表で比較し、候補を絞る
条件の調整	1週間程度	範囲、金額、契約形態を詰める
契約と準備	1〜2週間	契約締結、環境と権限の準備