システム開発の発注が不安なときに、発注前に仕分けておくこと

2026年9月16日

この記事でわかること

システム開発の発注が不安になる理由を仕分ける
進め方と契約で減らせる不安と、その対策
依頼先の種類と選び方
社外向けサービスは「顧客がつくか」を発注前に確かめる
発注前に確かめる手段を比べる

システム開発の外注には、費用や納期など、いくつもの不安がつきまといます。

知りたいこと	答え
不安は減らせるか	費用や納期、完成物のずれといった不安の多くは、依頼先選びと進め方・契約で減らせます
減らせない不安はあるか	社外向けサービスの場合、「作ったものに顧客がつくか」は開発を依頼するだけでは減らせません
何から始めればよいか	不安を仕分け、案件が社内向けか社外向けかによって、発注前に確かめる方法を選びます

この記事では、発注の不安を5つに仕分けたうえで、進め方と契約、依頼先の選び方を整理します。後半では社外向けサービスを発注する方に向けて、発注前に確かめる手段と、社内説明に使える判断表を紹介します。

システム開発の発注が不安になる理由を仕分ける

発注前の不安はひとつにまとめて感じられがちですが、分けてみると原因も打てる手も異なります。ここでは発注者が抱きやすい不安を5つに分け、最後に何で減らせるかを表で整理します。

費用が見積もりより膨らむのではないか

追加費用が発生する経路は、おおむね決まっています。代表的なのは、開発途中の仕様変更、既存データの移行、見積もりの範囲外だった作業の3つです。仕様変更は1回ごとの影響が小さく見えるため、合意の記録を残さないまま積み重なる傾向にあります。データ移行や操作研修も、発注側が開発費に含まれていると思い込みやすい作業です。

思っていたものと違うものができるのではないか

完成物のずれは、発注側が伝えた「要望」と、開発会社が設計に必要とする「要件」の間で生まれます。たとえば「入力を簡単にしたい」という要望だけでは、誰がどの項目をいつ入力するのかが決まりません。開発会社はその空白を推測で埋めて設計するため、現場の実際の作業と合わない画面ができあがります。実際に使う担当者が完成間際まで画面を見ていない場合にも、同じずれが起こります。

開発会社と話が通じないのではないか

打ち合わせで専門用語が続き、何を決めればよいのかわからないまま話が進んでしまうという不安です。原因は発注側の知識不足だけではなく、社内では当たり前の業務の前提が、外部からは見えないことにもあります。そのため、開発会社が業務を理解するために質問してくれるかどうかも、話の通じやすさを左右します。

納期が延びて終わらないのではないか

開発の遅れには、発注側に原因がある場合と、開発会社側に原因がある場合があります。発注側の原因としては、開発会社からの質問への回答が滞ることや、承認者が不在で判断が止まることが挙げられます。開発会社側の原因としては、見積もり時点での作業量の見込み違いや、担当者の交代に伴う引き継ぎの遅れがあります。どちらに原因があるかで対応が変わるため、質問と回答の日付を記録しておくと、遅れが出たときに切り分けられます。

作ったものが使われない、売れないのではないか

この不安は、システムの種類によって中身が変わります。社内の業務システムなら、現場が使わずExcelや紙の運用に戻ってしまうという不安です。一方で社外の顧客に提供する新しいサービスなら、お金を払う顧客がそもそもつくのかという不安になります。前者は現場の業務を確認しながら仕様を決めることで減らせますが、後者は仕様の詰め方や開発の品質をどれだけ高めても、それだけでは解消されません。

5つの不安を、何で減らせるかで仕分ける

ここまでの不安を、主にどの手段で減らせるかで整理すると次のようになります。

