COBOLエンジニアのフリーランス案件の仕事内容｜案件の種類と働き方

COBOLエンジニアのフリーランス案件の仕事は、稼働中の基幹系システムを読み解き、変更の影響を調べ、改修とテストで「今までどおり正しく動くこと」を守ることが中心です。ただ、制度対応の保守なのか、ジョブの運用と障害対応なのか、別の基盤への移行なのかで、1日の時間の使い方も、向き合う相手も、手元に残る成果物も変わります。

この記事では、COBOLの案件を4つの種類に分け、それぞれの1日と1か月の流れ、関わる相手、成果物を整理します。求められるスキルはCOBOLの案件で求められるスキル、報酬の決まり方はCOBOLの報酬の記事で扱っているので、ここでは「参画したら実際に何をしているか」に絞ります。

仕事の中身は「案件の目的」と「環境」で決まる

COBOLの案件は、募集の文面が「COBOL開発」と同じでも、働き方が大きく違うことがあります。違いを生むのは、主に次の2つです。

• 案件の目的：今のシステムを直し続けるのか（保守）、安定して動かすのか（運用）、別の基盤や言語に移すのか（移行）
• 環境：メインフレームか、UNIXやLinuxなどのオープン系か。バッチ中心か、オンラインも含むか

この2つを掛け合わせると、フリーランスのCOBOL案件はおおむね次の4種類に分けられます。

以下では、それぞれの1日と1か月の流れを、典型的な例として紹介します。配分は現場ごとに違うため、目安として読んでください。

基幹系の保守・制度対応の仕事

銀行・保険・公共などの基幹系で、法令や制度の改正、商品の追加、業務の変更に合わせてプログラムを直す案件です。COBOLの案件のなかでも数が多い種類です。

1日の流れ（例）

朝はチームの朝会で、前日の進み具合と、仕様の不明点を共有します。午前は、変更する項目やファイルを使っているプログラムとジョブを検索し、影響の一覧を作ります。COPY句や共通のサブプログラムを通じた間接的な影響まで追うため、ソースを読む時間が長くなります。午後は改修とコンパイル、単体テストのデータづくりと結果の確認です。夕方に、調査で分からなかった点をリーダーや発注元の担当者に確認します。

1か月の流れ（例）

• 月初：改修の依頼を受け、影響調査と工数の見積もりを行う
• 月の前半：詳細設計とレビュー、改修、単体テスト
• 月の後半：結合テスト、業務部門の確認、リリースの手順書の準備
• 月末前後：本番へのリリース。夜間や休日に作業が入ることがある

制度対応は施行日が決まっているため、締め切りが動かしにくいのが特徴です。施行の前の数か月は稼働が増えやすくなります。

成果物

影響調査の一覧、詳細設計書、改修したソース、テストの仕様と結果、リリースの手順書などです。長く稼働しているシステムでは、設計書と実際のソースが合っていないことがあるため、調べた結果を設計書に反映することまで求められる現場もあります。

運用保守・障害対応の仕事

夜間バッチなどのジョブを安定して動かし、異常が起きたときに原因を調べて手を打つ案件です。改修の量より、異常に早く気づき、正しく切り分けることが仕事の中心になります。

1日・1か月の流れ（例）

朝は前夜のバッチの結果を確かめ、異常終了したジョブがあれば、ログとリターンコードから原因を調べます。データの不備か、プログラムの不具合か、運用の手順の誤りかを切り分け、再実行の手順をまとめて運用チームに渡します。日中は、問い合わせへの回答、運用手順書の更新、小さな改修を行います。

1か月の単位では、月末や月初、年度末などの締めの処理の前後に作業が集中します。処理の件数が増える時期に向けて、ジョブの実行時間やファイルの容量に余裕があるかを確かめる仕事もあります。障害の連絡を受ける当番に入るかどうかは、案件によって違います。

成果物

障害の報告書（事象・原因・対処・再発防止）、運用手順書、ジョブの実行の記録、問い合わせへの回答の記録などです。報告書は、発注元の管理職が読むことが多いため、専門用語を減らし、何が起き、何を直したかを短く書くことが求められます。

移行の現行分析・検証の仕事

メインフレームのシステムを、オープン系の基盤やクラウドに移す案件、COBOLのプログラムをJavaなどに書き換える案件です。COBOLエンジニアは主に現行の側を担います。

