スクラッチ開発を選ぶべき状況とそのメリット

こんにちは!

ITエンジニア・webディレクター・webデザイナーなどのIT人材の自立・キャリアを支援するITプロパートナーズのCTOの柳澤(やなぎさわ)です。 弊社は、独立精神旺盛な優秀なエンジニアの方々の独立・起業サポートや、フリーランス支援を行っている会社です。

こちらの弊社運営「サイトスタートアップ開発ラボ STaP(スタップ)」では、企業の新規事業開発担当者の方や、システム開発責任者の方、事業責任者の方達に向けて、事業開発のコツや、自社プロダクトやWebサービスを立ち上げる際にポイントや注意点について、弊社ノウハウを包み隠さずにお伝えしています。

さて、今回はスクラッチ開発について見ていきます。

システム開発の方法は大きく分けて二通りに分けられます。

  1. 一つは既製品を使う方法で、いわゆるパッケージ開発と呼ばれる方法
  2. 既製品を使わずに独自に開発する方法

②の方法をスクラッチ開発と呼びます。

既製品を買うか、オーダーメイドで作ってもらうかと言えば、スーツと同じですが、システム開発の場合は既製品とオーダーメイド、それぞれにどういった特徴があるのかを今回は見ていきたいと思います。

スクラッチ開発とは

スクラッチ開発はオーダーメイド、パッケージ開発は既製品とご紹介しましたが、もう少しシステムのオーダーメイドとは、どういった特徴があるのか詳しいところを見ていきます。

よくシステム開発は家作りに例えられますが、大工さんが家を建てる前に、どんな家を建てるのか設計図が必要です。

システムを開発の場合は、プログラマーさんたちがシステムを実装していく前に、システムエンジニアが設計書を書きますが、更にその前、どういった機能が必要で設計書に落とし込まれていないとダメなのか、システム発注の要望に対して、開発側がどこまで実装することを合意したのかをまとめた、要件定義書というものが作られます。

スクラッチ開発の場合、この要件定義書作成に関し、まったくのゼロベースで、欲しい機能、実装して欲しい仕組みを、システム開発側に意見できるということです。

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

メリットはスーツのオーダーメイド同様に、自社の業務にぴったりの、まさに自社のためのシステムが納品されるという点です。

ただし、デメリットもスーツと同じで、時間もお金もかかります。

既製品のパッケージであれば、指定したシステムをSVにインストールして、あとは管理者設定すれば、最短でその日のうちに使えることさえあるなど、スピーディーな導入が可能です。

しかし、スクラッチ開発の場合、どんなシステムにするか話し合いを持つ必要があり、話し合いの内容に合意できてから、やっとシステムの開発が始まります。

納品前には開発されたものが、求めるシステムなのかどうか、念入りにテストする必要もあります。

そして、テストの結果が芳しくなければ、更にお金と時間をつぎ込んで改善させるか、開発失敗として案件自体をなかったことにするかの二つに一つです。

比較対象であるパッケージ開発についてもう少し見てみましょう。

パッケージ開発とは

続いてはパッケージ開発です。

こちらはスーツで言えば紳士服店に並んでいる既製品のスーツ、家で言えば壁の色など多少は変更できるものの、大枠はお客さんの要望で変えられないプレハブ住宅のようなものです。

パッケージ開発とはイメージ的には、マイクロソフトオフィスのようなものです。オフィスソフトが欲しいと考えている利用者はマイクロソフトオフィスを購入すれば、たいていの場合幸せになれます。

しかも、ワープロソフトだけあれば十分な人はWord単品で購入できますし、ワープロソフトだけでなく、計算表ソフトやメーラー、プレゼンソフトも必要であれば、Office Home & Businessを購入することも可能です。

利用者の要件を満たすパッケージを選んで導入するのがパッケージ開発です。また、マイクロソフトオフィスでは難しいですが、多少のカスタマイズができるパッケージもたくさんあります。

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

パッケージ開発のメリットは、利用開始までのスピーディーさと通常スクラッチ開発に比べて圧倒的に安いコストです。

反面、カスタマイズできるとはいえども、二階建てのプレハブ住宅を三階建てにするのは無理難題なように、自由度が高くなく、導入したものの、思っていたより効率化されなかったというケースも中にはあります、

パッケージ開発とスクラッチ開発どちらかで迷われている方もいらっしゃるかと思いますが、スクラッチ開発にするべき時があります。

スクラッチ開発を選択した方が良いとき

スクラッチ開発とパッケージ開発、それぞれの特徴が分かったところで、スクラッチ開発を選択した方が良いときについて、見ていきたいと思います。

