システムリプレイスとは？基幹システム刷新の進め方と判断のポイント

保守・サポートの終了や担当者の退職をきっかけに、システムリプレイス（今のシステムを新しいシステムに置き換えること）の検討を任されたものの、何から始めればよいか迷っていませんか。
業務の中心にあるシステムだけに失敗できない一方で、全部作り直すべきか、費用と期間がどれくらいかかるのかは見当がつきにくいものです。

社長への説明と開発会社への相談に向けて、この記事では次のことを解説します。

• システムリプレイスの意味と、必要になる3つのサイン
• 改修・SaaS（インターネット経由で使うサービス型のソフト）・一部の作り直しと比べる判断の軸
• 大変さと費用・期間の目安、5段階の進め方
• 起きやすい失敗、仕様が分からない場合の進め方、発注先の見方

EPICsは、業務システムやアプリの受託開発会社です。業務診断（今の業務と困りごとを調べ、進め方を決める工程）から始め、SaaSで足りるなら作らない選択肢も含めて中立に提案しています。
開発実績は250件以上です（出典：EPICs DX・業務システム開発支援／EPICs アプリ・システム受託開発サービス）。

システムリプレイスとは？今のシステムを新しいシステムに置き換えること

システムリプレイスとは、使っている業務システムを新しいシステムに置き換え、業務を新しいシステムで続けられるようにすることです。
実際の場面として多いのは、レガシーシステム（古い技術で作られ、直しにくくなったシステム）の置き換え。
経済産業省の「DXレポート」（2018年9月7日）は、既存システムの老朽化・複雑化・ブラックボックス化（中身が分からなくなること）と、保守運用の担い手の不在を挙げています。
これらがシステムトラブルやデータ滅失のリスクを高める、という指摘です（出典：経済産業省「DXレポート」）。

リプレイスと似た言葉の意味と関係は、次のとおりです。

言葉	意味	リプレイスとの関係
リプレイス リプレース	今のシステムを新しいシステムに置き換えること	同じ意味で、表記が違うだけ
更改	機器やシステムを新しくすること	ほぼ同じ意味で使われる
刷新	仕組みを新しくすること	業務の見直しも含めて新しくする意味で使われることが多い
移行	古いシステムから新しいシステムへ、データや業務を移す作業	リプレイスの中の工程の1つ
マイグレーション	今のシステムの仕組みを生かして、新しい環境へ移す方法	リプレイスの手段の1つ

置き換え方も1つではありません。
IPA（情報処理推進機構）の「システム再構築を成功に導くユーザガイド 第2版」（2018年）は、再構築の手法を4つに分けています。
今のシステムの設計をどこまで引き継ぐかによる分類で、ハードウェア更改・リホスト・リライト・リビルドの4つです（出典：IPA「システム再構築を成功に導くユーザガイド 第2版」）。

なかでも基幹システム（止まると事業が止まる、業務の中心にあるシステム）を置き換える場合は、止められない分だけ慎重な切り替えが必要です。
詳しくは、基幹システムとはをご覧ください。

システムリプレイスはいつ必要？見直しのきっかけになる3つのサイン

システムリプレイスに「何年ごと」という決まりはなく、保守の終了、直せる人の不在、業務とのずれという3つのサインで判断します。
「5年」と言われることがあるのは、国税庁がソフトウェアの耐用年数を、複写して販売するための原本・研究開発用以外は5年としているためです（出典：国税庁「No.5461 ソフトウエアの取得価額と耐用年数」）。
これは税務上の償却期間で、替える時期の決まりではありません。

サインは、次の3つです。

• 保守・サポートの終了が決まった
• 直せる人がいない
• 業務に合わず、直すたびに費用がかさむ

保守・サポートの終了が決まったら、期限から逆算して動く

開発元や製品の保守・サポートの終了が決まったら、終了日から逆算してリプレイスの計画を立て始めます。
終了後は不具合の修正やセキュリティの更新を受けられなくなり、トラブルが起きても直せなくなるためです。期限が迫ってから動くと、選択肢を比べる時間がなく、取れる方法も狭まってしまいます。
棚卸しから切り替えまでには数か月かかるので、早めの着手が欠かせません。期間の目安は、後述の「費用と期間は、画面の数と使う人数で変わる」で紹介します。

直せる人がいない状態は、止まる前に手を打つ