不安	主な原因	主に減らせる手段
費用が膨らむ	仕様変更の積み重ね、範囲外の作業	進め方と契約（範囲と変更手順の確認）
思っていたものと違う	要望と要件のずれ、現場確認の不足	進め方（目的と優先順位の整理、現場の参加）
話が通じない	用語の壁、業務の前提が伝わらない	依頼先選び（業務を質問してくれる会社か）
納期が延びる	回答の滞り、作業量の見込み違い	進め方と契約（進捗の確認方法）、依頼先選び
使われない（社内向け）	現場の業務と仕様のずれ	進め方（現場を巻き込んだ仕様決め）
顧客がつかない（社外向け）	需要の見込み違い	開発を依頼するだけでは減らせず、発注前に自社で確かめる

社外向けのサービスを発注する予定なら、表の最後の行が自社に当てはまるかを先に確認しておくと、以降の章の読み方が決まります。

進め方と契約で減らせる不安と、その対策

前の章で仕分けた不安のうち、費用、完成物のずれ、納期の3つは、発注側の準備と契約の決め方で手を打てるものです。ここでは発注前から納品後までの順に、発注側が決めておくことを整理します。

目的と優先順位を、発注前に社内で決めておく

発注前に用意するのは詳細な仕様書ではなく、何のために作るのかと、どの機能から作るのかという2つの判断です。目的が決まっていないと、開発会社から出てくる提案や見積もりを比べる軸がなくなります。経済産業省のモデル契約書でも、要件定義は、発注側が社内で役割を分担してシステムへの要件を明確にする工程と位置づけられています。

優先順位は、機能ごとに「ないと業務が止まる」「手作業で代替できる」「あれば便利」の3段階で分けると、社内の意見がまとまりやすくなります。あわせて、実際にシステムを使う部署から代表者を決め、要件を決める打ち合わせに参加してもらうことをおすすめします。

見積もりは金額より、前提と範囲を確認する

見積もりの金額は、要件がどこまで決まっているかによって精度が変わります。経済産業省とIPAのモデル契約書では、見積もりを試算、概算、確定の段階に分けて進める流れが示されています。そのため、要件定義の前に出てくる金額は確定値ではなく、幅を持った数字として扱う必要があります。

確認するのは、金額そのものより見積もりの前提条件と、含まれる作業と含まれない作業の境目です。データ移行、操作研修、テスト環境の用意、稼働後の不具合対応の期間などは、会社によって見積もりへの含め方が分かれます。複数社に見積もりを依頼する場合は同じ依頼資料を渡して前提を揃えておかないと、金額の差が作業範囲の差なのか単価の差なのかを判断できません。

仕様変更と追加費用のルールを、契約前に決める

開発途中の変更は避けられないため、変更が出たときの手順を契約前に合意しておきます。決めておきたいのは、変更依頼を書面やチャットで記録に残すこと、費用と納期への影響を見積もってから着手すること、承認する人の3点です。

あわせて確認しておきたいのが契約の形態で、請負契約は、あらかじめ特定した成果物の完成に対して対価を支払う契約です。準委任契約は、開発会社が専門家として業務を遂行すること自体に対価を支払う契約で、開発会社は成果物の完成義務を負いません。IPAのモデル契約書では、要件定義を準委任型、内部設計以降の開発を請負型とする組み合わせが示されています。工程ごとに契約を分ける考え方があると知っておくと、開発会社との相談を進めやすくなります。また、納品されたプログラムの権利がどちらに帰属するかは、将来の改修や開発会社の変更に関わるため、契約書で確認しておきます。

開発中は、進捗を具体的な量で確認する

進捗報告が「予定どおりです」という言葉だけになっていると、遅れに気づくのが終盤になります。定例の打ち合わせでは、完了した作業と残っている作業を画面や機能の単位で一覧にして、共有してもらうのがおすすめです。開発会社から発注側への質問も同じ一覧に載せておくと、発注側の回答待ちで止まっている作業も見えるようになります。さらに画面が動く段階で、実際に使う担当者に触ってもらう機会を設けておくと、完成間際の手戻りを減らせます。

運用・保守の費用と体制も、発注前に確認する

