開発会社の乗り換え判断フロー、承継後いつ・どの手順で切り替えるか

先代の代から付き合いのある開発会社やSaaSベンダーを、承継のタイミングで見直すべきかどうか。結論から言うと、承継直後に慌てて切り替える必要はない。まず「契約書の現物確認」と「システム管理台帳の作成」を承継後3〜6ヶ月以内に済ませ、更新月・EOL(サポート終了)・古参社員の稼働状況という3つの節目が重なるタイミングを狙って判断するのが、角を立てずに進められる唯一の現実的な手順である。

こんな状態の経営者に向けて書いている。先代が亡くなって、あるいは引退して半年から1年が経った。会社のシステムを長年見てくれている開発会社の担当者は先代の代からの付き合いで、自分より現場に詳しい。契約書がどこにあるかも正確には把握していない。見積もりが高い気はするが、他に頼める会社もわからないし、切り替えた瞬間に業務が止まるのが一番怖い。そして何より、株式や登記の引き継ぎには税理士や司法書士という「相談できる専門家」がいたのに、システムやITベンダーとの関係については、相談する相手がどこにもいない。この記事は、その孤独な判断を進めるための手順を、時系列で整理したものだ。

なぜ承継直後に切り替えを急いではいけないのか

承継したばかりの社長が最初にやってしまいがちな失敗は、「先代のやり方を全部変える」という意気込みでベンダーとの契約を一気に見直そうとすることだ。気持ちは理解できる。しかし業務システムは、会計・受発注・勤怠・顧客管理などが互いに連携している場合が多く、切り替えの影響範囲を把握しないまま動くと、決算期をまたいで数字が合わなくなったり、取引先への請求が止まったりするリスクがある。

承継直後の3〜6ヶ月は、経営者としての意思決定権を社内外に認知させる期間でもある。この期間にベンダー切り替えのような不可逆的な決断をすると、古参社員から「先代の時代を否定している」と受け取られかねない。まずは現状を正確に把握することに専念し、判断は次の節目まで待つ。これが遠回りに見えて最短の道になる。ベンダーへの最初の挨拶を承継前に済ませておくべきか、社内把握を終えてからにすべきかという順番については、外部ベンダーに先に挨拶するか、社内の把握を終えてからにするかも参考になる。

承継後にまずやるべきこと・契約書の現物を出させる

最初の一手は、開発会社やSaaSベンダーとの契約書一式を手元に集めることだ。多くの承継先で、契約書は先代の机の引き出しや、経理担当者のファイルの中に眠っている。担当のベンダーに連絡し、「代表が変わったので契約内容を確認したい」と伝えれば、ほとんどの会社は協力してくれる。ここで確認すべき項目は次の通りだ。

• 契約期間と自動更新の有無、更新月
• 解約通知の期限(何ヶ月前までに通知が必要か)
• 保守・運用の範囲(何を対応してくれて、何は別途見積もりになるのか)
• データやソースコードの所有権、契約終了時の引き渡し条件
• 料金の内訳(初期費用は償却済みか、月額に何が含まれているか)

IPA(情報処理推進機構)が公開している「情報システム・モデル取引・契約書」は、ユーザー企業とITベンダーの間で契約構造を透明化する目的で作られたモデル契約書で、受託開発・保守運用・パッケージ利用それぞれの版が用意されている。自社の契約書がこの標準的な構成とどれだけ違うかを見るだけでも、契約の異常な点(極端に自社に不利な条項、解約条件の不備など)に気づきやすくなる。

契約書を読んでもわからない場合は、「わからないところがあるので教えてほしい」とベンダーに直接聞いてしまって構わない。この段階では敵対する必要はなく、あくまで現状把握が目的である。

システム管理台帳を作る・これが承継後の最重要タスク

契約書の確認と並行して進めるべきなのが、システム管理台帳の作成だ。これは会社が使っているシステム・ソフトウェア・SaaSを一覧化し、それぞれの契約先・利用者・年間コスト・更新月・EOL予定をまとめた台帳である。先代が個人的な信頼関係で契約してきたシステムほど、こうした台帳が存在しないことが多い。

台帳に含めるべき最低限の項目は以下の通りだ。

この台帳ができた時点で、初めて「どのシステムがいつ判断のタイミングを迎えるか」が一覧で見える。承継後に何をどう見直すかを議論する土台は、この台帳がなければ作れない。逆に台帳さえあれば、次に何をすべきかはほぼ自動的に決まる。

