ベンダーロックインで保守費用が下がらない理由｜公的調査データで見る構造と確認手順

ベンダーロックインの状態にあると保守費用が下がらない、という話はよく聞きます。ただ、その先で必要なのは「うちはロックインされているのか」「されているとして、次に何をすればいいのか」という判断です。本記事は、稼働中のシステムについてなぜ保守費用が下がりにくいのかという構造の側を扱います。実際に保守会社を変える手順そのものは本記事では扱わず、記事末尾で別記事へ引き継ぎます。

根拠には、日本で数少ない「ロックインの実データ」である公的調査を2つ使います。会計検査院が国の府省等の保守・運用契約を調べた報告（2004年度のデータ・2006年報告）と、公正取引委員会が官公庁の情報システム調達を調べた実態調査（2022年2月）です。いずれも民間企業の調査ではないため、そのまま相場として使うことはできません。使えるのは、価格が決まる仕組みのほうです。

TL;DR｜下がらない原因は交渉力ではなく「他社が見積もれる状態か」

先に結論を書きます。

• 保守費用が下がらない主因は、値引きを断られていることではなく、比較対象を作れないことです。 他社が見積もりを出すには、作業量・責任範囲・システム構成が読める資料が要ります。それが手元にないと、そもそも相見積もりが成立しません
• ロックインは、ベンダーが情報を出し渋ることで起きているとは限りません。 公正取引委員会の2022年調査では、既存ベンダーから合理的な理由なく仕様の開示やデータ引き継ぎを拒否されたと答えた機関は2.1%（有効回答1,009機関）でした。一方で、ロックイン防止のために工夫していることは「特になし」と答えた機関が25.3%（有効回答1,011機関）あります。偏っているのは意思ではなく、資料・権限・知識の置き場所です
• 効いた対策は、値下げ交渉ではなく発注単位と資料の作り直しでした。 会計検査院が挙げた改善事例は、いずれも「仕様書に作業量と責任範囲を書く」「他社でもできる業務を別契約に分ける」「マニュアルを整備する」のどれかを発注側が作り直すところから始まっています（事例ごとに組み合わせは違います）
• したがって最初の一手は、金額の議論ではなく引き継ぎ資産の棚卸しです。 仕様書・設計書、構成図・運用手順書、管理者権限、ソースコード、データ、権利——この引き継ぎ資産6点のうち、いま受け取れるものがいくつあるか。多くが揃っていれば価格は比較で検証できます。揃っていないなら、価格の妥当性は誰にも判定できません
• 既存ベンダーの継続が正解になることもあります。 引き継げる状態さえ確保できていれば、続けるか変えるかは毎回選び直せます。本記事のゴールは乗り換えの推奨ではなく、選べる状態にすることです

ベンダーロックインとは何か｜公正取引委員会の定義で確認する

言葉の輪郭を先に固めます。公正取引委員会は2022年2月の実態調査報告書で、ベンダーロックインを次のように定義しています。

ソフトウェアの機能改修やバージョンアップ、ハードウェアのメンテナンス等、情報システムを使い続けるために必要な作業を、それを導入した事業者以外が実施することができないために、特定のベンダーを利用し続けなくてはならない状態

出典: 公正取引委員会「官公庁における情報システム調達に関する実態調査報告書」（2022年2月）脚注1

この定義で押さえるべき点が2つあります。

1つは、主語が「事業者以外が実施することができない」であることです。高いか安いかは定義に入っていません。価格は結果であって、ロックインそのものではありません。したがって「保守費用が高い＝ロックイン」でも「保守費用が安い＝ロックインでない」でもありません。安くても他社に頼めなければロックインですし、高くても他社が同じ作業を見積もれるなら、それは単に価格の問題です。

もう1つは、対象が「使い続けるために必要な作業」であることです。新しく作り直すときの話ではありません。機能改修、バージョンアップ、メンテナンス——つまり保守契約の中身そのものが対象です。だからロックインは、稼働後の毎月の請求書に最も強く出ます。

