スクラッチ開発とは？メリットやパッケージ開発との違い、将来性について解説

DXやペーパーレスなど、ITによる業務改善を進めるために多くの企業がシステムの導入を進めています。

一方で、システムの導入に失敗している企業も多いです。

世の中には多くの業務システムが開発、販売されており、利便性も急速に上がっています。

しかし、企業文化や独自の慣習により、便利なシステムを導入してもアンマッチングを起こし、せっかくのシステムを活かしきることができないといったケースが後を絶ちません。

ではどうすればいいのでしょうか。

その解決策の1つが「スクラッチ開発」です。

今回の記事ではスクラッチ開発について取り上げ、メリットやパッケージ開発との違いなどについて解説をします。

スクラッチ開発とは

スクラッチ開発とは、テンプレートを使用せずにゼロベースでオリジナルのシステムを開発することです。

最近のシステム開発では、フレームワークなどのテンプレートを利用して
「短納期で高品質なシステム開発をする」
事が求められています。

時代の変化が早いからこそ「製品化のスピード」も求められているのです。

一方で、世に出回っているシステムに備わっていない機能を実装する際には、スクラッチ開発が必要になります。

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

スクラッチ開発のメリットは大きく分けて2つあります。

1つ目のメリットは、独自性のあるシステムを開発できることです。

既存のシステムでは、利便性は高いが利用機会のない機能を備えていることがあり、企業にとっては無駄になるケースも少なくありません。

それに対してスクラッチ開発であれば企業文化や慣習に合わせて開発を進めることができるため、企業ごとに理想のシステムを開発できる期待があります。

2つ目のメリットは、ミニマムな改修をすることで長期に渡り利用可能であることです。

企業文化は一朝一夕に変化するものではありません。

そのためスクラッチ開発したシステムを稼働させて運用が始まれば、働き方に大きな変化が訪れない限りはそのシステムを継続して利用することができます。

ある程度の規模の企業になると、
「折角システムを導入したのに、現場の人間はやり方を変えてくれない」
というケースがあります。

そうなると、費用だけがかかって、結局業務効率が上がらない可能性があります。

そういった時には、
「今までの業務を極力変えないように、それでいて便利にはなる」
というシステム導入が求められます。

しかし、そんな都合の良い製品はないため、スクラッチで開発するのです。

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

一方、スクラッチ開発にはデメリットもあります。

デメリットの1つ目は、開発に時間を要することです。

オリジナルのシステムをゼロの状態から開発しなければならないため、開発にあたっては業務背景の理解や要件定義を丁寧に進める必要があります。

当然開発自体にもかなりの工数を要し、さらにはユーザーテストも漏れなく実施する必要があるため、実際に利用できるまでには年単位のスケジュールを組む必要があります。

2つ目のデメリットはコストが割高になることです。

既存のシステムであれば初期費用を抑えることができ、発生費用は利用料などのランニングコストが主になります。

しかしスクラッチ開発の場合は何もない状態から開発を始める必要があるため、開発に要するコストは相当な額になります。

3つ目のデメリットはベンダーによって品質に差が出やすいことです。

スクラッチ開発にはノウハウが必要です。

そのため、ベンダーのSEやエンジニアの質により成果物に大きな違いが生じてしまいます。

ベンダーには意向を汲み取ってアウトプットするスキルや、実際にプログラムを記述する知識や技術が求められます。

発注側にそれらを見きわめるのは難しいため、スクラッチ開発はトラブルが発生しやすい傾向にあります。

パッケージ開発との違い

スクラッチ開発と異なる手法として、パッケージ開発があります。

パッケージ開発は既に世に出回っているシステムを基本仕様とした上で開発を進める手法です。

既存のシステムとほぼ同一の機能にする場合もあれば、アドオンをして一部機能のみを追加や仕様変更するようなケースもあります。

パッケージ開発のメリットとしては、スクラッチ開発と違って既に出来上がっているシステムを利用することから、運用できるまでに要する時間が少なくて済みます。

また、コストについても抑えることが期待できます。

一方でデメリットもあります。

パッケージ開発のシステムは特定のユーザーに対して開発されたサービスではないため、企業によっては業務フローに見合わない仕様になっていることがあります。

仕様変更をしたい場合でも、汎用サービスであることから一企業の都合だけで改修することは難しく、
「システム側に業務フローを寄せる必要がある」
など、融通が利かないといったケースがあるのです。

また、これ以外には開発会社の都合によりサポート体制が急に終了してしまう、などといったリスクもあります。

スクラッチ開発か、パッケージ開発か

ここまで解説したように、スクラッチ開発にしろパッケージ開発にしろ、双方にメリットとデメリットがあります。

どちらを選択すべきかはケースバイケースのため、状況に応じて選択をする必要があります。

スクラッチ開発を選択するケース

スクラッチ開発を選択すべきケースとしては、特殊な商習慣が存在する業界や業種の企業、または独自の企業文化が根付いている企業の場合などが挙げられます。

また、国内と海外でもビジネスルールが違うため、内資系や外資系、という観点を持つことも必要です。

パッケージ開発のシステムは様々な業種に対応できる仕様となっていますが、汎用的過ぎるが故に特殊性を兼ね備えていません。

