システム開発を外注する前に確認すべき5つのこと｜発注準備ガイド

システム開発の外注が失敗する原因は「発注前」にある

失敗の原因のほとんどは、開発が始まる前の準備段階ですでに埋め込まれています。

システム開発の外注が失敗するとき、多くの場合、問題は開発が始まってから表面化します。しかし実際には、その原因は発注前の準備段階に潜んでいることがほとんどです。よくある失敗のパターンを、原因まで遡って整理すると次のようになります。

いずれも、開発が始まってから修正しようとすると大きなコストがかかります。一般に、要件定義段階での修正コストを1とすると、リリース後の修正コストは大きく膨らみます。逆に言えば、発注前に整理しておけば防げる問題が大半だということです。

以下では、開発会社に相談する前に押さえておきたい5つの確認事項を、順に解説します。

確認事項①：何のために作るのか（目的とゴール指標）

「業務効率化したい」は目的ではありません。事業上どんな変化を起こしたいのかを、数値で表現することから始めます。

「業務効率化したい」は目的ではない

システム開発の相談で最も多いのが、「業務を効率化したい」「DXを進めたい」という要望です。しかしこれは目的ではなく、手段の方向性に過ぎません。

目的とは、「そのシステムができた結果、事業や業務にどんな変化が起きるのか」を指します。ここが曖昧なまま開発を始めると、判断基準がないため機能が際限なく膨らみ、予算とスケジュールを圧迫します。

ゴールを数値で表現する

目的を明確にする最も確実な方法は、数値で表現することです。

数値に落とすと、「その数値を達成するために本当に必要な機能は何か」という判断ができるようになります。結果として、開発範囲が絞られ、コストも抑えられます。

「作らない」という選択肢も検討する

目的を突き詰めると、システム開発以外の解決策が見つかることもあります。

たとえば「在庫管理システムを作りたい」という要望の背景が「欠品による機会損失」であれば、フルスクラッチのシステムを作らなくても、既存の在庫データに発注点アラートを追加するだけで解決するかもしれません。既存のSaaSを導入すれば十分なケースも少なくありません。

発注前の段階で「本当に作る必要があるのか」を検討しておくと、無駄な投資を避けられます。信頼できる開発会社であれば、この段階から一緒に整理してくれるはずです。

チェックリスト①

• システムを作る目的を、事業上の変化として説明できる

• 達成したい状態を数値で表現できる

• システム開発以外の選択肢も検討した

確認事項②：現状の業務フローと課題を棚卸しする

「完成したが現場で使われない」の原因は、ほぼ例外なく現場の業務フローを把握しないまま要件を決めたことにあります。

現場を見ずに要件は決まらない

情報システム部門や経営層だけで要件を決めると、現場が実際にどう作業しているかとのズレが生まれます。特に、Excelやスプレッドシートで属人的に運用されている部分は、当事者以外には見えにくいものです。

棚卸ししておくべき情報

開発会社に相談する前に、以下の情報を整理しておくと、要件定義がスムーズに進みます。

業務フロー

• 誰が、いつ、何を、どのツールで行っているか

• 手作業・二重入力が発生している箇所

• 特定の担当者しかできない属人化した作業

現在使っているツール

• 基幹システム、会計システム、CRM、Excelファイルなど

• それぞれのデータ形式と、手動で転記している箇所

既存システムとの連携要否

• API連携が必要か、CSV連携で十分か

• 連携先システムの仕様書やAPIドキュメントの有無

既存システム連携は見積もりを大きく変える

特に注意したいのが、既存システムとの連携です。連携の要否と方式によって、開発工数は大きく変わります。

既存システムがベンダー製品の場合、そもそもAPIが公開されていない、連携に別途ライセンス費用がかかる、といったケースもあります。事前に確認しておくと、見積もり段階での認識のズレを防げます。

チェックリスト②

• 現場の担当者にヒアリングを行った

• 現在の業務フローを図や文書に落とした

• 既存システムとの連携要否を把握している

• 既存システムの仕様書・API情報の有無を確認した

確認事項③：予算とスケジュールの「幅」を持っておく

予算は伝えたほうが精度の高い提案が得られます。あわせて、初期費用だけでなくランニングコストまで含めて検討します。

予算は上限を伝えたほうがいい

「予算を伝えると足元を見られるのでは」と考え、開発会社に予算を伝えない発注担当者は少なくありません。しかし実際には、予算を伝えたほうが精度の高い提案が得られます。