システムは稼働した後も、不具合の修正や業務変更への対応で費用がかかり続けます。日本情報システム・ユーザー協会（JUAS）の調査には、自社開発システムの保守費用を年あたり初期開発費の2割強とする分析があります。この割合で計算すると、初期開発から5年間の総額は初期開発費の約2.1〜2.2倍になります。ただしこの分析は数年以上前の調査に基づくため、自社の見積もりに当てはめる数字ではなく、保守費の規模感をつかむ目安として扱ってください。

発注前には、保守契約の範囲が不具合の修正だけか小さな改修まで含むか、トラブル時の対応時間、月々の費用を確認しておきます。あわせて、設計書や運用手順書が納品物に含まれるかも確認しておくと、保守を別の会社に引き継ぐ場合や、自社で設定を変える場合に困りません。

依頼先の種類と選び方

システム開発の依頼先には複数の種類があり、どれが優れているかではなく、案件の規模や発注側が割ける時間によって向き不向きが分かれます。この章では依頼先の種類を同じ比較軸で並べたうえで、初回相談で確認しておきたいことを整理します。

依頼先の種類ごとの向き不向き

主な依頼先を、向いている案件、発注側に求められる関与の度合い、費用感、確認しておきたい点で比べると次のようになります。費用感は一般的な傾向を相対的に示したもので、実際の金額は個別の見積もりで確認する必要があります。

依頼先	向いている案件	発注側の関与	費用感	確認しておきたい点
大手SIer	基幹システムなど大規模で、品質管理や体制の厚さが求められる案件	中（窓口と承認の体制が必要）	高め	小規模案件を受けているか、実装を担う会社はどこか
中小の受託開発会社	中小規模の業務システムやWebサービス	中〜大	中程度	自社に近い業種・規模の実績があるか
フリーランス	範囲が明確な小規模の開発や改修	大（進行管理を発注側が担う場面が多い）	抑えやすい	離脱時の引き継ぎ方法、稼働できる時間
オフショア開発	仕様を文書で固めやすく、一定の規模がある案件	中〜大	人件費部分を抑えやすい	日本側の窓口役の有無、仕様書をどこまで細かく書く必要があるか
SES（エンジニアの稼働を契約）	要件が変わりやすく、社内で優先順位を決め続けられる案件	最大（作業の指示と判断を発注側が担う）	稼働時間に比例	社内に判断できる担当者がいるか
パッケージ・SaaS・ノーコード	業務が一般的な型に近く、ツールに業務を合わせられる案件	中（設定と運用ルールづくり）	初期は抑えやすく月額が続く	自社特有の業務にどこまで対応できるか

表の最後の行は、開発を発注しないという選択肢です。業務の大部分が既存のツールで回るのであれば、開発会社に相談する前に比較しておくと、発注の範囲を必要な部分だけに絞れます。

初回相談で確認したいこと

依頼先の種類を絞ったら、候補の会社との初回相談で次の点を確認します。いずれも会社案内や実績ページだけでは判断しにくく、実際の会話で見えてくるものです。

確認すること	聞き方の例	見るポイント
業務への質問	相談中に何を聞いてきたかを観察する	機能の話より先に、現在の業務の流れや困っている点を聞いてくるか
要件が固まっていない段階の進め方	「まだ決まっていない部分が多いのですが、どう進めますか」	固まるまでの進め方と、その期間の費用の考え方を説明できるか
開発体制	「実際に開発する方は御社の社員ですか、協力会社の方ですか」	担当者と実装者が誰か、打ち合わせに実装者が参加するか
リスクの説明	「この案件で費用や期間が膨らみやすいのはどこですか」	都合のよい話だけでなく、懸念点を具体的に挙げるか
発注側の役割	「近い規模の案件では、発注側は何を担当しましたか」	発注側に求める作業量を、契約前に具体的に示せるか

最後の質問は、発注側の工数を見積もるために役立ちます。回答を社内で共有しておくと、担当者の業務量の調整や、開発期間中に誰が判断するかを事前に決めやすくなります。

開発会社に聞いても判断できないこと

