COBOLエンジニアのフリーランスがつまずきやすい点と対策

フリーランスのCOBOLエンジニアがつまずきやすいのは、担当する工程が聞いていた話と違うこと、夜間・休日の対応の扱いがあいまいなこと、環境の系統の違いで立ち上がりが遅れること、設計書と実装の食い違いから影響調査に漏れが出ることです。どれも、長く稼働してきた基幹システムを、外部の立場で短い期間に扱うことから起きます。

対策の基本は、つまずきの種を契約と参画初期の確認で小さくしておき、現場では調査の記録と早めの共有で守ることです。この記事では、契約・現場・技術・お金の順に、COBOLならではの場面と対策を整理します。契約前に確かめる項目の一覧はCOBOLエンジニアがフリーランスになるにはで扱っているので、ここでは「実際に起きやすい場面」に絞ります。

契約でのつまずき

担当工程が聞いていた話と違う

面談では「影響調査から入ってほしい」と聞いていたのに、参画すると製造とテストだけを任される、あるいは反対に、製造の要員として入ったのに設計書の作成やレビューまで期待される、という食い違いは起きやすいものです。COBOLの保守は工程の境目があいまいになりやすく、引き受ける範囲が少しずつ広がることもあります。

対策：参画前に、自分が担う工程と成果物（影響調査の一覧、設計書、テスト結果など）と、担わないものを言葉で確かめておきます。範囲の外の依頼が来たときの扱いは業務範囲が変わったときの記事をご覧ください。

夜間・休日のリリース対応の扱いが決まっていない

基幹系の案件では、リリースや本番の切り替えが夜間や休日になることがあります。契約の段階でこの扱いを決めていないと、時間外の作業が精算の対象になるのか、月の稼働時間にどう数えるのかで、後から食い違いが生じます。

対策：夜間・休日の作業があるか、その頻度の見込み、精算の扱いを参画前に確かめ、契約の書面と照らし合わせます。精算の仕組みは精算幅の記事で解説しています。

常駐先で指示の形が社員と変わらなくなる

常駐の多いCOBOLの現場では、発注元の社員と同じ席で働き、勤務時間や作業の手順まで直接指示される状態になりやすい傾向があります。準委任の契約と実態がずれてくると、自分の立場が分かりにくくなります。考え方は偽装請負の記事で解説しています。

現場でのつまずき

環境の系統が違い、立ち上がりに時間がかかる

同じCOBOLでも、メインフレームの系統が違えば、ジョブの書き方、ユーティリティ、オンラインの仕組みが変わります。前の現場の感覚で進めると、ジョブの定義を読み違えたり、確認の手順が分からず止まったりします。

対策：最初の数週間は、ジョブの流れ、使われているユーティリティ、テスト環境の使い方を自分用の手順書にまとめながら覚えます。分からないことは、まとめて聞く時間を窓口にもらうと、相手の負担を減らせます。最初の1か月の進め方はCOBOLエンジニアの参画初月にやることで整理しています。

前の現場のやり方を持ち込みすぎる

調査の観点やテストの進め方に自分の型があるのは強みですが、参画してすぐに持ち込むと、現場の反発を招きやすくなります。長く同じ手順で保守してきた現場ほど、手順を変えることに慎重です。

対策：最初は現場の手順を踏襲し、困っている点が見えてから一つずつ提案します。提案するときは、漏れが減る、確認の手間が減るなど、何が良くなるかを先に説明します。

持ち出しのルールを踏み越えてしまう

ソースや設計書、テストのデータを手元にメモしたり、別の場所に写したりすることが、現場のルールで禁じられていることがあります。悪気がなくても、契約や守秘義務の違反になるおそれがあります。

対策：参画の初日に、扱ってよい情報、作業してよい端末と場所を確かめます。迷ったら聞いてから動きます。守秘義務の考え方は秘密保持契約の記事で扱っています。

技術でのつまずき

設計書を信じて影響調査に漏れが出る

