スクラッチ開発は時代遅れか｜パッケージ・SaaS・ローコードとの選び方
業務システムを新しく作ろうとすると、「いまどきスクラッチ開発は時代遅れで、SaaSやローコードで十分だ」という意見を耳にすることがあります。たしかに、会計や勤怠、顧客管理のように、すぐに使えるクラウドサービスが揃っている領域は増えました。ゼロから作るより早く安く始められる場面が多いのは事実です。
一方で、スクラッチ開発が時代遅れになったわけではありません。既製の製品では業務が回らない、他社と同じ仕組みでは差がつかない、複数のサービスをつなぐ部分がどうしても必要になる、といった理由で、自社専用のシステムを作る判断は今でも日常的に行われています。スクラッチ開発とパッケージ開発、SaaS、ローコードは、優劣ではなく向き不向きで選ぶものです。
問題は、「時代遅れかどうか」という問いのままでは、自社にとってどれが合うかが決まらないことです。必要なのは、どの条件ならスクラッチが合い、どの条件なら既製品を使うべきかという、発注側の判断基準です。
この記事では、スクラッチ開発が時代遅れと言われる理由、主な選択肢の違い、スクラッチが合う条件と合わない条件、選択肢を組み合わせる考え方を整理します。
スクラッチ開発が時代遅れと言われる理由
スクラッチ開発とは、既製の製品を土台にせず、業務に合わせてシステムを一から設計して作る方法です。これが時代遅れと言われる背景には、いくつかの変化があります。
- 会計、勤怠、経費精算、顧客管理など、多くの会社で共通する業務向けのSaaSが充実し、月額料金ですぐに使えるようになった
- ノーコード・ローコードのツールで、現場の担当者が簡単な業務アプリを自分で作れるようになった
- パッケージやSaaSを標準のまま使い、業務の側を合わせる導入の進め方が広まった
- 過去に作り込んだ自社専用システムが古くなり、改修や保守に苦労している会社が少なくない
どれも実際に起きている変化です。特に最後の点は、スクラッチ開発への警戒感の大きな理由になっています。作った当時の担当者が退職して中身が分からない、使っている技術が古くなって改修できる会社が限られる、といった状況を経験した会社ほど、「もう自社で作るのはやめたい」と考えるのは自然です。
ただし、これらの問題の多くは、スクラッチ開発という方法そのものではなく、作った後の扱い方に原因があります。仕様書やソースコードを自社で管理していなかった、保守の体制を決めずに作り込みを重ねた、といった事情です。同じことは、カスタマイズを重ねたパッケージにも起こります。スクラッチを避ければ解決するわけではない点は、押さえておく必要があります。
スクラッチ開発・パッケージ開発・SaaS・ローコードの違い
選択肢を比べるときは、「自由度」だけでなく、「誰が作り、誰が持ち、誰が更新するか」の違いに注目すると判断しやすくなります。代表的な4つの方法を整理すると次のようになります。
| 方法 | 作り方 | 持ち主と更新 | 向いている業務 |
|---|---|---|---|
| SaaS | 提供会社が作ったサービスを契約して使う | 提供会社が持ち、機能の更新も提供会社が行う | 会計、勤怠、経費精算など、会社ごとの違いが小さい業務 |
| パッケージ開発 | 既製の業務パッケージを導入し、設定や追加開発で合わせる | 製品は提供会社、追加開発部分は自社や導入会社が保守する | 業種ごとに型があり、一部に自社の事情がある業務 |
| ローコード・ノーコード | ツールの部品を組み合わせて画面やデータを作る | ツールは提供会社、作ったアプリは自社が持つ | 部門単位の管理業務、変更が多い小規模な業務 |
| スクラッチ開発 | 業務に合わせて一から設計して作る | 自社が持ち、改修も自社か委託先が行う | 自社独自の業務、他社との差になる仕組み、複数システムをつなぐ部分 |
費用の面では、スクラッチ開発は初期の開発費が大きくなりやすい一方、利用者数に応じた月額料金はかかりません。SaaSは初期費用が小さい代わりに、利用者数や利用量に応じた料金が続きます。どちらが安いかは、利用者数、使う年数、必要な機能によって変わるため、一律には言えません。比べるなら、5年程度の期間で、ライセンス料、開発費、保守費、社内の運用の手間を合わせた総額で見るのが現実的です。
なお、「パッケージ開発」という言葉は、既製のパッケージを土台にして足りない部分を追加開発する方法を指して使われることが多く、スクラッチ開発と対になる言葉です。パッケージ開発は、土台となる製品の業務の流れが自社に近いほど追加開発が少なく済み、早く安く導入できます。反対に、製品の流れと自社の業務がかけ離れていると、追加開発が膨らんで、結果的にスクラッチ開発より高くつくこともあります。製品のバージョンアップのたびに追加開発部分の動作確認が必要になる点も、スクラッチにはない負担です。パッケージ開発を選ぶなら、追加開発がどの程度になりそうかを、製品の標準の流れを実際に見たうえで見積もってもらうことが欠かせません。
もう一つの違いは、機能の変化を誰が決めるかです。SaaSでは、使わない機能が増えたり、使っていた機能の仕様が変わったりすることを、利用者側では止められません。スクラッチ開発では変化を自社で決められる反面、変化させるための費用も自社が負担します。この「主導権と負担の交換」が、選択肢の本質的な違いです。
それでもスクラッチ開発が合う条件
次のような条件に当てはまる場合は、既製の製品よりスクラッチ開発のほうが合う可能性が高くなります。一つだけでなく、複数に当てはまるほど、スクラッチを選ぶ理由は強くなります。
| 条件 | スクラッチが合う理由 |
|---|---|
| 業務のやり方そのものが、顧客から見た価値や競争力になっている | 既製品に合わせると、他社との差が消えてしまう |
| 既製品で回そうとすると、手作業やExcelでの補完が大量に残る | システムの外に業務が流れ、導入の効果が出ない |
| 複数のSaaSや既存システムの間をつなぐ処理が中心になる | つなぎの部分は既製品になく、どこかで作る必要がある |
| 利用者が多く、利用者数に比例する月額料金が重くなる | 長期で見ると、自社で持つほうが総額を抑えられる場合がある |
| データの扱いや処理の速さに、既製品では満たせない条件がある | 保存場所、処理量、応答の速さを自社で設計できる |
| 顧客や取引先に提供するサービスとして使う | 画面や機能を自社のサービスとして自由に設計する必要がある |
特に判断の分かれ目になるのが、最初の条件です。業務のやり方が自社の強みになっているかどうかは、「その業務を他社と同じやり方に変えたら、顧客は気づくか、困るか」と考えると見極めやすくなります。顧客が気づかないなら、その業務は既製品に合わせる候補です。顧客が困るなら、そこは自社で作る価値がある部分かもしれません。
また、スクラッチ開発といっても、すべてをゼロから書くわけではありません。認証、決済、メール配信、地図などの部品は、外部のサービスやライブラリを使うのが一般的です。自社で作るのは業務の中核になる部分に絞り、それ以外は既存の部品を組み合わせることで、開発費と保守の負担を抑えられます。
スクラッチ開発を選ばないほうがよい条件
反対に、次のような条件では、スクラッチ開発は避けたほうがよいでしょう。作れないわけではありませんが、費用や手間に見合う効果が出にくくなります。
- 会計や給与計算のように、法令に沿った処理が中心で、会社ごとの違いが小さい業務
- 法改正や制度変更への対応が頻繁に必要で、その追随を自社で担う体制がない業務
- 業務の内容がまだ固まっておらず、何が必要かを試しながら決めたい段階
- 利用者が少なく、既製品の月額料金のほうが明らかに小さい場合
- 作った後の保守や改修の予算、窓口となる担当者を確保できない場合
最後の条件は見落とされがちですが、重要です。スクラッチ開発のシステムは、作って終わりではなく、利用するOSやブラウザの変化、使っている技術の更新、セキュリティ対策に合わせて手を入れ続ける必要があります。その費用と体制を確保できないなら、提供会社が更新を担ってくれるSaaSのほうが安全です。
業務の内容がまだ固まっていない段階も、いきなりスクラッチで作り込むのは危険です。まずはローコードのツールや既製品で運用してみて、どこが足りないのかがはっきりしてから、足りない部分を作るほうが無駄が少なくなります。ローコードで回しながら要件を固め、規模が大きくなった段階でスクラッチに移るという順序も現実的な選択肢です。
ローコードのツールについても、万能ではない点は押さえておきましょう。現場で作れる手軽さの反面、作る人ごとにアプリの作り方がばらばらになりやすく、作った人が異動すると誰も直せなくなるという、スクラッチ開発と同じ属人化の問題が起こります。ツールの料金が利用者数に比例する場合は、利用者が増えるほど費用も増えます。ローコードを選ぶ場合も、アプリの作成ルールと管理者を決めておくことが前提です。
スクラッチ開発を選ぶ場合には、時代遅れと言われる原因になった問題を繰り返さない備えも必要です。
| 過去に起きやすかった問題 | 今回の備え |
|---|---|
| 中身を知る人がいなくなった | 仕様書、設計の資料、ソースコードを自社で保管し、更新のたびに最新にする |
| 改修できる会社が限られた | 広く使われている技術を選んでもらい、選定理由の説明を受ける |
| 作り込みが重なって複雑になった | 機能追加のたびに、既製品で代わりにならないかを確認する |
| 保守費用を見込んでいなかった | 開発費とは別に、毎年の保守と改修の予算を決めておく |
選択肢を組み合わせて決める手順
実際の業務システムでは、すべてをスクラッチで作るか、すべてを既製品で済ませるかの二択になることはあまりありません。会計はSaaS、顧客管理はローコードのツール、自社独自の受注処理と各サービスのデータ連携はスクラッチ、というように、業務ごとに方法を分けるのが一般的です。組み合わせを決めるときは、次の順序で考えると整理しやすくなります。
| 手順 | やること |
|---|---|
| 1. 業務を分ける | 対象の業務を、受注、在庫、請求、顧客対応のような単位に分けて一覧にする |
| 2. 独自性を判定する | それぞれの業務が、他社と同じやり方で困るかどうかを判定する |
| 3. 既製品を当てる | 独自性が低い業務から、SaaSやパッケージで回せるかを確かめる |
| 4. 残りの作り方を決める | 既製品で回らない業務を、規模と変更の多さに応じてローコードかスクラッチに振り分ける |
| 5. つなぎ方を決める | 業務間でどのデータを、どのタイミングで受け渡すかを決める |
この手順で見落としやすいのが、第5段階のつなぎ方です。業務ごとに別々の方法を選ぶと、データが複数のサービスに分かれます。顧客や商品のデータをどこで正として持つのか、ほかのサービスにはどう反映するのかを決めておかないと、同じデータを何度も入力することになり、組み合わせた効果が薄れます。スクラッチ開発が最も力を発揮するのは、実はこのつなぎの部分であることも少なくありません。
開発会社に相談するときも、「スクラッチで作ってください」と方法を指定するより、業務の一覧と、それぞれで困っていることを伝えて、方法の提案を受けるほうがよい結果になりやすいでしょう。既製品で済む部分は既製品を勧め、作るべき部分を絞ってくれる会社かどうかは、相談先を選ぶ判断材料にもなります。
まとめ
スクラッチ開発は時代遅れになったのではなく、使いどころが絞られてきた方法です。会社ごとの違いが小さい業務はSaaSやパッケージに任せ、自社の強みに直結する業務や、複数のサービスをつなぐ部分にスクラッチ開発を使うという分け方が、今の一般的な考え方です。
| 業務の性質 | 合いやすい方法 |
|---|---|
| 会社ごとの違いが小さく、法令に沿った処理が中心 | SaaS |
| 業種の型があり、一部に自社の事情がある | パッケージ（設定と最小限の追加開発） |
| 部門単位で、変更が多く、規模が小さい | ローコード・ノーコード |
| 自社の強みに直結する、または複数のシステムをつなぐ | スクラッチ開発 |
どの方法を選ぶにしても、作った後に誰が持ち、誰が更新し、その費用を誰が負担するのかを決めておくことが、失敗を防ぐ共通の条件です。明日はまず、対象の業務を一覧にして、それぞれについて「他社と同じやり方に変えたら顧客は困るか」を書き込んでみてください。その答えが、スクラッチで作る部分と既製品に任せる部分を分ける出発点になります。