ブログ

スクラッチ開発とパッケージ(SaaS)の比較:ERP・CRMの選び方

ERP・CRMはスクラッチ開発かパッケージ(SaaS)か。Excel管理の限界のサイン、6つの判断基準、ハイブリッド、MVPでの要件整理、データ移行、開発会社の選び方を解説。

成長する企業の多くは、Excel、メール、チャットグループでは事業を回しきれなくなる時期を迎えます。そこで、より難しい問いが生まれます。既製のSaaS製品を契約するのか、それとも自社の仕事の進め方に合わせてソフトウェアを開発するのか。このガイドでは、ERP、CRM、ワークフローシステムがそれぞれ何をするのか、選択肢をどう公平に比較するのか、そしてどちらを選んでもどう導入を進めるのかを説明します。

要点

ほとんどの中小企業にとって最も安全なのはハイブリッドです。会計や請求書発行のような標準的な業務には保守の行き届いたソフトウェアやSaaSを使い、自社ならではのプロセスだけを開発します。判断は6つの基準(プロセスの独自性、連携、ユーザーと権限、データの所有権、長期的なコスト、ロックイン)で行い、業務の棚卸し、MVP、段階的な展開で導入し、どの道を選んでもデータとコードが自社のものであり続けるようにしてください。

Excelやチャットでの管理が限界に来ているサイン

Excelやメッセージアプリは、複数の人が手作業で内容を合わせ続けなければ事業が回らなくなったときに破綻し始めます。典型的なサインは次のとおりです。

  • 同じデータを何か所にも入力している。 注文をExcelに入れ、次に請求書ツールに入れ、倉庫にメッセージを送る。そのうちにそれぞれの内容が食い違っていきます。
  • 誰も在庫の数字を信用していない。 売りすぎたり、思わぬ欠品が起きたり、棚卸しのたびに差異が見つかったりします。
  • 承認がチャットの中にある。 誰が値引きを承認したのかを知るために、何週間分ものメッセージをさかのぼることになります。
  • 顧客の履歴が会社から出て行く。 営業担当者が辞めると、連絡先とやり取りがその人のスマートフォンと一緒に消えます。
  • レポートの作成に何日もかかる。 手作業で集計し、マスターのExcelを理解しているのは1人だけです。
  • 誰でもすべてを見て変更できる。 原価も含めてです。しかも、誰が何を変えたかの記録がありません。

サインが1つか2つなら、適切なツールを1つ選ぶだけで済むかもしれません(Excelマクロや連携ツールの選び方は業務自動化ツールの選び方を参照)。複数が同時に当てはまるなら、通常はきちんとしたシステムを導入する時期です。

ERP、CRM、ワークフローシステム:それぞれの役割

ERPは業務とお金を、CRMは顧客と営業を、ワークフローシステムは社内の承認と連携を管理します。複数の領域をカバーする製品も多くありますが、中心となる役割は異なります。

  • ERP(統合基幹業務システム) は業務とお金を管理します。購買、在庫、受注、請求、そして多くの場合は会計、生産、複数の倉庫です。
  • CRM(顧客関係管理) は顧客と営業を管理します。連絡先、見込み客、商談パイプライン、見積もり、フォローアップ、すべてのやり取りの履歴です。
  • ワークフローシステム は社内のプロセスを管理します。購買、経費、休暇などの稟議・承認、共有文書、タスクです。Microsoft 365やGoogle Workspaceのようなスイートが、すでにその一部をカバーしています。

最も大切なのは、これらのシステムがデータを共有していることです。顧客マスターは1つ、商品リストも1つ、価格表も1つです。

3つの道:パッケージ、スクラッチ開発、ハイブリッド

道は3つあります。既製のパッケージソフトやSaaSを契約する、システムをスクラッチ開発(オーダーメイドで開発)する、あるいは両方を組み合わせたハイブリッドにする、の3つです。

パッケージソフトとSaaS。 ERPならOdooやNetSuite、CRMならHubSpotやSalesforceといった既存の製品を契約し、設定して使います。実績があってすぐに始められ、アップデートとセキュリティはベンダーが担い、通常はユーザー数やモジュール単位で料金を払います。トレードオフは、自社が製品に合わせることになり、製品のロードマップはベンダーのものだという点です。

スクラッチ開発。 開発チームが自社のプロセスに合わせてソフトウェアを作ります。業務にぴったり合い、ユーザー数ごとのライセンス料がかからず、本物の競争優位になり得ます。トレードオフは、初期投資が大きいこと、使い始めるまでの期間が長いこと、保守・セキュリティ・ホスティングの責任を負い続けることです。