3つの節目・更新月・EOL・古参社員の退職予定

乗り換えを検討する「タイミング」は、感覚ではなく次の3つの節目のいずれかに合わせるのが原則だ。

1つ目は契約の更新月。 多くのシステム契約は年単位の自動更新になっている。更新のタイミングを逃すと、望まなくてもさらに1年契約が継続してしまう。台帳に記載した解約通知期限(多くは更新の1〜3ヶ月前)を必ずカレンダーに入れておく。

2つ目はEOL（サポート終了）、つまり使用中のソフトウェアやOSのサポート終了だ。 サポートが切れたシステムは、セキュリティパッチが提供されなくなり、脆弱性が放置されたまま稼働を続けることになる。ベンダーから「そろそろ次期システムへの移行を」と提案されるのは、多くの場合このEOLが近づいたタイミングであり、これは乗り換え検討の自然な契機になる。

3つ目は、現場でそのシステムを実際に操作している古参社員の退職予定だ。 先代の時代から同じベンダーの担当者とやり取りしてきた社員が退職すると、「このシステムの使い方がわかる人が社内にいない」という状態が一気に表面化する。この社員がまだ在籍しているうちに、システムの使い方・過去のカスタマイズ経緯・ベンダーとの取り決めを聞き出しておくことが、乗り換え判断の材料集めとして非常に重要になる。

この3つが重なるタイミング、たとえば「更新月の半年前に、使い慣れた社員がまだ在籍していて、かつEOLも近い」という状況こそが、乗り換え判断の最適なタイミングだ。逆に、どの節目とも関係のないタイミングで動くと、解約金や違約金、業務の混乱を余計に招くだけになる。

判断フロー・6ステップで進める

台帳が整い、節目が見えてきたら、以下の6ステップで判断を進める。

1. 現状把握(承継後0〜3ヶ月): 契約書の現物確認、システム管理台帳の作成
2. リスク評価(3〜6ヶ月): 各システムのEOL・更新月・稼働年数を台帳に反映し、優先度をつける
3. 一次判断(6ヶ月〜1年): 「継続」「保守だけ他社に切替」「全面リプレイス」の3択で、システムごとに仮の方針を立てる
4. ベンダーへの意思確認: 現行ベンダーに直接、今後のサポート方針・料金・移行協力の可否を確認する
5. 相見積もり: 乗り換えを検討する場合は、最低2〜3社から見積もりを取り、ベンダーロックインの度合いを比較材料にする
6. 移行実行: 決定した方針に沿って、契約更新・保守切替・リプレイスのいずれかを実行する

このフローの要点は、「継続」という選択肢を常に対等な候補として扱うことだ。乗り換え検討イコール解約ではない。台帳とリスク評価の結果、「今のベンダーのままで問題ない」という結論になることも十分にあり得る。むしろ多くのケースでは、契約条件の見直し(値下げ交渉、保守範囲の明確化)だけで十分な場合も多い。

システムごとに優先順位をつける・全部を同時に扱わない

台帳ができたら、次にやるべきは「どのシステムから手をつけるか」の優先順位づけだ。承継直後の経営者は、目に付いたシステムから手をつけてしまいがちだが、優先順位を誤ると、重要度の低いシステムの見直しに時間を取られ、本当に危険なシステムが放置される。

優先順位を判断する軸は、大きく2つある。1つは「リスクの大きさ」、もう1つは「業務への影響範囲」だ。リスクが高く、かつ影響範囲が広いシステム(たとえば基幹の受発注システムがEOLを迎えている、というケース)を最優先とし、リスクが低く影響範囲も狭いシステム(社内の一部だけが使う簡易な備品管理ツールなど)は後回しにする。

具体的には、台帳の各行に「リスク(高・中・低)」と「影響範囲(全社・一部門・個人)」の2列を追加し、リスクが高く影響範囲が広いものから並べ替えるだけでよい。この作業自体は難しくないが、承継直後にこれをやっている経営者は驚くほど少ない。多くの会社では、声の大きい部門長の要望や、ベンダーからの営業トークの順番でシステム見直しの優先順位が決まってしまっているのが実態だ。

優先順位づけは一度やれば終わりではない。半期ごとに台帳を見直し、リスク評価を更新する習慣をつけておくと、次の判断のタイミングを見逃さずに済む。

見積もりの取り方・比較する際に見落としがちな点

相見積もりを取る際、多くの経営者は「月額料金」や「初期費用」といった総額だけを比較してしまう。しかし、システムの乗り換えにおいては、金額以外に確認すべき項目がいくつもある。