今のシステムを直せる人がいないなら、動いているうちにリプレイスを検討しましょう。
開発元の廃業や担当者の退職で、今のシステムやExcelのマクロ（作業を自動化する仕組み）・Accessを直せる人がいなくなった状態です。特定の人しか中身が分からない状態（属人化）も、同じ危うさを抱えています。
経済産業省の「DXレポート」も、保守運用の担い手不在によるシステムトラブルやデータ滅失のリスクを指摘しています（出典：経済産業省「DXレポート」）。
止まってからでは、仕様（システムが何をどう処理するかの決まり）を知る人がいないまま、急いで作り直すことになりかねません。その場合の進め方は、後述の「仕様が分からない、前の開発会社がいないときはどうする？」で説明します。

業務に合わない、直すたびに費用がかさむなら、作り直しと比べる

業務の変化や事業の拡大で今のシステムが合わなくなり、直すたびに費用と時間がかかるなら、改修を続けるか作り直すかを比べます。
「維持や改修の費用が重い」ことは、業務システムに限らず、作り直しを考えるきっかけになるものです。
たとえば当社が開発した学生服専用のフリマアプリ「unifle」は、スクラッチ（一から独自に作る方法）で作られていた既存のアプリを作り直した例。理由は維持費用や改修費用が高いことで、開発期間は約4か月でした（出典：開発事例「unifle」）。
比べ方は、次の章で紹介します。

全部作り直すべき？改修・SaaS・一部の作り直しと比べて決める

システムリプレイスは、全部作り直すだけではありません。
改修、SaaS・パッケージ（既製のソフトを購入して使うもの）への乗り換え、一部の作り直し、全面リプレイスの4つから選べます。選ぶ基準は、不満がどこまで広がっているかと、業務がどれだけ自社独自か。
向いている状況と注意点は、次のとおりです。

選択肢	向いている状況	注意点
改修	不満が一部の機能に限られ、土台の保守が続く	土台が古いままなので、保守終了の問題は残る
SaaS・パッケージ	業務が一般的で、ソフトに業務を合わせられる	自社独自の手順は合わない場合がある
一部の作り直し	独自の業務が一部に残る	ほかのシステムとの連携が要る
全面リプレイス	土台が限界で、業務も大きく見直す	費用・期間・リスクが最も大きい

全面リプレイスは、保守の終了や直せる人の不在で、今の仕組みの土台そのものが限界のときに選ぶ方法です。
IPAの「システム再構築を成功に導くユーザガイド 第2版」も、第2版でパッケージ製品を利用するケースを加えています（出典：IPA「システム再構築を成功に導くユーザガイド 第2版」紹介ページ）。

古いシステムを今の技術で作り替える手法（リホスト・リライトなど）の違いは、「モダナイゼーション」の記事で解説しています。

不満が一部の機能だけなら、改修で使い続けられる

困っているのが一部の機能や画面だけなら、改修で使い続けるほうが費用と期間を抑えられます。
ただし、土台（機器・OS（基本ソフト）・開発言語）の保守が続くことが前提です。改修を選ぶ前に、次の3点を確かめましょう。

• 土台の保守がいつまで続くか
• 直せる人がいるか
• 改修を重ねて、仕組みが複雑になっていないか

土台の保守が切れる場合や直せる人がいない場合は、改修では解決しません。
一方で、IPAのガイドが再構築の手法の1つに、ソフトはそのままで機器だけを替えるハードウェア更改を挙げているように、最小限の変更で済ませる選択肢もあります（出典：IPA「システム再構築を成功に導くユーザガイド 第2版」）。

業務が一般的なら、SaaSやパッケージに乗り換えられる

会計・勤怠・経費精算のように、多くの会社で手順が似ている業務は、作り直さずにSaaSやパッケージに乗り換えられます。
作るより費用を抑えやすく、機能の更新を提供元が行う場合が多いのが利点です。一方で、ソフトに業務を合わせる必要があり、自社独自の手順や、ほかのシステムとの連携が合わない場合もあります。
カスタマイズ（自社向けの作り込み）を重ねると、提供元の更新に合わせにくくなる点にも注意しましょう。

自社独自の業務が残るなら、その部分だけ作る方法もある

一般的な業務はSaaSやパッケージに任せ、自社独自の手順が残る業務だけを作り直す（または新しく作る）方法もあります。
たとえば、独自の手順がある受発注の業務は作り、会計は既製のソフトを使う、という分け方です。この場合は、システムの間でデータを受け渡す連携が必要になります。
連携をどう作るかと、データが食い違ったときにどちらのシステムのデータを正とするかは、先に決めておくことが大切です。

システムリプレイスは大変？難しさと費用・期間の目安

