レガシーシステムの刷新は、一部の大企業だけの話ではありません。

また、社内SEやPMO、インフラ担当にも関わるテーマです。

なぜなら、古い仕組みを使い続けるほど、
新しい技術や運用改善を進めにくくなるからです。

一方で、刷新は単なる入れ替えではありません。
業務を止めずに進める視点や、関係者を動かす調整力も必要です。

そこで本記事では、レガシー刷新の基本を整理しながら、PMOに求められる役割を解説します。

なお本記事は、経済産業省、IPA、Google Cloudなどの公開情報をもとに整理しています。
そのうえで、エーティーエスが運営する
テクパスにつながる視点も、実務寄りにまとめます。

PMO案件をテクパスで確認する

1. レガシーシステム刷新が今も課題な理由

レガシーシステムの問題は、
古い技術を使っていることだけではありません。

本質は、変更しにくいことです。
全体像が見えにくいことです。
そして、新しい仕組みを入れにくいことです。

経済産業省は2025年に、
レガシーシステムが最新のデジタル技術導入の足かせに
なっている現状を整理しました。
さらに、可視化、内製化、標準化対応、上流人材の育成と確保が重要だと示しています。
このため、このテーマは開発部門だけでなく、情報システム部門やPMOにも関係する論点です。

参考：経済産業省「レガシーシステム脱却に向けた『レガシーシステムモダン化委員会総括レポート』」

1-1. レガシーシステムとは何か

レガシーシステムとは、
古い言語や古い機器だけを指す言葉ではありません。

今も業務が回っていても、変更しづらい。
保守の負担が重い。
新しい要件に合わせにくい。
こうした状態なら、実務上はレガシー化していると考えた方が自然です。

たとえば、次のような状態です。

• 仕様書が古く、更新されていない。
• 例外処理が多く、全体像が見えない。
• ベンダー任せで社内に知見が少ない。
• 改修のたびに調査期間が長い。
• 新しいツールと連携しにくい。

このような状態では、新技術を入れたいと思っても、
前提整理だけで時間がかかります。
その結果、変化への対応が遅れやすくなります。

1-2. なぜ刷新が後回しになりやすいのか

刷新が進みにくい理由は、技術だけではありません。

業務を止められない。
影響範囲が広い。
関係者が多い。
責任の所在が曖昧になりやすい。
こうした事情が重なるからです。

また、現場では
「まず今のまま動かすこと」が優先されやすいです。
そのため、抜本的な見直しが後ろ倒しになります。

IPAも、産業分野ごとのレガシーシステムの現状や課題を把握する調査を実施しています。
つまり、この問題は個社だけでなく、広い産業課題として整理されているテーマです。

参考：IPA「レガシーシステムモダン化委員会」

1-3. 生成AI時代でも避けて通れない理由

最近は、生成AIを活用した開発効率化が注目されています。
ただし、既存システムの構造が複雑で、
業務ルールが整理されていない場合、AIを活かしきれないことがあります。

Google Cloudの2025年DORAは、AI支援の活用が進む一方で、
安定性や品質面の設計は引き続き重要だと示しています。
つまり、生成AIを使えばすべて解決するわけではありません。
むしろ、品質設計や運用設計をいっそう丁寧に考える必要があります。

参考：Google Cloud「2025年 DORA レポート: AI 支援によるソフトウェア開発の現状」

この点は、
キャリテ内の
コンテキストエンジニアリングとは？AIエージェント時代の設計力
や、
AIの「もっともらしい嘘」をどう見極めるか。ハルシネーションと理解負債に立ち向かうエンジニアの誠実な選択
ともつながります。

AIを使う前に、業務とシステムの前提を整理できているか。
ここが大きな分かれ目です。

2. システム刷新でPMOに求められる役割

ここで大事なのは、PMOを単なる進捗管理役として捉えないことです。

レガシー刷新のPMOには、工程表を更新する以上の役割が求められます。

具体的には、判断材料をそろえること。
関係者の決定を前に進めること。
移行と運用の準備を早めに整えることです。
つまり、進行管理だけでは足りません。

