システム開発を外注する前に決めておくべき10項目｜発注前チェックリスト

初めてシステム開発を外注するとき、迷いやすいポイントです。

結論からいうと、すべての仕様を決めてから相談する必要はありません。 一方で、目的や利用者、予算、希望時期などが何も整理されていないと、開発会社側も適切な提案や見積もりを出しにくくなります。

大切なのは、完璧な仕様書を作ることではなく、「決まっていること」と「まだ決まっていないこと」を整理することです。

この記事では、システム開発を外注する前に整理しておきたい10項目と、逆に発注側で無理に決めなくてもよいことを解説します。

この記事で分かること

• システム開発を外注する前に整理したい10項目
• それぞれをどこまで決めればよいのか
• 発注前に無理に決めなくてもよいこと
• 見積もりや開発工数が増えやすいポイント
• 開発会社へ最初に伝える内容

システム開発の外注前に、すべての仕様を決める必要はありません

システム開発では、相談したあとに「要件定義」という工程があります。

要件定義とは、どのような業務を、どのようなシステムで実現するのかを具体的に整理していく工程です。

そのため、初回相談の段階で画面構成や細かな動作まで完全に決めておく必要はありません。

ただし、「よく分からないので全部お任せします」でも進めにくくなります。

発注側しか分からないことも多いからです。

たとえば、

• 現在どの業務に困っているのか
• 誰がシステムを使うのか
• どんな業務ルールがあるのか
• 絶対に必要な機能は何か
• 予算や期限に制約があるか

といった情報は、開発会社だけでは判断できません。

発注前に必要なのは、完成した仕様書ではなく、システムの方向性を判断するための材料です。

システム開発を外注する前に決めておきたい10項目

開発会社へ相談する前に、次の10項目を一度整理してみてください。

すべてを確定する必要はありません。「決まっている」「まだ未定」と分けるだけでも十分です。

ここから、それぞれ詳しく見ていきます。

1. システムを作る目的・解決したい課題を決める

最初に整理したいのは、**「何を作りたいか」より「なぜ作りたいか」**です。

たとえば、

「受発注システムを作りたい」

だけでは、開発会社は何を優先すべきか判断できません。

もう一段具体的にして、

「受注情報をExcelとメールで管理していて、転記作業や入力ミスが発生している。情報を一元管理したい」

と伝えると、解決したい課題が見えてきます。

目的としては、たとえば次のようなものがあります。

• 手入力を減らしたい
• Excelへの二重入力をなくしたい
• 情報を一か所にまとめたい
• 担当者しか分からない業務を減らしたい
• 顧客自身で申し込みや確認ができるようにしたい
• 集計やレポート作成を自動化したい

「システムを導入する」がゴールではありません。

システムによって、業務や顧客体験をどう変えたいのかを考えてみてください。

2. 誰がシステムを利用するのか整理する

同じ機能でも、誰が使うかによって設計は変わります。

たとえば、

• 社内の担当者だけが使う
• 管理者と一般社員が使う
• 全国の店舗スタッフが使う
• 取引先もログインする
• 一般ユーザーが利用する

といった違いです。

利用人数も分かる範囲で伝えておきましょう。

「10人程度」「100店舗ほど」「一般ユーザー向けなので将来的に増える予定」くらいでも構いません。

利用者数や利用方法によって、権限管理、画面設計、インフラ構成などの検討内容が変わります。

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

新しいシステムの機能だけでなく、現在どのように仕事をしているのかも大切な情報です。

たとえば受注管理なら、

注文を受ける
↓
Excelへ入力する
↓
担当者が確認する
↓
在庫を確認する
↓
請求情報を会計ソフトへ登録する

といった流れです。

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

現在使っているExcel、Googleスプレッドシート、紙の帳票、メールのテンプレートなどがあれば、それ自体が開発会社にとって大きな参考になります。

また、

「通常はこの流れだが、キャンセル時だけ別の処理をする」

といった例外も分かる範囲で伝えてください。

システム開発では、こうした通常とは異なる処理が増えるほど、設計や実装、テストの工数が増えやすくなります。

4. どこまでをシステム化するのか決める

業務のすべてを一度にシステム化する必要はありません。

たとえば受発注業務でも、

• 受注だけ管理する
• 受注と在庫を管理する
• 請求まで管理する
• 顧客管理まで含める