システム開発は、同じ要望でも実現方法によってコストが大きく変わります。予算がわかっていれば、開発会社は「その範囲で最大の効果を出すには、どの機能を優先すべきか」を提案できます。逆に予算がわからないと、フルスペックの見積もりを出すしかなく、結果として「高すぎる」と判断されて話が進まなくなります。

初期費用だけでなくランニングコストも見る

システム開発の予算を検討する際、初期の開発費用だけを見て判断してしまうケースがあります。実際には、リリース後にも継続的な費用が発生します。

システムは作って終わりではなく、使い続けるものです。3年間の総保有コスト（TCO）で比較すると、初期費用が安くてもランニングが高い提案のほうが割高になることもあります。複数社から見積もりを取る場合は、同じ期間・同じ条件で比較するようにしましょう。

スケジュールは「いつまでに」の理由を明確にする

「なるべく早く」という要望は、開発会社にとって最も判断しづらいものです。納期には必ず理由があるはずなので、それを明確に伝えましょう。

• 法改正への対応期限がある

• 繁忙期の前に稼働させたい

• 取引先との契約開始日が決まっている

• 既存システムのサポート終了日が迫っている

理由が共有されていれば、「全機能を期日までに」ではなく「この機能だけ先にリリースし、残りは段階的に」といった現実的な進め方も提案できます。

チェックリスト③

• 予算の上限を社内で確認した

• 初期費用とランニングコストを分けて検討した

• 希望納期とその理由を説明できる

• 段階的リリースの可否を検討した

確認事項④：社内の推進体制と決裁ラインを整える

開発会社に任せれば勝手に進むと考えていると、ほぼ確実にプロジェクトは停滞します。

「丸投げ」は必ず失敗する

システム開発の外注で意外と見落とされがちなのが、発注側の体制です。開発期間中には、発注側の判断が必要な場面が何度も発生します。仕様の確認、画面デザインの承認、テストへの協力、既存データの提供など、発注側が動かなければ進まない工程が多数あります。

決めておくべき3つの役割

小さな組織であれば一人が兼任することもありますが、誰がどの判断をするのかを明確にしておくことが重要です。

確認フローにかかる日数を把握する

見落とされやすいのが、社内の確認・承認にかかる時間です。「この仕様で進めてよいか」という確認に対して、社内稟議で2週間かかるとしたら、それはスケジュールに織り込む必要があります。開発会社が1週間で作れるものでも、確認に2週間かかれば、実質3週間です。

事前に「どの規模の判断なら担当者レベルで即決できるか」「役員決裁が必要なのはどこからか」を整理しておくと、スケジュール遅延の大部分を防げます。

チェックリスト④

• プロジェクトの社内担当者を決めた

• 担当者が使える工数を確保した（兼務なら何割か）

• 決裁ラインと所要日数を把握している

• 現場からテスト協力を得られる体制がある

確認事項⑤：リリース後の運用・保守をどうするか

システムの価値が生まれるのはリリースしてからです。運用・改善の方針を、発注前の段階で決めておきます。

システムは作った瞬間から古くなる

システム開発の検討では、どうしても「作ること」に意識が向きがちです。しかし実際の運用では、必ず想定外のことが起きます。

• 現場から「この機能も欲しい」という要望が出る

• 業務ルールが変わり、システムの改修が必要になる

• 利用者が増えてパフォーマンスの改善が必要になる

• OSやライブラリのアップデート対応が発生する

• セキュリティ脆弱性への対応が必要になる

これらへの対応方針を、発注前の段階で決めておくことが重要です。

契約前に確認しておきたい項目

特にソースコードの権利帰属とドキュメントの納品は、後々のリスクに直結します。ソースコードが開発会社に帰属する契約だと、将来的に別の会社へ引き継ぐことができず、価格交渉の余地もなくなります。

継続的に改善する前提で設計する

システムを一度作って何年も使うという前提は、現在の事業環境ではあまり現実的ではありません。事業も業務も変わっていく以上、システムもそれに合わせて変わっていく必要があります。

そのため、開発会社を選ぶ際は「作れるか」だけでなく、リリース後も継続的に関わってくれるかという観点で見ることをおすすめします。月額制で専属チームを確保する契約形態を用意している会社もあり、継続的な改善を前提とする場合はこうした選択肢も検討する価値があります。

チェックリスト⑤

• 保守契約の範囲を確認した

• 機能追加の依頼方法を確認した

• ソースコードの権利帰属を確認した

