メインフレームエンジニアのフリーランス単価と参入5ステップ

担当している汎用機システムのマイグレーション計画が社内で動き出し、「自分の担当領域はいつまで残るのか」と考え始めた方は少なくないと思います。転職サイトを開いてみても、並んでいる求人の書き方と自分の 15 年・20 年の経験がどうにも噛み合わない。フリーランスという選択肢を知って単価相場の記事をいくつか読んでも、「案件はあるらしい」という以上の実感が得られない、という状態で止まっている方もいるでしょう。

その行き詰まりの原因は、多くの場合「案件があるかどうか」ではありません。メインフレーム系のフリーランス案件は 2026 年 8 月時点でも継続して募集されており、単価も公開されています。問題は、公開されている「平均月 60 万円」という数字を、自分のスキル構成に当てはめる方法が分からないことです。COBOL が書けるだけの人と、z/OS 上で JCL・CICS・DB2 まで運用できる人が同じ金額になるはずはない、という直感はあっても、その差がいくらなのかを説明した情報がほとんど見当たりません。

もう一つの壁が、経験の言語化です。長く社内にいるほど、経歴は社内の呼称やプロジェクト略称で記憶されています。「◯◯システムの二次開発を担当」という書き方は社内では通じても、案件要件を書いている側には何も伝わりません。案件要件で使われている語に翻訳しない限り、経験が正当に評価されないまま単価が決まってしまいます。

この記事では、メインフレームエンジニアのフリーランス単価を「ベース＋加算要素」という内訳に分解し、自分のスキル構成から提示単価を組み立てる方法を整理します。あわせて、スキル棚卸しからスキルシートの書き換え、登録先の選定、商談での答え方、初回の単価提示までを 5 ステップの参入ロードマップとして示し、2035 年度末という確定した期限から逆算した時間軸の考え方も扱います。単価の数値・案件数・期限はすべて出典と時点を併記していますので、ご自身で最新の値を確認しながら読み進めてください。

結論｜メインフレームエンジニアのフリーランス単価は月60万〜95万円が中心

実案件で確認できる単価レンジ

まず、公開情報で確認できる数字を並べます。

レバテックフリーランスの JCL 案件一覧によると、JCL の公開案件数は 201 件で、月単価は平均 60 万円、最低 40 万円、最高 185 万円です（2026 年 8 月時点）。JCL は汎用機のジョブ制御言語ですから、この数字はそのままメインフレーム系案件の中央値付近を示していると考えて差し支えありません。

一方、基盤運用まで担う案件になると水準が上がります。同じレバテックフリーランスの JCL 案件のなかには、COBOL・IMS・DB2・JCL を扱う金融機関向け基幹系メインフレームのバージョンアップ案件が、月額上限 85 万円で掲載されています。Adecco フリーランスの JCL 案件一覧でも、掲載 22 件の最高単価は 95 万円で、クレジットシステムの統合対応が月額 75 万〜95 万円で募集されています（いずれも 2026 年 8 月時点）。掲載元が違っても、z/OS 環境でのバッチ運用や DB2 を含む基幹系案件の上限は、月 85 万〜95 万円あたりに集まっています。

スキル単位で平均を比べても、同じ傾向が読み取れます。Adecco フリーランスでは JCL 案件の平均月単価が約 59.6 万円であるのに対し、DB2 案件は掲載 27 件で平均約 67.8 万円、最高 140 万円です（2026 年 8 月時点）。データベース側まで見られるかどうかで、平均そのものが 8 万円ほど動いていることになります。

COBOL 単体で見た場合の平均月単価は、集計元によって開きがあります。コエテコキャリアの集計とインディバースの集計を比べると、平均は 50 万円台から 70 万円台前半まで幅があり、最高単価は 170 万〜185 万円とされています。この「幅の大きさ」自体が重要な情報です。同じ COBOL 案件と呼ばれるものの中に、単価が 3 倍以上違う仕事が混在しているということだからです。

単価差を生んでいるのは言語ではなく基盤・ドメイン・移行フェーズ

