フルスクラッチとは？システム開発における使われ方とメリット・デメリットを紹介【2024年最新版】

システム開発における「フルスクラッチ」は、一からシステムを開発することを指します。細かい要件にも対応していけるので、開発手法としては魅力的に映ります。

しかし、細かい要件に対応することでシステム開発をしていくうえでのリスクが大きくなるのも事実です。今回は、フルスクラッチの意味とメリット・デメリットについてお伝えします。

フルスクラッチとは、既存のものを使用せず、一から全てを作り上げることです。システム開発においても「フルスクラッチ開発」という言葉でよく使われます。

何もない状態からどのようにシステムを組み上げるのか疑問を感じる人もいるかもしれません。しかし、一般的には最初に「要件定義」という工程があり、顧客に対して要件をヒアリングすることから始まるので問題ありません。

例えば、ホームページであればまずは顧客の要件をヒアリングし、顧客の要望をもとにして、自社の得意分野も考慮しながら開発仕様を決め、プログラムを組んでホームページを構築します。

業務アプリケーションの場合でも大筋の流れは変わらず、顧客の要件を元に仕様を決定し、一から業務アプリを設計して構築します。もとは模型の分野で使われていた和製英語でしたが、IT分野でも広く使われるようになりました。

世の中には「スクラッチ開発」という言葉もありますが、実は「フルスクラッチ」と意味の違いはありません。どちらを使うかは、表現したいニュアンスによります。

自分たちで一から作ることを強調したい場合は、「フルスクラッチ」と言うことがよくあります。一方、既存の製品を使わずに一から作ります程度のニュアンスであれば「スクラッチ開発」という言葉を使うことが多くあります。

今回お伝えするアプリケーションやツールの導入方法は3つです。
・フルスクラッチで開発する
・クラウド/SaaSソフトを利用する
・パッケージソフトを（カスタマイズして）利用する

一見、この3つの方法は全く違うことのように見えますが、実は大筋の流れに違いはありません。大筋の流れは以下の通りです。

1.要件定義
顧客より要件をヒアリングし、どのようなシステムを作るか決めます。

2.方式設計
要件が決まったら、使用言語など、どのような仕様・方針で作るかを決めていきます。

3.詳細設計
方式設計で決まった内容をもとにシステムの詳細を設計していきます。

4.実装
詳細設計の内容をもとに機能を実装します。プログラミングもこの工程で実施しましょう。

5.単体テスト
システムの単一機能ごとに、想定通り動くかテストを実施します。

6.結合テスト
構築したシステムの機能連携がうまくいくか、既存のシステムとの連携がうまくいくかなどをテストします。

7.運用テスト
要員の動きも交えて、実際にシステムが使われる場面を想定してテストします。

もちろん、導入方法によっては不要な工程も出てきます。3つの導入方法について、それぞれ内容を詳しくみていきましょう。

先ほど紹介した通り、一からシステムを組み上げることを指します。フルスクラッチで開発する場合の各工程は以下の通りです。

1.要件定義
フルスクラッチ開発は通常パッケージソフトを活用するよりも開発費用がかさみます。フルスクラッチでのシステム開発実施を決めるには、ある程度詳細な要件定義を実施する必要があります。なぜなら一般的にはコストを抑えてシステムを作りたいと考える企業が多いからです。

要件定義について詳しく知りたい方は以下の記事も併せてご確認ください。
システム開発外注の要件定義の流れ
要件定義の８つの手順と必要な６つのスキル

2.方式設計
実施内容としては、ソフトウェアの構造、データベース構造の最上位レベルの設計、後ほど実施する結合テスト要件の策定などが挙げられます。

ここではソフトウェアコンポーネント一つひとつの詳細については触れず、全体から見た概要レベルの事項を設計します。方式設計の成果物である方式設計書が完成したら、顧客と方式設計書のレビューを実施していきます。

3.詳細設計
方式設計で決まった内容をもとにシステムの詳細を設計していきます。個々のソフトウェアコンポーネントについての設計もこの段階で対応。

また、ソフトウェアインターフェースの詳細設計、データベースの詳細設計などもこの段階で実施し、利用者文書も詳細設計の内容に応じて更新していきます。詳細設計書の成果物である詳細設計書が完成したら、方式設計書と同様に顧客レビューを実施します。詳細設計の結果、方式設計内容に問題が発覚した場合は、適宜方式設計内容を修正し、顧客との再レビュー実施が必須です。

4.実装
詳細設計の内容をもとに実装します。プログラミングを実施していく中で、詳細設計書や方式設計書の内容と乖離が出てくる場合もあります。その場合は修正点を取りまとめて、顧客と再レビューを実施し、修正点について合意していくのがセオリーです。

基本的には設計書で決めた内容に従って実装するだけなので、協力会社や海外の企業へ実装を委託する場合もあります。

5.単体テスト/6結合テスト/7.運用テスト
システムが機能要件を満たしていないことが発覚した場合は、該当箇所を修正します。詳細設計書や方式設計書の修正が必要になる場合は、該当箇所を修正し、再度顧客レビューを実施します。


フルスクラッチでの導入は、大半の場合、全ての工程を緻密にこなし、顧客との密な連携が必要になってきます。工程ごとの成果物提出・修正はプロジェクトを進めるにあたって必須です。

現在では、さまざまなクラウド/SaaSのソフトが開発されています。クラウド/SaaSソフトを利用すると、多くの場合コストや工程を省くことが可能です。クラウド/SaaSソフトを使う場合でも開発には変わりありませんので、一般的には、以下のような順番で進みます。


