システム導入を検討するため複数のベンダーへ相談したところ、「A社はSaaS」「B社はローコード」「C社はスクラッチ開発」と、全く異なる提案が届くことがあります。
このような場合、見積金額や機能数だけを横に並べても、適切に比較できるとは限りません。各社が提案しているシステムの範囲、導入後の責任分担、業務をどこまで変更するのか、費用が発生する仕組みなどが異なるからです。
重要なのは、最初から「SaaS・ローコード・スクラッチのどれが優れているか」を決めることではありません。各提案を一度「何の課題を解決するための提案なのか」まで戻し、自社にとって共通となる判断軸へ置き直して比較することです。
本記事では、方式の異なるベンダー提案を比較するときに確認したい7つの判断軸と、見積範囲やリスクを整理する実務的な進め方を解説します。
なぜ複数ベンダーの提案はそのまま比較できないのか
複数のベンダーへ同じ課題を説明しても、必ずしも同じシステムが提案されるわけではありません。
あるベンダーは既存SaaSの標準機能を中心に考え、別のベンダーはローコード基盤上で業務に合わせた機能を構築し、さらに別のベンダーはスクラッチ開発を提案することがあります。
このとき、違うのは技術方式だけではありません。
- どの業務をシステムへ合わせるのか
- どの機能を新しく作るのか
- どこまでが導入時の対象範囲なのか
- 導入後に誰が設定・改修するのか
- ライセンスや保守費がどのように発生するのか
- データやシステムが特定のサービスへどの程度依存するのか
つまり、「同じシステムを3社が異なる価格で提案している」のではなく、そもそも3社が違うものを提案している場合があります。
この状態で単純な価格比較や機能数の比較をすると、各提案の前提条件を見落としやすくなります。
SaaS・ローコード・スクラッチの3提案が届いた仮想例
説明用の仮想例として、ある企業が業務システムの刷新について3社へ相談したケースを考えます。
| 提案 | 技術方式 | 提案の考え方 |
|---|---|---|
| ベンダーA | SaaS | 既存サービスの標準機能を利用し、一部の業務をサービス側へ合わせる |
| ベンダーB | ローコード | プラットフォーム上で、自社に必要な機能を構築する |
| ベンダーC | スクラッチ開発 | 自社の要件に合わせて専用システムを設計・開発する |
この3つは、同じ業務課題を対象としていても、実現方法が異なります。そのため、初期費用、継続費用、導入時に必要な業務変更、改修方法、保守体制なども異なります。
例えばSaaS提案の初期費用が低く見えても、自社業務を標準機能へ合わせるための社内作業が必要かもしれません。スクラッチ提案では個別要件を実装できても、将来の保守・改修体制を確認する必要があります。ローコードについても、使用するプラットフォーム、ライセンス条件、誰が開発・保守を担うかによって実際の運用は変わります。
したがって、方式の名称だけを見て固定的な優劣を付けることは避けた方がよいでしょう。
まず「どの課題を解決する提案か」をそろえる
ベンダー提案を比較する前に、最初に確認したいのは技術方式ではなく、「今回のシステムで何を解決したいのか」です。
例えば「申請業務をデジタル化したい」というテーマでも、実際に解決したい課題は企業によって異なります。
- 紙での回覧をなくしたい
- 承認待ちの状況を把握したい
- 同じ情報を複数システムへ入力する作業を減らしたい
- 監査時に承認履歴を確認できるようにしたい
- 拠点ごとに異なる申請方法を統一したい
何を解決するのかが曖昧なままだと、各ベンダーはそれぞれ異なる解釈で提案を作ります。その結果、機能範囲も費用も異なり、比較しにくくなります。
ここで重要なのは、すべてのベンダーに同一の技術方式を提案してもらうことではありません。そろえるべきなのは「解決したい課題」「必須要件」「自社の制約」「比較する観点」です。
技術方式が違う提案を比較する7つの判断軸
1．解決する課題・達成したい状態
最初に、各提案によって「何が変わるのか」を確認します。
提案書に多くの機能が記載されていても、自社が解決したい課題と関係しない機能であれば、選定上の優先度は高くありません。
逆に、機能数が少なく見えても、主要な課題を十分に解決できる提案であれば候補になり得ます。
2．必須要件への適合
次に、「なければ導入目的を達成できない必須要件」と、「あれば便利な任意要件」を分けます。
例えば既存システムとの連携が必須であれば、その要件を満たせない提案について、他の機能が多いことだけを理由に高く評価するのは適切とは限りません。
評価表を使用する場合も、必須要件と加点項目を同じ扱いにしないことが重要です。
3．自社の制約条件への適合
システムは、技術的に実現できればよいわけではありません。
予算、導入期限、既存システム、社内のITスキル、利用端末、ネットワーク環境、情報管理方針など、自社側の制約を踏まえる必要があります。
例えば機能面では適していても、社内で継続的に運用できない構成であれば、別の問題が発生する可能性があります。
4．導入・運用に必要な社内体制
ベンダー側が何を担当し、自社が何を担当するのかも比較します。
SaaSであっても、アカウント管理、権限設定、マスターデータ管理、問い合わせ対応等を自社で担う場合があります。ローコードでは、導入後の変更を自社が行うのか、引き続きベンダーへ依頼するのかで必要な体制が変わります。
スクラッチ開発でも、保守・改修を誰が続けるのか、設計情報やソースコードをどのように引き継げるのかを確認します。
5．費用と費用発生の構造
費用は初期見積だけでなく、利用期間全体で考えます。
TCO（Total Cost of Ownership：総保有コスト）は、導入費だけではなく、利用期間中に発生するライセンス、運用、保守、追加改修等を含めて費用を考える概念です。
例えば初期費用が低くても、利用者数に応じたライセンス費が継続的に発生する場合があります。逆に初期開発費が大きくても、その後の費用構造が異なる場合があります。
どちらが有利かは利用期間、利用人数、変更頻度等によって異なるため、初期費用だけでは判断しません。
6．技術・セキュリティ・依存関係のリスク
技術方式だけを見て「SaaSだから安全」「スクラッチだから柔軟」と判断することは避けます。
実際には、アクセス管理、更新、監視、バックアップ、障害対応、委託先管理などの設計・運用によって状況は変わります。
また、ベンダーへの依存だけでなく、特定のSaaSやローコード基盤、クラウドサービス等への依存も確認します。
依存関係そのものが問題なのではありません。重要なのは、サービス終了、価格改定、契約変更、担当ベンダー変更等が発生した場合に、自社へどのような影響があるかを把握しておくことです。
7．将来の変更・拡張・撤退可能性
導入時だけでなく、数年後の変更も確認します。
- 利用者や拠点が増えた場合に対応できるか
- 新しい業務要件を追加できるか
- 他システムとの連携を追加できるか
- 別サービスへ移行する場合にデータを搬出できるか
- 契約終了時に必要な作業は何か
- 開発・保守ベンダーを変更する場合に必要な情報を引き継げるか
導入時の要件だけでなく、「変更するときに困らないか」まで確認することで、各提案の違いを把握しやすくなります。
見積金額が違うときは「何が含まれているか」を確認する
複数の提案で見積金額が大きく異なる場合、すぐに「高い」「安い」と判断せず、まず見積範囲を確認します。
| 確認項目 | 確認したい内容 |
|---|---|
| 初期導入 | 設定、設計、開発等のどこまでが含まれているか |
| データ移行 | 既存データの整理、変換、移行作業が含まれているか |
| システム連携 | 既存システムや外部サービスとの連携範囲は同じか |
| ライセンス | 利用者数、機能、環境等によって継続費用がどう変化するか |
| 教育 | 利用者・管理者向け教育が含まれているか |
| 保守 | 障害対応、問い合わせ、更新等の範囲が明確か |
| 追加改修 | 導入後の機能追加がどのような契約・費用になるか |
| インフラ | クラウド等の利用費が見積に含まれているか |
| セキュリティ | 設定、ログ、バックアップ等の対応範囲が明確か |
| 契約終了 | データ搬出、移行、環境廃止等に条件や費用があるか |
例えば、ある提案ではデータ移行費が初期費用に含まれ、別の提案では別途作業になっている可能性があります。この状態では、提示されている合計額だけを比べても同じ範囲を比較していることになりません。
見積金額を比較する前に、「何が含まれているか」「何が含まれていないか」をそろえることが重要です。
提案書だけでは比較できない項目はベンダーへ再確認する
提案書に記載されている情報だけで、すべての判断軸を埋める必要はありません。不明な項目があれば、各ベンダーへ追加で確認します。
このとき有効なのが、各社へ同じ観点の質問を返すことです。
- 今回の提案で対応しない要件は何か
- 自社側で変更する必要がある業務は何か
- 導入後に自社が担当する運用作業は何か
- 追加改修は誰がどのように行うのか
- 利用者やデータ量が増えた場合、費用はどう変わるのか
- 他サービスへ移行する場合、どの形式でデータを取り出せるのか
- 契約終了時に自社で必要となる作業は何か
- 障害・セキュリティインシデント発生時の責任分担はどうなるのか
質問をそろえることで、提案書の書き方の違いではなく、各方式・サービスの実際の違いを比較しやすくなります。
各社の提案を比較できない場合は、まず「どの提案が優れているか」ではなく、「各提案が何を解決し、どの制約とリスクを残すのか」を同じ形式で整理します。それでも比較軸自体を決めにくい場合には、契約前に第三者と論点を整理する方法もあります。
評価表・点数化を使うときの注意点
複数ベンダーを比較するため、評価項目ごとに点数を付ける方法もあります。比較観点を明文化し、関係者間で認識をそろえる方法としては有効です。
ただし、合計点が最も高い提案を自動的に採用する仕組みにしないことが重要です。
例えば「便利な追加機能を多数持つ提案」が多くの加点を獲得した一方で、自社にとって必須となる要件を満たしていない可能性があります。また、重大なセキュリティ上の懸念や、経営上受け入れられない制約を単純な減点だけで扱うことが適切とは限りません。
評価表を使用する場合は、少なくとも「必須条件」「比較のための評価項目」「許容できないリスク」を区別しておくと、点数だけに判断を依存しにくくなります。
自社だけで判断しにくい場合は第三者へ論点を確認する
各提案を整理しても判断しにくい場合、外部の専門家へ第三者的な意見を確認する方法があります。
ただし、その目的は「どのベンダーを選ぶべきか決めてもらうこと」とは限りません。
例えば、次のような論点を整理するために外部知見を利用できます。
- 各提案の技術的な前提が異なっていないか
- 比較項目に抜けがないか
- ベンダーへ追加で確認すべき事項は何か
- 自社の必須要件と任意要件を適切に分けられているか
- 特定方式に依存するリスクをどう捉えるべきか
- PoCや追加調査が必要な論点は何か
最終的な選定は、予算、事業方針、運用体制、リスク許容度等を踏まえて自社で行います。第三者の役割は、判断を代行することではなく、自社が判断するための材料を整理することにもあります。
ベンダー提案を比較するチェックリスト
| 確認項目 | 確認内容 |
|---|---|
| 解決課題 | 各提案が解決しようとしている課題は同じか |
| 対象範囲 | 対象業務・利用者・拠点等の範囲は同じか |
| 必須要件 | 導入目的に必要な要件を満たしているか |
| 未対応事項 | 対応しない要件が明示されているか |
| 業務変更 | 自社側で変更する必要がある業務が分かるか |
| データ移行 | 既存データの移行範囲と責任分担が明確か |
| システム連携 | 既存システムとの連携範囲が明確か |
| 運用・保守 | 自社とベンダーの責任分担が明確か |
| 継続費用 | ライセンス、保守、インフラ等の費用構造を確認できるか |
| セキュリティ | アクセス管理、バックアップ、障害対応等の責任分担が明確か |
| 追加改修 | 導入後に機能を追加・変更する方法が分かるか |
| 依存関係 | ベンダーやプラットフォームへの依存を把握しているか |
| データ搬出 | 他システムへ移行するときにデータを取り出せるか |
| 契約終了 | 解約・移行時に必要な対応が分かるか |
| 追加質問 | 不明点について各ベンダーへ同じ観点で確認したか |
| 説明可能性 | なぜその提案を選ぶのか社内へ説明できるか |
このチェックリストは、該当数や○△×の合計によって自動的に採用ベンダーを決めるためのものではありません。
必須要件を満たさない提案や、自社にとって許容できない制約・重大なリスクがある提案については、他の項目で高い評価を得ていても別途検討する必要があります。
まとめ
複数ベンダーからSaaS、ローコード、スクラッチなど異なる方式の提案を受けた場合、方式名、初期費用、機能数だけで比較すると、それぞれの前提条件や導入後の違いを見落とす可能性があります。
まず「何の課題を解決したいのか」へ戻り、必須要件と自社の制約を整理します。そのうえで、運用体制、費用構造、技術・セキュリティ上のリスク、将来の変更や撤退まで、共通の判断軸へ各提案を置き直します。
見積金額が異なる場合も、すぐに高い・安いと判断するのではなく、データ移行、連携、ライセンス、保守、追加改修等の範囲を確認します。不明点があれば、各ベンダーへ同じ観点の質問を返すことで比較条件をそろえられます。
評価表や点数化は判断を補助する手段として利用できますが、必須要件や重大なリスクまで単純な合計点だけで判断しないことも重要です。
SCI総合研究所株式会社のKAMUSHIRUBEでは、「SaaS、ローコード、スクラッチなど方式の異なる提案を受け、どの基準で比較すればよいか分からない」「ベンダーごとに説明や見積範囲が異なり、提案の妥当性を判断しにくい」といった段階から相談できます。
特定のベンダーや方式を一方的に選定するのではなく、各提案の課題への適合、前提条件、費用、運用、セキュリティ、リスク等の論点を整理し、自社で選定理由を説明できる状態を目指します。