では、開発規模が大きく変わります。

ここで役立つのが、「今回はやらないこと」も決めることです。

「将来的には請求まで自動化したいが、今回は受注管理まで」

という形でも構いません。

範囲を区切ることで、初期費用や開発期間を抑えながら、優先度の高い課題から解決できます。

5. 必要な機能に優先順位をつける

機能を洗い出したら、すべてを同じ優先度にしないことも大切です。

たとえば、

必須

• ログイン
• 顧客登録
• 受注登録
• 検索
• CSV出力

できれば欲しい

• ダッシュボード
• グラフ表示
• 通知
• 詳細な検索条件

のように分けます。

見積もりが予算を超えたとき、優先順位がなければ「何を削るか」の判断ができません。

逆に優先順位が明確なら、

「今回は必須機能だけ開発して、通知機能は後から追加する」

といった選択ができます。

6. 既存データと外部システム連携を確認する

見積もり時に見落とされやすいのが、既存データの移行と外部システムとの連携です。

たとえば、

• Excelにある顧客データを移したい
• CSVデータを取り込みたい
• 会計ソフトと連携したい
• ECサイトと連携したい
• 決済サービスを利用したい
• メールやSMSを自動送信したい
• 社内の既存システムと情報をやり取りしたい

といったケースです。

システム同士がデータをやり取りする方法として「API」が使われることがあります。

ただし、発注側でAPIの詳しい仕様まで調べる必要はありません。

「どのサービスと、どんな情報を連携したいか」だけでも伝えておきましょう。

データ移行や外部連携が後から判明すると、設計や開発範囲が大きく変わる場合があります。

7. 権限とセキュリティの大枠を決める

業務システムでは、「ログインできるか」だけでなく、ログインした人が何をできるのかも考える必要があります。

たとえば、

といった違いです。

特に、

• 個人情報を扱う
• 社外秘情報を扱う
• 取引先ごとにデータを分ける
• 管理者しか見られない情報がある
• 操作履歴を残す必要がある

といった要件があれば、早めに伝えてください。

具体的な認証方式やセキュリティ技術まで決める必要はありません。

発注側では、**「誰に、どの情報まで見せてよいのか」**を整理するところから始めれば十分です。

8. 予算または予算レンジを決める

予算も、可能であれば最初に共有した方がよい情報です。

同じ課題でも、

「予算内で最低限のシステムを作りたい」

のか、

「必要な機能をすべて実現した場合の費用を知りたい」

のかで、開発会社からの提案は変わります。

正確な金額を決められない場合は、

• おおよその上限だけ決まっている
• ○○万円前後を想定している
• 予算は未定なので、まず概算が知りたい

といった状態でも構いません。

また、システムでは初期開発費だけでなく、公開後にも費用が発生します。

たとえばサーバー、ドメイン、外部サービス、保守、機能追加などです。

そのため、初期費用だけでなく、運用を続けるためのランニングコストも含めて考える必要があります。

あわせて読みたい：『Webシステム開発の費用相場｜50万・100万・300万円で作れるものを解説』

9. 希望する公開時期と、動かせない期限を整理する

納期については、「なるべく早く」だけではなく、その時期に公開したい理由も伝えましょう。

たとえば、

• 新サービスの開始日に合わせたい
• 年度が変わるまでに導入したい
• 現在のシステムの契約終了までに切り替えたい
• 特に期限はなく、費用を優先したい

などです。

「できれば早い方がいい」と「この日を超えると業務上困る」では、開発計画が大きく変わります。

絶対に動かせない期限がある場合は、初回相談時点で共有してください。

10. 社内の意思決定者と運用担当者を決める

システム開発では、開発会社だけで判断できないことが何度も発生します。

たとえば、

• この画面で問題ないか
• この機能は必要か
• この業務ルールでよいか
• 予算を追加するか
• この状態で公開してよいか

といった判断です。

そこで、「最終的に誰が決めるのか」を明確にしておく必要があります。

また、完成後に誰が運用するのかも考えておきましょう。

経営者や発注担当者だけで仕様を決め、実際に使う現場の担当者が確認していないと、完成後に「現場では使いにくい」となることがあります。

可能であれば、実際の利用者にも要件確認や画面レビューへ参加してもらうと、認識のズレを減らせます。

10項目を全部覚えるより「目的・優先順位・制約」を押さえる

