システム開発を検討しているものの、

「開発会社へ相談する前に何を準備すればよいのか分からない」

「必要な機能まで決めてから相談するべきなのか」

「まだ要件が固まっていない状態で問い合わせてもよいのか」

と悩むことがあります。

結論から言うと、発注前に完璧な要件定義書を作る必要はありません。

ただし、最低限、

• なぜシステムを作りたいのか
• 現在どのように業務をしているのか
• 何に困っているのか
• 誰が利用するのか
• 予算はどの程度か
• いつ頃使い始めたいのか

を整理しておくと、開発会社との打ち合わせや見積が進めやすくなります。

特に重要なのは、

欲しい機能を完璧に決めること

ではなく、

現在の業務と
解決したい課題を説明できること

です。

IPAも、要件定義はITベンダーだけに任せるのではなく、システムを利用するユーザー企業・業務部門が主体的に関与することの重要性を示しています。

この記事では、中小企業が業務システム・Webシステムを外部へ発注するときに、相談前に準備しておきたい内容をチェックリスト形式で解説します。

システム開発は要件が完全に決まっていなくても相談できる

最初に知っておきたいのは、

要件が全部決まるまで
開発会社へ相談できない

わけではないということです。

例えば、

現在Excelで顧客管理している。

営業担当が増えて、
誰がどの顧客を担当しているか
分からなくなってきた。

Web上で顧客・案件を
一元管理したい。

という程度でも、相談を開始できます。

ここから開発会社と、

現状業務を確認

↓

課題を整理

↓

新しい業務フローを検討

↓

必要な機能を整理

↓

システム構成を検討

と進めることができます。

一方で、

とにかく便利なシステムを
作ってください

だけでは、開発会社も提案・見積が難しくなります。

そのため、技術仕様ではなく、まず業務側の情報を準備することが重要です。

システム開発を発注する前に準備したい12項目

相談前に整理したい主な項目は次のとおりです。

項目	整理すること
1. 開発背景	なぜ開発を検討したのか
2. 開発目的	何を改善したいのか
3. 現状業務	現在どう仕事をしているか
4. 業務課題	何に困っているか
5. 利用者	誰が何人使うか
6. 必要機能	現時点で必要と思うもの
7. 既存資料	Excel・帳票・システム
8. データ	何を移行するか
9. 外部連携	他システムとの連携
10. 予算	予算レンジ
11. 納期	希望利用開始時期
12. 社内体制	誰が判断・確認するか

順番に見ていきます。

1．なぜシステム開発を検討しているのか

最初に整理するのは、

なぜ今、
システム開発が必要なのか

です。

例えば、

社員が増えて
Excel管理が限界になった

店舗が増えて
情報共有が難しくなった

二重入力が多い

既存システムが古い

担当者への属人化が進んでいる

などです。

記入例

現在、営業担当者ごとに
Excelで顧客情報を管理している。

営業担当が5名から15名へ増え、
顧客情報・案件状況を
営業部全体で把握することが
難しくなっている。

Excel管理からWebシステムへ
移行することを検討している。

この情報があるだけでも、開発会社は背景を理解しやすくなります。

2．システム開発の目的を整理する

次に、

システムを導入して
何を実現したいのか

を整理します。

例えば、

顧客情報を一元管理したい

だけでもよいですが、可能ならさらに具体化します。

例

営業担当者全員が
最新の顧客情報を確認できるようにする。

担当者が変更されても、
過去の対応履歴を確認できるようにする。

毎週2時間かかっている
案件集計作業をなくす。

IPAも、システム構築では単なる操作性・効率化だけでなく、経営・ビジネス上の目的を踏まえて要件を明確化する重要性を示しています。

「システムを作る」が目的にならないようにする

例えば、

在庫管理システムを作る

は手段です。

本来の目的は、

全拠点の在庫を一元化し、
毎週発生している集計作業をなくす

かもしれません。

この違いは重要です。

3．現在の業務フローを整理する

開発会社が特に知りたいのが、

現在どうやって
仕事をしているのか

です。

例えば、

