COBOLエンジニアの参画初月にやること｜現場で信頼される進め方

COBOLエンジニアの参画初月は、環境とジョブの流れ、担当業務の現行の仕組み、現場の手順と持ち出しのルールをつかみ、月末までに最初の改修か調査を現場の手順どおりに終えるところまでを目標にします。最初の1か月で求められるのは、作業の量より、この人に現行のシステムを触らせて大丈夫だと現場が判断できる材料を示すことです。

参画前の契約・環境の準備は参画が決まってから開始日までにやること、職種を問わない最初の1週間の進め方は参画初日から最初の1週間でやることで解説しています。この記事では、COBOLならではの初月の動き方に絞ります。

初月のゴールを3つに分ける

この3つを、1週目、2週目、3〜4週目の順に重心を移しながら進めます。

1週目：環境とルールを押さえる

最初に確かめること

COBOLの現場は、閉じたネットワークや専用の端末で作業することが多く、最初の数日で確かめることが多くあります。

1. 端末と権限：どの環境に入れるか、本番に近い環境への権限はあるか
2. 持ち出しのルール：ソース、設計書、データをどこまで手元で扱えるか、メモの取り方に決まりはあるか
3. ソースの管理：ソースの取り出しと戻しの手順、変更の履歴の残し方
4. レビューと承認：誰がレビューし、誰がリリースを承認するか
5. 連絡と勤務の時間：連絡のつく時間、夜間・休日の作業の有無

持ち出しのルールは、案件ごとに違います。迷ったら聞いてから動いてください。守秘義務の考え方は秘密保持契約の記事で扱っています。リモートの日がある案件では、リモートでできる作業と現地でしかできない作業の線も、この時期に確かめておきます。傾向はCOBOLのリモート案件の記事をご覧ください。

資料を読む順番

環境の説明を受けたら、担当業務の資料を次の順で読むと全体をつかみやすくなります。

1. システムの全体図と業務の流れ：どの業務がどのサブシステムで動いているか
2. ジョブの流れ図：夜間バッチの順序、主なファイルの入出力
3. 共通部品とレコード定義：よく使われるCOPY句や共通のサブプログラム
4. 直近の改修の記録と障害の記録：最近どこを直し、どこで問題が起きたか

設計書と実装が合っていない部分があることを前提に、気づいた点は仮説としてメモに残しておきます。引き継ぎを受けるときの進め方は引き継ぎの記事で整理しています。

2週目：現行の仕組みを自分の手で確かめる

ソースとジョブを追う

2週目には、資料で読んだ内容を、ソースとジョブの定義で確かめていきます。担当範囲の主なジョブを一つ選び、どのプログラムがどのファイルを読み書きしているかを自分で追うと、環境の書き方と現行の作りが同時に分かります。

小さな作業で手順を通す

テスト環境でのジョブの実行、ソースの取り出しと戻し、レビューの依頼など、現場の手順を小さな作業で一度通しておきます。手順を一通り経験しておくと、最初の改修で手順の確認に時間を取られずに済みます。

分からないことはまとめて聞く

分からないことが出るたびに聞くと、相手の作業を細かく止めてしまいます。調べた範囲と分からない点を分けて書き出し、まとめて聞く時間を窓口にもらうと、相手の負担を減らしつつ確かめられます。

3〜4週目：最初の改修か調査を手順どおりに終える

影響範囲を自分で洗い出す

最初に任される作業が小さな改修でも、影響範囲は自分で洗い出します。変更する項目やファイルを使っているプログラム、ジョブ、帳票を、設計書だけでなくソースとジョブの定義を検索して確かめ、調べた範囲を一覧にしてレビューに出します。

テストの観点と結果を残す

変更した部分だけでなく、影響を受ける既存の処理が変わっていないことを確かめる観点を作り、結果を記録します。数値の桁や端数の処理、文字コードの違いなど、ずれが出やすい箇所は観点に入れておきます。

気づいた注意点を共有する

作業の過程で、設計書と実装が違う箇所や、手順書にない注意点が見つかることがあります。それを一覧にして共有すると、自分の理解の深さを示せるだけでなく、チームの資料の整備にも役立ちます。

案件の型によって初月の重心は変わる

保守の案件

日常の保守では、改修と障害対応の手順を早く身につけることが中心です。夜間バッチの異常終了時の連絡の流れ、再実行を判断する人、本番の確認の手順を初月のうちに確かめておくと、当番に入ったときに慌てずに済みます。

制度対応・大規模改修の案件

期限が決まった改修では、初月から影響調査の一部を任されることがあります。チームの調査の観点や一覧の書式に合わせ、自分の担当範囲の調査を漏れなく仕上げることを優先します。

移行の案件

移行の案件では、現行分析や現新比較など、どの工程から入るかで初月の動きが変わります。現行の側に入るなら担当範囲のジョブとファイルの構成を、検証に入るなら比較の手順と差分の記録の仕方を、最初に押さえます。移行の時期によって働き方が変わることもあるため、今後の工程の予定も確かめておきます。

初月に避けたい動き

範囲外の依頼が増えてきたときの扱いは業務範囲が変わったときの記事、COBOLのフリーランスがつまずきやすい場面はCOBOLエンジニアのフリーランスがつまずきやすい点と対策で整理しています。

1か月の終わりに振り返ること

1か月が過ぎたら、次の点を自分で振り返ります。

• 担当範囲の主なジョブとファイルのつながりを、自分の言葉で説明できるか
• 現場の手順（ソースの管理、レビュー、リリース）を一通り経験したか
• 持ち出しのルールと、リモートでできる作業の線が分かっているか
• 契約で決めた業務の範囲と、実際に担っている仕事がずれていないか
• 夜間・休日の作業を含め、稼働時間の記録が残っているか

ずれている点があれば、2か月目の早い段階で窓口と話しておきます。

よくある質問

設計書がほとんど残っていない現場です。何から始めればよいですか？

担当範囲の主なジョブを一つ選び、ジョブの定義からプログラムとファイルのつながりを自分で追うところから始めるのが近道です。追った結果をメモにまとめておくと、自分の理解が進むだけでなく、チームの資料にもなります。設計書がない状態そのものも、窓口に共有しておくとよいでしょう。

初月から本番の障害対応に入ることになったら、どうすればよいですか？

まずは現場の手順と、判断する人を確かめます。自分の役割は、ログやリターンコードから原因の見立てを出し、取れる手の選択肢を示すことだと考え、再実行などの判断は責任者に委ねます。分からない点は分からないと伝えるほうが、後で信頼を損ないません。

1か月たっても全体像がつかめません。どうすればよいですか？

大規模な基幹系では、1か月で全体をつかみきれないこともあります。その場合は、分かっている範囲と分かっていない範囲を分けて窓口に伝え、残りをいつまでに確かめるかの予定を示してください。担当範囲を正しく扱えていれば、全体を知らないこと自体が問題になることは多くありません。