スクラッチ開発（オーダーメイド開発）が採算に合うのは、顧客対応や生産計画、案件の見積もりなど、競合他社と差別化できる領域だけです。会計や給与計算、メールといった残りの業務は、パッケージなどの既製システムに業務を合わせるほうが安く済みます。

第3の選択肢が、既製のパーツを組み合わせてアプリを作るノーコード・ローコード基盤です。本記事では、自作と購入を見極めるテスト、ノーコードが上限に達する場面、5年間の費用比較、そしてExcelの表が独自業務システムの要件定義書として役立つ理由を解説します。

3つの選択肢：購入・組み合わせ・スクラッチ開発

業務システムには、既製品の購入、ノーコード基盤での組み立て、スクラッチ開発の3通りがあります。それぞれ初期費用、導入スピード、ベンダーへの依存度が異なります。

服選びに例えると分かりやすくなります。

• 既製システムは既製服です。安価ですぐ手に入り、大半の人に合います。
• ノーコードはパターンオーダーです。店の選択肢の範囲内でパーツを組み合わせます。
• スクラッチ開発はオーダースーツです。高価で時間もかかりますが、体にぴったり合います。顧客の目に触れる部分や、既製服では合わない場面で価値を発揮します。

既製システムには、インストール型のパッケージソフトと月額制のクラウドサービス（SaaS）があります。ノーコード・ローコード基盤では、プログラミングなし、または最小限のコードで、ブラウザ上でフォームやルールを組み合わせてアプリを作ります。スクラッチ開発では、自社の業務フローに合わせて開発チームが設計・プログラミングを行います。

どの方法を選んでも依存は生じます。パッケージはベンダーが価格と機能を決め、ノーコードは基盤側ができることの範囲を決めます。スクラッチ開発で開発会社に依存するのは、ソースコードや仕様書、権利を受け取っていない場合だけです。

見極めテスト：競合との差別化につながるか

開発するか購入するかは、「その業務で競合と差別化しているか」という問いで決まります。ソフトウェア開発者のMartin Fowlerは、ソフトウェアを2種類に分けています（Martin Fowler、Utility vs Strategic Dichotomy）。

• 汎用機能（ユーティリティ）は、給与計算や会計などどの企業にも必要な機能です。既製パッケージを購入し、業務を合わせます。主なリスクはシステム停止なので、コストは低く抑えます。
• 戦略機能は、自社に優位性をもたらす機能です。競合に追い抜かれるリスクがあるため、投資して開発する価値があります。

ただし、多くの企業は戦略機能を広く捉えすぎています。Fowlerによれば、戦略機能に当たるのは5件に1件ではなく、20件に1件程度です。

2つ目の問いは「業務フローがどれくらいの頻度で変わるか」です。変化の多い業務には改修しやすいソフトウェアが必要ですが、安定した業務ならシンプルな仕組みで足ります。

同じ業務でも、企業によって位置づけは変わります。たとえば価格計算は、価格表で売る卸売業者にとっては標準業務ですが、キッチンを1件ずつ個別見積もりする家具工房にとっては商売の核です。顧客が自社の何を評価しているかを基準に判断してください。

半日でできる見極めテスト：

1. 営業・現場・経理のメンバーと一緒に、主要な業務を10〜15個書き出します。
2. それぞれの業務について「競合他社とまったく同じやり方にした場合、顧客は気づくか」を問います。
3. 気づかないなら既製品を購入します。気づくなら変更頻度を考慮し、マトリクスに沿って方法を選びます。

既製システムで十分なケース

会計、給与計算、勤怠管理、請求書発行、メール、一般的なECサイトは既製システムで十分です。法制度に左右される業務であり、法改正への対応もベンダーが担います。

チェコ統計局（ČSÚ）によると、2025年時点で従業員10人以上の企業の半数（小規模企業の42%、大企業の93%）が基幹システム（ERP）を利用していました。CRMの導入率は36%で、欧州平均の29%を上回っています（ČSÚ、企業部門におけるICT利用調査 2025）。チェコ市場ではPohoda、Money、ABRA Flexi、Heliosなどのシステムが代表例です。業種、従業員数、在庫管理の有無、会計担当者、必要な外部連携によって選ぶ製品は変わります。

システムは自社の実データで試してください。体験版で「受注」「請求」「クレーム対応」という3つの日常業務を一通り動かしてみます。自社の強みとなる部分で動きが滞るなら、そこだけ独自の拡張機能を作る方法を検討してください。

クラウド型を契約する前には、解約時の条件を確認します。

• どのような手順・形式・費用でデータを書き出せるか
• データはどこで処理され、誰がアクセスできるか
• ベンダーはいつ値上げやサービス終了を行えるか

独自開発が採算に合うケース

スクラッチ開発が採算に合うのは、競合他社と差別化している業務プロセスです。

• 独自の業務プロセス。自社特有の受注・計画・見積もりの仕組みは、既製システムに当てはめようとすると妥協が必要になります。
• 多数のシステム連携。ECサイト、在庫管理、会計、配送業者、営業の表計算シートの間で手作業の転記が発生している場合、担当者の時間と入力ミスというコストを払っています。
• 成長に伴うライセンス費の増加。パッケージソフトの多くはユーザー数に応じた課金です。顧客や取引先、アルバイトにもアカウントを発行すると、人数が増えるたびに費用が膨らみます。
• 強みになるデータ。受注・引き合い・在庫のデータを自社独自の構造で蓄積すれば、需要予測や自動化に活用できます。