顧客から問い合わせ

↓

営業担当がExcelへ登録

↓

案件化したら別Excelへ転記

↓

毎週管理者へメール

↓

管理者が各担当者のExcelを統合

↓

営業会議資料を作成

という流れです。

完璧な業務フロー図を作る必要はありません。

紙やメモでも、

誰が

何を受け取り

何を入力して

誰へ渡すか

が分かれば十分です。

4．現在困っていることを整理する

現状業務から、

何を改善したいのか

を整理します。

例えば、

・Excelを毎週集計するのに3時間かかる

・同じ情報を2回入力している

・入力ミスが発生している

・誰が最新ファイルを持っているか分からない

・担当者が休むと業務が止まる

・他店舗の情報を確認できない

などです。

現場担当者にも聞く

管理職が認識している問題と、実際に操作する担当者の問題が異なる場合があります。

例えば管理者は、

案件状況が見えない

と困っていて、

現場担当者は、

同じ顧客情報を
3回入力するのが大変

と困っているかもしれません。

発注前に主要な利用者へ確認しておくと、後から大きな要件が追加されるリスクを減らせます。

5．誰がシステムを利用するか

利用者も整理します。

例えば、

営業担当：
15人

営業管理者：
3人

システム管理者：
2人

などです。

さらに、

社内だけか

顧客も使うのか

取引先もログインするのか

今後人数が増えるのか

も確認します。

権限も大まかに考える

例えば、

営業担当：
自分の案件を登録・編集

管理者：
全案件を閲覧

システム管理者：
ユーザー追加・削除

程度でも構いません。

詳細な権限設計は要件定義で詰められます。

6．必要だと思っている機能を整理する

相談前の段階では、機能を完全に決める必要はありません。

現時点で、

必要そう

と思っているものを一覧にします。

例えば顧客管理システムなら、

・ログイン

・顧客登録

・顧客検索

・案件管理

・対応履歴

・CSV出力

・管理画面

などです。

必須と希望を分ける

できれば、

必須

できれば欲しい

将来対応

に分けます。

例えば、

機能	優先度
顧客管理	必須
案件管理	必須
対応履歴	必須
CSV出力	高
ダッシュボード	中
AI分析	将来

これだけでも、予算に合わせた提案を受けやすくなります。

7．現在使っているExcel・帳票・システムを準備する

業務システムを発注するときは、文章で一から説明するより、

実際に使っているもの

を見てもらう方が早い場合があります。

例えば、

• Excel
• Googleスプレッドシート
• Access
• CSV
• PDF帳票
• 紙の申請書
• 操作マニュアル
• 既存システムの画面
• メール文面

などです。

Excelには多くの業務ルールが隠れている

例えばExcelを見ると、

赤色は対応中

黄色は確認待ち

特定列は管理者だけ入力

月末に別シートへコピー

など、担当者が説明し忘れていたルールが見つかることがあります。

そのため、既存資料は重要な参考情報になります。

8．既存データを確認する

新しいシステムを導入するとき、

今あるデータを
どうするのか

も確認します。

例えば、

顧客：
20,000件

案件：
50,000件

Excel：
30ファイル

過去データ：
5年分

などです。

発注前に確認したい内容

どこにデータがあるか

何件あるか

何年分必要か

重複があるか

不要なデータはあるか

を確認します。

データ移行は開発費へ影響するため、見積を取る段階で伝えておく方がよいでしょう。

9．他システムとの連携有無を確認する

例えば、

会計システム

販売管理システム

Google Workspace

Microsoft 365

Slack

Teams

決済サービス

メール配信サービス

などを利用している場合です。

例えば、

新システムで登録された売上を
会計システムへ連携したい

のであれば、開発規模が変わります。

API連携なのか、CSV連携なのか分からなくても、

このシステムと
データを連携したい

まで伝えれば、技術的な方法は開発会社と検討できます。

10．予算を決める

システム開発では、

予算がまだ分からないので
金額を伝えない

というケースがあります。

しかし、

発注者：
100万円程度

開発会社：
1,000万円規模

