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

1. 方針が決まっていない現場の前提

移行より先に必要な方針

移行に進むのか、維持を続けるのか。その方針そのものが、現場では定まっていないことが多いのです。

IPAの調査では、レガシーシステムを抱える企業が今も半数程度に上ります¹。移行を語る記事の多くは「いつ動くか」を前提に書かれていますが、その手前には、入れ替えるかどうかを決める段階があります。

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

設計書を読み込むほど、書かれていない前提に行き当たり、判断は保留になっていきます。結論を急がず、保留になっている理由を一つずつ言葉にしていく進め方もあります。

決める人が不在のまま続く検討

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

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

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

何が材料として欠けているのかは、現場に長く関わってきた経験があるほど具体的に指摘できます。その経験は、判断を助ける材料になります。

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

次は、材料がどこに残っているのかを、引き継ぎの実務から見ます。

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

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

要件定義や設計は、今もドキュメント中心で進められています¹。仕様書や設計書には、機能の一覧や画面の構成が残っていても、なぜその仕様になったのかという経緯までは記録されていないことがあります。

COBOLの基幹システムが長く運用されている場合、運用を引き継ぐ人が入れ替わるたびに、仕様書に書かれていない判断がコードの中だけに残っている可能性があります。仕様書に残る情報と、実装の中にしか残らない情報とでは、性質が違います。

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

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

浅い材料のまま判断を求められる場面

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

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

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

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

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

3. 決める人の不在

責任者が定まらない検討の現場

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

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

この状態が続くと、検討そのものが止まったまま時間が過ぎます。エンジニア側にできるのは、判断を急がせることではなく、判断に使える材料を継続的に届け続けることです。

急いで結論を迫るより、決める人が現れたときにすぐ使える形で材料をそろえておく。待つことと、備えることは別の行動です。

決める人の不在と契約の負担

システム開発の契約では、取引ごとに手間や工数がかかる点を課題として挙げる企業が目立ちます¹。決める人が定まらない検討には、この契約面の負担も重なります。

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

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

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

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

小規模なシステムと組織ごとに独立したシステムの観点の違い

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

同じ方針の中には、組織ごとに独立していたシステムの刷新という項目も別に置かれています²。両者は別々の項目として並んでいます。

COBOLの基幹システムが小規模であれば、対象範囲を絞って判断の材料を集められます。組織ごとに独立して運用されてきた場合は、他システムとの依存関係を洗い出す作業が先に必要になります。

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

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

規模ごとの進め方の違い

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

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

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

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

次は、長く運用されて複雑になった現行システムそのものへの対策です。

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

長期運用で積み重なる複雑さ

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

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

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

方針に対策が追記された以上、複雑化した現行システムへの対応は、個別の現場だけの課題として扱われていません。

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

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

積み上げてきた経験を、判断のための言葉に変えていく。それが材料を作る仕事の中心です。

複雑になった現行システムに向き合ってきた経験は、案件を選ぶ際の軸にもなります。どんな条件の現行システムを扱ってきたかを振り返ると、自分に合う案件の輪郭が見えてきます。

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

6. 移した後の刷新の時期

移行直後と運用段階の観点の違い

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

COBOLの基幹システムをクラウドへ移した後も、次の刷新の時期を考える項目があります。移行を一度きりの出来事として捉えると、この先の見通しがずれます。

移行の直後は、システムが問題なく動くかどうかに関心が集まります。しかし方針には移行後の刷新の時期も項目として置かれており、その先に次の刷新があります。移行の直後と運用が続く段階では、確かめる観点が変わります。

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

運用を変えない場合のコスト削減効果

刷新しても運用が従前のままでは、コスト削減の効果は十分に出ません²。クラウドへ移すこと自体が目的になると、運用の見直しが後回しになります。

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

移行は通過点であり、その先に次の刷新があります。この見通しを持った材料は、移行後の運用の議論でも使えます。

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

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

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

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

システム開発の契約で、手間や工数を課題に挙げる企業がある¹ことは、先ほど触れたとおりです。案件ごとに条件や範囲を取り決める場面では、この負担が検討を重くする場合があります。

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

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

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

内製化を進めるうえでの課題として、人材の確保や新しい技術への対応を挙げる企業が目立ちます¹。COBOLの基幹システムを長く保守してきた経験を持つ人材が社内にそろっていない場合は、外部の力を借りる選択肢もあります。

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

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

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

材料を整理して手渡す関わり方

冒頭で触れた、何を材料に決めるかという問いに戻ります。材料と、決める人と、規模による分かれ方、そして移した後の運用。これらを整理して手渡す関わり方が、この領域で役に立ちます。

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

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

8. よくある質問

刷新の項目は、どのように分けられていますか

政府のクラウド活用の基本方針では、小規模なシステムにおける刷新²と、組織ごとに独立していたシステムの刷新²が、別々の項目として置かれています。

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

運用の仕方を変えているかどうかです。刷新しても運用が従前のままでは、コスト削減の効果は十分に出ません²。

複雑になった現行システムへの対策は、基本方針に含まれていますか

長期間の改修で複雑になった現行システムへの対策が、基本方針に追記されています²。

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

出典・参考情報

＊1 IPA「2024年度ソフトウェア動向調査 簡易分析レポート」レガシーの残存（2025年4月・2026年10月確認）
＊2 デジタル庁「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」複雑さへの対策（2026年・2026年10月確認）