「ここでいい」を「ここがいい」へ。発注先探しなら比較ビズで

システム開発外注者必見!スクラッチ開発とパッケージ開発の違いとは

最終更新日:2022年02月28日
 株式会社ラテラルリンク
監修者
代表取締役 岩井昌弘
システム開発外注者必見!スクラッチ開発とパッケージ開発の違いとは
この記事で解決できるお悩み
  • スクラッチ開発とパッケージ開発の違いが知りたい
  • 外注する際「スクラッチ開発とパッケージ開発どちらを選べば良いか?分からない」
  • スクラッチ開発の具体的な進め方が知りたい

システム導入では、サーバーやプログラムを用意し、必要とする仕組みや機能を実現させます。プログラムを準備する方法の違いでスクラッチ開発とスクラッチ開発があります。システム開発の外注に役立つように、2つの違い、それぞれのメリットデメリットなどを解説します。

システム導入におけるスクラッチ開発とは?パッケージ開発とは?

システム導入では、ユーザーが必要とする仕組みや機能を、どのように実現させるかが重要になります。サーバーやプログラムを用意し、実現させるのが一般的です。プログラムを用意する方法には、大きく分けて、

  • スクラッチ開発
  • パッケージ開発

2通りの方法があります。スクラッチ開発とはどのようなものか?パッケージ開発とはどのようなものか?それらの違いは何か?見てみましょう。

スクラッチ開発とは?

システム導入に必要なプログラムを、ゼロから作る方法を「スクラッチ開発」と言います。ユーザーが必要な機能や仕組みを、いわばオーダーメイドのように作るのです。

  • scratch

    「ひっかき傷」「ひっかく行為」などの意味があり、派生して「最初から」「ゼロから」などの意味を持っている

Java、C言語、COBOL、PHP、Ruby、pythonなど、様々なプログラミング言語の中から、適した言語を選び、要件に合わせたプログラムをゼロから作り上げていくのが、スクラッチ開発です。

基本的に、ユーザー自身もしくはユーザーが外注したプログラマーが、プログラミング言語を使ってプログラムを作ります。

ゼロからプログラムを作ると言っても、よく使われる機能などをテンプレート化したものを活用する、狭義の「スクラッチ開発」がある一方で、「フルスクラッチ開発」と呼ばれる方法もあります。

フルスクラッチ開発では、テンプレート化したものなどを使わず、全てゼロから作り上げるため、スクラッチ開発と区別する場合があります。しかし、どちらも、既製品を使わないという意味では同じです。

パッケージ開発とは?

スクラッチ開発がゼロからプログラムを作るのに対して、既製品のプログラムをまとめたパッケージソフトを活用する方法を「パッケージ開発」と言います。

パッケージソフトは、パッケージとかパッケージ製品、製品ソフトウェアなどと呼ばれることもあります。現在では、様々な種類のパッケージを見聞きするでしょう。

製造業、流通業、金融業など、特定の業界内でよく使われる仕組みや機能を実現させるパッケージもあれば、会計、ウェブサイト、コールセンターなど、様々な業界で共通に必要とされるものを実現させるパッケージもあります。

また、導入するだけでほぼ何もせず使い始めることができるパッケージがある一方で、ユーザー固有の仕組みや機能を追加・拡張したりカスタマイズできるパッケージもあります。

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

パッケージ開発、スクラッチ開発、どちらも、多くの企業や団体で採用されているシステム導入の方式です。

2つの違いをごく簡単に表現すれば、パッケージを使用しないシステム導入が、スクラッチ開発だと言うことができます。どちらの方法を選択するかによって、システム導入に必要となる費用や期間が大きく違ってきます。しかし、一概にはどちらの方法が良いと言い切ることはできません。

  • 準備できる費用
  • 使い始めるまでの期間
  • システム化したい仕組みや機能
  • 性能

など様々な要素で、適した方法を選ぶのがおすすめです。スクラッチ開発、パッケージ開発、それぞれのメリットとデメリットを理解したうえで、選択しましょう。

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