• 移行作業の範囲: 見積もりに、現行システムからのデータ移行作業が含まれているか。含まれていない場合、別途どの程度の費用がかかるか
• 契約後の保守体制: 開発した担当者が退職した場合、社内に別の担当者が引き継げる体制があるか。属人化のリスクが今のベンダーと同じ構造にならないか
• カスタマイズの自由度: パッケージ製品やSaaSの場合、自社の業務フローに合わせたカスタマイズがどこまで可能か。標準機能で対応できない部分は追加費用がどの程度発生するか
• サポート窓口の体制: 問い合わせから対応までの標準的なリードタイム、休日や夜間の対応可否
• 契約解除条件: 次にまた乗り換えを検討する場合の解約条件、データの持ち出し条件が明記されているか

これらの項目を比較表にまとめ、単純な金額比較だけでなく、総合的なリスクを含めた判断をすることが望ましい。特に「移行作業の範囲」は見積もりの段階で曖昧にされやすく、契約後に「それは別料金です」と追加費用を請求されるトラブルの原因になりやすい。

契約前に確認すべき「解約のしやすさ」

乗り換え先を選ぶ際、多くの経営者は「今の課題を解決してくれるか」という観点だけで判断してしまう。しかし、次にまた乗り換えを検討する場面(自分の代の途中、あるいは次の代への承継時)を見据え、「この会社との契約は将来解約しやすいか」という視点も同時に持っておくべきだ。

具体的には、契約前に次のことを確認しておく。

1. 契約期間の縛り(最低利用期間)は何年か
2. 解約時に自社データをどの形式で受け取れるか(汎用的なCSVか、独自形式か)
3. 開発したカスタマイズ部分の著作権・利用権は自社に帰属するか、ベンダーに残るか
4. ソースコードの開示は契約に含まれているか、別途費用が必要か

これらは契約締結前の交渉で確定させておくべき項目であり、契約後に「やはり確認しておけばよかった」と気づいても、条件を覆すのは難しい。今回の乗り換えで先代時代の反省を活かすなら、この「解約のしやすさ」の事前確認こそが、次の代に同じ苦労をさせないための最大の備えになる。

全部乗り換えるか、一部だけ残すか・マルチベンダーという選択

長年の付き合いのあるベンダーとの関係を、全か無かで判断する必要はない。会計システムは今のベンダーのまま残し、老朽化した受発注システムだけを別会社に切り替える、という判断は一般的だ。これはマルチベンダーと呼ばれる考え方で、1社に依存するリスクを分散しながら、関係性を維持したい部分は維持できる。マルチベンダー体制のメリット・デメリットを整理して見直しどきを判断したい場合は、マルチベンダー体制のメリット・デメリット、承継後の見直しどきを参考にしてほしい。

先代の代からの付き合いを重視したい場合、この「一部だけ切り替える」という選択肢は、心理的なハードルを大きく下げてくれる。全面的な決別ではなく、「この領域だけは専門性の高い別の会社に任せたい」という説明であれば、既存の担当者にも角を立てずに伝えやすい。

一方で、マルチベンダー化には管理コストが増えるという裏返しのリスクもある。窓口が増える分、障害時の責任範囲があいまいになりやすい。台帳に「どのシステムをどの会社が担当しているか」を明記し、連携部分(データの受け渡しなど)がどう動いているかも合わせて記録しておくことが欠かせない。

既存ベンダーへの伝え方・関係を壊さずに進める

乗り換えを決めた場合でも、伝え方次第で関係を壊さずに済む。実務上有効なのは以下のような伝え方だ。

• 「先代の代から本当にお世話になっている。今回は経営体制が変わったタイミングで、社内のシステム全体を一度整理させてほしい」という前置きをする
• 解約の理由を「担当者や品質への不満」ではなく「事業構造・体制変更に伴う見直し」として説明する
• 移行期間中のデータ引き渡し・引き継ぎ作業への協力を、契約条件として明文化しておく
• 感謝を伝えるタイミングを作る(電話だけでなく、直接会って伝えるなど)

これは単なる社交辞令ではない。多くの中小企業向けシステムは、契約終了後もデータ移行やAPI連携解除などの作業でベンダー側の協力が必要になる。関係を壊した状態で解約すると、この協力が得られず、移行作業そのものが滞るリスクがある。円満な解約は、実務上のリスク管理でもある。

「継続」を選ぶ場合の交渉ポイント