ハイブリッド。 標準的な部分には標準的なソフトウェアを使い、自社が他社と違う部分だけを開発します。会計、請求書発行、給与計算は、税制や電子インボイスのルールが国によって異なり、変わり続けるため、通常は保守の行き届いた製品に任せるのが最善です。たとえばEUでは、2025年に採択されたデジタル時代のVAT(ViDA)パッケージ(英語)により、2030年7月1日から、国境を越えるB2B取引について電子インボイスに基づくデジタル報告が導入されます。その会計の中核の周りに、ECサイトとの同期、卸売顧客向けの受注ポータル、倉庫スタッフ向けのスマホアプリなどを開発する、という形です。ECサイトをShopifyなどのプラットフォームで作るか独自開発するかは、Shopify・WooCommerce・フルスクラッチの比較で解説しています。Odoo Community(LGPLv3ライセンス)やERPNextのようなオープンソースのERPはその中間に位置します。自社でホスティングして改変できますが、加えた変更はアップグレードのたびに引き継いでいく必要があります。

多くの中小企業にとって、ハイブリッドが妥当な第一候補です。

判断を決める6つの基準

スクラッチ開発かSaaSかを決めるのは、プロセスの独自性、連携、ユーザーと権限、データの所有権、長期的なコストの要因、ベンダーロックインの6つの基準です。

  1. プロセスはどれだけ独自か。 顧客ごとの価格設定や独特な生産の流れなど、それが自社の競争力の源泉なら、汎用ソフトウェアに無理に合わせると損をします。帳簿づけのように標準的な業務なら、一から作り直す必要はありません。
  2. 連携。 データをやり取りする必要があるシステムをすべて書き出します。ECサイト、ECモール、決済、配送業者、会計、銀行、Webサイトのフォームなどです。既製のコネクタや、許容できる利用上限を備えたドキュメント付きのAPIがあるかを確認しましょう。たとえばHubSpotのAPI利用ガイドライン(英語)は、非公開で配布するアプリの1日あたりのAPI呼び出し上限を契約プランごとに定めており、FreeとStarterは1アカウントあたり25万回、Professionalは62万5,000回、Enterpriseは100万回です。本当の複雑さは、連携の部分に潜んでいることがよくあります。きれいなAPIがあれば、後からAIアシスタントを接続するのもずっと簡単になります。たとえば、AIアプリケーションを外部システムに接続するためのオープンソースの標準であるModel Context Protocol(MCP)(英語)を使う方法です(当社のAI導入支援もご覧ください)。
  3. ユーザーと権限。 ユーザー数ごとの料金は、倉庫スタッフ、ドライバー、外部パートナーのように時々しか使わないユーザーがいると高くつきます。細かな権限設定(営業担当者には自分の顧客だけを見せる、一部の役割には原価を見せない)も早めに確認してください。上位プランでしか使えないSaaS製品もあります。
  4. データの所有権。 データはどこに保存され、履歴や添付ファイルも含めて、すべてを使える形式でエクスポートできるか。解約したらどうなるか。EU域内の人々の個人データを扱う場合はGDPRが適用されます。自社に代わってそのデータを扱うサービス事業者は「処理者」にあたり、欧州データ保護会議(EDPB)の中小企業向けガイド(英語)は、管理者と処理者の関係は「契約によって規律されなければならない」と述べています。この契約は通常、データ処理契約(DPA)と呼ばれます。
  5. 長期的なコストの要因。 システムを使い続ける想定期間全体の総額で比較します。SaaSのコストは、ユーザー数、追加モジュール、(API連携などの機能のための)上位プラン、更新時の価格改定とともに増えていきます。スクラッチ開発のコストは、初期開発(範囲、役割、業務ルール、連携で決まります)、ホスティング、セキュリティアップデート、新機能から生じます。どちらにも、データ移行、研修、社内チームの時間が必要です。
  6. ベンダーロックイン。 SaaSの場合のリスクは、閉じたデータ形式、値上げ、機能の廃止です。スクラッチ開発の場合は、他の誰もコードを理解できないために1つの開発会社から離れられなくなることです。どちらのリスクにも対策は同じで、検証済みの全データのエクスポート、ドキュメント、主流の技術、そして契約終了時の扱いを定めた契約です。

スクラッチ開発の要件整理:業務の棚卸し、MVP、段階的展開

スクラッチ開発のシステムは、現在の業務の棚卸し、その簡素化、MVPの定義、段階的な展開の4ステップで範囲を決めます。最も高くつく失敗は間違ったものを作ることで、この順序がそれを防ぎます。

  1. 現在の業務を棚卸しする。 1件の注文、1件の購買、1件の顧客からの問い合わせを、最初から最後まで追いかけます。管理職だけでなく実際に作業をしている人と話し、実物の注文書、請求書、Excelを集めます。要件は、例外処理や回避策の中に隠れています。
  2. デジタル化する前に簡素化する。 混乱したプロセスを自動化しても、混乱が速く回るようになるだけです。
  3. MVPを定義する。 MVP(実用最小限の製品)とは、1つの倉庫での受注、在庫更新、納品書発行のように、実際の業務の流れを1本、最初から最後まで置き換えられる最小のバージョンです。役割、権限、主要な画面、連携、そして実際に使われている数少ないレポートを書き出します。
  4. 段階的に展開する。 まずパイロットのチームや拠点で始め、見つかった問題を直してから広げます。その後の各フェーズで、購買、CRM、承認といったモジュールを追加していきます。

