人手不足や法対応などさまざまな要因で、業務効率化が求められる物流領域において、物流システムの導入は必須となってきています。しかし、その際に「スクラッチでシステムを開発するべきか、それともSaaSを導入するべきか」という選択に悩む企業も多いでしょう。

本記事では、費用や導入までの期間だけでなく、協力会社やドライバーの利便性、データ活用の可能性といったあらゆる観点から、スクラッチ開発とSaaS導入の違いを物流DXパートナーのHacobuが解説します。

スクラッチ開発とSaaS導入の違いについて解説した資料はこちらからダウンロードいただけます。

スクラッチ開発とSaaS導入それぞれの概要

まず、両者の概要を整理します。

スクラッチ開発とは

スクラッチ開発は、既存のテンプレートやソフトウェアを使用せず、ゼロから特定の要件に基づいてソフトウェアやシステムを設計・構築する手法です。

SaaSとは

SaaS（Software as a Service）は、クラウド環境で提供されるソフトウェアをインターネット経由で利用するサービスモデルです。ユーザーはインストールや更新の手間を省き、サービス提供者が管理するソフトウェアをサブスクリプション形式で利用できます。

スクラッチ開発とSaaS導入の比較表

両者の違いについて、まずはサマリーをご覧ください。

上記の比較表も記載がある資料はこちらからダウンロードいただけます。

以降で、それぞれの詳細を解説します。

初期費用の違い

ここでは、両者で発生する初期費用を比較します。

スクラッチ開発の場合

スクラッチ開発の場合、システムの要件定義から設計、開発、テスト、導入までを全て自社（または受託会社）で行います。

具体的には以下の費用が発生します。

• 人件費：開発者、プロジェクトマネージャー、テスターなど外部委託費を含む人件費
• 開発環境の整備：ハードウェアやソフトウェア、開発ツールの購入費用

開発要件によっては、数千万円の開発費用（簡易な要件でも1千万円程度）になるなど、初期費用は高額になる可能性があります。

たとえば、バース予約システムは協力会社が予約のためにシステムを利用するように、物流システムは自社だけでなく社外の方にも使用いただくことが多いでしょう。そうなると、ユーザーを管理するなどのマスタ機能が必要になります。「マスタ機能を開発するだけ」でも数百万円かかる可能性があります。

また、開発期間が長期化すると、その分費用も増加します。

SaaSの場合

SaaSの場合でも、一般的には初期費用が発生します。初期費用には、以下の費用が含まれます。

• アカウント発行
• 初期設定サポート
• 専任担当者による導入支援サービス

一般的にSaaS導入の初期費用は数十万円程度であり、スクラッチ開発に比べて、初期費用が大幅に抑えられます。

ランニング費用の違い

ここでは、両者で発生するランニング費用を比較します。

スクラッチ開発の場合

スクラッチ開発の場合、初期の開発以外に費用が発生しないとお思いの方もいますが、実は運用開始後もシステムを安定的に稼働させるには、以下のような費用が継続的に発生します。

保守・運用費用

システムの安定稼働を維持するための定期的な保守作業に関する費用です。費用は開発費用の10~15%程度が一般的です。

インフラ関連の人件費

スクラッチ開発システムでは、システム基盤の設計・管理を担う専任のインフラ技術者が必要不可欠です。

主な業務は、システム全体のアーキテクチャ設計、ミドルウェアの設定変更、パフォーマンスチューニング、ベンダーとの技術的な調整などです。また、監視運用ベンダーへの指示や、中長期的な基盤更改の計画立案も重要な責務となります。

カスタマイズ費用

機能追加や改善、セキュリティ対策のための開発費用です。スクラッチ開発は初期の要件定義に基づいて開発しますが、利用していく中で新たな機能追加や機能改善の要望が出てくることが一般的です。機能追加のたびに費用が発生します。

ファームウェアの更新費用

ハードウェアに依存するシステムでは、ファームウェアの更新も必要です。

具体的には、新しいソフトウェア機能をサポートするためや、ハードウェア関連の脆弱性を修正する更新作業、ソフトウェアやインフラのアップグレードに伴うハードウェアの互換性を確保する更新作業などが考えられます。

バージョンアップ

