「2025年の崖」とは、経済産業省が2018年に発表した「DXレポート」の中で示した、日本企業が直面する深刻な危機シナリオを指します。このレポートでは、老朽化した既存ITシステムの問題を2025年までに解決できなければ、2025年以降に年間最大12兆円もの経済損失が生じる可能性があると警告しました。
この「12兆円」という数字は、危機感を喚起するための最悪ケースとして示されたものですが、放置すれば企業競争力の低下や巨額損失につながるリスクは決して絵空事ではありません。つまり2025年を境に、対応の遅れた企業はデジタル競争で大きく後れを取りかねない――それを"崖から落ちる"ことにたとえているのです。
では、具体的に何が問題なのでしょうか？背景にあるのは、多くの企業で使われ続けているレガシーシステム、すなわち古い基幹システムの存在です。こうしたシステムは事業部門ごとにバラバラに構築・カスタマイズされてきた歴史があり、その結果、全社でデータを活用できず複雑化・ブラックボックス化していることが少なくありません。経営者が「デジタル改革したい」と思っても、基幹システムに手を入れるには業務全体の見直しが必要となり、現場の抵抗も強く実行が難しいのが現状です。このような部門最適の積み重ねや業務改革への抵抗が根本原因となり、日本企業のDX推進が停滞してきました。
2025年という年が区切りとされたのにはいくつか理由があります。第一に、システムの老朽化が限界に近づいていることです。経産省レポートの試算によれば、2025年時点で稼働から21年以上経過した基幹システムを運用している企業が全体の6割に達するとされています。まさに2000年前後に導入されたシステムが更新されないまま残り、多くが技術的にも陳腐化しているのです。
また、これら古いシステムを支えてきたIT技術者の世代交代も迫っています。レガシー言語を扱えるエンジニアの多くは50代以上で、2025年前後に大量退職期を迎えると見込まれています。つまり「人」と「技術」の両面で2025年頃がタイムリミットになり得るというわけです。さらに、世界的なデジタル競争の激化も背景にあります。クラウドやAIなど新技術を活用してビジネスモデルを変革する企業が台頭する中、旧態依然としたシステムにしがみつけば国際競争力で大きく見劣りする危険があります。
「2025年の崖」の議論でしばしば登場するのが「COBOL」というプログラミング言語です。COBOLとは「Common Business Oriented Language(共通業務指向言語)」の略称で、1960年代から使われている極めて歴史の長い汎用プログラミング言語です。
主に企業の事務処理や金融機関の基幹業務のために設計され、大量のデータを正確に処理することに長けているのが特徴です。
実際、COBOLは銀行の勘定系システムや保険契約管理、政府・自治体の年金や税システム、大手製造業の在庫・生産管理など、社会の根幹を支える領域で長年使われ続けてきました。その信頼性は高く、止まってはいけないミッションクリティカルな処理を担ってきた実績があります。
世界に目を向けても、COBOLはいまだに広範囲で現役です。 IBMの報告によれば、オンラインバンキングシステムの4割以上はCOBOLを基盤としており、対面のクレジットカード決済の80%、ATM取引の95%がCOBOLで動くシステムによって処理されているとされています。 日本でも、多くのメガバンクや地方銀行の基幹系は依然COBOL製の巨大システムですし、自治体の住民情報システムなどもCOBOLで構築されたものが少なくありません。一説では世界中の金融取引の70%以上がCOBOL上で処理されているとも言われるほどで、COBOLは決してニッチな存在ではなく、縁の下の力持ち的に現代社会を支えているレガシー技術なのです。
ではなぜ、そのCOBOLが問題視されているのか？大きく分けて4つの理由があります。
COBOLエンジニアの人材不足は深刻です。COBOL全盛期に活躍した技術者は現在60歳前後となっており、若手世代でCOBOLを習得する人はほとんどいません。実際、日本のCOBOL技術者の平均年齢は50代後半とも言われ、平均57.8歳との調査結果もあります。40歳未満のCOBOLエンジニアは全体の15%にも満たないという報告もあり、年代構成のいびつさが顕著です。
古参のエンジニアが定年退職を迎えると、その知見を引き継ぐ若手が極めて少ないため、2025年以降毎年約3,000人規模でCOBOL技術者が減少するとも予測されています。要するに、システムは動いているが、それを直せる人がいないという事態が各所で起こりかねないのです。この人材問題は2025年の崖の根幹的課題であり、実際COBOLが履歴書で使える言語として挙がるのは50代以上のみいったデータも報告されています。レガシーシステムの維持・刷新に不可欠なベテランへの需要が高まる一方で、新陳代謝が進まない状況です。
COBOLで作られたレガシーシステムは、長年にわたる機能追加・改修の繰り返しで全体像が把握困難なブラックボックスになっていることが多々あります。もはや仕様書もなく誰も全容をわからない巨大プログラムになっているのです。例えば法改正や商品追加のたびに新たなプログラムを付け足し、古い処理を迂回するロジックを重ねるといったことを何十年も繰り返した結果、使われていない古いルーチンが大量に残存し、どこを削除してよいかすら判断できない状態になってしまいます。
このブラックボックス化が進むと、システムを変更する際に影響範囲が読めず極めて慎重にならざるを得ないため、身動きが取れなくなります。現にある調査では、レガシー刷新の課題としてブラックボックス化が進み変更時の影響が読めないと感じている企業が42.7%もありました。システムがブラックボックス化していること自体はCOBOL言語そのものの問題ではありません。しかし、日本では特に開発をベンダーに丸投げし、内部にノウハウが蓄積しないまま運用してきたという事情もあり、結果として社内に知見がないままブラックボックスだけが残るケースが多かったのです。ブラックボックス化したシステムは下手に触れず聖域化しがちで、これがDXの大きな足かせになっています。
COBOLで作られた旧来システムは、最新のデジタル技術との親和性が低いという問題もあります。典型的には、大型汎用機上でバッチ処理中心に動くCOBOLシステムは、リアルタイムなデータ連携やオープンなAPI経由のサービス連携が苦手です。そのため、いざクラウドサービスやモバイルアプリ、IoT機器、AI分析プラットフォームなどと連携しようとしても、古い基幹系が壁になりうまく繋がらないことが起きます。
実際2020年代に入り生成AIやビッグデータ活用がビジネスの鍵となっていますが、既存のCOBOLシステムがデータ提供やリアルタイム処理の障害となって新技術導入を妨げるケースも報告されています。またCOBOL自体、近年主流のオブジェクト指向やウェブ開発の文脈とは馴染みが薄く、オープンソースの豊富なライブラリ資産も乏しいため、新しい機能追加のたびに一から開発する必要があるなど開発効率の面でもハンディがあります。その意味で、COBOLシステムはレガシーと呼ばれるゆえんである変化に弱いシステムそのものと言えます。
レガシーCOBOLシステムをこのまま使い続けることは経済的にも持続困難です。まずハード面では、旧式のメインフレームやレガシーソフトの保守費用は年々高騰する傾向があります。サポート切れのOSを延命する特別契約や、専用ハードの保守部品確保など、最新技術へ移行しない延命治療のコストは馬鹿になりません。またソフト開発面でも、希少化したCOBOL人材に依頼する保守作業は高額になりますし、内部が複雑な分ちょっとした改修にも手間と費用がかかります。
経産省DXレポートでは、既存システムの放置は技術的負債を膨らませると指摘されています。すなわち、今払っている保守費が将来にわたり積み重なり、新規IT投資に振り向ける資金・人材を奪ってしまうという警告です。刷新が遅れれば遅れるほど、さらに将来のDX実行コストが増えてしまうという負のループに陥ります。実際、IT予算の9割以上が保守運用に消えるといった極端な事例も報告されており、このままでは経営を圧迫し競争力強化への投資余力が無くなる恐れがあります。
以上の理由から、「2025年の崖」の文脈でCOBOLがクローズアップされるのはCOBOLという古い言語で作られたシステムを管理・刷新できていないことが問題の本質だからだと言えます。ここで重要なポイントは、COBOLそのものが悪いわけでは決してないということです。実際、COBOLで書かれたプログラムはこれまで何十年も給与計算や税計算などの事務処理を堅実に支えてきました。言語として古いぶん最近の便利な機能は無いかもしれませんが、だから使えないというものではなく、現に今も動いて社会のニーズを満たしているのです。
真の問題はむしろ、COBOLで書かれたコードが膨大すぎて誰も全容を把握できないことと、保守作業が非常に非効率なことであり、これはCOBOL言語固有の欠陥ではなく運用・管理上の問題だと指摘されています。極端な話、仮にこのまま何もしなければ、COBOLに限らずどんな技術でもいずれ老朽化し人材不足に陥るでしょう。COBOLはたまたま歴史が長いため今その局面にあるということです。したがって、COBOLだから悪い、捨ててしまえという短絡的な解決ではなく、どうやって現在のCOBOL資産を次世代に引き継ぎ、必要なら段階的に新技術へ移行していくかが重要なのです。
COBOL自体も実は改訂が続けられており、最新の国際規格はCOBOL 2023で、現代的なシステムとのインターフェース強化も図られています。問題なのは古い言語であることよりも古いシステムをそのままにしてきたことである――この点を誤解しないことが肝心です。
「2025年の崖」を克服し、本格的にDXを推進するには何をすべきでしょうか。ここではレガシーシステムのモダナイゼーション手法と、実行に際しての現実的な課題を解説します。
ポイントは、単にシステムを新しくするだけでなく、組織の体制や文化も変革することです。技術面と組織面、両輪の対策が必要になります。
レガシーシステムを近代化するアプローチはいくつかあります。代表的なものを3つ紹介しましょう。それぞれメリット・デメリットが異なり、自社の状況に応じた選択が重要です。
現行システムを白紙から新しいシステムへ作り直す方法。ハードウェアもソフトウェアも含め全体をゼロベースで刷新。
最新の技術で理想的な形を実現。個別最適化されたプロセスを統合し、新しいビジネスモデルに対応。クラウドネイティブで将来の拡張性を確保。
コストと時間が莫大。大規模プロジェクト化しやすく、互換性問題でスケジュール遅延や予算超過のリスク。劇薬的なコストとリスクを伴う。
十分な資金力とDXに対する強い覚悟がある企業向け。中小企業は段階的なアプローチが現実的。
アプリケーションの中身には手を加えず、動作させるハードや基盤プラットフォームだけを新しくする方法。リプラットフォームとも呼ばれる。
短期間かつ比較的低コストで実現。ハードウェア保守費の削減や処理性能向上。リプレイスより格段にリスクが小さい。利用部門への影響が少ない。
システムの中身は古いままで本質的な課題は残存。現代的な要件には適応しづらい場合も。根本的な体質改善には至らない可能性。
メインフレームの保守費圧縮など応急措置や第一歩として有効。リホスト後に段階的移行を検討する戦略も可能。
プログラム資産を活かしつつ、内部構造を整理・改善。プログラミング言語や基本機能はそのままに、コードの非効率や複雑さを取り除く。
業務への影響を抑えながら品質改善。コードが整理され、全体像が把握しやすくなる。ブラックボックス状態から脱却。ローリスク。
内部改善のみで最新のDX要件には応えられない。新機能追加や抜本的な性能向上は別途検討が必要。得られる効果は漸進的。
現状のCOBOL資産を継続利用したいが保守性に課題がある場合。リプレイス前の準備段階としてコードをクリーンにする場合。
リプレイスは理想的だが高リスク・高コスト。リホストは短期的な効率化に有効。リファクタリングは段階的な改善に適する。企業の状況に応じて、これらの手法を組み合わせた段階的なアプローチが現実的な選択肢となる。
以上の3つが代表例ですが、実際のモダナイゼーションはこれらを組み合わせて段階的に進めることが多いでしょう。たとえば第一段階でリホストしてコスト削減と安定化を図り、第二段階でリファクタリングしてブラックボックスを解消、最終的に一部モジュールを新言語でリライトして段階的にマイクロサービス化するといった具合です。リライトという手法もよく言及されますが、これは現行プログラムのロジックを保ったまま言語だけ別言語に書き直すことで、広義にはリプレイスに近い位置づけです。
リライトすることで新しい開発者が参加しやすくなったり、システムが標準的なアーキテクチャになるメリットはありますが、一方で言語を変えても仕様を理解していなければ単に新しいブラックボックスが生まれるだけというリスクもあります。したがって、どの手法を取るにせよ自社の何を守り、何を変えるのかを明確にした上で、段階的・戦略的にアプローチを選択することが重要です。2025年の崖までに全部入れ替えなきゃと焦って巨額投資をしても、目的が曖昧では成果に結びつきません。後述するように、まず全社的な目標設定とロードマップ策定が肝心です。その上で適切な技術選択を行い、ステップバイステップで崖を下りることが現実的な処方箋となるでしょう。
対策を講じる上で、避けて通れない現実のハードルもあります。ここでは主な課題を3点挙げます。
基幹システムの刷新には多額の費用と長い工期が必要です。例えば大企業の勘定系を全面刷新するとなれば数百億円規模、数年がかりのプロジェクトになることも珍しくありません。中小企業でも基幹システム導入には何千万円から億単位の投資が必要なケースがあります。この投資対効果が見えにくいと、経営判断として着手に踏み切れないことがあります。またプロジェクトが長期化し、その間に経営環境が変わったらどうするのか、失敗したら大損害ではないかという不安も付きまといます。
実際、2025年の崖に関するアンケートでも自社には関係ないと回答した企業が約47.6%に上るという報告もあり、理由としてコストに見合わないなど消極的な声もあるようです。これに対しては、まず小さな範囲でいいので成功事例や効果を社内に示すことが有効でしょう。たとえば一部の業務プロセスをRPAで効率化し、数十万円のコスト削減になった、といったミニDXの成功例でも構いません。それを積み重ねDX投資はリターンを生むという社内共通認識を育てていくことが大切です。また外部の補助金・助成金を活用できる場合もあります。中小企業向けにはIT導入補助金などDX推進のための制度も整いつつあるので、資金面のハードルは専門家の助言を得ながら下げていくと良いでしょう。
前述のように、DXを実行しようにも担い手となる人材が足りない問題があります。レガシー刷新ではレガシー技術と新技術の両方を理解するリーダーが必要ですが、そのような人は社内にいない、という企業も多いでしょう。IPAの調査ではレガシーシステム刷新に長けたプロジェクトリーダーがいないと感じている企業が24.9%ありました。また現場のIT部門自体が日々の運用業務で手一杯で、他の案件に追われて要員を割けないとの声も最も多く挙がっています。このように人も時間も足りないのが実情です。
対応策としては、先述した人材戦略の見直しに加え、外部パートナー企業との協力が現実解となります。信頼できるITベンダーやコンサルティング会社と組み、彼らの知見を借りながら進めることで、自社人材の不足を補完できます。またクラウドサービスやローコード開発ツールの活用で、従来より少人数でシステムを構築・運用できる場合もあります。さらにユーザー企業同士の情報交換に参加し、DX成功例・失敗例のナレッジを取り入れることも有効でしょう。いずれにせよ、人材不足は一朝一夕に解消しない構造問題です。経営層が人への投資を中長期視点でコミットし、採用・育成・外部活用のあらゆる手段を総動員して対応せねばなりません。
システム刷新は単なる技術更新ではなく、多くの場合業務フローの変更を伴います。新しいシステムに合わせて従来のやり方を変える必要が出てくるため、現場から使い慣れた今の仕組みの方が良い、余計な混乱を招くのでは、という抵抗や不安が生じがちです。ある調査でもユーザーの既存システム操作へのこだわりを解消できないことがレガシー刷新の課題として28.3%の企業から挙げられています。人は誰でも変化に不安を感じるものです。特に長年使ってきたシステムで業務が染み付いている場合、新システムへの移行期には生産性が一時的に落ちる可能性もあり、現場から敬遠されることも理解できます。
この抵抗への対処策は、徹底したコミュニケーションとチェンジマネジメントです。まずなぜ刷新が必要なのかを現場の言葉で丁寧に説明し、危機感や目的を共有することが第一歩です。その上で、新システムの操作教育やサポート体制を手厚くし、移行期の不安を和らげます。たとえば何月までは旧システムも併用し徐々に慣れてもらう、移行後数週間は専門スタッフが常駐サポートする等の施策です。また、現場からの意見を適宜取り入れ使い勝手を改善する余地を残しておくのも有効でしょう。要は、現場無視のシステム刷新にならないよう、現場を巻き込んだ計画策定と合意形成を行うことが成功の鍵です。DX白書2023でも、DX停滞企業の課題として現場と経営の意識乖離が指摘されています。現場と経営が同じゴールに向かって協力できるよう、社内の風通しを良くし、変革をポジティブに捉える文化を醸成することが求められます。
最後に、モダナイゼーションとDX推進の客観的な進捗を測る指標について触れておきます。経済産業省はDX推進指標という自己診断ツールを公開しており、自社がDXのどの段階にいるかを評価できます。またデジタルガバナンス・コードに沿ったDX認定制度、DX銘柄の選定など、政府も企業のDX度合いを見える化する取り組みを進めています。自社の現状を把握し、社内に危機感と目標を共有する上で、こうした指標や認定制度を活用するのも一つの手です。例えばDX推進指標で当社はレベル1だった、業界平均レベル3に追いつくために何かを実施しよう、など、客観データを用いることで社内説明に説得力が増します。統計データや他社事例を積極的に参考にしながら、自社のDX課題を見極め、着実にひとつずつ克服していくことが、「2025年の崖」を乗り越える何よりの処方箋と言えるでしょう。
A. 以前よりは改善の兆しがありますが、十分とは言えません。以下に現状を整理します。
ポジティブな面から言えば、この数年で日本企業のDXへの意識と行動は確実に高まりました。たとえばIPAの調査では、DXに何らかの取り組みをしている企業が2021年度の55.8%から2023年度には73.7%に増加しています。またDXに取り組んで効果が出ていると感じている企業も2023年度時点で64.3%に上り、DXは絵空事ではなく成果を出し始めているという評価もあります。
さらに2025年の崖という問題自体も広く認知され、2024年には日経新聞や専門誌で特集が相次ぐなどメディアでも頻繁に取り上げられました。こうした世論喚起の効果もあって、多くの企業がDX投資を前倒しし、2025年までに何とか老朽システムの一部を刷新したケースも増えています。一部では最悪のシナリオを避けるべく奮闘した成果が見え始めたとの分析もあります。実際、IPA発表のDX白書2023では2025年の崖の克服とその先の競争力強化がテーマとされ、DX成功企業が着実に出てきていることが報告されています。
しかし課題が解消したわけではありません。2023年度の調査でも思うような効果が出ていないと感じる企業が約6割存在し、DXの成果を出せる企業と出せない企業の差が広がっている現状が指摘されています。また前述の通り、2023年度時点でも約4分の3の企業は何らかのレガシーシステムを抱えたままであり、レガシー脱却が完了したと胸を張れる企業はまだ一部です。特に中堅・中小企業では対応が間に合わなかった、人材・予算の制約で動けない組織も多く存在します。
DXへの取り組み状況は企業規模によってばらつきが大きく、大企業は前進、中小企業は停滞という二極化も見られます。さらに、人材不足の問題は2025年以降も続き、政府試算では2030年にはIT人材が最大79万人不足する恐れがあるとも警鐘が鳴らされています。
総括すると、崖の危機感に駆られてDXやシステム刷新に動いた企業が多かったのは事実で、その分状況は以前よりマシになったと言えます。ただし2025年になった今も、崖を越えきれていない企業は依然多く、問題は現在進行形です。専門家も2025年は終点ではなく、新たなスタート、引き続き持続的なDXを深化させることが重要と強調しています。したがって、改善傾向ではあるものの、もう安心とは言えず、2025年以降もDXの歩みを緩めないことが肝要です。
ポイント：改善傾向はあるが油断禁物。継続投資と人材確保、レガシー脱却の加速が必要。
A. 企業規模に関わらず、取り組む必要があります。ITの遅れは競争力を直接的に削ぎます。
確かに2025年の崖はメガバンクや大手企業の巨大システム問題のように語られがちですが、本質はITの遅れが競争力を削ぐという点にあります。中小企業であっても、もし社内のシステムやIT対応が旧態依然のままなら、いずれ経営に支障をきたす可能性が高いのです。
例えば、基幹システムそのものは持っていなくても、受発注や在庫管理を未だにエクセルで手作業、顧客データが紙台帳に分散しているといった状況だと、生産性でデジタル化した競合に太刀打ちできなくなります。また取引先が進めるDXに合わせられず、デジタルでのやり取りに非対応な会社と見なされ取引機会を失うリスクもあります。実際、あるアンケートでは約8割の企業が2025年の崖に何らかの懸念があると回答しており、その中には多くの中小企業も含まれています。うちはITにお金をかけられないから関係ないでは済まされない時代になっているのです。
もっとも、中小企業はリソースが限られる分、大企業とは異なるアプローチが必要です。幸い最近は、中小でも導入しやすいクラウドサービスやSaaS型の業務アプリが充実しています。大掛かりな自社開発をしなくても、例えばクラウド会計ソフトや在庫管理サービスを使えば安価に業務DXが実現できます。またFit To Standardという考え方も重要です。これは、市販の標準パッケージに業務を合わせることでカスタマイズを極力減らし、将来的なアップデートを容易にする発想です。
中小企業ほどIT部門の負担を減らすため、市販ソフトの標準機能を最大限活用して業務プロセスを合わせることが有効でしょう。さらに、国や自治体の支援策も活用してください。中小企業向けのデジタル化支援策は年々拡充しています。総じて、中小企業こそ限られた人材・資金を賢く使って小さく産んで大きく育てるDXを志向すべきです。たとえばまずは身近な業務の一部をデジタル化し、それにより得られた効果を原資に次の投資へ繋げる、といったサイクルです。
大企業ほど大掛かりなことはできなくとも、一歩ずつでもDXを進めることが将来の競争力に直結します。2025年の崖は規模問わず他人事ではない、と認識していただきたいと思います。
ポイント：中小企業こそSaaS活用・標準化・支援策の活用で、段階的にDXを前進させる。
A. 性急な言語切り替えには注意が必要です。重要なのは「言語」よりも、業務ロジックとシステム構造の正しい理解と再設計です。
確かにPythonやJavaは現代の主流言語で、若いエンジニアも多く、将来性があるように映ります。一方で、だからと言って既存システムを丸ごと新言語で書き直せば万事解決、というほど簡単ではありません。極論すれば、COBOLで書かれたブラックボックスを、中身を理解しないままJavaで書き直したら、今度はJavaで書かれたブラックボックスができるだけです。重要なのは言語そのものではなく、システムの構造や業務ロジックを把握し、適切に設計し直すことです。
COBOLを扱える人がいなくて困っている場合でも、まず現行システムの構造や仕様をドキュメント化し、理解できる状態にしてからでないと、新言語への移行はリスクが高いでしょう。実際、国内外で大規模なシステムの全面リライトが失敗した事例は少なくありません。膨大なコードを書き直すには時間も費用もかかり、その間に業務要件が変わったりバグが混入したりするリスクがあるからです。
いずれにせよ、COBOL＝悪ではありません。目的とROIを明確化し、「なぜその技術を選ぶのか」を説明できる形で計画しましょう。
ポイント：オールorナッシングではなく漸進移行が現実解。現行把握→段階移行→最適技術選定の順で。
A. 第一歩は現状を知ることです。以下のステップで着手しましょう。
漠然と危機感はあっても、具体的に自社のどこに問題があるのか把握できていないケースは多いものです。まずは社内のシステムや業務プロセスを棚卸ししてみましょう。基幹系だけでなく、部署ごとに使っているエクセルマクロやアクセスDB、手作業で行っている業務なども含め、レガシーな状態にあるものを洗い出します。その際、それぞれのシステムの稼働年数、担当者、コスト、問題点などをリスト化すると全体像が見えてきます。
それらの中からリスクや効果の大きいものに優先度をつけます。たとえば今年中にハード保守が切れるサーバがあればそれは最優先でしょうし、ミスが多く非効率な手作業プロセスがあればそこも改善効果が高そうです。こうして自社の課題ポイントを可視化・整理することが第一の一歩です。
並行して、社内でDX推進の機運を高めることも大切です。経営層や関係部門に対して、前述の現状リストとともにこのままではまずい、改善すればこれだけ効果があるといったストーリーを共有し、プロジェクトの旗振り役を誰が担うか決めます。中小企業なら社長自らがCDO的に陣頭指揮を執る覚悟も必要でしょう。組織横断のDX推進チームを作るのも有効です。
全部をいきなり刷新するのではなく、優先度の高いところから段階的に手を付けることが成功のコツです。例えばまず顧客管理をクラウド型CRMに移行してみる、工場のある一工程だけIoT化してみるといったパイロットプロジェクトを設定します。小規模でもDXの実践経験を積めば、社内の知見も深まり、次のステップへの自信につながります。
政府やIPAが提供する自己診断ツールを使ってみるのもおすすめです。自社のDX成熟度や弱点が客観的に分かり、何から着手すべきかのヒントになります。
一言で言えば、最初の一歩は現状把握と社内合意形成です。それさえできれば、では優先度1のこれから改善しよう、そのための予算とチームを作ろうと次の具体的アクションに進めます。逆にここを飛ばして闇雲にツール導入だけしても定着しないので注意が必要です。幸い情報発信や支援策も豊富になっています。他社の成功事例を調べたり、専門家に相談したりするのも良いでしょう。崖に直面しているのはあなただけではありません。社内外の知見を集め、できるところから一歩踏み出すことが、長い旅路の確実なスタートになります。焦らず着実に、一緒に乗り越えていきましょう。
ポイント：現状把握→合意形成→小さく実行→学習・展開、の循環を作る。
ここではマイグレーションサービスのプロジェクト実績が100件以上の信頼できる会社を厳選。その中で「レガシーシステムのオープン化」「AWSへの移行」「大規模システムの移行」という3つの目的別におすすめの会社を紹介します。
【選定基準】
「マイグレーションサービス」とGoogle検索し表示される10社のうち、公式HPでマイグレーションサービスの移行実績が100件以上の3社をピックアップしました。（2025年8月20日時点）
※1.2.参照元：FPTジャパンホールディングス公式HP（https://fptsoftware.jp/resource-center/connect/connect-legacy-modernization）2025年8月20日時点
※3.4.参照元：TIS公式HP（https://www.tis.jp/service_solution/aws/migration/）2025年8月20日時点
※5.参照元：日立製作所公式HP（https://www.hitachi-sis.co.jp/service/system/migration/index.html）