開発・新規事業
要件定義だけ外注できる？費用の考え方・成果物・依頼前の準備
システム開発の要件定義だけを外注できるのか。できる場合の条件、費用が変わる要因、受け取れる成果物、失敗しやすい点、依頼先の確かめ方を、要件整理の相談を受けている立場から詳しく整理します。
執筆：ストット玲奈（Nico合同会社 代表）
公開日： ／ 最終更新日：
先に結論
要件定義だけを外注することは、できます。 Nicoでも、要件定義だけのご相談を受けています。開発まで一緒に頼まなければいけない、ということはありません。
ただし、あとで困らないために、依頼する前に決めておきたいことが3つあります。
- 要件定義の結果を、何に使うか（他社への見積依頼／社内での開発／社内の提案や承認）
- 誰が最終的に決めるか（意見が割れたとき、決める人がいないと止まります）
- どこまでを要件定義に含めるか（成果物の範囲）
この記事では、この3つを含めて、次のことを順に整理します。
- 要件定義とは何か、何を決める工程か
- 要件定義だけを切り分けるのが向いている場合と、向いていない場合
- 費用が何で変わるか
- 受け取れる成果物と、その使い道
- 失敗しやすいパターンと、避け方
- 依頼先に確かめたい質問
- 依頼前の準備と、要件定義のあとの進め方
要件定義とは、何を決める工程か
要件定義は、システムを作る前に、「何のために、誰が使い、どこまで作るか」を決める工程です。機能を並べることではありません。
- 成果物の使い道
- 決める人
- 整理する範囲
- 次の進め方
本文の考え方を整理した説明図です。
たとえば、「顧客の管理をシステムにしたい」という依頼があったとします。この一文だけでは、次のことが分かりません。
今は、誰が、どこで、どう管理しているのか
何が困っているのか（探すのに時間がかかる／二重に入力している／担当者しか分からない）
新しい仕組みを使うのは誰か（営業だけか、事務も含むか、外部の人も見るか）
最初に作るのは、どこまでか（全部か、いちばん困っている部分だけか）
今ある資料やデータは、どうするか
要件定義は、これらを整理して、判断できる状態をつくる工程です。機能の一覧は、整理した結果のごく一部にすぎません。
開発（設計・実装・テスト）は、決まった要件をもとに進めます。要件が曖昧なまま開発に入ると、途中で「思っていたものと違う」が起こりやすくなります。要件定義だけを先に切り分けるという考え方は、その「違い」を、作り始める前に減らすためのものです。
こんなとき、要件定義だけを切り分けるのが向いています
次のような場合は、要件定義だけを先に依頼するメリットが大きいと考えています。
開発会社に見積もりを頼みたいが、依頼書に何を書けばよいか分からない。 要件定義の資料が、そのまま依頼書の土台になります。
要望が多く、最初に作る範囲を決められない。 「今作る／後に回す／作らない」に分ける作業を、外部の目で進められます。
現場・経営・開発担当で、作るものの認識がそろっていない。 同じ資料を見ながら話せるようになります。
社内に開発担当はいるが、業務の整理と優先順位づけに手が回らない。 整理だけを任せて、開発は社内で進める形です。
ノーコードや既存のサービスで足りるのか、作る必要があるのかが分からない。 手段を比べる前に、必要な機能と優先順位を整理します。
社内の承認や予算の説明に、根拠となる資料が必要。 「なぜこの範囲か」を説明できる資料になります。
反対に、次のような場合は、要件定義から開発まで同じ会社に任せたほうが進めやすいことがあります。
要件がすでにかなり固まっていて、整理より実装が主な作業になる
小さな機能追加や、既存の仕組みの改修が中心
要件定義の担当と開発の担当が別だと、引き継ぎの手間が大きくなる案件
どちらが合うか分からない場合は、「切り分けるかどうか」を決めるところから相談できます。
切り分けるメリットと注意点
| 区分 | 内容 |
|---|---|
| メリット | 作る範囲が決まった状態で、複数社の見積もりを同じ条件で比べられる。開発の依頼先を決める前に、範囲・進め方・費用の考え方を検討できる。社内の合意をとりやすい |
| 注意点 | 要件定義の担当と開発の担当が別になるため、引き継ぎの手間が出る。成果物が開発側にとって読みやすい形になっている必要がある。要件定義だけで、開発の見積もりまでは分からない場合がある |
引き継ぎの手間は、依頼のときに「開発は他社に頼む前提か、社内で行うか」を伝え、その相手が使える形で成果物をまとめることで、小さくできます。
要件定義だけを依頼すると、どう進むか（Nicoの場合の流れ）
会社や案件によって違いますが、Nicoでは、おおむね次の順で進めます。
1. ご相談（状況と、結果の使い道を伺う）
まず、困っていること、関係者、希望の時期、そして成果物を何に使うかを伺います。この段階で、資料や仕様が決まっていなくても構いません。
2. 最近の案件を、ひとつたどる
要件整理の相談では、まず、こう聞きます。
「最近の案件をひとつ、最初から最後まで教えてください。」
誰が受け取り、何を確認し、どこで止まったのか。機能の希望を聞くより先に、実際の流れをたどります。たどってみると、「確認する人が決まっていなかった」「この資料は、毎回、別の人が作り直していた」といった、要望の形になる前の事情が見えてきます。
3. 課題と優先順位を整理する
見えてきた事情を、課題として整理します。そのうえで、「今作るもの／後に回すもの／作らないもの」に分け、作らないものにも理由を残します。理由を残しておくと、あとで状況が変わったときに、見直す根拠になります。
4. 決まっていないことを、確認項目として残す
分からないことは、無理に埋めません。分からないまま、確認する項目として残し、決める人と期限をつけます。推測で埋めた前提は、あとから見積もりのずれや、認識の食い違いになりやすいからです。
5. 成果物をまとめて、お渡しする
合意した範囲で、成果物をまとめます。見積依頼書の形で整えるか、社内開発向けの形で整えるかなど、使い道に合わせます。
6. 次の進め方を、一緒に考える
同じ会社で開発に進むか、他社に見積もりを依頼するか、社内に引き継ぐかを、成果物を見ながら決めます。開発を依頼することは、前提ではありません。
費用は何で変わるか
要件定義だけの費用は、一般に、次の条件で変わります。条件ごとに、どう影響するかの例を挙げます。
| 条件 | どう影響するか |
|---|---|
| 対象の業務の範囲 | 扱う業務が1つか、複数の部署にまたがるかで、聞き取りと整理の量が変わる |
| 関係者の人数 | ヒアリングする人と、合意に必要な人が多いほど、会議と調整の回数が増える |
| 既存の資料・データの状態 | Excel、帳票、既存システムの資料が整理されていれば早い。散らばっていたり、人によって運用が違ったりすると、確認に時間がかかる |
| 成果物の範囲 | 業務の流れだけか、機能の一覧・画面のイメージ・データ項目・権限まで作るかで、作業量が変わる |
| 進め方とスケジュール | 会議・確認の回数、希望の納期。短い納期の場合は、範囲と進め方を調整する |
要件定義の費用が、開発費全体の何割になるかは、資料によって説明が異なります。割合だけで決めず、上の条件ごとに、見積もりの内訳を確認してください。
Nicoでは、要件定義（整理）だけのご依頼にも対応しています。料金は個別にお見積もりします。最初のご相談でボリュームとスケジュールを伺い、対応範囲と内訳をご提案します。目安として、最短で2〜3週間程度から進められる場合があります（内容により変わります）。
見積もりを受け取ったら、確認したいこと
何回の会議・聞き取りが含まれているか
どの成果物が含まれているか（含まれないものは何か）
修正や追加の確認は、何回まで含まれるか
開発を別の会社に頼む場合に、成果物を使うことに制限はないか
発注側が用意するもの、確認する人の負担はどれくらいか
要件定義で受け取れるものと、その使い道
成果物は、合意した範囲で決めます。主な例と、使い道は次のとおりです。
| 成果物の例 | 使い道 |
|---|---|
| 現状の業務の流れ（誰が、何を受け取り、何をして、誰に渡すか） | 関係者の認識をそろえる。課題の場所を見つける |
| 解決したい課題と、目指す状態、優先順位 | 何から作るかを決める。承認の説明に使う |
| 機能の一覧（今作るもの／後に回すもの／作らないもの） | 見積もりの範囲をそろえる。範囲の変更を判断する |
| 扱うデータの項目と、権限（誰が見られて、誰が変更できるか） | 設計の土台。個人情報や権限の確認 |
| 既存のツールやシステムとの連携の整理 | 連携の可否と、追加の費用や作業の確認 |
| 運用の条件（誰が管理し、誰が更新するか） | 公開後に使い続けられるかの確認 |
| まだ決まっていないこと（決める人と期限つき） | 開発の途中で止まらないための管理 |
| 見積依頼にそのまま使える依頼書（希望する場合） | 複数社に同じ条件で見積もりを依頼する |
実際の成果物のイメージは、要件整理シート（サンプル・架空）をご覧ください。架空の会社を想定した見本で、実際の案件ではありません。
失敗しやすいパターンと、避け方
要件定義の相談で、起こりやすいと感じるパターンを挙げます。
1. 機能の一覧だけが、成果物になっている
「管理画面」「検索」「通知」のような機能名が並んでいるだけでは、見積もりが会社ごとにずれます。誰が、どんな場面で使うかまで書かれているかを確認してください。
2. 決める人が決まっていない
意見が割れたとき、決める人がいないと、議論が続くだけになります。最初に、最終的に決める人を決めておきます。
3. 全部を最初から作ろうとしている
要望をすべて入れると、範囲が広がり、判断も難しくなります。今作るもの／後に回すもの／作らないものに分けて、最初に作る範囲を小さくすることを検討してください。
4. 分からないことを、推測で埋めてしまう
「たぶんこうだろう」で進めた前提は、あとで、見積もりのずれや認識の食い違いになります。分からないことは、確認項目として残します。
5. 成果物が、開発側で使えない形になっている
読みやすさや形式が合わないと、引き継ぎで手間が増えます。開発を依頼する相手（他社／社内）が分かっていれば、最初に伝えておくことで、使える形にそろえられます。
6. 決めた理由が残っていない
結論だけが残っていると、状況が変わったとき、見直せません。理由と、まだ確かめられていない点も、一緒に残してください。
依頼先に確かめたい質問
要件定義だけを依頼する場合、次の質問に、具体的に答えてもらえるかが、判断の手がかりになります。
最初のご相談で、何を聞かれますか。（機能の希望だけでなく、実際の業務の流れを聞いてくれるか）
成果物は、何がどの形式で受け取れますか。（見本があるか）
成果物を、他社への見積依頼や、社内開発に使えますか。
分からないこと、決まっていないことは、どう扱いますか。
要件定義のあとに、開発を依頼することは必須ですか。
費用は、何の条件で変わりますか。（内訳を説明してもらえるか）
進め方（会議の回数、確認の方法）と、こちらの負担は、どれくらいですか。
答えが具体的で、「決まっていないことは決まっていないと言える」会社は、あとから範囲がずれたときにも、相談しやすいと考えています。
依頼前に準備したいこと
すべてをそろえる必要はありません。次の4つがあると、話が早く進みます。
困っている作業の例を1件: 実際の画面、Excel、帳票、メールなど。「この作業が、こう困る」と説明できる1件があれば十分です。
関係者のリスト: 使う人、管理する人、決める人。
使っているツール: Excel、クラウドサービス、既存のシステム。
希望の時期と、予算の目安: 未定の場合は「未定」と伝えて問題ありません。
決まっていない項目も、そのまま共有してください。決まっていない部分を整理するのが、要件定義の役割です。
依頼前のチェックリスト
依頼の目的（何を解決したいか）を、一文で言える
困っている作業の実例が、1件ある
関係者と、最終的に決める人が決まっている
成果物を何に使うか（他社への見積依頼／社内開発／社内の提案）が決まっている
希望の時期や予算が未定でも、その旨を伝えられる
資料や仕様がなくても相談できることを、知っている
要件定義のあと、どう進めるか
要件定義の結果をもとに、次のいずれかを選べます。選ぶときの目安も添えます。
| 進め方 | 向いているとき |
|---|---|
| 同じ会社に、開発も依頼する | 整理した内容のまま、進め方に納得している。引き継ぎの手間を減らしたい |
| 要件定義の資料をもとに、複数社に見積もりを依頼する | 範囲をそろえて、比べてから決めたい。見積もりの比べ方も参考に |
| 社内の開発チームに引き継ぐ | 実装は社内でできるが、整理と優先順位づけが必要だった |
| ノーコードや既存のクラウドサービスで構築する | 一覧、状態管理、通知、申請の流れが中心。手段を比べたうえで、構築まで対応できる |
| 範囲を小さくして、試作から始める | 最初から全部を作るのは不安。最初の機能を絞る考え方も参考に |
要件定義の段階では、開発を依頼するかどうかは決まっていなくて構いません。
架空の例：要件定義だけを依頼した場合の流れ
実際の案件ではなく、架空の例です。イメージをつかむためのものとして、読んでください。
ある小規模な会社（架空）では、見積書の作成と案件の進み具合の管理を、複数のExcelで行っています。担当者は「システムにしたい」と考えていますが、何を作ればよいか決まっておらず、開発会社に見積もりを頼めずにいます。
ご相談: 「他社にも見積もりを頼みたい」ことが分かりました。成果物の使い道は、見積依頼書です。
最近の案件をひとつ、たどる: 見積書を作る担当者、内容を確認する人、承認する人が、人によって違うことが分かりました。確認する人が決まっていない案件がありました。
整理: 「見積書の作成」と「進捗の管理」の2つに分け、困っているのは、確認の抜けと、最新版が分からないことでした。
範囲の決定: 最初に作るのは「見積書の確認の流れ」のみ。進捗の管理は後に回し、その理由を残しました。
決まっていないこと: 承認者が部署ごとに違う点は、確認項目として残し、決める人と期限をつけました。
成果物: 業務の流れ、機能の一覧（今作る／後に回す）、データ項目、権限、確認項目、見積依頼書。
次の進め方: 依頼書を使って、2社に見積もりを依頼することにしました。
この例のように、要件定義の結果を、複数社に同じ条件で見積もりを依頼するための資料として使うことができます。
よくある質問
Q. 要件定義だけでも相談できますか？ A. はい。開発を依頼するかどうかが決まっていない段階でも、相談できます。
Q. 要件定義の資料を、他社への見積依頼に使えますか？ A. はい。見積依頼にそのまま使える形でまとめることができます。使う目的を最初に教えてください。
Q. 仕様書や資料がなくても依頼できますか？ A. はい。実際の画面やExcel、メールが1件あれば、そこから整理できます。
Q. 費用はいくらですか？ A. 対象の業務のボリューム、関係者の人数、既存資料の状態、成果物の範囲、希望のスケジュールで変わるため、個別にお見積もりします。最初のご相談で内容を伺い、内訳をご提案します。
Q. どれくらいの期間がかかりますか？ A. 内容により変わります。目安として、最短で2〜3週間程度から進められる場合があります。
Q. ノーコードで作ることもできますか？ A. はい。業務の内容によっては、ノーコードや既存のサービスの設定で足りる場合があります。手段を比べたうえで、構築まで対応します。
Q. 要件定義だけ依頼して、開発は別の会社に頼めますか？ A. はい。他社への依頼を前提としたご相談にも対応しています。その場合は、相手が使える形で成果物をまとめます。
Q. 関係者が多く、意見がまとまりません。 A. 案を増やす前に、前提の違い（誰が読むのか、どの場面で使うのか、その案で誰の何がよくなるのか）を確認します。それでも情報が足りないときは、聞き取りや小さな試作で確かめる進め方もあります。
まとめ
要件定義だけを外注することは、できる。見積もりを比べる、社内で開発するための準備として有効。
依頼前に決めたいのは、結果を何に使うか／誰が決めるか／成果物の範囲の3つ。
費用は、業務の範囲、関係者の人数、既存資料の状態、成果物の範囲、スケジュールで変わる。内訳を確認する。
失敗しやすいのは、機能の一覧だけが成果物になる、決める人がいない、分からないことを推測で埋める、の3つ。
依頼前は、困っている作業の例が1件あれば十分。決まっていないことは、そのまま伝えてよい。
Nicoでは、要件定義だけのご相談、他社や社内チームへの引き継ぎを前提としたご相談にも対応しています。資料や仕様がなくても、大丈夫です。まずは状況をお聞かせください。