経営者向け：保守費の保守先変更を見積依頼する前に整理する範囲・費用・本番化条件

先に結論：見積前にやるべきことは「安い会社探し」ではなく「同じ条件で見積もれる状態づくり」です

保守費が高い。毎月の月額は払っているのに、障害対応が遅い。軽微な改修でも見積が高い。担当者が変わり、過去の経緯が分からなくなっている。経営者がこの状態で、別の保守会社に見積を取りたいと考えるのは自然です。

ただし、保守先変更の見積は、開発の相見積よりも前提が崩れやすい領域です。なぜなら、新しい保守会社は、現行システムを作った会社ではありません。コード、構成、運用、障害履歴、権限、監視、バックアップ、契約条件、既存ベンダーの暗黙知を見なければ、どこまで責任を持てるか判断できません。

見積依頼前に整理がないまま「月額いくらで保守できますか」と聞くと、候補会社ごとに前提が変わります。ある会社は障害一次対応だけを保守に入れ、別の会社は軽微改修を含め、別の会社は初期調査を別費用にし、別の会社はセキュリティ更新を除外します。すると、見積金額を並べても比較できません。

結論は次の10点です。ここだけ読んでも、見積前に何をそろえるべきか分かるように整理します。

最重要ポイント: 保守先変更の見積前に必要なのは、対象範囲、現行費用、引き継ぎ資料、権限、SLA、初期調査、並行運用、本番化条件、除外条件、移管後KPIをそろえることです。ここが曖昧なまま相見積を取ると、安い見積ではなく、前提が薄い見積を選んでしまいます。

1. 保守対象を確定する: システム、画面、帳票、バッチ、API、外部SaaS、クラウド、ドメイン、証明書、監視、バックアップのどこまでを保守対象にするかを決める
2. 現行保守費を分解する: 月額を、定常運用、障害対応、軽微改修、問い合わせ、監視、バックアップ、セキュリティ、ライセンス、クラウド実費に分ける
3. 見積前資料をそろえる: 構成図、設計書、ソースコード、環境情報、障害履歴、改修履歴、権限一覧、監視設定、バックアップ手順、契約書を候補会社へ渡せる状態にする
4. 初期調査を別枠で見る: 新保守会社が最初に行うコード調査、環境調査、権限確認、監視確認、バックアップ確認は、月額保守とは分けて見積もる
5. 保守内と別費用を分ける: 障害対応、不具合修正、軽微改修、仕様変更、セキュリティ更新、法改正対応、性能改善を同じ「保守」に混ぜない
6. 既存ベンダー協力を条件化する: 資料提供、質問回答、権限移管、並行運用、解約後協力の有無を、候補会社の見積前提に入れる
7. 本番化条件を決める: 新保守会社へ完全移管する条件を、障害訓練、リリース訓練、バックアップ復元、権限切替、月次報告で判断する
8. 初年度と2年目以降を分ける: 初年度は移管費、並行運用費、資料整備費が出やすく、2年目以降に保守費削減が効く構造として見る
9. 候補会社へ同じ質問を出す: 各社に同じ資料、同じ質問、同じ前提条件を渡し、金額ではなく範囲差とリスク差で比較する
10. 移管後KPIで評価する: 削減額だけでなく、障害件数、初動時間、復旧時間、軽微改修リードタイム、追加費用件数、未対応課題数で見る

この記事は、保守費を下げるために保守先変更を検討しており、これから候補会社へ見積依頼を出す経営者向けです。既存ベンダーを変えるべきかの判断そのものは、経営者向け：保守費を下げるために保守先を変更する前に見る引き継ぎ条件で扱っています。本記事は、その次の段階である「見積前に何をそろえるか」に絞ります。

この記事を読むべき会社

この記事は、業務システム、基幹システム、EC、予約システム、会員サイト、販売管理、在庫管理、CRM、SFA、帳票システム、社内ポータル、クラウド環境、オンプレ環境、レガシーシステムの保守費を見直し、既存ベンダーから別会社へ保守先を変更したい中小・中堅企業の経営者、CIO、DX責任者、情シス責任者、管理部門向けです。

特に、次の状態にある企業に役立ちます。

