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

1 スクラッチ開発とは
2 スクラッチ開発の流れ
3 スクラッチ開発との相性が良いプロジェクト

スクラッチ開発は、市販のパッケージソフトウェアやテンプレート（ひな形）を使用することなく、１からプログラムを生成し、システムを作り上げていきます。本記事では、このスクラッチ開発について、どのような進め方でシステムを作っていくのか、パッケージ開発とはどのような違いがあるのか、類似する言葉のフルスクラッチ開発とは何が異なるのか、こちらの３点について詳しく説明していきます。

スクラッチ開発とは

スクラッチ開発とは、先述の通り、システム開発のひな形にあたるパッケージソフトウェアやテンプレートといったものを使用せずに、１から独自のシステムを開発するものです。市販のパッケージソフトウェアには搭載されていないユニークな機能を開発したいときなどによく採用されます。中規模から大規模な企業であれば、社内の業務管理システムの大半をスクラッチで開発しているでしょう。スクラッチ開発は、システムを１から開発しますので、それ相応のコストがかかってきます。また１からプログラムを生成し、オーダーメイドのシステムを開発しますので、時間もかかります。システムの品質や使いやすさよりもコスト感や速度感を求める企業にとってはあまり向いていない開発手法ともいえるでしょう。

パッケージ開発との違い

パッケージ開発とは、既存のひな形や既製品のソフトウェアを利用した開発手法となります。出来上がりのテンプレートや部品（パーツ）を組み立てて、システムを作っていきます。企業の規模感やシステムに求めること（システム仕様）などによって、スクラッチ開発パッケージ開発のどちらが適切かは変わってきますので、まずはそれぞれの開発手法の違いについて理解し、詳しくは社内のエンジニアやシステム開発会社に確認しましょう。

画面の見映えや機能、ユーザインタフェースの使い勝手は毎日システムを使う利用者からすると、少しでも使いやすいものが良いと思います。明確なこだわりやビジョンがある場合にはスクラッチ開発を選択する方がベターでしょう。「とりあえず初期は動けば大丈夫。」という程度でしたら独自のシステムをスクラッチで開発する必要はないかもしれません。コスト感や速度感を求める会社であればパッケージ開発をおすすめします。

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

スクラッチ開発を採用するメリットは大きく４つあります。

長期間使用し続けられる可能性が高い

市販のパッケージソフトウェアなどを利用すると、運営会社の事情により、途中でサポート終了という事態も考えられます。そのような事態が起きてしまうと、新しく１からシステムを開発し直す必要が出てきてしまい、時間もお金もかかってしまいます。一方のスクラッチ開発の場合だと、途中でシステムが使用できなくなる心配はありませんので、長期間にわたって利用することが可能です。

競争優位性を持たせることができる

先述しました通り、スクラッチ開発の場合、柔軟な機能実装、機能改良が可能です。そのため、競合他社とは異なったシステム開発、カスタマイズができます。システムを上手く活用することで、定常業務の自動化、効率化が実現でき、延いては人件費などのコストダウンに大きく貢献します。将来への投資と考えて、市販のパッケージソフトウェアではなく、スクラッチでの開発手法を選定し、競争優位性や築く企業が増えています。

開発予算を調整しやすい

スクラッチ開発は、１からシステムを開発しますので、通常では他の開発手法と比べて価格が高くなります。ただ、オーダーメイドで機能や画面を開発しますので、不要な機能や画面を削除（開発を後回し）することでコストを調整しやすいといった利用もあります。年度予算に合わせて、今年度はXXまで開発し、来年度YYまで開発するといったフェーズを区切っての開発も可能です。

開発の融通が効く

市販のパッケージソフトウェアを使用する場合、セキュリティやネットワーク、インフラ環境などの設定は全て運営会社次第になってきます。サポートセンターに問い合わせをしても「現状はこのような設計・仕様なので、リクエストにはお応えできません。」といった回答が届き、時にはエンドユーザ（お客様）に多大な迷惑を掛けてしまうケースもあるでしょう。スクラッチ開発の場合、インフラ環境も１から構築していきます。またシステムダウンした際に即座に別の予備のサーバに繋ぎなおすといったことも可能なので、ありとあらゆるリスクに対処できることも一つのメリットとしてあげられるでしょう。

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

スクラッチ開発のデメリットは大きく２つに分かれます。

プロジェクトマネージャーの負担が大きい

スクラッチ開発では、あらゆる課題を吟味しながらシステムの機能要件・非機能要件・デザイン要件を定義しています。そのため、開発期間中は幾度となく利用者にヒアリング、情報収集を行う必要があります。そのため、兼務としてプロジェクトマネージャー役を任された担当者レベルだと、なかなか話が前進せず、プロジェクトの全体スケジュールがずるずる後ろに引っ張られてしまうケースもあります。大切なのは、トップダウン形式で自社のプロジェクトマネージャーに時間と権限を与えることです。