System integration パッケージ・SaaS・スクラッチの選び方

Build options パッケージ・SaaS・スクラッチの違いとは

業務システムを用意する方法は、主にパッケージ、SaaS、スクラッチ開発の 3 つです。パッケージは、既製のソフトウェアを導入し、設定や追加開発で業務に合わせる方法です。SaaS は、インターネット経由でサービスとして使う方法です。スクラッチ開発は、業務に合わせて一から作る方法です。どれが合うかは、業務が一般的な流れにどれだけ近いか、これから業務が変わる見込み、他のシステムとの連携、運用と保守を担う体制で決まります。このページでは、3 つの違いと決める順番、スクラッチ開発が向かない場合、選ぶときに確認することを説明します。フロンティアエージェンシー（FAC）が開発を担うのは、スクラッチで作る場合です（SaaS との API 連携を含む）。

Comparison パッケージ・SaaS・スクラッチ開発の比較

金額は規模や契約の条件で大きく変わるため、ここでは費用のかかり方と、使い続けるときの違いを比べます。

比べる点パッケージSaaSスクラッチ開発
始め方既製のソフトウェアを導入し、設定で業務に合わせる契約し、設定とデータの登録を済ませて使い始める。始めるまでの期間は短いことが多い要件を整理し、設計と開発を終えてから使い始める
費用のかかり方ライセンスと導入の費用に加え、製品の保守の費用が続けてかかることが多い。追加開発が多いほど増える始めるときの費用は抑えやすい。利用する人数や利用量に応じた費用がかかり続ける開発の範囲で決まる。作ったあとの保守の費用も見込んでおく
業務への合わせ方設定と追加開発で合わせる。大きく変えるほど、製品の更新に追従しにくくなる用意された設定の範囲で合わせる。業務をサービスに合わせる部分が出る業務に合わせて作れる。その分、仕様を決める手間がかかる
運用・保守の担い手製品の提供元、導入した会社、自社で分担する提供元がサービスを保守し、自社は設定と利用者の管理を担う開発した会社と自社で範囲を決める
データの持ち方製品の形式で持つ。ほかへ移すときの書き出し方を確かめる提供元の環境に置く。書き出し方と、解約したあとの扱いを確かめる自社の要件に合わせて決められる。ソースコードと設計書の扱いは契約で決めておく
向いている業務業界で流れがほぼ決まっていて、自社の環境で管理したい業務一般的な流れで足り、早く始めたい業務自社独自の流れや、他のシステムとの細かい連携が必要な業務

3 つは組み合わせることもできます。たとえば、一般的な業務は SaaS を使い、自社独自の部分だけをスクラッチで作って API で連携する形です。

How to decide 作り方を決める順番

次の順に確かめると、3 つのうちどれが合うか、どう組み合わせるかが見えてきます。

  1. 業務が一般的な流れにどれだけ近いか

    同じ業界の多くの会社とほぼ同じ流れなら、パッケージや SaaS の機能で足りることが多くなります。自社独自の流れが強みになっている業務は、スクラッチ開発が候補になります。

  2. これから業務がどれだけ変わるか

    新しい事業や仕組みの見直しが続く業務では、変更のしやすさを比べます。設定で変えられる範囲なら、パッケージや SaaS でも対応できます。設定で収まらない変更が続く場合は、スクラッチ開発が候補になります。その分、変更のたびに改修の費用がかかります。

  3. 他のシステムとどうつなぐか

    連携先が多い場合や、細かい連携が必要な場合は、連携の方法を先に確かめます。SaaS やパッケージに API があれば、連携する部分だけを開発する方法もあります。

  4. 誰が運用と保守を担うか

    社内に担当者がいるか、外部に任せるか、使い続ける費用をどう見込むかを決めます。スクラッチ開発では、作ったあとの保守の範囲を契約の前に決めておきます。

保守の範囲の決め方は、システム保守の範囲と決め方で説明しています。

When not to build スクラッチ開発が向かない場合

スクラッチ開発は業務に合わせて作れる一方で、時間と費用、作ったあとの保守が必要です。次のような場合は、パッケージや SaaS の方が合うことがあります。

こんな場合理由
既製の機能で業務が回る多くの会社で流れが同じ業務は、パッケージや SaaS の方が早く使い始められ、費用も見込みやすくなります
使い始めるまでの時間がない要件の整理と開発には時間がかかります。期限が迫っている場合は、まず既製のサービスで始める方法もあります
作ったあとの保守を決められない保守の範囲と担い手を決められない場合は、提供元が保守するサービスの方が向いています
独自に作っても業務の結果が変わらない自社に合わせて作っても成果が変わらない部分は、既製の機能に合わせた方が保守の手間を減らせます

Excel・Access で回している業務の場合は、Excel・Access 業務のシステム化で、今のまま整える方法も含めて比べています。

Checklist スクラッチ開発を選ぶときに確認すること

確認すること理由
必須の機能と、あれば良い機能分けておくと、開発の範囲と費用を決めやすくなります。必須の機能から段階的に作る計画も立てられます
既製のサービスと組み合わせられる部分決済や認証など、既製のサービスを連携して使える部分は、作らずに済む場合があります
作ったあとの保守の範囲不具合への対応、機能の追加、サーバーの管理を誰が担うかで、使い続ける費用が変わります
今のデータの移し方Excel や古いシステムにあるデータを、どの形で移すかを先に確かめておくと、移行の手戻りを防げます

FAC の企画開発は、要件定義・設計から開発、リリース後の運用サポートまでを、スクラッチ開発で担います（SaaS との API 連携を含む）。
どの作り方が合うかは、ご相談の段階で業務と課題を伺い、一緒に整理します。

Pitfalls よくあるつまずき

つまずき起こりやすいこと防ぐために
機能の数だけで比べる使い続ける費用や、業務を合わせる手間が見えないまま決まる運用・保守とデータの持ち方も、同じ重さで比べる
パッケージを大きく作り変える製品の更新に追従できず、費用と手間が増える作り変える量が多い場合は、スクラッチ開発や組み合わせと比べ直す
データの書き出し方を確かめずに契約するあとで移したいときに、必要なデータを取り出せない契約の前に、書き出せる形式と解約後の扱いを確かめる

FAQ よくある質問

パッケージや SaaS から始めて、あとでスクラッチ開発に移せますか？

多くの場合は移せます。ただし、移せる内容は、パッケージや SaaS から書き出せるデータの範囲で変わります。まず、いまのデータの持ち方と書き出し方を確かめます。移行の進め方は、リプレイス・移行で説明しています。

SaaS と連携するシステムを、スクラッチで作れますか？

はい。FAC の企画開発では、API 連携開発を承っています。SaaS の API で何ができるかを確かめたうえで、連携する部分を設計します。

見積もりの前に決めておくことはありますか？

業務の流れ、必須の機能、使い始めたい時期、決定者を整理しておくと、見積もりの前提を合わせやすくなります。整理の方法はシステム開発の依頼の進め方の整理シート、費用が変わる要因はシステム開発の費用の決まり方で説明しています。

どの作り方が合うかが決まっていない段階でも、ご相談いただけます。お問い合わせフォームの「お問い合わせ内容」に「相談希望」とご記入ください。

まず相談する

関連：企画開発／システム開発の依頼の進め方／システム開発の費用の決まり方／Excel・Access 業務のシステム化