先代の代から年々上がっていく保守費の契約を見直すタイミング

先代の時代からの保守契約を、そのまま更新し続けている。毎年少しずつ保守費が上がっている気はするが、明細を見ても「一式」としか書かれておらず、何にいくら払っているのか分からない。担当者に聞いても「昔からこの金額で」と言われるだけで、誰も説明できない。

結論を先に言う。保守費の見直しは、今すぐ全部を解約するという話ではない。まず「何に対していくら払っているのか」を明文化させ、市場価格とのズレを確認し、そのズレが説明できないものだけを段階的に整理していく作業だ。関係を切ることが目的ではなく、関係を「見える状態」に戻すことが目的になる。

こんな状態に当てはまる社長に向けて書いている。

• 先代の頃から付き合いのある開発会社・SaaSベンダーへの保守費が、契約時の説明もなく年々上がっている
• 見積書や契約書を見ても「保守一式」「サポート費」としか書かれておらず、内訳が分からない
• 古参の従業員は「昔からこの会社にお願いしている」と言うが、なぜその金額なのかを誰も答えられない
• 先代の代からの付き合いなので、値下げや乗り換えの相談をすること自体に気が引ける
• 株式や登記のことなら税理士や司法書士に相談できるが、システムのことは誰に相談すればいいのか分からない

一つでも当てはまるなら、この記事はあなたの状況を扱っている。

なぜ保守費は「気づいたら」上がっているのか

多くの承継社長が口にするのは、「値上げの説明を受けた記憶がない」という感覚だ。契約更新の書面は毎年届いているはずなのに、金額の変化に気づくのは決算のときだけ、というケースが少なくない。

これは偶然ではなく、保守契約という仕組みそのものの性質による。保守契約は多くの場合、初年度に導入した価格が「基準」になり、その後は「前年並み」「物価スライド」「消費税増税分」といった名目で、個別の説明なしに更新されていく。一度契約したら、次に金額を精査するタイミングは自分から作らない限り訪れない。

先代がシステムを導入した当時は、担当者と直接話をして金額に納得していたかもしれない。しかし代替わりのタイミングで、その「納得の記憶」は引き継がれない。残るのは契約書と、毎年少しずつ増えていく請求書だけだ。

「親父の時代からずっとこの金額で、なぜこの値段なのか聞いたこともない。聞いたら失礼な気がして」

これは承継の現場でよく聞かれる感覚だが、失礼にあたるかどうかと、経営として金額を把握すべきかどうかは、まったく別の話だ。

まず知っておきたい保守費の「相場」という補助線

自社の保守費が高いのか、妥当なのかを判断するには、比較の軸が必要になる。よく使われる目安は、システムの開発費（導入費）に対する年間保守費の比率だ。

一般的には、年間保守費は開発費（導入費）の5〜30%程度が目安とされ、対象システムの規模や保守内容によって幅がある。この比率が20%を超えている場合は、内容を精査する価値があると言われる。

もちろんこの数字は業種・システム規模・保守範囲によって大きく変わるため、絶対の基準ではない。しかし「導入費が300万円のシステムに、年間150万円の保守費を払い続けている」という状態があれば、比率としては50%に達し、目安から大きく外れていることになる。まずは自社の契約でこの比率を一度計算してみることが、見直しの出発点になる。

• 導入費（開発費）を契約書・請求書から確認する
• 直近の年間保守費総額を確認する
• 保守費 ÷ 導入費 で比率を出す
• 20%を超えていれば、内容の精査を検討する

この作業自体は、システムに詳しくなくてもできる。必要なのは電卓と、過去の契約書を引っ張り出す手間だけだ。

「一式」という言葉が意味すること

保守費の見直しで最初に立ちはだかる壁は、見積書や契約書の記載が「保守一式」「サポート費」のように、内訳のない一行で済まされていることだ。

保守費用の内訳としては、一般的に障害対応・トラブルシューティング、問い合わせ・操作サポート、法改正・制度変更への対応、セキュリティ対応、サーバー・インフラ費用などが含まれる。これらが個別にいくらなのかが分かれば、自社にとって本当に必要な項目にだけ費用を払っているかを判断できる。逆に、これが「一式」としか書かれていない場合、その内訳を尋ねること自体が見直しの第一歩になる。