なお、システムを一から作り直す局面の話はレガシーシステム刷新戦略で扱っています。本記事は作り直す前の、いま払い続けている保守費用の側です。

ロックインは「開示を断られた」から起きているわけではない

ロックインの説明は「ベンダーが情報を囲い込むから起きる」という語られ方をしがちです。ところが実態調査の数字は、その説明と噛み合いません。

公正取引委員会が全国1,835機関（すべての国の機関、都道府県、市区町村）へアンケートを行い、1,021機関から回答を得た調査（回答率約55.6%）では、ベンダーの行為について次の結果が出ています。いずれも有効回答数1,009機関に対する割合です。

出典: 同報告書 第4-1(1)、第4-2(1)、第4-3(1)

ロックインを「断られた結果」として説明するには、この数字は小さすぎます。 開示や引き継ぎを断られたと答えたのは2.1%です。

では何が起きているのか。同じ調査で発注側の状態を見ると輪郭が出ます。ロックイン防止のために工夫・留意していることを複数回答で聞いたところ、「構築完了時にベンダーから機能の詳細な説明や設計書等の情報提供を受けている」を選んだのは44.6%にとどまり、「特になし」が25.3%ありました（いずれも有効回答1,011機関）。項目ごとの実測値と、担当者側の体制の数字は「いまの発注側は何をしているか」の章にまとめてあります。

つまり構造はこうです。ベンダーが渡さないのではなく、渡された記録がない、渡されても読める人がいない、そもそも渡すという約束をしていない。ロックインは、悪意の産物というより、資料・権限・知識がベンダー側に集まったまま誰も引き取らなかったことの帰結です。

この「資料・権限・知識」は、対処を決めるにはまだ粗い言い方です。次章では、資料にあたる①仕様書・設計書・②構成図・運用手順書・④ソースコード、権限にあたる③管理者権限、そして契約に書いておくべき条件である⑤データ・⑥権利という6点へ置き換えます。知識は、6点を判定するための前提として別に置きます。

この見方は実務的にも重要です。原因が悪意なら対処は交渉ですが、原因が偏りなら対処は契約と資料の作り直しになります。前者は相手の同意が要りますが、後者は自社から着手できます。

保守見積書では、ロックインはこう書かれている

ロックインは見積書に「ロックイン」とは書かれません。次のような、ごく普通の行として現れます。右の列は、次章で定義する引き継ぎ資産6点のどれに効くかを示しています。

ERP のように料率が公表されている領域では、内訳の読み方が変わります。SAP保守費用の仕組みで 22% の料率とアドオン保守の分け方を整理しています。

右の列が、そのまま「他社が見積もりを作るために必要なもの」です。空欄が多いほど、他社は見積もれず、比較は成立しません。 金額の妥当性を議論する前に、この列が埋まっているかを見てください。

行項目そのものの読み解き方はシステム保守費用の相場と妥当性にまとめてあります。本記事は、その中でも引き継ぎ可能性に効く要素だけを取り出しています。

引き継ぎ資産6点｜どこに偏りが出るのか

「ベンダーに依存している」という言い方は、対処を考えるには粗すぎます。実務で効くのは、どの資産がどちらの手元にあるかという単位です。本記事は次の6点を「引き継ぎ資産」と呼び、以降すべての判定をこの6点で行います。

①仕様書・設計書｜誰が書いているかで決まる

最も影響が大きく、最も見落とされます。次章の政府データ（抽出された168契約の集計）が示すとおり、保守の仕様書を既存ベンダーの協力を得て書いている状態は、他社が入りにくい状態と相関します。 ベンダーが書いた仕様書は、そのベンダーが読める前提で書かれます。他社が読んで工数を積める粒度にはなりません。

