【制作会社は必読】ものづくり補助金で黒字倒産した実例|月10万円で90%開発の地獄

【Web制作会社は必読】ものづくり補助金で黒字倒産した実例|月10万円で90%開発の地獄Webマーケティング

「補助金案件なら、予算が潤沢で利益が出る」
「大規模開発の実績にもなるし、一石二鳥だ」

もしあなたが、Web制作会社やシステム開発会社の経営者、あるいはディレクターで、そう考えているなら、一度立ち止まってください。

私はかつて、ものづくり補助金を使った大規模システム開発案件を主軸にしていた制作会社で働いていました。
帳簿上は「過去最高売上」。
にもかかわらず、その会社は3年後に黒字のまま倒産しました。

なぜ、国が支援する制度を使って「売上があるのに会社が潰れる」のか。
この記事では、補助金案件が制作会社をどう破滅させるのか、実体験をもとに包み隠さずお伝えします。

誤解しないでください。
この記事は、補助金を全否定するものではありません。
ただ、「補助金を使うなら、これだけは理解して備えろ」ということです。


まず確認してください。こんな光景に心当たりはありませんか?

  • ディレクターがメールやチャットワーク、Slackなどの通知を見ただけで深くため息をつく
  • マニュアル担当が「また直すんですか…」と呟く
  • 社長が、営業や資金繰りではなく、深夜に一人でコードを直している

一つでも心当たりがあれば、あなたの会社はすでに「補助金案件の罠」に片足を突っ込んでいます。


スポンサーリンク

補助金案件で制作会社が倒産する5つの理由

補助金案件で制作会社が倒産する5つの理由

① 「完成度10%」で納品せざるを得ない技術的地獄

補助金案件には、絶対に動かせない「事業完了期限」があります。
しかし、数千万円規模の複雑なスクラッチ開発を、限られた期間で”理想通り”に完成させることは、現実的に不可能です。

そこで現場で起きるのが、
「検査を通すためだけの、”表面的には完成している” ハリボテ(内部完成度10%)のリリース」
これが、すべての地獄の始まりです。

突貫開発が生む「技術的負債」

画面はあり、正常な手順なら動く。
しかし、エラー処理、セキュリティ、大量データの負荷テストなどは一切されていない。
「検査員に見せるルートだけは動く」という、砂上の楼閣です。

この前提で作られたコードは、継ぎ接ぎだらけのスパゲッティ構造になります。
その後、本来の仕様に近づけようとすると、

  1. 最初のコードが邪魔をする
  2. 修正が修正を呼ぶ
  3. 結局、作り直した方が早い

二度手間・三度手間が常態化し、エンジニアの士気は確実に削られていきます。

② 「金は払った」と勘違いするクライアントの暴走

補助金案件の最大の恐怖は、クライアントとのパワーバランスが壊れることです。
クライアント側の心理は、こうなります。

補助金で予算は確保している(もう払っている)。だから、要望は全部通るはずだ

無限に増える「ついでにやって」

「これも補助金の範囲でしょ?」
「ついでにここも直して」
「せっかくだから、この機能も追加で」
本来の契約範囲を超えたスコープクリープ(仕様膨張)が、善意と無知の顔をして襲ってきます。

ディレクターはサンドバッグになる

  • バグ報告
  • 使いにくいという不満
  • 追加要求

すべての矢面に立たされるのがディレクターです。
しかし会社としては「補助金案件だから」「角が立てられない」という弱みを抱え、要求を断れない。
結果、想定していた利益率は、音もなく消えていきます。

③ マニュアル地獄:生産性ゼロの賽の河原

未完成のシステムが、継ぎ接ぎでアップデートされ続けると、何が起きるか。
そう、マニュアルが死にます。

  • 先週作ったマニュアルが今週使えない
  • 画面が変わるたびに修正
  • 説明資料も作り直し

マニュアル担当やアシスタントは、「価値を生まない修正作業」を延々と続けることになります。
このフェーズに入ると、組織の疲労は一気に表面化します。

④ 「手伝いたくても手伝えない」セキュリティと属人化の罠

プロジェクトが炎上すれば、本来は人を増やして乗り切りたい。
しかし補助金案件の大規模システムでは、それができません。

  • 仕様書が存在しない
  • 社長 or エースエンジニアが突っ走る
  • 設計書は未整備
  • 属人化したコードだけが存在する

ヘルプに入ったエンジニアは、解読不能なコードを一行ずつ読むところからスタート。
結果、「触ると壊しそうで何もできない」という最悪の状態になります。

個人情報とセキュリティの壁

さらに追い打ちをかけるのが、「個人情報の壁」です。
補助金対象となる大規模システムは、顧客情報や予約データなど重要情報を扱います。