スクラッチ開発では、5年単位の大規模バージョンアップと、10年単位のフルリニューアルが一般的です。

5年での更新が必要な理由は、ハードウェアの保守期限切れ、OSやミドルウェアのサポート終了、技術の陳腐化などです。費用は初期開発の30-50%程度が必要です。

10年でのフルリニューアルは、システムの老朽化、技術的限界、ビジネス要件の大幅な変化に対応するために必要となります。この場合、初期開発と同等以上の費用が発生します。 これらの更新を怠ると、システム障害の増加、運用コストの急増、セキュリティリスクの増大などの問題が発生する可能性が高まります。

法改正対応

近年、物流領域では法改正により、荷主や物流事業者に求められる対応が増えています。

たとえば、元請け事業者は実運送体制管理簿の作成・保存が義務化されましたが、これをアナログに行うのは困難です。効率的に作成・保存するためには、日々の配車業務で扱うオペレーション・システムに組み込む必要があります。このような法改正に伴う対応も、導入以降に発生することが考えられます。

SaaSの場合

厳密にはサービスごとに異なりますが、SaaSのランニング費用には以下の費用が含まれることが多いです。

• サービス利用
• 機能追加や改善（法改正対応を含む）
• セキュリティアップデート
• 問い合わせ対応
• ヘルプページの確認やナレッジの取得
• 運用改善提案
• ユーザー同士のコミュニティ形成

機能改善や保守・運用はサービス提供者が行い、ランニング費用に含まれています。また、SaaS導入の目的（課題の解決）のために、どのようにSaaSを活用していくかといった改善提案の費用も含まれています。

ただし、利用する機能のアップグレードや運用拠点、オプションの追加などにより、費用は上昇することもあります。

以上をまとめると、スクラッチ開発とSaaSの初期費用・ランニング費用は以下のようなイメージになります。

スクラッチ開発とSaaSのTCO（Total Cost of Ownership）を比較すると、以下のイメージです。

スクラッチ開発の場合、仮にカスタマイズや法対応を行わなかったとしても、定期的なバージョンアップの際に追加で多くの費用が発生します。

以上はあくまでイメージですので、詳細は各業者へ見積もりを取って比較しましょう。スクラッチ開発の場合は、開発費用だけでなく毎年どのような費用が発生するかも正しく把握した上で、比較することをおすすめします。

スクラッチ開発とSaaS導入の違いについて解説した資料はこちらからダウンロードいただけます。

導入までの期間の違い

次に、両者の導入までの期間の違いについて解説します。

スクラッチ開発の場合

スクラッチ開発の場合、システムの要件定義から設計、開発、テストを経て本番運用に至ります。多くのプロセスが発生するため、導入意思決定後、8〜10ヶ月程度の期間がかかります。

複数人の要望を取りまとめながら、システム要件に落とし込むには、多大な社内調整も必要です。

要件定義や設計に時間がかかったり、予期せぬバグや問題が発生すると、想定以上に導入に時間がかかるリスクもあります。

SaaSの場合

SaaSはすでに完成されているシステムを利用するため、開発を待たずに利用開始できます。そのシステムをどのように既存の運用に適合させるかの運用準備が必要になりますが、1~2ヶ月程度で本番運用が可能です。

開発・機能追加の柔軟性

ここでは、開発・機能追加の柔軟性について比較します。

スクラッチ開発の場合

スクラッチ開発は、業界の特殊事情や自社の業務フロー、特有の要件に合わせた開発が可能なため、柔軟なシステムを構築できます。

ただし、すべての要望を踏まえた開発をするためには、開発費用や開発期間が想定以上にかかる可能性があります。

SaaSの場合

SaaSの場合、既存の機能を利用する形になるため、自社に都合の良い仕様変更は難しいです。

要件の決定権はサービス提供者にあり、利用者からの要望に優先順位をつけて開発を行います。自社に必要な機能が追加されるとは限りませんが、アップデートやメンテナンスの負担はありません。

保守運用体制

スクラッチ開発の場合

スクラッチ開発では、システムの保守運用がすべて自社の責任となるため、独自の体制を整える必要があります。