独自の業務システムだからといって、すべてを置き換える必要はありません。大半のケースでは、既製システムで対応できない部分だけを作り、データをやり取りさせます。典型的な例が、取引先が自分で発注し、自社向けの卸価格や手配状況を確認できるポータルです。

スクラッチ開発には、発注側にも業務を把握し、質問への回答や意思決定に時間を割ける担当者が必要です。分析から公開までの流れは、Webアプリ・モバイルアプリ開発の進め方で解説しています。私たちの開発費用は、業務システムが18万チェココルナ〜、Webアプリケーションが23万チェココルナ〜です。

ノーコード・ローコード：素早く始められるが上限がある

フォームや台帳管理、承認フローといったシンプルなアプリを最も早く作れるのが、ノーコード・ローコードです。プログラマーがいなくても、ブラウザ上で既製パーツを組み合わせて数日で形にできます。少人数の社内チームや、アイデアの素早い検証に向いています。

たとえば受付と工場に5人のスタッフがいる自動車整備工場なら、紙の代車管理表を、車両状態の写真付きフォームと貸出一覧を備えたアプリへ数日で置き換えられます。しかし、工場の空き状況に応じて顧客自身に代車を予約してもらう仕組みとなると、ノーコードでは対応しきれません。

アプリが軌道に乗ると、上限が見えてきます。

• 権限設定。「営業担当者に自分の担当顧客だけを表示する」といった細かい設定には制限がつきものです。
• 処理速度とデータ量。レコード数やユーザー数が増えると動作が重くなり、プラットフォームの上限に達します。
• ユーザー単価。社内5人で使うには安くても、取引先100社に開放すると高額になります。
• プラットフォームへの依存。作ったアプリを他社基盤へ移すことはできません。移行できるのはせいぜいデータだけなので、事前の確認が必要です。

シャドーITのリスクもあります。社員1人がアプリを作り、退職後に誰も仕組みを把握できなくなるケースです。アプリごとに責任者、データへのアクセス規則、バックアップ方法を必ず決めておきましょう。

一方で、ノーコードで作った試作品（プロトタイプ）は要件定義のたたき台として役立ちます。本格的な開発を発注する前に数週間現場で使ってもらい、足りない機能を書き留めておきましょう。

ハイブリッド構成と5年間のコスト比較

中小企業で最もよく選ばれているのがハイブリッド構成です。会計や在庫管理などの中核には既製品を使い、取引先向けポータルや生産計画といった独自機能をその上に追加します。優位性につながる部分だけに開発費をかけるやり方です。

システム同士はAPI（連携インターフェース）を通じて人手を介さずにデータをやり取りします。たとえばチェコの会計システムPohodaは、ECサイトやCRMと連携するためのXML通信機能を備えています（Stormware、インターフェース仕様書）。実務での進め方は、ECサイトと会計システムの連携の記事で解説しています。

この方法を使えば、タイヤの卸売業者が会計・在庫・請求処理を既製システムに残したまま、タイヤ専門店や整備工場向けの専用ポータルだけを追加開発できます。取引先はポータル上で自社の仕入れ価格と在庫を確認でき、注文データはメールや電話から転記することなく倉庫へ直接届きます。

費用は最初の請求書ではなく、5年間の総額で比較してください。既製システムは毎月の支払いになり、スクラッチ開発は初期に費用が集中します。以下の項目をすべて含めて計算します。

1. 既製システムの場合：1人あたりライセンス料×ユーザー数×60か月分、初期導入費、研修費、有料アドオン、そしてシステムの制約を補う手作業にかかる時間。
2. スクラッチ開発の場合：初期開発費、5年間の運用費（サーバー代、保守、セキュリティ更新）、追加開発費。
3. 両方に共通する費用：データ移行、新旧システムの並行稼働、社内教育。

事業拡大も織り込んでおきましょう。ユーザー数が2倍になればライセンス料も2倍になりますが、独自システムの運用費はそれほど急には増えません。3つの試算パターンはアプリ開発と5年間の運用にかかる費用、見積もり方式の違いは固定価格契約とタイム・アンド・マテリアル契約の比較をご覧ください。

今使っている表計算シートが要件定義書になる

独自の業務システムを作る際、要件定義に最も役立つのは、現場で今使われている表計算シートです。列を見れば扱うデータが分かり、数式には業務ルールが、色分けやメモにはステータスや例外処理が表れています。10ページの説明書を読むより、シートを見るほうが開発会社は1時間で多くのことを理解できます。

シートは次の手順で準備します。

1. 保管用の過去データではなく毎日使っているシートを選び、誰が入力し誰が閲覧するかを書き添えます。
2. 個人情報や機密データは架空のデータに置き換え、表の構造と数式はそのまま残します。
3. 色分け、略語、メモの意味を説明します。
4. シートの外で行っている手作業（倉庫への電話連絡、別画面での確認など）に印をつけます。
5. よく起きる例外パターンを3つと、その対処法を書き添えます。ここが見積額を左右します。

回答の結果、スクラッチ開発やハイブリッド構成が向いていそうでしょうか。プロジェクト・コンフィギュレーターに業務内容を入力すると、3パターンの解決策をまとめた要件シートを作成できます。

よくある質問