フルスクラッチ開発とは？用語の意味とシステム開発を成功に導く要点を解説
こんにちは。Wakka Inc.のWebディレクターの安藤です。
システム開発手法のひとつにフルスクラッチと言われるものがあります。IT用語としてはよく使われるので、システムにたずさわったことがあれば一度は聞いたことがあるかもしません。そうはいっても、
「聞いたことはあっても意味はきちんと理解できていない」
「意味はわかるけれど、特徴や導入のポイントはよくわからない」
という方も多いのではないでしょうか？そこでこの記事では、フルスクラッチの意味、メリット・デメリット、開発を成功させるためのポイントについて解説していきます。ぜひ最適なシステム導入への疑問や不安の解決にお役立てください。
Wakka Inc.ではフルスクラッチ開発を得意としています。フルスクラッチ開発のちょっとした疑問から お見積もり依頼までお気軽にお問合わせください
お問い合わせはこちらから。
●開発リソースの不足にお悩みなら●
＞＞＞Wakka.Inc独自の海外子会社設立サービスがおすすめ！
無料でサービス資料をダウンロードできますのでぜひご覧ください。
フルスクラッチの意味
フルスクラッチとは
スクラッチという言葉には、IT用語でゼロから新たに作るという意味があります。
つまり、既製品や部品などの土台となるものがあってそれをもとに作り上げていくのではなく、何もないゼロの状態からシステムを生み出すという意味で、IT業界では一般的にスクラッチ開発と呼ばれています。これはスーツでたとえるなら、オーダーメイドです。
店舗で販売されている既製品のスーツを選ぶのではなく、自分の体にあったサイズのスーツをオーダーしてゼロから自分用に作り上げてもらうのと似ています。つまり、オーダーメイドのスーツのように、自社にあったオリジナルなシステムをゼロから作り上げてもらうのがスクラッチ開発です。
フルスクラッチ開発とスクラッチ開発の違い
スクラッチ開発の中でも単に「スクラッチ」と呼ぶ場合と、とくに意味をわけて「フルスクラッチ」と呼ぶ場合があります。
ゼロからシステムを作り上げるという点で大きくは同じようなことを意味しているのですが、あえて「フルスクラッチ」という場合は少し意味合いが変わってきます。スクラッチ開発がゼロからシステムを作り上げることを意味しているといっても、厳密には
- テンプレートをもとにシステムを構築している
- フレームワークや既成の部品を組みあわせて構築している
ということが多いのです。その中で「フルスクラッチ開発」と呼ぶ場合には、使用するテンプレートやフレームワーク、部品なども含めすべてゼロから作り上げる開発を指しています。
フルスクラッチのメリット
これまでの説明で少しおわかりいただけたかもしれませんが、スクラッチ開発のようなオーダーメイドのシステムを作るのにはそれなりに手間ひまがかかります。
しかし、既製品のスーツとオーダーメイドのスーツにそれぞれ特徴があるように、手間ひまをかけて作るスクラッチ開発にもよいところがあるのです。このパートでは、システム開発手法としてフルスクラッチを選ぶことによるメリットについて見ていきましょう。
独自のビジネスにあわせた開発ができる
まずメリットのひとつ目として、独自のビジネスにあわせた開発ができることがあげられます。システムを導入するときにスクラッチ開発以外の選択肢としては、たとえばパッケージ製品の導入があります。
パッケージ製品とはさきほどのスーツの例でいえば、オーダーメイドではなく店舗にある既製品のスーツを選ぶようなものです。
オーダーメイドであれば自分の体にあわせてきめ細かくサイズの調整ができ、体にぴったりあう製品を手に入れられるでしょう。
逆に既製品のスーツでは、S, M,? Lといった全体的なサイズは体にあうとしても、腕の長さやウエストのサイズなど細かな部分は微妙にあっていないことが起こる可能性は高くなってきます。
システム開発もこれと同様で、パッケージ製品を選択すると安価で手軽にシステムの導入を進められますが、細かいところで自社の業務内容とあわなくて使いにくい、あるいは使えないことが出てくることがあります。フルスクラッチで開発する場合は、自社の業務にあわせてきめ細かく仕様を調整できます。
その分パッケージ製品よりも使い勝手のよいシステムを手に入れることができるのです。
改善活動をスピーディに回せる
次にあげるメリットは、改善活動をスピーディに回せることです。これはどういうことでしょうか？
ふたたびパッケージ製品との比較をしながら詳しく見ていきましょう。パッケージ製品とはそもそも、多くの企業に共通する業務で利用する用途で開発されているものです。
つまり、ある企業の業務に特化した構造にはなっていません。パッケージ製品を導入された方なら経験があるかもしれませんが、「せっかく導入したのに、使いにくい機能がある」ということが起きたりします。
そうなったときには使い勝手を改善したくなるかもしれません。
しかし特定の企業向けに開発された機能ではないため、パッケージの開発会社や販売会社に依頼したからといって、すぐに機能の改修を実現するのは難しい場合が多いのです。
それに対してフルスクラッチで開発したシステムの場合は、開発したシステムのソースを自社で所有できるため、システムを改修できる技術者さえいれば、比較的スピーディに機能の改修に取りかかれます。
システムはいちど導入してそのまま初期状態で使い続けることはまれで、たいていは使っているうちに、不具合など想定していなかった事象が発生したり、使い勝手のよくない部分が出てきたりするものです。
そのようなことに対応するため、システム導入後は利用しながらシステムの評価をするというプロセスを設けるべきでしょう。そして、評価をする中で、
- 使い勝手の悪さを改善する
- 不具合が起こりにくくなるよう仕組みを見直す
- 処理性能を改善する
といった課題を見つけていくのです。見つけた課題をPDCAのサイクルにのせて回していきます。
こうした、システムの評価やPDCAサイクルを回すときに、よりスピーディにサイクルを回せるのがフルスクラッチと言えます。
特別な制約がなくカスタマイズの自由度が高い
3つめのメリットは、カスタマイズの自由度の高さです。フルスクラッチは既製品を導入するのとは違ってカスタマイズの自由度が高いのが特徴です。
システム全体をゼロから構築するため、既製品のような仕様上の制約がありません。業務で使い勝手がいいように画面をデザインすることもできますし、動きや機能を要望にあわせて自由に決めて開発できます。
もちろん既存の自社システムとの連携も、特別な制約なく、比較的自由に取りまとめることが可能です。パッケージ製品の場合もある程度のカスタマイズは可能ですが、もとの製品としての仕様が決まっているため、仕様上の制約でどうしても対応できないところがでてきます。
また、パッケージ製品の仕様を熟知していないとカスタマイズができないため、製品を扱っている開発ベンダーにカスタマイズを依頼する必要があるでしょう。
フルスクラッチのデメリット
フルスクラッチによる開発はいろいろな面で自由度が高く、目的に適合したシステムを構築しやすいことがおわかりいただけたのではないでしょうか。
そのようなフルスクラッチも、当然ながらいい面ばかりではありません。選択するうえでデメリットになることも認識しておく必要があります。
このパートでは、フルスクラッチを選択することによるデメリットについて詳しく見ていきましょう。
開発に時間とコストがかかる
まずデメリットの1点目として、開発に時間とコストがかかることがあげられます。
フルスクラッチによる開発はゼロからオーダーメイドのシステムを構築するため、自由度が高い分、既製品を導入するよりも開発に時間とコストもかかります。
構築するシステムの規模や難易度にもよるため「どれくらいコストがかかるか」は一概には言えません。たとえば、1か月の稼働に70万円かかる技術者を10名、6か月間かけて開発できるシステムがあるとします。その場合は
70万円×10名×6か月＝4,200万円
と、これだけのコストがかかる計算になります。
これは計算を単純化した例ですが、実際にはシステム開発プロジェクトに参画する技術者にはプロジェクトマネージャやシステムアナリスト、システムアーキテクトなどレベルの高い技術力を求められます。
それだけ単価が高額な人も必要となるため、構築にかかるコストはさらに高額になることも十分考えられるでしょう。
同じくらいの規模のシステムをパッケージ製品やクラウドサービスなど既製品の導入でまかなうとしたら、おそらくここまでコストがかかることはないと思われます。つまり、フルスクラッチによる開発は
- ゼロからシステムの仕様を決め、ゼロから設計してから開発するため、製品の完成までに時間がかかる
- 開発プロジェクトに参画する技術者は、全員自社のシステム開発のためだけに技術力と時間を投入するため、それだけのコストがかかる
ことになるのです。
ランニングコストにも相応の予算が必要
フルスクラッチで開発したシステムは構築にかかるコストもさることながら、ランニングコストもそれなりにかかってくることを想定しておかなければなりません。
比較対象として、クラウドサービスとして提供されているパッケージ製品について見てみましょう。
パッケージ製品の中でも最近ではASP業者がクラウドサービスとして提供している製品が増えています。クラウドサービスとして提供されている製品の場合、パッケージ製品を提供している業者が、
- バグ修正によるアップデート
- 製品自体のバージョンアップ
などの製品自体のメンテナンスを、サービスの一環として実施していることが多いのです。上記以外にも、
- OSやミドルウェアのサポート期限が切れる場合
- ストレージの容量が不足してきたため拡張したい場合
にも自動的にバージョンアップされたり、ストレージの容量が追加されることもあります。そのため、クラウドサービスを利用している場合はメンテナンスのためのコストが軽減できます。
これに対してフルスクラッチで開発したシステムの場合はどうでしょう。
クラウドサービスとは違って、システムの機能自体が自前でオリジナルなものとして構築されているため、バグ修正のアップデートもバージョンアップも自社で計画して自前で実施することが必要です。これらメンテナンスにかかるコストは、当然ながらシステムのランニングコストとして毎年の予算に計画的に組み込んでおくことになります。
したがって、フルスクラッチで開発したシステムを何年も維持していくためには、ランニングコストも毎年の予算として相応に見込んでおかなければなりません。
高い技術力を持つ人材が必要
パッケージ製品をそのまま導入したり、既成の部品を組みあわせたりフレームワークやテンプレートに沿って開発するのに比べて、フルスクラッチのようにゼロからシステムを開発するには高い技術力が必要です。
またひと口に高い技術力といっても、ある分野についての技術力が高いだけでは質の高いシステムを構築するのは難しいでしょう。
- システムのデザインに関する技術
- プログラミングの技術
- セキュリティに関する技術
などそれぞれに専門性の高い技術が総合的に必要になります。もちろん、一人の技術者がそれら専門知識を幅広くカバーしている必要はありませんが、それぞれの専門分野に長けた技術者を調達することは不可欠です。
パッケージ製品の場合は、これら専門性の高い技術を盛り込んで製品化されています。そのため、パッケージを導入するのにそれほど専門性の高い技術は求められません。
フルスクラッチの場合はゼロからの構築です。
パッケージ製品に見劣りしないような機能を実装するためには、個別に専門性の高い技術を用いてシステムを構築することが求められるわけです。
【おすすめ資料】海外開発拠点の設立を検討されていますか？
【保存版】成長企業が導入するWakkaのラボ型開発
＞ラボ型開発を進めるポイントとWakka inc.の『独自の海外子会社設立サービス』を紹介した資料です。ぜひあわせてご覧ください。
フルスクラッチ開発の流れ
このパートではフルスクラッチでシステムを構築する場合の開発の流れについて見ていきましょう。
ウォーターフォール型の開発手法が主流
システム開発の手法は、開発するシステムの特性や求められるスピード感などに応じてさまざまな種類があります。その中でもウォーターフォール型の開発手法というのは、製造業で古くから用いられているものです。
製造現場でよく見られるモデルをシステム開発にも応用した手法で、IT業界でもほかの開発手法と比べて古くから使われています。滝の水が流れ落ちるように上流から下流に向かって工程が進んでいくという特徴から、「ウォーターフォール」と呼ばれています。
製造業では一般的に、製品の企画⇒設計⇒製造という流れで製品を開発していきますが、これと同様にウォーターフォール型の開発では、下記の流れで開発を進めていくのが一般的です。
- 要件定義
- 設計
- 製造
- テスト
上流工程が終了したら、次の工程という流れでシステム開発の工程は進んでいくのです。
ねらいどおり開発するためには上流工程が命
ウォーターフォール型の開発の特徴は、ひとつの工程が完全に終わらないと次の工程へは進めないことです。つまり、要件定義工程が終わらないと次の設計工程へは進みません。
そして、工程で作り上げた成果物（要件定義工程であれば『要件定義書』が該当）は次の工程のインプットになります。そのため、前の工程で作成した成果物に誤りがあると、次の工程にもその誤りが引き継がれていきます。
誤りが一度埋め込まれると、それは下流工程へいくほど手戻りの影響が大きくなってしまうのです。
したがって、ウォーターフォール型の開発を行うときは上流の工程ほど大切になってきます。要件定義工程が、システム開発を成功させられるかどうかの鍵を握っているといっても過言ではないでしょう。
スクラッチ開発は時代遅れか？
時代とともにITは大きな進化を遂げています。ひと昔前までは、システムの構築もスクラッチ開発が主流という時代でした。しかし、現在は企業の業務にあわせて構築されたパッケージ製品が数多く出回っています。
たとえば会計・経理のような、どの企業にとっても定型的な業務のシステムとなると、パッケージ製品を導入するケースがほとんどではないでしょうか。
それ以外に、業界に特化した専門性の高い業務においても、パッケージ製品化が進んでいるケースは増えています
「もうスクラッチ開発は時代遅れなのでは？」と感じている技術者も少なくありません。
時代遅れという声も聞かれる中で、スクラッチ開発の価値はどこにあるのでしょうか？詳しく見ていきたいと思います。
スクラッチ開発とパッケージ開発の違い
まず、パッケージ開発の流れについて簡単に見ていきましょう。
パッケージ開発では、ウォーターフォール型の開発手法でいう要件定義にあたる工程で、パッケージ製品が持つ機能と製品を利用する業務とのフィット＆ギャップ分析をおこないます。フィット＆ギャップ分析とはつまり、
- パッケージの機能が自社の業務要件を満たしているか？
- このままの仕様で自社の業務利用にあうのかどうか？
を確認します。フィット＆ギャップ分析が終わったら、ギャップの部分をいかにして埋めあわせてギャップをなくすかを検討します。
- パッケージ機能にあわせて業務を変更する
- 業務で使いやすいようにパッケージ機能をカスタマイズする
基本的には、上記のいずれかの方法でギャップを埋めていきます。こうしてカスタマイズ要件を確定し、カスタマイズ開発を進めるというのがパッケージ開発の流れです。
これに対してスクラッチ開発はゼロからシステムを作り上げるわけですから、開発するすべての機能について仕様を決めて、すべての機能をゼロから開発するわけです。パッケージ開発とはかかるコストがはるかに違ってくるのがおわかりいただけるのではないでしょうか。
流行ではなくシステム開発の目的によって選ぶことが大切
パッケージ開発のフィット＆ギャップ分析においてギャップがそれほど多くなく、パッケージ機能でおおむね自社の業務が回せるのであれば、パッケージ製品の導入は有力な候補と考えられるでしょう。
では「ギャップが多すぎてとてもパッケージは使えない」という場合は、どのように対処すればよいでしょうか。あるいは、
- 自社の業務は業界でも独自のもので、パッケージ製品でまかなえるものではない
- 自社ならではの業務プロセスこそが、業界他社との競争優位を保つために不可欠となっている
という場合はどうでしょう？「パッケージ製品にあわせて自社の業務を変更する」という選択肢は、現実的ではありません。
業務プロセスこそがビジネスを優位にするなら、自社の業務に適合した、最適なシステムを構築すべきでしょう。この場合はスクラッチ開発を選択するのが最適解になります。
このように、自社の目的によって適している開発手法は変わってくるため、今はパッケージ開発が主流だからと流行に乗るのではなく、自社の目的にあった最適なシステム開発手法を検討することが大切です。
フルスクラッチは１つの選択肢！目的にあったシステム開発を選ぼう！
フルスクラッチはシステムをゼロから開発する手法です。パッケージのような既製品と違って独自のシステムを開発するには適した手法ですが、逆にデメリットになる部分もあります。どちらを選択するかはシステム開発の目的や、予算、リソースなどの状況によって変わってきます。
お読みくださっているみなさまが自社のねらいと制約条件など、システム開発を取り巻く状況をしっかりと見極め、最適な開発手法を選択してくださることを願っています。
▼フルスクラッチのメリットを活かすならこちらもチェック
【おすすめ資料】海外開発拠点の設立を検討されていますか？
【保存版】成長企業が導入するWakkaのラボ型開発
＞ラボ型開発を進めるポイントとWakka inc.の『独自の海外子会社設立サービス』を紹介した資料です。ぜひあわせてご覧ください。
学生時代にWebサイトを自作したことがきっかけでWebの世界に。制作会社でデザイン、WordPressテーマ開発の実務を経て、テクニカル・ディレクターとして大規模サイト構築のディレクションを経験。2021年からWakka Inc.の日本拠点でWebディレクターとして参画。最近はブロックエディタになったWordPressをもう一度、勉強しています。
