![IT IT](https://srad.jp/static/topics/it_64.png)
メインフレーム技術者不足、問題に 116
タレコミ by AAC
AAC 曰く、
日経ITproの記事によると、国内でのメインフレーム技術者不足が問題になっているそうだ。
日本は海外に比べてメインフレームの導入数が多く、いまでも出荷金額ベースで国内サーバー市場の4分の1ものシェアを占めているそうだ。しかし、メインフレームに精通した技術者は60歳の定年を迎え始めており、技術者の不足が顕在化してきたとのこと。
ベンダーは、定年後の再雇用で技術者不足を補おうとしていたが、「体力的にきつい」や「給与が下がる」ために多くの技術者が再雇用に応じなかったそうだ。またメインフレームは枯れた技術であるため、興味を持つ若手が少なく育成が難しいとのこと。メインフレームができる派遣技術者の数も減っているということで、この問題の解決は難しいようだ。
企業側の努力が足りない。 (スコア:5, すばらしい洞察)
労働を緩和して、給料を上げればいいだけ。
企業側にその気があればやっているはず。
Re:企業側の努力が足りない。 (スコア:5, すばらしい洞察)
コスト関数に必要な要素が含まれていないとよい解は得られない (スコア:2, すばらしい洞察)
そういう技術革新への追随コストは本来必要経費なので給料に載せるか、組織的に教育するかするかして
キチンと 更新コストとして存在を意識するのが経済システム的には正しいと思う。
ところがそういうコストを社会的には存在しないことにして労働者の「自己責任」にしちゃうあたり経営としてはどうかと思うけどね。
このへんの教育コストは別に技術系に限った話ではない、
実は世の中の仕組みや経済的情勢も結構変わるから生涯学習が必要なのはすべての業種について言える。
あるいは文系職種(特にお役所)でよくある「ジェネラリスト養成」とかいって各部署をくるくるまわして結局どこの仕事もモノにならないとか、
常時「今勉強中でしてw」が当たり前になっちゃってるのとかも本質は同じで、やっぱり教育・学習コストを無視することに原因がある。
コスト関数に必要な要素が含まれていないとよい解は得られないのはコンピュータ・システムも社会システムも同じ。
Re:企業側の努力が足りない。 (スコア:5, すばらしい洞察)
# セレブは消え去り、成金だけが残ったんだなぁ
Re:企業側の努力が足りない。 (スコア:4, すばらしい洞察)
左様、メインフレームを維持する事への意欲が薄い、プライオリティが低いワケで、
企業側にその気が無くなり、フェードアウトしつつあると言う事ですね。
そんな事はない、必要だから不足が問題になるんだ、と仰る方も居るかも知れませんが、
少なくとも経営者、と言うか金銭的な決定権を持つレベルの人は、
そう思ってないと言う事が現れてるわけで、
Re:企業側の努力が足りない。 (スコア:2, 興味深い)
その意見は逆に決定権を持つ人間を信頼しすぎでは?
現場では共通認識でも上に情報が上がってかないのはわりと常態のような気がします。
顧客側の努力が足りない。 (スコア:4, すばらしい洞察)
相応のコストを負担する必要がある。
今まで安かったんだから、これからも安い筈だという考えでは、
パートナーとして付き合ってくれる会社が無くなるでしょう。
答えはある。それを見つける能力が無いだけだ。
昔のメインフレームと今のメインフレームは違う (スコア:3, 参考になる)
NECの例を出すといまや
ACOS-2はXeon(Intel)
ACOS-4はItanimu(Intel)
ACOS-6はオリジナルのCMOSプロセッサらしい
メインフレームたるメインの「フレーム」も昔のオフコン程度の小ささです
(もちろん水冷なんて過去のものになってる)
Re:昔のメインフレームと今のメインフレームは違う (スコア:2, 興味深い)
Re:顧客側の努力が足りない。 (スコア:3, すばらしい洞察)
「求人希望の人材が来る迄、条件をアップしろ。」
でオシマイですね。
不人気な職種なんだったら単に他の条件で人気の有る職場にすれば良いだけ。
業務内容の人気不人気なんぞ関係ない。
でもって、一番手っ取り早いのはやっぱり給与でしょうから。
他にも勤務条件とかで人気を上げる事は出来るでしょうし、なんなら立地条件で釣っても良い。
不足になる事が問題なんだったら、その辺り嵩上げして人間を集めれば良いだけだし、それでペイしないって会社ならチャッチャと事業売却でもして身軽になった方が良い。
求人なんて基本的な契約なんだから、その辺りにも駆け引き位有ると知っているだろうに。
バブル時なんてあんなに各社で高待遇のバーゲンをやっていたってのに。
「希望者が来る迄、条件をアップしろ。」ができないのは (スコア:3, すばらしい洞察)
分かっててやってるのか天然なのか知らないけど、日本経営の伝統なのです!
日本では、人材不足とは
労働力が不足した仕事があるにも関わらず自発的に志願しないという
金に汚くて気の利かない非英雄的な労働者どもの責任なのです!
給料やら休みが欲しいとかいう前にProject-Xに出てるよーな英雄たちでもみならって
ローコストで英雄的に働きやがれなのです!
(古くは3Kとかいう言葉が生まれて流行った頃から、メジャー・メディアでは右も左もその点を誰も突っ込まないあたりそうとしか思えない。)
Re:「希望者が来る迄、条件をアップしろ。」ができないのは (スコア:3, 興味深い)
私の元記事は表現で調子に乗りすぎて「フレームの元」マイナスモデされちゃいましたがw。
本当はそういう経営者や購入者の個人レベルで
コストを押し付けあうということの是非について話がしたかったわけじゃなくて
今回の例でもかつての3Kの話でも 需要に対して供給が実際に不足しているのに価格が上がらないというように
市場メカニズムが期待通りには働いてないにも関わらず、
そのことが究明すべき問題として認識されずスルーされ、
あたかも労働者の問題のような言論が流布することに対して違和感があるというお話。
Re:顧客側の努力が足りない。 (スコア:2, すばらしい洞察)
Re:顧客側の努力が足りない。 (スコア:1, すばらしい洞察)
--- Toshiboumi bugbird Ohta
Re:顧客側の努力が足りない。(-1オフトピ (スコア:1)
------------
惑星ケイロンまであと何マイル?
Re:顧客側の努力が足りない。 (スコア:1)
そこの本質は(激しくオフトピ-100) (スコア:2, すばらしい洞察)
Re:企業側の努力が足りない。 (スコア:1)
#対価が体感できるかと。
そもそも「止まってはいけない」「RCA」と叫ぶばかりで運用と言う概念が無い会社が多すぎるのが悪い (スコア:5, 興味深い)
しかし、Active/Standby 構成を作るのになにもメインフレームである必要はありません。Unixシステムでだってちゃんと堅牢性は実装可能です。唯一の問題点は「メインフレームに比べて恐ろしく高い頻度で service down/ failover を繰り返す」と言うだけの話。
もちろん、Standby があるのですから Active が倒れても大丈夫です。1回目は。
.
問題は2度目以降になります。この手の客は「Root Cause Analysis」と叫ぶあまりに、Standbyに切り替わって、もう予備が無い状態なのに『切り替わった原因が判るまで、ダウンしているマシンを交換することはまかりならぬ』などと馬鹿を言う。結果、2台目がトラブルを食らったときに、もう代替機が無くてサービスが落っこちる。
Standbyが無くなったら危険なのはサルでも判る。ましてやメインフレームの主要顧客は金融・証券系。ポートフォリオのプロの集団でなくてはいけないはずの業態です。原因究明と、サービスダウンと、どちらを優先するべきか、ちょっと脳みそを使えば判る話なのに。全然プロ意識のかけらも無い、ただの文句を垂れ流す阿呆がこの手のシステムを管理している。だから、メインフレームぐらいしかその馬鹿な要求に答えられない、と言うわけです。そもそも、そんな連中に高い給料を払う余裕があるなら、金利をもっと上げろと…。税金で投入した金を返せと…。そしてもっと廉価なマシンを大量に使って、「システムとして安定している」ものを他人におんぶに抱っこなどという状態になっていないで、ちゃんと技術を理解して構築するべきです。
国際的に見て、他の国の運用形態とあまりにもかけ離れた、非常識なやり方をしているのが問題なのであって、メインフレーム技術者が不足している、と評価するのはまるっきりお門違いでしょう。
Re:そもそも「止まってはいけない」「RCA」と叫ぶばかりで運用と言う概念が無い会社が多すぎるのが悪 (スコア:4, 興味深い)
「予備が壊れたらどうするんだ。予備の予備を用意しておけ。でも普段使わないんだからそのマシンは値引け」というバカが
#実話だから悲しい
情報技術者は「新しい物好き」 (スコア:3, 興味深い)
枯れたシステムで安定した基盤を作る事に喜びを感じるタイプの人間は、土木工学科に進む事が多いはず。
情報技術なんぞを飯の種にしたがるような人間は、多かれ少なかれ新しいもの好き、新しいものを作るのが好きな人間。
枯れた技術に人気が無いのは、当然の帰結かと思います。
「将来性」を問題にするならば、若手はアセンブラやC言語に飛びつき、LLなんて使いたがらないはずです。
多くの若手にとって、問題は「未来があるか」ではなく、「未開拓地があるか」でしょう。
枯れた技術だからではない (スコア:2, 興味深い)
若者が参入しないのは将来性がないからじゃないの。
いつ「メインフレーム最後の日」が来るかわからんのに、
何が悲しくてそんなものを勉強せねばならんのよ。
Re:枯れた技術だからではない (スコア:2, 興味深い)
あ、いやもしかしたらメインフレームを扱っている企業内には潤沢なドキュメントがあるのかもしれませんが。
少なくとも書店やネット上では見かけない気がします。
#ただ単に自分の興味が無いから気がつかないだけかもしれませんが
Re:枯れた技術だからではない (スコア:4, 参考になる)
別のマニュアルから「○○」の項を見つけてくると「××の項を……」
最後に行き着くのは「サポートに連絡ください」
サポートに連絡すると「△△のページを……」と案内される
「どこのゲームブックだよ」とつっこみたくなる、そんな世界でした。少なくと某社のDBは。
# ちょっと前まで中の人だったのでAC
Re:枯れた技術だからではない (スコア:1, 興味深い)
Re:枯れた技術だからではない (スコア:3, 参考になる)
もちろん内容は充実。だから一般書店で扱われるような入門本の出る幕はないね。
っていうかそもそもボリューム的に個人で持つ物じゃないんだから出版しても売れないだろう。
例えば昔のMacでプログラミングに必須と言われてたInside Macintoshが、何冊も必要で一冊あたりも高価だったけど、あれの十倍以上の分量があるんよ。
そして、不明点などあればネットで調べるまでもなくメーカーに問い合わせれば済むので、情報が外に出ることもない。
まぁパソコンとは次元が違います。
Re:枯れた技術だからではない (スコア:1)
「いまどき紙製かよ!」
「オンライン版はWebで公開してないの?」
と思わずツッコミ入れた人間は私だけじゃないよね?
Re:枯れた技術だからではない (スコア:2, 参考になる)
>「オンライン版はWebで公開してないの?」
>と思わずツッコミ入れた人間は私だけじゃないよね?
単なる利便性からツッコミいれる話じゃないと読み取れない人だけでしょ。
…ハードウェアと一緒に書架も用意することになる世界ですよって言ってるのだから。
東芝・日立・富士通・日電…それらの基幹系にでも送り込まれたら、
誰も開かない謎の書架があって、そこに純正資料が置かれているのを目にする事が出来る。
つまり、そういう企業に就職した人間が囲い込まれて教育して運用する形態だった。
そりゃそうだ、専用ハードとの間で方言があって、秘密にするわけでも何でもなく、
応用範囲が狭いから外部から「ええ、それなら知っています使えます」って人間が
育つというプロセスはありえなかった、と。
#そういう外部の人間がいても、一度は募集企業に採用された経験があるとかいうオチ
Re:枯れた技術だからではない (スコア:1, 興味深い)
少なくとも自分が担当していた5年ぐらい前はOASYS文章のほうがたくさんあった。
#一応AC
Re:枯れた技術だからではない (スコア:1)
それは新しい資料では?その前は WDS? とかいうやつだと...
Re:枯れた技術だからではない (スコア:1, 参考になる)
大量すぎて何見たらいいかわからんくらい。
IBMだったらRedbooksから。
Re:枯れた技術だからではない (スコア:1)
別コメントで「ハウツーものはない」と書いてしまいましたが、
「ハウツーものは完備していない」と書けば良かったです。
Re:枯れた技術だからではない (スコア:1, すばらしい洞察)
Re:枯れた技術だからではない (スコア:1, すばらしい洞察)
試しに給与倍額にしてみ?多分翌日は問い合わせで賑わうぞ。
なんとなく (スコア:1)
オープン系=RGM-79シリーズ
こんなイメージが。
神社でC#.NET
Re:なんとなく (スコア:1)
メインフレーム技術って (スコア:2, 興味深い)
ハードウェア的には? ソフトウェア的には?
お爺さん対決 (スコア:2, 興味深い)
いろいろな意味で限界も感じていて
そろそろ終わりにしたいと思っているのでしょうね。
現場から離れてコンサルっぽくのし上がった
管理職・経営層のお爺さんは
まだまだ権力を持って居たいので、PCサーバーに置き換えられたら困ると。
先輩面が出来なくなりますから。
やっぱり正直な人は偉くなれないのでしょうか。
この立場の人々に求められるスキル (スコア:1)
ホスト担当がメインフレーム技術者、という位置づけになるわけだよね。
ホスト側ってもうシステムとしては鉄板というか、ほぼ完成されていて、
現場にいない自分としては、これからの新規の開発ってのはほとんどないと思ってて、
じゃあ、この立場の人々に求められるスキルって具体的には何?
・ホストとセンターサーバの電文仕様の把握
(センター側の業務仕様策定に付き合わされる時などに必要?)
・エラーが起きたら、マニュアルに従って運用再開
(レプリとレストアができたらだいたいOK?)
仕事内容は複雑ではないが、万一止めてしまったりしたら、責任重大。新聞沙汰。
という認識でいいのかな?
Re:この立場の人々に求められるスキル (スコア:2, 興味深い)
>という認識でいいのかな?
問題は、それだけしか把握していないがために
システム移行の際に情報が足りなくて困るのです。
で、結局見送りになったり・・・
# 知識が生きているウチに次を作り続けるのがいいのかなぁ?
すでに実施されている類似例 (スコア:2, 参考になる)
死亡フラグ(何の?) (スコア:1)
技術者「俺, この仕事が終わったら, 故郷に帰るんだ」
保護しましょう! (スコア:1)
「演劇、音楽、工芸技術その他の無形の文化的所産で
我が国にとつて歴史上又は芸術上価値の高いもの」
ということだそうですので
メインフレーム技術は無形重要文化財、
その技術保有者は人間国宝として保護するというのはどうでしょう?
#問題は芸術価値がどれだけ認められるかどうかだw;
~パタポン教徒~
Re:保護しましょう! (スコア:2, すばらしい洞察)
3世代くらいにわかれて。親方、中堅、新人で共同作業をし続ければ、
技術伝承できるんじゃない?
コストかかるとおもうけど。
今こそ (スコア:1)
> #問題は芸術価値がどれだけ認められるかどうかだw;
「文芸的プログラミング(by Knuth)」か!
メインフレームに精通した技術者 (スコア:1)
切り替えたら自分のアドバンテージが減るじゃん。それどころか既存のを使うために定年後も契約形態を変えてずっと会社に居座るとかできるかもでしょ。
まぁ、どうして変わらないかってのは社内政治 [srad.jp]の方がふさわしい話なのかもですけれども。
しかし、年金や高齢者医療制度とかと同じで、若い人間は先人によるその場しのぎのせいで将来自分が借金を負わされるとわかっていても「あいつら早く氏ねばいいのに・・」と思う以上のことをするのは難しいところで。
自分はそんな職場とはおさらばしましたが。いかんせんこの国からはなかなか・・・。
◆IZUMI162i6 [mailto]
あえて言う (スコア:1, すばらしい洞察)
Re:それじゃ (スコア:1)
Re:どこで勉強するのよ (スコア:5, 参考になる)
http://www-03.ibm.com/systems/z/os/zos/bkserv/index.html [ibm.com]
などと結構あります。
もちろん、ハウツーものの情報はまずないです。
少なくともGeneral Information辺りのマニュアルを読まないと
概要を掴めないのが敷居を高くしているのかも知れないですが
結構日本語マニュアルもあります。
実際に問題になるのはマニュアルを読み込まないと判らないノウハウが散逸しつつあることでしょう。
マニュアルを読んで動かして一見思い通りに動かない、よくよく調べるとマニュアルのこの記述は
こうなのか、さらに原文に当たって初めて合点が行くというようなことです。
もちろん、たまにはマニュアルが間違っていて修正プログラムならぬ修正マニュアルが提供される
こともありますが。
Re:どこで勉強するのよ (スコア:3, 参考になる)
汎用機関係の仕事はちょっとだけやったことありますが、本当に謎が多くて。
特定の仙人に知識が集約していて、困ったらその仙人がやるからおまえらは知らなくていいみたいな雰囲気もあるし。
昔は特許関係でIBMと厳密な契約をする必要があったらしく、情報を流出させないようにしていた名残りとかなんとか