スクラッチ開発とは、既製のパッケージやテンプレートを使わず、自社の業務に合わせてシステムを作る進め方のことです。検索するとメリットとデメリットを並べた解説がたくさん出てきますが、読み終えても「で、うちはどっちなのか」が決まらないことが多いのではないでしょうか。理由ははっきりしていて、上位に出てくる記事のほとんどが、パッケージかローコード基盤か開発そのものを売っている会社の書いたものだからです。この記事では何も売らない立場から、パッケージ開発との違いを整理したうえで、発注側が自分のケースで決めるための判断軸を並べます。先に結論を書くと、分かれ目は機能の数ではなく、いまの業務のやり方を製品側に合わせて変えられるかどうかです。
この記事のポイント
- スクラッチ開発はひな形を使わず自社の業務に合わせて作る進め方で、フレームワークや既製のクラウドサービスは使う
- パッケージ導入には業務のやり方を製品側に合わせる前提があり、そこを変えられるかが最初の分かれ目になる
- 費用は初期費用だけで比べず、ライセンスと改修費を足した数年分で見ると順位が入れ替わることがある
- 解説記事も提案書も書き手が売っているものに寄るので、立場を確かめてから中身を読む
目次
スクラッチ開発とパッケージ開発の違い
スクラッチ開発とフルスクラッチの違い
まず言葉の整理からです。スクラッチ開発は、市販のパッケージ製品やテンプレートを土台にせず、自社の要件に合わせて作る進め方を指します。ゼロから作ると説明されることが多いのですが、実際には開発用のフレームワークやライブラリ、クラウドの既製サービスは普通に使います。全部を手書きするという意味ではありません。
これとよく並べられるのがフルスクラッチという言葉です。フレームワークすら使わずすべて自前で組む、という意味で使う人もいれば、単にスクラッチを強調しただけで使っている人もいます。業界で定義が統一されていないので、私は見積書や提案書に「フルスクラッチ」と書かれていたら、必ず「どこまでを自前で作る前提の見積もりですか」と聞くようにしています。ここが曖昧なままだと、あとから基盤部分の工数が追加で出てきます。
発注側にとっての実務的な意味は、もっとシンプルです。スクラッチ開発を選ぶということは、製品ライセンス料を払わない代わりに、作る分の工数がすべて自社の見積もりに乗るということです。逆にパッケージを選ぶということは、作る工数を製品の代金として分割して払い続けるということになります。どちらもお金は出ていきます。出ていき方の形が違うだけです。
パッケージ導入は業務を製品に合わせること
ここがこの記事でいちばん伝えたい点です。パッケージ製品は、いろいろな会社で使える形に整えて作られています。裏を返すと、特定の一社の細かい事情に合わせては作られていません。ですからパッケージを入れるときは、製品が想定している手順のほうに、自社の業務を寄せていく作業が必ず発生します。業務改革やBPRと呼ばれるものの正体は、多くの場合これです。
この前提は、製品を売る側からはあまり強く語られません。デモの場で「その業務にも対応できます」と言われたとき、それが標準機能で今のやり方のまま動くという意味なのか、運用を変えれば成立するという意味なのか、あるいは追加開発すれば実現できるという意味なのかは、聞かないと分かれません。同じ「できます」でも、後ろ二つは自社の負担が増えます。
私が現場でよく見るのは、情報システム部門としてはパッケージで決めたのに、現場に降ろした段階で「この手順は変えられない」と止まるパターンです。そうなると結局カスタマイズ費用が積み上がり、当初の見積もりから大きく離れていきます。パッケージが悪いわけではなく、業務を変えられるかどうかの確認を後回しにしたことが原因です。
ですから比較の順番は、機能一覧の突き合わせより先に、現場の手順を変えられるかどうかの確認だと考えています。この確認さえ済んでいれば、あとの比較はかなり楽になります。
費用と期間はどこで逆転するのか
費用の話は、初期費用だけを見ると必ずパッケージが安く見えます。作る工数が要らないので当然です。ところが実際に払うお金は初期費用だけではありません。年間のライセンス料、自社に合わせるためのカスタマイズ費、提供元のバージョンアップに追随するための改修費が、毎年または数年おきに乗ってきます。
ざっくりした比べ方の枠として、次のような費目で並べると全体像がつかみやすくなります。金額そのものは対象業務や規模で大きく動くので、ここでは考え方の枠として見てください。
| 費目 | スクラッチ開発 | パッケージ開発 |
|---|---|---|
| 初期費用 | 高い。作る範囲がそのまま工数になる | 抑えられる。導入設定と移行が中心 |
| 年間ライセンス | かからない | 利用人数や機能に応じて毎年かかる |
| 自社に合わせる費用 | 最初の設計に織り込む | 追加費用。製品によって範囲に制限がある |
| バージョンアップ | 時期を自社の都合で決められる | 提供元の時期に合わせる。追随の改修費が出ることがある |
| やめるときの費用 | 移行先を選びやすいが移行作業は必要 | データの取り出し方が製品仕様に依存する |
逆転するかどうかの見方は、そこまで難しくありません。初期費用の差額を、パッケージ側で毎年かかるライセンス料と改修費の合計で割ると、およそ何年で並ぶかが出ます。数年で並ぶ計算になるなら、初期費用の差だけで決めるのは早いということです。逆に十年以上かかる計算なら、パッケージのほうが合理的でしょう。
期間についても、スクラッチは長くなります。規模によりますが、要件定義から本番稼働まで半年から二年程度を見ておくのが一般的な目安です。パッケージでも移行と教育に数か月はかかるので、差は思ったほど極端ではないこともあります。いずれも一般的な目安なので、実際の判断は個別の見積もりで確認してください。システム開発の費用相場を規模別・種類別に整理した記事もあわせて見ると、金額の当たりがつけやすくなります。
なお両者を同じ土俵で比べるには、見積書の前提条件をそろえる必要があります。片方だけデータ移行や教育が含まれていない、という状態はよく起きます。見積もりの危険サインを見抜く60項目チェックシートで、対象外になりやすい範囲を先に洗い出しておくと、比較がぶれにくくなります。
スクラッチ開発が時代遅れと言われる理由
「スクラッチ開発 時代遅れ」「スクラッチ開発 反対」といった調べ方をする人がいます。実際にそう言われる背景には、理由が三つあります。
一つ目は、SaaSが増えて標準機能のままで足りる業務領域が広がったことです。会計、給与、勤怠、経費精算あたりは、わざわざ作る理由が少なくなりました。二つ目は、ローコードやノーコードの基盤で作れる範囲が広がったことです。三つ目は、長期の大規模開発が失敗する事例が繰り返し報じられ、作ること自体のリスクが強く意識されるようになったことです。
どれも事実です。ただ、その言葉を誰が言っているかは意識したほうがいいと思います。「スクラッチはもう古い」と書いている記事の多くは、SaaSやローコード基盤を売っている会社のものです。売り物がある人の主張が間違いとは限りませんが、都合の悪い部分は書かれません。ローコード基盤にも、作れる範囲の上限と、その基盤自体への依存という別の課題があります。
私の見方としては、スクラッチが不要になったのではなく、出番が絞られたという表現が近いと思っています。他社と同じでいい業務は買う、自社の勝ち負けが決まる業務は作る。この使い分けが現実的な落としどころです。
スクラッチ開発を選ぶかどうかの判断軸
業務フローを変えられるかを先に確かめる
判断の一歩目は、製品比較ではありません。いまの業務手順を書き出して、変えられるものと変えられないものに仕分ける作業です。
仕分けの基準は、その手順がなぜそうなっているかです。取引先から指定されている、法令や業界のルールで決まっている、監査で求められている。こうした理由があるものは、社内の都合では動かせません。一方で「前任者のときからこうしている」「システムがそうだったから」という理由のものは、たいてい動かせます。
この仕分けをすると、たいていの会社で「変えられない手順」は思ったより少なく残ります。そしてその残ったものが、パッケージの標準からどれだけ外れているかが、そのまま判断材料になります。外れが小さければパッケージで足りますし、中核業務で大きく外れているならスクラッチ寄りに傾きます。
既製ツールを買う場合と開発を発注する場合で、判断のポイントをより実務に寄せて整理した業務改善システムを買うか作るかの選び方もあります。対象を業務改善に絞った内容なので、テーマが近い方はそちらのほうが具体的です。
差別化の源泉かどうかで線を引く
次の軸は、その業務が自社の競争力に直結しているかどうかです。
会計や給与のように、他社と同じやり方で困らない業務は、作る理由がありません。むしろ制度改正への追随を製品側に任せられる分、買ったほうが安全です。反対に、受注の取り方、配車や在庫の組み方、与信や査定の判定ロジックのように、その会社らしさが出ていて競合との差になっている業務は、既製品に合わせて丸めた瞬間に価値が落ちます。
全部をスクラッチにする必要も、全部をパッケージにする必要もありません。現実的には、周辺業務は既製品、中核業務だけスクラッチという組み合わせが多いですし、それでよいと思います。線を引く場所を決めるのが発注側の仕事で、そこは開発会社にもパッケージ会社にも代わりに決めてもらえません。
解説や提案の書き手がどちら側かを見る
これは検索して情報を集める段階で、いちばん効く見方だと思っています。
パッケージやERPを売っている会社は、スクラッチについて「高い」「長い」「属人化する」と書きます。開発会社は、パッケージについて「業務に合わない」「結局カスタマイズ費で高くつく」と書きます。ローコード基盤の会社は、その両方の弱点を挙げたうえで「間を取れる」と書きます。どれも嘘ではありません。ただ、自社に都合の悪い部分は書かれないので、一本だけ読むと必ず偏ります。
読むときは、運営会社が何を売っているかをまず確認してください。そのうえで、その会社が売っていないほうの選択肢について書かれた部分だけを拾うと、実態に近づきます。
提案を受ける段階でも同じです。私が有効だと思っている質問は二つあります。一つは「御社の標準機能で対応できない業務が出たとき、追加費用はどのように決まりますか」。もう一つは「この見積もりに含まれていない作業を三つ挙げてください」。どちらも、答えにくい部分を先に開いてもらうための質問です。ここで具体的に答えられる相手は、たいてい信用できます。
やめるときの費用を先に見積もる
入口の費用は誰でも比べますが、出口の費用を見ている会社は多くありません。ここを見ておくと判断の質が上がります。
スクラッチ開発を選ぶ場合に確認しておくのは、著作権が自社に帰属するか、ソースコードと設計書が納品物に含まれるか、開発会社を替えることになったときに引き継げる状態で残るか、の三点です。契約書にこれらが書かれていないと、作ったはずのシステムなのに手を出せない状態になります。
パッケージを選ぶ場合は、データの取り出し方が確認点です。契約を終了したあとにデータをどの形式で受け取れるのか、いつまで保持されるのか。標準機能でエクスポートできるのか、作業を依頼する必要があるのか。ここが曖昧だと、乗り換えたくても乗り換えられません。
どちらの選択肢にも、特定の会社や製品から離れにくくなる要素はあります。仕組みと対策はベンダーロックインの原因と回避策をまとめた記事で整理していますので、契約前に一度目を通しておくと安全です。