この幅を作っているのは、COBOL の習熟度ではありません。案件要件を読み比べると、金額が上がる案件には共通して次のいずれかが含まれています。

• z/OS・JCL・CICS・IMS・DB2 といった基盤側の運用・障害対応まで任せられること
• 勘定系・保険契約管理・官公庁基幹など、特定の業務ドメインの深い理解が前提になっていること
• 現行解析・リホスト・リライトなど、移行プロジェクトの一部を担えること
• チームリードやベンダー調整、ドキュメント整備といった役割上の責任範囲が広いこと

逆に、既存プログラムの改修とテストが中心で、仕様も手順も揃っている案件は、COBOL の経験年数が長くてもベース水準に収まりやすくなります。つまり、単価を決めているのは「何年 COBOL を書いてきたか」ではなく「メインフレームという基盤の上で何を任せられるか」です。

この記事で得られること

以上を踏まえると、平均値を眺めても自分の提示額は出てきません。必要なのは、自分のスキル構成を要素に分解し、それぞれがいくら乗るのかを積み上げる作業です。この記事の残りでは、次の 4 つを順に扱います。

1. 案件がどこに、どれだけ、どういう中身で存在するか
2. 単価をベースと加算要素に分解し、モデルケースで提示額を計算する方法
3. 2030 年度末・2035 年度末という確定した期限から逆算した、稼ぐフェーズの選び方
4. スキル棚卸しから初案件獲得までの参入 5 ステップ

メインフレームエンジニアのフリーランス案件は今どれだけあるか

汎用機エンジニアのフリーランス案件はどこにあるか

「案件がある」と言われても実感が湧かないと思いますので、確認できる掲載件数を挙げます。いずれも 2026 年 8 月時点の公開情報です。

ここで押さえておきたいのは、スキル名によって見える件数がまったく違うという点です。COBOL で検索すると千件単位で出てくる一方、JCL や DB2、z/OS といった基盤側のスキル名で絞ると件数は一気に減ります。件数が少ないことは不利に見えますが、実際は逆で、絞られた側こそ供給が薄く単価が高い領域です。案件を探すときも、自分を売り込むときも、COBOL 一語ではなく基盤スキル名で検索・記載することが出発点になります。

案件の中身は3タイプ

掲載されている案件の中身は、大きく 3 つに分かれます。自分がどれを狙うかで、必要なスキルも単価も変わります。

1. 現行保守運用型

稼働中の基幹システムの改修・障害対応・ジョブ運用を担うタイプです。件数はもっとも多く、契約期間も長めで安定しています。既存の手順書が整備されている現場では、単価はベース水準に収まりやすい傾向があります。

2. 延命・リホスト移行型

現行資産をそのまま、あるいは最小限の変更でオープン環境や他社機に載せ替えるプロジェクトです。移行元であるメインフレーム側の仕様と挙動を理解している人が不可欠なため、現行を知っている経験者の価値が最も直接的に金額に反映されます。

3. モダナイゼーション上流・現行解析型

ドキュメントが失われた現行システムの仕様を、ソースとジョブ定義から読み解いて再構築するタイプです。移行方式の検討やベンダー選定の支援まで含む案件もあります。長年の現場勘がそのまま単価になる領域で、レガシー領域では単価上限が最も高くなりやすい仕事です。

稼働形態の実態

期待値を合わせておくために、働き方の現実にも触れておきます。

メインフレーム案件は金融・保険・官公庁といった、セキュリティ要件が厳しい領域に集中しています。そのため常駐比率が高く、リモート勤務や作業データの持ち帰りが制限されるケースが少なくありません。ただし、Adecco フリーランスの JCL 案件一覧では多くの案件に「リモート併用相談可」の記載があり、「すべて常駐」というわけでもありません。

契約期間は他ジャンルより長い傾向があります。システムそのものが長期運用前提であるうえ、引き継ぎコストが高いため、発注側も短期での入れ替えを望まないからです。週 2〜3 日稼働の案件は Web 系ほど多くありませんが、現行解析やレビュー中心の役割では成立するケースがあります。稼働日数を絞りたい場合は、後述する登録先の選定と商談の段階で明示的に条件として出す必要があります。

