発注者が書くべきは仕様ではありません。「困っていること」です。 そして困っていることは、開発会社には絶対に書けません——それを知っているのは現場にいるあなただけだからです。
この記事は、システム開発を外注するときに発注者側が用意する要件定義とRFP（提案依頼書）を、「何を書くか」より先に**「何は書けて、何は書けないか」から整理します。発注全体の流れはシステム開発の発注 完全ガイドを、金額の話は費用相場と総コストを参照してください。本稿は着手前に発注者が書く文書**に集中します。
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年より前のデータ移行
「やらないこと」が書いてあると、見積もりの前提が揃います。書いていないと、各社が勝手に違う前提を置き、金額が比較できなくなります。相見積もりを取るなら、この項目は必須です（相見積もりの取り方も参照）。
3. RFP（提案依頼書）の最小構成
RFPは分厚いほど良い、というのは誤解です。A4で3〜5枚あれば十分で、必要なのは網羅性ではなく、判断に必要な情報が揃っていることです。
最小構成は7項目です。
1. 背景と目的
- 事業の状況と、このシステムで達成したいこと（売上／時間／リスクのどれか）
2. 現状の業務と困りごと
- 2-1〜2-3 で書き出したもの
3. 対象範囲と、今回やらないこと
- 2-4 で書き出したもの
4. 利用者と規模
- 役割別の人数、想定データ件数（受注 月◯件、商品 ◯点 など）
5. 予算レンジと希望時期
- 「未定」ではなくレンジで。時期は「◯月の繁忙期前」など理由つきで
6. 提案してほしい内容
- 体制、工程とマイルストーン、見積内訳、前提条件と除外事項、保守の範囲
7. 選定基準と選定スケジュール
- 何を重視して選ぶか、いつ決めるか
予算を書くべきか——書いてください
「予算を書くと足元を見られる」と考えて伏せる方がいますが、逆効果です。予算レンジが無いと、開発会社は外す確率を下げるために大きめの構成で提案します。結果として全社の見積もりが高止まりし、比較もできません。
レンジで書けば、開発会社はその範囲で何ができるかを設計して提案します。「300〜500万円で、優先度の高いところから」と書けば、優先順位の提案が返ってきます。それは発注者にとって最も有用な情報です。
提案の受け取り方も書く
「見積内訳」「前提条件と除外事項」を明示的に求めてください。求めないと総額だけの紙が返ってきて、何が含まれているか読めない見積もりを比較する羽目になります。
4. 書いてはいけないこと——過剰な仕様指定
RFPで最も損をする書き方は、理由のない技術指定です。
「データベースはMySQLでお願いします」
こう書いた瞬間、より適した選択肢を持っている会社も、黙ってMySQLで見積もります。提案の幅が消え、あなたは自分の知識の範囲でしか答えを受け取れなくなります。開発会社に払っているのは、まさにその知識に対してです。
制約がある場合は、指定ではなく理由を書いてください。
| ❌ 指定だけ | ✅ 理由つき |
|---|---|
| 「DBはMySQLで」 | 「既存の基幹システムがMySQLで、日次でデータ連携が必要です」 |
| 「AWSで構築してください」 | 「社内規程でデータの国内保管が必須です」 |
| 「React で作ってください」 | 「将来的に社内の担当者が軽微な修正をしたく、その人がReactを読めます」 |
理由が書いてあれば、開発会社はその制約を満たす複数の案を出せます。指定だけだと、一案しか返ってきません。そして「理由が言えない指定」は、たいていどこかで聞いた話であって、あなたの業務要件ではありません。
同じことが画面の指定にも言えます。「この画面にこのボタンを」と描き込むより、「この作業を3クリック以内で終わらせたい」と書くほうが、良い設計が返ってきます。
5. 曖昧さを残していい場所と、潰すべき場所
要件は全部固める必要はありません。固めるべき場所と、固めなくていい場所があります。
| 固める（発注前に決める） | 曖昧でよい（走りながら決める） |
|---|---|
| 対象範囲と、やらないこと | 画面の細かいレイアウト |
| 役割と権限（誰が何を見られるか） | ボタンの文言・色 |
| 扱うデータの種類と量 | 一覧の並び順・絞り込み条件 |
| 法令・社内規程の制約 | 帳票の細かい書式 |
| 検収条件（次章） | 将来の拡張機能 |
左列はあとから変えると設計をやり直すことになるもの、右列は動くものを見てから決めたほうが良いものです。
とくに「役割と権限」は左列である点に注意してください。「あとで権限を分けたい」は、データ構造そのものを変える作業になり得ます。逆に、画面のレイアウトを発注前に固めようとすると、時間ばかりかかって精度は上がりません。
そして——固まっていない箇所は、固まっていないと書いてください。 伏せたまま固定価格の見積もりを求めると、開発会社は不確実性の分を上乗せするか、安く見積もって後から追加請求するかのどちらかになります。どちらも発注者の損です。契約形態の選び方は請負と準委任の使い分けにまとめています。
6. 検収条件を、発注前に書く
最後に、最も後回しにされ、最も揉める項目です。
「何ができたら完成とみなすか」を、契約前に文章にしてください。 稼働後に決めようとすると、決めるのは必ず立場の強い側になります。
書き方のコツは、機能を列挙しないことです。業務がひと回りすることを確認する形にします。
| ❌ 機能の列挙 | ✅ 業務でなぞる |
|---|---|
| 「受注登録機能があること」 | 「受注担当が電話で受けた注文を登録すると、翌朝の出荷リストに反映されている」 |
| 「在庫管理機能があること」 | 「出荷を確定すると在庫が減り、受注画面の在庫数がその値になっている」 |
| 「権限管理機能があること」 | 「倉庫スタッフのアカウントで、他社の受注が見えない」 |
右列は、そのまま検収の手順書になります。検収日に「これで完成ですか？」と問われて困ることがなくなり、開発会社にとってもゴールが明確になります。双方にとって得です。
3つ目の例のように、セキュリティの確認も業務の形で書けます。「他の会社のデータが見えないこと」は、権限設計が正しいかを確かめる検収項目であり、あとから直すと最も高くつく箇所でもあります。
まとめ：発注者の仕事は「事実を渡すこと」
3点に畳みます。
- 本当の失敗は「納期も予算も守られたのに満足されない」こと。 QCD定義なら成功率75%、満足度を含めると52.8%。この差が要件定義の失敗そのものです。
- 発注者が書くのは業務の事実、開発会社が書くのは解決の設計。 誰が・いつ・何に困り・今どう回避しているか——この4つは、あなたにしか書けません。
- 指定ではなく理由を書く。 理由を書けば複数案が返り、指定だけだと一案しか返りません。
要件定義は、技術文書を書く作業ではなく、現場で起きていることを言葉にする作業です。それができていれば、A4で3〜5枚のRFPで十分に良い提案が集まります。
書き出す前の整理に使えるよう、発注前チェックリストを用意しています。「うちの場合は何を書けばいいか」を一緒に整理したい場合は、無料DX診断（30分）で、困りごとの棚卸しから優先順位づけまでお手伝いします。