スクラッチ開発は、比較的には大企業などが利用する基幹システムなどで採用される事が多い傾向があります。もちろん、中小規模の企業や、個人事業主であっても、スクラッチ開発を選ぶこともあります。

スクラッチ開発を選ぶときに大切なのは、スクラッチ開発のメリットに当てはまること、デメリットを許容できることと言えるでしょう。

スクラッチ開発の最大の特徴は、ゼロから作り上げることです。このことから生まれるメリットとデメリットの例を順に紹介します。

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

独自性のあるシステムを作れる

スクラッチ開発では、ゼロからシステムを作り上げるので、ユーザーの要件に柔軟に対応することができます。費用や期間など、リソースが許す限り、必要な仕組みや機能を全て実現することが可能です。

そのため、ユーザー独自の要件や特殊事情がある場合は、パッケージには含まれない事が多いので、スクラッチ開発を選ぶことになります。

長期間使うことができる

スクラッチ開発で作り上げたプログラムは、利用期間に制限はなく、ユーザーが望む限り、長期間使い続けることができます。

プログラミング言語によっては、バージョンアップがあり、プログラムの修正や、稼働確認テストが必要となるケースもありますが、基本的には使い続けることができます。パッケージ開発をすると、パッケージで定められたサポート期間を超えて使うことができません。

パッケージでは、定期的なバージョンアップが行われることが多く、いくら安定稼働していたとしても、バージョンアップ後に、画面が変わったり、ユーザーが必要とする仕組みや機能がなくなったりする恐れがあります。

予算に合わせた開発ができる

スクラッチ開発では、ユーザーの要件に合わせてすすめるのが基本であるため、必要な機能であっても、予算の都合に合わせて、システム化するものを取捨選択したり、優先順位付けすることができます。

たとえば、自社の基幹系システム全体を作り変えたいのに予算が足りない場合、スクラッチ開発では工夫して対応することができます。

システム全体の構想・設計を立てたうえで、機能Aを今年度に開発・リリースし、機能Bを来年度に、機能Cを再来年度に、それぞれ開発・リリースするなど、フェーズに分けて対応するといった方法をとることも可能です。

もちろん、パッケージ開発でも可能な場合がありますが、スクラッチ開発ではより柔軟に、予算に合わせた対応が可能です。

システムのブラックボックス化を防ぐことができる

現代社会では、多くのシステムが動くことによって成り立っています。ひとたび、システムトラブルが起これば、混乱が生じます。

企業システムでシステムトラブルが起こると、直接的な損害が生じるだけでなく、企業イメージの低下などが生じる恐れもあります。それを防ぐための1つの方法として、システムのブラックボックス化を防ぐことが求められます。

スクラッチ開発では、プログラムをゼロから作り上げているため、全ての内容を把握することが可能です。そのため、システムのブラックボックス化を防ぐことができます。

プログラム著作権の帰属は明確に

ただし、外注する場合などは、プログラムの著作権を誰に帰属させるのか、明確にしておく必要がありますので、十分に注意しましょう。

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

開発期間が長くなる

スクラッチ開発では、ユーザーの要件をまとめ上げ、設計・開発・テストしたのちに、リリースする流れを取ります。このため、どうしても開発期間が長くなってしまいます。使い始めたい日が決まっていたり、法令対応などで期限が決まっている場合は注意が必要です。

費用が多くかかる

スクラッチ開発では、費用が多くかかるのもデメリットの一つです。ゼロから作り上げる必要があるため、対応すべきことが多く、人や期間などリソースが多く必要となります。その分、費用が多くかかってしまうというわけです。

必要な仕組みや機能の全てをシステム化するには膨大な費用がかかるような場合でも、内容の見直しや、フェーズに分けて対応することで、費用を抑えることができる可能性があります。

外注先選びに苦労する