段階ごとの仕事

• 現行分析の段階：ソース、ジョブ、ファイルやDBの定義を読み、処理の流れと仕様を文書に起こす。使われていないプログラムやジョブを洗い出すこともある
• 移行の段階：移行先のチームからの質問に答え、文字コードや数値の形式の変換で注意すべき点を伝える
• 検証の段階：同じ入力データで現行と移行先の出力を突き合わせ（現新比較）、差分の原因を調べる

検証の段階では、差分が出るたびに「現行の仕様どおりか、移行先の誤りか」を判断する材料を出すのが主な仕事になります。端数の処理や文字の変換など、細かな違いの原因を追う作業が続くこともあります。

1か月の流れ（例）

段階によって大きく変わります。現行分析の段階は、資料の読み込みと文書化、打ち合わせが中心で、比較的予定が読みやすい時期です。現新比較のテストや本番の切り替えが近づくと、差分の調査と関係者との確認が増え、切り替えの週末に作業が入ることもあります。参画する時期がどの段階にあたるかで、働き方の見通しが変わります。

成果物

現行の仕様書、処理の流れの図、ファイルやDBの項目の一覧、変換の規則、現新比較の結果と差分の原因の一覧などです。移行の案件の今後の見通しはCOBOLの将来性の記事で解説しています。

オープン系COBOLの開発・保守の仕事

UNIXやLinuxの上で動くCOBOLのシステムを開発・保守する案件です。プログラムの書き方はメインフレームと共通する部分が多い一方、ジョブはシェルやジョブ管理のツールで動かし、コンパイルやリンクの手順も環境ごとに違います。

1日の流れは、改修、テスト、レビューが中心で、ほかの言語の開発案件に近い形です。周辺のWebシステムや他社のシステムとのファイル連携が多く、連携先の担当者と項目の形式や受け渡しの時刻を確かめる時間も多くなります。開発環境に社外から接続できる仕組みがあれば、リモートを組み合わせやすい種類でもあります。働く場所の傾向はCOBOLのリモート案件の記事をご覧ください。

どの案件にも共通する仕事

種類が違っても、次の仕事はほぼすべてのCOBOL案件にあります。

1. 影響調査：変更する項目やファイルを使っているプログラム、ジョブ、帳票を洗い出す
2. テストの証跡づくり：何を確かめ、どんな結果だったかを、後から第三者が追える形で残す
3. リリースの準備：手順書、戻す手順、作業の時間割を用意し、関係者と確認する
4. 確認の記録：仕様の不明点を誰に聞き、どう決まったかを残す

金融や公共の基幹系では、テストの証跡や作業の記録が監査やレビューの対象になります。作業の速さより、記録の丁寧さで信頼が決まる場面が多いのが、COBOLの案件の特徴です。

フリーランスならではの仕事として、自分の稼働時間の記録もあります。月の稼働時間に幅を決めて精算する契約が多く、夜間のリリースや障害対応の時間も含めて日々つけておく必要があります。仕組みは精算幅の記事をご覧ください。

関わる相手と、その相手に出すもの

COBOLの案件は、元請けの会社のチームの一員として参画する形が多く、発注元と直接話す場面はリーダーが担うこともあります。自分がどこまで発注元と直接やり取りするかは、体制によって変わります。業界ごとの現場の特徴は銀行業界のIT案件の記事なども参考になります。

よくある質問

COBOLの案件は、新しくプログラムを書く機会がありますか？

ゼロから新しいシステムを作る案件は多くありません。制度対応や商品の追加で、既存のプログラムに機能を足したり、新しいプログラムを追加したりすることはあります。書く時間より、既存のソースを読んで影響を調べる時間のほうが長くなるのが一般的です。

夜間や休日の作業はどのくらいありますか？

リリースや本番の切り替え、障害の対応で、夜間や休日に作業が入ることがあります。頻度は案件と時期によって大きく変わります。参画前に、リリースの頻度と、障害の連絡を受ける当番に入るかどうかを確かめておくと、稼働の見込みとのずれを防げます。

参画して最初の1か月は何をすることが多いですか？

環境への接続や権限の手続き、システムの全体像と業務の流れの把握、ソースやジョブの調べ方の確認から始めるのが一般的です。初月の進め方はCOBOLエンジニアの参画初月にやることで詳しく解説します。