年齢については、40 代・50 代であることが不利に働きにくい領域です。むしろ現行システムを知る人材の高齢化と引退が課題として語られており、経験年数の長さが評価される側に働きます。

単価相場の内訳｜メインフレームエンジニアの単価はスキル要素ごとにいくら乗るか

ここからがこの記事の中核です。単価を「ベース＋加算要素」で組み立て、自分の提示額を計算できる形にします。以下で示す金額は、前述の公開単価データから読み取れる傾向をもとにした目安であり、案件の期間・地域・発注元との距離（元請けか二次請けか）によって変動します。確定値ではなく、自分の位置を測る物差しとして使ってください。

ベース単価の考え方

仕様書と手順書が整っている環境で、既存 COBOL プログラムの改修・単体テスト・リリース作業を担う。基盤側の設定変更や障害の一次切り分けは別担当がいる。この構成がベースです。

このレンジは、公開データでいう「COBOL の平均単価」の下側、おおむね月 50 万〜60 万円台に相当します。経験年数を重ねてもここから大きく上がりにくいのは、業務内容が代替可能な形に切り出されているためです。長年 COBOL を書いてきた方が相場記事を読んで「思ったより安い」と感じるとしたら、比較対象になっているのがこのベース水準だからです。

言語としての COBOL 案件の状況や、COBOL を軸にしたキャリアの選択肢そのものを詳しく知りたい場合は、COBOL フリーランス案件の実態と単価もあわせてご覧ください。本記事は言語ではなく基盤側のスキルを軸に扱います。

加算要素1｜基盤運用スキル（z/OS・JCL・CICS・IMS・DB2）

最初の、そして最も大きな加算要素が基盤運用スキルです。具体的には次のような経験が該当します。

• z/OS（または富士通 GS21・日立 VOS 系）上でのシステム運用・パラメータ設定・バージョンアップ対応
• JCL のジョブネット設計、異常終了時のダンプ解析・リラン判断
• CICS のオンライン領域の運用、トランザクション性能の調整
• DB2・IMS・VSAM のデータ設計、領域再編成、バックアップ・リカバリ設計
• 夜間バッチの処理時間管理とチューニング、締め処理の遅延対応

先ほど挙げた金融機関向け基幹系メインフレームのバージョンアップ案件（COBOL・IMS・DB2・JCL、月額上限 85 万円）や、Adecco フリーランスの JCL 案件の最高単価 95 万円が求めているのは、まさにこの領域を任せられる人材です。ベース水準との差は月 25〜35 万円程度あり、加算要素の中で寄与が最も大きくなります。

同じ掲載元の中で、JCL 案件の平均が約 59.6 万円、DB2 案件の平均が約 67.8 万円と差がつくことも、基盤側スキルの上乗せを裏づけています（Adecco フリーランス、2026 年 8 月時点）。

この差が生まれる理由は単純で、供給がほとんどないからです。COBOL は書けるがジョブの異常終了を自力で追えない、という人材は市場に一定数いますが、基盤側の障害を切り分けられる人材は極端に少なくなります。z/OS・CICS・DB2 の運用経験がある方は、その経験を最前面に出すべきです。

加算要素2｜業務ドメイン（勘定系・保険契約・官公庁・製造/流通）

次の加算要素が業務ドメインの知識です。勘定系の日次・月次処理の流れ、保険契約の異動処理、税・年金といった官公庁業務の制度対応など、システムの裏側にある業務ルールを理解していることは、外部から短期で補えない価値になります。

移行案件では特にそうです。現行の処理がなぜその順序なのか、この分岐は何の制度に対応しているのか、という問いに答えられる人がいないと、移行仕様が固まりません。同じ基盤スキルを持っていても、発注元と同じ業界の経験がある人は月 5 万〜15 万円程度上乗せされる余地があります。