スクラッチ開発の成功のカギを握っているのは、プログラマー・エンジニアの質だ!と言っても過言ではありません。しかし、残念なことに、優秀なプログラマー・エンジニアの数は少なく貴重で、確保できたとしても費用が掛かります。

世の中には、システム開発を請け負う会社や、プログラマー・エンジニアが、多数存在しています。そのなかから、優秀な人や、それを抱える会社を見つけ出すのに苦労します。

また、IT業界はピラミッド構造になっており、外注先が見つかったとしても、外注先から他の会社やエンジニアへ再委託・再々委託されることが普通に行われます。

再委託・再々委託そのものは悪いことではなく、技術進化が激しいIT分野では、得意なエンジニアが確保できるなら必要なことでしょう。

しかし、管理態勢が行き届かない場合は、情報漏洩などのセキュリティ事故が起こるリスクが高くなります。外部委託する場合は、再委託・再々委託を含む実体をしっかり確認し、契約書や覚書にして文書で合意しておくことが望まれます。

安定稼働するまで苦労する

スクラッチ開発で作り上げたプログラムは、他では稼働実績がありません。リリースまでに、エンジニアやユーザーがテストを行いますが、バグやシステムトラブルのリスクをゼロにすることは難しいです。

「プログラムは枯れた方が良い」と言われることもありますが、システムは使う期間が長くなればなるほど、発生したバグやシステムトラブルへ対応が進むため、安定稼働できるようになります。

システムの規模や複雑性によって異なりますが、新たに導入したシステムが安定稼働するためには、一定期間が必要になります。その間に、バグの修正、システムトラブル対応、それらに伴う顧客対応など、苦労が絶えません。

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

スクラッチ開発のメリットがなかったり、デメリットを受容出来ない場合は、パッケージ開発を選ぶことになります。パッケージ開発においても、メリットとデメリットがありますので、その例を順に紹介します。

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

短期間で開発できる

パッケージ開発では、すでに製品として販売されているプログラムを使うため、ゼロから作り上げるスクラッチ開発と比べると、短期間でシステム導入をすることが可能です。法令対応などでシステム化対応機関が限られている場合などには、パッケージ開発は非常に有効です。

カスタマイズなどの数で期間が延びる可能性もあり

パッケージ開発でも、追加・拡張開発、カスタマイズなどの数が増えると、その分、期間が延びるので注意が必要です。

費用を抑えることができる

パッケージソフトは、多くのユーザーに使われることを前提に販売されているため、それぞれのユーザーにとっては、同じような仕組みや機能をシステム化する場合は、スクラッチ開発溶離も費用を抑えることができます。

多くのパッケージでは、オプションやカスタマイズできる範囲があったり、追加・拡張開発できます。スクラッチ開発程ではないですが、予算に応じた選択肢が用意されています。

安定稼働に対するリスクが低い

パッケージ開発の最大のメリットは、安定稼働に対するリスクが低い点です。新発売されたパッケージだと、少し不安は残りますが、スクラッチ開発と比べると、そのリスクは低いです。

クラッチ開発の場合は、バグやシステムトラブルは、ユーザー特有のものなので、顕在化したことによって対応に追われることになります。

一方で、パッケージ開発の場合は、他のユーザーで顕在化したバグなどがきっかけで、自分自身には影響が出ないうちに、修正版が配布され、対応が完了することがあります。

定期的なバージョンアップが行われるパッケージでは、常に開発・販売元のエンジニアがバグ対応、脆弱性対応などをおこなっており、安定稼働に期待が持てます。

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

独自性があるシステムが作れない

パッケージ開発では、ユーザーの独自性を反映させることが難しいです。カスタマイズ機能があれば、ある程度の独自性を出すことができますし、追加・拡張開発して独自性を出すことも可能です。しかし、どうしてもパッケージの許容する範囲に限定されてしまいます。

会計、ウェブサイト、コールセンターなど、様々な業界で共通に必要とされるものをシステム化する場合、パッケージ開発を選ぶことが多いです。その中でも、自らの戦略などに直接関係する仕組みや機能が必要な場合は、それらが対応できるか見極めることが重要です。

