「パッケージを試したが、結局Excelに戻ってしまった」「業界特有の計算ロジックがパッケージに乗らない」——中小企業の経営者から、こうした打ち明け話を伺う機会が増えています。スクラッチ開発は「高い・遅い・大企業向け」という印象で語られがちですが、AI駆動開発を前提にすると、その前提自体が崩れてきました。本記事では、スクラッチ開発のメリットを5つに整理し、パッケージでは満たせない典型業務、費用相場と回収期間までを、建造くんの実例とともに経営者目線で組み立て直します。
この記事の結論（3行）
- スクラッチ開発のメリットは「業務適合100%・自由度・スケール・他社差別化・資産化」の5つに集約される
- パッケージで詰まる典型業務は「複雑承認・特殊計算・業界規制」の3領域、ここに該当するならスクラッチが本筋
- AI駆動開発で従来相場の半額が現実化、建造くんは市場相場2500〜4000万円を2000万円で実現し3年で投資回収済み
スクラッチ開発のメリット5つ
スクラッチ開発は技術論として語られがちですが、本質は経営判断の問題です。パッケージが「他社と同じやり方を買う」選択であるのに対し、スクラッチは「自社独自のやり方をシステム化する」選択です。この差から生まれるメリットを5つに整理します。
業務適合100%——「業務をシステムに合わせる」が消える
パッケージ導入の現場で最も頻繁に発生するのが、「業務をシステムに合わせる」逆転現象です。本来はシステムが業務を支えるべきところを、業務側がパッケージの画面構成や入力順序に合わせて変形します。結果、現場は「やりにくくなった」と感じ、Excelで回避策を作り始めます。
スクラッチ開発の最大のメリットは、この逆転を起こさないことです。現場の業務フロー、用語、帳票レイアウト、承認ルートを、そのままシステムに反映できます。建設業の「協力会社別の単価マスタ」、士業の「案件種別ごとの工程テンプレート」、製造業の「ロット番号と検査記録の紐づけ」——こうした業界固有のルールを画面の隅々まで作り込めるのがスクラッチです。業務適合度が高いほど、現場で使われる確率が上がり、データの蓄積精度も上がります。
自由度——変えたいときに変えられる
パッケージのカスタマイズには、ベンダーが用意した範囲というガラスの天井があります。「この項目を追加したい」「この承認ステップを1段増やしたい」と現場が言っても、パッケージの設計思想に反する変更は、追加開発として高額になるか、そもそも不可になるかのどちらかです。
スクラッチは自社のソースコードなので、変更したい場所を変更できます。新しい業務が増えたら画面を1枚足す、廃止業務があれば機能を引っ込める、法改正があれば計算ロジックだけ差し替える——こうした追随が取れます。経営判断のスピードが上がるほど、この自由度の価値は重くなります。
スケール——業務拡大に耐えるデータ構造
パッケージ製品は想定ユーザー数や想定データ件数に上限を持つことが多く、自社の業務が伸びた瞬間に「上位プランへの移行」「別製品への乗り換え」が必要になります。乗り換え時のデータ移行コストは数百万円単位、業務停止リスクも避けられません。スクラッチであれば、データ構造とインフラを自社の成長予測に合わせて設計でき、10年使い続ける前提でデータベース設計を組んでおけば、ユーザー数が3倍になってもサーバーを増強するだけで対応できます。
他社差別化——同じ業界内での競争力
同業他社が同じパッケージを使っている限り、業務オペレーションの効率は横並びになります。差別化は「人の頑張り」か「営業力」でしか作れません。スクラッチ開発は、システムそのものが競争優位になります。たとえば見積もり作成スピードが他社の3倍、納期回答が即時、現場写真と請求書がワンクリックで紐づく——こうした「自社にしかできないオペレーション」を実現でき、同業他社が真似するには1年・1000万円単位のコストがかかります。
資産化——会社のバランスシートに乗る価値
パッケージの月額費用は経費として消えていく支出です。スクラッチで自社開発したシステムは、会計上は無形固定資産として計上でき、減価償却を通じて会社の資産に組み込めます。さらに、システム自体が事業承継・M&A・資金調達の場面で評価対象になります。「業務がシステム化されている」「データが10年分蓄積されている」「ノウハウがコードに残っている」——こうした状態は、後継者にとっても買い手にとっても価値です。
パッケージでは満たせない3つの典型業務
「とりあえずパッケージで始めて、足りなければ後でスクラッチ」という導入順序は、現場で何度も失敗しています。パッケージで詰まる業務には共通パターンがあり、最初からスクラッチ前提で組んだほうが結果的に安く速いケースが多いのです。詰まる業務は、大きく3つに分類できます。
複雑承認——役職横断・条件分岐・社外承認
承認ワークフローは、パッケージで最初に詰まる領域の代表格です。多くのパッケージは「申請者→上長→部長→決裁」という線形フローを前提にしています。一方、実務では「500万円超なら役員2名の合議」「営業部長と経理部長の両方の承認」「協力会社の社印が押された見積もりを添付した場合は工程を1段スキップ」など、条件分岐と役職横断が当たり前です。
こうした複雑なルールをパッケージのワークフロー機能に押し込もうとすると、「一律で全員承認」「実態と違うが手動で運用回避」という妥協が始まります。スクラッチであれば自社の承認規程をそのままコードに落とし込めるため、規程変更時にもシステム側で追随できます。
特殊計算——業界固有の単価・歩掛・按分
建設業の歩掛、運送業の傭車料金、製造業の原価按分、士業の報酬規程——業界ごとに「計算の正解」が違う領域があります。パッケージは「最大公約数の計算式」を提供するため、業界固有ロジックを完全に乗せるのは難しい構造です。
たとえば建造くんでは、協力会社別・工種別・地区別の3軸の単価マスタを掛け合わせ、工事規模ごとの歩掛係数を乗算して見積もりを生成します。これをパッケージに乗せようとするとExcel連携やCSVエクスポートを挟む「半手動運用」になり、ミスとダブル入力が日常化します。
業界規制——許認可・記録保存・監査対応
建設業法・宅建業法・薬機法・労働安全衛生法など、業界規制に紐づく書類・帳票は、改正のたびに様式が変わります。パッケージは法改正に追随しますが、追随タイミングは製品ベンダーのスケジュール次第で、自社業務の都合とは合いません。スクラッチであれば、規制改正があった月のうちに様式変更を反映でき、監査時に「どの法令のどの条文に対応した機能か」をコード上で追跡できる状態は、コンプライアンス上の安心感が違います。
スクラッチ開発の費用相場と回収期間
ここまでメリットを語ってきましたが、経営判断としては「いくらかかって、いつ回収できるか」が最終的な争点です。スクラッチ開発の費用相場を、規模感ごとに整理します。
| 規模 | 機能数 | 工数 | 市場相場 | AI駆動開発相場 | 主な対象 | |---|---|---|---|---|---| | 小規模 | 10〜20機能 | 3〜5人月 | 300〜600万円 | 200〜400万円 | 単一業務領域・部署内利用 | | 中規模 | 20〜40機能 | 8〜15人月 | 800〜1800万円 | 500〜1000万円 | 複数業務領域・全社利用 | | 大規模 | 40〜70機能 | 20〜35人月 | 2500〜4000万円 | 1500〜2500万円 | 全業務統合・社外連携 | | 超大規模 | 70機能超 | 40人月以上 | 4500万円超 | 3000万円超 | 業界プラットフォーム化 |
回収期間の目安は、業務時間削減・売上機会拡大・人件費圧縮の3軸で試算します。たとえば中規模スクラッチ（実費800万円）の場合、月20時間の業務削減（時給3000円換算で月6万円）と新規受注3件増（粗利1件50万円換算で月150万円）の合計で月156万円のリターン、約6ヶ月で投資回収という計算になります。現場業務に深く食い込んだスクラッチほど、回収は速くなる傾向があります。自社の業務がどの規模に該当するかは、項目別に整理するところから始めると、見積もり相場との突合がしやすくなります。
経営者目線で考える「スクラッチ開発」
ここからは、技術論ではなく経営の話です。「スクラッチは高い」「パッケージは安い」という業界の通説は、3年TCOで見ると逆転することが多い——この事実を経営者がどう取り扱うかが、本質的な論点です。
業務システム業界の構造的な問題として、ベンダー側に「パッケージを売るインセンティブ」が強く働く構図があります。パッケージは1本作って多数に売る商品なので、ベンダーは保守費・カスタマイズ費・ライセンス費の3階建てで継続収益を取れます。一方、スクラッチは「1社に1本」のため、ベンダー側の収益効率が悪く、提案段階で避けられがちです。発注者側から見れば、この3階建ては「ベンダーの収益＝自社のコスト」であり、3年・5年・10年で考えるとスクラッチを資産として持つほうが、トータルコストも経営自由度も上です。
経営者が持つべき判断軸は3つです。
- 自社の業務に「他社と違う部分」がどれだけあるか——同業他社と完全に同じ業務ならパッケージ、固有業務が3割以上あるならスクラッチ検討
- 3年で回収できる業務改善効果が金額として見えているか——回収シナリオが描けない投資はスクラッチでもパッケージでも失敗する
- 業務側を変える覚悟があるか——システムだけ入れて業務を変えない会社は、どちらを選んでも使われないシステムを抱える
この3軸で考えれば、「スクラッチか、パッケージか」という二択は、自社の業務固有性と回収シナリオの組み合わせで自然に答えが出ます。
ぷらすわんの実例：建造くん
弊社の実例を1つ。建設会社向けに開発した業務統合システム「建造くん」です。
建設業界の業務統合システムは、機能規模で言えば57機能、工数換算で30.8人月、市場相場では2,500〜4,000万円のレンジに該当する大規模スクラッチです。弊社では、これを 2,000万円 で開発・納品しました。市場相場の下限と比べても2割安、上限と比べると半額です。
なぜそれが可能だったか、3つの理由があります。
理由1：AI駆動開発で実工数を3〜4割削減
設計フェーズではAIに業務フロー図のたたき台を作らせ、コーディングフェーズでもAIが7〜8割のコードを書きます。エンジニアの作業は「AIが書いたものをレビューして整える」「業務固有のロジックだけ自分で書く」に集中するため、人月単価あたりの実工数が大幅に減ります。30.8人月相当の機能を、実工数では20人月強で構築しています。
理由2：建設業固有業務を妥協なく作り込み
協力会社別の単価マスタ、工種別・地区別の歩掛係数、現場写真と工事報告書の自動紐づけ——こうした建設業独自の業務をパッケージで吸収しようとした場合のカスタマイズ追加費用は1000〜1500万円規模になります。スクラッチで最初から作り込むことで、この追加費用が発生しません。
理由3：データ構造を10年使う前提で設計
建造くんは、ユーザー数の拡大・取引先増加・新規業務追加に耐えるデータベース設計を採用しています。発注元が10年後にも同じシステムを使い続けられる構造で、追加開発・乗り換えコストが発生しません。
建造くん導入後、発注元の建設会社では、見積もり作成時間が従来比3分の1、現場写真の整理工数が月20時間削減、協力会社への発注ミスが年間で7割減少——という効果が出ています。手元の業務がスクラッチに向くかどうかは、診断することで適合度の概算が出せます。
スクラッチ開発を成功させる4つの実践
最後に、スクラッチ開発を成功させるための実践的な4つの観点を整理します。技術選定よりも、経営者の判断順序のほうが成否を分けます。
- 業務側の「捨てる覚悟」を先に固める
- ベンダーの収益構造を読んで発注先を選ぶ
- AI駆動開発を前提に費用相場を再評価する
- 3年運用と10年運用の両方で投資計画を描く
業務側の「捨てる覚悟」を先に固める
スクラッチで最も多い失敗は、現状業務のすべてをシステムに乗せようとすることです。現状業務には「過去の経緯で残っている不要な工程」「特定担当者の好みで残っている例外処理」が必ず混じっています。これらを全部システム化すると、規模が膨らみ、現場で使われない巨大システムになります。発注前に「何を捨てるか」を決めるだけで、最終費用が3〜4割変わります。
ベンダーの収益構造を読んで発注先を選ぶ
ベンダーの収益構造によって、提案内容は大きく変わります。パッケージ販売を主軸にしているベンダーはパッケージを薦め、SESを主軸にしているベンダーは大規模スクラッチを薦め、AI駆動開発を主軸にしているベンダーは中規模スクラッチを薦めます。発注前に「どこで稼いでいる会社か」を確認するだけで、提案の偏りを補正できます。
AI駆動開発を前提に費用相場を再評価する
「スクラッチは高い」という業界相場感は、2020年代前半までの前提です。AI駆動開発を前提にすれば、同じ機能規模でも実費が3〜4割下がります。複数社から見積もりを取る際は「AI駆動開発を採用しているか」を確認し、採用ありと採用なしの2社で比較すると、価格差の構造が見えます。
3年運用と10年運用の両方で投資計画を描く
スクラッチ開発の真価は3年では出きらず、5年・10年運用で資産化されてから本領を発揮します。投資計画は、3年回収シナリオと10年資産化シナリオの両方を描いたうえで判断するのが本筋です。他社見積もりとの比較を依頼することで、相場との差と回収期間の両面が見えます。
まとめ
スクラッチ開発のメリットは、業務適合100%・自由度・スケール・他社差別化・資産化の5つに集約されます。パッケージで満たせない典型業務は複雑承認・特殊計算・業界規制の3領域で、自社業務がここに該当するならスクラッチが本筋です。
費用相場は規模ごとに300〜4500万円超のレンジで、AI駆動開発を前提にすれば従来相場の半額が現実的に出ます。中規模スクラッチでも半年〜1年で投資回収できるシナリオが描けます。手元の業務がスクラッチに向くかどうかを切り分けたい場合は、業務改善・システム見積もりAI適正診断で個別に整理できます。