台帳とリスク評価の結果、「今のベンダーを継続する」という判断に至った場合も、そのまま何もしないのではなく、更新のタイミングで契約条件を見直す交渉をするべきだ。具体的には次のような項目が交渉の対象になる。

• 保守費用の内訳を明確にしてもらう(何にいくらかかっているか)
• 対応時間・SLA(サービスレベル)を契約書に明記してもらう
• データのエクスポート形式・データ移行のしやすさの確保(将来また乗り換えを検討する余地を残す)
• 属人化している部分(特定の担当者しか対応できない状態)の解消を依頼する

特にデータを他システムへ移せる状態の確保は、継続を選ぶ場合でも必ず交渉しておきたい項目だ。今回は継続するとしても、将来また同じ判断をする場面が来る。その時に自社のデータを別のシステムに移せる状態を維持しておくことが、次の代への引き継ぎでも役に立つ。

リプレイスを選ぶ場合の切り替え手順

台帳とリスク評価の結果、システムの老朽化が進みすぎている、あるいはEOLが迫っていて、リプレイス(全面的な入れ替え)を選ぶ場合は、以下の順序で進める。

まず、現行システムからのデータ移行が技術的に可能かどうかを確認する。長年使ってきたシステムほど、データ形式が独自仕様になっていて、単純なCSV出力では移行できないケースがある。この確認を後回しにすると、リプレイス先の選定を終えた後に「データが移せない」という事態に陥る。

次に、業務を止めない移行スケジュールを組む。決算期・繁忙期をまたがない時期を選び、旧システムと新システムを一定期間並行稼働させる計画を立てる。特に受発注や請求に関わるシステムは、並行稼働期間を設けずに切り替えると、取引先への影響が避けられない。

最後に、現行ベンダーとの契約終了日と、新システムの稼働開始日の間にバッファ(空白期間を作らない)を確保する。この2つの日付を同じ日に設定すると、トラブルが起きた際に後戻りできなくなる。最低でも1〜2ヶ月の並行稼働期間を確保しておきたい。

レガシーシステムをどう判断するか

先代の時代に導入され、10年以上手を加えられていないような古いシステムは、乗り換え判断において特別な注意が必要になる。長期間動き続けているという事実は、それ自体が「今のところ業務は回っている」という実績でもあるため、経営者としては「動いているものを触りたくない」という判断に傾きやすい。

しかし、レガシーシステムには次のような固有のリスクがある。

• 開発した担当者やベンダー社内の担当者が退職・引退している可能性がある
• ソフトウェアやOSがEOLを迎えていて、セキュリティリスクが放置されている
• 仕様書やドキュメントが存在せず、改修の見積もりだけで高額になる
• 後継のベンダーが「ブラックボックス化していて手を出せない」と判断し、対応を断られる

台帳を作る過程で「稼働年数が長く、かつ担当者情報が不明」というシステムが見つかった場合は、他のシステムより優先度を上げてリスク評価すべきだ。動いているからといって安全とは限らない、という前提を持っておく必要がある。

オンプレミスで残すか、クラウドに移すか

老朽化したシステムを見直す際、多くのケースで論点になるのが、自社サーバーで運用するオンプレミス型を維持するか、クラウド(SaaS)型のサービスに移行するかという判断だ。オンプレミスは初期投資こそ大きいが、カスタマイズの自由度が高く、データを自社内に置ける安心感がある。一方でサーバーの保守・更新・セキュリティ対応を自社かベンダーが継続的に担う必要があり、担当者の退職や高齢化がそのままリスクになる。

クラウド型は、保守・セキュリティ対応がサービス提供元に委ねられる分、運用の手間は減るが、月額課金が継続的なコストになり、サービス提供元の方針変更(値上げ、サービス終了)に会社側の裁量が及ばないという弱点がある。どちらが正解ということはなく、台帳に記録した「稼働年数」「担当者の状況」「年間コスト」を並べて比較検討する材料にするのが実務的だ。

内製化するか、外部に任せ続けるか

システムの見直しを進める過程で、「自社でエンジニアを雇って内製化すべきか」という論点が出てくることもある。内製化するか外部に任せ続けるかの判断は、承継直後の段階では急いで決める必要はない。内製化には採用・育成のコストと時間がかかり、承継直後の経営リソースが限られている時期には現実的でないことが多い。

