目次
フルスクラッチとは
フルスクラッチとはパッケージや既存のシステムやコードを活用せず新規にシステムやアプリケーションを開発することを指します。またソフトウェアやシステムの開発で既に存在するコードやアプリケーションを土台に開発することをスクラッチ開発と言います。
パッケージ開発との違い、比較
パッケージ開発とフルスクラッチ開発の違いについて、開発期間や使いやすさ、セキュリティの観点から比較していきます。
フルスクラッチ開発
【開発期間】
フルスクラッチ開発では、ゼロから開発するため他よりも膨大な時間を要します。
【使いやすさ】
フルスクラッチ開発では、ゼロから自社にとって扱いやすい機能やUIを実装するため、パッケージ開発よりも自社に適したシステムを構築できます。
【セキュリティ】
サーバーにシステムをインストールして利用するため、自動アップデートができず老朽化します。その結果、脆弱性などのセキュリティ面のリスクが発生します。
パッケージ開発
【開発期間】
パッケージ開発では、標準的・汎用的な業務に合わせて製品を作成して導入を行います。フルスクラッチ開発とは異なり、既存のシステムを導入する事ができるため、要件をすり合わせる時間を短縮できます。
【使いやすさ】
既存システムを導入するため、自社業務と機能が全て合っていない箇所などは使い慣れるまでに時間がかかります。
【セキュリティ】
フルスクラッチ開発同様、サーバーにシステムをインストールして利用するため、自動アップデートができず老朽化します。その結果、脆弱性などのセキュリティ面のリスクが発生します。
フルスクラッチと他の構築方法を比較
フルスクラッチ開発と他の構築方法としてオープンソースやASP（アプリケーション・サービス・プロバイダー）型カートシステム、パッケージ開発があります。
ここではフルスクラッチ開発と他の構築方法を初期費用から導入、セキュリティ面、カスタマイズ性から比較します。
初期費用
初期費用では、オープンソースやASP型カートシテムの方が安く構築できます。どちらも無料で利用できるサービスで、インハウスで構築する場合は初期費用がゼロでECサイト等を開設することができます。
一方でフルスクラッチ開発では、工数やデザインなどで大幅に費用がかかるため初期費用が高くなります。
構築～導入
構築から導入までが短いのはASP型カートシステムです。ASP型では、テンプレートを選択するだけで基本的なカスタマイズをすることができます。一方でオープンソースやパッケージ開発でもプラグイン開発や導入が必要になるのでASP型よりも、工数がかかります。またフルスクラッチ開発では、ゼロから開発するため他よりも膨大な時間を要します。
セキュリティ面
パッケージ開発やフルスクラッチ開発では、サーバーにシステムをインストールして利用するため、自動アップデートができず老朽化します。その結果、定期的にアップデートをおこなわないと脆弱性などのセキュリティ面でリスクが高くなります。顧客情報が漏れたりする場合は、損害賠償に発展するリスクもあります。
カスタマイズ性
パッケージ開発やオープンソースでもある程度自由にカスタマイズすることはできます。しかしフルスクラッチ開発では、ゼロから自社にとって扱いやすい機能やUIを実装するため他の構築方法よりもカスタマイズがしやすいです。
フルスクラッチのメリット
フルスクラッチのメリットは以下の3つが挙げられます。
・自社に最適なシステムを構築
・カスタマイズの自由度が高い
・保守や機能追加をしやすい
自社に最適なシステムを構築
フルスクラッチであれば、ゼロからシステム構築をすることができます。そのため技術的に可能であれば、自社の複雑な要件も取り込むことが可能です。Webサイトであれば、自社の要件の中にはユーザビリティを高めることもできます。ユーザーにとって使いやすいWebサイトを構築することができ、ユーザーの自社に対する信頼やロイヤリティの向上に寄与することができます。
カスタマイズの自由度が高い
フルスクラッチはカスタマイズの自由度も高いです。自社の複雑な要件を取り込めるため、Webサイトであれば、サイトの挙動やデザインなど他社と差別化することが可能です。また、開発スケジュールの遅れが発生した場合にも、必要な機能のみを選択してスモールスタートすることや、優先度の低い要件はカットオーバー後に対応するなど、柔軟な対応が可能になります。
保守や機能追加をしやすい
フルスクラッチを利用することで、運用保守でも機能を追加することが可能です。例えば、自社がよく使う機能をメインに配置した管理画面を構築する、よく使用する機能はより短手順で実行することができるようにする、今後の改修がしやすいような設計にするなど保守運用面でも便利な機能を追加することにより、メンテナンスを容易にすることが可能になります。
フルスクラッチのデメリット
次にフルスクラッチのデメリットを紹介します。以下の2つが考えられます。
・高い技術力が求められる
・構築にかかるコストが高い
高い技術力が求められる
フルスクラッチの場合、プラットフォームの設計や、セキュリティマネジメント、インフラ基盤の構築、要件を実現するための必要な技術の調査など、IT系の幅広い知識と技術力、調査能力を保持している人員が求められます。そのような優秀な人材は少ないため、自社で作る場合には、人員の新規採用が必要になるケースもありますし、外注する場合にはそもそも対応できる会社が少ないケースや、人件費が高額になるケースがあります。
構築にかかるコストが高い
フルスクラッチの場合、パッケージソフトとは異なり、ゼロからシステムを構築しなければなりません。また、パッケージソフトではある程度できる事とできないことが明確になっていますが、フルスクラッチの場合では技術面で可能であれば実現方法を検討する必要があります。そのため、要件定義から構築までコストや時間を多く要する傾向にあります。
一般的にパッケージソフトでは数百万程度の費用がかかります。しかしフルスクラッチの場合、ゼロから開発をするため数千万の費用も見込んで置いた方が良いでしょう。また、運用面でも一からシステムを作っているため、別の担当者へ引き継ぐ難易度も高くなります。引継ぎに時間がかかったり、優秀な人材ではないと保守できないというケースもあり、運用面でもコストがかかる可能性があります。
（参考：ECサイト構築の費用はどれくらい？14社の見積り比較から手法別の料金相場まで解説）
フルスクラッチでの開発の進め方
ここではフルスクラッチでの開発の進め方を紹介します。
要件定義
まず初めに行うことが要件定義です。ここでは構築するシステムの目的をベースに搭載する機能や仕様を確認していきます。Webサイトであれば、業務要件、機能要件、非機能要件、技術要件などをまとめていきます。
新しいシステムを入れるとなると、期待してしまい様々な要望を詰め込みたくなりますが、あまりに詰め込んでしまうとスケジュールの遅延やコストの増大につながりますので、技術的な向き不向きや、目的に沿った要望となっているか、別の方法で対応可能かなどをベースに優先順位をつけておくとよいでしょう。
設計
要件定義の目途が付いたら設計フェーズに移ります。このフェーズでは要件を満たすためにはどのようなロジックにするべきか、よりユーザーが使いやすいシステムにするにはどうするべきか、をもとに設計を行います。
設計時には内部設計と外部設計に大きく分かれており、内部設計はシステム内部のロジックに注力し、外部設計は画面などのユーザーの目に触れる部分の開発を行います。特に外部設計に関しては、Webサイト開発の場合、顧客の信頼やロイヤリティにも直結してきます。
打ち合わせを入念に行い、詳細に仕様を詰めていくようにしましょう。
開発
設計フェーズが完了したら、開発フェーズに移行していきます。設計フェーズで作成した設計書をもとにプログラミングをしていくことになります。ここで注意するべき事は、この段階で追加の要望等が発生しないように双方の認識相違を進めることです。
開発段階で追加要望が発生してしまうと、影響調査やプログラミングの書き直しなど、多数の工数がかかってしまい、高額な改修費用を請求される可能性があります。設計フェーズまでにはシステムを使用する関係部署の代表者を集め、認識相違がないようにしておきましょう。
テスト
一通り開発が完了したら、テストフェーズになります。テストフェーズでは動作に問題ないか、バグが発生していないかを検証します。テストフェーズでは、単体テスト、結合テスト、総合テスト、運用テストの4つの段階に分けて行います。
単体テストでは1機能ごとの確認、結合テストでは1業務単位でデータの受け渡しタイミングやインターフェースに問題がないかの確認、総合テストでは仕様書/要件に沿ったシステムになっているかの確認、運用テストでは実際にユーザーに検証してもらい不都合がないかの確認をすることになります。
また、この運用テストの段階では開発者がユーザーに使い方を説明する、教育フェーズも兼ねているケースが多いです。
保守・運用
テストが完了したら、正式にリリースとなります。その後は構築したシステムを保守・運用していくことになります。保守・運用ではシステム障害がないか監視を行い、障害が発生した場合には障害対応や、それに伴うシステム改修をします。
また、インフラ基盤がアップデートされたときにはパッチ対応をするケースもあります。他にもこのフェーズではユーザーが新たに改善要望を出してくるケースも多く、要望に合わせてシステムを改修するケースもあります。特にリリース直後は、ユーザーからの改修要望が多く上がる傾向にあります。企業側はこれらの要望を保守・運用担当者にきちんと伝えるとともに優先順位の基準を明確にし、要望に対して迅速に対応できる体制を整えておくと良いでしょう。
大手企業のECサイトがフルスクラッチ開発の理由
大手企業のECサイトではフルスクラッチでの開発が多いです。理由は以下の通りです。
・柔軟な仕様変更への対応が可能
・他社ECサイトと差別化するため
・ユーザビリティ追求のため
柔軟な仕様変更への対応が可能
ECサイトは開発して終わりではなく、常に改修しながら良いサイトにしていく必要があります。パッケージソフトでは仕様が限られているため、改修要件に対応できないケースがあります。しかし、フルスクラッチであれば改修要件に対して柔軟に対応することが可能です。
他社ECサイトと差別化するため
フルスクラッチ開発の場合、カスタマイズの自由度が高いため他社のECサイトと差別化をすることが出来ます。
一方でパッケージソフトを使用した場合、デザイン性にはある程度制限がかかってしまい、他社ECサイトと差別化する独特なデザインを追求するのが難しいでしょう。
ユーザビリティ追求のため
ECサイトでは一般ユーザーが触れるため、ユーザビリティの追求が必要です。そのため、要件数が多くかつ複雑になりがちであり、フルスクラッチでないと対応できないケースがあります。そのため大手企業ではフルスクラッチ開発を選択するケースが多くなります。
フルスクラッチを成功に導くポイント
フルスクラッチで構築する場合にはプロジェクトの規模が大きくなるため、その分失敗のリスクも上がります。開発する際には以下の点に注意をして進めると良いでしょう。
・目的を明確化する
・開発フェーズに入る前に関係する部署の担当者と合意する
・ドキュメントをきちんと作る
目的を明確化する
大前提ですが、なぜこのシステムを構築するのか、その結果得られるメリットは何か、いつまでに構築する必要があるのか、など目的を明確にしましょう。そして、要件が目的に沿っているか確認するようにしましょう。
開発フェーズに入る前に関係する部署の担当者と合意する
システムを開発する側にとって、手戻りは大きなリスクになります。事前に関係する部署の担当者と要件をすり合わせておくことで、手戻りをできる限り防ぐことが出来ます。
ドキュメントをきちんと作る
忙しいプロジェクトではドキュメントの作成がおろそかになりがちです。その結果、保守・運用時に開発担当が抜けてしまい、ブラックボックス化してしまうケースがあります。ドキュメントはきちんと作成し、テスト時のリスクや保守・運用のリスクを下げるようにしましょう。
まとめ
今回の記事では、フルスクラッチ開発について解説しました。コンサルティング案件などを探している方、事例を知りたい方は、ぜひfoRProまでご相談ください。