システム開発の発注前に社内で整理する方法
2026年11月1日
システム開発を外注したくても、見積もりを依頼する段階で迷うことがあります。
- 仕様が固まらず、何を伝えて見積もりを頼めばよいか分からない
- 社内で要望がまとまらず、何を頼むのか決まらない
- 見積もりは届いたが、金額が妥当か判断できない
この記事では、開発会社（ベンダー）に相談する前に、社内で整理しておきたい5つの項目を紹介します。専門的な仕様書を作る必要はありません。まずは紙1枚を目安に、分かっていることと未決定のことを書き出してみてください。
調査でも挙げられている、発注側の合意形成
発注者と受注者の関係や、長時間労働の要因について、厚生労働省が公表した意識調査があります。
「発注者・受注者で実現する働き方改革に関するプロジェクトマネージャの意識調査」厚生労働省
2019年度（調査期間 2019年8月19日〜9月9日）、IT業界4団体（JASA・CSAJ・JISA・JUAS）加盟企業、回答715件（回収率17.8%）
出典: 厚生労働省のページ（確認日 2026年11月1日）
この調査では、長時間労働の発生原因のうち発注者側の原因が5割以上だと回答したプロジェクトマネージャは62.8%でした。
調査結果には、受注者から発注者への要望として、次の点も挙げられています。
- 業務の課題と、システム化・製品化の目的について社内で合意を得ること
- 仕様変更が納期延長やコスト超過の負担につながることを認識すること
この調査からは、発注者側で目的や優先順位を共有することも、円滑に開発を進めるうえで重要だと読み取れます。技術の選定だけでなく、社内の合意形成にも目を向ける必要があります。
これは2019年度に実施された、回答者の認識を尋ねる調査です。当社の実績や、現在の開発案件全体の実態を示すものではありません。以下の5項目は、この調査を参考に当社が整理したもので、調査で効果を検証した手順ではありません。
社内で書き出す5つ
5つの項目の全体像は次のとおりです。すべてを決め切ってから相談する必要はありません。空欄があれば、相談時に確認したい課題として残しておきます。
① 目的を1文で書く
最初に、「何が困っていて、どう改善したいか」を短い文にします。うまくまとまらない場合は、困りごとをいくつかに分けて書き出し、優先したいものを選びます。具体的な対象範囲は②で整理します。
② 対象の業務を1つに絞る
関係する業務を一度にすべて対象にすると、必要な作業や費用を把握しにくくなります。まずは優先する業務を1つ選び、残りは「今回の対象外」として書き出しておきます。業務同士が切り離せない場合は、そのつながりも伝えます。
③ 入れるものと出したいものを書き出す
今ある資料・データ（入力）と、欲しい集計表や帳票などの結果（出力）を並べます。「今は紙しかない」「データの形式がそろっていない」といった現状も、必要な作業を考えるための情報になります。
④ 導入後に使う人と、更新・改修の窓口を決める
使う人だけでなく、変更が必要になったときの担当や相談先も確認します。日々のデータ更新と、プログラムの改修では、担当が異なることがあります。社内の担当者・部署と、外部へ相談する窓口を整理し、未定なら未定と記しておきます。
導入を提案する部門と、実際に使う部門が異なる場合は、両方の意見を確認してください。使い方や変更時の役割を発注前に共有しておくと、導入後に必要な支援も開発会社へ伝えやすくなります。
⑤ 変更が出たときの扱いを決めておく
開発中や利用開始後には、変更が必要になることがあります。社内では、誰が変更を判断するか、既存の手順で対応できる範囲はどこか、どの変更を開発会社へ相談するかを整理します。追加費用や納期への影響は、開発会社との協議で確認します。
書き出した1枚の例（架空）
以下は架空の会社と架空の業務です。実在の案件ではありません。
架空の設定: 従業員28名の部品加工会社。月次の受注集計を、担当者1名が受注メールと納品書の控えから表計算に手で入力している。
| 項目 | 書き出した内容 |
|---|---|
| ① 目的（1文） | 月次の受注集計を、担当者が不在でも翌月初めに作成できる状態にする |
| ② 対象の業務（1つ） | 月次の受注集計。対象外: 見積の作成、請求、在庫 |
| ③ 入れるもの | 受注メールの添付（注文書PDF）、納品書の控え、既存の集計表（過去2年分、形式が3回変わっている） |
| ③ 出したいもの | 得意先別・製品別の月次受注金額と数量、前月比 |
| ④ 使う人 | 営業2名、経理1名 |
| ④ 更新・改修の窓口 | （空欄） |
| ⑤ 変更の扱い | 製品分類が増えたときは分類表を更新する担当を決める。仕組みの改修が必要な変更は都度相談とする |
この例では、④の更新・改修の窓口が未定です。空欄は失敗ではなく、先に決めるべきことが見つかった状態です。未定のまま進めると、納品後の更新や不具合への対応で困るおそれがあります。社内の担当や開発会社との役割分担を、相談時の確認事項に加えます。
③で「既存の集計表の形式が3回変わっている」と書けたことも、見積もりの前提を伝えるうえで役立ちます。過去データをどこまで揃えるかで作業量が変わるためです。
この整理でできないこと
- 見積もりの前提を共有する準備であり、金額が決まるわけではありません。実現方法や費用の内訳は、開発会社と確認します
- 要件定義そのものではありません。画面や項目を決める作業はこの先にあります
- 作らない選択が最適な場合があります。表計算や既存のサービスで足りることもあります
- 引用した62.8%は、長時間労働の原因の5割以上が発注者側にあると回答したプロジェクトマネージャの割合です。発注者の62.8%が失敗する、という意味ではありません
- この整理をすれば開発がうまくいく、という保証はできません。報告されている詰まりどころに対して、先に手が打てる範囲を示したものです
開発会社に相談するときに確認すること
社内で整理した内容をもとに、開発会社へ相談します。その際は、提案した方法を選ぶ理由、見積もりの内訳、納品後の運用・保守、費用に含まれる範囲、より小さく始める方法がないかを確認してください。目的や条件を共有してから聞くことで、各社の提案の違いを比べやすくなります。
ご相談について
書き出す途中で止まったときは、ご相談いただけます（30分程度）。この記事を読むために相談は必要ありません。初回のご相談には、個別の調査、完全な要件定義、試作、詳細なお見積りは含みません。必要になった場合は、範囲と条件を決めてから別途ご相談します。