目次

初めての基幹システム

「2000年問題」と「昭和100年問題」

金曜日定時前の悲劇

「10進数データ・エラー」の謎

流通全体での実務経験が、その後のキャリアの武器に

初めての基幹システム

私のキャリアの原点は、コンビニ子会社での基幹系システムの運用オペレーター業務でした。
2000年3月卒業、4月入社を目指しての就職活動は、氷河期のど真ん中。
コンピューター関連で就職先を探す中で、私は友人から「情報システムの子会社がある親会社を狙おう」という作戦を聞き、自分もマネをして無事にコンビニ本体へ就職。入社から9か月間の新入社員研修期間を経てから狙い通りに情報システム子会社へ出向となり、私のシステム管理者の道が始まりました。

そのコンビニ会社では基幹システムとしてIBMのオフコンであるIBM iを使用しており、オペレーターとして一番初めに覚えたコマンドは「WRKACTJOB」でした。これはWindowsのタスクマネージャーの様な画面を呼び出すコマンドで、ジョブ（Windowsでのプロセスに近い）の稼働状況等を確認したりジョブを終了させたりすることもできます。そして二番目に覚えたのが「PWRDWNSYS」コマンドでした。
このコマンドを知らない方でも、文字列からなんとなく不穏な響きを感じた方はセンスがあります。是非IBM iの世界に入りましょう。
「PWRDWNSYS」はシステムを落とすコマンドです。間違って実行するとシステムがダウンしてグループを含めた全体に影響が…出ますが、当時IBM iは本社、各配送センター、地方拠点などと分散処理での配置をしていたので、実際に影響を受ける範囲は限定的です。
とはいえ本当に本社のIBM iを落としてしまったら会社の外線/内線電話が鳴りやまなくなるのは確定しています。
このままIBM iのコマンド解説講座としてしまっても良いのですが、100回まで連載しても終わりませんので残念ながら割愛します。
IBM iのコマンド体系はWRKやDSP等の動詞から始まり、そのシステムの思想などが現れていて面白いので、興味がある方は是非調べてみてください。

「2000年問題」と「昭和100年問題」

「2000年問題」を記憶されている方は多いと思いますが、私はぎりぎりで2000年問題を避けてからの2000年4月入社でしたので、対応の苦労は経験していません。しかし、私が現場で直面したのは「昭和100年問題」でした。年号を2桁で扱うという設計判断がその後、長期間にわたり運用を縛り続けていたのです。

IBM iにはジョブスケジューラー（当時はAUTO/400と呼ばれていた）が導入されていましたので、各種バッチ処理では指定時間や先行ジョブに応じてジョブが自動実行され、オペレーターとしてはジョブが投入された事、異常終了せずに実行完了した事などをチェックし記録に残していました。
コンビニ店舗からの受注データを取りまとめて件数を確認し、メーカーへの発注処理の稼働を確認したり、POSレジの商品マスターの送信、店舗別の販促情報の処理、店舗の売上データを元に社長宛に日次決算の帳票（ラインプリンタでストックフォームに印刷）を届けたりなど、流通の仕組みや店舗からのデータの流れ、経営の仕組みを覚えながらのオペレーター業務でした。
その他のオペレーター業務の一つとして各部署からの依頼や定型業務としてメニューからジョブを手動で投入する事がありました。
いつの日付のデータとして処理をするのかという営業日を入力して実行するジョブがあります。その際にメニューからは和暦2桁と月日4桁を合わせて6桁で処理日を指定して実行するジョブがありました。
当時はすでに平成12年でしたが昭和75年に相当するので、今日が12月10日だとすると営業日を「751210」と入力して実行します。
これは昭和から平成へ遷移した際にプログラム改修を行っていないからなのですが、和暦であれば2000年問題は避けられますね。しかしこのプログラムでは昭和100年問題が発生します。換算すると昨年が昭和100年に相当します。
さすがに実際に昭和100年となり桁あふれ（オーバーフロー）で00となり、運用に支障がでた会社の話は世間でも聞きませんでしたが、当時は「2000年問題ってこういう事なんだなぁ」と実感をもって理解した社会人１年生でした。

金曜日定時前の悲劇

さて、その後順調にオペレーター業務を身に着け、先輩の助けがなくても一日のオペレーター業務を回せるようになった社会人2年目。待望の後輩が配属され、先輩は本業のプログラム開発に戻りました。今度は私が後輩を育成する役割となり、運用の改善にも手を付けることになったのです。