ここまでの確認で、依頼先選びと進め方に関わる不安の多くは具体的な手順に落とし込めます。一方で、開発会社は「どう作るか」の専門家であり、作ったサービスを市場の顧客が買うかどうかを保証する立場にはありません。事業の相談に乗る開発会社もありますが、需要があるかどうかの判断材料を用意し、発注するかを決めるのは発注側です。社内向けのシステムであればこの点は問題になりにくい一方、社外の顧客に提供するサービスの場合は、発注前に別の手段で確かめておく必要があります。

社外向けサービスは「顧客がつくか」を発注前に確かめる

ここからは、社外の顧客に提供する新しいサービスを発注する場合に絞った内容になります。社内の業務システムを発注する場合は、最後の章「発注するかどうかを社内で説明するための判断表」に進んでもかまいません。

社内システムと社外向けサービスでは、発注前に確かめることが違う

同じシステム開発の発注でも、使う人が社内か社外かによって、発注前に確かめる対象が変わります。

項目	社内の業務システム	社外向けの新しいサービス
使う人	自社の従業員	社外の顧客
発注前に確かめること	現場の業務の流れと例外、既存ツールで代替できる範囲	想定した顧客が課題を抱えているか、問い合わせや購入などの行動をとるか
確かめる方法の例	業務の棚卸し、現場へのヒアリング、既存ツールでの試行	顧客へのインタビュー、反応を数値で測る方法（次の章で比較）
確かめる相手	社内にいるため、声をかければ話を聞ける	社外にいるため、接点をつくるところから始める

「MVPから始める」も、ひとつの発注である

失敗を小さくする方法として、必要最小限の機能だけを持つ製品（MVP）を先に作り、顧客の反応を見てから機能を足していく進め方があります。最初から全機能を作るより投資の規模を抑えられ、実際に使われたときの継続率や操作性など、作ってみないとわからない情報も得られます。

ただし、MVPも開発会社への発注であることに変わりはなく、この記事で扱ってきた要件の整理、見積もり、契約の確認はすべて必要です。また、どの機能を最小限とするかは「顧客はこの課題にお金を払う」という前提の上で決まります。その前提自体を確かめたい場合は、作る前に確認できる手段もあわせて比べておくと、MVPに何を載せるかの判断にも使えます。

発注前に確かめる手段を比べる

顧客がつくかを発注前に確かめる手段は複数あり、確かめずに発注する選択も含めて同じ軸で並べると次のようになります。

手段ごとの、わかること・わからないこと

手段	わかること	わからないこと	費用の主な中身	向いている状況
確かめずに発注する	―	発注前には何もわからない	開発費のみ	既存顧客から具体的な要望や購入の約束がある
自社で行う（顧客への聞き取りなど）	課題の具体的な中身、顧客の言葉	接点のある相手以外の反応	社内の人件費	想定顧客とすでに接点がある
調査会社に依頼する	多数の回答者の評価や課題の有無	回答者が実際に問い合わせや購入をするか	調査費	市場の全体像や、課題の広がりを知りたい
広告代理店に依頼する	広告を見た人のクリックや問い合わせの反応	判定の基準は依頼範囲によって異なる	広告費と運用費	自社で結果を読み、判断できる担当者がいる
検証サービスに依頼する	広告経由の反応と、事前に決めた基準による判定	成約までの営業結果、継続利用	広告費と検証費	判断の基準づくりから外部の手を借りたい
MVPを発注する	継続利用や操作性など、使ってみないとわからない反応	前提が外れていた場合、それがわかるのは開発後	開発費	需要の手応えはあり、使われ方を確かめたい

すでに購入を約束している顧客がいる場合は、確認に時間をかけるより発注を早めるほうが合理的です。

実例：2週間の検証でわかったこと、わからなかったこと

ここで紹介するのは開発案件ではなく、既存事業で新しい顧客層を探した検証の実例です。自社の想定と市場の反応のずれを確かめるという構造は、開発の発注前と共通しています。

どのような条件で検証したか

対象はリネンサプライ業の会社で、検索広告と検証用のページを使い、2週間、広告費約10万円で新しい顧客層の需要を確かめました。期間中の表示回数は1,850回、クリックは129回、成果と定義した問い合わせと資料請求は合わせて15件でした。