設計書のほうは「あるか」ではなく「いつ時点のものか」で見ます。稼働時の設計書は残っているが、その後の改修が反映されていない、というのはよく見られる状態です。これは他社にとって、資料がないのとほぼ同じです。反映されていない改修があると分かっている資料は、そのまま見積もりの前提にできません。

経営判断への影響はシンプルです。仕様書を自社で書けない限り、相見積もりを取っても比較になりません。「他社は高かった」という結果が出たとき、それが本当に高いのか、条件が読めず安全側に見積もっただけなのかを区別できないからです。なお見積書に「設計書の更新」という費目が存在しないなら、更新されていない可能性が高いと考えてください。更新は無償では発生しません。

②構成図・運用手順書｜他社の担当者が読んで作業できるか

構成図とバッチ一覧、障害対応手順、定常作業の手順書です。判定基準は「存在するか」ではなく「作った会社以外の担当者が読んで作業できるか」です。社内の共有フォルダにあっても、前提知識がないと読めない資料は、引き継ぎ資産として機能しません。

毎月の作業報告が出ていない場合も、この資産が欠けている状態に含めます。何にどれだけ時間を使っているかの記録は、次の会社が体制を組むための手がかりになるからです。

③管理者権限｜渡っていないのは、要求されなかったからであることが多い

管理者権限をベンダーしか持っていない場合、他社は調査すらできません。調査できないものは見積もれません。権限の移管は、資料の整備に比べれば負担が小さいことが多い領域です。 それでも渡っていないことが多いのは、単に誰も要求してこなかったからです。ここは交渉というより依頼で動きます。

クラウドやドメイン、SSL証明書の契約名義も同じ扱いです。名義がベンダーだと、解約時に事業が止まるリスクが実費の議論とは別に発生します。

④ソースコード｜納品対象になっているか、最新版と一致するか

契約上の納品対象になっているか、手元にあるものが本番稼働版と一致するか、そしてビルドできるかの3点です。「納品を受けた記憶はあるが、その後の改修分が入っていない」という状態では、他社が引き継いでも動くものを作れません。

稼働後にこの状態を作り直すのは、発注前に条項を入れておくより手間がかかります。これから発注する案件でソースコードの納品条件をどう書くかは、ソースコードが納品されない見積もりのリスクで扱っています。本記事はすでに稼働しているシステムの側です。

⑤データ｜出口条件が契約に書かれているか

業務データの出力形式、提供期限、費用です。この項目だけは、稼働中に困らないため後回しになりがちで、必要になったときには交渉材料が何もありません。 公正取引委員会の実態調査報告書のヒアリング（第4-2(1)）には、公共施設予約システムの更新にあたって既存ベンダーからデータ移行費用として5,000万円を請求され、移行を断念して職員が1件ずつ手入力したという声が記録されています（人口5万人以上20万人未満の地方公共団体）。同じ機関は「将来的にデータ移行をすることが予想されるのであれば、既存ベンダーとの契約時にその旨を仕様書に書いておくべきだった」と述べています。これは特定の官公庁の1事例であり、民間の金額水準を示すものではありません。それでも、出口条件を契約時に書いておくかどうかで結果が変わるという点は共通します。

⑥権利｜ベンダー側に正当な権利がある領域

著作権の帰属と利用許諾の範囲です。ここは①〜⑤と性質が違い、ベンダー側に正当な権利がある領域です。後述するとおり、公正取引委員会も、権利の行使と認められる範囲内であれば直ちに独占禁止法上の問題となるわけではない、としています。だからこそ、稼働後に交渉するより、契約書の記載を確認して不足していれば次回更新時に書き足すという進め方になります。

6点の前提｜自社側に資料を読める人がいるか