ここまで10項目を紹介しましたが、初めて発注する場合は一度に整理するのが難しいかもしれません。

その場合は、最低限次の3つから考えてみてください。

目的

何を改善・解決するために作るのか。

優先順位

今回絶対に実現したいことは何か。

制約

予算、期限、既存システムなど、簡単には変えられない条件は何か。

この3つが分かるだけでも、開発会社は提案の方向性を考えやすくなります。

逆に、外注前に発注側で決めなくてもよいことがあります

発注前の準備は必要ですが、専門的な部分まで発注側だけで決める必要はありません。

むしろ、理由なく技術を固定すると、選択肢を狭めることもあります。

プログラミング言語やフレームワーク

「PHPで作る」「Reactを使う」といった技術指定は、特別な理由がなければ必須ではありません。

既存システムとの統一、社内エンジニアが今後保守するなどの事情があれば指定する意味があります。

そうでなければ、機能、利用人数、予算、運用方法、将来の拡張などを伝え、適した技術を提案してもらう方法があります。

サーバーやインフラ構成

AWSやGoogle Cloudなど、システムを動かす環境にもさまざまな選択肢があります。

発注前にサービス名まで決めるより、

• 24時間利用する
• 海外からも利用する
• 大量アクセスが発生する可能性がある
• 個人情報を扱う

といった条件を伝えた方が、適切な構成を検討しやすくなります。

細かな画面デザイン

画面で「何をしたいか」は整理しておくべきですが、ボタンの位置や余白まで発注前に決める必要はありません。

参考にしたいサービスや簡単な手書きイメージがあれば、それを共有するだけでも十分な材料になります。

すべての例外ケース

業務には、通常とは異なる処理が必ずと言ってよいほどあります。

とはいえ、初回相談までにすべてを洗い出す必要はありません。

まず通常の業務を説明し、その後の要件定義で例外を確認していく方法があります。

発注前に整理しておくと、見積もりのズレも減らしやすくなります

開発会社の見積もりは、単純な「画面数」だけで決まるわけではありません。

たとえば、

• 例外処理が多い
• 権限パターンが多い
• 複数の外部システムと連携する
• 大量の既存データを移行する
• 複雑な承認フローがある
• 高いセキュリティ要件がある

といった条件があると、設計・実装・テストする内容も増えます。

つまり、発注前の情報整理には、単に「話し合いを楽にする」だけでなく、開発会社が必要な工数を判断しやすくする意味もあります。

逆に、重要な条件が契約後に判明すると、追加費用やスケジュール変更の原因になることがあります。

分かっていることは、見積もり段階からできるだけ共有しておきましょう。

そもそもシステムを作らない方がよいケースもあります

「システム開発を検討している＝システムを作るべき」とは限りません。

ExcelやGoogleスプレッドシートで十分な場合

利用者が数人しかおらず、現在の方法でも大きな問題がないのであれば、システム開発の費用に見合わないことがあります。

ExcelやGoogleスプレッドシートの整理、自動化だけで解決できないかも検討してみてください。

既存SaaSでほとんど解決できる場合

勤怠管理、会計、顧客管理、予約管理など、多くの分野にはすでにSaaSがあります。

自社独自の業務が少なければ、一から作るより既存サービスを使った方が早く、運用負担も小さくなる場合があります。

業務フロー自体がまだ固まっていない場合

新規事業などで業務の進め方が頻繁に変わっている場合、最初から細かくシステム化すると、完成時には業務と合わなくなることがあります。

まずはExcelや既存ツールなどで業務を試し、運用がある程度固まってから開発する方法もあります。

開発費に対して改善効果が小さい場合

毎月わずかしか発生しない作業を自動化するために、大きな開発費をかけるのであれば、投資として合理的かを考える必要があります。

大切なのは、「システムとして作れるか」だけではありません。

そのシステムを作る価値があるかまで考えておきましょう。

10項目が全部決まっていなくても、開発会社へ相談できます

たとえば、

• 目的：決まっている
• 利用者：決まっている
• 必要機能：大まかに決まっている
• 予算：分からない
• 技術：分からない
• 公開時期：年内を希望

という状態でも、十分に相談できます。

むしろ、分からない技術や仕様まで無理に自社だけで決めるより、開発会社へ条件を伝えながら整理した方がよい場合もあります。

