本業でCOBOLの保守を続けながら、業務委託の副業を探していたときのことです。打ち合わせで「汎用機の端末はお渡しできません」と言われ、やはりCOBOLの副業は無理かと思いかけました。ところが相手は続けて、「お願いしたいのは、このプログラムが何をしているかを書き起こしてもらうことなんです」と話します。COBOLの副業は、汎用機を動かす仕事か、仕様を言葉にする仕事かで分けます。

1. COBOLの副業が難しく見える理由

汎用機の端末が副業の机に届かない

COBOLの仕事と聞いて思い浮かぶのは、本番ジョブの運用、夜間の障害対応、汎用機の上でのプログラム改修とテストの実行です。どれも客先の閉じた環境に入ることが前提で、本業ではそれが作業環境の当たり前になっています。

そのため、副業でも同じ環境が要るはずだと考えがちです。自宅のパソコンから汎用機の端末は使えません。副業の発注元が端末を貸し出す場面も、あまり想像できません。「端末はお渡しできません」の一言で話が終わったように感じるのは、この前提があるためです。

環境に入るかどうかで仕事を分ける

ただし、COBOLにまつわる仕事のすべてが汎用機の上で進むわけではありません。ここでは書き手の整理として、仕事を2つに分けます。1つは環境に入る仕事で、本番ジョブの運用、障害対応、汎用機上での改修とテスト実行が当たります。もう1つは環境に入らずに進む仕事で、現行の仕様の読み解き、ドキュメント化、移行のための調査、テスト設計が当たります。

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

右側の仕事は、プログラムと資料が手元で読めれば進められます。ただし、ソースコードや資料を自宅で扱えるかどうかは、発注元の規程で決まります。持ち出せない場合は、リモート接続の環境で読む形も考えられます。

打ち合わせで最初に聞くこと

打ち合わせで「汎用機には触れません」と言われたら、断る前に、頼みたい仕事がどちら側かを聞いてみます。冒頭の場面では、相手が頼みたかったのはプログラムの動きを文章にする仕事でした。端末に入れるかどうかと、仕事を受けられるかどうかは、別の話です。

では、こうした仕事はどんな背景で生まれるのでしょうか。国の資料にある、自治体の基幹業務システムの移行から見ていきます。

2. 自治体の基幹業務システムの移行とメインフレーム

特定移行支援システムの意味

デジタル庁の「地方公共団体の基幹業務システムの統一・標準化」のページは、地方公共団体の基幹業務システムのうち、令和8年度（2026年度）以降の移行とならざるを得ないことが具体化したシステムを、「特定移行支援システム」としています¹。

ここで話題になっているのは、地方公共団体の基幹業務システムです。民間企業の基幹系全体の話ではありません。また、令和8年度は、その年度以降に移行することになるシステムの区分を示す年で、移行がその年度から始まるという意味ではありません。

理由の例にメインフレームが挙がっている

同じページは、特定移行支援システムとなる理由の例として、最初に「現行システムがメインフレームで運用されているもの」を挙げています¹。理由はほかにも、個別開発のもの、事業者の撤退、事業者のリソースのひっ迫などがあります。

メインフレームは理由の例の1つです。例の並びから、メインフレームが主な理由だと読むことはできません。さらに、この記述から、COBOLを使う仕事が増えるのか減るのかも分かりません。

国の支援の方針は5年以内

デジタル庁、総務省、制度所管省庁は、特定移行支援システムについて移行完了の期限を設定し、概ね5年以内に標準準拠システムへ移行できるよう積極的に支援するとしています¹。

これは特定移行支援システムを持つ自治体に向けた支援の方針です。移行が5年以内に終わった実績でも、終わるという予測でもありません。そのため、この5年を、COBOLの仕事が減る期間や続く期間として読むことはできません。

資料の記述の項目別の整理

デジタル庁のページの記述を、項目ごとに並べ直します。特定移行支援システムの意味、理由の例、国の支援の方針の3つです。いずれも地方公共団体の基幹業務システムについての記述で、民間企業の基幹系や、COBOLを使う仕事の増減について述べたものではありません。理由の欄は例の列挙で、挙がっている順に大きさの差があるわけではありません。

