スクラッチ開発とパッケージ開発の比較・違いについて徹底解説

開発手法は、スクラッチ開発か？パッケージ開発か？新たなシステムの導入で挙がる課題です。

しかし、コストや機能性の面で、スクラッチ開発とパッケージ開発の比較に悩まれる方も多いのではないでしょうか。

そこで当コラムでは、スクラッチ開発とパッケージ開発の違いから、双方の選定時に起こりうるリスク、さらにそのリスクを避けるための注意ポイントまで解説します。

どちらを検討すべきか迷われている方は、ぜひご一読ください。

 

 

パッケージ開発に比べてスクラッチ開発は時代遅れ？

スクラッチ開発の概要

○ スクラッチ開発はオーダーメイド

スクラッチ開発とは、既存システムを活用せず、ゼロからオーダーメイドでオリジナルシステムを開発する手法です。

 

スクラッチ開発の著作権について

スクラッチ開発の著作権は、受注側に発生します。

すなわち発注者ではなく、そのシステムを作成した当人側の著作物であるということを留意しておきましょう。

なお、例外として契約書に「著作権の帰属」に関する条文を入れ、対象を発注者とした場合、著作権は発注側に移ります。

もし発注時に著作権も保有したい場合は、譲渡規定の明記を忘れずに行いましょう。

 

パッケージ開発の概要

○ パッケージ開発はフレームワークなどを使用

一方、パッケージ開発とは、既存システムで使われているフレームワークやアプリケーションを活用し開発する手法を指します。

スクラッチ開発の対義語として位置づけられます。

 

スクラッチ開発とパッケージ開発の相違点

双方の相違点は、既存システムを活用するか否かです。

スクラッチ開発がゼロから手掛けられることに対し、パッケージ開発は、既存システムに機能を追加する形で手掛けられます。

 

スクラッチ開発とパッケージ開発のメリット

スクラッチ開発とパッケージ開発を比較検討するために、まずは双方のメリットをご紹介します。

 

スクラッチ開発のメリット

○ カスタマイズ性の高さ

既存システムの制約にとらわれず、自由に設計できる点はスクラッチ開発の一番のメリットといえるでしょう。

自社の業務フローや顧客特性に合わせたシステムを開発できるため、既存システムと比較すると、微細な要求にも手が届く仕様に仕上げられます。

 

○ ライセンス料の負担がかからない

パッケージ開発の場合、元となるパッケージソフトにライセンス料を支払わなければなりません。

ライセンス料には、1度の支払いでよいケース（買い切り型）と、月額制で支払いを行うケース（サブスクリプション型）がありますが、いずれの負担も背負わなくてよい点も、スクラッチ開発のメリットです。

 

パッケージ開発のメリット

○ 初期費用が安い

既存システムをもとに開発するため、スクラッチ開発と比較して、相対的に初期費用を抑えることができます。

 

○ 開発スパンが短い

既存システムで使われているソースコードを一部流用して開発するため、ゼロからのスタートと比べると、開発期間を短縮できる点もメリットです。

 

スクラッチ開発とパッケージ開発のデメリット

次に、スクラッチ開発とパッケージ開発、双方のデメリットについても触れておきます。

 

スクラッチ開発のデメリット

○ 初期費用がかかる

システムの形態によって変動するため一概には言えませんが、一般的に数十万～数百万、規模によっては数千万円の初期費用がかかります。

 

○ 開発スパンが長い

ゼロから開発を手掛けるため、開発には数年を見越しておく必要があります。

システム導入にスピーディーさを求める場合には不向きです。

 

パッケージ開発のデメリット

○ かゆいところに手が届きにくい

パッケージ製品は、万人の顧客に対して、汎用的に活用してもらう目的で開発されているため、こまかなニーズには対応していません。

自社にフィットするシステムを求めるのであれば、パッケージをある程度カスタマイズする必要があります。

 

○ 機能に合わせた業務改善が必要

先述の通り、パッケージ製品は機能がある程度固定されているため、システムに合わせて業務フローを改善しなければならないケースもあります。

総じて、慣れるまでは従業員側に負担がかかる点もデメリットのひとつです。

 

