開発を依頼する開発会社の中には、契約後にトラブルにつながりやすい特徴を持つ会社も存在します。契約前に、そうした危険なサインに気づけると、大きな失敗を避けられます。この記事では、契約前に見抜きたい、危険な開発会社のチェックポイントを解説します。

この記事で分かること

すべての開発会社が誠実に対応してくれるとは限らず、中には注意すべき対応をする会社も存在します。この記事では、契約前の段階で確認できる、危険なサインを紹介します。

結論を先に示すと、注意すべきサインは次の3つです。

  • 契約内容の説明が曖昧、あるいは急かしてくる
  • 極端に安い、または高すぎる見積もりを提示する
  • 過去の実績や、担当者の実力を確認させない

個人でサービスを立ち上げる場合、開発会社との関係は一度きりではありません。最初のリリースだけでなく、その後の改善や機能追加も含めて、長く付き合う相手を選ぶことになります。だからこそ、契約前の段階で「この会社は信頼できるか」を見極める視点が重要です。逆に言えば、危険なサインに気づけなかったために、時間とお金を失ってから後悔するケースは、決して珍しくありません。

危険な開発会社を示す3つのサインの概要図。中心の「危険な開発会社」から、サイン1(契約内容の説明が曖昧・急かす)、サイン2(極端に安い/高い見積もり)、サイン3(実績や担当者を確認させない)へ分岐し、それぞれの特徴と対処法を示す。

サイン1:契約内容の説明が曖昧、あるいは急かしてくる

契約書の内容について質問すると、はぐらかされる、あるいは「大丈夫です、心配しなくても」というように、具体的な説明を避ける会社は注意が必要です。また、「今すぐ契約すれば割引します」というように、契約を急かしてくる会社も、慎重に検討する時間を与えないための手法である可能性があります。

誠実な開発会社であれば、契約内容について、時間をかけて丁寧に説明してくれるはずです。説明を急かされたり、曖昧にされたりした場合は、契約を一度保留し、他の選択肢も検討することをおすすめします。

具体的にどう聞かれると危険なサインか

たとえば、次のような言い回しが出てきた場合は、一度立ち止まって考えるべきタイミングです。

  • 「細かい条件は後で決めましょう。まずは契約からお願いします」
  • 「今週中に契約いただければ、初期費用を割引します」
  • 「他のお客様もこの内容で契約されているので、大丈夫ですよ」
  • 「契約書はこちらの雛形をそのまま使ってください。変更はできません」

これらはいずれも、発注者側が納得して契約するための「検討する時間」を奪う言い回しです。特に、初めて開発を発注する個人にとっては、専門用語の並んだ契約書を短時間で読み込むのは簡単ではありません。誠実な会社であれば、こちらが理解できるまで説明を重ねてくれるはずですし、持ち帰って検討することを嫌がることもありません。

急かされたときの失敗パターン

実際にあった失敗パターンとして、「今日中に契約すれば特別価格にします」と言われ、契約書の細部を確認せずに押印してしまい、後から「検収基準が明記されていない」「追加開発の扱いが曖昧」といった問題に気づくケースがあります。契約後に条件を変更するのは、契約前に確認するよりもはるかに難しく、時間もコストもかかります。急かされて即決するのではなく、「一度持ち帰って検討します」と伝え、相手の反応を見ることも、一つの見極め方法です。ここで機嫌を損ねる、あるいは態度が急に変わる会社であれば、その時点で見送りを検討してよいでしょう。

サイン2:極端に安い、または高すぎる見積もりを提示する

相場から極端に外れた見積もり(極端に安い、または高い)を提示する会社には、注意が必要です。極端に安い見積もりの場合、後から追加費用を請求される、あるいは品質が低い成果物が納品されるリスクがあります。逆に、極端に高い見積もりの場合、内訳が不透明なまま、必要以上の金額を要求されている可能性があります。

相場感を把握するためには、複数の会社から見積もりを取り、比較することが重要です。相見積もりを取る際の伝え方については、別記事で詳しく解説しています。

「安すぎる見積もり」が引き起こす典型的な失敗

極端に安い見積もりを提示された場合に起こりやすい失敗として、次のようなものが挙げられます。

  1. 契約後に「これは別途費用です」と言われる項目が次々と出てくる。最初の見積もりには、動作確認に必要な最低限の項目しか含まれておらず、実際の開発に必要な作業の多くが「オプション」として後出しされます。
  2. 必要な工程が省略されている。要件定義や設計にかける時間が極端に短く、実装をいきなり始めてしまうため、後になって「思っていたものと違う」というズレが発生しやすくなります。
  3. 品質の担保が弱い。テストや検収の工程が簡略化されており、リリース後に不具合が頻発する。
  4. 担当者が頻繁に変わる、あるいは1人で全工程を抱えている。低価格を実現するために、体制を極限まで絞っている場合があり、担当者が離脱すると開発が止まってしまうリスクがあります。

