パッケージとスクラッチ開発の違いは？業務への適合と改修の自由度で選ぶ

パッケージとスクラッチ開発を選ぶときは、必須業務を標準機能で処理できるか、足りない部分をどの方法で補うか、その後も無理なく改修を続けられるかを確認します。 標準機能に合わせて業務を整理できるなら、パッケージが有力です。独自の業務条件が広く関わり、製品の仕組みに合わせた追加開発が複雑になるなら、スクラッチ開発も比較する価値があります。

「何％の機能に対応しているか」だけでは判断できません。多くの機能が使えても、毎日の出荷や月次請求に欠かせない処理が一つ抜けると、運用に大きな影響が出るためです。この記事では、業務への適合を確かめる方法と、将来の改修まで含めた比較の進め方を整理します。

パッケージとスクラッチ開発の違い

パッケージは、多くの利用企業に共通する機能を備えた既製のソフトウェアです。導入にあたり、設定や追加機能で自社の業務に合わせる製品もあります。スクラッチ開発は、自社の要件から必要な機能や情報の流れを設計し、個別に開発する方法です。

パッケージは、自社のサーバーに導入する形に限りません。クラウド上で利用する製品や、SaaSとして提供される製品もあります。パッケージとスクラッチは作り方・調達方法の比較、SaaSは提供・利用の形態なので、完全に別々の3種類として扱わないようにします。

ここでは、製品の標準機能を使う範囲と、自社向けに設計する範囲に焦点を当てます。利用料や運用の分担を中心に比較したい方は、SaaSの比較記事をご覧ください。コラムSaaSとスクラッチ開発の違いは？費用・運用・連携から選ぶ

パッケージなら必ず短期間・低価格、スクラッチなら必ず自由に変更できる、とは言えません。標準からどれだけ外れるか、何をどこまで作るかで条件が変わります。

標準機能との適合は、業務を通して確かめる

「見積機能あり」「在庫管理に対応」といった機能名だけでは、必要な仕事ができるか判断できません。見積を訂正したときの承認、分納したときの在庫と請求、担当者が不在のときの引き継ぎまで、一連の処理で確かめます。

要件と標準機能を照らし合わせる作業は、フィット＆ギャップ分析と呼ばれます。評価するときは、まず要件を次の3つに分けると整理しやすくなります。

• 必須条件：取引条件や事業上の理由があり、満たせないと業務が成立しないこと。
• 運用を変更できる条件：手順や画面が変わっても、必要な結果を得られればよいこと。
• 将来の候補：今回の導入には含めず、業務量や事業の変化を見て追加すること。

たとえば、取引先が指定する計算結果は必須でも、社内で使ってきたExcelと同じセルの配置は変更できるかもしれません。この区別をしないまま見積もりを取ると、残す必要のない手順まで追加開発の対象になってしまいます。

機能の有無から、業務の確認項目へ変える例

以下は要件整理のための仮想例です。特定の製品の仕様や、Ouverの個別案件の実装内容を示すものではありません。

すべての会社にこの条件が必要なわけではありません。自社で頻繁に起きる処理と、まれでも止められない処理を選び、製品デモや試作品で実際に確認します。デモに使うデータは、顧客情報を含まない見本に置き換えます。

パッケージのカスタマイズは、方法を分けて確認する

「カスタマイズできます」という回答だけでは、費用や改修のしやすさは分かりません。何を変更するのか、製品のどの仕組みを使うのかを確認します。

設定で変更する

入力項目、承認ルート、権限、帳票の表示などを、製品に用意された設定で調整する方法です。設定だけで必須業務を満たせるなら、独自のプログラムを持つ範囲を抑えられます。ただし、設定の組み合わせと日々の管理負担は確認が必要です。

拡張機能や外部連携で補う

追加アプリ、プラグイン、API連携などで不足する処理を補う方法です。たとえばMicrosoftのBusiness Centralでは、アプリを追加して機能や動作を拡張できます。これは、既製の製品でも拡張できる例です。Microsoft公式の拡張機能の説明（英語）

この場合は、製品本体と追加部分の担当が分かれることがあります。問い合わせ窓口、障害の切り分け、更新への対応を、誰が取りまとめるか決めておきます。

製品本体を変更する