当然、セキュリティ要件は厳しくなります。
アクセス権限を付与するだけでも申請が必要ですが、その手続きをする時間すら惜しいほどのデスマーチです。

結果、
「アクセス権を持つ数人だけが過労死寸前で働き、周りの社員は手伝いたくても手伝えない」
という、組織としての機能不全が起こります。

⑤ 営業停止→キャッシュ枯渇→黒字倒産へ

最大の悲劇は、ここです。
社長が現場に張りつき、営業が止まる。

  • 新規問い合わせに対応できない
  • 既存顧客のフォローができない
  • 次の提案が一切生まれない

半年後に訪れる「キャッシュの空白」

営業を止めたツケは、すぐには来ません。
しかし半年後、確実にこうなります。

「あれ…来月の入金がない?」

補助金案件の売上は、すでに人件費として消えています。
残るのは、

  • 案件がない
  • 社員が疲弊して辞めていく
  • 売上の見込みがゼロ

こうして会社は、黒字のまま資金ショートし、倒産しました。


【実録】ものづくり補助金3,000万円案件で起きた倒産の全記録

私が在籍していた制作会社の実例です。
数字は、業界でよくある「補助率2/3」のケースでリアルに算出しています。

お金の流れ(クライアント vs 制作会社)

まず、このプロジェクトがどうやって成立したかを見てください。
クライアントは「3,000万円払っても、後で2,000万円(2/3)戻ってくるから実質1,000万円だ」と考えて発注します。

では、制作会社の懐事情はどうなるでしょうか。

項目金額備考
① 売上(入金)+3,000万円クライアントから全額入金
② コンサル・マージン▲500万円採択支援担当者への謝礼・紹介料
③ 初期外注費・サーバー費▲200万円突貫工事のための外部パートナー費など
④ 手元に残るお金+2,300万円これが「利益」だと錯覚する

なぜ「2,300万円」も残って倒産するのか?

社長は思います。
「原価もほとんどかからず、2,300万円も儲かった!すごい利益率だ!」

しかし、これは「利益」ではありません。
これから始まる地獄の3年間の開発を支える「人件費(固定費)」そのものです。
しかも、このチームはこの案件にかかりきりになるため、3年間「他の売上」を作れません。

本当の収支計算(3年間)

この案件を回すために、最低でもエンジニア2名、ディレクター1名が張り付きになると仮定します。

項目計算式金額
手元の資金上記④より+2,300万円
1年目の人件費チーム人件費(月150万×12ヶ月)▲1,800万円
残金(1年目終了時) 残り 500万円
2年目の人件費開発継続(月100万×12ヶ月)▲1,200万円
収支(2年目終了時) ▲700万円(赤字転落)
3年目の人件費泥沼修正(月80万×12ヶ月)▲960万円
最終赤字額 ▲1,660万円

結論:
最初に2,300万円あっても、固定費(人件費)であっという間に溶けます。
こうして、帳簿上は黒字(最初の売上がデカいから)なのに、銀行口座の現金だけが尽きていき、3年後に倒産しました。


なぜ誰も止められなかったのか?

全員が「正しい」と思っていた

  • 発注者: 「補助金が出たから問題ない」
  • 制作会社: 「大型案件を途中で投げ出せない」
  • 銀行: 「初年度は好調だから融資継続」
  • 社長: 「ここで諦めたら全てが無駄になる」

→ 全員が正常性バイアスに陥っていた

構造的な問題

  1. 補助金の「前払い(に見える)」錯覚
    • 発注者は「もう払った」と思い込む。実際は完成していないのに心理的に優位に立つ。
  2. 契約書の不備
    • スコープが曖昧。追加開発の費用負担が明記されていない。
  3. 資金繰りの甘さ
    • 初年度の「見かけの粗利」に騙される。翌年以降のキャッシュフロー(固定費の流出)を予測していない。
  4. 属人化とセキュリティの壁
    • 社長・エースエンジニアしか触れないシステム。撤退も引き継ぎもできない。

補助金案件を受けるなら、最低限これだけは守れ

前提:あなたの会社に以下の体制がありますか?

  • 社長が現場に入らなくても回る開発体制
  • 営業担当が別にいる(社長が営業停止しても大丈夫)
  • 6ヶ月〜1年、売上ゼロでも耐えられるキャッシュ
  • スコープを守り切る交渉力
  • 契約書を精査できる法務知識

1つでも欠けているなら、補助金案件は受けるべきではありません。
でも、どうしても受けるなら――以下の4つの鉄則を守ってください。

鉄則1:契約書に「スコープ凍結条項」を必ず入れる

具体的な文言例:

本契約における開発範囲は、別紙仕様書に記載された内容に限定される。
発注者からの追加機能・仕様変更の要望については、別途見積もりの上、追加契約とする。
なお、補助金申請の都合による仕様変更についても、本条項の例外とはならない。