見積もりに対して工数の内訳と単価の根拠を開示してもらうことが有効であり、根拠を示せないベンダーであれば、他社との比較を検討する理由になる、という指摘もある。これは決して喧嘩を売る行為ではない。「今後も長くお付き合いしたいので、内容を正しく理解しておきたい」という説明で十分に伝わる依頼だ。

この表の右側にチェックが集中しているなら、それは今のベンダーが不誠実だという意味ではなく、「長年見直されていない契約」に共通して起きる自然な劣化だと捉えたほうがいい。

ベンダーロックインという状態は、多くの場合、悪意によって作られるのではなく、双方が特に何もしないまま何年も経過することで、なんとなく出来上がっていく。

承継社長が抱える「相談先の孤独」

株式の承継なら税理士がいる。登記の変更なら司法書士がいる。労務のことなら社労士がいる。しかし、システムや保守契約のことを相談できる専門家は、多くの中小企業に存在しない。

これは承継社長が共通して抱える孤独の一つだ。先代の時代に契約したベンダーが「専門家」の立ち位置を担ってきたため、そのベンダー自身の契約内容や価格の妥当性を、外部の目でチェックする仕組みがそもそも存在しない。いわば「顧問弁護士に自分自身を訴えられるか相談する」ような構造的な難しさがある。

だからこそ、保守費の見直しは、ベンダーを信頼していないから行うものではなく、経営として当然に行うべき定期チェックだと位置づける必要がある。決算書を毎年確認するのと同じ感覚で、システムの保守契約も年に一度は数字を確認する対象にする。

• 顧問税理士に決算の相談はできるが、保守契約の妥当性は範囲外
• 顧問弁護士がいても、契約書の「金額の妥当性」までは通常見てくれない
• 情報システム部門がない中小企業では、社内に判断できる人材がいない
• 結果として、先代の代からの「言われた金額をそのまま払う」が継続する

この構造を認識した上で、外部の第三者（別のベンダーへの相見積もり依頼など）を使って比較材料を得ることが、実質的な「相談先」を作る手段になる。

見直しのタイミングを判断する5つのサイン

保守費の見直しは、いつ着手すべきなのか。以下のいずれかに当てはまるなら、それは検討を始めるべきタイミングだ。

1. 値上げの通知に説明がない——「例年通り」「物価上昇のため」といった一文だけで、具体的な工数変化の説明がない
2. 担当者が変わった、または高齢化している——先代の頃からの担当者が退職・引退し、引き継ぎがされていない、あるいは属人化している
3. 同じベンダーとの契約が5年以上続いている——契約当初は適正だった価格が、市場相場と乖離したまま固定されている可能性が高い期間
4. システムの利用実態と契約内容が合っていない——事業内容が変わり、当初契約した機能の一部が使われていない
5. 他社の営業を受けて、初めて自社の保守費の高さに気づいた——比較対象を持ったことで、違和感が具体的な疑問に変わった

同じベンダーと5年以上契約を継続している場合、当初は適正だった費用が市場相場と乖離したまま固定されているケースがあり、他社に概算見積もりを依頼して現在の保守内容と比較することが有効だとされている。承継のタイミングそのものが、まさにこの「5年以上」を振り返るのに適した節目でもある。先代から引き継いだという事実自体が、見直しの正当な理由になる。

相見積もりは「裏切り」ではない

多くの承継社長が最も気にするのは、「今のベンダーに失礼にならないか」という点だ。特に先代の代からの付き合いがある場合、この心理的なハードルは高い。

しかし、相見積もりはビジネスにおける公正な取引の基本プロセスであり、事前通知・同一条件の提示・丁寧な断りの連絡といった基本マナーを徹底することが、中長期的に自社の信頼性を高めることにつながるとされている。つまり、正しい手順を踏めば、相見積もりを取ることそのものは失礼な行為ではない。

実務としては、次の順序が角を立てにくい。

1. 既存ベンダーに「契約内容を正確に把握したいので、内訳の詳細を教えてほしい」と伝える（この時点では他社比較を明言しない）
2. 開示された内訳を基に、同等条件で他社1〜2社から概算見積もりを取る
3. 差額が説明できる範囲か、説明できない範囲かを見極める
4. 説明できない差額がある場合のみ、既存ベンダーに「他社と比較検討したい」と正式に伝える