製品や契約によっては、本体の処理を変更する方法もあります。どの部分を変更できるか、メーカーのサポート対象か、新しい版へ更新するときに変更を引き継げるかを確認します。変更できることと、継続して保守しやすいことは別に評価します。

拡張機能であっても更新対応が不要とは限りません。Business Central Onlineの公式資料では、拡張機能の提供者が、新しい製品バージョンとの互換性を維持する必要があると説明されています。候補製品ごとの更新方針を確認してください。Microsoft公式のカスタマイズ更新方針（英語）

スクラッチ開発の自由度を、運用後も保つには

スクラッチ開発では、独自の計算や業務の流れを設計に反映できます。ただし、設計が複雑で変更の影響を追えない、仕様を知る担当者がいない、テストが残っていない状態では、簡単な変更にも時間がかかります。

開発の相談時には、機能だけでなく、次の点を確かめます。

• 業務ルールと、そのルールを実装した箇所を確認できる資料を残すか。
• 変更の影響を調べ、既存の処理が壊れていないか確かめるテストをどう行うか。
• ソースコード、データ、運用環境を誰が管理し、引き継ぎ時に何を渡すか。
• 不具合対応、技術の更新、機能追加を、誰が判断し、どの費用範囲で進めるか。

「オーダーメイドだから将来も自由」と考えるだけでは不十分です。改修を続けられる設計と資料、担当者、予算まで含めて、個別開発の価値を判断します。

パッケージ・スクラッチ・併用をどう選ぶか

パッケージが有力になる条件

標準機能と設定で必須条件を満たし、違う手順も現場が受け入れられる場合です。残る追加開発が限定され、製品更新時の対応範囲も把握できるなら、既存機能を活用する利点があります。

スクラッチ開発を比較すべき条件

中核となる業務ルールが独自で、その違いが画面、計算、データ構造、連携など広い範囲に及ぶ場合です。パッケージへの追加開発と更新対応の見積もりを確認し、自社向けに設計した場合と、初期費用・運用負担・今後の改修を同じ条件で比べます。

独自ルールが多くても、すべて残す必要があるとは限りません。先に業務を整理し、必要な違いを特定することで、個別開発する範囲も絞れます。

併用が合う条件

会計などの共通業務は既製品を使い、独自の受注処理や作業割り当てを個別開発するなど、役割を切り分けられる場合です。その際は、顧客・商品・金額のどのデータをどちらで管理するかを決めます。両方に同じ情報を持つ場合は、訂正をどこから反映するかも設計します。

同じ条件で回答してもらうための確認項目

合計点だけで順位を付ける前に、必須条件を満たさない案を特定します。「要確認」のまま残る条件は、契約前にデモ、試作品、追加調査で確かめましょう。

Excelからデータを移す場合は、表の中に隠れたルールや重複データの整理も必要です。移す前の準備は、次の記事で詳しく解説しています。コラムExcelからシステムへのデータ移行：移す前のデータクレンジングと、隠れたルールの見つけ方

CRM・在庫管理の開発事例で見る要件の具体化

ここでは、公開事例で確認できる要件整理・再構築の内容を紹介します。パッケージとの比較結果や採用理由を示すものとしては扱いません。

CRMでは、管理画面の前に業務とデータの扱いを見直す

Ouverの営業代行会社向けCRM開発では、他社で進んでいた開発の現状分析から入り、要件定義と業務フローを見直したうえで設計・開発を行いました。スプレッドシートの管理方法をそのまま再現するのではなく、成長する事業に合う情報管理を検討した事例です。事例スプレッドシート管理の限界に向き合う。営業代行会社の成長を支えるCRM開発

在庫管理では、数量の記録以外の業務ルールも引き継ぐ

倉庫物流会社の在庫・受発注管理システムの再構築では、時期によって変わる在庫の基準値や、仕入れアラートから発注につなぐ流れなど、既存業務を支えていた仕組みを確認しました。これらは新しく考案した機能ではなく、引き継ぐべき機能として扱っています。事例PHP 5の在庫・受発注管理システムを約6ヶ月で再構築した事例

こうした事例を参考に、自社でも「顧客管理」「在庫管理」という機能名を、具体的な業務の条件まで掘り下げてください。その条件が明確になると、パッケージで足りる範囲と、個別開発が必要な範囲を比較しやすくなります。