運営者のAS400実務経験

AS400現場ノートの作者です。2000年から、AS400 / IBM iを使う業務システムの開発・保守を続けています。

いちばん長く担当してきたのは、卸売・小売・アパレルなどの販売管理システムです。プログラムを作るだけでなく、受注から出荷、売上、請求まで、仕事の流れを見ながら調査や改修を行ってきました。

現在も2社の開発・保守を担当し、日々の仕事でCodexを使っています。このブログと法人向け研修では、現場で身につけてきた「調べ方・直し方・確かめ方」を伝えています。

これまで担当してきた仕事

AS400との出会いは、2000年に入社した開発会社でした。学生時代は名前も知らず、入社後のRPG研修から学び始めました。

その後は流通業の販売管理を中心に、物流や不動産関連のシステムにも携わってきました。新しいシステムを作る仕事も、長年使われているシステムを直しながら支える仕事も経験しています。

主に扱ってきた技術はRPG、CL、SQLです。販売管理の中だけでなく、会計システムや外部システムとのデータ連携も担当してきました。

長く担当しているシステムでは、プログラムの動きとお客様の業務を結びつけて考えられることが、自分の強みだと感じています。

たとえば、出荷処理を変更するときは、そのプログラムだけでなく、在庫、売上、請求、外部へのデータ連携にどう影響するかも確認します。ソースだけでは分からないことは、処理の記録であるジョブログや、データ、帳票を見ながら調べます。

「どこを直すか」だけでなく、「直した結果、ほかの仕事に何が起きるか」まで考える。開発でも保守でも、この見方を大切にしています。

この考え方は、業務理解が設計に必要な理由でも紹介しています。

現在担当している2社の案件では、追加・変更開発にも日々の保守にもCodexを使っています。

たとえば、古い設計書と実際の動きが合わないときは、Codexにソースを解析してもらい、プログラムが今どのような処理をしているかを調べています。ソースの読解だけでなく、変更箇所の検討やテストの準備にも活用しています。

ただし、Codexの回答だけで正しいと決めるわけではありません。元のソースや業務の流れと照らし合わせ、実行結果を確かめます。顧客情報を守り、社内ルールに沿って使うことが前提です。

夜間バッチの停止や、ジョブが応答待ちになるトラブルにも対応してきました。こうした場面では、すぐに操作するより、まず次の順番で状況を整理します。

分かっている事実と、まだ分からないことを分けて伝えることも大切です。一人で抱え込まず、業務への影響と確認できた内容を共有し、必要な判断につなげます。

具体的な確認の進め方は、次の記事にまとめています。

若手に教えるときは、まずシステム全体図や、周辺システムとのつながりが分かる図を見せるようにしています。最初から全部覚える必要はありません。「今見ているプログラムは、何の仕事に使われているのか」をつかむところから始めます。

そのうえで、ソースの読み方、調査する順番、変更した後に確認することを、一つずつ伝えていきます。コマンドや文法だけでなく、分からないことを整理して質問する力も、現場では役立ちます。

法人向けのCodex研修でも、講師の実演を見るだけでなく、参加者自身が手を動かし、ソースを調べ、作成・改修し、結果を確かめるところまでを大切にしています。

入社したころから「AS400は古い」と言われることはありました。それでも、長年の開発・保守を通じて、企業の日々の仕事を支えているシステムだと実感しています。

だからこそ、これから関わる人が、古い画面や専門用語だけで苦手意識を持たずに学べる場所を作りたいと思っています。現場で困ったこと、調べたこと、判断に迷ったことを、このブログにまとめています。

記事では顧客名や機密情報を伏せ、実務経験をもとに説明しています。実際の本番作業は、所属組織のルール・権限・承認手順に従ってください。

保守や今後の運用を考える方には、次の記事も用意しています。