COBOLで動く基幹システムに長く関わってきたエンジニアほど、移行という言葉の手前でつまずく場面を知っています。ただ現場に入ると、いつ動くかより先に、何を材料に決めるかが定まっていない場面によく行き当たります。IPAの調査では、レガシーシステムを抱える企業が今も半数程度に上り¹、判断を担う責任者を置いていない企業も約半数です³。この記事では、移行と維持のどちらに進むにせよ必要になる、判断の材料をどう作るかを整理します。

1. まだ決まっていないという前提

移行より先に、方針が定まっていない

COBOLで動く基幹システムに関わってきたエンジニアほど、移行という言葉の手前でつまずく場面を知っています。移行に進むのか、維持を続けるのか、その方針そのものが現場では定まっていないことが多いためです。

IPAの調査では、レガシーシステムを抱える企業が今も半数程度に上ります¹。移行を語る記事の多くは「いつ動くか」を前提に書かれていますが、実際にはその手前で、入れ替えるかどうかの判断自体が止まっている現場が広がっています。

この前提を踏まえずに移行の話を進めると、現場の実感とずれた提案になります。最初に見ておきたいのは移行の手順ではなく、方針を決めるための材料がどこまで整理されているかという点です。

現場に長く関わってきたエンジニアであれば、この感覚に覚えがあるはずです。設計書を読み込むほど、書かれていない前提の多さに気づき、判断はいつも保留になっていきます。焦って結論を急ぐよりも、保留になっている理由を一つずつ言葉にしていくほうが、結果として近道になります。

決める人がいないまま検討が続く

方針を決めるには、材料だけでなく決める人も必要です。ところが意思決定を担う責任者を置いていない企業は、約半数に上ります³。

責任者が定まっていない状態では、現場からどれだけ材料を積み上げても、最終的な判断にはつながりません。エンジニア側にできるのは、判断そのものを代わりに下すことではなく、判断できる状態を整えることです。

材料と、決める人。この二つがそろって初めて、移行か維持かの検討が動き出します。案件に入るエンジニアに求められているのは、答えを急ぐことではなく、この二つが今どこまで整っているかを見極める視点です。

この視点は、技術的な知見だけでは身につきません。現場に長く関わってきた経験があるからこそ、何が材料として欠けているのかを具体的に指摘できます。積み上げてきた経験は、そのまま判断を助ける材料になります。

図の作成：Remogu編集部。整理したもので、統計データではありません

次の章では、材料がなぜ不足しやすいのか、引き継ぎの実務に即して見ていきます。

2. 材料が無い——ドキュメント中心の引き継ぎ

仕様書に残る情報と、実装の中にしか残らない情報は違う

要件定義や設計が、今もドキュメント中心のまま引き継がれている現場は珍しくありません²。仕様書や設計書には、機能の一覧や画面の構成は残っていても、なぜその仕様になったのかという経緯までは記録されていないことがよくあります。

長年運用されてきたCOBOLの基幹システムほど、この傾向は強くなります。担当者が入れ替わるたびに、仕様書には書かれていない判断がコードの中だけに残っていく構造ができあがるためです。仕様書に残る情報と、実装の中にしか残らない情報とでは、性質そのものが違います。

観点	仕様書に残りやすい	実装の中にしか残らない
機能や画面の一覧	残っている	ー
変更した理由や背景	残っていないことが多い	コードや運用記録に残る
例外処理の詳細	概要のみ	実装に依存する
判断の根拠	明文化されていない	担当者の記憶に依存する

出典：IPA「2024年度ソフトウェア動向調査 簡易分析レポート」（2025年4月）をもとに作成

材料が浅いまま判断を求められる場面が続く

この状態で移行や維持の検討に入ると、判断の材料そのものが浅いまま議論が進みます。仕様書だけを見て「移行できそうだ」と判断すると、実装に残っていた例外処理や過去の変更理由を見落とすことになりかねません。

材料を厚くする作業は、地味に見えても検討の質を左右します。ドキュメントと実装を突き合わせ、抜け落ちている経緯を言葉にしていく作業こそが、判断の土台を作ります。仕様書を並べるだけでは不十分で、実際に動いているコードや運用の記録と照らし合わせて、初めて判断に使える形に整います。

材料の厚みは、移行だけでなく維持を選ぶ判断にも関わります。どちらを選ぶにしても、実装の中に埋もれた経緯を掘り起こす作業を避けて通ることはできません。

ドキュメントを整えるだけの作業に見えて、実際には現行システムの動きを読み解く力が問われます。コードの中に残った条件分岐一つひとつに、過去の業務判断が刻まれているためです。これを丁寧に拾い上げられるかどうかが、材料の厚みを左右します。

次の章では、決める人が定まっていない現場に、材料を届ける側としてどう関わるかを見ていきます。

3. 決める人がいない

責任者が定まらないまま検討が漂う

意思決定を担う責任者を置いていない企業は、約半数に上ります³。COBOLの基幹システムに携わってきたエンジニアが移行の相談を受けても、最終的にゴーサインを出す人が定まっていない場面によく行き当たります。