引き継ぎ資産6点とは別に、判定の前提が1つあります。資料と権限が揃っても、読める人がいなければ判断は前に進みません。 「いまの発注側は何をしているか」の章で見るとおり、公正取引委員会の2022年調査では、情報システム関連業務の担当を置いている機関でも、そこに情報システムに詳しい職員も外部人材もいないという回答が52.5%ありました（有効回答956機関。専門部署を置く機関と兼務職員を充てる機関の合計が母数）。

ただしこれは、自社で全部を理解する必要があるという意味ではありません。必要なのは、資料が揃っているかを判定できる人が、社内か外部の第三者にいることです。中身を設計できる必要はなく、揃っているかを言える人がいれば足ります。

引き継ぎ資産6点のうち、①②④⑤⑥はベンダーとの合意が要ります。③は依頼だけで動くことが多く、読める人の確保は自社の意思決定だけで進められます。動かせるほうから着手するのが、費用も時間も最小になります。

政府調達データで見る「競争が成立しない」構造（2004年度データ・2006年報告）

ここから、ロックインが価格にどう効くのかを実データで確認します。

適用条件を先に書きます。 対象は国の府省等の情報システム調達であり、民間企業の保守契約ではありません。予算制度も契約制度も異なります。データは平成16年度（2004年度）、報告は平成18年（2006年）10月25日です。20年以上前のデータであり、現在の相場ではありません。読み取れるのは価格が決まる仕組みだけです。

なお、随意契約比率と落札比率の全体像は姉妹記事「システム保守費用の相場と妥当性」でも扱っています。本記事はその先にある仕様書を誰が書いていたかと競争性を拡大した実例に重心を置きます。

会計検査院が参議院からの要請（2005年6月8日受諾）を受けて実施した検査で、対象となったのは各府省等のコンピュータシステムの調達等に係る経費4,773億円（2004年度）です。このうち、支払金額300万円以上の契約2,873件から、各省庁の内部部局が締結している保守・運用契約492件・366億円を抜き出して競争性と経済性が調べられています。

この492件のうち、随意契約が件数で91.8%・金額で96.0%を占めていました（競争契約は件数8.1%・金額3.9%）。さらに、随意契約452件のうち個別業務・システムに係る94件を対象にみたとき、契約相手方がシステム導入時の調達契約の相手方と同一またはその関連会社となっていたものが85件（90.4%）ありました。この90.4%は492件全体でも452件全体でもなく、抽出された94件に対する割合です。

落札比率（契約金額÷予定価格）については、492件から単価契約・総合評価落札方式による競争契約等を除いた458件を対象に、随意契約97.4%（431件）に対し競争契約81.9%（27件）、競争契約の内訳では1者応札94.3%（17件）・複数応札60.9%（10件）という平均値が報告されています。ただし同報告は「システムの保守・運用業務の予定価格については、積算体系が確立している工事請負契約等と異なり、内容によってはその妥当性を十分に検証できない面がある。したがって、落札比率の高低だけをもって競争性を評価することはできないが」と限定を付したうえでこの数値を示しています。予定価格そのものの妥当性が検証しきれない以上、比率の差を「そのまま値下げ余地」と読むことはできません。この限定は落としてはいけない部分です。

読み取れるのは、より地味な事実です。保守・運用契約の9割超が、競争のない形で締結されていた。 そして抽出された94件では、導入したベンダーが保守も担っていた割合が9割でした。

随意契約の理由は「障害時に即応できるのは作った会社だけ」だった

なぜ競争にならなかったのか。理由は報告書に集計されています。随意契約452件のうち、法令上の適用理由が「契約の性質又は目的が競争を許さない」だったのは416件（92.0%）でした。その具体的な理由として挙げられていたのは、次のような内容です。

システムの障害発生時における迅速な対応はシステムを開発し内容を熟知している者以外には難しいため

この理由は、いま民間企業が既存ベンダーから受け取る説明とほとんど同じです。 そして、この説明は多くの場合に事実でもあります。作った側が最も速く直せるのは自然なことです。問題は理由が嘘だということではなく、この理由が成り立つかどうかを発注側が検証できないことにあります。

