Stella Creation「安い開発会社」で失敗する典型パターンと見分け方｜安さの理由を3つに分類する
開発費が安いこと自体は問題ではありません。問題は「なぜ安いのか」を説明できるかどうかです。安さの3類型、典型的な失敗パターン、著作権とソースコードの帰属など契約で必ず確認すべき点を整理しました。
佐野 泰規株式会社Stella Creation 代表取締役この記事でわかること
- 安さには3類型ある。構造的に安い／範囲を削って安い／どこかにしわ寄せしている。危険なのは3つ目だけ
- 典型的な失敗は4つ。使えないものが納品される・追加費用で逆転する・途中で連絡が取れなくなる・ソースコードが手に入らない
- ソースコードの著作権は原則として開発会社に帰属する。契約書に譲渡を明記しないと発注者のものにならない
- 著作権法27条・28条の権利は契約書に「特掲」しないと譲渡されたことにならず、改修時に困ることがある
先に立場を明確にしておきます。開発費が安いこと自体は、まったく問題ではありません。 工数構造が違えば価格は変わります。問題なのは、その安さがどこから来ているのかを説明できないときです。この記事では、安さの理由を3つに分類し、典型的な失敗パターンと、契約段階で必ず確認すべき点を整理します。
「安い理由」は3種類に分けられる
同じ「相場より安い見積もり」でも、中身はまったく違います。
| 類型 | 何が起きているか | 判断 |
|---|---|---|
| 構造的に安い | 開発手法・体制・使う技術によって、そもそも工数が少ない。中間マージンがない | 問題なし。ただし説明を求める |
| 範囲を削って安い | テスト・データ移行・教育などの工程が入っていない | 要確認。削った分は後から必要になる |
| どこかにしわ寄せしている | 下請けへの低単価発注、経験の浅い担当者の投入、レビュー体制の省略 | 危険。品質・納期・継続性に跳ね返る |
判別方法はシンプルで、「なぜその価格で提供できるのですか」と聞くだけです。1番目の会社は具体的に答えられます。3番目の会社は、たいてい話が抽象的になります。
典型的な失敗パターン4つ
1. 納品されたが、業務で使えない
最も多いパターンです。大まかな方向性だけを伝えて発注し、数か月後に出てきたものが実際の業務の使い方と合っていない。原因は要件定義の省略で、これは「安さのために削られる工程」の筆頭です。
要件定義は発注側にも負荷がかかる工程なので、「そこは省略できます」と言われると魅力的に聞こえます。しかし省略されたぶんの認識合わせは、必ずどこかで発生します。
2. 追加費用で結局高くなる
初期見積もりは安かったが、着手後に「それは範囲外です」が続き、最終的な支払額が他社より高くなるケース。低価格の開発会社では、想定外の追加費用が発生するリスクが指摘されています。
これは見積書の前提条件・除外事項の欄を読めば事前に察知できます。読み方は見積書の読み方（5つの視点）にまとめました。
3. 途中で連絡が取れなくなる／廃業する
小規模な事業者や個人に発注した場合に起きます。特に深刻なのは納品後の廃業です。実際に、開発業者が廃業したためソースコードの引き渡しを求めたが応じられず、損害賠償請求に至った事例が報告されています。
システムは納品して終わりではありません。3年後に改修できるかまで含めて発注先を見る必要があります。
4. ソースコードが手元に残らない
次章で詳しく触れますが、これは契約書の不備によって起きます。「お金を払ったのだから自社のもの」という思い込みが、そのまま事故になります。
契約書で必ず確認する3点
ここは法律が絡むため、価格の安さ以上に効いてきます。
著作権とソースコードの帰属
重要なので明確に書きます。ソースコードの著作権は、コードを書いた開発会社に帰属するのが原則です。 発注者が権利を得るには、契約書で譲渡を定める必要があります。
さらに実務上の落とし穴があります。著作権法27条（翻案権等）・28条（二次的著作物の利用に関する権利）は、譲渡契約で「特掲」されていない場合、譲渡した側に留保されたものと推定されます。 つまり「著作権を譲渡する」とだけ書かれていても、改修・機能追加に関わる権利が移っていない可能性があるということです。
契約書には、次のように明記されているかを確認してください。
本件成果物に関する著作権（著作権法第27条および第28条の権利を含む）は、検収完了をもって甲に移転する。
なお、開発会社が汎用的な部品を他案件でも使うため、譲渡ではなく利用許諾で折り合うこともあります。これ自体は不当ではありません。大事なのは、自社が将来やりたいこと（他社への改修依頼を含む）ができる条件になっているかです。
契約不適合責任の期間
2020年4月施行の民法改正で、従来の「瑕疵担保責任」は契約不適合責任になりました。納品物が契約内容に適合しない場合、発注者は追完請求（修補）・代金減額請求・損害賠償請求・契約解除を求められます。
注意点は通知の期限です。 不適合を知ってから1年以内に通知する必要があります。高額な開発では1〜2年程度の保証期間を設けるのが一般的なので、契約書に期間の定めがあるかを確認してください。「検収して終わり」ではありません。
検収基準
何をもって「完成」とするかが書かれていない契約は、揉めます。テスト項目、確認方法、検収期間、不合格時の扱い——ここが空欄の契約書は、そもそも書類として不十分です。
発注前チェックリスト
価格の安さに納得できるかを判断するための質問です。
- なぜその価格で提供できるのですか（構造で答えられるか）
- 実際に手を動かすのは誰ですか（自社の社員か、下請けか）
- 類似案件の実績はありますか（低価格でも実績のない会社はリスクが高いとされます）
- テスト・データ移行・操作説明は含まれていますか
- 成果物の著作権はどう扱われますか
- 納品後の保証期間と、保守の体制はどうなりますか
- 3年後に改修を頼めますか
最後の質問に淀みなく答えられるかどうかは、その会社が長く事業を続ける前提で仕事をしているかの手がかりになります。
「安いのに大丈夫な会社」は説明できる
冒頭に戻ります。相場より安いこと自体は、選ぶ理由にも避ける理由にもなりません。判断材料は「安さの構造を説明できるか」の一点です。
当社もAI受託開発で「中小の開発会社相場の約半額」を掲げていますが、これは値引きではなく、生成AIを開発工程に組み込むことで工数そのものが減っているからです。この基準は当社に対しても同じように向けてください。 説明を求めて、納得できなければ選ばない——それが発注側の正しい姿勢です。
複数社を比べる際の進め方は相見積もりの取り方にまとめています。
出典（2026年8月時点）
よくある質問
- 開発費が安い会社に頼むのは避けるべきですか？
- 安さ自体は問題ではありません。判断すべきは「なぜ安いのか」です。開発手法や体制が理由なら合理的ですが、必要な工程を削っている、あるいは下請けにしわ寄せしている場合はリスクが高くなります。
- 納品されたシステムのソースコードは自社のものになりますか？
- 契約書に明記しなければ、原則として著作権は制作した開発会社に帰属します。ソースコードや設計書の権利をどう扱うかは、契約時に必ず取り決めてください。
- 契約書で著作権を譲り受けるとき注意点はありますか？
- 著作権法27条・28条の権利は、譲渡契約に特掲されていないと譲渡した側に留保されたと推定されます。「著作権（著作権法27条および28条の権利を含む）を譲渡する」と明記されているか確認してください。
- 納品後に不具合が見つかったらどうなりますか？
- 請負契約では契約不適合責任を追及できます。不適合を知ってから1年以内に通知する必要があるため、検収後も放置せず、気づいた時点で書面で伝えてください。
- 安い会社かどうかはどう見分ければいいですか？
- 「なぜその価格で提供できるのか」を質問してください。工程・体制・使っている技術で構造的に説明できる会社は信頼できます。値引きの理由が説明できない、あるいは即答で大幅値引きする会社は要注意です。