1.要件定義
クラウド/SaaSソフトを利用する場合は、本格的な要件定義に入る前に顧客側で利用を決めていることもあります。また、要件定義の段階で「〇〇社の××というサービスを使いたい」と打診が来ることも。ITベンダーからコストダウンのためにクラウド/SaaSシステムを提案していくことも場合としてはあります。

2.方式設計
主に既存システムと新規導入のクラウド/SaaSシステムを連携させるための設計をしていくことになります。既存システムが自社開発のものであればスムーズですが、他のITベンダーが開発したものであれば、調整に手間がかかる場合も。

既存システムのITベンダーは新規導入システムのための調整を費用に見込んでいない場合もあるので、顧客に既存システムのITベンダーへ調整費用を支払うように依頼する必要があります。

3.詳細設計
引き続き既存システムとの連携を考慮して設計します。

4.実装 /5.単体テスト
導入するクラウド/SaaSソフトによっては、既存システムとの連携だけ気にすればよく、実装や単体テストが必要ない場合もあります。

6.結合テスト/7.運用テスト
クラウド/SaaSソフトの導入によって変更がある部分をテストします。既存システムのITベンダーにもテストに参画してもらう場合は、当然テスト費用の見積書を取得し、費用を支払う必要があります。

1.要件定義
パッケージソフトの導入では、カスタマイズが必要かどうかの観点から要件をヒアリングしていくことになります。

カスタマイズが不要な場合は、そのままパッケージを導入できるため費用も安く、パッケージソフトの保守サポートも既存のサービスメニューを利用できるので、導入費用を安くできます。カスタマイズが必要な場合は高額な保守サポートが必要になる場合もあるので注意が必要です。

2.方式設計/3.詳細設計
クラウド/SaaSソフトを導入する場合と同じく、既存システムとの連携を考慮して設計します。

4.実装
パッケージソフト導入は、ソフトをインストールしてしまえば実装できることがほとんどです。その他の作業要件がないかは事前に調査し、もしあれば実施します。

5.単体テスト/6.結合テスト/7.運用テスト
既存システムとの連携を考慮してテストを実施します。


パッケージソフトの導入は、ソフトを業務に合わせるのではなく、いかに業務をソフトに合わせられるかが導入費用削減のポイントといえるでしょう。

ここまで各導入方法の内容を見てきましたが、各導入方法のメリットやデメリットはどんなものがあるのでしょうか。ここでは、各導入方法のメリットやデメリットをみていきます。

メリット
・一からソフトを設計できるので、細かい要件にも対応しやすい
・追加要件が出てきた場合にも、ある程度対応できる
・保守運用の対応もソフトを開発したITベンダーに頼みやすい

デメリット
・一からソフトを開発するため、時間がかかる
・業務が複雑であればあるほど、コストが膨れ上がる
・ITベンダーの対応が悪かった場合、他の会社に変更しにくい

メリット
・自社で設備を持つ必要がないので、ハードの保守を考慮しなくてよい
・自社でシステムを開発するよりも費用を安くできることがある
・大抵のクラウド/Saasソフトは費用を支払って申請するだけで使えるようになる

デメリット
・日本の法律ではなく、クラウド/Saasソフトを運営している国の法律が適用され、自社に不都合なことが発生する場合もある
・ネットワーク障害が発生した場合はシステムが利用できない

メリット
・業務をソフトの仕様に合わせられれば導入費用を安くできる
・カスタマイズメニューが豊富なパッケージソフトもある
・一般的にフルスクラッチでソフトを作成するよりも導入コストを相当安くできる

デメリット
・フルスクラッチほど自由なカスタマイズはできない
・複雑なカスタマイズをしてしまうと、ソフトの保守費用が高くつくこともある
・ソフトに問題があっても、即時に改修してもらえないこともある

では、実際にシステムを開発するうえで、目的から導き出される「要件」を定義していくには、どのようにすればよいのでしょうか。最後にフルスクラッチ開発を実施する場合に絞って、要件定義の方法をお伝えします。

フルスクラッチ開発の目的で意外に多いのが、「上から作れと言われたから」という要件。確かに経営層の意見は尊重すべきかもしれませんが、これでは絵に描いた餅になりかねません。課題をはっきりと把握し、なぜフルスクラッチで開発するのか理由を明確にしましょう。

クラウド/SaaSシステムやパッケージソフトでも対応できる課題であれば、無理にフルスクラッチで開発しない方が無難です。

要件上、どうしてもフルスクラッチの開発でないと対応できない場合は、費用感の見積もりに入りましょう。費用感が不明な場合は、自社で開発する場合でもしない場合でも、複数のITベンダーへ見積もりを打診してみると費用感がわかります。

費用感が不明で困っている場合は、一度ITベンダーへ見積もりを依頼してみることをおすすめします。見積もりだけであれば、無料で対応してくれるITベンダーがほとんどです。

システム開発を進めていくと設計などの修正が必要になる場面がいくつも現れます。また、作業が遅延する状況が出てくる場合もあるでしょう。そんな時、期間を定めていないとズルズルとスケジュールが遅延しがちです。最初に根拠を持ったフルスクラッチ開発の期間をはっきりと定めておきましょう。

最後に、システム開発を外注した際にかかる費用相場をご紹介します。

システム開発の費用相場をご紹介しました。より正確な費用を知りたい方は料金シミュレーターをご利用ください。

フルスクラッチでの開発は、細かい要件にも柔軟に対応できるので、開発手法として選択されがちです。

しかしながら、フルスクラッチ開発には膨大な費用と期間を要します。フルスクラッチ開発の担当者にかかる負担も相当なものになるでしょう。本当にフルスクラッチ開発が必要なのかどうかは担当者間で検討し、慎重に対応していきましょう。

システム開発に関連する記事も豊富にありますので以下の記事もご覧ください。
システム開発外注のおすすめ会社
システム開発の費用・相場