責任者が不在のまま検討が続くと、提案は宙に浮きます。技術的な選択肢を示しても、社内のどこで判断されるのかが見えないまま、時間だけが過ぎていく構図です。

この状態を放置すると、検討そのものが止まったまま数年が過ぎることも珍しくありません。エンジニア側にできるのは、判断を急がせることではなく、判断に使える材料を継続的に届け続ける関わり方です。

急いで結論を迫るより、決める人が現れたときにすぐ使える形で材料をそろえておく。この姿勢のほうが、長期的には信頼につながります。待つことと、備えておくことは、まったく違う行動です。

決める人の不在が、契約の負担にもつながる

決める人が定まらない背景には、契約面の負担もあります。取引ごとに手間や工数がかかる点を課題として挙げる企業が目立ちます⁴。

都度の契約調整に手間がかかると、意思決定の場そのものを整える余力が後回しになりやすくなります。移行の検討が進まない理由は、技術力の不足ではなく、体制を整える工数を確保しづらいことにある場面もあります。

材料を届ける立場のエンジニアにとって、決める人が見えない状態は珍しくありません。だからこそ、判断が下しやすい形に材料を整理し、必要なタイミングで手渡せるようにしておくことが、案件で信頼を得る一歩になります。

次の章では、刷新の形が一様ではないことを、規模という切り口から見ていきます。

4. 刷新は一様ではない——規模と分かれ方

小規模なシステムと、組織ごとに独立していたシステムでは見る観点が違う

政府のクラウド活用の基本方針でも、刷新の検討は一様には扱われていません。刷新の項目として、小規模なシステムにおける刷新が置かれています⁷。

同じ方針の中には、組織ごとに独立していたシステムの刷新という項目も別に置かれています⁸。両者が並んで挙げられていること自体が、規模や成り立ちの違いによって刷新の扱いが変わることを示しています。

COBOLの基幹システムが小規模に切り出されている場合と、組織ごとに独立して運用されてきた場合とでは、判断の材料を集める範囲が変わります。前者は影響範囲を見極めやすい一方、後者は他システムとの依存関係を洗い出す作業が先に必要になります。

種類	主な特徴	材料集めで見る点
小規模なシステム	対象範囲が限られる	影響範囲を見極めやすい
組織ごとに独立していたシステム	他システムと個別に運用されてきた	依存関係の洗い出しが先になる

出典：デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」（2026年）をもとに作成

規模で分ければ、進め方も変わる

規模や成り立ちが違えば、材料を集める順番も変わります。小規模なシステムであれば、まず対象範囲を確定し、影響を受ける業務を洗い出すところから始められます。

一方、組織ごとに独立して運用されてきたシステムでは、依存関係を先に整理しないと、影響範囲そのものが確定できません。同じ「刷新」という言葉でも、最初に手を付ける作業は変わってきます。

案件に入るエンジニアがまず確かめておきたいのは、対象のシステムがどちらの性質に近いかという点です。ここを取り違えると、材料の集め方そのものが的外れになります。

現場によっては、両方の性質が混ざっているシステムもあります。その場合は、どの部分が独立していて、どの部分が影響を受けやすいのかを切り分けるところから始めます。分け方を間違えなければ、後工程の見通しは立てやすくなります。

次の章では、長く運用されてきたことで複雑になった現行システムそのものへの対策を見ていきます。

5. 複雑になった現行システムへの対策

長期運用が複雑さを積み重ねる

長期間の改修で複雑になった現行システムへの対策が、政府のクラウド活用の基本方針に追記されました⁶。長く運用されてきたCOBOLの基幹システムほど、改修が積み重なり、全体像を把握しづらくなっている場合が目立ちます。

改修のたびに部分最適が積み重なると、仕様書だけでは実態を追えなくなります。COBOLの基幹システムに長く関わってきたエンジニアの経験が、この複雑さを解きほぐす材料として求められる理由もここにあります。

対策が方針に追記された意味

方針に対策が追記されたということは、複雑化した現行システムへの対応が、個別の現場任せでは済まなくなってきていることの表れでもあります。

現場での対応としては、複雑さを一気に解消しようとするのではなく、どこがどう複雑になっているのかを言葉にして整理することが先になります。整理された記録は、そのまま移行か維持かを決める材料にもなります。

複雑さを整理する作業は地道ですが、判断の材料としての価値は高いといえます。長く運用に関わってきた経験は、複雑になった現行システムを読み解くうえで生きてきます。

積み上げてきた経験を、判断のための言葉に変えていく関わり方が、この領域では求められています。

複雑になった現行システムに向き合ってきた経験は、案件を選ぶ際にもそのまま強みになります。同じ経験を積んできた立場だからこそ気づける論点は、外部から関わり始めたばかりの人には見えにくいものです。

次の章では、刷新が一度で終わらないことを、クラウド移行後の運用という視点から見ていきます。

6. 移した後にも刷新の時期がある

移行の直後と、その後の運用フェーズでは見る観点が違う

政府のクラウド活用の基本方針では、クラウドへ移した後の刷新の時期についても項目が置かれています⁹。移行を終えた時点をゴールとして扱っていないことが、この項目からも読み取れます。