注意点として、ドメイン知識は書かなければ伝わりません。「金融系システムの保守」ではなく「地方銀行の勘定系（預金・為替）における日次バッチ運用」まで書いて、初めて加算要素として認識されます。

加算要素3｜移行フェーズ経験と加算要素4｜役割

3 つめの加算要素が移行フェーズの経験です。現行仕様の解析とドキュメント化、リホスト・リライトの実作業、移行後の並行稼働・データ移行検証、オープン環境の COBOL への移植。これらのいずれかを経験していると、単純な保守要員ではなく移行プロジェクトの戦力として扱われ、月 10 万〜20 万円程度の上乗せが見込めます。移行需要が続く間はこの加算が効きやすく、後述する時間軸の議論とも直結します。

4 つめが役割です。チームリード、PL としての進捗・品質管理、ベンダー間の調整、失われたドキュメントの整備といった責任範囲は、そのまま単価に反映されます。ここは月 5 万〜15 万円程度の加算幅です。正社員時代にサブリーダー格だった方は、この経験を「マネジメント経験」という抽象語ではなく、担当した体制人数・工程・調整先の種類まで書いて示してください。

3つのモデルケースで見る提示単価の計算例

以上を組み合わせて、3 つのモデルケースで計算してみます。いずれも架空の想定例であり、実際の提示額を保証するものではありません。

ケース A：保守中心型

COBOL の改修・テストが中心。ジョブの再実行は手順書に沿って対応できるが、異常終了の原因解析は別担当。業務は流通系。

ベース 55 万円 ＋ ドメイン加算 5 万円 ＝ 月 60 万円前後

これは JCL 案件の平均月単価 60 万円とほぼ一致します。相場記事の平均値がしっくりこない方は、まず自分がここより上か下かを判定してください。

ケース B：基盤運用まで担える型

z/OS 環境で JCL のジョブネット設計と障害解析を担当。CICS のオンライン運用と DB2 の領域管理も経験。保険の契約管理システムを長年担当。

ベース 55 万円 ＋ 基盤運用加算 30 万円 ＋ ドメイン加算 10 万円 ＝ 月 90 万円台

これは、先ほど確認した基幹系案件の上限帯（月 85 万〜95 万円）と重なります。ペルソナ像として想定した「実務 15〜20 年の保守運用サブリーダー」の多くは、実はこの構成に該当します。

ケース C：移行上流に入っている型

ケース B の構成に加えて、現行システムの仕様解析とドキュメント化を担当し、移行方式の検討でベンダーとの調整も経験。チーム 5 名程度のサブリーダー。

ベース 55 万円 ＋ 基盤運用 30 万円 ＋ ドメイン 10 万円 ＋ 移行フェーズ 15 万円 ＋ 役割 10 万円 ＝ 月 110 万〜120 万円

公開データの最高単価（170 万〜185 万円）まではまだ距離がありますが、平均値からは大きく離れた位置にいることが分かります。

計算してみて自分の見込みが想像より高かった場合、それは経験の問題ではなく「これまで値付けの対象として意識してこなかった」だけです。逆に低かった場合は、どの加算要素が欠けているかが明確になったはずで、次に伸ばすべき方向が決まります。

2035年から逆算する｜メインフレーム案件はあと何年、どのフェーズで稼げるか

2030年度末・2035年度末という期限が作る需要

メインフレームエンジニアの将来性は、しばしば「需要は残る」「いや、なくなる」という水掛け論になります。しかし、この領域には他ジャンルにはない特徴があります。期限が公表されていることです。

富士通は自社メインフレームについて、製造・販売を 2030 年度末に終了し、保守を 2035 年度末に終了すると公表しています（日経クロステック「メインフレームに『2035年の崖』問題、富士通撤退でモダナイズ待ったなし」）。2026 年 8 月時点から数えると、製造販売の終了まで約 4 年半、保守の終了まで約 9 年半です。