このプロセスの利点は、最初から「他社に切り替えるつもりです」という宣戦布告をせずに進められることだ。多くの場合、内訳を開示させる段階で、ベンダー側も「そろそろ見直しの時期かもしれない」と察して、自主的に条件を調整してくることもある。

「内訳を聞いただけで、次の更新から急に安くなった」という声も、保守費見直しの現場では珍しくない。

「乗り換える」ではなく「並走させる」という選択

保守費の見直しの結論は、必ずしも「今のベンダーを切る」ことである必要はない。実務上有効な選択肢の一つが、基幹システムは既存ベンダーに残しつつ、新しく必要になった領域（Webサイト、予約システム、在庫管理の一部など）を別のベンダーに依頼する、という並走の形だ。

これは一社に業務を集中させず複数のベンダーに役割を分担してもらう体制で、依存するリスクを下げながら、既存の関係を急に断ち切らずに済む現実的な移行方法になる。特に、先代の時代から続く基幹システムが古すぎて全面リプレイスにはリスクが大きい場合、まず新しい領域だけを別会社に任せて、比較対象と実績を作ってから本体の見直しを検討する、という段階的な進め方が現場では機能しやすい。

• 基幹（会計・在庫・生産管理など）は既存ベンダーを維持
• 新規領域（Web・予約・簡易な業務アプリなど）は別会社に依頼
• 両者の対応速度・費用感・説明の分かりやすさを比較する材料にする
• 比較の結果を踏まえて、数年かけて本体の契約も見直すかどうか判断する

一気に全部を切り替える必要はない。承継後の数年間は、無理に大きな決断をせず、小さな比較の積み重ねで判断材料を増やしていく方が、社内の混乱も少ない。

契約書で最低限確認すべき3つの条項

保守費の妥当性を判断する前に、そもそも契約書自体に何が書かれているかを確認する必要がある。承継後に契約書を初めて通しで読んだ、という社長は少なくない。

1. 解約条項と通知期間

解約したい場合、何ヶ月前に通知が必要かが定められているかを確認する。この期間を把握していないと、見直しを決めても即座には動けない。3ヶ月前通知、6ヶ月前通知など、ベンダーによって差がある。

2. データの引き渡し方法

契約を終了した場合、蓄積してきたデータ（顧客情報、取引履歴、在庫データなど）がどの形式で、どのタイミングで引き渡されるかが明記されているかを確認する。ここが曖昧だと、乗り換えたくても身動きが取れなくなる。データを他社のシステムでも使える形で持ち出せるかどうかという論点は、保守費そのものより重要になることも多い。

3. 保守の対象範囲とSLA（サービスレベル）

障害が起きたときに、何時間以内に対応するのか、対応時間外（夜間・休日）はどうなるのかが明記されているかを確認する。「都度対応」としか書かれていない契約は、実際に障害が起きたときのトラブルの火種になりやすい。

これら3点が契約書に明記されていない、あるいは条項自体が存在しない場合、見直しの優先順位は「費用の高さ」よりも「契約条件の不透明さ」の方が高いと考えるべきだ。

古いシステムほど「保守費が上がりやすい」構造的な理由

保守費が年々上がっていく背景には、ベンダー側の値上げ意図だけでなく、システム自体の老朽化という構造的な要因もある。

経済産業省が2018年に公表した「DXレポート」では、多くの企業のIT予算の約8割が既存システムの維持管理費に割かれており、システムの老朽化・複雑化・レガシーシステム化を放置した場合、2025年以降、最大で年間12兆円規模の経済損失が生じる可能性があると指摘されている。この構造は中小企業にとっても無関係ではない。長年にわたり個別のカスタマイズを繰り返してきたシステムほど、内部構造が複雑になり、保守を担当できる人材も限られてくるため、対応できる会社・担当者が固定化し、価格交渉力そのものが弱まっていく。

つまり、保守費が上がる背景には「このシステムを直せるのはもう自社しかいない」というベンダー側の構造的な優位性が存在している場合がある。これは意図的な便乗値上げというより、システムが古くなるにつれて自然に生まれる力関係の変化だ。

• システムが古くなるほど、対応できる技術者・会社が減る
• 対応できる会社が減るほど、価格交渉力はベンダー側に偏る
• 価格交渉力が偏った状態が、そのまま何年も固定される
• 気づいたときには、他に頼める会社が見当たらない状態になっている