まずは外部のベンダーとの関係を整理し、台帳による見える化を済ませた上で、事業規模の拡大や特定領域への依存度の高さを見ながら、中長期的な課題として内製化の是非を検討するのが順序として自然だ。承継直後にすべてを一度に変えようとしないことが、繰り返しになるが最大のポイントである。

社内の合意形成・古参社員をどう巻き込むか

ベンダーとの関係整理は、社長一人の判断だけで進めると社内の反発を招きやすい。特に、長年そのシステムを使い続けてきた古参社員は、新しいシステムへの抵抗感を持つことが多い。「今のシステムで問題なく回っている」という現場の感覚と、経営者が台帳から読み取ったリスクとの間にギャップがあるためだ。

この抵抗感を無視して一方的に乗り換えを決めると、現場の協力が得られず、移行作業そのものが滞る。逆に、現場を説得しようと躍起になりすぎると、決断のタイミングを逃す。実務的な進め方としては、次の順序が有効だ。

• 台帳とリスク評価の結果を、感情的な理由ではなく「事実」として現場に共有する(EOLの日付、更新月、コストの内訳など)
• 現場が今のシステムに感じている不満や、逆に「これだけは変えてほしくない」という要望を先に聞く
• 乗り換え後の運用が現場の負担にならないよう、移行期間中のサポート体制を事前に約束する
• 決定権は経営者が持つことを明確にしつつ、現場の意見を反映した形で最終判断を伝える

先代の代からシステムに詳しい社員がいる場合、その社員を「乗り換え検討のプロジェクトメンバー」として正式に位置づけるのも有効な手だ。反対する立場から、判断に加わる立場に変えることで、抵抗が協力に転じることは少なくない。

承継直後に頼れる相談先はどこにあるか

株式や登記の承継には税理士・司法書士・弁護士という専門家が伴うが、システムやITベンダーとの関係整理について同じように専門的に相談できる相手は、身近にはなかなか見つからない。ここでは、実際に頼れる可能性がある相談先を整理しておく。

特に最後の「セカンドオピニオン的な相談」は見落とされがちだが有効な手段だ。今のベンダーに直接聞きにくい内容(このシステムは今の技術水準として妥当か、料金は適正かなど)を、契約関係のない第三者のIT企業に単発で評価してもらうことで、判断の材料を増やせる。乗り換えを前提にせず、あくまで現状評価を目的とした依頼であることを明確にしておくと、話がスムーズに進みやすい。

よくある失敗パターン

承継後のベンダー見直しでよく見られる失敗には、共通したパターンがある。

• 契約書を確認する前に、感情的な理由(先代への反発、担当者への不満)で解約を決めてしまう
• 台帳を作らずに個別のシステムだけを見て判断し、連携している他のシステムへの影響を見落とす
• 更新月やEOLのタイミングを無視して動き、違約金や空白期間を発生させる
• 古参社員がまだ在籍しているうちに情報を聞き出さず、退職後に「使い方がわからない」状態になる
• 相見積もりを取らずに、最初に接触した1社だけで乗り換え先を決めてしまう

これらはいずれも、「まず現状を正確に把握する」という最初のステップを省略したことに起因する。焦らず台帳を作ることが、結果的に最短の道になる。

承継後1年間のタイムライン・時系列で整理する

ここまで述べてきた手順を、承継後1年間の時系列に沿って整理すると次のようになる。実際のスケジュールは会社ごとに前後するが、大まかな目安として使ってほしい。

このタイムラインで重要なのは、「判断を下す」タイミングと「判断を実行する」タイミングを分けて考えることだ。承継後6ヶ月〜1年の間に判断を下すとしても、実行(実際の契約切替や移行作業)は、その後に来る更新月やEOLのタイミングに合わせる。判断と実行を同時にやろうとすると、準備不足のまま動くことになり、失敗のリスクが高まる。

費用面の考え方・乗り換えコストをどう見るか

乗り換えを検討する際、経営者が最も気にするのはやはり費用だ。ここで注意したいのは、「今の契約を続けるコスト」と「乗り換えにかかる一時的なコスト」を同じ土俵で比較してしまうと、常に「今のままが安い」という結論になりやすいという点だ。

乗り換えには、初期費用・データ移行費用・並行稼働期間中の二重コスト・社員研修の時間コストなど、目に見えやすい一時的な負担が発生する。一方で、今の契約を続けるコストには、老朽化したシステムのメンテナンス費用の増加、EOL後のセキュリティリスク、属人化した担当者が退職した場合の対応コストなど、目に見えにくいが将来発生しうる負担が含まれている。