期限が決まっているということは、その日までに移行を終えなければならない企業が確実に存在するということです。しかも移行には、現行システムを理解している人間が不可欠です。ここに、期限に向かって高まる需要の山があります。

背景としてもう一つ、人材側の事情があります。IPA の『DX 動向 2025』によると、DX を推進する人材の「量」が不足していると回答した日本企業は 85.1% で、米国（23.8%）・ドイツ（44.6%）と比べて突出しています（IPA『DX動向2025 - AI時代のデジタル人材育成』）。移行を実行したい企業が多い一方で、それを担う人材が慢性的に足りていない構図です。

IBM z 継続組と国産機ユーザーで時間軸が違う

ここで注意したいのが、「メインフレーム」とひとくくりにできない点です。

富士通が撤退方針を示している一方、日本 IBM はメインフレーム事業を継続しています。SCSK と日本 IBM は 2024 年 11 月に協業を強化し、SCSK のデータセンターに IBM z16 を導入したメインフレームの共同利用サービスを 2025 年春に開始すると発表しました（日経クロステック「SCSKと日本IBMが協業強化、メインフレームの共同利用サービスを2025年春に開始」）。また、NEC・日立・BIPROGY もサポート継続の方針を示していると報じられています（日経BP「IBMはメインフレームのハイブリッド活用推し、NEC・日立・BIPROGYもサポート継続」）。

つまり、IBM z 系のスキルと国産機のスキルでは、需要の時間軸が異なります。IBM z 環境の運用スキルは、2035 年という区切りに縛られずに継続する見込みがあります。一方、富士通機を使い続けてきたユーザー企業の現場では、期限に向けた移行案件が今後数年で集中する可能性が高いといえます。

自分がどちらの経験を持っているかで、狙うべき案件のタイプが変わります。ただし、これは公表済みの方針と業界動向から読み取れる範囲の話であり、「何年後に案件がなくなる」といった断定はできません。

移行前・移行中・移行後で必要な人材と単価がどう変わるか

移行プロジェクトは 3 つのフェーズに分かれ、それぞれ求められる人材像が違います。

注目すべきは、移行前と移行中がピークで、移行後は下がるという形です。現行システムを知っていることの希少価値は、移行が完了した瞬間に薄れます。長期的にこの領域で稼ぐつもりなら、移行後の環境で何ができるかを移行が終わる前に準備しておく必要があります。

自分はどのフェーズで稼ぐか

以上を踏まえると、参入の方針は 3 つに整理できます。

現行解析型を狙う：現行仕様の読解とドキュメント化に強みがある方向き。単価が高く、期限までの数年間は需要が見込めます。一方、案件は移行完了とともに終わるため、案件の切り替えが定期的に発生します。

移行実行型を狙う：移行元と移行先の両方を扱えることが条件です。今から準備するなら、オープン環境の COBOL や移行ツールの知識を 1 つ持つことが最短ルートになります。

移行後保守型を狙う：移行後の環境での運用に軸足を移す方針です。単価は前 2 者より抑えめですが、案件寿命は長くなります。稼働日数を絞りたい方や、長期的な安定を重視する方に向いています。

どれを選ぶにせよ、「どのフェーズで稼ぐか」を先に決めてから登録先とスキルシートを組み立てると、案件との噛み合わせが良くなります。

参入ロードマップ｜正社員の経験をフリーランス案件に換える5ステップ

ここからは、正社員の状態から初案件を獲得するまでの具体的な手順です。各ステップに、その日のうちに着手できる作業を置きました。

ステップ1｜スキル棚卸し（機種・OS・ミドル・工程・規模・実績を書き出す）

最初にやるのは、書類作成ではなく事実の書き出しです。次の 6 項目を、思い出せる範囲ですべて列挙してください。この段階では体裁を整えなくて構いません。