• リリース後の改善体制を検討した

発注前チェックリスト（5項目の一覧）

ここまでの内容を一覧にまとめます。開発会社に相談する前のセルフチェックにお使いください。

すべてが完璧に整理できている必要はありません。「わかっていること」と「まだ決まっていないこと」を切り分けておくだけでも、開発会社との議論の質は大きく変わります。

発注先を選ぶ際にあわせて確認したいこと

社内の準備が整ったら、次は開発会社の選定です。選定時に見るべき4つのポイントを整理します。

要件の背景まで聞いてくれるか
「言われたとおりに作ります」という会社より、「なぜそれが必要なのですか」と目的まで確認してくれる会社のほうが、結果的に良いシステムができます。

同じ規模・業種の開発実績があるか
実績の数だけでなく、自社と近い規模・業種の経験があるかを確認しましょう。業務理解の深さが提案の質に直結します。

リリース後の関わり方を提示してくれるか
納品して終わりではなく、その後の改善まで含めて提案してくれるかは重要な判断材料です。

見積もりの内訳が明確か
「一式」ではなく、工程ごとの工数と単価が示されている見積もりのほうが、比較検討しやすく、後々のトラブルも起きにくくなります。

開発会社の選定基準については、受託開発会社の選び方｜価格だけで決めてはいけない理由、および「納品して終わり」の開発会社を避けるための質問リストでさらに詳しく解説しています。

よくある質問（FAQ）

Q. システム開発の外注費用の相場はどのくらいですか？

システムの規模や要件によって大きく異なりますが、業務システムの新規開発であれば数百万円から、基幹システムの刷新となると数千万円規模になることもあります。重要なのは金額そのものよりも、その投資でどれだけの効果が得られるかです。目的とゴール指標が明確であれば、投資判断もしやすくなります。

Q. 要件が固まっていない段階でも相談できますか？

問題ありません。むしろ、要件が固まる前の段階から相談したほうが、より適切な解決策にたどり着けるケースが多くあります。要件定義そのものを支援する開発会社もあります。「何を作るか」ではなく「何を解決したいか」の段階でご相談ください。

Q. 開発期間はどのくらいかかりますか？

弊社の場合、小規模な業務システムで3〜4ヶ月、中規模のWebサービスやSaaSで6〜12ヶ月が一つの目安です。ただし、要件の複雑さ、既存システムとの連携有無、発注側の確認スピードによって変動します。全機能を一度にリリースせず、優先度の高い機能から段階的にリリースする進め方もあります。

Q. 既存システムがあるのですが、連携は可能ですか？

多くの場合は可能ですが、連携先システムの仕様によります。APIが公開されているか、データベースへのアクセスが可能か、といった条件によって実現方法とコストが変わります。既存システムの仕様書やベンダー情報をご用意いただけると、より正確な判断ができます。

Q. 小規模な開発でも依頼できますか？

開発会社によって受注可能な規模は異なります。小規模案件を受けていない会社もあれば、小さく始めて段階的に拡張していく進め方を得意とする会社もあります。まずは目的と予算感を伝えて、実現可能な進め方を相談するのが確実です。

Q. 開発を外注すると、社内にノウハウが残らないのでは？

契約内容次第です。ソースコードの権利が自社に帰属し、設計書などのドキュメントが納品される契約であれば、資産は社内に残ります。また、開発の過程に自社メンバーが関わることで、業務側のノウハウは蓄積されていきます。契約前に権利帰属とドキュメント納品の条件を確認しておきましょう。

まとめ

システム開発の外注は、開発会社の技術力だけで成否が決まるものではありません。発注する側の準備が、プロジェクトの成否を大きく左右します。

本記事で解説した5つの確認事項を、あらためて整理します。

1. 目的とゴール指標 — 何のために作るのかを数値で表現する

2. 業務フローと課題 — 現場の実態を把握し、既存システム連携を確認する

3. 予算とスケジュール — ランニング費用も含め、納期の理由を明確にする

4. 社内の推進体制 — 担当者・決裁ライン・確認日数を整理する

5. 運用・保守 — リリース後の改善体制を事前に決めておく

これらを整理したうえで開発会社に相談すれば、見積もりの精度が上がり、認識のズレによる手戻りも大幅に減らせます。

ただし、すべてを社内だけで整理する必要はありません。目的の整理や業務フローの棚卸しの段階から一緒に考えてくれる開発会社もあります。「何を作るか」が決まっていない段階での相談こそ、価値が生まれる場面です。