• 見積を取りたいが前提がない: 新しい保守会社に何を渡せばよいか分からない
• 月額だけ比較しそう: 既存保守費と候補会社の月額だけで判断しようとしている
• 既存資料が古い: 設計書、運用手順、障害履歴、権限一覧が最新か分からない
• 保守範囲が曖昧: 障害対応、軽微改修、問い合わせ、セキュリティ対応の境界が分からない
• 初年度費用が読めない: 移管費、並行運用費、資料整備費、緊急改修費が社内説明できない
• 候補会社の見積を比較できない: 各社の提案範囲、除外条件、責任分界がばらばらになりそう
• 本番化が不安: 新保守会社に切り替えた後、障害時に本当に動けるか不安がある
• 社内稟議を通したい: 保守費削減だけでなく、リスクと品質改善を経営会議で説明したい

逆に、まだ保守先を変えるべきか分からない段階なら、先に既存ベンダー変更判断の記事を読むべきです。すでに候補会社へ正式提案依頼を出す段階なら、次のRFP記事で評価軸と契約条件を整理するべきです。

事前に整理できること

ここで扱うのは「保守会社を紹介してください」ではありません。事前に整理したいのは、保守先変更の見積前診断、現行保守費の分解、引き継ぎ資料の棚卸し、候補会社へ出す見積条件書の作成、見積比較表の設計、90日移管計画、本番化条件の整理です。

関連する支援は システム開発・DXの相談 で確認できます。

関連記事との使い分け

保守費、保守先変更、見積、RFP、引き継ぎは近い検索意図が多いため、記事の役割を明確に分けます。

この切り分けにより、同じ「保守費」でも知りたい内容を分けます。本記事の中心は、保守先変更の見積依頼前に、各社が同じ前提で見積もれる状態を作ることです。

見積依頼前に決めるべき7つの範囲

保守先変更の見積で最初に決めるべきことは、月額ではなく範囲です。範囲が曖昧なまま見積を取ると、安い会社ほど対象外が多く、高い会社ほどリスクを見込んでいるだけ、という比較不能な状態になります。

ここでの判断軸: 候補会社に「保守できますか」と聞く前に、何を保守対象にするか、何を対象外にするか、対象外を誰が持つかを決めます。

この7つを最初に決めると、候補会社の見積は比較しやすくなります。逆に、この7つが曖昧なまま月額だけを比較すると、月額の差が「安さ」なのか「範囲の少なさ」なのか分からなくなります。

現行保守費を見積前に分解する

候補会社に見積を依頼する前に、現行保守費を分解します。目的は、既存ベンダーを責めることではありません。新しい保守会社が同じ条件で見積もれるように、いま何に費用がかかっているかを見える状態にすることです。

見積前にこの分解をしておくと、候補会社の見積に対して「現行より安いか」ではなく、「現行と同じ範囲を含んでいるか」「削ってよい項目を削っているか」「削ってはいけない項目まで削っていないか」を確認できます。

候補会社へ渡す見積前資料

保守先変更の見積は、資料の質で精度が変わります。完璧な設計書がなくても見積依頼はできますが、何があるか、何がないかを明示しなければ、候補会社はリスクを見込むか、範囲を狭めます。

最低限そろえる資料: 設計書だけでは足りません。構成、コード、環境、障害、改修、権限、監視、バックアップ、契約の9領域を見積前に棚卸しします。

資料がないこと自体は、珍しくありません。問題は、資料がないことを隠して見積を取ることです。資料がない項目は「初期調査で確認する」「旧ベンダーへ回収依頼する」「移管後の改善対象にする」と分ける必要があります。

初期調査費を月額保守に混ぜない

保守先変更では、初月から安い月額を求めすぎると失敗します。新しい保守会社は、現行システムの中身を知らないため、最初に調査が必要です。この初期調査を月額保守に混ぜると、見積が安く見える一方で、実際には調査不足のまま運用が始まります。

見積前には、候補会社へ「初期調査を月額保守に含めるのか、別費用にするのか」「初期調査の成果物は何か」「調査後に月額が変わる条件はあるか」を聞きます。初期調査を明示する会社は、見積が高く見えることがあります。しかし、実務上は、その方が移管後の追加費用を説明しやすいです。

保守内と別費用の境界を決める

保守費の見積で最も揉めるのは、「これは保守に含まれると思っていた」という認識差です。候補会社へ見積依頼する前に、保守内と別費用の境界を決めます。