正確な比較をするには、単年度の費用だけでなく、今後3〜5年間のトータルコストを見積もることが望ましい。台帳に記録した「稼働年数」や「担当者の状況」を踏まえ、今のシステムをこのまま5年間使い続けた場合に発生しうる追加コスト(老朽化対応、EOL対応、属人化リスクの解消費用など)を保守的に見積もった上で、乗り換えコストと比較する。この視点を持たないと、「今は安く見えるが、将来的には高くつく」という選択をしてしまうことになる。

なお、システムのリプレイスやIT導入には、IT導入補助金など公的な補助制度が使える場合がある。制度の対象条件や申請時期は年度によって変わるため、検討段階になったら商工会議所や認定支援機関に最新の情報を確認するとよい。

まとめ・孤独な判断を仕組みに変える

株式や登記の引き継ぎには税理士や司法書士という専門家が付くが、システムやITベンダーとの関係については、相談できる相手がいないまま経営者一人で判断を迫られることが多い。この孤独な状況を変える方法は、感覚的な判断をやめて、契約書の確認・台帳の作成・3つの節目(更新月・EOL・古参社員の退職)というチェックリストに落とし込むことだ。

承継後すぐに動く必要はない。まず3〜6ヶ月以内に現状を可視化し、その後は台帳に記録された節目が来るたびに、継続・部分切替・全面リプレイスのいずれかを選ぶ。この繰り返しさえ仕組みにしてしまえば、次に社長が代わる時にも、同じ台帳がそのまま引き継ぎ資料として機能する。ベンダーとの関係整理は、一度きりの決断ではなく、経営を続ける限り繰り返される定期的な業務として捉えておきたい。

先代への配慮と経営判断の両立

最後に触れておきたいのは、先代への配慮と経営判断をどう両立させるかという点だ。先代が長年築いてきたベンダーとの関係を大きく変えることは、先代の判断そのものを否定しているように感じられ、後継者自身が心理的な抵抗を感じることも多い。とりわけ、先代がまだ会長や相談役として社内に残っている場合、この配慮はより繊細な問題になる。

ここで持っておきたい前提は、「関係を見直すこと」と「先代の判断を否定すること」は別物だという点だ。先代がそのベンダーと契約した当時は、その選択が最適だった可能性が高い。しかし、事業規模やIT環境は年々変化する。10年前に最適だった契約が、今も最適である保証はない。これは先代の判断が誤っていたということではなく、単に状況が変わったというだけの話だ。

先代がまだ社内にいる場合は、判断の前に一度、率直に相談してみるのも一つの方法だ。「今の契約内容を確認していて、更新のタイミングが近いので一度整理したい」という伝え方であれば、先代としても、自分の判断を否定されたと感じにくい。むしろ、長年付き合ってきたベンダーへの理解が深い先代からの助言が、判断の助けになることも少なくない。承継1年目の後半から次の段階の準備をどう並行して進めるかは、承継1年目の後半、Stage2の準備をいつから並行して始めていいかにまとめている。

一方で、最終的な決定権は後継者である自分にあるということも、同時にはっきりさせておく必要がある。相談はするが、判断は自分で下す。この線引きを曖昧にしたまま進めると、いつまでも「先代の意向を確認しないと動けない」状態が続き、経営者としての意思決定権が育たないままになってしまう。

FAQ

Q1. 承継してすぐに開発会社を変えるべきですか? 急いで変える必要はない。まず3〜6ヶ月かけて契約書の確認とシステム管理台帳の作成を行い、更新月・EOL・古参社員の退職予定という3つの節目が来るまで判断を待つのが基本の進め方だ。

Q2. 長年の付き合いのある会社を切る際、関係を壊さない伝え方はありますか? 理由を「担当者や品質への不満」ではなく「経営体制の変更に伴う社内システムの整理」として説明し、感謝を伝えた上で、データ移行など解約後の協力を契約条件に明文化しておくと、関係を壊さずに進めやすい。

Q3. 全部のシステムを一度に見直す必要がありますか? 必要はない。会計システムは残し、老朽化した受発注システムだけを切り替えるといった、システムごとの部分的な見直し(マルチベンダー化)も現実的な選択肢だ。

Q4. システム管理台帳は誰が作ればいいですか? 経理担当者や総務担当者と一緒に、経営者自身が主導して作るのが望ましい。先代の個人的な信頼関係で契約されてきたシステムほど、社内の他の誰も契約の全体像を把握していないことが多いためだ。