項目	資料の記述
特定移行支援システムの意味	令和8年度（2026年度）以降の移行とならざるを得ないことが具体化した、地方公共団体の基幹業務システムです1
理由の例	現行システムがメインフレームで運用されているもの、個別開発のもの、事業者の撤退、事業者のリソースのひっ迫などです1
国の支援の方針	移行完了の期限を設定し、概ね5年以内に標準準拠システムへ移行できるよう積極的に支援するとしています1

メインフレームの移行が動くとき、副業の側にはどんな仕事が生まれるのでしょうか。次の節で、移行の前にある作業を見ます。

3. 移行の前に要る、現行の仕様を言葉にする仕事

レポートが挙げる、仕様のドキュメントの問題

経済産業省のレガシーシステムモダン化委員会総括レポート（2025年5月28日）は、レガシーシステムの問題の例として、仕様や設計のドキュメントが整備されておらず、新システムへの移行や再構築時に支障が発生することを挙げています²。

これはレガシーシステム一般についての指摘で、COBOLの名前は出てきません。また、前の節のデジタル庁の資料は自治体の基幹業務システムの話で、こちらは別の資料です。自治体も企業も同じ流れにあるとは、束ねて言えません。

移行の前段にある、環境に入らない作業

ここからは書き手の見立てです。移行は、現行の仕様をつかむところから始まると考えます。プログラムを読み解き、ドキュメントに起こし、移行先との差分を調べます。この3つは、現行のプログラムと資料が手元にあれば、汎用機の端末に入らなくても進められる段階です。

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

仕様や設計のドキュメントが整っていないと移行時に支障が出る、というのがレポートの指摘でした。そうであれば、ドキュメントが無い部分を、プログラムから起こす作業が要る場面はありえます。仕事が増えているとまでは言えませんが、COBOLを読み、処理の意味を説明できる経験は、この場面で使えます。

言葉にするとは、何を書くことか

ここでの「言葉にする」は、プログラムの1行ずつの解説ではありません。何を入力として受け取り、どんな条件で分岐し、何を出力するのか。移行先の担当者が読んで、同じ結果を出す仕組みを作れる粒度の説明です。

本業で保守を続けてきた人は、プログラムの動きだけでなく、業務の都合で入った例外の処理にも触れてきたはずです。こうした経験は、資料が残っていない場面で、読み解く側の手がかりになります。次の節では、メインフレームを使っていることと、レガシーであることの関係を見ます。

4. メインフレームの利用とレガシーの線引き

古い技術でも、レガシーではない場合

同じレポートは、メインフレーム等の古い技術で構築されたシステムでも、保守の体制が整い、仕様が明確で、継続的な機能改良が可能な作りであれば、レガシーシステムではないと言える、と整理しています²。メインフレームを使っているというだけで、レガシーと呼ぶ基準にはなっていません。

この整理は、COBOLの仕事を否定するものではありません。条件の例に、仕様が明確であることが入っている点は、この記事の主題と重なります。仕様が書き起こされているかどうかが、システムの状態を左右する条件の1つに数えられているということです。

移行した後にも残る注意

同レポートは、既にメインフレーム等から脱却済みであっても、運用維持保守に問題があれば再レガシー化する可能性があると指摘しています²。移行すれば片付く、という整理にはなっていません。移行先のシステムでも、保守の体制が問われます。

条件と注意の項目別の整理

ここで、経済産業省のレポートの2つの記述を並べます。1つは、メインフレーム等の古い技術で構築されたシステムでも、レガシーではないと言える条件の例です。もう1つは、移行して脱却した後の注意です。最後の行は、この記事の書き手の見立てで、レポートの記述ではありません。条件の例は挙がっているものの一部で、これだけを満たせばよいという意味でもありません。

観点	中身
レガシーではないと言える条件の例	保守の体制が整っていること、仕様が明確であること、継続的な機能改良が可能な作りであることです2
移行した後の注意	運用維持保守に問題があれば、再レガシー化する可能性があります2
書き手の見立て	移行した先でも、残った側でも、仕様を説明できる人の手が要る場面があります

移行の先でも、残った側でも