この境界を候補会社ごとに確認すると、月額の差が見えるようになります。月額30万円の会社が安いのではなく、軽微改修、緊急対応、バックアップ復元、セキュリティ更新を含んでいないだけかもしれません。逆に、月額60万円の会社が高いのではなく、重要な運用を含んでいる可能性もあります。

本番化条件を見積前に決める

保守先変更は、契約開始日がゴールではありません。新しい保守会社が本番環境を理解し、障害時に動ける状態になることがゴールです。そのため、見積前に本番化条件を決めます。

完全移管の条件: 新保守会社が「資料を読んだ」だけでは不十分です。障害対応、リリース、バックアップ復元、権限切替、月次報告を一度通してから完全移管します。

見積依頼時には、「完全移管までに何を確認するか」「本番化判定会議を行うか」「判定前の障害責任は誰が持つか」を候補会社へ聞きます。ここが曖昧だと、契約は始まったのに新会社が本番環境を触れない、旧会社も責任を持たない、という空白期間が生まれます。

初年度と2年目以降の費用を分ける

保守先変更の稟議では、初年度から保守費削減額だけを効果として出すと誤ります。初年度は、移管費、調査費、資料整備費、並行運用費が発生しやすいからです。

たとえば、現行保守費が月額80万円、新保守費が月額50万円なら、月額差は30万円、年間差は360万円です。しかし、初年度に初期調査120万円、資料整備80万円、並行運用2か月分160万円、監視再設計60万円が出れば、初年度は削減効果がほぼ消えます。これは失敗ではありません。見えなかった運用負債を移管時に整理している状態です。

稟議では、初年度は移管投資、2年目以降は保守費削減と品質改善、と分けます。経営者が見るべきなのは、初年度だけで黒字になるかではなく、2年目以降に障害、追加費用、改修待ち、属人化が減るかです。

候補会社へ出す見積依頼テンプレート

候補会社へ見積を依頼するときは、各社に同じ情報を渡します。メール本文で「保守をお願いします」と送るのではなく、次の項目を見積条件書として渡します。

このテンプレートを使うと、候補会社の見積は比較しやすくなります。見積を安く見せる会社は、対象外が増えます。実務的な会社は、資料不足、旧ベンダー協力、初期調査、並行運用を条件に入れます。経営者は、金額だけでなく「どこまで見えている見積か」を判断できます。

GXO式「保守移管・見積条件書5ゲート100点」判定表

この記事の肝は、条件書を作ったかどうかではなく、候補会社が同じ条件で見積もれる完成度かを100点で判定することです。GXO独自分析として、見積条件書を「対象範囲」「現状証拠」「費用構造」「SLA・除外」「移管・本番化」の5ゲートに分解しました。

公式資料で確認できる事実とGXO独自分析は分けて扱います。契約・非機能・セキュリティの確認観点は出典へひも付け、配点、見積停止条件、比較方法はGXOの実務判断として明示します。

各ゲートは5項目、1項目4点の合計20点です。採点は 0点＝未記載・口頭説明のみ、2点＝記載はあるが数量・責任者・証拠のいずれかが欠ける、4点＝条件書の記載箇所と証拠を第三者が追跡できる の3段階とします。Gate 1またはGate 2に0点の項目がある場合、合計点が高くても相見積を開始しません。 対象と現状が不明なままでは、金額を比較しても意味がないためです。

Gate 1：対象範囲（20点）

刺さらない条件書の例

「販売管理システム一式を保守してください」では、候補会社は責任を持てません。例えば、請求バッチは保守対象でも、その前段のCSV加工と後段の会計SaaS連携が対象外なら、月末障害の責任が分かれます。

条件書では、次のように境界を書きます。

対象：販売管理Web、請求バッチ、帳票、DB、監視
外部連携：会計SaaSへのCSV出力まで対象、取込後は対象外
軽微改修：月10時間以内、DB変更・API変更は対象外
問い合わせ：業務責任者2名からの依頼に限定

Gate 1のレッドフラグと通過基準

• レッドフラグ: 「一式」「関連作業」「柔軟に対応」とだけ書かれている
• レッドフラグ: 外部サービス障害時の一次切り分け担当がいない
• 通過基準: 障害が起きた箇所ごとに、誰が受付・調査・復旧するか説明できる