業務がシステムに制約を受ける

パッケージのカスタマイズできる範囲にもよりますが、パッケージ開発を選択すると、ユーザーの業務がシステムに制約を受ける恐れがあります。譲れない仕組みや機能が、パッケージで実現可能なのか?しっかり事前に検証することが求められます。

よくある事例としては、画面の並びや、帳票の種類などです。慣れてしまえば問題ないものも多いですが、システム導入直後は混乱が起こることもあります。リリース前に、ユーザー研修を行うなど、十分な準備を行うことでその混乱を防ぐことができます。

システムがブラックボックス化するリスクがある

パッケージでは、どのようなプログラムが動いているのか、通常は知ることができません。そのため、ユーザーが期待する動きをしなかった場合でも、それがバグなのか?ユーザーの操作ミスなのか?その他の理由なのか?ユーザーはわかりません。

いわゆるブラックボックスの状態になっています。このブラックボックス化が、システムトラブルが起こった時、解決まで時間がかかる要因になる恐れがあります。

また、ブラックボックス化したシステムは、パッケージを開発・販売するベンダーに対する依存度が高くなる事が考えられます。ベンダーの倒産や撤退などによって、パッケージのサポートが打ち切られたり、トラブル対応ができなくなる可能性がゼロではないことを理解しておくことが求められます。

スクラッチ開発の進め方

システム導入の進め方は様々です。ウオーターフォール型と呼ばれる、代表的な進め方や、アジャイル、スクラムと呼ばれる比較的新しい進め方などが広く使われています。

ここでは、スクラッチ開発で採用されることが多いウォーターフォール型を想定して、その進め方を紹介します。

要件定義

システム導入で最も大切なフェーズが、要件定義です。文字通り、システム化する「要件」を「定義」する段階です。

どのような仕組み・機能をシステム化するのか?について、ユーザーが主体となって、要件を洗い出し整理し、まとめ上げます。これが不十分だったり、曖昧だったりすると、以降の工程で、後戻りが起きやすくなります。

後戻りが起きると、追加の費用が掛かったり、期間が伸びたりする恐れがあるので、気を付けましょう。 作り直しや、システム導入の中止など、最悪のケースに至ってしまった事例も多くあります。

パッケージ開発でも要件定義を行うことがありますが、スクラッチ開発では、ベースとなるものがありませんので、より手間と時間をかける事が望まれます。

設計

要件定義に基づいて、エンジニアがプログラムなどをどのように作るかについて、決めていきます。それが設計のフェーズです。

画面や帳票などのユーザーインターフェースのほか、プログラムの内部や、他のシステムとの連携など、様々な部分を設計で明確にします。

大きなプロジェクトになると、外部設計・内部設計にわけたり、概要設計・詳細設計に分けて、すすめることもあります。

開発

設計に基づき、プログラムを作ります。多くの場合、複数のエンジニア・プログラマーが関わるため、プロジェクトの中では、最もリソースが必要となるフェーズです。プログラム単体で稼働確認をする単体テストが含まれることもあります。

テスト

開発したプログラムが、設計や要件定義通りにきちんと動くかどうか検証をします。大きなプロジェクトになると、結合テスト、連携テスト、運用テスト、システムテストなど、様々なテストを実施し、リリースしても問題がないことを念入りに確認します。

リリース

テストが完了すれば、実際にユーザーが業務で使えるようにリリースします。既存システムがある場合は、新システムへの移行や、並存稼働することもあります。リリースが無事終われば、運用フェーズに移ります。

スクラッチ開発を選ぶ際のポイント

実際に、システム導入をする場合、これまで解説・紹介した内容をふまえた上で、さらに、何をポイントにして、スクラッチ開発に決めればよいのか?解説します。

要件を満たすパッケージがあるか?ないですか?