では話が大きくずれます。

厳密な金額でなくても、

100〜200万円

300〜500万円

1,000万円以内

など、予算レンジを整理しておくとよいでしょう。

予算が決まっていない場合

どうしても分からなければ、

最低限必要な構成

標準構成

将来機能まで含む構成

など複数案を依頼する方法があります。

11．希望納期を整理する

例えば、

12月まで

ではなく、

2027年1月から
新店舗で利用開始したい

など、理由も整理します。

納期には、

絶対に動かせない期限

できれば間に合わせたい期限

があります。

開発会社から、

主要機能を先にリリースし、
残りを第2フェーズにする

という提案を受けられる場合もあります。

12．発注者側の社内体制を決める

システム開発は、開発会社へ丸投げして完了するものではありません。

発注側でも、

業務内容を説明する人

仕様を確認する人

最終判断する人

受入テストする人

が必要です。

IPAの要件定義ガイドでも、システムの利用を通じてビジネスへ貢献するユーザー側が、要件定義へ主体的に関与する重要性が示されています。

例えば、

プロジェクト責任者：
営業部長

業務担当：
営業担当2名

システム担当：
情報システム担当1名

最終決裁：
代表取締役

とします。

意思決定者を決めておく

開発途中で、

営業部長：
Aがよい

経理部長：
Bがよい

社長：
Cがよい

となると進みません。

最終的に、

誰が決めるのか

を明確にしておくことも重要です。

【コピペ用】システム開発の発注前チェックリスト

開発会社へ相談する前に、次を確認してみてください。

【背景・目的】

□ なぜシステム開発を検討しているか説明できる

□ 現在の問題を整理した

□ システム導入後に実現したい状態を整理した

□ 可能なら数値目標を整理した


【現状業務】

□ 現在の業務フローを説明できる

□ 利用しているExcelを準備した

□ 既存帳票を準備した

□ 現在利用しているシステムを整理した

□ 現場担当者の課題を確認した


【利用者】

□ 誰が利用するか整理した

□ 利用人数を把握した

□ 管理者を決めた

□ 社外ユーザーの有無を確認した


【機能】

□ 必要だと思う機能を一覧化した

□ 絶対必要な機能を決めた

□ 将来追加でもよい機能を分けた

□ 今回対象外にするものを整理した


【データ】

□ 既存データの保存場所を確認した

□ おおよそのデータ件数を確認した

□ 移行したい期間を確認した

□ Excel・CSV等を準備した


【外部連携】

□ 他システムとの連携有無を確認した

□ 利用しているSaaSを整理した

□ API・CSV連携の希望を整理した


【予算・納期】

□ 予算レンジを決めた

□ 希望利用開始日を決めた

□ 納期が必須か希望か整理した


【社内体制】

□ プロジェクト責任者を決めた

□ 業務を説明できる担当者を決めた

□ 仕様確認担当を決めた

□ 最終意思決定者を決めた

□ 受入テスト担当を想定した

相談前に作っておくと便利な1枚資料

大規模なRFPをいきなり作らなくても、次の内容を1〜2ページにまとめるだけでも有効です。

【システム開発相談シート】

■ 開発したいもの

顧客・案件管理システム


■ 開発背景

営業担当者ごとにExcelで
顧客・案件を管理している。


■ 現在の課題

・顧客情報が分散
・案件状況を管理者が把握できない
・過去の対応履歴が残らない
・毎週Excel集計が必要


■ 実現したいこと

・顧客情報を一元管理
・案件状況をリアルタイム確認
・営業対応履歴を共有


■ 利用者

営業担当：15名
営業管理者：3名


■ 必要と思っている機能

・顧客管理
・案件管理
・対応履歴
・検索
・CSV


■ 現在のデータ

顧客：約10,000件
案件：約30,000件
Excel：約20ファイル


■ 予算

300〜500万円程度


■ 希望時期

2027年4月利用開始希望

この程度の資料があるだけでも、最初の打ち合わせをかなり進めやすくなります。

発注前に要件定義書まで作る必要はある？

必ずしも必要ありません。