Gate 2：現状証拠（20点）

具体例：障害実績を隠すと、安い月額が出る

月額40万円の見積でも、候補会社が「障害は月1件程度」と想定し、実際には月15件なら、契約後に体制増強や追加費用が必要になります。障害件数を隠すことは値下げ交渉ではなく、比較条件を壊す行為です。

資料がない場合は空欄にせず、次のように明記します。

DB定義：2019年版のみ。現行との差分は初期調査対象
復元試験：実施記録なし。移管判定までに実施
障害履歴：メールから直近12か月分を再集計予定
クラウド管理者：旧ベンダー。名義変更可否を確認中

Gate 2のレッドフラグと通過基準

• レッドフラグ: 資料がないことを候補会社へ伝えていない
• レッドフラグ: 障害・改修件数が「多い」「少ない」という感覚値だけ
• 通過基準: 候補会社が、確認済み・未確認・初期調査・対象外を分けて見積もれる

Gate 3：費用構造（20点）

24か月総費用の比較式

24か月総費用 = 初期調査 + 資料整備 + 並行運用
             + 月額保守 × 24
             + クラウド・SaaS・ライセンス
             + 想定追加作業件数 × 追加単価
             + 社内移管工数 × 社内時間単価

月額だけではなく、障害の時間外対応、軽微改修超過、緊急パッチ、復元訓練など、発生可能性が高い別費用へ想定件数を入れます。

Gate 3のレッドフラグと通過基準

• レッドフラグ: 初期調査が無料だが、調査成果物と完了条件がない
• レッドフラグ: 「個別見積」の単価・最小請求時間・承認方法がない
• 通過基準: 安値・標準・障害多発の3シナリオで24か月総費用を比較できる

Gate 4：SLA・除外条件（20点）

危ない回答と比較可能な回答

Gate 4のレッドフラグと通過基準

• レッドフラグ: SLAが努力目標だけで、報告・改善条件がない
• レッドフラグ: 対象外にした作業の引き渡し先がない
• 通過基準: 同じ障害シナリオを各候補へ渡し、対応範囲・時間・追加費用を横並び比較できる

Gate 5：移管・本番化（20点）

具体例：契約開始済みなのに、誰も本番へ触れない

新契約の開始日と旧契約の終了日だけを決め、完全移管判定を置かないと、新会社は「まだ引き継ぎ中」、旧会社は「契約終了済み」と主張する空白が生まれます。見積には、並行運用の会議・訓練・判定作業まで含めます。

Gate 5のレッドフラグと通過基準

• レッドフラグ: 新契約開始日と旧契約終了日が同じ
• レッドフラグ: 移管完了が「資料受領」で、実地訓練がない
• 通過基準: 新保守先が重要運用を実行し、残課題と例外を経営者が承認してから旧契約を終える

点数の読み方

GXO式・保守移管見積条件書100点をCSVでダウンロード

25項目をぶれずに採点する「0・2・4点」アンカー

担当者の印象で点数を付けると、判定表そのものが形骸化します。25項目すべてに共通して、次の証拠ルールを適用します。

証拠は、条件書の記載箇所 → 添付資料 → 確認日 → 確認者の順でひも付けます。スクリーンショットだけでは設定全体や更新性を証明できないため、可能なら設定エクスポート、管理画面の閲覧、ログ、実地試験を優先します。候補会社の提案書だけで自社環境の状態を証明してはいけません。

資料がない・旧ベンダーが協力しない場合の代替調査

資料欠損を理由に、推測で満点を付けてはいけません。一方で、旧ベンダーの回答待ちだけで移管を止め続ける必要もありません。欠けた証拠ごとに代替調査と経営判断を決めます。

旧ベンダーの協力拒否は、新ベンダーの能力では解決できないことがあります。著作権、契約上の成果物、アカウント名義、データ返還は、契約書と事実を整理したうえで必要に応じて弁護士等の専門家へ確認します。本記事の判定表は法的判断を代替しません。

システム形態別に、同じ点数でも見る証拠は変わる

3つの記入済みケース：点数から経営判断まで

以下は採点方法を示す架空例です。実在企業やGXOの支援実績を示すものではありません。