1. 機種・OS：IBM z/OS、富士通 GS21、日立 VOS3 など。バージョン、稼働年数、担当期間
2. ミドルウェア・製品：CICS、IMS、DB2、VSAM、JES2/JES3、ジョブ管理ツールの製品名
3. 言語・開発資産：COBOL（方言・コンパイラ）、PL/I、アセンブラ、JCL、SQL
4. 担当工程：要件定義／設計／製造／単体・結合テスト／リリース／運用監視／障害対応のどこを何年
5. システム規模：本数（プログラム本数・ジョブ本数）、データ量、オンライン端末数、バッチの処理時間、稼働ユーザー数
6. 障害対応・移行の実績：対応した障害の種類と復旧までの流れ、参加した移行・更改プロジェクトの規模と自分の役割

今日できる作業：この 6 項目の見出しだけをファイルに作り、思い出せる固有名詞を箇条書きで放り込みます。数字が思い出せないものは「後で確認」と書いて残します。所要 30 分程度です。

ステップ2｜スキルシートの翻訳（社内語から案件要件語へ）

棚卸しした事実を、案件要件で使われている語に翻訳します。ここがこの記事でもっとも重要なステップです。多くの方の経歴が正当に評価されない原因は、経験不足ではなく、社内でしか通じない書き方をしていることにあります。

翻訳前（社内語）

◯◯システム二次開発プロジェクトに参画。保守運用チームのサブリーダーとして、定期リリースおよび障害対応を担当。マイグレーション検討にも関与。

翻訳後（案件要件語）

【環境】IBM z/OS（V2.4）／CICS／DB2 V12／JCL／COBOL 【領域】生命保険の契約管理システム（オンライン＋夜間バッチ、COBOL 資産 約 4,000 本、夜間バッチ 約 1,200 ジョブ） 【役割】保守運用チーム サブリーダー（メンバー 6 名）。月次リリースの計画・レビュー・実施 【業務】(1) 契約異動処理の改修設計〜リリース (2) 夜間バッチの異常終了時の原因解析・リラン判断（オンコール当番として月 4 日）(3) DB2 の領域再編成とバッチ処理時間の短縮対応（月次バッチを約 3 時間短縮）(4) 現行仕様のドキュメント化と移行方式検討時のベンダー窓口

違いは 4 点です。(1) 環境を製品名とバージョンで書く、(2) システムを規模の数字で書く、(3) 役割を体制人数と担当工程で書く、(4) 成果を定量で書く。翻訳後の書き方であれば、案件側は「基盤運用まで任せられるか」「業務ドメインが合うか」「移行フェーズに入れるか」を読み取れます。先ほど分解した加算要素は、まさにこの 4 点から判定されています。

今日できる作業：直近に担当したシステム 1 件だけを、上記の 4 行フォーマット（環境／領域／役割／業務）で書いてみます。数字が分からない箇所は概算で構いません。1 件書ければ残りは同じ型で展開できます。

ステップ3｜登録先の選定（掲載件数と稼働条件で使い分ける）

登録先は「有名だから」ではなく、自分のスキル名で案件が現に表示されるかで選びます。手順は次のとおりです。

1. 各エージェント・案件サイトで「JCL」「z/OS」「CICS」「DB2」「IBM 系汎用機」など、COBOL 以外の基盤スキル名で検索する
2. 出てきた件数と、単価レンジ、常駐／リモートの比率を記録する
3. 件数が多い先と、単価上限が高い先を、それぞれ 1 社ずつ選ぶ

先ほど掲載件数を確認した各サイトは、この検索の出発点として使えます。件数が多い先は案件の選択肢が広く、件数が少なくても単価上限が高い先は基盤スキルを評価する傾向がある、と読むことができます。

登録は 2〜3 社に絞るのが現実的です。多すぎると同じ案件を複数社から重複提案され、かえって調整が煩雑になります。稼働日数を絞りたい場合や、リモート希望がある場合は、登録の初回面談で最初に伝えてください。後出しにすると、条件の合わない案件の紹介で時間を消耗します。

今日できる作業：基盤スキル名 3 つで 3 サイトを検索し、件数と単価レンジを表にメモします。所要 20 分程度です。

ステップ4｜商談で聞かれることと答え方

