汎用系エンジニア案件の主な仕事内容
汎用系エンジニア案件では、COBOLを中心に基幹系システムの新規開発・機能追加・改修を担当する仕事が多く見られます。基本設計〜テストまでの開発一連に加え、既存ソースの解析や影響範囲調査、不具合修正、リリース対応までを求められるケースもあります。
業務領域は金融（勘定系オンライン、銀行バッチ、口座振替、外為など）や保険（新契約・保全・保険金・人事給与など）が目立ち、業務知識と整合した設計・データ更新が重要になります。オンラインとバッチが混在し、帳票修正やジョブ運用を含めて安定稼働を支える役割を担うこともあります。
開発だけでなく、更改・移行や運用寄りのポジションも一定数あります。z/OSのバージョンアップやH/W更改に伴う設計・構築・移行、ホスト環境からLinux/UNIXなどへのマイグレーションに向けた現行調査・資産整理、全体移行（システム・データ）設計、変換作業や文字コード対応といった、移行特有のタスクが中心になります。
汎用系エンジニア案件で求められる必須スキル
必須スキルの軸は、汎用系環境でのCOBOL実務経験です。基本設計〜テストまでを自走できることが求められやすく、改修中心の案件では既存資産の読解、影響調査、単体テストまでを確実に進められる力が重視されます。保守開発や維持保守では、障害・問い合わせ対応の調査手順を理解していることも重要です。
また、データを扱う場面が多いため、RDBを前提としたSQLの基礎や、DB2などのテーブルを扱った開発経験が必須に寄ることがあります。AS/400系では、RPG（RPGⅢやILE RPG）やCL、AS/400コマンド操作が前提となる案件があり、環境ごとの「当たり前」を押さえているかが応募可否に直結します。
更改・移行系では要件が変わり、JCL/TSO、ShellやLinuxの基本操作、コピー句修正や変換作業、文字コード（EBCDIC/JEF、ASCII/SJISなど）の理解が必須として出てきます。基盤寄りの案件ではz/OSの実務経験や、ネットワーク関連（VTAM/TCPIP/HULFT）のバージョンアップ時の設計・構築経験、IMSの設計・構築といったプロダクト経験が求められます。
歓迎要件・評価されやすい経験
歓迎要件としては、対象ドメインの業務知識が挙がりやすい傾向です。生命保険の保全・保険金・新契約や、銀行の融資・債権管理・決済、預金・振込など、処理の正確性が求められる領域では、用語や業務イベントを理解した上で設計・テスト観点に落とし込める経験が評価されます。
また、大規模資産を前提にした現行調査・リバースエンジニアリング、設計書レビュー、移行計画やテスト計画の作成、移行イベントを含むリリース調整など、開発以外の実務も強みになります。構成管理やアプリケーションリリース、資材配布といった運用寄りの経験も、保守開発の現場では価値が出やすいです。
モダナイズや周辺技術に触れていることもプラスに働きます。例として、ホストからオープン系への移行に関連してLinux/UNIXの知識やShell、ETL/BI連携の検証、将来のリライトを見据えたJavaなどの理解が歓迎されるケースがあります。基盤更改では、リード経験やベンダー・チーム間調整の経験が評価に繋がりやすいです。
開発環境・技術スタックの見方
汎用系案件の環境は大きく、メインフレーム（IBM z/OS等）とAS/400（IBM i）に分かれて記載されることが多いです。COBOLが共通言語でも、前者はJCL/TSOやCICS、DB2、IMSなどが絡み、後者はRPG/ILE RPG、CL、DB2 for i、QRY、AS/400コマンド操作が前提になるなど、必要な周辺知識が変わります。
データベースはDB2の登場頻度が高く、テーブル定義やデータ操作を伴うため、SQLを書けるだけでなく「業務データをどう更新・検証するか」を理解していると立ち上がりが早くなります。一部ではHiRDB、OracleDB、PostgreSQLなども見られ、ホストだけで閉じない構成（Linux/UNIX連携）を想定した案件もあります。
更改・移行を含む案件では、OSとしてLinux/UNIX、スクリプトとしてShellが併記されることがあります。この場合、バッチやジョブの移行、データ変換、性能検証など「移行手順の再現性」が重要になるため、運用・テストの観点で何を確認すべきかを理解していると動きやすいです。ツール面ではBacklog、Redmine、SVN/Git/GitHub、Slack、Office系でのドキュメント整備が求められることもあります。
参画前に確認したいポイント
まず、担当範囲が「アプリ開発」か「更改・移行」か「運用保守/技術支援」かを切り分けて確認するとミスマッチを減らせます。開発でも、要件定義から入るのか、基本設計以降なのか、製造〜テスト中心なのかで求められる動き方が変わり、必要なドキュメント作成量や調整範囲も変化します。
次に、対象プラットフォームと周辺技術の前提をすり合わせます。z/OS案件ならCICS/DB2/IMSやネットワーク（VTAM/TCPIP/HULFT）、AS/400案件ならRPG/CL/コマンド操作、移行案件ならJCL/TSOやShell、文字コード対応など、求人票に明記されがちな要素が自分の経験と合致しているかを確認してください。
最後に、既存資産の扱い方と品質担保の進め方を把握することが重要です。既存ソース解析や影響調査が中心か、プログラム本数や改修粒度はどの程度か、テスト計画の作成まで求められるか、本番リリース・移行イベントにどこまで関与するかを事前に確認すると、期待値のズレを抑えた参画判断がしやすくなります。