まずは、システム化したい要件を満たすパッケージの有無が、ポイントになります。そもそも、要件を満たすパッケージがなければ、スクラッチ開発を選ぶしか方法がありません。

また、パッケージ開発を検討したものの、パッケージの制約によりカスタマイズができない場合など、スクラッチ開発を選ぶ場合もあります。

さまざまなパッケージが存在するため、探すのは大変です。取引があるシステム開発会社があれば、相談するのも有効ですし、同業者の動向を探るのも有効です。

本当に独自のシステムが必要か?

システム化したい仕組みや機能は、本当に独自のシステムが必要なのか検証することも必要です。パッケージを使うと、業務に制約を受けたり、いままでの業務フローを変えなくてはいけない場合もあります。

しかし、冷静に判断すべきです。本当にそれらは、独自システムとしてスクラッチ開発する必要があるものなのでしょうか?これまでの業務をそのままシステム化することは可能です。しかし、その分、時間や人など多くのリソースと、それに応じた費用が必要になります。

システム化のタイミングは、業務の見直しのタイミングかもしれません。本当に独自のシステムが必要か?パッケージに合わせることで、業務改善や効率化できないか?見直すことも重要です。

開発・保守態勢を整えられるか?

スクラッチ開発では、開発・保守態勢を準備できるか、見極めることも重要なポイントです。特に、保守体制は見落としがちですが必要不可欠です。

システムは導入・リリースしただけで終わりではありません。使い続ける限り、バグ対応、トラブル対応などの保守態勢、制度変更、要件変更に対応するための開発態勢が必要です。

パッケージ開発の場合は、サポート契約を結べば、開発・保守態勢は整います。一方で、スクラッチ開発では、ゼロから作り上げたプログラムを、誰がどのように守るのか、態勢を整える必要があります。

おわりに

システム導入において、スクラッチ開発かパッケージ開発か検討する場合は、この記事で紹介したそれぞれのメリットとデメリットを、あなたの状況に照らし合わせて、比較することをおすすめします。

外注をお考えの場合は、その比較した結果をもとに、ベンダーなどと相談すると、話が進めやすいでしょう。

あなたの状況に応じた適切なシステム導入が選択でき、無事リリースされることをお祈りしております。

監修者の一言

どちらが良いかは、これから開発するシステムの種類にもよってくるでしょう。例えば、ECシステムにおけるカート機能や決済機能は、必ず付随する機能です。同様に、CMS(コンテンツ管理システム)、顧客管理システムといったものも、会社が変わっても基本的な機能は共通ですので、パッケージ製品を土台とするのがよいでしょう。

カスタマイズ可能な範囲は、パッケージによって異なりますので、どの程度カスタマイズが可能かという点は、十分に確認しておく必要があります。一方で、基幹業務を効率化するようなシステムでは、会社によって独特な業務の流れがあったり、過去の資産を有効活用するために他システムとの連携が必要なったりといった、特有の事業がある場合も多く、パッケージよりも、独自開発を選択する場合が多くなるでしょう。

システム開発においては、記事にもあるとおり“自社の環境の徹底的な洗い出し”を実施した上で、あるべき姿(システム)を描き、今回開発する範囲を定めていきます。“あるべき姿”へ道筋も考慮した上で、独自システムか、パッケージか、といった観点も取り入れることが必要です。

 株式会社ラテラルリンク
代表取締役 岩井昌弘
監修者

徳島県出身。名古屋大学情報文化学部卒業。同大学院人間情報学研究科修士課程修了。2006年有限会社ラテラルリンクを設立。名古屋市で、Webシステム開発を中心に、Web構築全般、Web活用支援に従事。クライアントは、中小・零細企業から東証一部上場企業、国立大学まで幅広いニーズに対応。経済産業省認定「スマートSMEサポーター」。

Webシステム開発を一括見積もりで発注先を楽に探す
Webシステム開発を一括見積もりで発注先を楽に探す
比較ビズへ掲載しませんか?

一括見積もりで発注先を探す