製造業例は70点でも見積へ進めません。Gate 2の復元項目が0点なら、総合点より停止条件を優先するためです。EC例は価格回答を受け取っても、決済障害シナリオを全社へ再提示するまで順位を付けません。92点のSaaS連携例でも、残り8点を「契約後に相談」へ逃がさず、条件付き事項として契約・移管計画へ転記します。

合計点だけで決めない最終判定マトリクス

重大欠陥は、保守対象が特定できない、自社が管理権限を持てない、本番とコードの一致を確認できない、復元できない、重大障害の受付先がない、新旧どちらも責任を持たない期間があるの6つです。1つでも残る場合、月額が安くても契約判定を通しません。

採点結果を「再質問・見積・契約・90日移管」へ変換する

判定表は採点して終わりではありません。0点と2点を、次の成果物へ一度ずつ転記します。

この変換を行うと、候補会社が営業提案で約束した内容を、見積条件、契約、運用、本番化判定まで切れ目なく追跡できます。逆に転記先がない点数は、意思決定には使われていません。

記入済み比較例：月額40万円のA社を選ばない理由

以下は使い方を示す架空例で、GXOの支援実績ではありません。

A社は最安ですが、Gate 2の復元実績が0点、Gate 4の除外条件も不明です。安さではなく、障害多発時の追加費用と復旧不能リスクが読めないため見送りです。B社は一部を条件調整すれば比較可能、C社は高い理由を説明できます。

この比較例の価値は「B社を選ぶ」ことではありません。月額差の理由を、範囲・証拠・追加費用・本番化条件へ分解し、経営会議で説明できることです。

見積条件書の根拠と検証方法

5ゲートは、デジタル庁のシステム整備・管理、IPAのモデル契約、非機能要求、セキュリティ対策を、保守移管の見積条件へ再構成したものです。

• 判定表バージョン: 2.0（2026年7月13日）。20項目・各5点から、25項目・0/2/4点の証拠採点へ改訂
• 監修範囲: GXO AI・DX開発チームが、見積範囲、保守運用、非機能、移管・本番化条件を確認
• 非監修範囲: 個別契約の法律判断、特定候補会社の履行保証、停止損失の保証
• 更新条件: 公式資料の改定、実際の見積比較で不足項目が判明した場合に版番号と更新日を変更
• 検証可能性: 各点数に条件書の記載箇所・添付資料・候補会社回答をひも付け、口頭説明だけでは満点にしない

候補会社に必ず聞く20問

見積前に候補会社へ同じ質問を出します。回答の質を見ることで、安い会社ではなく、移管リスクを説明できる会社を選びやすくなります。

1. 初期調査で何を見ますか。 コード、環境、権限、監視、バックアップ、障害履歴を含めるか確認する
2. 月額保守に含む作業は何ですか。 障害対応、不具合修正、問い合わせ、軽微改修を分けて確認する
3. 月額保守に含まない作業は何ですか。 仕様変更、機能追加、緊急脆弱性対応、性能改善の扱いを確認する
4. 軽微改修の上限はありますか。 月間時間、件数、対象作業、除外条件を確認する
5. 障害の受付時間と初動目標は何ですか。 平日日中、夜間休日、緊急度別の扱いを確認する
6. 原因調査と根本改修はどこで分かれますか。 暫定復旧、原因分析、再発防止の費用を確認する
7. 監視と通知はどこまで対応しますか。 既存監視の維持、新規監視、通知先、一次対応を確認する
8. バックアップ復元確認は含まれますか。 取得確認だけか、実復元まで行うか確認する
9. セキュリティ更新はどこまで含みますか。 パッチ判断、証明書、脆弱性対応、権限棚卸しを確認する
10. 旧ベンダーとの並行運用に参加できますか。 会議、質問回答、責任分界表の作成を確認する
11. 資料が不足している場合の進め方は何ですか。 追加調査、見積条件、対象外の扱いを確認する
12. ソースコード権限がない場合はどうしますか。 旧ベンダー依頼、再構築、対象外の判断を確認する
13. クラウド名義が旧ベンダーの場合は対応できますか。 名義変更、権限移管、請求分離を確認する
14. リリース手順がない場合は作れますか。 手順作成、検証環境、戻し手順を確認する
15. 月次報告には何を含めますか。 障害、問い合わせ、改修、未対応課題、改善提案を確認する
16. 初年度と2年目以降の費用を分けられますか。 移管費と継続保守費を分ける
17. 保守開始後に月額が変わる条件は何ですか。 範囲追加、障害多発、資料不足、利用増を確認する
18. 引き受けられない条件は何ですか。 技術、権限、契約、セキュリティ上の限界を確認する
19. 完全移管の判定条件は何ですか。 障害訓練、リリース訓練、復元確認を確認する
20. 他社との違いは価格以外で何ですか。 保守品質、改善提案、移管PMO、運用設計を見る