2-1. 判断材料をそろえる

まず必要なのは、関係者が同じ前提で話せる状態を作ることです。

たとえば、今の業務を支えている機能は何か。
どこに例外運用があるのか。
どの業務は残し、どの業務は見直すのか。
こうした論点を整理する必要があります。

この整理ができていないと、後から
「その条件が抜けていた」
「その運用は変えられない」という話が増えやすくなります。

経済産業省も、ユーザー企業にはシステムの可視化が必要だと示しています。
そのため、判断の土台を整えることはPMOの大きな役割です。

2-2. 決定の順番を整える

レガシー刷新では、
情報システム部門だけで意思決定できるとは限りません。

事業部門、現場利用者、経営層、外部ベンダーなど、関わる人が多くなりやすいです。
そのためPMOには、誰が何を決めるのか。
どの順番で決めるのか。
会議で何を持ち帰らずに決めるのか。
こうした流れを整える力が必要です。

つまり、PMOの役割は会議を開くことではなく、
意思決定を止めないことにあります。

2-3. 移行準備と運用引継ぎを前倒しで確認する

新しい仕組みを作る議論だけでは、刷新は成功しません。

データ移行をどう進めるのか。
切り替え時に業務を止めないか。
障害時の対応はどうするのか。
運用保守は誰が担うのか。
こうした論点も、早い段階で確認する必要があります。

最近は、開発体験の改善という文脈で、
開発のしんどさを解消！プラットフォームエンジニアリングとは
のようなテーマも注目されています。

ただし、土台となる移行準備や運用引継ぎが弱いままでは、
どんな新しい考え方を入れても現場で回りにくくなります。
そのため、刷新初期から本番後まで見据えた整理が必要です。

3. 刷新案件で失敗しやすい論点

レガシー刷新でよくある失敗は、技術選定だけで起こるわけではありません。
むしろ、判断や準備の不足で起きることが多いです。

3-1. 判断基準が曖昧なまま要望が増える

「まずは今のまま移す」という考え方自体は、必ずしも悪くありません。

ただし、何を残し、何を見直すのか。
この判断基準が曖昧なまま進むと、後から要望が増えやすくなります。

たとえば、部署ごとに例外運用を残したい。
過去の帳票も同じ形にしたい。
承認ルールも変えたくない。
こうした要望が積み上がると、結果として複雑さを引き継ぎます。

つまり、問題は現行踏襲そのものではなく、
どこまでを例外として認めるのかが決まっていないことです。

3-2. 決定者が曖昧で会議だけが増える

刷新案件では、
論点が難しいから進まないとは限りません。
誰が決めるのかが曖昧なまま、
会議だけが増えることも多いです。

たとえば、現場は変えたくない。
情報システム部門は標準化したい。
ベンダーはスケジュールを優先したい。
このように立場が分かれると、
論点が残り続けやすくなります。

その結果、会議は開かれるのに決定が進まない、
という状態になりやすいです。

3-3. 本番後の運用負荷を見積もれていない

新システムが動くことと、安定して回ることは別です。

監視、権限管理、問い合わせ対応、
障害時の切り分け、運用引継ぎまで考えてこそ、実務で使える仕組みになります。

しかし、刷新案件では開発や切り替え準備に意識が寄りやすく、
本番後の運用負荷が見落とされることがあります。

Google Cloudの2025年DORAでも、
AI活用が進む一方で、安定性への配慮が重要だと示されています。
作る速さだけを追うと、あとで運用負荷が増える。
この感覚は、レガシー刷新でも同じです。

参考：Google Cloud「2025年 DORA レポート: AI 支援によるソフトウェア開発の現状」

4. 経験ごとに活きる場面は異なる

レガシー刷新の案件では、
活きる経験が一つに決まるわけではありません。

社内SE、インフラ、運用保守、PMOでは、
それぞれ強みが出る工程が違います。
そのため、自分の経験がどこで役立つのかを切り分けて見ることが大切です。