Bake Systemでは、最初に課題とゴールを整理し、画面や仕様の叩き台を出したうえで、最優先の価値となる部分から実装し、運用後に必要な機能を改善・拡張していく流れを公開しています。

最初からすべてを固定するのではなく、まず判断できる状態を作り、優先度の高い部分から具体化していくという考え方です。

開発会社へ最初に問い合わせるときは、この内容を伝えればOKです

初回相談のために、長い仕様書を作る必要はありません。

最低限、次の内容が分かれば話を始めやすくなります。

• 現在困っていること
• 作りたいもの
• 誰が使うのか
• 絶対に必要な機能
• 希望時期
• 予算感
• まだ決まっていないこと

たとえば、次のような内容です。

「現在、受注業務をExcelで管理しており、入力や確認に時間がかかっています。Webシステムへの移行を検討しています。

利用者は社内10名程度で、年内の利用開始を希望しています。顧客管理と受注管理は必要だと考えていますが、具体的な機能や予算についてはまだ検討中です。」

この内容だけでも、

「何に困っているのか」

「どの程度の規模なのか」

「どこから一緒に整理する必要があるのか」

が分かります。

最初の問い合わせでは、完璧な資料を作ることより、背景と現在地を正しく伝えることを優先してください。

将来の保守や開発会社の変更も発注前に確認しておく

初期開発だけでなく、完成したあとのことも少し考えておきましょう。

システムは公開後も、

• 不具合への対応
• OSやブラウザなど環境変化への対応
• 外部サービスの仕様変更への対応
• 機能追加
• 利用者の要望に合わせた改善

などが発生します。

そのため、開発会社を選ぶ際には、

• 公開後の保守を依頼できるか
• 保守費用はどのような形か
• ソースコードはどのように管理されるか
• 自社でもデータを取得できるか
• 将来ほかの開発会社へ引き継げるか

といった点も確認しておくと安心です。

特定の会社にしか分からない構成になると、将来の選択肢が狭くなることがあります。

初期費用だけでなく、数年運用する前提で「誰が保守できるのか」まで確認することをおすすめします。

よくある質問

Q. 10項目すべて決まっていないと相談できませんか？

いいえ。すべて確定している必要はありません。

決まっている項目と未定の項目を分けておけば、未定部分も含めて開発会社へ相談できます。

Q. RFPは必ず作る必要がありますか？

必須ではありません。

RFP（提案依頼書）は、発注側が開発会社へシステムの概要や要望、条件などを伝え、提案を依頼するための資料です。

複数社へ同じ条件で提案を依頼する場合などには役立ちますが、小〜中規模の開発で初回相談をするために必ず詳細なRFPを作る必要があるわけではありません。

Q. 予算が分からなくても相談できますか？

相談できます。

「まだ予算が決まっていないので、まず概算を知りたい」と伝えて構いません。

ただし、使える上限が決まっている場合は早めに共有した方が、その範囲で実現できる方法を検討しやすくなります。

Q. 使用するプログラミング言語も決めた方がよいですか？

特別な理由がなければ、無理に決める必要はありません。

必要な機能、利用人数、既存環境、予算、将来的な拡張などを伝え、それに適した技術を提案してもらう方法があります。

Q. 要件定義は発注側と開発会社のどちらが行いますか？

発注側も主体的に参加する必要があります。

業務のルールや目的を最も理解しているのは発注側です。一方で、それをシステムの仕様へ落とし込むには専門知識が必要なので、開発会社の支援を受けながら整理していく形が現実的です。

「全部お任せ」ではなく、業務について説明し、仕様を確認・判断する役割は発注側にもあります。

まとめ｜完璧な仕様書より「判断材料」を整理してから相談しましょう

システム開発を外注する前には、次の点を押さえておきましょう。

• 目的・利用者・現在の業務を整理する
• 必要な機能に優先順位をつける
• 予算・期限・外部連携などの制約を共有する
• すべてを自社だけで決めようとしない
• 初期開発だけでなく、公開後の運用や保守も考える

そして、10項目すべてを確定する必要はありません。

「ここまでは決まっている」「ここから先は分からない」と整理できたら、開発会社へ相談を始めるタイミングです。

技術や細かな仕様について分からなくても問題ありません。

まずは「何を作りたいか」より、「今何に困っていて、どう変えたいのか」から整理してみてください。