メインフレームシステムを支える要員の育成について

By 岡田 - Posted: 2013/07/29 Last updated: 2016/12/04 - 2 Comments
印刷用ページの表示 印刷用ページの表示
私がエンジニアになった当初、サーバは無く一部で16ビットのパソコンの仕事はありましたが、多くの人がメインフレームに関わる仕事をしていました

私が最初に携わったメインフレームシステムは、現在主流と私が感じている膨大なデータを安全・安定に管理・運用するデータベースコンピュータとは異なり、人が要求した事について迅速・的確に計算結果を求める純粋なカリキュラマシーンでした。

そのため、早い処理結果が常に求められ、毎年のように新機能を導入したり、最新のCPU・OSに引き上げるためにCPU更改やOSのバージョンアップ作業を行ってきました。その結果、私は日立のVOS3を生成・構築するスキルが養われました。

時代は流れ、私が担当していたカリキュラマシーンはパソコンにダウンサイジングされシステム自体無くなりました。
そして、データベースコンピュータが業界の殆どを占める状態となり、安全・安定がコンセプトのため『触らぬ神に祟りなし』のように、保守期限ギリギリまでOSのバージョンアップを行わないシステムや、セキュリティ強化・コンプライアンス遵守のために保守要員でありながら、マシンを触れさせる事ができなくなっている冷戦時代のような印象を受けております

冷戦時代しか経験していない要員は突発的なトラブルに対処することができないと言うのが私の感想です

私が現在働いているサイトにも冷戦時代しか経験していない要員がいます。この要員を見ていると、手順書なしに、私がお願いした要求に答えるために投入したTSSのコマンドの一つが、コマンドとオペランドの間にスペースを入れるという、ごく当たり前のことが解っていなくて、コマンド自体が失敗していたのが解らずに、三つ後に、自分が期待した動作にならないことに(ようやく)気づいて、原因調査をしている状態です。

トラブル対処と言えば、”システムの障害回復訓練”ですが、定期的に実施しているサイトは少なく、行っているとしても期(六ヶ月)に一度あれば贅沢な方です。そんな六ヶ月に一度の、しかも障害回復手順書でオペレーションが固められていては、手順書に書かれた通りにシステムが応答した場合にしか対応できない頭カッチカッチの要員しか育ちません


二極化の記事で少し触れていますが、JCLをXML化してサーバでも同様な処理ができるようにするサービスが出てきました。日々のマシン費用が重荷になっている企業はどんどんダウンサイジングして行くことと思います

しかし、どんな形でメインフレームの業務がダウンサイジングしたとしても求められる要員は手順書に従って、マリオネットのように動く要員ではなくて、どんなトラブルにも迅速に対処できる人材のはず。マリオネットのような要員が必要なのであれば、VOS3ですとAOMPLUSに該当するのですが、コンソールメッセージに対してアクションを作りこんでおくような”自動化”をしてしまえばいいのです。

私が一時期、失業状態にあり、就職口を探していた時、メインフレームのオペレータを派遣している企業の面接を受けました。面接官はマネージャクラスの人でしたが、そこの企業では、トラブルが発生しても現場の人間に対策をさせずに、エスカレーションをして、上からの指示通りに動くように求められていました。そこの企業は離職率が高いことを後から知りました。マリオネットのように使われる事で、自分の目標を失い、精神疾患に陥るのだそうです。

コンピュータの応答内容に100%対処できる(人が作りし)手順書なんてあり得ないです

顧客自身が自分たちのシステムを支える要員を、抱えているシステムで育てることができないのであれば、今後必要である要員の育成をどこの環境で育てるつもりなのでしょうか?

今、突発的なトラブルにも迅速に働ける要員は、セキュリティ強化やコンプライアンス遵守が厳しくなる前に叩き上げで頭の中に経験を積んできた人材に他なりません。でもそのような人材も定年になれば、他の人に席を譲らなければなりません。バトンタッチ出来る人が現れるのでしょうか?

業界あげて、会社間の縦割りを取っ払って、取り組むべき問題と考えます

少なくても、IBM(MVS)互換をうたっているマシン要員については、IBM?富士通?日立の三社間で連携をとって、訓練環境の創設、共通用語辞書の作成などといったインフラ環境の整備に努める事が必要となっていくと考えます

IBMではエミュレータがあり、そこでOSレベルの訓練はできるとおもいます。
しかし日立にはそのようなエミュレータはありません。昔顧客から、求められたこともありましたが、、、
Posted in つぶやき・雑感 • • Top Of Page

2 Responses to “メインフレームシステムを支える要員の育成について”

Comment from 野良猫
Time 2013年7月30日 at 00:51

まさにその通りだと思います。

現場で、障害が発生しているのに、対応と言えば、担当者へ連絡をして指示を待つだけですからネ。

また、作業も手順書が無いと何もできない状態に成ってしまっています。挙句に、手順書が納品物扱いになっているところも多々ありますからネ。

真の納品物は、システムではないのかと毎回思うのですが、その事を言うと?が頭にあるようです。

Comment from okada
Time 2013年7月30日 at 01:21

野良猫さん、レスありがとうござます。

この業界に入った時に新人がする恒例の作業は「マニュアル読み」でした。
分厚いマニュアルが何十冊もあったのです。
催眠術のように必ず眠くなりました

現代ではCD?ROM化されていて、WEBで見ることができるようになりましたが、私がマニュアル読みをした当初、マニュアル自体貴重なものだったので、付箋や書き込みをすることが許されませんでした。

そして、現場作業でマニュアル読みをした成果を試されたのです。


マニュアルの一字一句を覚える必要はなくて、「ここの部分にこんな記述があったな」というイメージをたくさん頭の中に入れておいて、あとで必要となった情報を引き出すために、マニュアル読みをさせられていたのです


そのような作業を積み重ねて、手順書や納品物には残せない「システムから伝わる感覚」を現場に駐在するベンダーSEであった私は吸収して、他のサイトにも応用していきました。

「ここのサイトはNUCLEUSのパンクが頻繁に発生するから、コンデンスを毎回作業時に行う必要がある」とか、「特定のジョブ名のスプール占有率が高いから、スプールのパンクに気をつける」などです

私がメインフレームのエンジニアとして働き出して8年から9年後に会社の方針で派遣社員を入れる事が決まって、入ってきました。
他のサイトでオペレータの経験を積んできた人が殆どだったのですが、彼らはまさに、現場でたたき上げられて育った人間ではなかったので、私が感じてきた”システムから発する感覚”を受け止めることができず、部下として使うのにとても苦労しました。

正直、私たちと彼ら(オペレータ育ちの派遣社員)には最後まで、見えない壁がありました。とても、私の後任として任せる事はできませんでした。


昔に比べて、科学技術の進歩などでMTBF(平均故障間隔)は長くなっていますが、MTTR(平均回復時間)の維持には必ずトラブルに対処できる保守要員が欠かせません。
たたき上げの世代が定年になったら、確実にMTTRは伸びるでしょう。

そして、メインフレームシステム自体の信頼を失って、業態全体の縮小に拍車がかかることを私は懸念しています