システムリプレイスの大変さ（難易度）は、システムの大きさより、今の仕様が分かっているかと、業務を止められる時間で決まります。取り上げるのは、次の3つです。

• 今の仕様が分かっているか
• 業務を止められる時間
• 費用と期間の目安

今の仕様が分からないほど、手戻りが増える

今のシステムが何をどう処理しているかが資料に残っていないほど、作り直したあとに「前はできた」が見つかり、手戻りが増えます。
IPAの「システム再構築を成功に導くユーザガイド 第2版」が紹介しているのは、今の仕様が不明確なまま開発を進めた事例です。
使っている機能の作り忘れ（実装漏れ）や、今どおりの処理結果にならない不一致が、試験（テスト）の工程で多発しました（出典：IPA「システム再構築を成功に導くユーザガイド 第2版」）。
対処法は、後述の「仕様が分からない、前の開発会社がいないときはどうする？」で紹介しています。

業務を止められる時間が短いほど、切り替えに手間がかかる

業務を止められる時間が短いほど、切り替えを段階に分けたり、新旧のシステムを並べて動かしたりする手間が増えます。
たとえば、毎日動く受注の業務や、月末に締める会計の業務は、止められる日時が限られるもの。そのため、止められる日時は計画の最初に決めておくことが大切です。
IPAの「非機能要求グレード」実践セミナーの資料（2017年）も、移行の計画で「システム停止可能日時」を決める項目を挙げています（出典：IPA「非機能要求グレード」実践セミナー説明資料）。

費用と期間は、画面の数と使う人数で変わる

リプレイスの費用と期間は、画面の数と使う人数でおおよそ決まります。当社がDX・業務システム向けに公開している目安は、次のとおりです。

規模	期間	費用
小規模なシステム （〜15画面・〜1,000人想定）	1ヶ月〜	80万円〜
中規模なシステム （31〜50画面・〜10,000人想定）	3ヶ月〜	200万円〜
大規模・基幹システム （50画面〜・10,000人〜）	4ヶ月〜	300万円〜

このほか、業務診断は30万円〜（本開発を依頼した場合は全額充当）、一部業務のパイロット開発（一部の業務で先に試すための開発）は50万円〜です（出典：EPICs DX・業務システム開発支援）。
いずれも「〜」の付いた下限の目安で、移すデータの量、ほかのシステムとの連携の数、仕様の分かりやすさによって変わります。

システムリプレイスの進め方は？何から始めて、どう切り替える？

システムリプレイスは、今のシステムと業務の棚卸しから始め、5段階で進めます。
棚卸し、目的と範囲の合意、要件の決定、切り替え方の決定、一部で試してから広げる、の5つで、一度にすべてを切り替えないのがポイントです。段階ごとの役割分担を、次の表にまとめました。

段階	発注者がやること	開発会社に任せること
1. 棚卸し	業務と困りごとを洗い出す 資料を集める	今のシステムの中身を調べる
2. 目的と範囲	目的・予算・期限を決める 社長と合意する	選択肢と概算を示す
3. 要件	変える・変えないを決める 決めた内容を承認する	要件を整理し、仕様にまとめる
4. 切り替え方	止められる日時を決める 現場に知らせる	移行方式（切り替え方）とデータ移行（古いデータを新しいシステムへ移すこと）の計画を立てる 移行リハーサル（データを移す練習）を行う
5. 試して広げる	一部の現場で使い、広げるかを決める 現場に説明する	改善する ほかの現場へ広げる

IPAの「デジタル変革に向けたITモダナイゼーション企画のポイント集」（2018年）は、再構築で陥りやすい7つの落とし穴を挙げています。
その1つ目が、「再構築だから」と企画・要件定義（新しいシステムに求めることを決める工程）を軽視することです（出典：IPA「デジタル変革に向けたITモダナイゼーション企画のポイント集」）。

まず、今のシステムと業務を棚卸しする

リプレイスで最初にやるのは、今のシステムが担っている業務と機能、使っている人、つながっているシステム、困りごとを書き出す棚卸しです。
IPAのポイント集は、現行システムの調査が「表面的」になることを落とし穴に挙げ、普段目にしない部分も含めて、業務とシステムの「全体像」を明らかにするよう求めています（出典：IPA「デジタル変革に向けたITモダナイゼーション企画のポイント集」）。
発注者がやるのは、マニュアル・画面の写し・帳票などの資料を集め、現場の困りごとを聞くこと。システムの中身の調査は、開発会社に頼めます。