危ない回答は、「資料がなくても大丈夫です」「月額内で柔軟に対応します」「障害時はできる限り早く対応します」のように、範囲、時間、除外条件、成果物が曖昧な回答です。良い回答は、分からないことを分からないと言い、初期調査と条件付き見積に分けます。

見積比較表で見るべき項目

候補会社の見積が集まったら、月額の安い順に並べてはいけません。比較表では、初年度総額、2年目以降、含まれる作業、対象外、リスク、成果物を並べます。

この比較表を作ると、A社が月額40万円、B社が月額55万円、C社が月額70万円でも、単純な高低では判断できません。A社は初期調査なし、軽微改修なし、バックアップ復元なし。B社は標準的。C社は監視再設計と月次改善まで含む。こうした違いが見えると、経営会議で「なぜ一番安い会社を選ばないのか」を説明できます。

社内稟議で使う説明の型

保守先変更の稟議は、「月額が下がります」だけでは通りにくいです。障害が起きたときの責任、初年度費用、旧ベンダーとの関係、社内作業、リスクを説明する必要があります。

稟議では、次の順番で説明します。

1. 現状課題: 現行保守費の内訳、障害対応、軽微改修、属人化、資料不足を説明する
2. 変更目的: 月額削減だけでなく、障害対応改善、改修速度改善、権限整理、運用品質改善を目的にする
3. 見積前提: 対象範囲、資料状況、初期調査、旧ベンダー協力、本番化条件を説明する
4. 候補会社比較: 月額、初年度総額、2年目以降、対象外、リスク、成果物を比較する
5. 初年度投資: 移管費、資料整備費、並行運用費が必要な理由を説明する
6. 移管計画: 30日、60日、90日の確認事項を説明する
7. 成功KPI: 障害件数、初動時間、改修リードタイム、追加費用、未対応課題を説明する

社内説明で重要なのは、安くなることを誇張しないことです。初年度は増える可能性があります。その代わり、2年目以降に月額を下げ、障害と追加費用を減らし、社内の説明責任を高める。このストーリーで稟議を作る方が、後から揉めにくくなります。

90日移管計画を見積前に入れる

候補会社の見積には、90日移管計画を入れてもらいます。保守先変更は、契約日ではなく、90日で安定運用へ移すプロジェクトとして見ます。

見積前に90日計画を入れる理由は、候補会社の実務力を見るためです。移管計画を具体的に出せない会社は、月額保守が始まった後に「聞いていません」「資料がありません」「旧ベンダーに確認してください」となりやすいです。

業種別に見積前へ入れるべき条件

保守先変更の見積条件は、業種によって重要項目が変わります。同じ月額保守でも、EC、製造、士業、医療、物流、BtoB業務システムでは止めてはいけない機能が違います。

業種別条件を見積前に入れると、候補会社は一般的な保守ではなく、自社の止めてはいけない業務を前提に見積もれます。保守費を下げることが目的でも、止めてはいけない業務の保守まで削ると、削減額以上の損失が出ます。

見積前に保守先変更を止めるべきケース

見積を取る前に、保守先変更を一時停止すべきケースもあります。無理に見積を取ると、候補会社から高い見積しか出ないか、引き受けられないと言われます。

• ソースコードが社内にない: 既存ベンダー管理で、契約上の引き渡し権利も曖昧
• 本番環境の管理者が社内にいない: クラウド、ドメイン、証明書、DBの権限が旧ベンダーのみ
• 障害履歴が残っていない: 同じ障害の再発リスクが読めない
• 設計書と実装が大きく違う: 候補会社が見積前提を作れない
• 重要リリース直前: 制度改正、繁忙期、大型改修前で移管リスクが高い
• 既存ベンダーとの契約終了条件が不明: 解約後協力、資料提供、権限移管で揉める
• 現行システムが古すぎる: 保守先変更より刷新、再構築、SaaS移行を検討すべき