ここからも書き手の見立てです。移行した先のシステムが再レガシー化しないためには、保守の体制と、仕様が明確であることが要ります。移行せず残ったシステムでも、仕様が明確であれば、レガシーとは言えないと整理されていました。どちらの側でも、現行の仕様を説明できる人の手が要る場面は考えられます。

COBOLの仕事が先細りになる、とも、安泰だとも、この資料からは言えません。言えるのは、仕様を言葉にする作業が、移行の前にも後にも、残った側にも関わるという範囲までです。次の節では、汎用機に触れなくても進む仕事の形を、成果物ごとに見ていきます。

5. 汎用機に触れなくても進む仕事の形

仕事と成果物の組み合わせ

書き手の整理として、環境に入らずに進む仕事は、手元に残る成果物で見分けると分かりやすくなります。プログラムの読み解きは処理の説明書、ファイルや帳票の項目の洗い出しは項目の対応表、移行先との差分の調査は差分の一覧、テスト設計はテストケースの一覧という組み合わせです。

図の作成：Remogu編集部。仕事と成果物の組み合わせを整理したもので、統計データではありません

4つの成果物は、いずれも文書です。端末の中で動かして確かめる作業ではなく、読んで、書いて、渡す作業なので、区切りを決めて受けやすい仕事だと考えます。

読み解きと項目の洗い出し

プログラムの読み解きでは、冒頭の場面のように、何を入力として受け取り、どの条件で分岐し、何を出力するのかを文章にします。処理の説明書は、移行先の担当者が読んで、同じ結果を出す仕組みを組める粒度が目安です。

ファイルや帳票の項目の洗い出しは、項目の名前、桁数、意味を表に並べる作業です。本業で保守を続けてきたなら、項目がどの処理で使われているか、例外的な使い方があるかに触れてきたはずで、その経験が読み解く手がかりになります。

差分の調査とテスト設計

移行先との差分の調査は、現行の処理と移行先の仕様を並べ、同じ結果になるかを一覧にする仕事です。現行の処理を細部まで読み解いた人が書くほど、一覧の精度は上がると見立てています。

一方、テスト設計は、読み解いた結果から、確かめる条件と期待する結果をテストケースの一覧にまとめる仕事です。テストの実行は汎用機や移行先の環境で行う場合があるため、副業では設計までを受ける、という切り分けも考えられます。

資料の持ち出しとリモート接続

ソースコードや資料を自宅で扱えるかどうかは、発注元の規程で決まります。持ち出せる場合は手元で読めますが、持ち出せない場合は、リモート接続の環境に入って読む形が考えられます。どちらになるかは、受ける前に決めておく項目です。

では、受ける前に何を決めておけばよいのでしょうか。次の節で、項目に分けて見ていきます。

6. 受ける前に決めておく項目

決めておく6つの項目

書き手の整理として、受ける前に決めておく項目は6つあります。資料の受け渡しの方法、リモート接続の有無と時間帯、成果物の形と粒度、質問の窓口と回答の待ち時間、秘密保持の範囲、本業の取引先と重ならないかです。いずれも、始めてから決めようとすると、作業が止まる原因になります。項目ごとに、決める中身の例を並べます。

決めること	中身の例
資料の受け渡しの方法	ソースコードや資料を手元に置けるか、置けないか
リモート接続の有無と時間帯	接続して読む場合の、使える曜日と時間
成果物の形と粒度	説明書か対応表か、1つの処理ごとか、機能ごとか
質問の窓口と回答の待ち時間	誰に聞くか、返事が届くまでの目安
秘密保持の範囲	業務の内容や資料のうち、外に出せないもの
本業の取引先との重なり	取引先や、取引先の関連する業務を相手にしていないか

受け渡しと接続の決め方

資料の受け渡しは、先に決めておく項目の筆頭です。手元に置けるなら、保管の方法と、仕事が終わったあとの扱いまで決めます。置けないなら、リモート接続の環境で読むことになり、接続できる時間帯が作業時間を決めます。

本業と並べる副業では、接続できる時間帯が本業の時間と重ならないかも見ます。夜間や休日にしか接続できないなら、1週間に進められる量が変わり、成果物の粒度や期限の置き方にも響きます。

質問の窓口と本業との重なり

