著者: 野原琉海(業務効率化に特化したエンジニア)
エンジニアがこんなことを言うのは矛盾に見えるかもしれない。ただ、これが本音だ。
「業務に合ったシステムを自社で作りたい」「既存ツールだと痒いところに手が届かない」。その気持ちは分かる。でも、中小企業が社内システムを自作するのは、ほぼ全てのケースで間違いだと思っている。
業務効率化に特化したエンジニアとして顧問先の現場を見てきた経験から言うと、自社システムを作ったことで逆に業務が止まった会社、エンジニアが疲弊した会社、数百万円かけたシステムが3年後に「誰も使わないツール」になった会社を複数見てきた。
この記事では、中小企業が社内システムを作らない方がいい理由を具体的なコストと事例で整理する。また、本当に作るべき唯一のケースの判断基準も書く。
社内システムを作ると「本当のコスト」はいくらか
「システムを作る費用」というと、多くの人は開発費だけを想像する。でも実際のコストはそれだけではない。
初期開発費の現実
中小企業向けの業務システム(受発注管理・在庫管理・顧客管理など)の開発費用は、機能の規模によって大きく異なる。システム開発の外注で失敗するパターンと回避策でも触れているが、「簡単なシステムだから安く作れる」という前提は危険だ。
| システムの種類 | 開発費用の目安 |
|---|---|
| シンプルな受注管理(入力・一覧表示のみ) | 50万〜150万円 |
| 請求書自動生成・PDF出力あり | 150万〜300万円 |
| 在庫管理+発注管理の連携 | 200万〜500万円 |
| 勤怠管理+給与計算連携 | 300万〜600万円 |
この費用は開発のみの金額だ。ここに毎年かかるメンテナンス費用が加わる。
見えにくい「年間維持コスト」
ソフトウェア開発の業界では、年間保守費用は開発費の20〜30%が相場とされている。200万円で作ったシステムなら、年間40万〜60万円の維持コストがかかる計算だ。
この維持コストの内訳を整理すると、こうなる。
| コストの種類 | 内容 | 発生頻度 |
|---|---|---|
| セキュリティパッチ対応 | 脆弱性が発見された際の修正 | 年3〜6回程度 |
| ライブラリ・フレームワーク更新 | 使用技術のバージョンアップ | 年1〜2回 |
| 法改正対応 | 税率・制度変更に合わせた仕様変更 | 不定期(最近は毎年のように発生) |
| バグ修正 | 利用中に見つかる不具合の修正 | 随時 |
| ブラウザ・OS対応 | Chromeのアップデート等で動作が変わる | 年1〜3回 |
5年間の総コスト比較
この維持コストを5年間で計算すると、SaaSとの差が明確になる。
| 自社システム(開発費200万円の場合) | SaaS(月額5,000円の場合) | |
|---|---|---|
| 初期費用 | 200万円 | 0円(または年額契約で数万円) |
| 年間維持費 | 40万〜60万円 | 約6万円 |
| 5年間の総コスト | 400万〜500万円 | 約30万円 |
5年間で比べると、自社システムはSaaSの10倍以上のコストがかかる。これは「似た機能のSaaSが存在する場合」の比較だ。
自社では月3.5万円のクラウドツール代(ChatGPT Plus・クラウド会計・ストレージ等)で、経理・請求処理・コンテンツ制作・顧客管理を回している。システムを自作していたら、同じ業務をこの費用では実現できなかった。
作った瞬間から始まる「メンテナンスの現実」
システムは作って終わりではない。作った瞬間から、メンテナンスが始まる。
セキュリティの問題は永遠に続く
ウェブシステムには、定期的にセキュリティの脆弱性が発見される。発見されたら即対応が必要だ。対応が遅れると、情報漏洩やシステム改ざんのリスクになる。
2021年末に発見されたLog4Shell(Log4jライブラリの脆弱性)は、世界中の無数のシステムに影響を与えた。利用企業はゼロデイ(脆弱性発見当日)対応を迫られた。SaaSの場合、ベンダーが即対応する。自社システムの場合、自社でエンジニアを手配して対応するしかない。
法改正への対応が毎年のように発生している
ここ数年、中小企業に影響する法改正が立て続けに発生している。
- 2022年1月: 電子帳簿保存法の改正(電子データ保存の要件が大幅変更)
- 2023年10月: インボイス制度開始(請求書フォーマットに適格請求書番号の記載が必要に)
- 2024年1月: 電子帳簿保存法の猶予措置終了
freeeやマネーフォワードのようなSaaSクラウド会計は、法改正のたびにシステムを自動でアップデートする。ユーザーは何もしなくていい。
自社で作った請求書システムだったら、インボイス制度対応のために別途改修が必要だ。その費用は自社負担になる。「法改正対応で追加費用が50万円かかった」という話を実際に聞いている。
「放置システム」が生まれるまでの典型的な経緯
僕が実際に見てきた「放置システム」ができるまでのパターンがある。
- 担当エンジニアが退職・異動する
- システムの仕組みを知っている人間がいなくなる
- 小さな不具合が発生しても誰も直せない
- 「何かあったら困るから使い続けるしかない」状態になる
- 新しいSaaSを導入しても旧システムとの並行運用が始まり、二重管理になる
このパターンに陥った会社で、最終的に「旧システムは触らないようにしている」という状態になっているのを見たことがある。開発費に数百万円かけたシステムが、実質的に「怖くて改修できない遺産」になっている。
SaaSは競争原理で勝手に良くなる。自社システムは違う
ここが最も伝えたい話だ。
freee・マネーフォワード・SlackのようなSaaSには、競合が存在する。競合に負けないために、各社が自分たちのプロダクトを絶え間なく磨き続けている。
- 新機能が毎月のように追加される
- UIが改善される
- セキュリティが強化される
- 法改正に自動で対応する
- サポート体制が継続的に改善される
これをユーザーは月額数千円で受け取り続ける。
自社システムは違う。機能を追加したければ、エンジニアに依頼して追加費用を払う必要がある。UIを改善したければ同様だ。放置していれば、競合他社が使っているSaaSがどんどん良くなる中、自社システムは同じ状態で取り残される。
SaaS vs 自社システムの項目別比較
| 項目 | SaaS | 自社システム |
|---|---|---|
| 機能の改善 | ベンダーが継続的に対応 | 自社でエンジニアを手配して費用を払う |
| セキュリティ対応 | ベンダーが即対応 | 自社で対応(遅延リスクあり) |
| 法改正対応 | 多くの場合自動対応 | 自社で改修費用を負担 |
| 初期費用 | 0〜数万円 | 数百万円 |
| 月額費用 | 数千〜数万円 | 維持費として月数万〜数十万円 |
| 障害時のサポート | ベンダーのサポートが動く | 自社でエンジニアを手配 |
| 機能拡張の柔軟性 | ベンダーのロードマップ次第 | 自由だが都度費用が発生 |
「SaaSだと自社の業務に合わない部分がある」という声は理解できる。ただ「5%合わないから全部自作する」という判断が合理的かどうかは別の話だ。SaaSが持っている90%以上の機能と、継続的な改善・サポートを手放す理由になるかを冷静に判断してほしい。
「うちの業務は特殊だから」は本当か
「うちの業務は特殊で、既存ツールでは対応できない」という話を何度も聞いてきた。
正直に言う。この「特殊」の実態を確認すると、多くの場合「業務フローが整理されていないだけ」だ。
業務フローの整理不足が「特殊性」に見える
例えばこんなケースがあった。「受注から請求書発行までの流れが複雑で、既存ツールでは対応できない」という相談を受けた。実際の業務フローを確認すると、以下の状態だった。
- 受注の管理はExcelのシートA
- 在庫確認は別のシートB
- 請求書はWordのテンプレートを毎回コピーして手直し
- 入金確認はメールをBCCで別アドレスに転送して手動でスプレッドシートに入力
このフローが「特殊」なのではなく、「複数の非効率な手作業がバラバラに積み重なっている」状態だった。クラウド会計・受発注管理ツールを組み合わせれば十分対応できる内容だった。問題は「うちの業務が特殊」ではなく、「業務フローを整理したことがなく、その複雑な現状に合わせてシステムを作ろうとしている」ことだった。
業務フローを整理してから判断する手順
社内システムを検討する前にやるべきことがある。
- 「今やっている作業の手順」を全部紙に書き出す
- その手順の中で「毎回同じことをやっている」ステップを洗い出す
- その繰り返し作業が、既存のSaaSで代替できるかを確認する
業務効率化は何から始める?最初の一歩を具体的に解説でも書いているが、業務フローを整理せずにツールやシステムを検討しても、問題の本質には対処できない。
既存ツール+小さなカスタマイズで済む場合
本当に既存SaaSで対応できない部分がある場合でも、「全部自作する」ではなく「既存ツール+小さなスクリプトで補完する」を先に検討してほしい。
例えば、クラウド会計から特定フォーマットのCSVを出力したい、という場合。会計ソフト自体を自作するのではなく、会計ソフトからのエクスポートデータを変換するスクリプト(数万円で作れる)を追加するだけで解決できることが多い。
それでも自社システムを作るべき唯一のケース
全否定するつもりはない。自社システムを作るべきケースは確かにある。
ただし条件は1つだけだ。「技術(システム)が事業の核になる会社」のみだ。
作るべきかどうかの判断チェックリスト
以下の全てに「Yes」と答えられる場合のみ、自社システムを作ることを検討してよい。
- システム自体が顧客に提供する価値の中心になっているか
- 既存SaaSを10社以上調査した上で、全て要件を満たせないと判断したか
- 社内に継続的にメンテナンスできるエンジニアがいるか(外部委託ではなく社員)
- 5年間の開発・維持費用を試算した上で、ROIがプラスになる確信があるか
- 法改正が発生した際に即対応できる体制があるか
1つでも「No」があれば、まずSaaSか「SaaS+小さなカスタマイズ」で対応できないかを徹底的に探すべきだ。
バックオフィス効率化目的なら作る必要はない
「経理を効率化したい」「受発注管理を改善したい」「問い合わせ対応をまとめたい」という目的なら、市場に十分なSaaSが揃っている。
| 業務 | 利用できるSaaSの例 | 月額費用の目安 |
|---|---|---|
| 会計・経理 | freee、マネーフォワード | 2,000〜8,000円 |
| 受発注管理 | Zoho CRM、HubSpot | 無料〜数千円 |
| 問い合わせ管理 | HubSpot、Freshdesk | 無料〜数千円 |
| 勤怠管理 | ジョブカン、freee人事労務 | 数百〜数千円/人 |
| プロジェクト管理 | Notion、Asana | 無料〜1,000円/人 |
この表にある業務のために自社システムを作ることは、費用対効果の観点から合理的ではない。中小企業の業務効率化ツール10選|目的別の選び方ガイドでもツール別の特徴を整理しているので、参考にしてほしい。
まとめ:「作らない」が最も合理的な選択
中小企業が社内システムを自作すべきでない理由を整理する。
- コスト: SaaSの10倍以上のコストがかかる(5年間の総コスト比較)
- メンテナンス: セキュリティ・法改正・バグへの対応が永続的に続く
- 進化しない: SaaSは競争原理で勝手に良くなるが、自社システムは費用をかけないと改善できない
- 特殊性の誤解: 「業務が特殊」の多くは「業務フローが整理されていないだけ」
- 作るべきケース: 技術が事業の核になる会社だけ
エンジニアとして、「作れるから作る」ではなく「作る必要があるから作る」という判断が重要だと思っている。バックオフィス業務のために数百万円のシステムを作るより、同じ予算を本業の成長に使う方が合理的だ。
まず手元の業務フローを紙に書き出して、既存SaaSで対応できないかを確認するところから始めてほしい。判断に迷う場合はデジタルツール導入で失敗する4つのパターンと対策も参考になる。