決定的な差は、仕様書を誰が書いたかにあった

同じ報告書は、保守・運用契約492件から168契約（競争契約は総合評価落札方式を除く30件、随意契約は原則として各省庁の支払金額上位5件ずつ計138件）を抽出し、仕様書の中身を調べています。

まず記載内容です。競争性を広げるうえで重要な要素として、〔1〕作業項目別作業量・障害発生状況等、〔2〕責任範囲、〔3〕システム構成の3項目が挙げられ、いずれの項目も記載率は随意契約より競争契約のほうが高いという結果でした。〔1〕〔2〕については、競争契約の中でも複数応札の案件のほうが1者応札より記載率が高くなっています。〔3〕は1者応札のほうが高いものの、報告書は「複数応札の中には、契約内容からみて必ずしもシステム構成を示す必要のないものも含まれているため」と説明を付けています。

そして、次が本記事で最も重要な数字です。

競争契約では6割超が自前で仕様書を書いているのに対し、随意契約では過半（50.7%）が開発事業者の協力を得て書いていました。 報告書自身がこの結果に付けている解釈が明快です。

随意契約では仕様書で〔1〕から〔3〕の項目が記載されている割合が低いが、仕様書に具体的な記載がなくても契約相手方が履行可能になっているのは、このようなことが背景となっていると考えられる

仕様書に何も書かなくても契約は回ります。回ってしまうから書かれず、書かれていないから他社は入れません。 これがロックインの機構です。誰かが情報を隠したわけではなく、書く必要がなくなった結果として書かれなくなった、という順序です。

民間企業の保守契約に置き換えると、こうなります。毎年の更新見積書が「システム保守費 一式」の1行で成立しているなら、それは自社が作業内容を仕様として定義していないという意味です。その状態で相見積もりを取っても、他社は同じ土俵に乗れません。

出典: 会計検査院「各府省等におけるコンピュータシステムに関する会計検査の結果について」（会計検査院法第30条の3の規定に基づく報告書、2006年10月）第2章2「保守・運用契約の競争性、経済性の状況」の(1)ア〜エおよび図表2-1〜2-6。対象は平成16年度（2004年度）

なお、政府がこの当時「レガシーシステム」をどう定義していたかも示唆的です。「汎用コンピュータやオフコン（…）を使用したシステム及びこれらに接続するためのシステム、又は平成6年以降随意契約が継続しているシステムのいずれかに該当するシステムで、年間10億円以上の経費を要する情報システム」——つまり、技術が古いことと同じ相手との契約が続いていることが、並列の要件として置かれていました（同検査結果の要約版注3。括弧内は中略）。

仕様書と発注単位を変えたら何が起きたか（2004〜2006年度の政府契約・2006年報告）

同じ報告書には、競争性を拡大した参考事例が5件挙げられています。いずれも値下げ交渉ではなく、発注側の準備作業から始まっている点が共通しています。

出典: 同報告書 第2章2(1)オ「競争性の拡大の検討」参考事例(a)〜(e)

金額の比較には注意が必要です。国立国会図書館・会計検査院・防衛施設庁の事例はいずれも契約期間が異なるため、金額を単純比較できません。 文部科学本省の事例にいたっては、報告書自身が「業務時間を長くしているため、予定価格は高くなっている」と明記しており、下がったのは落札比率だけです。

それでも、5件から取り出せる打ち手は次の4つです（4つすべてを5件が実施しているわけではなく、事例ごとに組み合わせが違います）。

1. 仕様書に作業量と責任範囲を書く（何をどれだけやるかが読めれば、他社が見積もれる）
2. 他社でも実施できる業務を別契約に切り出す（全部を一括にすると、一部の困難さが全体をロックする）
3. マニュアル・設計図書を、作った会社以外が読める形にする
4. 権利関係が他社の作業の障害にならないか、事前に確認する