仕様を読み解く仕事では、プログラムを読んで分からない箇所が出てきます。そのときに誰へ質問し、返事を何日待つのかが決まっていないと、作業が止まります。待ち時間の目安を先に聞いておけば、成果物の期限を現実的に置けます。

そして、本業の取引先と重ならないかは、読み解く対象のシステムが分かってから確かめます。対象が本業の取引先の業務に近い場合は、本業の側の契約や規程に、副業についての定めがないかも見ておきます。次の節では、これらを受け方の順番に並べます。

7. 本業と並べるための受け方

受け方の順番

書き手の見立てとして、受け方には順番があります。最初に、頼まれた仕事が環境に入る必要のある仕事かどうかを確かめます。次に、成果物の区切りを決め、そのうえで資料の受け渡しの方法を決めます。最後に、契約の条件を書面で確かめます。

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

この順番にするのは、最初の問いで話の大半が決まるためです。環境に入る必要がある仕事なら、本業と並べるのは難しくなります。環境に入らずに進む仕事なら、残りは成果物と受け渡しの条件の調整になります。

資料から言えること、言えないこと

自治体の基幹業務システムについては、デジタル庁のページが、メインフレームでの運用を特定移行支援システムとなる理由の例の1つに挙げています¹。経済産業省のレポートは、仕様や設計のドキュメントが整っていないと移行時に支障が出るとしています²。移行後も、運用維持保守に問題があれば再レガシー化する可能性がある、という指摘もあります²。

ただし、2つの資料は別の話で、COBOLの仕事の増減を示すものでもありません。そこから書き手が見立てたのは、移行の前後で現行の仕様を説明できる人が要る場面がある、というところまでです。副業は、その場面の一部を、環境に入らない形で受ける選択肢です。

最初の一歩は、頼まれる仕事を聞くこと

Remogu（株式会社LASSIC運営）は、リモートワーク案件特化のエンジニアマッチングで、案件の90%以上がフルリモート可能です。案件の条件は案件によって異なるため、登録して、自分の経験に合う条件を確かめるところから始められます。

打ち合わせで「端末はお渡しできません」と言われたときは、そこで断らずに、頼みたい仕事がどちら側かを聞いてみます。本業で積んだ読み解く力は、汎用機の外でも使える場面があります。COBOLの副業は、汎用機を動かす仕事か、仕様を言葉にする仕事かで分けます。

8. よくある質問

汎用機の環境が自宅に無くても練習はできますか

できます。COBOLの文法やファイルの処理は、オープン系の処理系でも確かめられます。読み解きや項目の洗い出しの練習なら、手元の環境で足ります。

ただし、汎用機に固有の操作は、手元の環境では試せない場合があります。環境に入る仕事を受けるのであれば、その部分は本業の経験で補うことになります。

移行が進むとCOBOLの副業は無くなりますか

この記事で見た資料の範囲では、無くなるとも、続くとも言えません。デジタル庁などは、特定移行支援システムについて、概ね5年以内に標準準拠システムへ移行できるよう支援するとしていますが、これは自治体の基幹業務システムへの支援の方針です¹。

経済産業省のレポートは、メインフレーム等の古い技術のシステムでも、保守の体制が整い、仕様が明確で、継続的な機能改良が可能ならレガシーではないと整理しています²。移行後にも保守の問題があれば再レガシー化しうるとも指摘しています²。書き手の見立てでは、移行の前にも後にも、現行の仕様を説明する仕事があります。

本業の取引先と近い分野の副業を受けるときに確かめることは何ですか

本業の契約書や社内規程に、副業の扱いが書かれていないかを確かめます。あわせて、本業で負っている秘密保持の対象に、副業で読む資料や業務の内容が入らないかも見ます。

判断に迷うときは、副業の発注元と本業の側の両方に、読み解く対象の範囲を伝えたうえで相談します。受ける前の段階で、対象のシステムと取引先の関係を示せるようにしておくと、話が進めやすくなります。

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

出典・参考情報

＊1 デジタル庁「地方公共団体の基幹業務システムの統一・標準化」（2026年9月30日・2026年10月確認）
＊2 経済産業省「レガシーシステムモダン化委員会総括レポート」（2025年5月28日・2026年10月確認）