目的と範囲を決め、社長と合意する

棚卸しの結果から、何のために替えるか（目的）、どこまで替えるか（範囲）、予算と期限を決め、社長と合意してから開発会社に依頼します。
社長に説明する項目は、次の5つです。

• 目的
• 範囲
• 費用と期間の目安
• 止めてよい日時
• 効果の測り方（処理時間など）

新しいシステムで業務を始めてよいかの判断基準（業務継続性の判断基準）を作り、経営層も交えて合意する。これもIPAのポイント集が求めていることです（出典：IPA「デジタル変革に向けたITモダナイゼーション企画のポイント集」）。
合意がないまま進むと、途中で範囲が広がりやすくなるため注意しましょう。

要件は「変える・変えない」を分けて決める

新しいシステムに求めること（要件）は、「今のまま変えない」「変える（直したい不便）」「作り直すと変わってしまう」の3つに分けて決めるのが基本です。
IPAのポイント集も、「今と同じ」という要件定義を落とし穴に挙げ、要件を「変えない」「変える」「再構築により変わってしまう」に分けて整理し、文書に残すよう求めています（出典：IPA「デジタル変革に向けたITモダナイゼーション企画のポイント集」）。
発注者がやるのは、どれを変えるかの判断と承認です。要件を文書にまとめる作業は、開発会社と一緒に進めます。

切り替え方は、一括・段階・並行・パイロットから選ぶ

新しいシステムへの切り替え方（移行方式）は、一括・段階・並行・パイロットの4つ。
止められる時間と、失敗したときの影響の大きさで選びます。各方式の特徴は、次のとおりです。

方式	やり方	向いている場合	注意点
一括	ある日にすべて切り替える	小規模で業務が単純	失敗すると全業務が止まる
段階	業務や拠点ごとに順に切り替える	業務の区切りがはっきりしている	新旧の間でデータの受け渡しが要る
並行	新旧を同時に動かし（並行稼働）、結果を比べてから切り替える	止められない基幹の業務	二重入力で現場の負担が増える
パイロット	一部の現場で先に使い、直してから広げる	現場の使い方が読めない	全体の切り替えまで時間がかかる

IPAの「非機能要求グレード」実践セミナーの資料も、移行方式として、一斉に展開するか段階的に展開するかを決める項目を挙げています（出典：IPA「非機能要求グレード」実践セミナー説明資料）。
どの方式でも、切り替えの前に移行リハーサルを行い、失敗したときに元へ戻す手順も決めておきましょう。

一部の業務で試してから広げ、現場に定着させる

全体を切り替える前に一部の現場や業務で新しいシステムを使い、使いにくさや抜けを直してから広げると、現場に定着しやすくなります。
業務部門を上流工程（計画や要件を決める段階）からプロジェクトのメンバーに加え、利用の実態を十分に確かめる。IPAのポイント集が求めているのも、この点です（出典：IPA「デジタル変革に向けたITモダナイゼーション企画のポイント集」）。
広げるときは、操作の説明会とマニュアルを用意し、現場の声を集める窓口も決めておきましょう。切り替えたあとも、業務の変化に合わせて改善を続けます。

リプレイスはなぜ失敗する？中小企業で起きやすい4つの失敗

システムリプレイスの失敗の多くは技術ではなく、範囲・役割分担・データ・現場の準備不足から起きます。中小企業で起きやすいのは、次の4つです。

• 今の機能をすべて移そうとして、費用と期間が膨らむ
• 開発会社に任せきりにして、業務に合わないものができる
• データ移行を後回しにして、切り替えの直前で止まる
• 現場に説明しないまま切り替えて、使われなくなる

今の機能をすべて移そうとして、費用と期間が膨らむ

「今と同じ機能で」とすべてを移そうとすると、使っていない機能まで作り直すことになり、費用と期間が膨らみます。
変えない（現行踏襲）ほうがかえってコストや時間がかかる場合がある、というのがIPAのポイント集の指摘です（出典：IPA「デジタル変革に向けたITモダナイゼーション企画のポイント集」）。
防ぐには、棚卸しの段階で使っている機能と使っていない機能を分け、新しいシステムに移さない機能を決めておきましょう。

開発会社に任せきりにして、業務に合わないものができる

