なぜ「危ない会社」に引っかかるのか
公開日：2026年6月30日｜カテゴリ：システム開発・外注管理・リスク回避
「格安で作ります」と言われて発注したら、後からオプション費用が雪だるま式に膨らんだ。納品直前にベンダーと連絡が取れなくなった。完成したシステムがバグだらけで使い物にならない——。
システム開発のトラブルは一定の割合で訴訟・仲裁・調停に発展する。訴訟化するトラブルに共通するのは「書面による合意の不足」と「プロジェクト経緯の記録の不備」——つまり、危ない会社は契約前から兆候を出している。
ここで朗報がある。危ないシステム開発会社は、発注前に必ず「シグナル」を出している。そして、そのシグナルが最も濃縮されて表れる場所が見積書だ。
本記事では、行動経済学・認知科学・成功者の思考パターンをもとに、危ない開発会社の見分け方と、見積書から会社の本性を読み取る具体的な技術を解説する。ITの専門知識がない経営者・担当者でも、今日から使える判断基準を提供する。
第1章：なぜ「危ない会社」に引っかかるのか——行動経済学の答え
「安さ」があなたの判断力を破壊する——アンカリング効果
行動経済学の「アンカリング効果」——最初に提示された数字が基準になり、その後の判断がすべて歪む——が、発注失敗の最大のメカニズムだ。
3社から見積もりを取り、A社800万円・B社750万円・C社300万円だったとする。このときC社の「300万円」がアンカーになり、「A社とB社は高すぎる」と感じてしまう。だが実際に疑うべきはC社だ。最低限の機能のみを見積もりに含め、後から「オプション」として追加費用を請求するケースは少なくない。「格安」を謳う見積もりこそ、最も高くつく可能性がある。
「サンクコスト効果」が撤退を遅らせる
危ない会社と契約してしまった後も、行動経済学の罠は続く。「もう500万円払ったのだから、いまさら止められない」——このサンクコスト効果により、発注者は問題だらけのプロジェクトに追加投資を続け、被害を拡大させる。
成功者の思考は逆だ。「すでに払った金は戻らない。これから払う金で何が得られるか」だけで判断する。だからこそ、撤退条件を契約前に決めておくことが、傷を浅くする唯一の方法になる。
コストだけで選ぶことのメリット・デメリットを正面から整理する
安い会社を選ぶメリットは明確だ。初期投資が抑えられ、稟議が通りやすく、失敗しても損失が小さい——ように見える。
だがデメリットは構造的だ。安さの源泉は「工数の削減」であり、それは要件定義の省略・テストの簡略化・経験の浅い人員の投入・オフショアへの丸投げのどれかで実現されている。発注経験の豊富な担当者ほど「技術力と誠実さ」を重視する傾向があるのは、コストのみで選定したベンダーと後からトラブルになる事例が非常に多いことを、身をもって知っているからだ。
コスト重視が合理的なのは「小規模・使い捨て・失敗しても業務が止まらない」案件だけだ。基幹業務に関わるシステムでは、価格の安さは「リスクの前借り」にすぎない。
第2章：危ない開発会社が出す8つの危険シグナル
危ない会社は、契約前の言動に必ず兆候が出る。以下の8つのシグナルのうち、3つ以上該当したら発注を見送るべきだ。
図1｜危ない開発会社の危険シグナル・チェックリスト
| # | 危険シグナル | なぜ危険か | 危険度 |
|---|---|---|---|
| 1 | 見積書に「一式」が多い | 内訳を隠すことで、後からの追加請求の余地を残している。「一式」はトラブルの温床。 | ★★★ |
| 2 | 要件が曖昧なのに即答で金額を出す | 詳細が決まらない状態での安易な開発費算出は、後から仕様変更のたびに費用が雪だるま式に膨らむ前兆。 | ★★★ |
| 3 | 相場より極端に安い | 最低限の機能のみを含め、後からオプション費用を請求する典型パターン。安さはリスクの前借り。 | ★★★ |
| 4 | 要件定義を省略・軽視する | 失敗原因の筆頭は「要件定義の曖昧さ」。ここを急がせる会社は完成後の「思っていたものと違う」を量産する。 | ★★ |
| 5 | 議事録を残さない・書面化を嫌う | 訴訟化するトラブルの共通点は「書面による合意の不足」。口頭ベースで進める会社は紛争予備軍。 | ★★ |
| 6 | 再委託（下請け）の説明が曖昧 | 窓口は元請でも実作業は別会社という構造では、引継ぎ不足・品質管理の不一致でトラブルが一気に拡大する。 | ★★ |
| 7 | 運用保守の話を避ける | 保守契約なしで納品後に障害が起きても対応してもらえず、業務が長時間ストップした事例は多い。「作って終わり」の会社は避ける。 | ★★ |
| 8 | 中間確認（マイルストーン）がない | 長期プロジェクトで一度も成果物を確認できないまま納期直前になるのは非常に危険。段階確認を嫌う会社は進捗を隠す。 | ★★ |
※3つ以上該当で発注見送りを推奨。特に★★★の3項目は1つでも該当したら要警戒。
第3章：見積書から会社の本性を読み取る技術
見積書は単なる価格表ではない。開発会社からの「提案書」であり、その会社の仕事の進め方・誠実さ・技術力が凝縮された「人格診断書」だ。どこを見れば何が分かるのか、具体的に示す。
図2｜見積書の読み方——ここを見れば本性が分かる
| 見る場所 | 良い見積書のサイン | 危険な見積書のサイン |
|---|---|---|
| 内訳の粒度 | 機能ごとに費用が分解され、工数（人月）と単価が明示されている。予算超過時に「この機能を削る」判断ができる。 | 「開発費一式」「設計一式」の羅列。内訳の質問に「弊社の標準です」としか答えない。 |
| 「やらないこと」の明記 | データ移行・マニュアル作成・対応ブラウザ範囲など「含まれないもの」が明記されている。誠実さの証拠。 | 対応範囲の記載がなく、「そこは含まれていません」が開発後半に頻発する構造になっている。 |
| 単価と工数の妥当性 | 「1人月◯◯万円×◯ヶ月」が相場（60〜120万円/人月）の範囲内。工数の根拠を質問すると具体的に説明できる。 | 単価が異常に高い/安い。簡単な要件に不自然に長い工数。不要なライセンス費・サーバー費が高額に紛れ込む。 |
| 変更管理のルール | 「仕様変更は◯回まで無料」「軽微な修正の定義」など、どんな場合に増額されるかが契約条件に含まれている。 | 変更時のルールが一切書かれていない。開発終盤での追加請求の余地が意図的に残されている。 |
| マイルストーン | 最終納期だけでなく、中間成果物の確認タイミングがスケジュールに組み込まれている。 | 「納品日」しか書かれていない。途中経過を見せる設計になっていない。 |
| 保守・契約不適合責任 | 納品後の保守体制・費用と、契約不適合責任（不具合を知ってから1年以内が追及期間）の扱いが記載されている。 | 納品後のことが一切書かれていない。「作って終わり」を前提とした構成。 |
※見積書は「価格」ではなく「透明性」を見る。ブラックボックス化している項目は遠慮なく質問し、回答の誠実さで会社を判断する。
認知科学：質問への「反応」が最大の情報源
見積書の内容以上に情報量が多いのが、「質問したときの反応」だ。認知科学の知見では、人は準備された説明よりも、想定外の質問への即応にその実力と誠実さが表れる。
「この工数の根拠を教えてください」「2人で3ヶ月ではなく1人で6ヶ月なのはなぜですか」と質問してみる。良い会社は具体的な作業分解で答える。危ない会社は「経験上そうなります」「弊社の標準です」と抽象論で逃げる。質問への回答が具体的か抽象的か——これが最も確実なリトマス試験紙だ。
第4章：発注前にやるべき防衛5ステップ
危ない会社を「見抜く」だけでは不十分だ。良い会社と組んでもトラブルは起きる。認知科学の「チェックリスト効果」を使い、発注前の防衛手順を型にする。
図3｜発注前の防衛5ステップ
| STEP | やること | 具体的なアクション |
|---|---|---|
| 1 | RFP（提案依頼書）を作る | 目的・解決したい課題・対象業務範囲・必須機能・予算・希望納期を1枚にまとめる。複数社を同一条件で比較でき、「言った言わない」の予防になる。AIに骨子を作らせれば1時間で完成する。 |
| 2 | 3社以上から相見積もり | 同一のRFPを3社以上に提出。金額の比較ではなく「内訳の透明性」「質問への回答の具体性」「やらないことの明記」を比較する。極端に安い1社はアンカリングの罠と疑う。 |
| 3 | 評価を点数化する | 技術力・PMの質・提案の具体性・保守運用体制・価格の透明性の5項目を各10点で採点する。感覚ではなく数字で比較することで、「安さ」に引きずられる認知バイアスを排除できる。 |
| 4 | 契約書の4点を確認 | 「仕様変更のルール（承認・見積・納期の3点セット）」「検収基準（何をもって完成か）」「再委託の可否と範囲」「契約不適合責任の期間」。この4点が書面にあるかを確認。なければ追記を要求する。 |
| 5 | 撤退条件を先に決める | 「マイルストーン2回連続遅延で中止検討」など、続行/中止の判断基準を契約前に社内で決めておく。サンクコスト効果で撤退できなくなる前に、冷静な自分が基準を作っておく。 |
第5章：AIを「発注者側の武器」にする
IT知識の非対称性——開発会社は技術を知っており、発注者は知らない——が、危ない会社に付け込まれる根本原因だ。2026年、この非対称性はAIでかなり埋められる。
① 見積書をAIに精査させる： 受け取った見積書の内容（社名等は伏せる）をClaudeやChatGPTに貼り付け、「この見積もりの内訳で曖昧な項目、相場から外れた単価、後から追加請求される余地がある箇所を指摘して」と依頼する。専門家の視点での一次チェックが数分で得られる。
② 質問リストを作らせる： 「この見積書について、開発会社に確認すべき質問を10個作って。特に追加費用のリスクと対応範囲の曖昧さを重点的に」と指示する。商談の場で「鋭い発注者」として振る舞える。これ自体が悪質な会社への抑止力になる。
③ RFPの叩き台を作らせる： 「在庫管理システムを外注したい。業種は◯◯、従業員◯名、予算◯万円。開発会社に渡すRFPを作って」と入力すれば、要件の抜け漏れが少ない依頼書の骨子ができる。RFPの質が上がれば、見積もりの精度も上がる。
④ 契約書のリスク箇所を洗い出させる： 契約書ドラフトをAIに読ませ、「発注者に不利な条項、記載が欠けている重要事項を指摘して」と依頼する。最終判断は弁護士に委ねるべきだが、事前スクリーニングとして極めて有効だ。
第6章：成功者の思考パターン——「良い客」になることが最大の防衛
危ない会社を避けるだけでなく、良い会社に選ばれる
見落とされがちな真実がある。優良な開発会社ほど、客を選んでいる。要件が曖昧で、丸投げ体質で、決定が二転三転する発注者は、良い会社から敬遠され、結果として「どんな客でも受ける会社」——つまり危ない会社としか出会えなくなる。
失敗の4大原因は「要件定義の曖昧さ・コミュニケーション不足・プロジェクト管理の甘さ・ベンダー丸投げ」であり、半分は発注者側に起因する。RFPを用意し、議事録を確認・署名し、意思決定を迅速に行う発注者は、良い会社にとって「組みたい客」になる。
「信頼の構築」は記録から始まる
行動経済学のゲーム理論が示すように、継続的な関係では「裏切りにくい構造」を作ることが双方の利益になる。議事録を双方が確認・署名する習慣、仕様変更を書面で残す運用、プロトタイプで「動くもの」ベースの認識合わせ——これらの記録文化は、相手を疑うためではなく、誠実な会社が誠実に働ける環境を作るためにある。危ない会社はこの文化を嫌って自然に離れていく。記録の徹底こそが、最も上品で最も強力なフィルターなのだ。
まとめ：今日から動ける3つのアクション
アクション1（見積もりを受け取ったら即日）： 見積書の中の「一式」の数を数える。3つ以上あれば、全項目の内訳開示を要求する。回答の誠実さがその会社の本性だ。
アクション2（商談前日まで）： AIに見積書を精査させ、質問リスト10個を用意して商談に臨む。「工数の根拠」「含まれないもの」「変更時のルール」の3つは必ず聞く。
アクション3（契約前）： 「仕様変更ルール・検収基準・再委託の範囲・契約不適合責任」の4点が契約書にあるか確認し、なければ追記を要求する。あわせて撤退条件を社内で決めておく。
危ないシステム開発会社は、見積書と質問への反応に必ず本性を表す。そして、記録を徹底し、要件を明確にし、AIで知識の非対称性を埋める発注者には、危ない会社のほうから寄ってこなくなる。見抜く技術と、選ばれる姿勢——この両輪が、あなたの会社の投資を守る。
データ出典：ITトレンド「システム開発の見積もり徹底解説」・発注ラウンジ・Incubation Base「システム開発の失敗事例と訴訟リスク」・アイシア法律事務所・各社公開情報（2025〜2026年）。契約に関する最終判断は必ず専門家（弁護士等）にご相談ください。
タグ： システム開発 | 外注 | 見積書 | ベンダー選定 | 発注 | RFP | 契約トラブル | AI活用 | 行動経済学 | リスク管理