スクラッチ開発 or パッケージ開発を選択した際のリスク

双方の手法について、メリット・デメリットを見ていただきました。

メリット・デメリットを踏まえたうえで、次にご紹介するのは、比較フェーズ時に抑えておきたいポイントです。

まずは、双方を選択した際に考えうるリスクについて触れておきます。

メリット・デメリットを理解していても、開発前の下準備が整っていない場合、下記のようなケースも発生しうることを念頭に置いておきましょう。

 

スクラッチ開発を選択した際に考えうるリスク

○ 要件定義の手戻りが発生してしまう可能性

スクラッチ開発は開発期間が長いため、開発段階での仕様変更も往々にして発生するケースが多いようです。

とりわけ、トレンドの移り変わりが激しい時代では、数年前にはよいと思っていた仕様設計が、システム完成後には時代にそぐわなくなる、といったリスクもあります。

このリスクはパッケージ開発にも少なからずいえることではありますが、ゼロから開発する分、スクラッチ開発の方がやや影響度は大きいといえます。

 

○ 一定の技術力を求められる

スクラッチ開発では、要件定義から仕様設計など、上流工程から踏み込んで開発を進めていきます。

このため、開発プロジェクトを進めるためには、ある程度の経験やスキルを持つエンジニアとともに進める必要があります。

( 詳細は当サイト関連コラム「スクラッチ開発とは？メリット・デメリットと進め方のコツを紹介」をご覧ください ）

 

パッケージ開発を選択した際に考えうるリスク

○ カスタマイズで結果的にコストが高くなってしまう可能性

パッケージ開発はカスタマイズできるケースもありますが、機能を盛り込んでいった結果、スクラッチ開発よりもコストがかかってしまったというケースも存在します。

 

○ 開発ベンダーの方針に運用面を左右される可能性

パッケージ製品の場合、開発を終了した時点でサポートが終了してしまい、その後の運用が困難になってしまう可能性もゼロではありません。

提供元は大手企業が多いため、頻繁に起こりうる事象ではありませんが、少なからずリスクとして存在します。

 

スクラッチ開発とパッケージ開発のリスクを避けるために

双方のリスクについてご紹介しました。

では、先述のような事態を防ぐためには、どのような点に気を付けておけばよいのでしょうか。

当項では、改めてどちらを選べばよいか、そして、導入を成功に近づけるためのポイントを3点ご紹介します。

 

ニーズを満たすパッケージ製品の確認

まずは、現状の課題を整理し、課題からどのような機能が必要かを整理しましょう。

求める機能を可視化した後は、その機能を持つパッケージ製品がないかをリサーチします。

求める機能を満たすパッケージ製品がない場合や、類似製品でも大幅なカスタマイズが必要な場合、いくつかの製品を複合して活用しなければならないケースであれば、スクラッチ開発を選択する方が無難です。

 

改善したい課題の独立性と優先度を精査

2つめに挙げられるポイントが、システム導入によって改善を図りたい事象の独立性と優先度のバランスです。

改善が急務となる場合はスクラッチ開発はどうしても不向きとなってしまう一方、その事象が業務や事業の重要事項と密接に関連している場合は、汎用的な機能だけでは対処しきれないケースもあります。

基幹システムなどはパッケージ製品で事足りるケースも多いですが、独立性を求める場合はやむなく開発期間に折り合いをつけなければならないケースも存在します。

どちらを取るか、自社の実態から検討しましょう。

 

信頼できる技術者の選定

最後に挙げられるポイントは、開発におけるエンジニアやベンダーの選定です。

スクラッチ開発はもちろんのこと、パッケージ開発においてもカスタマイズを行う場合はプログラミングの知識が必要なため、特に自社でエンジニアを保有していない場合、外部の力を借りる必要があります。

また開発に留まらず、開発後の保守・運用でも技術者の力は欠かせません。

外部の力を借りる場合は、一定の技術力だけでなく、できることとできないことやコスト面の開示など、透明性を重視して選定しましょう。

 

スクラッチ開発の対義語は「パッケージ開発」「SaaS」

スクラッチ開発に対して「パッケージ開発」「SaaS」の方法があります。

スクラッチ開発の対義語にあたるものです。これらを詳しく解説します。

 

パッケージ開発

パッケージ開発とはその名の通り、既存のシステムやパッケージを活用し、それを開発する形で、システムを作っていくことです。

スクラッチ開発と比較すると自由度は劣ります。

独自性のあるシステムにはならないデメリットはありますが、時間とコストは抑えることが可能です。

また社内にノウハウのある人材や技術者がいなくとも、開発が可能です。

 

SaaSの特徴

「SaaS」とは、「Software as a Service」を略した言葉で、クラウドでアプリケーション（ソフトウェア）機能を提供するサービスのことです。

「サース」もしくは「サーズ」と読みます。 SaaSはアカウントを作れば誰でも使用できるサービスです。

 

SaaSを使用するメリット

SaaSを使用すると様々なメリットがあります。

 

○ 比較的に安価で使用できる

SaaSのメリットは比較的安価で使用できることです。

オンプレミスと異なり、ハードウェアなどを購入する必要がないため、イニシャルコストはかかりません。

また、自社で開発する必要もないため、開発運用の費用もゼロです。

料金体系は使用料によって従量課金されることが多く、無駄な費用がかかりません。

 

○ 導入期間が短い

SaaSは既にクラウドで提供されているものを利用できるため、アカウントを作るとすぐに利用できます。

従来のオンプレミス型では導入期間が長く、早急に利用したい場合でも利用できませんでした。

迅速に導入できるため手間がかからないといったメリットがあります。

 

SaaSを使用するデメリット

上述のようにSaaSを使うと様々なメリットがある一方で、デメリットもあります。

ここからデメリットについて解説しましょう。

 

○ 自社用にカスタマイズできない

SaaSのデメリットは自社用にカスタマイズできないことです。

SaaSは基本的に用意されているソフトウェアを使用するだけのサービスのため、カスタマイズ性は高くありません。

用意されている機能だけで足りない場合、サービス提供者に独自のカスタマイズを依頼する必要があります。

それもできない場合、ソフトウェアの独自開発となってしまうでしょう。

 

○ サービスが終了したら使えなくなる

SaaSはサービス提供会社が終了すると使用できなくなります。

重要な書類を保存している場合、大きなデメリットになるでしょう。

 

長期的な企業戦略においてはSaaSはなるべく避けることが得策になる

SaaSは企業にとって、サービスが終了したら使えなくなるなど、システム開発に比べてデメリットのほうが大きいでしょう。

B to Cのサービスは個人用のため影響は大きくありませんが、B to Bの場合、終了するリスクは避けるべきです。

ソフトウェア開発はSaaSではなくシステム開発会社への依頼をおすすめします。

（※シーンによって例外はあります。)

 

