# 発注者が書く要件定義とRFP：「思っていたものと違う」を防ぐために、何を書き、何を書かないか > システム開発の要件定義とRFP（提案依頼書）を、発注者の立場で解説。納期も予算も守られたのに満足されないプロジェクトが2割ある——その差を生む『発注者しか書けない4つのこと』、そのまま使えるRFPの最小構成、過剰な仕様指定がなぜ提案の質を下げるのか、検収条件を発注前に書く理由までを、公開されている実測データに基づいて整理します。 - 公開日: 2026-08-26 - 著者: 友田 陽大 - タグ: システム開発, 発注, 受託開発, 要件定義, 技術選定 - URL: https://tomodahinata.com/blog/system-development-rfp-requirements-definition-guide - カテゴリ: 発注・内製化・コスト - 総合ガイド: https://tomodahinata.com/blog/system-development-outsourcing-guide-vendor-selection-cost ## 要点 - 納期も予算も守られたのに満足されないプロジェクトが約2割ある（日経コンピュータ調査：QCD定義なら成功率75%、満足度を加えると52.8%）。この差が要件定義の失敗そのもの - 発注者が書くべきは仕様ではなく『困っていること』。誰が・いつ・何に困り・今どう回避しているか——この4つは発注者しか書けず、開発会社には推測すらできない - RFPの最小構成は7項目。A4で3〜5枚あれば十分で、分厚さは提案の質を上げない - 過剰な仕様指定は提案の質を下げる。『DBはMySQLで』と書いた瞬間、より良い選択肢を持つ会社が黙って合わせるだけになる - 検収条件は発注前に書く。『何ができたら完成か』を後から決めると、決めるのは必ず立場の強い側になる --- **発注者が書くべきは仕様ではありません。「困っていること」です。** そして困っていることは、開発会社には絶対に書けません——それを知っているのは現場にいるあなただけだからです。 この記事は、システム開発を外注するときに発注者側が用意する要件定義とRFP（提案依頼書）を、「何を書くか」より先に**「何は書けて、何は書けないか」**から整理します。発注全体の流れは[システム開発の発注 完全ガイド](/blog/system-development-outsourcing-guide-vendor-selection-cost)を、金額の話は[費用相場](/blog/system-development-cost-estimate-market-rate-guide)と[総コスト](/blog/system-development-total-cost-of-ownership-guide)を参照してください。本稿は**着手前に発注者が書く文書**に集中します。 --- ## 1. データが示す「本当の失敗」は、納期でも予算でもない まず、要件定義に時間を割く理由をデータで確認します。 日経コンピュータのプロジェクト実態調査（2018年3月1日号）では、1,745件のシステム導入／刷新プロジェクトのうち成功は52.8％、失敗は47.2％でした。ここでの「成功」は**スケジュール・コスト・満足度**の3条件をすべて満たしたものです。 一方、同じ調査シリーズの2014年10月16日号では、成功を「当初予定していた品質・予算・納期（QCD）を順守できた」と定義したところ、成功率は**75％**でした。 定義の差を並べるとこうなります。 | 成功の定義 | 成功率 | 調査 | |---|---|---| | QCD（品質・予算・納期）を順守 | **75%** | 日経コンピュータ 2014年10月16日号 | | スケジュール・コスト・**満足度** | **52.8%** | 日経コンピュータ 2018年3月1日号（1,745件） | 調査年も母集団も違うので単純な引き算はできません。それでも、この2つの数字が同じ方向を指していることは読み取れます。 > **納期と予算は守られたのに、使う人が満足していない。** これが「発注の失敗」の実像に最も近い姿です。システムが落ちたわけでも、予算を超えたわけでもない。**できあがったものが、求めていたものと違った。** そしてこれは技術の問題ではなく、**着手前に何を伝えたか**の問題です。 IPAの集計では、プロジェクトの工期の中央値は**10.1ヵ月**（N=1,396）。その10ヶ月の行き先を決めるのは、最初の数週間に交わした文書です。 --- ## 2. 発注者しか書けない4つのこと 要件定義を「難しそうな技術文書」だと思うと手が止まります。発注者が書くべき部分は技術文書ではありません。**業務の事実**です。 分担はこう考えてください。 | | 書く人 | 中身 | |---|---|---| | **業務の事実** | **発注者** | 誰が・いつ・何に困り・今どう回避しているか | | 解決の設計 | 開発会社 | どんな画面・データ構造・処理で解くか | 発注者が解決の設計まで書こうとすると、開発会社の知見を使えなくなります。逆に業務の事実を渡さなければ、開発会社は推測で作るしかありません。**「思っていたものと違う」は、ほぼこの受け渡しの失敗です。** 発注者しか書けない4つを、具体的に見ます。 ### 2-1. 誰が使うのか（役割と人数） 「社員が使います」では足りません。**役割ごとに分けて、人数を書く。** > 受注担当 3名（毎日／PC）、倉庫スタッフ 8名（毎日／スマホ・手袋着用）、経理 1名（月末のみ／PC）、社長 1名（週1回／スマホ） 倉庫スタッフが手袋をしていることは、開発会社には推測できません。しかしそれが分かれば、ボタンの大きさも、入力方式も、設計が変わります。**役割ごとに「いつ・どの端末で」を添えるだけで、提案の精度が上がります。** ### 2-2. いま何に困っているのか（症状であって、解決策ではない） ここが最も重要で、最も間違えやすい場所です。 | ❌ 解決策で書く | ✅ 症状で書く | |---|---| | 「在庫管理システムが欲しい」 | 「在庫数を電話で倉庫に確認していて、1日30分かかる。しかも聞いた時点の数字なので、受注後に欠品が判明することが月に2〜3回ある」 | | 「顧客管理をデータベース化したい」 | 「担当者ごとにExcelで顧客リストを持っていて、退職時に引き継げなかったことがある」 | | 「スマホ対応してほしい」 | 「現場から事務所に戻らないと入力できないので、報告が翌日になる」 | 右列を渡された開発会社は、**左列では出てこなかった解決策**を提案できます。「在庫管理システム」ではなく「受注画面に倉庫の実数を出すだけで足りる」という提案かもしれません。安く済むほうの答えは、症状を渡さないと出てきません。 ### 2-3. いま、どう回避しているのか 困りごとには、たいてい現場の回避策がついています。二重入力、手書きのメモ、特定の人しか知らないExcelのマクロ、締め日前の残業。 **この回避策こそ、要件の実体です。** 回避策を書き出すと、次の2つが同時に分かります。 - **本当に困っている度合い**（毎日30分の回避 vs 月1回の回避） - **移行時に消える手順**（その回避策を前提に別の業務が回っていないか） 回避策を書かずに発注すると、システムは正しく作られたのに、**現場が回避策を手放せずに二重運用になる**——という失敗が起きます。 ### 2-4. やらないこと 範囲を狭める記述は、範囲を広げる記述より価値があります。 > 今回やらないこと：会計ソフトとの連携、スマホアプリ（Webのみ）、複数拠点対応（本社のみ）、過去3年より前のデータ移行 「やらないこと」が書いてあると、見積もりの前提が揃います。書いていないと、各社が勝手に違う前提を置き、**金額が比較できなくなります**。相見積もりを取るなら、この項目は必須です（[相見積もりの取り方](/blog/system-development-quotation-comparison-guide)も参照）。 --- ## 3. RFP（提案依頼書）の最小構成 RFPは分厚いほど良い、というのは誤解です。**A4で3〜5枚あれば十分**で、必要なのは網羅性ではなく、判断に必要な情報が揃っていることです。 最小構成は7項目です。 ```text 1. 背景と目的 - 事業の状況と、このシステムで達成したいこと（売上／時間／リスクのどれか） 2. 現状の業務と困りごと - 2-1〜2-3 で書き出したもの 3. 対象範囲と、今回やらないこと - 2-4 で書き出したもの 4. 利用者と規模 - 役割別の人数、想定データ件数（受注 月◯件、商品 ◯点 など） 5. 予算レンジと希望時期 - 「未定」ではなくレンジで。時期は「◯月の繁忙期前」など理由つきで 6. 提案してほしい内容 - 体制、工程とマイルストーン、見積内訳、前提条件と除外事項、保守の範囲 7. 選定基準と選定スケジュール - 何を重視して選ぶか、いつ決めるか ``` ### 予算を書くべきか——書いてください 「予算を書くと足元を見られる」と考えて伏せる方がいますが、逆効果です。予算レンジが無いと、開発会社は**外す確率を下げるために大きめの構成で提案します**。結果として全社の見積もりが高止まりし、比較もできません。 レンジで書けば、開発会社は**その範囲で何ができるかを設計して提案**します。「300〜500万円で、優先度の高いところから」と書けば、優先順位の提案が返ってきます。それは発注者にとって最も有用な情報です。 ### 提案の受け取り方も書く 「見積内訳」「前提条件と除外事項」を明示的に求めてください。求めないと総額だけの紙が返ってきて、[何が含まれているか読めない見積もり](/blog/system-development-cost-estimate-market-rate-guide)を比較する羽目になります。 --- ## 4. 書いてはいけないこと——過剰な仕様指定 RFPで最も損をする書き方は、**理由のない技術指定**です。 > 「データベースはMySQLでお願いします」 こう書いた瞬間、より適した選択肢を持っている会社も、黙ってMySQLで見積もります。提案の幅が消え、**あなたは自分の知識の範囲でしか答えを受け取れなくなります**。開発会社に払っているのは、まさにその知識に対してです。 制約がある場合は、**指定ではなく理由を書いてください。** | ❌ 指定だけ | ✅ 理由つき | |---|---| | 「DBはMySQLで」 | 「既存の基幹システムがMySQLで、日次でデータ連携が必要です」 | | 「AWSで構築してください」 | 「社内規程でデータの国内保管が必須です」 | | 「React で作ってください」 | 「将来的に社内の担当者が軽微な修正をしたく、その人がReactを読めます」 | 理由が書いてあれば、開発会社は**その制約を満たす複数の案**を出せます。指定だけだと、一案しか返ってきません。そして「理由が言えない指定」は、たいてい**どこかで聞いた話**であって、あなたの業務要件ではありません。 同じことが画面の指定にも言えます。「この画面にこのボタンを」と描き込むより、「この作業を3クリック以内で終わらせたい」と書くほうが、良い設計が返ってきます。 --- ## 5. 曖昧さを残していい場所と、潰すべき場所 要件は全部固める必要はありません。**固めるべき場所と、固めなくていい場所があります。** | 固める（発注前に決める） | 曖昧でよい（走りながら決める） | |---|---| | 対象範囲と、やらないこと | 画面の細かいレイアウト | | 役割と権限（誰が何を見られるか） | ボタンの文言・色 | | 扱うデータの種類と量 | 一覧の並び順・絞り込み条件 | | 法令・社内規程の制約 | 帳票の細かい書式 | | 検収条件（次章） | 将来の拡張機能 | 左列は**あとから変えると設計をやり直すことになる**もの、右列は**動くものを見てから決めたほうが良いもの**です。 とくに「役割と権限」は左列である点に注意してください。「あとで権限を分けたい」は、データ構造そのものを変える作業になり得ます。逆に、画面のレイアウトを発注前に固めようとすると、時間ばかりかかって精度は上がりません。 そして——**固まっていない箇所は、固まっていないと書いてください。** 伏せたまま固定価格の見積もりを求めると、開発会社は不確実性の分を上乗せするか、安く見積もって後から追加請求するかのどちらかになります。どちらも発注者の損です。契約形態の選び方は[請負と準委任の使い分け](/blog/system-development-contract-types-guide)にまとめています。 --- ## 6. 検収条件を、発注前に書く 最後に、最も後回しにされ、最も揉める項目です。 **「何ができたら完成とみなすか」を、契約前に文章にしてください。** 稼働後に決めようとすると、決めるのは必ず立場の強い側になります。 書き方のコツは、機能を列挙しないことです。**業務がひと回りすることを確認する形**にします。 | ❌ 機能の列挙 | ✅ 業務でなぞる | |---|---| | 「受注登録機能があること」 | 「受注担当が電話で受けた注文を登録すると、翌朝の出荷リストに反映されている」 | | 「在庫管理機能があること」 | 「出荷を確定すると在庫が減り、受注画面の在庫数がその値になっている」 | | 「権限管理機能があること」 | 「倉庫スタッフのアカウントで、他社の受注が見えない」 | 右列は、そのまま**検収の手順書になります**。検収日に「これで完成ですか？」と問われて困ることがなくなり、開発会社にとってもゴールが明確になります。双方にとって得です。 3つ目の例のように、**セキュリティの確認も業務の形で書けます**。「他の会社のデータが見えないこと」は、権限設計が正しいかを確かめる検収項目であり、あとから直すと最も高くつく箇所でもあります。 --- ## まとめ：発注者の仕事は「事実を渡すこと」 3点に畳みます。 1. **本当の失敗は「納期も予算も守られたのに満足されない」こと。** QCD定義なら成功率75%、満足度を含めると52.8%。この差が要件定義の失敗そのものです。 2. **発注者が書くのは業務の事実、開発会社が書くのは解決の設計。** 誰が・いつ・何に困り・今どう回避しているか——この4つは、あなたにしか書けません。 3. **指定ではなく理由を書く。** 理由を書けば複数案が返り、指定だけだと一案しか返りません。 要件定義は、技術文書を書く作業ではなく、**現場で起きていることを言葉にする作業**です。それができていれば、A4で3〜5枚のRFPで十分に良い提案が集まります。 書き出す前の整理に使えるよう、[発注前チェックリスト](/resources)を用意しています。「うちの場合は何を書けばいいか」を一緒に整理したい場合は、[無料DX診断（30分）](/pricing#dx-assessment)で、困りごとの棚卸しから優先順位づけまでお手伝いします。