システム開発の要件定義はどう依頼する？発注前に整理すべき5つの論点と依頼方法
「要件がまだ固まっていないので、要件定義からお願いしたいのですが」
開発会社への問い合わせで最も多い依頼のかたちであり、最も揉めやすい依頼のかたちでもあります。
任せたはずなのに、出てきた要件定義書が「思っていたものと違う」。指摘すると見積もりが上がり、金額調整で気まずくなる。開発が始まってからも「それは要件に入っていません」「いや、伝えたはずです」の応酬が続く。
この詰まりは、担当者の伝え方が下手だから起きるのではありません。発注側が持っている情報と、開発会社が必要としている情報のあいだのギャップが、依頼という行為に構造的に埋め込まれているからです。
この記事では、システム開発の要件定義をどう依頼すればよいのかを、発注側・進行担当者の目線で整理します。依頼前に何を言語化しておくか、依頼の場で何を確認するか、依頼後にズレを出さないために何を可視化するかまでを扱います。
※ 発注全体の流れや費用感については「Webシステム開発の外注費用｜相場と失敗しない会社の選び方【2026年】」で解説しています。本記事は、そのうち「要件定義の依頼」に絞って深掘りする内容です。
要件が固まっていない段階のご相談も歓迎です。「何から整理すればいいか分からない」という状態のままで構いません。
目次
1. 「要件定義からお願いします」がうまくいかない構造
要件定義を開発会社に依頼すること自体は問題ありません。問題は「依頼する」を「丸投げしてよい」と読み替えてしまうことです。
開発会社は技術的な実現可能性や機能の分解、非機能要件の相場観を持っています。一方で、次の情報は発注側にしか存在しません。
- そのシステムで解決したい業務課題と、その優先順位
- 現場の例外運用（マニュアルに載っていない処理）
- 社内の意思決定プロセスと、最終的に承認する人
- 「これができなければ導入する意味がない」という譲れない一線
これらが渡されないまま要件定義が始まると、開発会社は一般的なベストプラクティスで空白を埋めます。できあがるのは「間違ってはいないが、うちの業務には合っていない要件定義書」です。
しかもズレは、後工程で見つかるほど高くつきます。要件定義段階なら一行の書き換えで済むものが、実装後には作り直し、検収前なら追加費用と納期調整の交渉になります。そしてこの事後発生こそ、「聞いていない」「言ったはず」という感情の対立に変わり、信頼関係を最も削ります。
合意が崩れていく構造はなぜシステム開発は「合意したはず」なのに揉めるのかでも整理しています。
2. 依頼前に押さえる｜要求定義・要件定義・基本設計の役割分担
どこまでが発注側の仕事かを分けておかないと、後で「誰がやるはずだったのか」という責任の議論になります。
| 工程 | 主体 | 決めること | 依頼時の状態 |
| 要求定義 | 発注側 | 何を実現したいか・成功の基準 | 依頼前にたたき台が必要 |
| 要件定義 | 開発会社（発注側が参加） | 要求を実現可能な要件に翻訳する | 依頼して問題ない |
| 基本設計 | 開発会社 | どう実現するか（画面・データ・処理方式） | 依頼して問題ない |
つまり、「要件定義から依頼する」ことはできても、「要求定義まで依頼する」ことは原理的にできません。何を実現したいかは、業務を持つ側にしか答えられないからです。
ただし完璧である必要はありません。粗い箇条書きでも、開発会社はそこに赤を入れる形で進められます。ゼロから聞き出す1時間と、たたき台に赤入れする1時間では、到達する解像度がまったく違います。
非機能要件を先送りしない
依頼の場では機能要件に時間が集中し、非機能要件（応答速度、同時利用者数、停止の許容範囲など）が「一般的な水準で」のまま先送りされがちです。しかしリリース後に「業務時間帯に画面が固まる」と発覚したとき、要件に書かれていなければ追加費用の話になります。
自社だけで言語化するのは難しいため、公開された枠組みを使うのが現実的です。IPA（独立行政法人情報処理推進機構）の「非機能要求グレード」は、非機能要求についてユーザーと開発者の認識の行き違いを防ぐことを目的に、要求項目を網羅的にリストアップし、要求レベルを段階的に示したツール群で、「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」の6つの大項目に分類されています。依頼段階では、この6項目について想定レベルを言葉にできれば十分です。
非機能要件を先送りしない
依頼の場では機能要件に時間が集中し、非機能要件（応答速度、同時利用者数、停止の許容範囲など）が「一般的な水準で」のまま先送りされがちです。しかしリリース後に「業務時間帯に画面が固まる」と発覚したとき、要件に書かれていなければ追加費用の話になります。
自社だけで言語化するのは難しいため、公開された枠組みを使うのが現実的です。IPA（独立行政法人情報処理推進機構）の「非機能要求グレード」は、非機能要求についてユーザーと開発者の認識の行き違いを防ぐことを目的に、要求項目を網羅的にリストアップし、要求レベルを段階的に示したツール群で、「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」「システム環境・エコロジー」の6つの大項目に分類されています。依頼段階では、この6項目について想定レベルを言葉にできれば十分です。
3. 依頼前に整理すべき5つの論点
問い合わせの前に、以下を書き出してください。すべて埋まっていなくても構いません。「埋まっていない箇所がどこか」が分かっていること自体が、良い依頼の条件です。
論点1｜目的と成功の判定基準
「業務を効率化したい」は判定できないため目的になりません。「1件20分の受注入力を10分以内に」まで落とします。ここが決まっていないと、開発途中で「この機能は入れるべきか」と問われたときに判断する基準が存在しません。
論点2｜スコープの境界線（やらないことを書く）
依頼精度を上げるのは、やることのリストではなくやらないことのリストです。対象外の業務・拠点、今回は変えない運用、次フェーズに送るものを明示しておくと、後から出る要望を「追加要望」として正しく扱えます。書かれていなければ、すべてが「当然入っているはず」になります（参考：スコープ管理が崩れる本当の原因）。
論点3｜関係者と意思決定者
要件定義が長引く原因の多くは技術ではなく承認です。レビューする人、最終承認する人、意見は言うが決定権はない人を分けます。「誰の承認をもって確定とするか」を共有するだけで、上位者のちゃぶ台返しはかなり防げます。
論点4｜現状業務と例外運用
現状フローを粗くてよいので書き出します。各業務について「誰が→何を受け取り→何をして→誰に渡すか」が1行で追えれば十分です。重要なのは、そこに乗らない例外運用のほうです。マニュアルにも載っておらず、現場の担当者に聞かないと出てこない処理が、リリース直前に「これができないと業務が回らない」と判明します。
論点5｜予算レンジと譲れない一線
予算を伏せると開発会社は前提が立てられず、提案の粒度が下がります。「上限」ではなく「投資判断のレンジと根拠」を伝えるのが現実的です。あわせて「これがなければ導入する意味がない」機能を1〜3個に絞ってください。予算調整が必要になったときの判断軸になります（相場はWebシステム開発の外注費用を参照）。
Enlytディレクターの現場から｜「例外はありますか」では出てこない
ヒアリングで「例外的な処理はありますか」と聞いても、多くは「特にないです」と返ってきます。例外は当事者にとって日常であり、例外として認識されていないからです。
そこでEnlytのディレクターは聞き方を変えます。「この処理、うまくいかないときはどんなときですか」「新人に引き継ぐとき、口頭で補足していることはありますか」。つまずきから逆に辿ると、マニュアルにない運用が出てきます。ここで拾い損ねた例外は、必ず検収前後に戻ってきます。
4. 要件定義の依頼方法｜問い合わせから合意までの進め方
ステップ1｜問い合わせ時に渡すもの
上記5論点を1〜2枚にまとめて渡します。正式なRFP（提案依頼書）は初回相談では不要です。取引実績のないベンダーの情報を幅広く集める段階では、RFI（情報提供依頼書）を先に使う選択肢もあります。
ステップ2｜初回ヒアリングで開発会社を見る
ここは、発注側が開発会社の進め方を見極める場でもあります。見るべきは提案の華やかさではなく質問の質です。「その業務、例外的な処理はありますか」「この機能がないとリリースできない優先度は」「どなたの合意をもって確定としますか」こうした問いが相手から出てくるかを確認してください。機能の話だけで見積もりに向かう場合は、途中で認識齟齬が出る可能性が高いと考えたほうが安全です。
ステップ3｜契約形態と成果物を確定する
要件定義を有償の独立工程とするか、成果物は何か（要件定義書・業務フロー・画面一覧・非機能要件一覧など）、完了条件は誰の承認か、他社に開発を移す場合に成果物を使えるか。ここを曖昧にしたまま進めるのは危険です。無償の要件定義は必然的に工数が抑えられ、掘り下げが浅くなります。
ステップ4｜要件を「決定」「検討中」「対象外」に分ける
打ち合わせを重ねると、決まったことと決まっていないことが同じ資料に混在します。これが「合意したはず」問題の温床です。検討中の項目には必ず「誰が」「いつまでに」「何を判断すれば決定になるか」を併記してください。期限と担当のない検討中は、実質的に放置されます。
ステップ5｜変更管理のルールを、揉める前に決める
要件は必ず変わります。問題は変わることではなく、変わったときの扱いが決まっていないことです。変更要望の窓口、影響を回答するまでのリードタイム、誰の承認で確定するか、軽微な変更の線引き。これがあると、変更の話が「お願いできませんか」という交渉から「影響はこうです、判断をお願いします」という手続きに変わります。責任分界の詰め方はシステム開発の責任範囲はどこまで？を参照してください。
Enlytディレクターの現場から｜議事録は「読み物」ではなく「台帳」にする
議事録を発言の記録として時系列でまとめると、決定と保留が同じ文章に溶け、後から「どこが確定だったか」を誰も特定できなくなります。
Enlytのディレクターが残すのは、決定・検討中・対象外に分けた一覧です。検討中の行が空欄のまま次の打ち合わせを迎えた項目は、その場で優先的に扱います。曖昧さを残さないというのは精神論ではなく、曖昧なまま次に進めない形式を使うということです。
5. 依頼の場で潰しておきたい「曖昧語」
口頭では出さない「いい感じに」も、文書になると「適切に」「必要に応じて」「基本的に」に姿を変えて紛れ込みます。
| 曖昧な依頼 | ズレる理由 | 具体化した依頼 |
| 検索を使いやすく | 「使いやすい」の基準がない | 氏名・メールの部分一致。0件時は「該当なし」を枠内表示 |
| 大量アクセスでも問題なく | 「大量」「問題なく」に数値がない | 同時500リクエストで応答2秒以内 |
| 権限は柔軟に設定できるように | 「柔軟」の範囲が読み手任せ | 管理者・承認者・一般の3種。承認者は自部署のみ閲覧可 |
| 既存システムと連携する | 方式・頻度・項目が未定義 | CSVを日次バッチで連携。項目は別紙12項目 |
| エラー時は適切に処理 | 異常系の挙動が未定義 | 通信失敗はトースト＋再試行、入力エラーは項目直下に赤字 |
判定基準はひとつ、「誰が読んでも1通りにしか読めないか」です。発注側が完璧にやる必要はありませんが、「ここは自分たちでは具体化できない」と自覚して依頼できるかで、開発会社の掘り下げ方は変わります（詳細は仕様書は渡したのに、なぜ違うものが上がってくるのか）。
6. 依頼先を見極める質問と、多拠点体制の確認ポイント
商談で次を聞いてみてください。回答の具体性が、そのまま進行品質の指標になります。
- 要件定義の成果物と完了条件は
- 要件が途中で変わったとき、どう扱うか
- 非機能要件はどうやって決めるか
- 進捗では何が可視化されるか
- 開発チームはどこにいて、仕様は誰が翻訳するか
- 似た案件で、一番揉めたのは何だったか
特に6つ目が有効です。揉めた経験を構造として説明できる会社は、同じ火種を先回りして潰す設計を持っています。「特に問題は起きませんでした」は、そのままでは安心材料になりません。
開発チームが海外拠点にある場合、確認すべきは「多様性を尊重していますか」ではなく、どこを標準化し、どこを明文化し、誰が翻訳し、どこでズレを早期発見しているかです。あわせて、週次でリスク（まだ起きていない懸念）と問題（すでに起きた事象）を分けて扱っているかも聞いてください。問題だけを追う体制は火消しに終始し、リスクを拾う体制は火種の段階で手を打てます。
Enlytディレクターの現場から｜「なんとなく不安」を放置しない
リモートでは、同じ場所にいれば表情や雑談から拾えていた違和感がテキストに埋もれます。
Enlytでは、ディレクターが抱えた「まだ問題ではないが引っかかっている」感覚を個人に留めません。週次のヒアリングでPMOに上げ、リスクとして扱うか様子を見るかを第三者の目で切り分けます。ひとつの案件で見つかった火種は横展開し、次の案件の確認項目に組み込む。暫定的にどう収めたかだけでなく、次から起こさないために何を標準に足したかまで残すのがEnlytのやり方です。
よくある質問（FAQ）
Q.要件が全然固まっていない状態で問い合わせてもよいですか？
問題ありません。ただし「何も決まっていない」と「何が決まっていないかが分かっている」では初回打ち合わせの生産性が大きく変わります。目的・やらないこと・譲れない一線の3つだけでも書き出してからご相談ください。
Q.要件定義書は誰が作るのですか？
一般的には開発会社が作成し、発注側がレビュー・承認します。ただし内容の正しさを判断できるのは業務を持つ発注側だけです。「読んで承認する」ではなく「一緒に作る」関与が、結果的に手戻りを減らします。
Q.要件定義だけ依頼して、開発は別会社に頼めますか？
可能な場合もありますが、成果物の権利帰属と他社での利用可否を依頼前に書面で確認してください。あわせて、要件定義を行った会社が開発を担当しない場合、実現可能性の担保が弱くなる点も踏まえた判断が必要です。
Q.小さく始めたい場合、要件定義も軽くできますか？
量は減りますが、目的・成功基準・やらないことの明確化はむしろ重要になります。何を検証したいかが曖昧だと、リリースしても判断がつかないためです（参考：中小企業の新規事業はMVP開発から始める）。
まとめ｜要件定義の依頼方法は「渡し方」の設計である
要件定義をどう依頼するかは、突き詰めると発注側が持つ情報を、どの粒度で、誰に、いつ渡すかの設計の話です。目的と成功基準、やらないことの境界、意思決定者、例外運用、譲れない一線——この5つは発注側にしか出せません。ここが渡されないまま始まる要件定義は、精度ではなく運に依存します。
この記事の要点
- 要件定義は依頼できるが、要求定義（何を実現したいか）は依頼できない。粗くてもたたき台を用意する
- 依頼前に整理するのは目的と成功基準・やらないこと・意思決定者・例外運用・予算レンジと譲れない一線の5つ
- 初回ヒアリングは、開発会社の質問の質を見極める場でもある
- 要件は「決定」「検討中」「対象外」に分けて残す。検討中には期限と担当を必ず併記する
- 変更管理のルールは、揉める前に決める。変更の話が交渉から手続きに変わる
- 「適切に」「柔軟に」は、誰が読んでも1通りにしか読めない表現に置き換える
- 多拠点体制なら、どこを標準化し、誰が翻訳し、どこでズレを早期発見するかまで確認する
依頼した後の質は、丁寧さではなく仕組みで決まる
決定と検討中を分けて残す、変更管理を揉める前に決める、曖昧語を具体に置き換える、リスクと問題を切り分けて週次で追う。どれも特別な技術ではなく、標準の進め方として持っているかどうかの差です。
ここで価値を発揮するのは、タスクを管理する担当者ではありません。曖昧さを減らし、期待値を揃え、事後発生を先回りして防ぎながら、プロジェクトを前に進めるPM/ディレクターです。
Enlytでは、受注前の要件整理から、要件・完了条件の構造化、UI/UX起点の体験設計、見える化された進行管理までをワンチームで支援しています。日本のディレクターがブリッジとなり、ベトナム拠点の開発チームへ仕様を翻訳・構造化して渡す体制を、属人的な調整力ではなく標準化された運用として持っています。どの言葉を具体化してから渡すかという観点までチームで共有しているため、担当ディレクターが誰であっても、開発チームに届く要件の粒度が揃う。これが、多拠点でも進行品質を落とさずに進められる理由です。
要件が固まっていない段階のご相談も歓迎です。「前回の開発で何がまずかったのかを言語化したい」といったご相談からでも構いません。
関連記事
- なぜシステム開発は「合意したはず」なのに揉めるのか｜合意形成のズレを防ぐ進め方──依頼後の打ち合わせで「決めたはず」が崩れていく構造と防ぎ方。
- システム開発の責任範囲はどこまで？発注者と開発会社が「検収間際」で揉めないための切り分け方──要件定義段階で決めておくべき責任分界を、検収から逆算して整理。
- 仕様書は渡したのに、なぜ違うものが上がってくるのか｜解釈のズレを生む構造と防ぎ方──曖昧語の言い換えと着手前の読み合わせの実務を解説。