安さそのものが悪いわけではありません。効率的な開発体制や、テンプレートの活用によって、適正な価格で安く提供できる会社も存在します。問題は、「なぜこの価格で提供できるのか」を説明できない、あるいは説明を避ける会社です。安い理由を尋ねたときに、具体的で納得できる説明が返ってくるかどうかを、判断基準にするとよいでしょう。

「安すぎる見積もり」が引き起こす典型的な失敗4パターンを示すステップ図。1.契約後に別途費用が次々発生、2.必要な工程が省略される、3.品質の担保が弱い、4.担当者が頻繁に変わる、の順に並び、判断基準として安さの理由を説明できるかを示す。

「高すぎる見積もり」に潜む問題

一方で、相場より極端に高い見積もりにも注意が必要です。特に、次のようなケースでは、内訳を細かく確認することをおすすめします。

  • 「一式」「その他対応費」といった曖昧な項目で、金額の大部分が構成されている
  • 工数の内訳(誰が何時間作業するか)を尋ねても、明確な回答が得られない
  • 同じ要件を他社に伝えても、金額に大きな差が出る

高い見積もりが必ずしも高品質を意味するわけではありません。ブランド力や知名度に対して料金を上乗せしている場合もあれば、単に価格交渉を前提として、最初から高めに提示している場合もあります。相見積もりを取り、複数社の内訳を比較することで、金額の妥当性を判断しやすくなります。

サイン3:過去の実績や、担当者の実力を確認させない

「実績は機密情報のため公開できません」「担当者のスキルは契約後に分かります」というように、実績や担当者の情報を全く開示しない会社は、注意が必要です。すべての実績を詳細に開示することは難しい場合もありますが、少なくとも、大まかな実績の傾向や、担当者の経験について、ある程度の説明を求めることは、発注者として当然の権利です。

こうした「危険な提案」を見抜くには、開発会社に限らずAI開発の発注先を選ぶ際にも共通する視点が役立ちます。提案書の内容をどのような軸で比較すればよいかは、危険な提案を見抜く判断軸でも整理されている。

実績確認で見るべき具体的なポイント

実績を確認する際は、単に「実績があるかどうか」だけでなく、次のような視点で見ることをおすすめします。

  • 自分が依頼したい分野に近い実績があるか。ECサイトの開発実績が豊富でも、業務システムや専門性の高いツールの開発経験が少ない会社では、専門分野特有の落とし穴に気づけない可能性があります。
  • 公開できる実績と、公開できない実績の理由が説明されているか。守秘義務契約(NDA)によって公開できない実績があるのは自然なことです。その場合でも、「どのような業種・規模の案件か」を、具体的な名称を伏せた形で説明できるはずです。
  • 実際に開発を担当する人物のスキルを確認できるか。営業担当者が実績を説明するだけでなく、実際に手を動かすエンジニアやデザイナーと直接話す機会があるかどうかも、重要な確認ポイントです。契約後に「別の担当者に代わります」というケースもあるため、契約前の面談で、担当予定者との顔合わせを依頼してみるとよいでしょう。

実績確認を避ける会社の言い回し例

以下のような言い回しが出てきた場合、実績確認を避けている可能性があります。

  • 「実績は多数ありますが、詳細はお見せできません」
  • 「そのあたりは信頼していただくしかありません」
  • 「弊社は大丈夫ですので、ご安心ください」

こうした言い回しが出てきたときは、「では、業種や規模だけでも教えていただけますか」「担当予定のエンジニアの経験年数を教えてください」など、具体的で答えやすい質問に切り替えて、相手の反応を確認するのも一つの方法です。誠実な会社であれば、可能な範囲で具体的に答えようとする姿勢が見えるはずです。

その他の注意すべきサイン

サイン4:連絡先が携帯電話番号や個人のメールアドレスのみ

会社としての固定電話番号や、法人としての登記情報が確認できない場合、実態が不明な個人・小規模な事業者である可能性があります。必ずしも問題があるとは限りませんが、契約前に、会社の実態(法人登記の有無など)を確認することをおすすめします。

法人登記の有無は、国税庁の法人番号公表サイトなどで、会社名から無料で検索できます。個人事業主やフリーランスに依頼すること自体が問題というわけではありませんが、「法人として登記しているのか、個人事業主として活動しているのか」を、契約前に明確に把握しておくことは重要です。契約書に記載される契約主体と、実際にやり取りしている相手が一致しているかどうかも、合わせて確認しておくと安心です。