4-1. 社内SE経験は業務整理の工程で活きる

社内SEの経験が活きやすいのは、
業務ルールや例外運用を整理する場面です。

現場では、正式な仕様書に載っていない運用が
そのまま業務を支えていることがあります。
たとえば、月末だけ処理が違う。
部署ごとに承認順が違う。
紙とシステムを併用している。
こうした実態です。

社内SEは、こうした例外を拾いながら、
残すべき運用と見直せる運用を分けやすい立場です。

社内SEの経験を活かせる案件を見たい方は、社内SEの案件一覧も確認してみてください。

4-2. インフラ・運用経験は切り替え後の安定稼働で活きる

インフラや運用保守の経験が活きやすいのは、
切り替え後の安定稼働を支える場面です。

刷新案件では、新しい仕組みを作る段階に意識が集まりやすいです。
しかし、実際に問題が出やすいのは、切り替え直後や運用開始後です。

たとえば、権限設定が整理されていない。
監視項目が不足している。
障害時の切り分け手順が曖昧。
問い合わせの受け皿が決まっていない。
こうした状態だと、本番稼働後に負荷が集中します。

そのため、運用経験がある人は、「動くかどうか」ではなく、
「回り続けるかどうか」を先回りして見やすいです。

クラウド移行や運用設計に近い案件を見たい方は、クラウドエンジニアの案件一覧も参考になります。

4-3. PMO経験は意思決定を前進させる工程で活きる

PMO経験が活きやすいのは、
論点を止めずに、意思決定へ運ぶ場面です。

刷新案件では、課題そのものが難しいというより、
決める順番が乱れることで進まなくなることがあります。

たとえば、仕様が固まる前にテスト観点が広がる。
役割分担が曖昧なまま会議だけ増える。
宿題は出るが、誰がいつまでに決めるかが残らない。
こうした停滞です。

PMO経験がある人は、
論点の順番を整え、
会議の目的を明確にし、
決めるべきことを残しやすいです。

PMOの案件を見たい方は、PMOの案件一覧を確認してみてください。

5. 刷新案件を見るときのポイント

刷新案件に興味があるなら、求人票では言葉の見方を少し変えることが大切です。

5-1. 求人票で見るべきキーワード

まず確認したいのは、次のような語です。

• PMO
• システム刷新
• 基幹システム
• クラウド移行
• モダナイゼーション
• 社内SE
• 情報システム部門

こうした語が入っていても、案件の中身はかなり違います。
そのため、言葉だけで判断しないことが大切です。

5-2. 役割範囲だけでなく成果物も確認する

確認したいのは、役割の名前だけではありません。
最終的に何を求められるのかです。

• 会議運営が中心なのか。
• 課題管理表の更新までなのか。
• 業務整理や要件整理まで含むのか。
• 移行計画やテスト推進も担うのか。
• 成果物として何を出すのか。

同じPMO表記でも、求められる成果物が違えば、積める経験も変わります。

そのため、役割名だけを見るのではなく、
どの工程で、何をアウトプットするのかまで確認することが重要です。

自分に合う職種から整理したい場合は、
テクパスの職種一覧から確認してみてください。

また、派遣ITエンジニアの働き方を整理したい方は、
IT派遣の市場動向2025｜経験を活かす職種と3つの戦略
や、
【2026年】派遣ITエンジニアの働き方はどう変わる？
もあわせて確認すると、
仕事の選び方を整理しやすくなります。

6. まとめ

レガシー刷新で見ておきたいのは、
技術の新しさだけではありません。

どの業務を残すのか。
誰が判断するのか。
切り替え後に回るのか。
この3点を整理できるかが重要です。

また、社内SE、インフラ、PMOの経験は、それぞれ違う形で活かせます。
そのため、自分の経験がどの工程に合うのかを見ながら案件を確認することが大切です。

刷新案件に関心がある方は、役割名だけで判断せず、担当工程や成果物にも注目しながら、
関連する案件情報を確認してみてください。