「要件定義書がないとシステム開発会社に相談できない」は本当？

「要件定義書がないと相談できない」と書かれた開発会社のサイトを見て、相談を諦めた——そんな経験はないだろうか。

現場の困りごとはある。予算感もぼんやりある。だが画面一覧もAPI仕様もない。その状態で問い合わせフォームを開いては閉じる、はよくある。

結論から言う。要件定義書がなくても相談できる。 ただし、何もない状態と、整理途中の状態では話の質がまったく違う。要件定義書は相談の結果であって、前提条件ではない。

結論：相談前に揃える最小セット

揃えるもの	なくても相談できるか	あると何が良くなるか
事業課題と理想状態	必須に近い	論点がズレない
制約（期限・予算感・既存）	あった方がよい	実現可能性の話ができる
利用者と規模感	あった方がよい	MVPの切り方が早い
画面・APIの詳細仕様	不要	見積もり精度が上がる段階で使う

「何を作るか」より「なぜ作るか」が先でよい。

なぜ「要件定義書必須」と書く会社があるのか

理由は2つある。

1. 営業効率の問題 — 曖昧な相談に工数を使いたくない
2. 見積もり精度の問題 — 要件がないと見積もりが出せない

どちらも開発会社側の都合だ。発注者が「何を作るかまだ整理中」なのは、むしろ普通の状態だ。固定価格の厳密見積もりには詳細が要るが、相談・要件整理の入口まで詳細を求めるのは別問題である。

現場で見た、早すぎる「見積もり依頼」

匿名化した一例だ。新規事業の責任者が、構想段階のまま「概算見積もり3社」を依頼した。各社は前提を大きく置いて数字を返し、最安を採択した。

着手後、利用者・課金・既存CRM連携が次々に変わり、見積もりの前提が崩壊した。追加と作り直しで半年遅れ、結局「要件定義からやり直したい」と別相談が来た。

最初から「見積もり」ではなく「課題の構造化とMVP切り出し」を依頼していれば、安い数字のコンペを避けられた。相談の種類を間違えると、要件書の有無より先に失敗する。

要件定義書なしで相談できる条件

以下が分かっていれば、十分に相談のスタートラインに立てる。

• 事業課題: 何が困っているか
• 理想の状態: 解決したらどうなるか
• 制約: 予算感、期限、既存システム、法規制
• 利用者: 誰が使うか、何人規模か

画面設計やAPI仕様がなくても問題ない。

逆に、これだけは用意しておく

情報	例
背景	現場の業務フロー、今の困りごと
数字	ユーザー数、処理件数、売上規模
既存資産	使っているシステム、データの所在
社内体制	誰が判断者か、IT担当はいるか

PowerPoint 1枚でも、箇条書きのメモでもいい。完璧な要件定義書より、生の課題感の方が有益な相談になる。

「要件定義から一緒にやる」開発会社を選ぶ

優良な受託開発会社は、要件定義書を持参する前提ではなく、要件定義自体を一緒に進める。

• ヒアリングで課題を構造化する
• MVP（最小機能）を切り出す
• フェーズ分けして段階的に投資する

「要件が固まっていないから相談できない」ではなく、「要件が固まっていないからこそ相談してください」——この姿勢の会社を選ぶ。

判断軸：今すぐ相談する／もう少し社内で詰める

状況	推奨
課題・理想・制約のメモがある	今すぐ相談してよい
「とりあえず見積もりだけ」が目的	先に課題整理の依頼に切り替える
判断者が不在で、ヒアリングが空振りする	社内の意思決定者を先に決める
詳細仕様はあるが事業目的が曖昧	仕様より目的の言語化を優先

次に確認すること

1. 困りごとを4〜6行で書けたか
2. 理想状態は「リリース後に何が変わるか」まで落ちたか
3. 期限・予算感・既存システムの制約は出せたか
4. 相談の目的は見積もりか、整理か、明確か
5. 社内の判断者は初回面談に出られるか
6. 相手が要件定義から伴走する姿勢か

よくある質問

Q. 要件がないと費用感も教えてもらえませんか？

レンジの話はできることが多い。ただし固定の正式見積もりとは別物だと割り切る。レンジのために必要なのは、利用者規模・期限・既存連携の有無程度だ。

Q. 社内にIT担当がいなくても相談できますか？

できる。むしろ翻訳役がいないときほど、課題と制約を先に共有した方がよい。担当者不在を理由に相談を遅らせる必要はない。

まとめ

要件定義書は相談の結果であって、前提条件ではない。

整理途中の状態こそ、技術パートナーに相談するタイミングだ。見積もりコンペの前に、課題の構造化から入る相手を選ぶ。

---

要件が固まっていない段階からの相談・要件整理は、お問い合わせフォーム からどうぞ。