サイン5:口約束を重視し、書面での記録を避ける

「口頭で伝えた内容」だけを重視し、メールや契約書などの書面での記録を避けようとする対応も、注意すべきサインです。後になって「言った・言わない」のトラブルにつながりやすいため、重要な内容は必ず書面(メールも含む)で記録を残す習慣をつけることをおすすめします。

たとえば、打ち合わせの場で「その機能も対応します」と口頭で言われたにもかかわらず、後日、議事録やメールで確認を求めると、「そのような話はしていません」と否定されるケースがあります。このようなトラブルを避けるためには、打ち合わせの後に、決定事項を簡単にまとめて相手に送り、「この内容で認識に相違がないか」を確認する習慣をつけることが有効です。この確認メールに対して返信を渋る、あるいは内容を否定してくる会社であれば、注意が必要です。

サイン6:質問への回答が専門用語ばかりで、要点が伝わらない

発注者が理解できるように説明する努力をせず、専門用語を多用して説明を終わらせようとする対応も、危険なサインの一つです。専門的な内容を扱う以上、専門用語が出てくること自体は自然ですが、誠実な会社であれば、発注者の理解度に合わせて、噛み砕いた説明をする姿勢を見せてくれます。「分からないことはいつでも聞いてください」という姿勢があるかどうかも、信頼できる会社かどうかを見極める材料になります。

サイン7:見積もりの提示後、すぐに連絡が取れなくなる

契約前は非常に丁寧な対応だったにもかかわらず、見積もり提示後、こちらからの質問に対する返信が急に遅くなる、あるいは連絡が取れなくなるケースもあります。これは、契約の見込みが薄いと判断された、あるいは他の案件に手を取られている可能性を示しています。契約後の対応スピードを推測する材料として、契約前のレスポンスの速さや丁寧さを観察しておくことも有効です。

危険なサインの一覧チェックリスト

契約前に、以下のチェックリストを使って、危険なサインがないかを確認してみてください。当てはまる項目が多いほど、慎重な検討が必要です。

  • [ ] 契約内容について質問すると、はぐらかされる、あるいは曖昧な返答しか得られない
  • [ ] 「今すぐ契約すれば」というように、契約を急かしてくる
  • [ ] 見積もりが、他社と比較して極端に安い、または高い
  • [ ] 見積もりの内訳(工数・単価)を尋ねても、明確な説明が得られない
  • [ ] 実績や担当者のスキルについて、一切の情報開示を拒否する
  • [ ] 実際に開発を担当する人物と、契約前に話す機会が得られない
  • [ ] 会社としての固定電話番号や、法人登記の情報が確認できない
  • [ ] 重要な内容を、口頭のみで済ませようとする
  • [ ] 打ち合わせ後の確認メールに対して、返信を渋る、または内容を否定する
  • [ ] 専門用語を多用し、こちらの理解度に合わせた説明をしない
  • [ ] 見積もり提示後、質問への返信が急に遅くなる

一つのサインだけであれば、必ずしも問題があるとは限りません。しかし、チェックリストの半数以上に当てはまる場合は、その会社との契約を一度立ち止まって再検討することをおすすめします。

危険なサインに気づいた場合の対応

これらのサインに複数当てはまる場合、その開発会社との契約は、慎重に再検討することをおすすめします。すでに相談を進めている場合でも、契約を結ぶ前であれば、断ることは十分に可能です。

一つのサインだけで即座に断る必要はありませんが、複数のサインが重なっている場合は、リスクが高いと判断し、他の開発会社も検討することをおすすめします。

断りにくいと感じたときの対処法

すでに何度か打ち合わせを重ねた相手を断ることに、気が引けると感じる人も多いでしょう。しかし、契約はまだ結んでいない段階であれば、断ることに遠慮する必要はありません。「他社の提案も含めて、社内で検討させていただきます」といった伝え方であれば、相手との関係を大きく損なうことなく、断ることができます。開発会社側も、契約に至らない相談があることは前提として理解しています。断ることへの心理的なハードルよりも、契約後に問題が発覚した際のコストの方が、はるかに大きいことを念頭に置いておきましょう。

危険なサインが一部だけ当てはまる場合の判断

すべての条件が明確に「危険」と「安全」に分かれるわけではありません。たとえば、実績の一部を開示できないが、その理由(NDAなど)が明確に説明されている場合は、必ずしも危険なサインとは言えません。重要なのは、「説明を求めたときに、誠実に向き合ってくれるかどうか」という姿勢です。情報を開示できない理由が明確で、代替の説明(業種・規模の傾向など)が得られるのであれば、過度に警戒する必要はないでしょう。