COBOLの基幹システムをクラウドへ移した後も、一定の時期が来れば次の刷新が視野に入ります。移行を一度きりの出来事として捉えると、この先の見通しを見誤ることになります。

移行が完了した直後は、システムが動き続けることに関心が向きがちです。しかし方針が示すとおり、その先には次の刷新の時期が控えています。移行の直後と、運用が続く段階とでは、確かめておきたい観点が変わります。

段階	関心が向きやすい点	確かめておきたい点
移行の直後	システムが問題なく動くか	次の刷新の時期をいつ見込むか
運用が続く段階	日々の稼働の安定	運用の仕方そのものを見直しているか

運用を変えなければ効果は出ない

刷新しても運用が従前のままでは、コスト削減の効果は十分に出ません¹⁰。クラウドへ移すこと自体が目的化すると、この点を見落としやすくなります。

運用の仕方を変えるという発想は、移行の検討段階からあらかじめ材料に含めておく必要があります。移した後にどう運用するかまで見通しておくことが、判断の材料としての厚みになります。

移行は通過点であり、その先に次の刷新が控えています。この見通しを持てるかどうかが、材料を作る立場のエンジニアの価値を分けます。

見通しを持つといっても、先の刷新の時期を具体的に言い当てる必要はありません。運用の仕方を見直す視点を持ち続けているかどうかを、材料の中に含めておくだけで十分です。

次の章では、契約の負担と人材の確保という、判断を難しくしているもう一つの側面を見ていきます。

7. 契約の負担と、人材の確保

契約ごとの負担が、検討を止める

取引ごとに手間や工数がかかる点を課題として挙げる企業が目立ちます⁴。COBOLの基幹システムに関わる契約は、案件ごとに条件や範囲を都度取り決める場面が多く、この負担が検討そのものを重くしています。

契約面の負担が大きいと、技術的な選択肢を検討する前段階で疲れてしまう現場も出てきます。材料を届ける立場のエンジニアとしては、契約の負担そのものを軽くする提案まではできなくても、判断に必要な材料を簡潔な形で渡す工夫はできます。

契約の形を大きく変えることは、一人のエンジニアの範囲を超えます。ただ、どの部分に負担が集中しているのかを言語化して示すことならできます。小さな整理の積み重ねが、次の契約更新のときの材料になります。

人材の確保が、内製化の壁になる

内製化を進めるうえでの課題として、人材の確保や新しい技術への対応を挙げる企業が目立ちます⁵。COBOLの基幹システムを長く保守してきた経験を持つ人材は、社内に限られている場合が多く、外部の力を借りる場面が増えています。

人材の確保が壁になっている現場ほど、判断の材料づくりを任せられる相手を求めています。COBOLの経験だけでなく、材料を整理し言葉にして手渡せる力が、参画の入り口になります。

契約の負担と人材の確保。この二つは別々の課題に見えて、根っこは同じです。判断できる材料と、判断できる体制が、同時に不足している状態から生まれています。どちらか一方だけを整えても、検討は前に進みません。

図の作成：Remogu編集部。整理したもので、統計データではありません

Remoguは、リモートワークの案件に特化したエンジニアマッチングサービスで、案件の90%以上がフルリモート可能です。場所に縛られず、これまで積み上げてきた経験を活かせる案件と出会う入り口になります。

ここまで見てきた材料と、決める人と、規模による分かれ方。これらを整理して手渡す関わり方が、この領域では求められています。

移行と維持のどちらを勧めればよいですか

この記事は、どちらか一方を勧める材料ではありません。材料と決める人がそろっているかを確かめ、その状態を言葉にして手渡すことが、この記事で示した関わり方です。最終的な選択は、各企業の状況とクライアントとの協議で決まります。大切なのは判断を先送りにすることではなく、判断できる状態を早く整えることです。

小規模なシステムと、独立して運用されてきたシステムは、どう見分ければよいですか

対象範囲が限られているかどうかで見分けられます⁷。他のシステムと依存関係を持ちながら、組織ごとに独立して運用されてきたかどうかも、あわせて確かめておきたい点です⁸。

クラウドへ移した後は、何を確かめればよいですか

運用の仕方を変えているかどうかを確かめます。刷新しても運用が従前のままでは、コスト削減の効果は十分に出ません¹⁰。移した後の運用まで見通しておくことが、次の判断につながります。クラウドへ移すこと自体をゴールにせず、その先の運用まで含めて材料を整えておくと、次の刷新にも落ち着いて備えられます。

COBOLの基幹システムに関わってきた経験は、そのまま判断の材料になります。積み上げてきた経験を、参画先で判断できる材料に変えていく。そのために、自分の経験に近い案件がどこにあるかを、まず確かめてみましょう。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」レガシーの残存（2025年4月）
＊2 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」引き継ぎの材料（2025年4月）
＊3 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」決める人（2025年4月）
＊4 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」契約の負担（2025年4月）
＊5 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」入る余地（2025年4月）
＊6 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」複雑さへの対策（2026年）
＊7 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」規模で変わる（2026年）
＊8 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」分かれている前提（2026年）
＊9 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」移した後の話（2026年）
＊10 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」刷新の限界（2026年）