パッケージがない場合

まず、当然ながらパッケージ開発したくても、パッケージがない場合はおのずとスクラッチ開発になります。

例えば、メガバンクの勘定系システムのような一点モノや、JRの座席件予約システム「マルス」の初期構築時のような、他社の先例となり業界のディファクトスタンダードになるようなシステムです。

競合他社が少ない、あるいはシステム化されていない業界への参入や、まったく新しいビジネスに乗り出す場合は、パッケージを使いたくても使えないと思っておいた方が良いでしょう。

自社オリジナルの機能を実装したい時

業務としてはパッケージがあるけれど、自社特有で付加したい機能がある場合もスクラッチ開発の方が良いかもしれません。

というのも、その付加したい機能が複雑でパッケージの根本部分にも手を入れる必要がある場合、開発期間についても開発コストについても、スクラッチ開発と大して差がないということもあるからです。

むしろパッケージとして完成されていたところを下手に改変した結果、バグを埋め込むリスクすらあります。

他社と差別化したい時

また、エンドユーザに対して自社サービスを競合他社と差別化するために、パッケージではなくスクラッチ開発を選択する企業も少なくありません。

企業ごとにカスタマイズ化するといっても、ベースは同じパッケージですので、おのずと使い勝手が似てしまいます。

しかし、スクラッチ開発であれば他社に比べて明らかな変化をつけることも可能です。

更に、パッケージ開発に比べスクラッチ開発の方が自由度が高いというのは、構築時だけの話ではありません。

エンドユーザの要望をシステムに反映しようとした際、パッケージ開発の場合は、パッケージの枠組みが邪魔になることがありますが、スクラッチ開発であれば、そうした制限はありません。

しかし私は、どちらか迷ったときはパッケージ開発をおすすめしています。

その理由について見てみましょう。

どちらか迷った時はパッケージ開発にした方が良い理由

最近のトレンドとして、基本的にはパッケージ開発を選択し、特別な事情があるものだけ、スクラッチ開発にするというのがもはや常識です。

特にどの企業でも必要で、大きく業界・企業ごとにスタイルが変わらないですし、変化をつける必要のないERPシステムの場合、クラウドERPも含めて、パッケージ開発ではないものの方が珍しいくらいです。

これはひとえに、パッケージ開発に比べて、スクラッチ開発は時間的・費用的コストが非常に重荷だからです。

しかもパッケージ開発は、すでに実績あるシステムを移植するようなものですが、スクラッチ開発は多額の支出に反して開発失敗するリスクがあり(IT業界では実に7割が失敗案件、という話が定説のように語られています)、費用対効果的に極めて不利です。

“よほどの理由”がない限り、パッケージに不満がなければ、パッケージ開発で実装するのがベターです。

中には、どの開発方法が最適か判断しかねている方もいらっしゃるかと思いますので、次に開発方法の選び方について記載しました。

業務の優先度で開発方法を分ける

パッケージ開発ではなく、敢えてスクラッチ開発を決断する“よほどの理由”とは、つまるところ、そのシステムが関係する業務の優先度です。

競合他社に優位に立つために必要な特別な機能を実装するのであれば、影響度を鑑み、コストをかけることに躊躇してはいけません。

ただし、スピード感が求められる場合は、パッケージ開発を選択する必要があります。

そのため、競合他社に先を越されぬように、パッケージ開発で低コスト・俊敏に初版をリリースしつつ、本命をスクラッチ開発という方法もあります。

逆にグループウェアなど、速やかに環境を整える必要があり、利用者は社内の人で業務に致命的な影響与えないシステムの場合は、パッケージで手軽に速やかに用意するべきです。

なお、スクラッチ開発とパッケージ開発は両立可能です。

ERPそのものはパッケージ開発ですが、ERPにつながった生産管理システムや在庫システムはスクラッチ開発という企業は非常に多いです。

まとめ

スクラッチ開発とパッケージ開発について今回は見ていきました。

基本的には特別な事情がない会切りパッケージ開発、必要に応じてスクラッチ開発です。

スクラッチ開発を選ぶべきかどうかは、判断に迷うことも少なくありません。

ITベンダーの営業などに相談し、相応しいパッケージがあるのか確認するのが大切ですが、そのためにはまず、なにをシステムにしたいのか、それがどれだけ重要なのか、はっきりさせることが大切です。

システム開発の依頼をベンダーなどに投げる前に、社内でシステムに求めるものをはっきりと明確化しましょう。

©︎2020 Hajimari inc.