危険なサインを避けるために、事前にできること

開発会社に相談する前に、その会社の実績や評判について、インターネット上の情報や、可能であれば実際にその会社に依頼した人の声を確認しておくことも、有効な事前対策です。

また、この記事で紹介したチェックポイントを、相談の際にあらかじめ意識しておくことで、危険なサインに気づきやすくなります。

危険なサインを避けるという「引き算」の視点だけでなく、そもそもどのような開発会社であれば安心して任せられるのか、「足し算」の視点で具体的な見極めポイントを知っておくと、判断はさらに確実になる。その観点は失敗しない開発会社の見極め方でも詳しく紹介されている。

相談前に準備しておきたい質問リスト

初回の相談時に、あらかじめ以下のような質問を用意しておくと、危険なサインに気づきやすくなります。

  • 「この分野の開発実績はどの程度ありますか。具体的な業種や規模を教えてください」
  • 「見積もりの内訳(工数・人数・単価)を教えてください」
  • 「実際に開発を担当する方は、どなたになりますか」
  • 「契約後、途中で担当者が変わることはありますか」
  • 「検収の基準や、保守・運用の範囲はどうなっていますか」
  • 「追加で発生しうる費用には、どのようなものがありますか」

これらの質問に対して、具体的かつ一貫した回答が得られるかどうかを、複数社で比較してみると、相場観や対応の誠実さの違いが見えてきます。

相見積もりを取ることの重要性

一社だけの説明を信じるのではなく、複数の会社に同じ条件で見積もりを依頼し、比較することが、危険なサインに気づく最も有効な方法です。一社だけと話していると、その会社の説明が「普通」なのか「不自然」なのかを判断する基準がありません。複数社を比較することで、見積もりの相場、説明の丁寧さ、対応のスピードなど、様々な観点での違いが見えてきます。

専門知識を活かしたツールの場合、追加で注意したいサイン

専門分野の業務ロジックを含むツールの場合、その専門性を理解していないにもかかわらず、「対応できます」と安易に請け負う会社には注意が必要です。専門的な質問をしてみて、的確な回答が返ってこない場合、実際の開発段階で、理解不足によるトラブルが発生する可能性があります。

たとえば、士業や特定業種向けの業務システムのように、専門知識に基づいた細かい業務ルールが存在するツールを開発する場合、開発会社の担当者がその業界特有のルールや制約を理解していないと、要件定義の段階で重要な業務ロジックが漏れてしまうことがあります。専門性の高いツールを依頼する際は、次のような質問を投げかけてみることをおすすめします。

  • 「この業界・分野の案件を過去に手がけたことはありますか」
  • 「〇〇(専門用語)という制約について、どのように実装しますか」
  • 「業務フローのヒアリングには、どの程度の時間をかけますか」

具体的で的確な回答が得られない場合、その会社にとって未経験の分野である可能性が高く、開発途中で業務ロジックの理解不足が露呈するリスクがあります。専門性の高いツールほど、契約前の対話の中で、相手の理解度を見極めることが重要になります。

実際にあったトラブル事例から学ぶ

危険なサインを見逃した結果、どのようなトラブルに発展するのか、具体的なパターンを知っておくことも有効です。ここでは、個人がサービスを立ち上げる際によく聞かれる失敗パターンを、匿名化した形で紹介します。

事例1:追加費用が段階的に発生し、当初予算の2倍になった

あるケースでは、初回の見積もりが相場よりかなり安く、疑問を持ちながらも契約したところ、開発が進むにつれて「この機能は別途費用です」「サーバー設定は別料金です」「テスト環境の構築は追加費用です」という連絡が次々と届き、最終的な支払額が当初見積もりの2倍近くに膨らんだという事例があります。契約前に、見積もりに含まれる作業範囲を明文化し、「この範囲に含まれないものは何か」を具体的に確認しておくことで、こうした事態は避けやすくなります。

事例2:担当者が途中で退職し、進捗が数ヶ月止まった

低価格を実現するために、1人の担当者にすべての工程を任せていた開発会社で、その担当者が開発の途中で退職し、後任への引き継ぎがうまくいかず、数ヶ月にわたって開発が停止したという事例もあります。契約前に、「担当者が離脱した場合の引き継ぎ体制」について確認しておくことは、特に小規模な開発会社に依頼する際の重要なチェックポイントです。

事例3:検収基準が曖昧で、完成の定義がすれ違った