そのため、業務フローに特殊なルールや特別な拘りがある場合などはスクラッチ開発が向いているといえます。

パッケージ開発を選択するケース

パッケージ開発を選択するケースとしては、業界ルールが厳重に管理されていて変更が難しい場合などが挙げられます。

また、業務フローが既に確立されている、もしくは業務の仕組み化が進めやすい環境にあることもパッケージ開発を選択する上での判断材料になります。

今後も運用に大きな変化がないと予想できる場合は、パッケージ開発との親和性が高いと考えられます。

スクラッチ開発の進め方

スクラッチ開発は完成までに相当な時間を要することを先に述べました。

ではスクラッチ開発は具体的にどう進めるのか、そのフローについては以下の通りです。

要件定義→設計→開発→運用テスト→本番稼働

この一連のフローの中で最も時間を費やすべき部分が要件定義のフェーズです。

どのようなシステムを開発したいのか、そのシステムで何を実現したいのか、などを抜け漏れなくアウトプットをして、依頼元とベンダー関係者双方の認識を統一しなければなりません。

そうしないといざ開発が終了したタイミングで当初要件と違う設計のシステムができ上がってしまい、トラブルの原因になる可能性があるからです。

スクラッチ開発の将来性

スクラッチ開発は企業ごとの痒いところに手が届くような仕様を実現できるため、様々な場面で活躍をしてきました。

しかし、昨今のビジネスはスピードが重要であることから、スクラッチ開発には逆風が吹いている状況下にあります。

ここではスクラッチ開発の置かれている現状と、今後の見通しについてを述べたいと思います。

クラウドサービスなどの普及

逆風の1つ目の要因はクラウドやノーコード開発の普及です。

スクラッチ開発は難易度が高く、かつ開発に時間を要します。

一方、クラウドサービスやノーコードであれば開発の難易度を抑えることができる、かつ立ち上がりが早いことから需要が増加しており、スクラッチ開発のニーズは減少傾向にあります。

開発形態の変化

逆風の2つ目の要因は、システム開発の主流がウォーターフォール型からアジャイル型に変わりつつあるためです。

ウォーターフォール型開発とは、開発の最初から最後までの設計を一気通貫で開発するスタイルです。

一方、アジャイル開発とは要件を細分化し、機能ごとに分けて開発を進める手法です。

ウォーターフォールは一気通貫で進められる反面、途中で仕様の変更があった場合などは修正が難しく、手戻りが発生するというデメリットがあります。

その反面、アジャイル開発の場合は機能ごとに分けて開発をしていることから、途中の仕様変更にも柔軟に対応することが可能です。

このような理由から、最近のシステム開発はアジャイル開発が主流となっています。

スクラッチ開発にもアジャイル型はありますが、スピードという観点からはクラウドサービスのほうが親和性が高いといえます。

業界構造

逆風の3つ目の要因は人手不足と業界の下請け構造にあります。

インターネットの急速な普及により、システム化の案件がなくなることはありません。

しかし、需要はあっても実際に開発を担えるエンジニアが足りていないのが現状です。

スクラッチ開発はパッケージ開発と比べて時間も人も要するため、人手不足の現状では対応が困難であると考えられます。

また、多重下請けという業界構造が常態化していることも課題です。

下請けになるほど中間マージンが発生するため、給与面での待遇が悪いという状況にあります。

この点においても人手不足が解消しない大きな問題であるといえます。

スクラッチ開発の需要は残る

ここまで述べたようにスクラッチ開発に逆風が吹いているのは事実です。

しかし、スクラッチ開発の需要は今後も残ると考えられる理由があります。

理由の1つ目は、DXへの取り組みや、プラットフォーム戦略によるシステムの統一化の推進です。

DXやプラットフォーム戦略を実現するためには、システムの統一による業務フローの標準化が必要になります。

このような大型案件をクラウドサービスで解決するのは困難であるため、スクラッチ開発の力を存分に発揮するシーンであるといえます。

理由の2つ目は、2025年の崖問題といわれる旧システムの移行問題の解消です。

2025年の崖問題とは、老朽化したシステムの大規模改修が控えていることです。

システムの安定運用を維持するため、保守運用は必須となります。

これらのシステムはスクラッチ開発でなければ対応ができない案件であることから、今後も当面は需要が残ると考えられています。

システム開発はAMELAに

今回は、システム開発の方法である「スクラッチ開発」について見てきました。

業界的に見れば、少し逆風的な位置づけにあるスクラッチ開発ですが、企業によっては、有効活用が出来ます。

例えば、すでに複数のパッケージソフトを利用している場合。

その場合、データの連携が上手くいなかいケースがあります。

そうなると、間で手作業が入ったり、人間が操作することによるヒューマンエラーの可能性が出てきます。

こういった部分で、スクラッチ開発により、自動化をすることも出来ます。

規模によっては、スクラッチ開発でも安価に短納期で開発が進められます。

また、AMELAはオフショアでの開発を行っています。

通常のシステム開発に比べて費用が安いこともありますので、
「スクラッチで自社に完璧に適合した仕組みを作りたいけど、予算が・・・」
というお客様は、是非ご相談頂ければと思います。