要件の判断までベンダー（開発会社）に任せきりにすると、現場の実際の使い方が反映されず、業務に合わないシステムができあがります。
対策としてIPAのポイント集が挙げるのは、業務部門が上流工程からプロジェクトのメンバーとなるよう、経営層に要請することです（出典：IPA「デジタル変革に向けたITモダナイゼーション企画のポイント集」）。
防ぐには、発注者側に決める人（責任者）と、業務を知る現場の担当者を置くこと。情シス（社内の情報システム担当）がいなくても、業務を知る人が関われば進められます。

データ移行を後回しにして、切り替えの直前で止まる

データ移行を後回しにすると、形式の違いや入力の揺れが切り替えの直前に見つかり、予定どおりに切り替えられなくなります。入力の揺れとは、同じ取引先が別の名前で登録されているような状態です。
IPAのポイント集は、今のシステムが動いているからと品質保証を簡単に考えることを落とし穴に挙げ、品質保証の方針を上流工程で決めるよう求めています（出典：IPA「デジタル変革に向けたITモダナイゼーション企画のポイント集」）。
防ぐには、移すデータの範囲と期間を早めに決め、移行リハーサルで確かめておくことです。

現場に説明しないまま切り替えて、使われなくなる

現場に目的や操作を説明しないまま切り替えると、慣れた古いやり方（Excelや紙）に戻り、新しいシステムが使われなくなります。
入力されない項目がある、古い台帳との二重管理が続く、といった状態はその兆しです。
業務部門に上流工程から参加してもらうようIPAのポイント集が求めているのも、現場とのずれを防ぐためと考えられます（出典：IPA「デジタル変革に向けたITモダナイゼーション企画のポイント集」）。
防ぐには、切り替える理由を先に伝え、一部の現場で試してもらったうえで、説明会とマニュアルを用意しておきましょう。

仕様が分からない、前の開発会社がいないときはどうする？

仕様書がなく、前の開発会社や担当者がいない場合でも、リプレイスは進められます。手立ては、次の3つです。

• 前の開発会社に、引き渡しを頼む
• 使っている人への聞き取りと、今の画面などの調査で調べる
• 次の開発会社と、資料と権利の受け取りを契約で決めておく

前の開発会社には、ソースコード・データ・資料の引き渡しを頼む

前の開発会社と連絡が取れるなら、リプレイスに必要なものの引き渡しを依頼します。別の開発会社にリプレイスを頼むこと自体は可能です。
依頼するのは、ソースコード（プログラム本体）、データ、設計書などの資料、サーバーやドメインなどのアカウント情報。何を受け取れるかは前の開発会社との契約の取り決め次第なので、契約書で成果物の扱いと引き渡しの取り決めを確かめておきましょう。
IPAは、契約で仕様や検収（納品物の確認）の方法などを取り決めるための「情報システム・モデル取引・契約書（第二版）」を公開しています（出典：IPA「情報システム・モデル取引・契約書（第二版）」）。

資料がなければ、使っている人への聞き取りと今の画面から調べる

資料が残っていない場合は、使っている人への聞き取りと、今の画面・帳票・データの中身から、システムが何をしているかを調べます。
資料だけでは分からない場合は有識者へのヒアリングで補う、というのがIPAの「システム再構築を成功に導くユーザガイド 第2版」の考え方です（出典：IPA「システム再構築を成功に導くユーザガイド 第2版」）。
この調査は開発会社に頼めます。発注者がやるのは、聞き取りに応じる人と時間の確保です。調べた処理を要件にまとめる方法は、要件定義とはで解説しています。

次の開発会社とは、資料と権利の受け取りを契約で決めておく

次のリプレイスで同じ苦労をしないよう、資料と権利の受け取りは、新しい開発会社と契約の段階で決めておきます。
決めておくのは、設計書などの資料を作って渡すことと、ソースコードとデータの扱い・引き渡しです。こうしておけば、特定の会社やツールでしか直せない状態（ベンダーロックイン：特定の取引先から離れられない状態）を避けやすくなるでしょう。
契約の取り決めには、IPAの「情報システム・モデル取引・契約書（第二版）」も参考になります（出典：IPA「情報システム・モデル取引・契約書（第二版）」）。

リプレイスを頼む開発会社は、どう選ぶ？

リプレイスの発注先の選定では、価格よりも、進め方と契約の中身を比べます。
確かめたい5つの点と、その理由は次のとおりです。

確かめること	見る理由
今のシステムの調査から入るか	仕様が分からないと手戻りが増える
作らない選択肢も示すか	改修やSaaSで足りる場合がある
段階的に進め、途中で止められるか	一度に切り替える失敗を避ける
資料と権利を渡す契約か	次のリプレイスで困らない
保守まで続けられるか	切り替えたあとも改善が続く