この構造を理解しておくと、「なぜ今の会社にしか頼めないのか」という疑問への納得感が生まれる。同時に、この状態こそが最も早く手を打つべき対象でもある。放置すればするほど、選択肢は狭まっていく。

「システム管理台帳」がないと何も始まらない

保守費の見直しを進めようとして、多くの承継社長が最初にぶつかる壁は、「自社にどんなシステムがあり、それぞれどのベンダーと、どんな契約をしているか」という全体像そのものが分からない、という問題だ。

先代の時代から、会計システム、受発注システム、勤怠管理、Webサイト、メールサーバーなど、複数のシステムがそれぞれ別のタイミングで別のベンダーと契約されてきたケースは多い。これらが一覧化されていないと、保守費の見直しは個別の交渉ごとに終始し、全体としての優先順位がつけられない。

システム管理台帳を作ることは、保守費見直しの前提作業として最も地味だが、最も効果が大きい。具体的には、以下の項目を一覧表にまとめる。

この一覧を作るだけで、「どの契約から手をつけるべきか」の優先順位が自然と見えてくる。金額が大きいもの、更新月が近いもの、導入年が古いものから着手するのが基本の順序になる。

EOL（サポート終了）を先に確認する

保守費の話をする前に、必ず確認しておきたいのが、使用中のシステムやソフトウェアがEOL（サポート終了）を迎えていないか、あるいは近づいていないか、という点だ。

サポートが終了したシステムを使い続けている場合、保守費が高いかどうかを議論する前に、そもそもセキュリティリスクや動作保証の観点で継続利用が難しくなっている可能性がある。この場合、保守費の見直しは「値下げ交渉」ではなく「移行計画の策定」という、より大きな話に発展する。

• 使用中のOS・データベース・業務パッケージのサポート終了予定を確認する
• サポート終了が近い場合、保守費よりも移行タイミングの検討を優先する
• ベンダーに「このシステムはいつまで保守可能か」を直接尋ねる
• 回答が曖昧な場合、それ自体が乗り換え検討の材料になる

先代の時代に導入されたシステムほど、この確認が抜け落ちているケースが多い。保守費の見直しに着手する際は、必ずこのEOLの確認を最初のステップに含めてほしい。

古参社員との関係をどう扱うか

保守費の見直しにおいて、技術的な検討以上に難しいのが、社内の人間関係だ。先代の時代からベンダーの担当者と個人的な付き合いがある古参社員がいる場合、その社員にとって、ベンダーの見直しは「自分がこれまでやってきたことへの否定」のように感じられることがある。

このとき有効なのは、見直しの目的を「ベンダーを疑うこと」ではなく「会社を守るために契約内容を明文化すること」だと社内で位置づけることだ。誰が悪いという話にせず、「先代の時代から契約が更新され続けて、内容を誰も把握していない状態そのものが会社としてのリスクだ」という説明にすれば、古参社員も味方につけやすくなる。

• 古参社員を「情報提供者」として関わってもらう（経緯を知っているのはその人だけ）
• 「ベンダーを切る前提」ではなく「内容を確認する」という位置づけで依頼する
• 決定権は経営者が持つが、確認作業は古参社員と一緒に進める
• ベンダー側への連絡も、可能であればこれまでの担当者を通す

古参社員を蚊帳の外にして経営者だけで進めると、後から「勝手に決めた」という不満が生まれやすい。逆に、情報収集の段階から巻き込んでおくと、見直しの過程そのものが社内の合意形成として機能する。

見直しの結果、起こりうる3つのパターン

保守費の見直しを実際に進めた場合、結果は大きく3つのパターンに分かれる。

パターン1: 妥当だったと分かる

内訳を確認し、他社と比較した結果、今の保守費が実は市場相場に近い妥当な金額だったと分かることもある。この場合、見直しの成果は「安心して払い続けられる根拠を得たこと」になる。金額が変わらなくても、これは無駄な作業ではない。

パターン2: 交渉によって値下げできる

内訳の中に、実際には使っていない機能への保守費や、対応範囲が重複している項目が見つかり、交渉によって費用を圧縮できるケースもある。適切に見直すことで年間10〜30%のコスト削減が実現できるケースは珍しくないが、闇雲にコストカットすれば障害対応が遅れるリスクがある、という点には注意が必要だ。値下げそのものを目的化せず、内容に見合った金額にすることが目的であるべきだ。