この場合は、いきなり相見積を取るのではなく、現状診断、資料回収、権限整理、契約確認を先に行います。候補会社へ見積を依頼するのは、その後です。

GXOの見積前診断で作る成果物

GXOが保守先変更の見積前診断を行う場合、最初から新しい保守契約を決めるのではなく、候補会社が同じ前提で見積もれる成果物を作ります。

この成果物があると、見積を取る前に候補会社の比較条件がそろいます。逆に、成果物がないまま見積を取ると、各社の前提が違い、社内説明に使えない見積が集まります。

よくある質問

Q. 見積前に完璧な設計書が必要ですか

必要ありません。ただし、設計書がないなら、ないことを候補会社へ明示し、初期調査費や資料整備費に入れる必要があります。資料がない状態を隠して月額だけの見積を取ると、移管後に追加費用や対象外が増えます。

Q. 保守先変更の見積は何社から取るべきですか

候補は2〜3社で十分です。重要なのは社数ではなく、同じ資料、同じ質問、同じ前提条件で回答させることです。5社以上にばらばらの前提で依頼すると、比較表を作るだけで時間がかかり、結局金額だけで選びやすくなります。

Q. 一番安い月額の会社を選んではいけませんか

選んではいけないわけではありません。ただし、安い理由を確認してください。初期調査、軽微改修、監視、バックアップ復元、セキュリティ更新、旧ベンダー協力、月次報告が対象外なら、月額が安くても年間総額は高くなります。

Q. 既存ベンダーに見積前資料を依頼すると関係が悪くなりませんか

言い方と順番が重要です。いきなり解約前提で依頼するのではなく、保守範囲の見直し、資料整理、権限棚卸しとして始める方法があります。契約上の引き渡し義務や成果物の所有権も確認してください。

Q. 初年度に費用が増えるなら、保守先変更の意味はありますか

あります。初年度は移管投資として増えることがありますが、2年目以降に月額を下げ、障害、追加費用、改修待ち、属人化を減らせるなら意味があります。初年度だけで判断せず、2年目以降の費用と品質KPIで評価してください。

Q. RFPはいつ作るべきですか

見積条件書と候補会社質問票を作り、保守対象、費用、初期調査、除外条件、本番化条件がそろった後です。RFPは正式な提案依頼です。本記事は、その前段階で比較可能な見積前提を作るための記事です。

GXOに相談すべきタイミング

次のどれかに当てはまるなら、記事を読むだけで止めず、保守先変更の見積前診断から相談してください。

• 新しい保守会社へ何を渡せばよいか分からない
• 現行保守費の内訳を経営会議で説明できない
• 候補会社の見積が安いのか、範囲が薄いのか判断できない
• 初期調査費、並行運用費、資料整備費を稟議で説明したい
• 旧ベンダーから何を引き継がせるべきか整理したい
• 月額保守に含める作業と別費用にする作業を分けたい
• 90日で安全に保守先を移管する計画を作りたい

GXOでは、保守費内訳診断、見積条件書作成、候補会社質問票、見積比較表、既存保守契約レビュー、引き継ぎ資料チェック、90日移管計画、本番化判定表、レガシー刷新の優先順位整理を支援できます。

相談先は システム開発・DXの相談 です。

出典・参照した一次情報

• デジタル庁「デジタル社会推進標準ガイドライン」: https://www.digital.go.jp/resources/standard_guidelines
• IPA「情報システム・モデル取引・契約書」: https://www.ipa.go.jp/digital/model/index.html
• IPA「非機能要求グレード」: https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/ent03-b.html
• IPA「中小企業の情報セキュリティ対策ガイドライン」: https://www.ipa.go.jp/security/guide/sme/about.html

上記は2026-07-13に公式ページと内容を確認しました。この記事は一般的な実務整理であり、個別の契約解釈、システム停止リスク、法的判断、セキュリティ適合性を保証するものではありません。既存契約、個別システム、外部サービスの条件は、契約書、社内規程、顧問弁護士、専門家、各ベンダーの公式情報を確認してください。