報告書の言う「設計図書」「マニュアル」は、本記事の引き継ぎ資産でいえば①仕様書・設計書と②構成図・運用手順書にあたります。会計検査院の所見も同じ方向でまとめられています。「仕様書の記載内容をより具体化したり、業務内容を見直して競争可能な業務を別途契約にしたりなどして、随意契約から競争契約への移行を検討し、契約の競争性、透明性を向上させること」（前掲の要約版「検査の結果に対する所見」より）。

民間企業がそのまま真似できるのは、2番目です。 保守契約を「監視」「問い合わせ対応」「障害対応」「改修」に分けたとき、監視と問い合わせ対応は他社でも受けられることが少なくありません。全部を1社に一括で頼んでいる状態は、価格ではなく発注単位の問題です。

ただし、これらは自社の状態を確かめたあとの打ち手です。先に確認すべきは、自社の引き継ぎ資産6点がいまどうなっているかで、その判定は後段の「引き継ぎ可能性の判定表」で行います。

いまの発注側は何をしているか｜公正取引委員会の2022年調査

2004年度のデータだけでは現在の話ができません。より新しい調査として、公正取引委員会が2021年6月から実施し2022年2月に公表した実態調査を見ます。こちらも対象は官公庁（国の機関・地方公共団体）で、民間企業ではありません。

「情報システムの仕様の内容、発注方法等について、あらゆるベンダーが情報システム調達に参入することができるように、工夫・留意していること」を複数回答で聞いた結果です。

出典: 同報告書 図表8。有効回答数1,011、複数回答可

この表は、そのまま民間企業の自己点検票として使えます。 上位2項目（設計書等の情報提供を受ける／不必要な一括発注をしない）ですら半数に届いていません。データの権利を発注者帰属と定めているのは27.9%、機能（技術）の権利では11.6%です。

なおこれは「工夫・留意していること」を選ぶ設問なので、選ばれなかった項目が「実施していない」ことの証明にはなりません。それでも、ロックイン防止として意識されている項目が半数に届かないという事実は、この構造が特定の組織の怠慢ではないことを示しています。

体制の側の数字も併せて見ておきます。情報システム調達に関する組織・人員体制について、専門部署や特定部署内の専門の係・担当を設置しているのは680機関（67.3%）、兼務職員の配置が279機関（27.6%）、いずれもなしが52機関（5.1%）でした（有効回答数1,011、択一）。

そのうえで、この専門部署等を有する機関だけに絞って、その部署に「一般の行政職員のうち特に情報システムに関して深い知見を有する者」または「外部人材（CIO補佐官など）」が含まれているかを聞いたところ、いずれも含まれていないという回答が502機関（52.5%）でした（有効回答数956、①②は複数回答可）。この52.5%は専門部署等を持つ機関を母数とした割合であり、全回答機関に対する割合ではありません。

担当は置いているが、読める人はいない。専門部署を設けている機関も、兼務職員を充てている機関も、この点では同じ母集団に入っています。この形が、資料の不備が長年放置される最大の理由だと考えられます。

ベンダー側の言い分が正当と言える条件

ここまでの話は、既存ベンダーを疑うためのものではありません。既存ベンダーの主張が正当であるケースははっきり存在します。

公正取引委員会は、この線引きを明示しています。

既存ベンダーが、知的財産権を有する場合に、権利の行使と認められる範囲内で、既存システムの仕様の開示や接続、データの引継ぎ等を拒否することや、適正な対価を請求すること自体が、直ちに独占禁止法上の問題となるわけではない

出典: 同報告書 第4-2(2)

そのうえで、問題となるおそれがある場合として挙げられているのは、合理的な理由が無いにもかかわらず仕様の開示・接続・データ移行を拒否すること（「事実上拒否するのと同視し得る程度に高額なデータ移行のための費用を請求する場合を含む」）などにより、他のベンダーが入札に参加することや受注することができないようにさせる場合です。判断の分かれ目は、拒否や請求そのものではなく、合理的な理由と算定根拠があるかに置かれています。