要件定義書には、

業務要件

機能要件

非機能要件

データ要件

権限

外部連携

運用

移行

などを詳細に記載します。

しかしシステム開発の経験がない企業が、開発会社へ相談する前にすべて決めるのは難しいでしょう。

むしろ、

現在の業務

課題

目的

制約

を整理し、

必要なシステムは
開発会社と一緒に考える

方法も有効です。

IPAも、要件を分析・整理して取りまとめることをシステム開発の重要な上流活動として位置づけています。

発注前にRFPを作る必要はある？

これも案件によります。

RFPが向いているケース

例えば、

複数社へ正式提案を依頼する

数百万円〜数千万円規模

開発対象が広い

社内稟議が必要

公平にベンダー比較したい

場合です。

簡易資料でもよいケース

一方、

小規模な業務システム

まず相談したい

依頼候補が1〜2社

要件定義から依頼する

なら、最初から本格的なRFPを作らなくてもよいでしょう。

まず、

相談シート
+
既存Excel
+
業務説明

程度から開始できます。

開発会社に「何を作ればよいか」提案してもらってよい？

問題ありません。

例えば、

現在のExcel業務を
システム化したい。

ただし、
どんな画面・機能が必要か分からない。

という状態でも相談できます。

むしろ、

検索機能を作ってください

CSV機能を作ってください

ダッシュボードを作ってください

と発注者側だけで機能を決めるより、

なぜ必要なのか

から開発会社と検討した方が、不要な開発を減らせる場合があります。

開発会社へ相談するときに伝えなくてもよいこと

逆に、最初から決める必要がないものもあります。

例えば、

プログラミング言語

フレームワーク

DB製品

クラウドサービス

APIの詳細設計

などです。

明確な社内制約がなければ、

今回の要件に適した構成を
提案してください

でも構いません。

例えば、

Pythonで作ってください

ではなく、

利用者30名程度の社内Webシステム。

運用負荷と月額費用を
できるだけ抑えたい。

と伝えます。

その条件から開発会社が技術構成を提案できます。

見積を依頼する前に要件を揃える

複数社から相見積もりを取る場合は特に重要です。

例えばA社には、

スマートフォン対応が必要

と伝え、

B社には伝えなければ、

A社：
400万円

B社：
300万円

となっても比較できません。

相見積もりでは、

同じ開発目的

同じ対象範囲

同じ主要機能

同じ利用人数

同じデータ量

同じ希望時期

を伝えます。

発注前に「今回やらないこと」も決める

意外に重要です。

例えば、

今回：

○ 顧客管理
○ 案件管理
○ 対応履歴

今回は対象外：

× 請求
× 会計
× マーケティング
× AI分析

とします。

これによって開発範囲が広がり続けることを防ぎやすくなります。

システム開発発注前によくある失敗

失敗1｜いきなり機能一覧から考える

まず、

現在の業務

↓

課題

↓

実現したい状態

を考えます。

その後に必要機能へ落とします。

失敗2｜現場へ確認しない

経営者・管理者だけで要件を考えると、現場業務が抜ける場合があります。

失敗3｜既存Excelを見せない

実際の業務ルールがExcelへ埋め込まれていることがあります。

失敗4｜データ移行を忘れる

既存データを新システムへ移す作業には工数がかかります。

失敗5｜予算を決めない

提案規模が大きくばらつく原因になります。

失敗6｜納期だけ伝えて理由を説明しない

必須期限なのか希望期限なのかで開発計画が変わります。

失敗7｜意思決定者が決まっていない

仕様決定に時間がかかり、開発が止まりやすくなります。

失敗8｜最初から技術を指定しすぎる

合理的な理由がなければ、実現したいことを伝え、技術は提案してもらう方法があります。

失敗9｜すべての機能を初回開発へ入れる

予算・納期が膨らみます。

Must・Should・Couldなどで優先順位を付けます。

開発会社への初回相談で確認したいこと

発注者側の準備だけでなく、開発会社にも質問します。

例えば、

要件定義から対応できますか？

今回の業務に近い開発経験はありますか？