ポイント:

  • 「補助金だから」という例外を作らない
  • 追加開発は必ず別契約にする

鉄則2:「完成検査」と「本稼働」を明確に分ける

補助金の検査通過 ≠ システムの完成

契約書に明記すべき内容:

  • フェーズ1: 補助金検査用の最小機能実装(MVP)→ここまでが初期契約
  • フェーズ2: 本稼働に向けた追加開発 → 別途契約

重要:
フェーズ2の見積もりと契約を、フェーズ1の段階で必ず取り交わしておく。

鉄則3:月額保守費は「開発継続費」として設定する

  • ❌ NG: 月額10万円(保守・運用)
  • ⭕ OK: 月額50万円〜(継続開発・保守含む)

最初から「保守費=開発費の一部」として契約設計。

具体例:

補助金検査通過後の追加開発・機能改善について、月額○○万円の継続開発契約を締結する。
本契約期間:検査通過日より24ヶ月間

鉄則4:社長は絶対に手を動かさない

ルール:

  • 社長がコードを書いたら、その案件は失敗
  • 社長の仕事は、営業・資金繰り・契約交渉のみ
  • 技術的な火消しは、エースエンジニアに任せる

なぜか?
社長が現場に張りつくと、営業が止まる。
営業が止まると、半年後にキャッシュが枯渇する。


補助金案件を断る時の3つのトークスクリプト

パターン1:キャパシティを理由にする

「ありがとうございます。ただ現在、弊社では大型案件を複数抱えており、御社のプロジェクトに十分なリソースを割けない状況です。中途半端な対応になるよりは、最初からお断りする方が誠実だと考えております」

パターン2:専門外を理由にする

「御社の業務は非常に専門的で、弊社では十分な知見がございません。補助金案件という性質上、失敗が許されないプロジェクトだと理解しておりますので、より専門性の高い制作会社をご紹介させていただけますでしょうか」

パターン3:リスクを正直に伝える

「率直に申し上げますと、補助金案件は弊社にとってリスクが高すぎます。過去に同様の案件で資金繰りに苦しんだ事例を複数見てきました。御社との長期的な関係を大切にしたいからこそ、今回はお断りさせてください」


よくある質問(FAQ)

Q1. 補助金案件は絶対に受けない方がいいですか?
A. いいえ。
ただし、上記の「前提条件」を全てクリアしている会社のみ受けるべきです。特に、社長が営業に専念できる体制があるかどうかが最重要です。
Q2. 既に補助金案件を受けてしまいました。どうすればいいですか?
A. まず、契約書を見直してください。
スコープが曖昧な場合、今からでも「追加開発は別契約」という覚書を取り交わすべきです。発注者との関係悪化を恐れず、明確な線引きをしてください。
Q3. 月額10万円で開発を続けるのは本当に不可能ですか?
A. ほぼ不可能です。
上記の計算表の通り、年間120万円ではエンジニア1人分の人件費すら賄えません。赤字垂れ流しになるだけです。
Q4. 発注者に「もう払った」と言われたらどう対応すべきですか?
A. 「補助金の支払いと、開発費用の支払いは別です」と明確に伝えてください。
契約書に追加開発の費用負担が明記されていれば、それを根拠に交渉できます。
Q5. 制作会社が倒産したら、発注者はどうなるんですか?
A. 未完成のシステムが残り、他社への引き継ぎは困難です。
補助金の返還義務が発生する可能性もあります。つまり、発注者も大損します。
Q6. 補助金案件で成功している制作会社もいますよね?
A. はい、います。
ただし、そういう会社は必ず以下の条件を満たしています:

 

  • 社長が営業に専念できる体制
  • 契約書で完璧にスコープを守っている
  • 豊富なキャッシュフロー
  • 属人化しない開発体制
Q7. この記事で紹介された倒産事例は本当ですか?
A. はい、実体験です。
ただし、訴訟リスク回避のため、一部の数字はフェイクを入れています。構造的な問題は全て事実です。


まとめ:その利益は「命を削る価値」がありますか?

制作会社の経営者の方へ。
補助金案件は、短期的な売上を生む代わりに、会社の体力を確実に削ります。

もし受けるなら、最低限以下が必要です。

  • ✅ 完全な仕様書と契約書
  • ✅ スコープを守る覚悟
  • ✅ 属人化しない開発体制
  • ✅ 経営者が現場に張りつかない仕組み
  • ✅ 1年間売上ゼロでも耐えられるキャッシュ

それができないなら、補助金案件は「会社の寿命を縮める麻薬」です。
手を出さない判断も、立派な経営判断だと、私は思います。

*本記事の一部数字はプライバシー保護のため修正していますが、構造的な問題は全て実体験に基づいています。

コメント