パターン3: 段階的な乗り換えが必要と分かる

内訳の開示すら難しい、あるいはシステム自体がEOLを迎えていることが分かった場合、値下げ交渉ではなく、段階的な移行計画を立てる必要がある。この場合は焦って一気に切り替えるのではなく、前述の「並走」の形を取りながら、数年かけて移行するのが現実的だ。

いずれのパターンに進むにせよ、最初の一歩は同じだ。内訳を開示させ、比較材料を得ること。ここから逆算して、自社がどのパターンに当てはまるのかが見えてくる。

ITに詳しくなくても使える「質問リスト」

非IT出身の社長にとって、最大の障壁は「技術的な話をされたら反論できない」という不安だ。しかし、保守費の妥当性を判断するために、技術知識は必須ではない。必要なのは、次のような具体的な質問をぶつけ、答えの明確さそのものを評価する姿勢だ。

• 「今払っている保守費のうち、障害対応にいくら、法改正対応にいくら使われていますか」
• 「今年、実際に対応してもらった作業の回数と内容を教えてください」
• 「このシステムは、あと何年くらい保守を続けられますか。サポートが終了する予定はありますか」
• 「解約する場合、何ヶ月前に伝える必要がありますか。データはどんな形式で受け取れますか」
• 「同じ内容を他社に頼んだ場合との違いを説明してもらえますか」

これらの質問に対して、具体的な数字や期限で即答できるベンダーは、内部で契約内容を整理して管理している可能性が高い。逆に、「昔からこの金額で」「その都度対応しているので回数は数えていません」といった曖昧な返答が続く場合、それは技術力の問題ではなく、契約管理そのものが属人化し、更新されていないというサインだと受け取ってよい。

質問をぶつけたときの「反応の速さ」と「答えの具体性」こそが、技術知識がなくても使える、最も信頼できる判断材料になる。

半年で進める見直しの実行スケジュール例

保守費の見直しは、一度に全部を片付けようとすると挫折しやすい。実務上は、半年程度の期間を見て、段階的に進めるのが現実的だ。以下はその一例になる。

1〜2ヶ月目: 現状の可視化

自社が契約しているシステムとベンダーを一覧化し、それぞれの年間保守費・契約更新月・解約通知期間を確認する。契約書が見つからない場合は、まずベンダーに再発行を依頼する。この段階では交渉は行わず、事実の収集に専念する。

3ヶ月目: 内訳の開示依頼

金額の大きい契約、あるいは更新月が近い契約から優先して、既存ベンダーに内訳の開示を依頼する。「契約内容を正確に理解しておきたい」という説明で十分に伝わる。この時点ではまだ他社比較には触れない。

4ヶ月目: 概算見積もりの取得

開示された内訳を基に、同等条件で他社1〜2社から概算見積もりを取得する。値段だけでなく、対応スピードや説明の分かりやすさも比較材料として記録しておく。

5ヶ月目: 判断と交渉

比較の結果、妥当と判断できる契約はそのまま維持し、説明のつかない差額がある契約については、既存ベンダーに正式に相談する。値下げ交渉、範囲の見直し、あるいは段階的な移行のいずれかを選ぶ。

6ヶ月目: 契約更新への反映

交渉の結果を、次回の契約更新に反映させる。仮に大きな変更がなくても、この半年間で「内容を把握した上で更新している」という状態を作れたこと自体が、承継後の経営としての進歩になる。

この期間の長さに厳密な決まりはなく、契約更新のタイミングに合わせて前後させて構わない。重要なのは、思いついたときにまとめて動くのではなく、決算や契約更新のように、年に一度は必ず見直す「定例行事」として社内に組み込むことだ。

社外の第三者に同席してもらうという選択

ここまで紹介した手順は、経営者一人でも進められるように設計してあるが、実務上、社外の第三者に同席してもらうことで進めやすくなる場面もある。特に、ベンダーとの打ち合わせの場に、利害関係のない立場の人間が同席するだけで、内訳の開示や質問への回答が具体的になるという効果は現場でよく見られる。

この第三者は、必ずしも法律や技術の専門家である必要はない。顧問税理士やメインバンクの担当者、あるいは商工会議所の経営相談窓口など、普段から付き合いのある立場の人間に「同席してもらうだけ」でも、交渉の場の空気は変わる。もちろん、システムそのものの技術的な妥当性を判断するには、別の開発会社に相談し、現行システムの状態を客観的に評価してもらうという選択肢もある。