実務に落とすと、次のようなケースでは既存ベンダーの説明は正当です。

逆に言えば、これらの説明が出てくること自体は問題ではありません。 確認すべきは、説明があるかどうかと、その説明に根拠資料が付いているかどうかです。

なお、公正取引委員会が聴取したベンダー側の意見には、次のようなものもありました。

政府のガイドライン等に基づき、ベンダーが代わる際の対応があらかじめ仕様書に盛り込まれている場合が多くなっている。したがって、当社の情報システムから他の情報システムへのデータ移行に際しても、あらかじめデータ抽出費用を応札価格に含めているため、当社が官公庁に対して当該費用を追加で請求することはない

契約時に書いてあれば、その費用は最初から見積もりに含まれます。 後から高額になるのは、書いていなかったからです。

確認が必要なケース｜4つの状態で切り分ける

「ロックインされているか、いないか」の二択で考えると、判断が止まります。引き継ぎ資産6点のそれぞれを、次の4状態へ割り振ってください。

この4状態は、姉妹記事「システム保守費用の相場と妥当性」で使っている費目の格付けと同じ枠組みです。金額の側と引き継ぎの側を、同じ物差しで並べられます。

重要なのは、「高リスク」が必ずしもベンダーの落ち度ではないことです。 設計書の更新が契約に含まれていなければ、更新されていないのは当然です。責任の所在を争うより、いくらでいつまでに整備できるかを見積もってもらうほうが早く進みます。

引き継ぎ可能性の判定表

引き継ぎ資産6点を、上の4状態で判定します。「持っている」ではなく「いま受け取れる」で判定してください。 ①だけは受領の可否ではなく、保守の仕様書を自社で書けるかどうかで判定します。

判定結果の読み方は次のとおりです。これは本記事独自の目安であり、公的調査に基づく基準ではありません。

この個数に応じて何をするかは、最後の「判断が固まったあとの選択肢」で示します。

「安いほうへ乗り換える」が失敗しやすい理由

判定の結果「説明済み」が4〜6で、他社への相見積もりへ進む場合の注意です。ロックインの解消を検討すると、他社の見積もりが現行より安く見えることがあります。ここで注意すべきは、乗り換え後の見積もりは、しばしば過小になっていることです。

新しいベンダーは、現行システムの中身を知りません。知らない状態で出す見積もりでは、次の費目が抜けやすくなります。

安い見積もりが安いのは、範囲が狭いからであることが少なくありません。 比較するなら、現行契約の対応範囲を書き出したうえで、同じ範囲で見積もってもらってください。範囲を揃えていない比較は、値下げ交渉の材料にも社内稟議の根拠にもなりません。

そして、この記事の結論としてもう一度書いておきます。検証の結果、既存ベンダーの継続が合理的という答えになることは十分にあります。 引き継げる状態さえ作れていれば、その判断は毎年やり直せます。

ベンダーへそのまま送れる確認質問8問

以下はコピーしてそのまま送れる文面です。値下げの要求は含めていません。質問1〜6が引き継ぎ資産6点にそのまま対応し、質問7〜8は補足（費用の内訳と、資料整備の見積もり）です。返ってきた回答は、そのまま前掲の判定表へ書き写せます。

〇〇株式会社
ご担当者様

いつも保守対応をいただきありがとうございます。
社内で保守体制の整理を進めており、現状を書面で確認させていただきたく、
下記についてご回答をお願いできますでしょうか。
契約内容の変更を前提とするものではなく、社内の資産管理と
事業継続計画の整備を目的としたものです。

1.【仕様書・設計書】保守作業の仕様書と、システムの設計書について、
   最終更新時点をお教えください。稼働後の改修のうち、資料へ反映済みの
   ものと未反映のものを区別してお示しいただけますか。