どのような進め方になりますか？

概算費用はどの程度ですか？

要件変更にはどう対応しますか？

リリース後の保守は可能ですか？

実際の担当者は誰ですか？

などです。

初回打ち合わせでは、技術力だけでなく、

こちらの業務を
理解しようとしているか

も確認します。

システム開発を発注するまでの流れ

一般的には次のように進めます。

STEP1
現在の業務を整理

↓

STEP2
課題を整理

↓

STEP3
システム化の目的を決める

↓

STEP4
主要要件を整理

↓

STEP5
予算・納期を決める

↓

STEP6
開発会社へ相談

↓

STEP7
提案・見積を受ける

↓

STEP8
相見積もり・比較

↓

STEP9
ベンダー選定

↓

STEP10
契約

↓

STEP11
要件定義

↓

STEP12
設計・開発

案件によっては、ベンダー選定前に詳細なRFPを作成したり、先に要件定義支援を依頼したりする場合もあります。

発注前の準備に関するよくある質問

必要な機能が分からなくても相談できますか？

できます。

現在の業務・課題・実現したい状態を伝えれば、必要機能を開発会社と整理できます。

予算が決まっていなくても相談できますか？

相談自体は可能です。

ただし、概算でも予算感がある方が現実的な提案を受けやすくなります。

「最低構成・標準構成・拡張構成」のように複数案を依頼する方法もあります。

要件定義書を準備しないと見積は取れませんか？

必ずしも必要ありません。

簡易な概算見積なら、背景・目的・主要機能・利用人数などから提示できる場合があります。

ただし、要件が曖昧なほど見積の幅は大きくなります。

Excelしかなくても相談できますか？

問題ありません。

既存Excel自体が重要な業務資料になります。

どのように使っているかと合わせて共有すると、システム化の検討材料になります。

開発会社は何社くらい相談すればよいですか？

複数社を比較する場合は、候補をある程度絞った上で3社前後から正式な提案・見積を受ける方法があります。

重要なのは、各社へ同じ条件を伝えることです。

hiro-dev-labの要件整理・業務システム開発支援

hiro-dev-labでは、Webシステム・業務システムについて、実装だけではなく発注前の段階から相談できます。

例えば、

• 現状業務のヒアリング
• 既存Excel・帳票の確認
• 業務フロー整理
• 業務課題の洗い出し
• システム化範囲の整理
• 業務要件・機能要件整理
• 非機能要件整理
• データ移行方針の整理
• 外部システム・API連携の検討
• Java・Python・TypeScriptによるWebシステム開発
• リリース後の保守・機能追加

などを検討できます。

例えば、

Excelで管理しているが
限界を感じている

↓

システム化したい

↓

しかし
何を作ればよいか分からない

という状態でも、

業務ヒアリング

↓

課題整理

↓

新業務フロー検討

↓

必要機能整理

↓

システム設計

↓

開発

と進めることができます。

発注前に必要なのは「仕様書」より「業務を説明できる準備」

システム開発を初めて発注する場合、

機能一覧を作らなければ

仕様書を作らなければ

技術を決めなければ

と思うかもしれません。

しかし、発注前の段階で最も重要なのは、

なぜシステム化したいのか

現在どう仕事をしているのか

何に困っているのか

誰が利用するのか

どこまで改善したいのか

を説明できることです。

技術的な部分は、その後に開発会社と整理できます。

まずは、

1．開発背景

2．目的

3．現状業務

4．課題

5．利用者

6．必要だと思う機能

7．既存Excel・データ

8．外部システム

9．予算

10．納期

11．対象外

12．社内体制

を確認してみてください。

すべて決まっていなくても問題ありません。

分からない部分を明確にして、

ここは開発会社と相談して決めたい

と整理すること自体が、発注準備になります。

「システム化したいが何から整理すればよいか分からない」

「現在のExcel業務をWeb化したい」

「要件定義から相談したい」

「発注前に必要な機能・費用を整理したい」

という段階からでも、システム開発の検討を進めることができます。

要件整理・業務システム開発について相談する