具体的には、バグの修正や定期的なアップデート、新たなセキュリティリスクへの対応など、日々のメンテナンスが欠かせません。保守要員や技術者を社内に確保しなければならず、システムが複雑化するほど運用コストや人的リソースも増大します。

トラブルが発生した際には迅速に対処できる体制が求められ、解決に時間がかかるとさまざまなリスクも発生します。

既存の基幹システムなどで保守要員や技術者のリソースが手一杯で、新たな物流システムの保守運用まで手が回らない可能性もあるでしょう。

SaaSの場合

SaaSの場合、保守運用は主にサービス提供者が行うため、自社の負担は軽減されます。

サービス提供者がシステムの安定性やセキュリティに関するアップデート、バグ修正、新機能の追加などを継続的に実施するため、利用者は常に最新の機能や安全な環境を利用できます。

トラブルが発生した場合もサービス提供者側でサポート体制が整備されているため、対応が迅速であることが一般的です。また、通常はクラウド環境で提供されているため、インフラ管理の負担もなく、自社リソースを割く必要もありません。

利用部門目線では、システム部門への社内調整コストをかけずに、物流システムを構築できます。

導入リスクの違い

ここでは、導入リスクの違いについて比較します。

スクラッチ開発の場合

スクラッチ開発の場合、導入時に多くの費用とリソースが発生するため、後戻りが難しい点が大きなリスクです。 システムを用いて期待通りの成果が出ない場合や事業の方向性が変わった場合でも、投資に対する減価償却が発生するため、途中で運用を停止すると資金的な損失が大きくなります。 また、トライアルのような一時的な導入ができず、長期的な使用を前提としたリスクの高い投資になるため、計画段階での要件定義や意思決定が非常に重要です。

SaaSの場合

SaaSの場合、一般的には導入対象や契約プランをミニマムから始められます。初期リスクを抑えつつシステムの効果を検証することや、成果に応じて利用規模やプランを拡張することが可能です。

また、契約は年単位であることも一般的です。万が一、期待した成果が得られない場合、契約期間の終了後に解約が可能なため、不要な投資を避けやすく、リスクを最小限に抑えることができます。

スクラッチ開発とSaaS導入の違いについて解説した資料はこちらからダウンロードいただけます。

既存システムとの互換性の違い

ここでは、既存システムとの互換性について比較します。

スクラッチ開発の場合

スクラッチ開発では、ERPやWMSなど既存の自社システムとの連携や統合が柔軟に設計できるため、既存システムとの互換性が高くなります。

要件に応じてカスタムAPIやデータ連携の仕様を設計できるため、データの双方向のやりとりがスムーズに行え、業務フローに最適化された統合が可能です。また、既存システムとのデータ構造やビジネスロジックに合わせてシステムを設計するため、効率的に情報を活用できることが大きなメリットです。

SaaSの場合

SaaSは標準化された機能やインターフェースを提供しているため、既存の自社システムと連携する際に制約がある場合があります。

多くのSaaSは汎用的なAPIや一部のシステムと接続可能なインテグレーションを提供していますが、自社の要件に完全には一致しない場合もあります。

セキュリティの違い

ここでは、セキュリティについて比較します。

スクラッチ開発の場合

スクラッチ開発では、企業が自社独自のセキュリティ要件やポリシーに基づいてシステムを設計・構築できるため、特定のリスクに対応したセキュリティ対策を柔軟に導入できます。機密情報や業務上の重要データの保護が必要な場合も、自社の基準に沿ったアクセス制限や暗号化を組み込むことで高度なセキュリティ環境を構築可能です。

ただし、セキュリティ対策を適切に維持するには、専門知識を持つ人材やセキュリティポリシーが必要で、定期的なアップデートや脆弱性管理のコストもかかります。セキュリティ要件が複雑で厳しい場合には自社でコントロールができる反面、対策の整備と維持に時間とリソースが必要です。

SaaSの場合

サービス提供者にとって、セキュリティの強化はサービス価値の重要な一部であり、専門チームが常に最新の対策を講じています。

多くのSaaSでは、業界標準のセキュリティプロトコル（例：データの暗号化、多要素認証、アクセス管理）に加え、サーバーやネットワーク全体のセキュリティも強化されています。また、最新の脆弱性対策や侵入検知システムを常に更新し、監視体制も整えています。