少し前に触れた「PWRDWNSYS」コマンドは、システムの安定性のために毎週金曜日の定型業務が終わった後、最後に実行するタスクでした。（IBM iには再起動まで開放されないリソースがあり、数年間起動を続けるとジョブが投入できない（プログラムが開始されない）事象が発生するのと、不要なセッションを切断する目的で毎週再起動をしていました。）

誰もが金曜日の夜を待ちわびる定時間際の時刻、「今日も処理は無事に終えた。飲みに（職場から歩いて5分で繁華街に行けた）行こうかな」なんて思っていると、PWRDWNSYS後に電源投入しても、IBM iがうんともすんとも言わず立ち上がって来ません。

トラブルは突然に来るものです。すぐに保守サポートに連絡しCE（カスタマーエンジニア）さんに来ていただきましたが、部品交換が必要となり、その時間からの対応では当日中の対応が完了せず、復旧は土曜日までかかることとなりました。

先輩が居たのならば先輩はきっと「先に帰っていいよ」と言ってくれたと思いますが、今は私が先輩です。後輩に「後の対応はするから先に帰っていいよ」と心では泣きながら顔は笑顔で後輩を帰しました。

その反省から、復旧までの時間を少しでも短くするとともに、夜間にわたる対応の負担を減らすため、「マシンの再起動は木曜日に昼過ぎに行う」というルールに変更されました。
小さな変更ですが、これはのちの私が災害対策（DR）の販売やセキュリティ製品の開発に関わる際のリスク管理の原点となりました。

「10進数データ・エラー」の謎

その後、後輩も独り立ちした頃、オペレーター業務のメイン担当を後輩に任せて私もプログラミングを兼任するようになりました。当時の基幹系システムはCOBOLとCL（WindowsのBATファイルの様にコマンドの集合）で構成されていました。私にとってプログラムを利用する側から、プログラムを提供する側になった瞬間です。
10進数データ・エラーは、IBM iの開発経験者には見慣れたエラーかもしれません。
IBM iのCOBOLでは数値データを厳密に扱うため、数値項目として定義された領域に、スペースなど数値以外の値が混じると、計算を実行した瞬間に「10進数データ・エラー」としてプログラムがアベンド（異常終了）します。
しかしオペレーター時代の私には、システムが機械的に処理しているはずのデータの中に、なぜ仕様外の値が混じり、その結果として「システムが止まる」のか、まったく理解できませんでした。
原因としては多々ありますが、商品部が入力している商品マスターに不備があるなど、手作業が原因で処理が止まる事は実際の業務を経験してみないとわからない事でした。

開発と運用はセットですが、私はオペレーターとして毎日見ていた受発注処理のバッチプログラム、メーカーへの送信が間に合わない、10進数データ・エラーでプログラムの処理が止まる。こうした運用についての理解があるからこそ、「なぜ運用でエラーの時に処理を止めるのか」「異常値が来てもプログラムをどうするべきか」スキップで良いのか、データを修正して再処理しないと発注データの欠落で店舗への納品が欠品となるのか等の、運用前提の設計の意図を理解して学ぶことができました。

また、情報システム子会社の役割で、オフィス内や配送センターだけではなく、「店舗の現場」にも行きます。私にとって忘れられないのは、店舗でのレジ交換作業です。POSレジも機械ですので稀に故障するため、お客様との接点となる機械を前に、POSレジの重要性や止まる事の影響を理解しました。
ポータブル端末でレジ打ちができるシステムがあるため、レジが故障時のバックアップがある事に何度か助けられたこともあります。POSレジ故障時のバックアップシステムの大切さはこの時に肌で感じることができました。

当時、私が漠然と考えていたのは、「このままプログラムを書き、レジシステムや本部システムに関わっていくのだろう」ということでした。まさか、その後、セキュリティ製品の開発や新事業立ち上げといった、技術とビジネスの境界線を何度も越えるキャリアを歩むことになるとは、夢にも思っていませんでした。

流通全体での実務経験が、その後のキャリアの武器に

このコンビニ子会社でのキャリアとしては身に着けた事は多いですが、一番の成果はPOSレジからの販売データや発注用のポータブル端末からの発注データが、本部でどのように取りまとめられ、メーカーとの連携だけでなく、配送センターでピッキングリストを作成し現場でのピッキング作業や、配送から納品・検品・返品・棚卸など、流通システム全体を実作業として経験し身に着けることができた点にあります。このシステム全体の流れを知る体験が後のキャリアの土台になりました。

次回は、現場での経験しか持たなかった私が、偶然の転職をきっかけに、開発・導入・営業・ガバナンスまでを担う立場へと引き込まれていった、その始まりを振り返ります。