案件の商談（面談）で確認されるポイントは、メインフレーム案件ではかなり定型的です。想定質問と、答えるときに押さえる観点を挙げます。

• 「どのくらいの規模を担当していましたか」：本数・ジョブ数・データ量・バッチ処理時間で答えます。「大規模でした」は情報になりません
• 「障害対応の経験を教えてください」：具体的な事象を 1 つ選び、検知から原因特定、暫定対応、恒久対応までの流れを順に話します。何を見て切り分けたか（ダンプ、ログ、ジョブの戻り値）まで触れると、基盤運用スキルの証明になります
• 「移行案件での役割は」：関与したフェーズと、自分が出力した成果物（現行仕様書、移行方式の比較表、テストケース）で答えます
• 「ドキュメントがない環境でどう進めますか」：この質問は現行解析型の案件で頻出します。ソースとジョブ定義から追う手順、業務側へのヒアリングの進め方など、自分の実際のやり方を説明します
• 「オープン系・クラウドの経験は」：未経験であれば正直に伝えたうえで、学習の状況と、移行先環境をどう理解しようとしているかを添えます。経験の有無より、移行後を見据えているかどうかが見られています

正社員時代に商談の経験がない方が最初につまずくのは、謙遜しすぎることです。「一通りやっていました」と答えると、加算要素が一つも伝わりません。棚卸しした事実を、そのまま数字で述べるだけで十分です。

ステップ5｜初回の単価提示と契約前の確認事項

希望単価を聞かれたときは、先ほど計算した積み上げをそのまま根拠にします。「相場が 60 万円なので 60 万円で」ではなく、「z/OS 環境での CICS・DB2 運用と保険契約管理システムのドメイン経験があるため、90 万円前後を希望します」と、加算要素を明示して伝えます。根拠を添えた提示は、値引き交渉になったときにも守りやすくなります。

契約に進む前に、次の項目は必ず確認してください。

• 契約形態：準委任か請負か（成果物責任の範囲が変わります）
• 精算幅：月◯◯〜◯◯時間の上下限と、超過・不足時の単価
• 稼働日数・時間：常駐日数、コアタイム、夜間・休日対応の有無（バッチ運用案件では特に重要です）
• 勤務地・リモート可否：作業場所の制限、持ち帰りの可否
• 契約期間と更新条件：初回契約の期間、更新の判断時期
• 業務範囲：オンコール当番の有無、担当外システムへの応援の扱い

開業届の提出や各種保険の切り替えといった、独立に伴う一般的な手続きについてはフリーランスエンジニアの独立手続きで整理していますので、あわせてご確認ください。本記事ではスキルの翻訳と案件獲得に絞って扱っています。

参入前に知っておきたい落とし穴と回避策

参入できたあとに起きやすい問題にも先回りしておきます。

「保守要員」枠で単価が固定される構造と回避策

最初の案件で保守運用の一部を担当すると、次の更新でも同じ役割が前提になり、単価が据え置かれやすくなります。発注側にとっては、慣れた人が同じ仕事を続けてくれるのが最も低リスクだからです。

回避策は 2 つあります。1 つは、契約更新のタイミングで担当範囲の変更を交渉材料にすることです。「現行解析のドキュメント化も引き受ける」「移行テストの設計に入る」といった提案は、期限を抱えた発注側にとって歓迎されやすい申し出です。もう 1 つは、案件選定の段階で移行フェーズを含む案件を優先することです。前述のとおり、移行前・移行中のフェーズは単価が高く、役割の幅も広がります。

金融・官公庁案件のセキュリティ要件と稼働条件の確認項目

メインフレーム案件の主戦場である金融・官公庁は、セキュリティ要件が厳格です。参画前に、次を確認しておくとギャップが小さくなります。

• 作業場所の指定（客先常駐か、元請けの拠点か）と、フロア間の移動制限
• 貸与端末の種類、私物端末・記憶媒体の持ち込み可否
• インターネット接続の可否（調べ物ができない環境か）
• 入館手続き、身元確認書類の提出範囲
• リモート勤務の可否と、可の場合の頻度