契約書に「検収基準」が明記されていなかったため、発注者側は「まだ完成していない」と考えている一方、開発会社側は「契約内容は満たしている」と主張し、支払いをめぐって長期間の交渉になった事例もあります。検収基準(どのような状態になったら「完成」とみなすか)を、契約前に具体的な文言で契約書に落とし込んでおくことが、こうしたトラブルを避ける最も確実な方法です。

これらの事例に共通しているのは、いずれも「契約前に、もう少し詳しく確認していれば防げた」という点です。危険なサインは、多くの場合、契約前の対話の中に、すでに現れています。

開発会社の対応を評価するための比較表

複数の開発会社を比較する際は、以下のような観点で一覧表を作り、対応を比較することをおすすめします。感覚的な印象だけで判断するのではなく、項目ごとに書き出して比較することで、危険なサインに気づきやすくなります。

確認項目誠実な対応の例注意すべき対応の例
契約内容の説明質問に対して具体的に答え、持ち帰りも歓迎するはぐらかす、契約を急かす
見積もりの内訳工数・人数・単価を明確に提示する「一式」でまとめ、内訳を教えない
実績の開示NDAで開示できない理由も含め説明する一切の実績を見せない
担当者との対面契約前に実担当者と話す機会がある営業担当者としか話せない
連絡先・法人情報固定電話・法人登記が確認できる携帯番号・個人メールのみ
打ち合わせ後の記録議事録やメールで認識合わせをする口頭のみで済ませようとする
質問への回答姿勢分かりやすい言葉で噛み砕いて説明する専門用語だけで押し切る

この表を、実際に相談した複数の会社について記入してみると、どの会社が誠実に対応しているかが、視覚的に分かりやすくなります。

誠実な対応と注意すべき対応を5項目で比較した図。契約内容の説明、見積もりの内訳、実績・担当者との対面、連絡先・法人情報、記録の残し方・質問への回答姿勢について、左列に誠実な例、右列に注意すべき例を並べて対比している。

危険なサインを見抜く力は、発注者側の経験でも磨かれる

危険なサインを完璧に見抜くことは、初めて開発を発注する個人にとって簡単ではありません。しかし、この記事で紹介したチェックポイントを一つずつ確認しながら、複数の会社と対話を重ねることで、「何が普通で、何が不自然か」という相場観は、次第に磨かれていきます。

特に重要なのは、契約前の段階で「分からないことを、遠慮せずに質問する」という姿勢です。個人でサービスを立ち上げる場合、開発の専門知識に自信がないことを理由に、質問を控えてしまう人も少なくありません。しかし、誠実な開発会社であれば、専門知識のない発注者からの質問であっても、丁寧に向き合ってくれるはずです。逆に、質問することをためらわせるような雰囲気を作る会社であれば、それ自体が一つの危険なサインだと考えてよいでしょう。

また、危険なサインは、必ずしも「悪意」から生まれるわけではありません。人手不足で対応が追いつかない、社内の体制が整っていない、といった事情から、結果的に危険なサインに当てはまる対応をしてしまう会社もあります。悪意の有無を推測するよりも、「自分がその会社と、この先何ヶ月・何年と付き合っていけそうか」という視点で、契約前の対応を観察することが、実践的な判断基準になります。

最終的に、危険なサインへの気づきは、一つの質問や一度のやり取りだけで判断するものではなく、契約に至るまでの複数回の対話全体を通じて、積み重ねていくものです。この記事で紹介したチェックポイントを、相談の初期段階から意識しておくことで、危険な開発会社を避け、長く付き合える相手を選びやすくなります。

Q. 知人や紹介で見つけた開発会社にも、同じようにチェックすべきですか

A. 知人からの紹介であっても、チェックポイントを省略しないことをおすすめします。紹介という関係性があると、「失礼にならないように」と質問や確認を控えてしまいがちですが、契約はあくまで会社対個人のビジネス上の関係です。紹介者との人間関係を気にして確認を省略した結果、トラブルが起きた場合、開発会社との関係だけでなく、紹介者との関係にも影響が及ぶ可能性があります。むしろ、紹介であることを踏まえたうえで、「せっかくのご紹介なので、契約前にいくつか確認させてください」と伝えれば、相手も気持ちよく応じてくれるはずです。紹介の有無にかかわらず、同じ基準で確認する姿勢を持つことが、結果的に紹介者との関係も守ることにつながります。逆に、紹介だからという理由で通常より甘い条件を提示してくる会社についても、その甘さの根拠を確認しておくと安心です。

この記事の次に読みたい記事

危険な開発会社のサインを理解したら、次は規模別の発注先の向き不向きについても確認しておきましょう。あわせて次の記事も参考にしてください。