要件が固まらないまま発注していい？進め方と最低限決めること

「システムを作りたいけれど、要件がはっきり固まっていない」——この状態で発注していいのか、迷う方は多いはずです。結論から言えば、要件が固まっていない段階で相談・発注しても問題ありません。むしろ、多くのシステム開発は要件が曖昧なところからスタートします。この記事では、なぜ要件が固まらないのか、完璧な仕様書がなくても始められる理由、そして「まず作って試す」進め方と、最低限決めておくべきことを解説します。

システムを触ったことがない段階で「完璧な仕様」を想像するのは、そもそも無理があります。頭の中だけで作った要件は、実物を見た瞬間に「思っていたのと違う」となるのが普通だからです。大切なのは、全部を決めてから発注しようとしないこと。決めるべきは「目的」「優先順位」「予算の上限」の3つだけで十分で、残りは動くものを見ながら開発会社と一緒に固めていく——これが今の主流の進め方です。要件を丁寧に整理する工程そのものについては要件定義の進め方でも解説しています。避けたいのは、「要件が完璧に固まってからでないと動けない」と思い込んで、いつまでも相談に進めないことです。要件を固める作業自体、開発会社と話しながらの方がはるかに早く進みます。一人で抱え込む必要はありません。

なぜ要件が固まらないのか

そもそも、なぜ要件は固まらないのでしょうか。理由が分かると、対処の仕方も見えてきます。多くの場合、原因は次の3つのどれか、あるいは複数が重なっています。

固まらない理由	起きていること	どう対処するか
現場のイメージが湧かない	システムを使ったことがなく、何ができるか分からない	動くもの（試作）を見てから決める
やりたいことが多すぎる	あれもこれもと機能が増え、優先順位がつかない	「これがないと業務が回らない」機能だけ選ぶ
社内で決められない	誰が決めるか・何を優先するかが定まっていない	目的と決裁者を先に一人に絞る

現場のイメージが湧かないのは、経験がない以上ごく自然なことです。カタログだけ見て家を建てられないのと同じで、実物や試作を見て初めて「こうしたい」が出てきます。だからこそ、頭の中で完璧を目指すより、小さく作って見てみる方が早いのです。

やりたいことが多すぎるケースも非常に多く見られます。「せっかく作るなら」と機能を積み増した結果、費用も納期も膨らみ、しかも実際に使われるのは基本機能だけ——という話は珍しくありません。機能の一覧に「これがないと、いま困っている業務は回るか？」という問いを一つずつ当てると、本当に必要なものが見えてきます。

社内で決められないのは、目的や決裁者が定まっていないサインです。誰のための、何のためのシステムかが曖昧だと、関係者の意見がぶつかって前に進みません。まず目的を一文にし、最終的に判断する人を決めるところから始めます。

完璧な仕様書がなくても始められる理由

「発注前に詳細な仕様書を用意しなければ」という思い込みは、多くの場合、不要です。完璧な要件書を作ろうとして時間だけが過ぎるより、必要な最小限に絞って動くものを見ながら決めていく方が、はるかに失敗しにくく、費用も抑えられます。

理由はシンプルで、システム開発は「作りながら要件が見えてくる」性質を持つからです。紙の上で100%決めきったつもりでも、実際に画面を触ると必ず「ここはこうしたい」が出てきます。それなら、最初から6〜7割の要件で走り出し、残りは実物を見て詰める方が理にかなっています。頭の中だけで作った要件は、たいてい実物を前にするとズレが出るものです。だからこそ、机上での作り込みに時間をかけすぎないことが、かえって近道になります。

発注側に求められるのは、詳細な仕様書ではなく「何に困っていて、どうなったら嬉しいか」を語れることだけです。専門的な設計や、機能への落とし込みは開発会社の仕事です。困りごとと理想を正直に話せれば、要件書は開発会社が質問しながら一緒に組み立てていきます。むしろ、要件がふわっとした段階での相談を歓迎する会社を選ぶことが、そのまま失敗しない会社選びにつながります。逆に「要件が固まってからでないと受けられない」という会社は、伴走してくれるタイプではないと判断する材料にもなります。

「まず作って試す（MVP）」で育てる進め方

要件が固まらないときにいちばん有効なのが、まず小さく作って試す進め方です。最初に必要最小限の機能だけを持つ試作（MVP＝まず必要な最小限のもの）を短期間で作り、実際に触りながら「本当に必要な機能」を見極めていきます。

進め方のイメージは次のとおりです。全部を一度に作るのではなく、小さく作って確かめ、育てるサイクルを回します。

1. 目的と、まず絶対に必要な機能を2〜3個だけ選ぶ
2. その範囲でMVP（試作）を短期間で作ってもらう
3. 実際に現場で触ってみて、良い・悪いを確かめる
4. 使ってわかったことを次の要件に反映し、機能を足していく
5. 2〜4を繰り返し、実際に使えるものへ育てる