長年の改修で、設計書と実際のプログラムが合っていないシステムは少なくありません。設計書だけを頼りに影響範囲を洗い出すと、共通のレコード定義を通じて使われているプログラムや、別のジョブから呼ばれている処理を見落とします。漏れは本番の障害に直結します。

対策：設計書に加えて、ソースやCOPY句、ジョブの定義を検索して実際の使われ方を確かめます。調べた範囲と方法を一覧に残しておくと、漏れが見つかったときにも経緯を説明できます。

数値の形式や文字コードの違いを見落とす

パック10進数やゾーン10進数の扱い、桁あふれや端数の処理、文字コードの違いは、結果のわずかなずれとして表に出ます。特に移行の現新比較では、差分の原因がこうした違いにあることがよくあります。

対策：差分が出たら、データの形式、文字コードの変換、並べ替えの順序、端数の処理の順に切り分けます。求められる知識の全体像はCOBOLの案件で求められるスキルで触れています。

本番の障害で再実行の判断を急ぐ

夜間バッチが異常終了したとき、原因を確かめないまま再実行すると、ファイルの二重更新など、被害を広げることがあります。外部の立場だと「早く直さなければ」という焦りから判断を急ぎがちです。

対策：再実行の判断は、現場の手順と責任者の判断に従います。自分の役割は、ログやリターンコードから原因の見立てを出し、取れる手の選択肢を示すことだと考えておくと、落ち着いて動けます。

お金でのつまずき

移行の切り替えや改修の区切りで契約が突然終わる

移行の切り替えや制度対応の山場が過ぎると、体制が縮小されることがあります。フリーランス法では、6か月以上の業務委託を解除したり更新しなかったりする場合、発注側は少なくとも30日前までに予告することになっています（2026年10月時点、公正取引委員会のフリーランス法特設サイトによる）。

対策：契約期間と、改修や移行の工程の区切りを並べて見ておき、更新の見込みを早めに確かめます。契約期間の考え方は契約期間の記事をご覧ください。

合う案件がすぐに見つからず空白が長引く

COBOLの案件は、環境の系統、業務、工程の条件が細かく、次の案件が条件に合うまで時間がかかることがあります。リモートや週の稼働日数を絞りすぎると、さらに選択肢が減ります。

対策：契約の更新時期の1〜2か月前には次の相談を始めます。通える範囲や出社の頻度に幅を持たせ、保守と移行の両方を候補に入れると、選べる案件が広がります。

長期の保守で報酬と役割が釣り合わなくなる

同じ現場の保守を長く続けるうちに、製造の要員として入ったのに、影響調査やレビュー、若手の指導まで担うようになることがあります。役割が広がっても条件が見直されないと、負担だけが増えます。

対策：担っている役割の変化を記録しておき、契約の更新の時期に条件を見直す相談の材料にします。報酬の決まり方はCOBOLエンジニアの報酬の記事で整理しています。

よくある質問

参画してから、聞いていた工程と違うと気づきました。どうすればよいですか？

まずは、何が違うのかを具体的に書き出し、契約で決めた業務範囲と照らし合わせます。そのうえで、紹介を受けたエージェントや発注側の窓口に早めに伝えてください。我慢して続けると、範囲外の作業が当たり前になり、後から戻しにくくなります。

自分の改修が原因で本番障害が起きたら、損害賠償を求められますか？

準委任契約では、成果そのものではなく、専門家として通常求められる注意を払って業務を行うことが約束の中身です。ただし、契約の内容や、作業の進め方に落ち度があったかどうかで判断が変わることがあります。不安がある場合は、契約書の損害賠償の条項を読み、弁護士などの専門家にご相談ください。

経験のない系統のメインフレームの案件に入っても大丈夫ですか？

COBOLの読解や影響調査の考え方は共通して生きるため、入れる案件はあります。ただ、ジョブの書き方やユーティリティの違いで立ち上がりに時間がかかるため、面談でその差を正直に伝え、最初の数週間で覚える見込みを話しておくと、参画後の食い違いを防げます。