自社の強みとして掲げた訴求は、検索表示が0回だった

この会社は、設備による汚れのチェックや小ロットでの対応を強みと考え、広告の切り口にしていました。しかし期間中、汚れの悩みを切り口にした広告と、小ロット対応を切り口にした広告は、どちらも表示回数が0回でした。反応が集まったのは、民泊事業者がリネンの業者を探すといった、業者そのものを探している検索でした。

表示されなかったことは強みに価値がないことを意味せず、顧客と出会う入口ではなく、出会った後に比べてもらう材料として使うべきだという結果です。開発に置き換えると、強みとして要件に入れようとしている機能が、顧客の探す理由になっているかを確かめる必要がある、ということになります。

差を判定できた指標と、できなかった指標がある

比較	民泊事業者の層	業者を広く探す層	差を判定できたか
クリック率	約17%（クリック25回）	約6%（クリック75回）	できた
問い合わせ率	20%（5件）	約9%（7件）	できなかった

クリック率は分母が大きいため差として読めますが、問い合わせは件数が一桁のため、2倍に見えてもこの検証だけでは差があるとは判断できません。

問い合わせから成約まで追うと、件数はここまで絞られた

問い合わせと資料請求の15件のうち、商談に進んだのは5件、成約に至ったのは2件でした。入口の反応の件数は、そのまま売上になる需要の量を示すわけではありません。なお、商談と成約の顧客層ごとの内訳はここでは扱っていないため、民泊事業者の層に絞る判断の裏づけには使っていません。

発注するかどうかを社内で説明するための判断表

発注の判断を社内で説明するには、結果の読み方と進める条件を、第三者が見てもわかる形で残しておく必要があります。この章では、その2つを稟議資料に使える表にまとめます。

検証結果を段階ごとに読む

反応を数値で測った場合は、成約に近い段階から順に、どこで反応が止まったかを確認します。1件の検証から基準値は示せないため、状態ごとの意味と次の行動を整理し、前の章の実例を参考として添えています。

見る順	観測された状態	意味	次の行動	実例
①	成約が出た	入口から成約までつながった	再現性を確かめつつ、発注の規模を段階的に決める	該当（2件）
②	商談は出たが成約はない	価格や条件、営業のどこかで止まっている	失注の理由を確認し、提供条件を見直す	―
③	問い合わせは出たが商談はない	関心はあるが検討段階にとどまっている	問い合わせの中身と訴求の内容を照らし合わせる	―
④	クリックはあるが問い合わせがない	ページの内容が合っていない	ページを見直して再測定する（需要なしとは判定しない）	清掃関連の検索で該当
⑤	表示はあるがクリックがない	広告の見せ方が合っていない	広告の文面を見直す	管理系の訴求で該当
⑥	表示がない	期間中、その言葉で検索した人がいなかった	入口には使わず、差別化の材料として残すかを別に判断する	汚れ・小ロットの訴求で該当
―	件数が少なく差を判定できない	判断不能	延長か保留かを、事前の取り決めに従って決める	顧客層ごとの問い合わせ率で該当

「判断不能」は正式な結論のひとつとして扱います。発注か見送りかの二択にしておくと、判断がつかない結果が社内の期待でどちらかに寄せられやすくなるためです。

稟議に載せる判断材料を埋める

次の表は、社内システムと社外向けサービスのどちらの発注にも使えます。

項目	記入の手がかり
案件の種類	社内の業務システムか、社外向けサービスか
最も大きな不安	不安を仕分けた表から選ぶ
その不安を減らす手段	依頼先選び、進め方と契約、発注前の確認のどれか
発注前に確かめる方法	社内なら業務の棚卸し、社外向けなら手段の比較表から選ぶ
確認にかける費用と期間	開発見積もりの金額と並べて書く
発注を進める条件	確認を始める前に決める
発注を見送る条件	確認を始める前に決める
判断できなかった場合の扱い	延長、保留、規模を縮小した発注のどれか