2.【構成図・運用手順書】システム構成図と運用手順書（バッチ一覧、
   障害対応手順、定常作業手順）の有無と、最終更新時点をお教えください。

3.【管理者権限】本番環境・クラウドサービス・ドメイン・SSL証明書の
   契約名義と、管理者権限の保有者をお教えください。
   弊社側で管理者アカウントを保有していない対象があれば、
   一覧でお示しください。

4.【ソースコード】ソースコードの納品対象と保管場所をお教えください。
   現在弊社が保有しているのはどの範囲でしょうか。
   最新の本番稼働版と一致していますか。

5.【データ】契約終了時のデータ出力の形式・提供期限・費用について、
   現行契約での定めをお教えください。
   定めがない場合は、その旨をご回答ください。

6.【権利】成果物の著作権の帰属と、弊社の利用許諾の範囲について、
   契約書のどの条項に定めがあるかをお教えください。
   第三者に改修を委託する場合の可否も併せてご教示ください。

7.【補足・費用の内訳】現在の保守費用の内訳を、監視・問い合わせ対応・
   障害対応・改修・実費の区分でお示しください。あわせて、実際に作業を
   担当されている体制と、下請・再委託の有無、その役割範囲をお教えください。

8.【補足・整備の見積もり】上記1〜2の資料に未整備・未更新のものがある
   場合、整備に必要な作業内容・期間・費用のお見積もりをいただけますでしょうか。

お手数をおかけしますが、〇月〇日までにご回答いただけますと幸いです。
よろしくお願いいたします。

回答をどう読むか

回答が返ってこないこと自体を問題視しないでください。 担当者が資料の所在を把握していないだけのこともあります。重要なのは、回答が返らなかった項目を「判断不能」として記録し、次回更新の議題に載せることです。

判断が固まったあとの選択肢

引き継ぎ資産の棚卸しが終わったら、次のいずれかへ進みます。

「説明済み」が6で、かつ改修の頻度が低い場合は、上の「比較して判断する」に加えて一部を自社で保守するという選択肢も成立します。監視や定常作業など切り出しやすい範囲から内製へ移し、外部委託の範囲を段階的に見直す形です。切り出す範囲の決め方は、まず監視・問い合わせ対応・障害対応・改修のうち、直近1年で自社の判断が必要だった作業がどれかを洗い出すところから始めます。

実際に保守会社を変える段になったら、必要な資料・権限・引き継ぎ条件を先にそろえる必要があります。手順はシステム保守会社は変更できる？必要な資料・権限・引き継ぎ条件にまとめてあります。本記事が「なぜ下がらないのか」、あちらが「どう変えるか」の担当です。

システム自体が古く、保守費の上乗せがどこから来ているかを分けたい場合はレガシーシステムの保守費用を、作り直すところまで視野に入る場合はレガシーシステム刷新の開発会社の選び方を参照してください。後者には「ベンダーロックインから脱却すべきか」の判断フローがあります。

手元の保守見積書について、引き継ぎ条件の記載を確認したい場合は、引き継ぎ可能性チェック（登録不要）が使えます。見積書のテキストはブラウザ内で識別情報をマスクしたうえで診断にかけられ、結果を見るまでメールアドレスの入力は不要です。診断結果は「高い／安い」ではなく、確認すべき項目とベンダーへの質問として返ります。

根拠資料と適用条件

本記事で使った資料と、その適用範囲です。数値ごとに性格が違うため、まとめて扱わないでください。

本記事では、公的機関が示した数値と、koromo編集部が整理した確認観点を区別して記載しています。前者は出典と年代を明示し、後者は「確認観点」として提示しています。

なお本記事は、法的な最終判断を提供するものではありません。契約解釈、著作権の帰属、独占禁止法上の評価については、それぞれの専門家にご確認ください。

よくある質問