中小企業の基幹システム選び方｜SaaS・パッケージ・カスタム開発の判断軸
中小企業の基幹システム選びで、SaaS（kintone・freee）、国産パッケージ（OBIC・GLOVIA・奉行）、カスタム開発のどれを選ぶか。業種・規模・業務特性ごとの向き不向き、内製の罠、ベンダーロックインの考え方を解説します。
「kintoneとOBICとカスタム開発、どれにすべきですか？」
これも頻出の質問だ。答えは「業務によって違う」と言いたいところだが、それでは判断材料にならない。実際には、3つの選択肢には、それぞれ向く会社・向かない会社のパターンがある。
中小企業の基幹システム選びは、選定を間違えると、5年〜10年単位で会社の生産性に響く。本記事では、SaaS・パッケージ・カスタム開発の3つの選択肢について、現場で繰り返し相談される視点から判断軸を整理する。
3つの選択肢の特徴
まずは、それぞれの特徴をざっくり押さえる。
SaaS（クラウド型業務システム）
代表的なものに、kintone、freee、マネーフォワード、Salesforce、Microsoft Dynamics 365、BoxRなどがある。月額課金で、サーバー管理が不要。すぐに使い始められる。
向く会社: 業務がそこまで特殊でない、社員数が少なめ（〜100人）、IT人材がいない、初期投資を抑えたい。
向かない会社: 業務に強い独自性がある、データ量が膨大、SaaS の制約に業務を合わせられない。
国産パッケージ
OBIC（オービック7）、GLOVIA（富士通）、SMILE（大塚商会）、奉行シリーズ（OBIC8）など。中堅・中小企業向けに作られた、買い切り型または保守契約型のシステム。
向く会社: 中堅規模（年商10〜100億円）、業務が標準的、データ量が多い、業界に応じた機能が欲しい（製造業向け、卸売業向けなど）。
向かない会社: 既製の機能枠を超えた要件がある、SaaS的な低コスト運用を求めている。
カスタム開発
ゼロからシステムを開発する、または既存システムに大幅なカスタマイズを加える。Webアプリケーションフレームワーク（Ruby on Rails、Laravel、Next.js等）で構築するのが主流。
向く会社: 業務に強い独自性がある、競争力の源泉が業務システムにある、長期運用を前提に内部資産化したい、それなりの予算とプロジェクトマネジメント体制がある。
向かない会社: ITリソースが薄い、要件が曖昧、開発側に依存しすぎる体制になりがち。
業種・規模別の向き不向き（私の現場感覚）
具体的にどの会社にどれが向くかを、私の現場感覚で整理する。これは絶対の正解ではないが、中小企業の相談に乗ってきた経験からの一般傾向だ。
製造業（社員50〜150人）
- 生産管理 + 在庫管理 + 受発注を統合したい場合、国産パッケージ（GLOVIA、A's-PROなど）が無難
- 業務に強い特殊性がある場合（例: 多品種少量、特殊な製造工程）、カスタム開発の選択肢が出てくる
- SaaSだけで完結させるのは厳しい（生産管理SaaSの完成度がまだ低い）
卸売業・商社（社員30〜100人）
- 受発注・在庫・販売の標準的な業務なら、kintone + freee の組み合わせで結構いける
- 取引先からEDI連携を求められる場合は、パッケージの方が無難
- カスタム開発は、独自の値付けロジックや与信管理がある場合のみ
サービス業（社員20〜80人）
- 顧客管理 + プロジェクト管理 + 請求は、SaaS（Salesforce + freee + プロジェクト管理SaaS）の組み合わせが多い
- パッケージは選択肢が少ない（サービス業向けの国産パッケージは限定的）
- カスタム開発は、業務特化型のWebサービスを作る場合
建設業（社員30〜200人）
- 業界特化型のパッケージ（PROCES.S、BIM-FM、CIVILなど）が強い
- 汎用 SaaS だけでは賄えない要件が多い（工事原価管理、出来高管理など）
- カスタム開発は、大規模建設業の管理に限定
アパレル・小売業（社員30〜100人）
- 私のアパレル時代の経験で言うと、ZAITEN、CUBE、TFLEX などの業界特化パッケージが強い
- SaaSのShopify、BASE、STORESを活用したD2Cの仕組みも増えている
- カスタム開発は、ブランド独自の在庫管理ロジック・需給調整がある場合
内製の罠｜「うちで作ろう」が地雷になりやすい理由
中小企業の経営者から、「うちで作ろうかと思って」という相談を受けることがある。社内に若手エンジニアが入った、社長自身がシステムに詳しい、SIerに高い見積もりを出された、などの背景で出てくる話だ。
結論から言うと、基幹システムの内製はおすすめしない。理由は3つある。
理由1: 開発と運用は別の専門性
「作る」ことができる人材と、「長期運用する」人材は別だ。1〜2人で開発したシステムは、その人が辞めると保守できなくなる。中小企業で複数のエンジニアを継続雇用するのは現実的に難しい。
理由2: 業務知識と技術知識の両立が稀
良い基幹システムを作るには、業務をよく分かる人と、技術をよく分かる人の両方が必要だ。中小企業の社内に両方揃うことは稀で、片方欠けたまま作ると、機能不足か技術負債のいずれかに陥る。
理由3: 5年後の総コストが見合わない
「内製の方が安い」という前提で始めても、5年単位で計算すると、SaaSやパッケージの方が圧倒的に安く済むケースが多い。エンジニアの人件費、機能追加の工数、サーバー運用コスト、これらを積み上げると、初期は安くても、ランニングが重い。
唯一例外があるとすれば、業務システムが会社の競争力の源泉そのものである場合。例えば、独自の需給調整ロジックや、独自のマッチングアルゴリズムが、ビジネスの差別化要因になっている会社。これは内製化する価値がある。
ベンダーロックインの考え方
「ベンダーロックインが怖い」と言う経営者は多い。確かに、特定のベンダーに依存しすぎると、そのベンダーが事業撤退したり、保守費を上げたりしたときに、対応が難しくなる。
ただし、ロックインを完全に避けようとすると、コストが膨らむ。データのオープンフォーマット保管、複数ベンダー前提の設計、ベンダー切り替え可能な抽象化レイヤー、これらをすべて入れると、システム構築費が1.5〜2倍になる。
中小企業のリアルな判断としては、
- 主要ベンダーに依存することは受け入れる
- ただし、「データはいつでもエクスポートできる」「移行のための仕様書は手元にある」という最低限の備えはする
- 5〜7年に一度は基幹システムを入れ替える前提で、組織の体質を作る
これくらいの現実主義が、コストパフォーマンス的に合っている。
ハイブリッド構成という選択肢
最近増えているのが、「全てをひとつのシステムに集約しない」ハイブリッド構成だ。例えば、
- 会計: freee または マネーフォワード（SaaS）
- 販売・受発注: kintone（SaaS）
- 在庫・生産: 国産パッケージ
- 顧客管理: Salesforce（SaaS）
- 特殊業務: カスタム開発（小規模Webアプリ）
これらを API・iPaaS（Zapier、Make、launchctl）で連携する形だ。
メリットは、領域ごとに最適なツールを選べること、それぞれが進化していくこと、特定ベンダーへの依存度を分散できること。
デメリットは、連携の運用が複雑になること、データの整合性管理が大変になること、トラブルシューティングの切り分けが難しいこと。
私の感覚では、社員30〜80人の中小企業にハイブリッド構成は向いている。それより大規模になると、統合パッケージかカスタム開発の方が運用が楽になる。
失敗しないベンダー選定の進め方
選定の進め方として、3〜5社のベンダーから提案を取るのが基本だ。RFP（提案依頼書）を作って配布し、提案を受け、デモを見て、価格交渉をする。
ここで現場でよく見るのが、「営業がうまいベンダーに引っ張られる」失敗だ。提案資料の見栄えやプレゼンの巧さで判断すると、実際の運用フェーズで「こんなはずじゃなかった」となる。
私が伴走するときに必ず確認しているのは、次の3点だ。
- 同規模・同業界の導入実績を3件以上: 名前を伏せた状態でいいので、実際の使われ方の話を聞く
- 保守チームの体制: 営業ではなく、実際にトラブル対応する技術者の体制を確認する
- 5年後の運用コスト想定: 初期費用だけでなく、保守費・追加開発費・データ容量増加費を含めた5年シミュレーション
この3点で誠実に答えてくれるベンダーは、運用フェーズでも信頼できる。逆に、初期費用ばかりアピールするベンダーは、選定段階で外す方が無難だ。
関連する記事
LAVRA WORKS は、中小企業の基幹システム選定の伴走支援を行っている。特定ベンダーに偏らない立場で、御社の業務・規模・予算に合ったシステム構成をご提案する。「ベンダーから提案を受けたが、判断が難しい」という段階でも歓迎だ。
Related