いずれにせよ、一人で抱え込まないことが重要だ。株式や登記の相談先があるのと同じように、システムの相談先を持つことは、承継後の経営を安定させるための備えの一つになる。

見直しを急ぎすぎて失敗する典型パターン

保守費の見直しには、逆に急ぎすぎることで失敗するパターンも存在する。承継直後の社長は「先代の代のやり方を早く変えたい」という気持ちが強く出やすく、それが判断を誤らせることがある。

失敗パターン1: 内訳を確認する前に解約を通告してしまう

現状の内容を把握する前に、勢いで「他社に切り替える」と伝えてしまうケースがある。この場合、データの引き渡し方法や移行にかかる期間を確認していないまま契約終了の期日が近づき、業務が止まりかねない状況に陥る。まず内訳と移行条件を確認してから動く、という順序を守る必要がある。

失敗パターン2: 価格だけで乗り換え先を決めてしまう

他社の見積もりが安いという理由だけで即決してしまい、実際に移行してから、対応の遅さや説明不足に悩まされるケースもある。価格差だけでなく、対応スピード・過去の実績・担当者の説明の分かりやすさを含めて比較する必要がある。

失敗パターン3: 社内の合意を取らずに独断で進める

古参社員や現場の担当者に相談せず、経営者だけで見直しを進めてしまうと、実際の運用段階で「使い方が変わって困る」という反発が後から出てくることがある。決定権は経営者にあるとしても、現場の意見を吸い上げるプロセスを省略しないことが望ましい。

失敗パターン4: 一度の見直しで満足し、その後放置する

苦労して見直しを行った後、「これで安心」と考えて再び数年間放置してしまうと、同じ問題が再発する。見直しは一度きりの作業ではなく、決算や契約更新のタイミングに合わせて定期的に繰り返す仕組みとして根付かせる必要がある。

これらの失敗は、いずれも「急ぎすぎ」か「一人で完結させようとする」ことに起因している。前章で紹介した半年程度のスケジュールと、社内・社外を巻き込む進め方を守ることが、これらの失敗を避ける最も確実な方法になる。

保守費以外にも広がる「見直しの視点」

保守費の見直しに着手すると、多くの場合、その過程で保守費以外の論点も見えてくる。代表的なのが、契約している複数のシステムが、実は機能的に重複している、というケースだ。

たとえば、会計システムに標準で搭載されている在庫管理機能と、別に契約している専用の在庫管理システムが、実は同じ用途でほぼ重複して使われている、という状況は珍しくない。先代の時代に別々のタイミングで導入されたシステムが、統合されずにそのまま両方の保守費を払い続けている、というパターンだ。

このような重複は、システムの一覧化（前述の管理台帳の作成）を行った時点で自然と見えてくる。保守費の見直しが、単なるコスト削減の話ではなく、会社全体のシステム構成を整理し直す機会にもなる、という点は、承継後の経営において意外と大きな意味を持つ。先代が積み上げてきた仕組みを否定するのではなく、今の事業規模と実態に合わせて棚卸しをする、という前向きな作業として捉えてほしい。

まとめ：見直しは「関係を切る」ためではなく「関係を続ける」ための作業

先代の代から続く保守契約を見直すことは、これまでの関係を否定する行為ではない。むしろ、内容を明文化し、双方が納得できる金額と条件に整えることは、その関係を今後も健全に続けていくための土台作りだ。

株式や登記のことなら専門家に相談できるのに、システムのことは誰にも相談できない、という孤独を抱えている承継社長は少なくない。しかし、保守費の見直しは、法律の専門知識がなくても、契約書を確認し、内訳を尋ね、他社の概算見積もりを取るという、地道な手順の積み重ねで進められる作業だ。

まずは自社の保守契約書を引っ張り出し、保守費 ÷ 導入費の比率を計算してみることから始めてほしい。それだけで、次に何をすべきかが見えてくる。

この記事の次に読みたい記事

• 先代の代からの開発会社に「うちでしか直せません」と言われたときに確認する契約書の項目
• 先代システムのソースコードの権利は誰にあるか、納品物から確認する方法
• データをエクスポートできるか、古参ベンダーからの乗り換え前に確認すべきこと