システム開発の「ウォーターフォール型」「アジャイル型」と違い

SaaSの利用やパッケージ開発が企業においてはおすすめしづらいと述べましたが、そもそも、システム開発を依頼する場合、どのような種類があるのでしょうか？

システム開発には「ウォーターフォール型」と「アジャイル型」があります。

ここから具体的に見ていきましょう。

 

「ウォーターフォール型」の特徴

「ウォーターフォール型」とはシステム開発を行うための開発方法の1つであり、上から下に水が流れるように開発していくことです。

上から下に「作るものを決める」「作るために必要な機能を決める」「実際に作ったものをテストする」といった流れで開発します。

「ウォーターフォール型」では「V 字モデル」と呼ばれる流れで開発を進めていくため、全体像が見えやすいといったメリットもあります。

 

○ 「ウォーターフォール型」の開発フロー

「ウォーターフォール型」の開発フローは以下の通りです。

 

1. 計画

最初に要件定義を行います。

要件定義とは、システムの要件を決める作業のことです。

システム開発は、クライアントの要望を聞き具体的なシステムをイメージすることから開発がスタートします。以下の内容をクライアントと打ち合わせしながら、大まかに明確化していくのです。

 

2. 外部設計

外部設計とは「基本設計」とも呼ばれており、システムを使う方が実際に目にする部分を設計していく作業のことです。外部設計では、実際に作るシステムのイメージを明確化していきます。

 

3. 内部設計

