システムの見積もり・ベンダー提案はどう比較する？発注前の確認リスト

システムの導入や刷新で複数の提案を受け取ると、まず総額の差に目が向きます。しかし、提案ごとに含まれる作業や前提が違えば、総額を並べても同じものを比べたことになりません。

提案の間で差が出やすいのは、次のような点です。

• 対象範囲：どの業務・画面・帳票まで作るか。外部のシステムとの連携を含むか。
• 発注側が担当する作業：データの整備、業務ルールの確認、テストへの参加、利用者への説明を、どちらが担当するか。
• ライセンス・基盤の費用：利用人数やデータ量に応じて増える費用が、見積もりに含まれているか、別途か。
• データ移行：過去のデータのどこまでを、誰が整えて移すか。
• 保守・運用：問い合わせへの対応、不具合の修正、更新作業が、どの条件で月額に含まれるか。

安い提案や明細の少ない提案が、それだけで不適切とは言えません。対象を絞った提案や、発注側の作業を前提にした提案もあります。比較で必要なのは、何が含まれ、何が含まれていないかを、同じ条件にそろえて確認することです。

提案を比べる前に、自社が求める条件を短く書き出します。各社の提案は、この条件に対する回答として読み直します。

• 達成したい業務：どの業務を、どの状態にしたいか（例：受注から請求までの二重入力をなくす）。
• 利用規模：利用する人数、データ量、処理の頻度。
• 期限：稼働が必要な時期と、その理由。
• 必須条件：満たさなければ採用できない条件（連携先、権限、扱うデータなど）。
• 現行システムの制約：停止できる時間、残すシステム、契約の更新時期。

費用は、比較する期間をそろえます。初期費用が安く月額が高い提案と、その逆の提案は、1年目の金額だけでは比べられません。利用を見込む期間を決め、その期間の初期費用と継続費用を合わせて比べます。

要求がまだ固まっていない段階の見積もりは、多くの前提を置いた概算です。未確定の要求が多いまま概算で本開発を発注すると、前提が変わるたびに範囲と金額が動き、比較した意味が薄れます。この場合は、要求の整理を先に進め、整理した内容で見積もりを取り直す選択肢があります。IPAの解説では、要件定義は発注者の仕事であり、ベンダーの支援を受けても成果物の責任は発注者にあるとされています（IPA DX SQUARE「要件定義とは？」）。

どの業務から手を付けるか自体が決まっていない場合は、DX推進の全体像と優先順位の付け方から整理します。既存システムの刷新で、移行の方式や切替の計画から検討したい場合は、レガシーシステム移行の進め方が参考になります。

比較表では、項目ごとに自社が求める条件を置き、その横に各社の記載を並べます。次の8項目を基本にし、案件に合わせて追加・統合します。

各社の欄には、記載の内容に加えて、状態と出典を残します。

• 状態：確認済 / 対象外 / 未確認のいずれか。提案書に書かれていない事項は「非対応」とせず、「未確認」として質問に回します。
• 出典：資料名、版、ページ。口頭で回答を受けた場合は、回答者と日付。

必須条件は点数で相殺しません。先に満たす / 満たさない / 未確認を判定し、そのうえで任意の項目に重みを付けます。重みは自社の目的に合わせて決めます。

提案書では、性能、復旧、セキュリティなどの非機能の要求について、機能の説明に比べて具体的な条件が書かれていないことがあります。IPAが公開している非機能要求グレード（2018年版。現在はアーカイブとして掲載）は、非機能の要求項目を一覧にし、発注者と開発者の認識のずれを防ぐための資料で、確認する項目を洗い出す際の参考になります（非機能要求グレードの紹介ページ）。

データ移行の記載を、2つの提案で比べた記入例です。記入の仕方を示すために作成した例で、実際の案件ではありません。

この例だけで、Aが割安、Bが割高、どちらかが不適切とは判断できません。未記載の部分を質問で確認し、同じ条件にそろえた見積もりで比べます。

費用は、期間・人数・利用量・税の扱いをそろえたうえで、次の3つに分けて記録します。