特に「インターネットに接続できない環境か」は、働き方への影響が大きい割に見落とされやすい項目です。

週2〜3稼働・年齢条件のミスマッチをどう扱うか

メインフレーム案件は週 5 日常駐を前提としたものが多く、稼働日数を絞りたい方にはミスマッチが起きやすい領域です。週 2〜3 日を狙う場合は、現行解析・レビュー・技術顧問的な関与など、常時の立ち会いを必要としない役割の案件に絞って探すのが現実的です。エージェントには登録時点で稼働条件を明示し、条件に合う案件だけを提示してもらうようにします。

年齢面の不安については、この領域はむしろ経験年数が評価されやすい側です。とはいえ、稼働形態や体力面の折り合いは別の論点として残ります。40 代・50 代からのフリーランス転向全般の考え方は、50代フリーランスエンジニアの働き方で扱っていますので、年齢軸の判断材料が必要な方はそちらをご参照ください。

案件終了リスクの分散

メインフレーム案件に固有のリスクとして、案件の終了がシステムの終了と直結する点があります。移行が完了すれば、その現行システムに関する仕事はなくなります。長期契約が多いことは安定に見えますが、裏を返せば単一システムへの依存度が高い状態でもあります。

分散の方法は 3 つです。1 つめは、同じ発注元の別システムや、同業他社の類似システムに横展開できる形で経験を記述しておくこと。2 つめは、移行側のスキルを 1 つ持つこと（移行ツール、オープン環境の COBOL、移行先のミドルウェアのいずれか）。3 つめは、契約更新の見通しを定期的に確認し、システムの移行計画がどの段階にあるかを把握しておくことです。移行完了の 6 か月前には次の動きを始められる状態にしておくと、空白期間を避けられます。

まとめ｜今週やる3つのこと

この記事の要点を整理します。

1. メインフレーム系のフリーランス案件は実在し、件数も単価も公開情報で確認できます。JCL の平均月単価は 60 万円、z/OS 上で DB2・CICS の運用まで担う基幹系案件では月 85 万〜95 万円が上限帯として提示されています（レバテックフリーランス／Adecco フリーランス、いずれも 2026 年 8 月時点）
2. 単価はベース＋加算要素で決まります。加算要素は基盤運用スキル・業務ドメイン・移行フェーズ経験・役割の 4 つで、なかでも基盤運用スキルの寄与が最大です。平均値ではなく、自分の構成で積み上げて値付けしてください
3. 参入の障壁は案件の有無ではなく、経験の翻訳です。社内語で書かれた経歴を、環境・領域・役割・業務の 4 行フォーマットで案件要件語に書き換えるだけで、伝わり方が変わります
4. 2030 年度末・2035 年度末という公表済みの期限があります。移行前・移行中・移行後のどのフェーズで稼ぐかを決めて、そこから逆算してスキルと登録先を選んでください

そのうえで、今週着手できることは 3 つです。

• スキル棚卸しリストを埋める：機種・OS／ミドルウェア／言語／担当工程／システム規模／障害・移行実績の 6 項目を箇条書きで書き出す
• スキルシートを 1 件だけ翻訳する：直近のシステム 1 件を「環境／領域／役割／業務」の 4 行フォーマットで書き換える
• 登録先を 2 社に絞る：COBOL ではなく JCL・z/OS・CICS・DB2 といった基盤スキル名で検索し、件数と単価レンジを比べたうえで登録先を決める

COBOL という言語を軸にしたキャリアの選択肢について詳しく知りたい方は、COBOL フリーランス案件の実態と単価を、独立に伴う手続き面についてはフリーランスエンジニアの独立手続きをご覧ください。

次のアクション

メインフレーム・汎用機の経験を活かせる案件を、稼働日数やリモート可否といった条件から絞り込んで探したい方は、フリーランスエンジニア向けの案件ポータル Workee で案件を探す をご検討ください。スキルと希望条件を登録すると、条件に合致する案件を比較しながら確認できます。