結果として、自社で個別にセキュリティを管理する場合よりも、セキュリティリスクを軽減できるケースが多いです。

協力会社やドライバーから見た違い

基幹システムなどと異なり、物流システムは自社だけでなく、協力会社やドライバーにも使用いただく機会が多いシステムです。つまり、自社だけでなく、協力会社やドライバー目線での利便性も考慮しなければなりません。

スクラッチ開発の場合

当然ながら、スクラッチ開発の場合、そのシステムが使われるのは自社だけです。

例えば、バース予約システムにおいて、協力会社やドライバーは物流拠点への荷積み・荷降しを予約する際、自社独自のシステムでは操作に不慣れで、予約に手こずるかもしれません。

SaaSの場合

SaaSの場合、近隣地域や同業他社でも同じシステムが使われていることが考えられます。

他の物流拠点への予約で使い慣れたシステムであれば、自社においてもスムーズに予約いただけるでしょう。

データ活用への可能性の違い

ここでは、物流システムを利用することで取得できるデータの活用について比較します。

スクラッチ開発の場合

スクラッチ開発の場合、システムを通じて蓄積されたデータは基本的に自社内での活用が中心となります。たとえば、入出荷や配送の履歴データを基にした自社の業務改善や効率化が可能です。

しかし、自社で取得しているデータの定義や保有情報が他社のシステムと異なる場合が考えられます。その場合、他社とデータを用いた議論で、話が噛み合わない、話が進まない、といった事態に陥ることがあります。

SaaSの場合

SaaSの物流システムの中には、MOVO（ムーボ）のように、クラウド基盤を通じて企業をまたいでデータが集約され、物流情報プラットフォームを形成しているサービスがあります。

入出荷データや配送データは業態・業界を超えてプラットフォーム上に集約され、このビッグデータを活用し、共同輸配送や効率的なルート構築といった新たな物流モデルの実現を後押しします。

まとめ

これまで解説してきたとおり、物流システムを構築する際、スクラッチ開発するかSaaSを導入するか、以下の観点を整理し、自社に合う手法を選択すべきでしょう。

• 費用：初期費用やランニング費用を比較する。その際、保守運用などあらゆる費用を整理する。
• 期間：本番導入の希望時期から逆算し、導入スケジュールを整理する。
• 柔軟性：業界の特殊事情や自社の業務フローから、必要条件を整理する。
• 運用体制：保守運用の体制が社内にあるか整理する。
• リスク：極力リスクのない投資手法を整理する。
• 互換性：既存システムと連携すべきデータを整理する。
• セキュリティ：自社のセキュリティポリシーを整理する。
• 自社外における利便性：自社だけでなく社外の利用者にとって最適な運用を整理する。
• データ活用：全体最適のために、あるべきデータの持ち方を整理する。

システム導入は企業戦略の一環として、慎重に検討する必要があります。自社の現状と将来的なビジョンを明確にし、最適なシステムを選択することで、ビジネスの成長と競争力の強化が期待できます。本記事がその一助となれば幸いです。

スクラッチ開発とSaaS導入の違いについて解説した資料はこちらからダウンロードいただけます。

なお、Hacobuでは「運ぶを最適化する」をミッションとして掲げ、物流DXツールMOVO（ムーボ）と、物流DXコンサルティングサービスHacobu Strategy（ハコブ・ストラテジー）を提供しています。

物流現場の課題を解決する物流DXツール「MOVO」の各サービス資料では、導入効果や費用について詳しくご紹介しています。

トラック予約受付サービス（バース予約システム） MOVO Berth

MOVO Berth（ムーボ・バース）は、荷待ち・荷役時間の把握・削減、物流拠点の生産性向上を支援します。

動態管理サービス MOVO Fleet

MOVO Fleet（ムーボ・フリート）は、協力会社も含めて位置情報を一元管理し、取得データの活用で輸配送の課題解決を支援します。

配車受発注・管理サービス MOVO Vista

MOVO Vista（ムーボ・ヴィスタ）は、電話・FAXによるアナログな配車業務をデジタル化し、業務効率化と属人化解消を支援します。

物流DXとは？メリットや推進する上での課題、解決策、事例について解説

近年、さま…

2021.11.29