リスクを一緒に洗い出してくれるかも、見ておきたい点です。IPAのポイント集も、リスクを共有するだけでなく、開発会社も入れて対応の方針を整理し、合意するよう求めています（出典：IPA「デジタル変革に向けたITモダナイゼーション企画のポイント集」）。

見積もりは、同じ範囲・同じ条件で複数社に出してもらうと比べやすくなります。
依頼内容をまとめた文書（RFP：提案依頼書）を作っておけば、各社に同じ条件を伝えられるでしょう。

業務システムのリプレイスならEPICs

EPICsは、業務システムのリプレイスを、現場の業務診断から開発・導入・保守まで1社で支援しています。
出発点は、現場の実態を確かめる業務診断。SaaSで足りる場合や一部の改修で済む場合は、作らない選択肢も含めて中立に提案し、診断だけのご依頼にも対応しています。

進め方は、現状把握・方針策定・パイロット・横展開・継続改善の段階に分け、パイロットの後に「拡げる・作り直す・止める」を判断できる形です。
開発手法は業務の領域ごとに使い分け、基幹に関わる重要な部分はスクラッチ開発で堅く作ります。

ドキュメントを整備し、コードとデータの所有権をお渡しして、移管しやすい状態を保つのも当社の方針。10年使う前提で保守しやすく作り、業務の変化や法改正に合わせた追加開発・改善も続けます。
費用の目安は、業務診断が30万円〜（本開発をご依頼の場合は全額充当）、大規模・基幹システムが4ヶ月〜・300万円〜。開発実績は250件以上です。

まずは困りごとと替えたい業務を整理し、どこから手を付けるかを専門家と一緒に決めることから始めてみてください。

出典：EPICs DX・業務システム開発支援／EPICs アプリ・システム受託開発サービス

なぜ、今と同じ機能のまま移すリプレイスは、費用がかさみやすいのですか？

使っていない機能まで作り直すことになるためです。「今と同じ」で移すと、今は使っていない機能や画面まで作り直す対象になり、その分の費用と期間がかかります。IPAの「デジタル変革に向けたITモダナイゼーション企画のポイント集」も、変えない（現行踏襲）ほうがかえってコストや時間がかかる場合がある、という立場です。費用を抑えるには、棚卸しで使っている機能と使っていない機能を分けたうえで、新しいシステムに求めることを「変えない」「変える」「作り直すと変わってしまう」の3つに分けて決めましょう。そうすれば、作り直す範囲を必要な分に絞れます。

リプレイスの最中も、今のシステムで業務を続けられますか？

はい、続けられます。新しいシステムに切り替えるまでは今のシステムで業務を続け、切り替え方の工夫で業務への影響を抑えるのが基本です。止められない業務では、新旧のシステムを同時に動かして結果を比べる並行、一部の現場から先に使うパイロット、業務や拠点ごとに順に切り替える段階、といった方式から選びます。ただし並行は、二重入力で現場の負担が増える点に注意が必要です。どの方式でも、業務を止められる日時を計画の最初に決め、データを移す練習（移行リハーサル）と、失敗したときに元へ戻す手順を用意しておきます。

今の開発会社とは別の会社に、リプレイスを頼めますか？

はい、頼めます。最初の一歩は、前の開発会社に、ソースコード（プログラム本体）、データ、設計書などの資料、サーバーやドメインなどのアカウント情報の引き渡しを依頼すること。何を受け取れるかは前の開発会社との契約の取り決めによって異なるため、契約書で成果物の扱いと引き渡しの取り決めを確かめておきましょう。資料が残っていない場合でも、今のシステムを使っている人への聞き取りと、今の画面・帳票・データの中身の調査から、システムが何をしているかを調べられます。この調査は、新しい開発会社に任せることも可能です。

社長の承認を得るには、何を説明すればよいですか？

目的・範囲・費用と期間の目安・止めてよい日時・効果の測り方の5つです。効果の測り方は、処理時間などで示すと伝わりやすくなります。あわせて、全部作り直す方法と、改修・SaaS（インターネット経由で使うサービス型のソフト）・一部の作り直しを比べた結果を添えると、社長も判断しやすいでしょう。IPAの「デジタル変革に向けたITモダナイゼーション企画のポイント集」は、新しいシステムで業務を始めてよいかの判断基準を作り、経営層も交えて合意するよう求めています。この基準を企画の段階で社長と合意しておくと、切り替えを決めるときの判断がぶれにくい点も利点です。