このやり方は「アジャイル的に育てる」とも呼ばれます。最初に全機能を想像で決めるのではなく、動くものを見て要件を確定させていくため、机上で全部決めるより精度が高くなります。MVPを触ると「これは要らなかった」「本当はこれが欲しかった」がはっきりし、次に作るものの要件は驚くほど決めやすくなります。

目安として、最初のMVPは「1〜3画面・主要機能を2〜3個」に収めると、短期間で形にでき、社内でも評価しやすくなります。要件が固まらないことは、この進め方ではむしろ前提です。固まらないからこそ、小さく作って確かめる価値があります。

例：電話とFAXで注文を受けていた卸売の会社が、「在庫連動も売上集計も帳票出力も欲しい」と要件が広がって決めきれずにいたとします。ここで全部を一度に作ろうとせず、まず「注文の写真取込→自動データ化→一覧表示」だけのMVPを2〜3週間で作りました。実際に触ってみると、当初は必須だと思っていた売上集計は既存のExcelで十分で、逆に「出荷指示の通知」が本当に欲しかった機能だと分かりました。最初の要件が固まっていなくても、動くものを見たことで、次に足すべき機能の要件がはっきりしたわけです。全部を想像で決めていたら、使われない機能に費用をかけていたかもしれません。

固めるべき最低限（目的・優先度・予算の上限）

「全部決めなくていい」とはいえ、何も決めずに始めると迷走します。要件が固まらなくても、次の3つだけは先に決めておきます。この3つがあれば、開発会社は動き出せます。

決めること	内容	例
目的	何を解決したいか（機能ではなく困りごとで）	「電話とFAXの注文入力に毎日2時間取られているのをなくしたい」
優先順位	まず絶対に必要な機能はどれか	「注文の取込と一覧だけ先に。在庫連動は後回し」
予算の上限	いくらまでなら出せるか	「初期は100万円まで。それを超えるなら相談」

目的は、機能名ではなく「困りごとの解消」で書くのがコツです。「注文管理アプリがほしい」ではなく「注文入力の手間をなくしたい」。目的が具体的だと、機能の優先順位も自然と決まります。

優先順位は、「これがないと業務が回らない機能」と「あったら便利な機能」を分ける作業です。迷ったら後回しにするくらいでちょうど良く、最初のMVPには絶対に必要なものだけを入れます。

予算の上限は、要件が動く前提だからこそ重要です。上限が決まっていれば、開発会社は「その範囲で何ができるか」を提案できます。費用の考え方は100万円でどこまでできるかも参考になります。逆に、この3つ以外の細部は決まっていなくて構いません。

相談前に手元にあると話が早いもの

完璧な仕様書は不要ですが、次のものがあると初回相談から話が一気に具体化します。どれも新たに作り込む必要はなく、いま手元にあるもので構いません。

• 目的を一文で言えるようにしておく（何を解決したいか）
• 今使っている紙・Excel・ツールの実物やスクリーンショット
• 現状の業務の流れ（手書きのメモや箇条書き程度でOK）
• 「これができたら嬉しい」の具体例を3つほど
• 使う人（誰が・何人・どの端末で）のざっくりしたイメージ
• いくらまでなら出せるか、いつまでに使い始めたいかの希望

すべて揃っていなくて大丈夫です。上の2〜3個でも、そこから開発会社が質問しながら埋めていけます。要件が固まっていないことと、手ぶらで相談することは違うので、いま持っている材料だけは集めておくと、その後がスムーズです。

要件が動く前提の契約（準委任という選択肢）

要件が固まらない＝作りながら変わることが前提なら、契約形態も知っておくと安心です。システム開発の契約は、大きく「請負」と「準委任」に分かれます。

	請負契約	準委任契約
責任	決めた仕様のものを完成させる	業務を適切に進める（完成は保証しない）
向いている場面	要件が固まっている	要件が変わりやすい・作りながら決めたい
支払い	検収・納品後が基本	稼働（人月）ベースの月次精算が多い

要件が固まっていない段階では、完成責任を負う請負より、伴走しながら進める準委任が向くとされます。要件が変わっても、その都度大きく再契約し直さずに進められるからです。契約形態の詳しい違いは契約（請負と準委任の違い）で解説しています。