• 見積もりに含まれる費用：初期費用と、比較する期間の継続費用（月額×月数、または年額×年数）。
• 必須の別途費用：見積もりには含まれていないが、利用に必要な費用（ライセンス、基盤、移行作業など）。金額が分からないものは、次の「まだ分からない費用」に記録します。
• まだ分からない費用：未確認の作業や、条件によって変わる費用。金額を仮に置かず、質問の対象にします。

現時点で金額と前提を確認できた費用は、「初期費用＋継続費用（比較する期間の分）＋金額を確認できた必須の別途費用」で小計を出します。まだ分からない費用は別の欄に残し、0円としては扱いません。

小計は、確認できた範囲どうしを比べる材料になります。ただし、必須の費用が未確認の提案は、小計だけで割安・割高や順位を判断せず、同じ条件を示して金額を確認します。条件がそろい、対象の費用を確認できた段階で、比較する期間の総額として比べます。

比較表で「未確認」になった項目は、質問にして各社へ送ります。各社には同じ質問文を送り、どの資料のどの箇所についての質問か、どのような回答がほしいかを添えると、回答がそろいやすくなります。手元の質問一覧には、回答が判断にどう影響するかも記録しておきます。

• 対象外：見積もりに含まれない作業は何か。その作業が必要になった場合はどう扱うか。
• データ移行：移行の対象データ、対象期間、形式、データ整備の担当は、どこまで見積もりに含まれるか。
• 運用保守：月額の保守に含まれる対応（問い合わせ、不具合の修正、更新作業）と、含まれない対応は何か。
• 追加見積：どの条件で追加見積になるか。仕様変更の受け付け方と、金額の決め方はどうなるか。
• 納品物：納品される成果物（設計書、操作手順、ソースコード、設定情報など）と、その形式は何か。
• 管理権限：システムやクラウドの管理者権限、ドメイン・アカウントの名義は、どちらが持つか。
• 引き継ぎ：契約終了時に、データの出力、ドキュメントの提供、他社への引き継ぎに、どこまで協力を受けられるか。

受け取った回答は、質問・回答者・回答日とともに一覧にまとめ、比較表の該当する欄を更新します。

受入は、納品されたものが合意した条件を満たしているかを確認する作業です。確認する業務と方法を発注前に決めておくと、納品時の認識の違いを減らせます。データ移行を例にすると、次のように書き出します。

この表は、案件ごとに合意するためのたたき台です。表を埋めただけで、契約上の受入条件が決まるわけではありません。契約書の条項としてどう定めるか、法的にどう扱うかは、技術的な確認とは分けて、契約の担当者や専門家と確認します。

比較表と質問の一覧は、社内でも作れます。一方で、次のような場合は、外部の担当者に提案を読み直してもらう方法（セカンドオピニオン）もあります。

• 提案が1社だけで、内容と金額が自社の条件に合っているか確かめたい。
• 複数社の前提（範囲・期間・人数）が違い、そろえ方が分からない。
• 移行、保守、セキュリティなどの重要な項目が未確認のまま、判断の期限が近い。
• 社内に、技術的な記載を読み解いて判断できる担当者がいない。

外部のレビューで整理できるのは、技術的な判断の材料です。発注先の選定と決定、予算、業務上の優先順位、最終的な受入の判断は、自社で行います。

Malakeでは、外部IT責任者・IT顧問の支援の一つとして、提案・見積もりのレビューを行っています。要求と提案の比較表、ベンダーへの質問一覧、受入条件のたたき台、判断事項の整理を、開始前に合意した形式と範囲で作成します。初回相談（無料）では、状況と支援の範囲を確認します。有料のレビューは、対象の資料、提案の社数、成果物、レビューの回数を確認して個別にお見積もりします。

この記事は、一つの導入・刷新で受け取った提案を比べる方法を扱っています。社内のIT運用を継続して外部へ任せる場合の体制と費用は、情シス外注の費用と選び方で整理しています。

発注の前に確認する項目を、チェックリストにまとめました。