AS/400・IBM iの案件を探すと、「運用保守」という同じ言葉でも、担当する仕事には幅があります。定常作業や障害調査が中心なのか、利用者の要望を聞いてRPGの改修まで行うのか。案件名だけで判断すると、経験とのずれが生まれます。
LegacyForceの掲載案件を二つ比べると、その違いが見えてきます。自分の経験をどの募集に結びつけるか、応募前の確認に使ってください。
同じIBM iでも、二つの募集はここが違う
| 比較する点 | 食品業界の維持管理・運用 | 商社の運用保守・開発 |
|---|---|---|
| 掲載されている仕事 | 保守リリース、障害調査、月次IPL、ユーザー申請対応、データ抽出 | ユーザーとの要件確認から設計、開発、テスト、運用保守まで |
| 求める経験 | RPG開発、IBM i運用、基本設計以降の自立した対応 | RPGで上流から下流まで自立して対応した経験 |
| 応募前に掘り下げたい点 | 定常作業と障害対応の分担、作業時間、承認の流れ | 要件を決める相手、改修規模、設計・レビューの分担 |
出典：食品業界向け案件、商社向け案件。上表の「応募前に掘り下げたい点」は、募集内容を読んで編集部が整理した確認事項です。
前者にもRPG開発経験が求められ、後者にも運用保守が含まれています。「運用なら開発経験は不要」「開発ならリリース後の対応はしない」と区切れる募集ではありません。
なお、月次IPLの記載だけで、休日や夜間の勤務があると決めつけることはできません。作業日時、立ち会いの必要性、代休や精算の扱いを個別に確認します。
登録エンジニアの経験：利用者に見てもらい、違うところを直す
LegacyForceに登録するAS/400技術者は、基幹システムの保守開発について、RPGの調査から改修、単体テスト、利用者による確認までの流れを説明してくれました。
登録エンジニアのコメント（発言要旨）
RPGを調査して改修し、単体テストまで行ったものをユーザーに見てもらっていました。そこで違うところがあるとフィードバックをもらい、また直す、という作業です。
この方が語っていたのは、完成した仕様に沿ってコードを書くだけの仕事ではありません。既存の処理を調べ、変更し、利用者に確認してもらうところまでが、一続きの担当業務でした。
さらに、次に希望する仕事についても、AS/400で手を動かす仕事を続けたいと話し、担当したい範囲を詳細設計からリリースまでと説明しています。長い経験があることと、管理や要件定義を中心に働きたいことは、同じではありません。
LegacyForceの見方
この話から、私たちが案件との照合で確かめたいのは、「RPGを書けるか」に加えて、既存処理の調査や利用者との確認までを担当してきたか、そして次もその役割を希望するかです。経験豊富だから上流工程、という当てはめ方では、ご本人が続けたい仕事を取りこぼします。
今回の掲載案件と、この登録者が経験した現場は別です。実例にある改修・利用者確認の経験と、募集で求められている運用作業や設計範囲を、一つずつ照らし合わせることが大切です。
経験を整理するときは「作業」「調査」「判断」を分ける
「運用を担当していました」という説明には、手順書に沿った作業から、障害の原因調査、復旧方法の判断まで含まれ得ます。応募先が知りたいのは、その中のどこを任せられるかです。
作業を担当した経験
定められた手順で実施した作業について、実行前の確認、結果確認、異常時の連絡先まで説明します。「実行した」だけでなく、どの状態を正常と判断していたかが分かると具体的です。
調査を担当した経験
障害や問い合わせに対し、何を確認して原因の候補を絞ったかを振り返ります。プログラム、処理結果、データ、ジョブの実行状況など、自分が実際に調べた対象を書きます。調査結果を開発担当へ渡したのか、自分で改修まで進めたのかも区別します。
判断・調整を担当した経験
再実行の可否、変更の承認、利用部門への説明を誰が担当していたかを整理します。自分が承認者ではなかった場合も、判断材料をまとめていた経験は説明できます。権限がなかった部分を、担当したように広げる必要はありません。
RPG・CL・DDSは、使った場面まで確認する
RPG、CL、DDSなどの名称を並べるだけでは、担当範囲は伝わりません。ソースを読んだ、既存資産を修正した、新規に作成した、レビューした、という違いがあります。
例えばRPGの改修経験があっても、バッチ処理の呼び出し部分は別の担当者が管理していたかもしれません。その場合は、RPGの変更範囲と、周辺処理をどこまで確認したかを書き分けます。
今回比較した二つの案件では、CL・DDSが個別の必須条件として明記されているわけではありません。「IBM i案件なら全員必須」と読み替えず、対象資産と期待する担当範囲を確認してください。言語や画面定義の形式についても、募集ページの大まかな環境表記だけで判断せず、実際に扱う形式を尋ねます。
障害対応の経験を説明するためのメモ
実際の経験を、次の五つに分けて一件書き出してみてください。顧客名や具体的なデータは不要です。
何が起きたか：どの業務の、どの処理が止まった・ずれたのか。
最初に何を確認したか：実行結果、入力、変更履歴など。
自分はどこまで調べたか：原因特定までか、切り分けて引き渡したか。
誰が対応を決めたか：承認者と、自分が用意した判断材料。
対応後に何を確認したか：処理結果、後続業務、再発を防ぐ変更。
「障害対応経験あり」の一行よりも、この説明の方が案件との相性を検討しやすくなります。件数や改善効果を覚えていなくても、無理に数字を置く必要はありません。
応募前に、担当範囲と勤務条件を一緒に確認する
募集で「一人称で対応」とされていても、すべての仕事を一人で担う意味とは限りません。チーム体制、相談先、レビュー、承認の仕組みを確認します。
監視・定常作業と、改修・障害調査の担当は分かれているか。
夜間・休日作業、待機、緊急連絡はあるか。ある場合の頻度と条件はどうか。
本番作業の承認者と、実施する担当者は誰か。
アプリケーション、OS、機器のどこまでが担当範囲か。
利用部門への説明や問い合わせ対応を、どの程度任されるか。
LegacyForce編集部が重視したいのは、長年の経験を「運用保守」の一語にまとめないことです。利用者の業務を知り、調べ、変更の影響を確かめてきた経験は、具体的な作業として示すことで伝わります。
AS/400・IBM iの案件を見る ／ RPGの案件を見る
経歴書への落とし込みは、AS/400・RPGのスキルシートの書き方で扱っています。経験を登録して相談する際にも、得意な作業と希望する担当範囲を分けて伝えてください。