見積もりはフェーズごとに依頼しましょう。範囲、連携、業務ルールが費用と期間を左右するため、明確な業務の棚卸しこそが見積もりを信頼できるものにします。

データ移行と、社内への定着

スムーズなデータ移行とは、何を移すかを決め、データを整理して試験的に取り込み、決めた日に切り替えることです。定着するかどうかは、キーユーザーを巻き込み、役割ごとに研修し、新しいシステムを唯一の正しい情報源にできるかで決まります。

データ移行: 何を移すかを決めます。マスターデータ(顧客、商品、価格)、未完了の案件(注文、残高、現在の在庫)、そしてどこまでの履歴を移すかです。古い記録は読み取り専用のアーカイブに残しておけます。重複や不統一な商品コードを整理し、試験的な取り込みを実行して、倉庫ごとの在庫などの合計を旧データと照合します。そのうえで切り替え日を決め、古いツールを凍結します。

定着:

  • 各チームのキーユーザーを最初から巻き込みます。
  • 役割ごとに、チームが使う言語で書いた短いガイドを使って研修します。
  • 新しいシステムを唯一の正しい情報源にします。チャットで届いた注文もシステムに入力し、システムの外で処理しないようにします。
  • 倉庫や現場のスタッフがスマートフォンで作業できるようにします。専用アプリを作る場合の進め方はアプリ開発の流れで解説しています。
  • 最初の数週間は小さな不便をすばやく直します。それが、社員がシステムを信頼するかどうかを決めます。

開発会社の選び方と、避けたい落とし穴

開発会社は、作業範囲の決め方、使う技術、コードとアカウントの所有者、提供されるドキュメントとテスト、公開後の対応を確認して選びます。尋ねる価値のある質問は次のとおりです。

  • 機能の見積もりの前に業務の棚卸しをしてくれるか。作業をどのようにフェーズに分けるか。
  • どの技術を使うか。別のチームが引き継ぐことは可能か。
  • ソースコードは初日から自社アカウントのリポジトリに置かれ、クラウド、ドメイン、外部サービスのアカウントは自社名義になるか。
  • どんなドキュメントが提供されるか。アーキテクチャ、データモデル、APIリファレンス、デプロイ手順書、ユーザーマニュアルなど。
  • テストとバックアップはどう行い、実際に復元を試したことがあるか。
  • 公開後はどうなるか。不具合の修正、セキュリティアップデート、新機能、そして契約を終える場合の引き継ぎ。

よくある落とし穴:

  • Excelの混乱を、項目ごとにそのままソフトウェアで再現してしまう。
  • パイロットなしで、すべてのモジュールを一度に稼働させる。
  • SaaS製品を過度にカスタマイズし、ベンダーのアップデートのたびに何かが壊れる。
  • 自社のデータで試さず、洗練されたデモだけで決めてしまう。
  • 決定権を持つ社内の責任者がいない。
  • 保守の予算も、撤退の計画もない。

よくある質問

スクラッチ開発は常にSaaSより高くつきますか?

通常は初期投資が大きくなります。数年単位で見ると、比較の結果はユーザー数、システムを使う期間、それぞれの選択肢でどれだけのカスタマイズや連携が必要かによって変わります。初年度ではなく、システムを使う期間全体の総コストで比較してください。

まずSaaSで始めて、後からスクラッチ開発のシステムに移行できますか?

はい。むしろ理にかなっていることが多い方法です。SaaS製品を使うことで、本当に必要なものがわかるからです。全データのエクスポートとドキュメント付きのAPIを備えた製品を選べば、後の移行は救出作業ではなく計画的なデータ移行になります。

スクラッチ開発したシステムのソースコードは誰が所有すべきですか?

理想は自社が所有することです。少なくとも、完全なアクセス権と、利用・改変の権利を持つべきです。これを契約に明記し、コードは自社アカウントのリポジトリで管理し、別のチームが開発を引き継げる水準のドキュメントを求めてください。

ERPやCRMの導入、あるいは今あるツール同士の連携の改善を検討しているなら、当社のアプリ・システム開発サービス、業務の棚卸しやシステム選定を支援する戦略コンサルティングをご覧いただくか、お問い合わせください。UsualMatrixは世界中のお客様と、中国語・スペイン語・英語でやり取りしています。

注記:本記事は一般的な情報であり、法的助言ではありません。データ保護や税務のルールは国や事業内容によって異なるため、詳細は専門家にご確認ください。

次のステップ

自社のビジネスに活かしませんか?

現在の状況とご要望をお聞かせください。具体的なアドバイスとプランをご提案します。WhatsAppまたはフォームからご連絡ください。対応言語は中国語・スペイン語・英語です。

WhatsAppで相談する メッセージを送る
関連サービス アプリ・システム開発

次のプロジェクトについて、お話ししませんか。

メッセージひとつで始められます。構想をお聞かせいただければ、明確なアドバイスとプランをご提案します。