内部設計とは、実際に作る際に必要なシステムの詳細を決めていく作業のことです。

具体的には、システムの機能ごとに次のことを決めていきます。

内部設計の役割は「プログラムで扱うデータ」などの具体的な処理の流れを決めていくことです。

実際にプログラムを作ることをイメージした上で作り、データベースを登録するテーブルなども決めていきます。

 

4. プログラミング（開発）

内部設計が終わったら、プログラミング（開発）を行います。

「外部設計」「内部設計」で作られた資料を読みながらプログラマーが実際にプログラムを作ります。

 

5. テスト

作ったプログラムが正しく動くかテストしていきます。

テストには「単体テスト」「結合テスト」「システムテスト」の3種類があります。

「単体テスト」は内部設計で作った動きが正しく動くか確認していくテストです。

「結合テスト」は、例えばアプリ開発などで複数の画面でデータが正しく登録・更新・削除・確認できるか、操作に問題がないかチェックします。

最後に「システムテスト」を行います。

「システムテスト」は要件定義で決めたレベルでシステムが動くか確認するテストです。

実際にシステムを使うことを想定したテストシナリオを作り、動作を確認していきます。

問題がなければシステムがリリースされるのです。

 

6. 運用

運用とはシステムを安定的に稼働させるための業務のことです。

リリース直後は不具合や使い方の問い合わせが多くなるため対応します。

問い合わせが減ってきたタイミングで、追加の機能を作っていくこともあるでしょう。

 

○ 「ウォーターフォール型」のメリット

「ウォーターフォール型」のメリットは下記の点です。

 

○ 「ウォーターフォール型」のデメリット

• 【修正・変更が難しい】

「ウォーターフォール型」は最初の段階で詳細に設計するため、修正・変更が難しいといったデメリットがあります。

また、急な変更のため手戻りがあると工数や人的コストがかかるでしょう。

 

「アジャイル型」の特徴

「アジャイル型」とは、ウォーターフォール型のようにシステム全体を作っていくのではなく、小さな機能に分けて「計画」「開発」「テスト」の流れで開発する方法です。

アジャイル型では、実際の動きを見ながら詳細な仕様を決めていきます。

 

○ 「アジャイル型」のメリット

• 【修正・変更が行いやすい】

最初に作るものを一通り決めてから作る「ウォーターフォール型」と異なり、「アジャイル型」はある程度の仕様を決めたらすぐに開発がスタートします。

このため、途中で変更がしやすいといったメリットがあるのです。

ウォーターフォール型は仕様をしっかりと決めてから作るため、変更する場合、要件定義・設計書の修正に時間がかかります。

しかし、アジャイル型では、ある程度のレベルであれば修正が簡単です。

 

○ 「アジャイル型」のデメリット

• 【スケジュール管理が難しい】

「アジャイル型」のデメリットはスケジュールが管理できないことです。

途中変更が多い「アジャイル型」は完成までの工程管理が難しくリリースの調整も難しいといった傾向があります。

また、何度も変更を繰り返すうちに最初の方向性と違ってくる場合もあるのです。

 

開発検討からベンダー選定まで、お悩みをお持ちの際は

双方の選び方から、選ぶ際に気を付けておきたいポイントについて解説しました。

今回は最低限抑えておきたいポイントとしてのご紹介ではありますが、実際に選定を進めると、以下のような課題に突き当たるケースも多いようです。

上記の お悩みをお持ちの方に、ぜひ検討視野に入れていただきたいのが「フリーランスエンジニアの活用」です。

フリーランスエンジニアと開発プロジェクトの期間のみ契約を結べることから、ランニングコストを抑えられる点や、一定のスキルを有するため即戦力として活躍できる点など、活用メリットが多い選択肢となります。

なお、IT・テクノロジー領域特化型エージェントサービス「HiPro Tech」では、下記のスキルを有する人材が活躍しています。

現状を見極め最適なベンダー選定をサポートできるITコンサルタント、要件定義からプロジェクトを丸ごと担えるPM、実際にコーディングを手掛けるプログラマーなど、必ずあなたのニーズを満たすエンジニアと出会えるはずです。

少しでも興味をお持ちいただけましたら、まずはお気軽にお問合せください。