ただし、準委任は稼働に応じた支払いになるため、「結局いくらになるか読みにくい」という不安もあります。反対に、要件が固まっていないのに請負で無理に総額を固定すると、あとから変更のたびに追加費用と再見積もりが発生しがちです。そこで、総額が先に固定される一律料金の仕組みなら、請負の「金額が読める安心感」と、準委任の「作りながら変えられる柔軟さ」の両方を得やすくなります。要件が動いても追加費用が出ないため、金額を気にせず優先順位を組み替えられます。契約形態そのものより、「範囲・追加費用・成果物の権利」が着手前に明確になっているかが、揉めないための肝心な点です。ソースコードの権利が発注側に渡るかどうかも、あとで別の会社に引き継ぐ際に効いてくるので、あわせて確認しておくと安心です。

「要件が固まらない」と「丸投げ」の違い

ここで注意したいのが、「要件が固まらない」ことと「丸投げ」は違うということです。この2つを混同すると失敗します。

• 丸投げ：目的も判断も相手任せ。「いい感じに作っておいて」で、確認もしない。完成後に「思っていたものと違う」となりやすい。
• 要件が固まらない：目的は言えるが、実現方法や細部がまだ決まっていない状態。優先順位の判断は自分でする。

丸投げが危険なのは、目的や判断まで手放してしまうからです。作る側は「何のためのシステムか」が分からないまま進めることになり、出来上がったものが的外れになりがちです。完成してから「これではない」と気づいても、作り直しには余計な時間と費用がかかります（→せっかく作ったのに使われないシステムの原因）。

一方、要件が固まらないのは問題ありません。目的と優先順位を自分の言葉で語り、途中の確認にきちんと関わっていれば、細部が未定でも良いものが作れます。「目的と判断は握る、細部は一緒に決める」——これが丸投げとの決定的な違いです。要件が動いても、この姿勢さえあれば迷走しません。

要件が固まらない時にやってはいけないこと

最後に、要件が固まらない状況でやりがちな失敗を挙げます。あらかじめ知っておけば避けられます。

やってはいけないこと	何が起きるか	代わりにどうするか
完璧な仕様書ができるまで動かない	いつまでも着手できず、機会を逃す	目的・優先度・予算だけ決めて相談する
目的まで相手任せにする（丸投げ）	的外れなものが完成する	目的と判断は自分で握る
思いつく機能を全部盛る	費用も納期も膨らみ、使われない機能が残る	MVPに絞り、追加は次フェーズへ
現場に確認せず決裁者だけで決める	完成後に「これでは使えない」となる	実際に使う人を相談に巻き込む
変更のたびに追加費用が出る契約で無理に固める	「変えたいのに言えない」で使いにくいものが残る	要件が動く前提の進め方・料金を選ぶ

特に多いのが、完璧を目指して着手が遅れるパターンです。要件が固まらないことを理由に相談を先延ばしにしても、状況は変わりません。むしろ開発会社と話す中で要件は固まっていきます。

もう一つ多いのが、変更しづらい契約で無理に要件を固めようとすることです。変更のたびに追加費用と再見積もりが発生する形だと、発注側は「変えたいけれど言いにくい」と感じ、結果として使いにくいものが残ってしまいます。要件が動くことを前提に、柔軟に進められる相手・仕組みを選ぶことが大切です。

一律料金だと要件が固まらなくても始めやすい

見積もり型の開発では、要件が増えるたびに金額が変わるため、「要件を盛るか削るか」で発注側も気を使います。要件が固まっていないと、見積もり自体が出しにくいこともあります。D-oneAppは料金が一律100万円（大規模なプロプランは一律200万円）で追加費用がなく、着手前に総額が確定するので、金額を気にせず「本当に必要なもの」を一緒に考えられます。

要件がふわっとした段階からの相談を歓迎しており、要件整理そのものを一緒に進めます。一律の範囲で優先順位を決め、最短2〜3週間でMVPをお出しして、動くものを見ながら要件を仕上げていきます。要件が途中で変わっても追加費用は発生しません。作ったシステムのソースコードの権利もお客様にお渡しするため、あとから別の会社に引き継ぐことも可能です。

まとめ

要件が固まらないまま発注しても問題ありません。多くの開発は曖昧な段階から始まり、動くものを見ながら要件を固めていくのが今の主流です。決めるべきは「目的」「優先順位」「予算の上限」の3つだけ。あとはMVPを小さく作って試し、育てていけば十分です。

大切なのは、要件が固まらないことと「丸投げ」を区別すること。目的と判断は自分で握り、細部は開発会社と一緒に決めていきましょう。要件が動く前提なら、柔軟に進められる相手・仕組みを選ぶことが失敗を防ぎます。

D-oneAppは、要件がふわっとした段階からの相談を歓迎し、要件整理そのものを一緒に進めます。料金は一律で追加費用がなく、着手前に総額が確定するので、金額を気にせず「本当に必要なもの」を選べます。要件が固まっていなくて大丈夫です。無料相談で、あなたの「やりたいこと」を一緒に言葉にするところから始めましょう。