汎用機オペレータの現状 その13

このエントリーをはてなブックマークに追加
952非決定性名無しさん:2006/02/20(月) 04:32:56
>>941
931、940です。(偽装)派遣会社の営業の人は、「君には期待しているよ」みたいな
ことを言っていたけど、ひそかに心の中で「コイツ、あの年であんな誰にでもできるような
仕事やってて、バカだよな。まあこっちは儲かるけどな」とか思われてるんでしょうか?
953非決定性名無しさん:2006/02/20(月) 05:38:49
>>948
お前のその独りよがりなんとかしろよ。迷惑だ。
ここに書いてストレス発散しているやつだっている。
お前のやっている事って知識をひけらかしたいだけだろうが。
スレのタイトル見ろよ。いらないお世話だ!
わかったら他でやれ!迷惑がっているやつの事も考えろ。
嫌味なんだよ。勉強しなきゃって追い詰められているみたいだろが。
954非決定性名無しさん:2006/02/20(月) 05:49:24
>>951
>>JCL=Win95、Java=WinXPみたいなもんだ

なんだそりゃ?キャグか?
Javaっていうのが何か調べてから書いて来い。
月曜の朝から大笑いしちゃったよ〜。
それにJCLもわかりにくいなんて言っている奴が
Javaなんてわかるわけないだろが。
しかももうJavaって古いぞ。何が時代はJavaなんだよ。
お前 普段でも口ばっかりって言われているだろ。
955非決定性名無しさん:2006/02/20(月) 06:19:04
>>952 それはどの仕事だろうと決まったらちゃんと働いてもらうためのお決まり文句だよ。
営業マンが元IT業界の現場で働いてたなら、そう思うだろうけど、現場経験無い人は派遣から文句言われたらそうなのかなあ?って思う程度で
そこまでわかるもんじゃないよ。
956非決定性名無しさん:2006/02/20(月) 09:35:10
>>953
そうか、そんなつもりで書いたわけじゃないんだがな。
確かにスレ違いとは思うし、不快に思われたのなら反論できん。
悪かったな。取り消すよ。

あ、あと951へ
(ほとんど954が言ってくれたけど)俺も正直笑った。
開発言語とジョブ制御言語じゃ比べるほうが無理ってもんだ。用途が
ぜんぜん違う。それにシステムを不安定にさせる可能性があるのは
JCLよりもそのJCL内で定義するプログラム本体だ。JCLってのは
決まり文句のように同じ単語ばかりしか使わない。とくに業務ではな。
まぁ、JCLをわかりにくいというのはJCLそのものを見た事が
ないのか、もしくは作った人の定義位置がバラバラで見にくかったのだろう。

俺もオープン系での運用設計ではJAVAを使うがJCL程簡単ではない。
そして「時代はJAVAだ」っていう貴方はどのくらいJAVA組めるのか?
もしシステムを作れる程ならもう一回JCLを見てみなよ。簡単だよ。
但し、オープン系での構築はJAVAだけ使えても難しいよ。場合によっちゃ
VBやCも使う事になるだろう。それと汎用機のCOBOL資産をオープン系に
移行するにはオープン系のCOBOLが必要だ。つまり運用環境作るのにも
多くの言語を覚えなきゃならないって事だ。まぁ金があればメーカーに
任せてもいいが、数千万かかるだろう。結局は自分らでやる事になる。

正直、JCLくらいで手こずるようじゃJAVAなど到底むりだ。

あと「JCLなんて社会から必要とされていない」ってのは 文章内容的に
変だと思うぞ。
957非決定性名無しさん:2006/02/20(月) 09:52:27
>>951
>>チャンスに恵まれないのはスキル不足、能力不足のため
>>それを分からないようではたかが知れているというものだよ明智君

上からの仕事はその人にスキルがあろうとなかろうと与えられる。
人材育成の為だ。そしてチャンス(仕事)があって初めてスキルが身につく。
机上の勉強だけでは役に立たないといわれる所以はそういう事だ。

お前若いだろ?この先自分にできる仕事ばかり来ると思うなよ。
自分にスキルがない仕事でもそれなりに答えを出さないとやっていけないぞ。
958非決定性名無しさん:2006/02/20(月) 11:21:34
お前、うちの汎用機担当SEなんじゃないの?
スキル、スキルうるさいし、勉強会やりたがるし。
俺たちゃ早く帰れればそれでいいんだよ。そんな出世したいか?
959非決定性名無しさん:2006/02/20(月) 11:34:45
OPのスキルってなんだ?

私は会社の方針によって違うと思う

業務の遂行を担ってる運用課として、管理能力を求められている会社であるか、
JCLなどを覚えてさらにCOBOLを覚えてもらい将来開発になって40-50才台まで
開発をさせるかどちらかだと思う。
960非決定性名無しさん:2006/02/20(月) 15:45:43
>>936
マジレスするわ。

あんな分厚いマニュアル???
本当に何にもやってないんだな。暇なんだろちょっとは中身みろ。ボケオペ。
マニュアル見てみろユーティリティなんて少しだぞ。
分厚いのは、ユーティリティにくっつくパラメータの説明が多いからだ。

ウチのオペは運用管理込みなので>>936みたくライン工ではない。
資格は最低でも初級シスアドは持っている。
普通に基本も取っている。
今はみんなセキュアドの勉強している。
給料は新卒で手取り20万くらいだ。
961非決定性名無しさん:2006/02/20(月) 15:57:51
>>951
たとえがめちゃくちゃだけど
JCL覚えるならjava覚えろってことだな。
そりゃあそーだ。

でもJCLは覚えるのではく自然と覚えちゃうものだ。
道具だよ、運用上の。

オペのスキルなんてないよ。
客とのコミュニケーションくらいだな、役に立つのはさ。
962非決定性名無しさん:2006/02/20(月) 18:09:54
>客とのコミュニケーションくらいだな、役に立つのはさ。
コミュニケーション能力とかは、むしろオペやってたら、だめだめに
ならない?
スキルチェックしたら、俺らの現場のオペは全員、顧客リレーション、
ネゴシエーション、コミュニケーションがレベル1だった。
尤も、客やSEと話をするのは管理者の仕事で、俺らは指示書に従って
作業するだけだから当然なんだけどね。
情シスの主任とは3年間、一度も口聞いた事ないよ。
963非決定性名無しさん:2006/02/20(月) 19:05:31
>>960
情報処理技術者試験のテクニカルエンジニア(システム管理)
を管理者が受験するんだが、市販のテキストを見せてもらった。
これのどこにも、オペレータが「ジョブ制御言語ハンドブック」や
「コンソールメッセージハンドブック」を見て対応しろとは書いていない。
それは管理者の仕事で、僕等交替制の仕事ではない。
964非決定性名無しさん:2006/02/20(月) 19:28:18
オペレータに適してる性格ってなんだろ(´・ω・)?
集中力を持続できるとか??
965非決定性名無しさん:2006/02/20(月) 20:16:15
>>964
ルーチンワークを厭わない。
気が利きすぎない。
966非決定性名無しさん:2006/02/20(月) 20:54:52
私は昨年の5月からこのスレを読んでいますが、印象に残った書き込みは

「この仕事をあまり長く続けてるとバカになる」というものと

「子供のころ、自分がこんな夢もない仕事をしてる大人になるなんて思ってもみなかった」

といった内容のものでした。過去ログさがせば見つかると思います。
967非決定性名無しさん:2006/02/20(月) 22:04:18
情報処理技術者試験 テクニカルエンジニア(オペレータ)

問題:
コンソール前にカセットコンロがあります。
調理しても安全かつ美味なメニューを答えよ。

(1)焼き肉
(2)ちゃんこ鍋
(3)焼き鳥
(4)焼きガニ




答え 4.

解説:
1は油が飛び、画面がテカテカになる。
2はダシがコンソールにこぼれるとリカバリー不能
3はカセットコンロではおいしく調理できない。炭火であれば可能。
4が正しい。
968非決定性名無しさん:2006/02/20(月) 22:12:57
うわー懐かしいなあw
オペ8年前辞めて転職したけど、
このスレにノスタルジーを感じました。
ありがとう。
969非決定性名無しさん:2006/02/20(月) 22:13:00
情報処理技術者試験 テクニカルエンジニア(オペレータ)

午後2  論文(回答時間90分)
問題:
余暇時間に読む書籍を整理するための本棚(W40cm, H120cm, D35cm)が導入された。
初期費用20万円、毎月の固定費が1万円として、
本棚に入れる書籍を選定し、棚割せよ。

但し、書籍のジャンルの組み込み比率の制限は以下のとおりとする。
漫画 30%以下
男性向け書籍 20%以下
成人向け書籍 20%以下
女性向け書籍 5%以上
情報処理書籍 10%以上
970非決定性名無しさん:2006/02/20(月) 22:26:57
>>969
女性向けいらなくね?
971非決定性名無しさん:2006/02/20(月) 23:03:36
>>948
同じく転職を考えてるのか。やはり、この業界転職してナンボだからな。
俺の会社もデキル奴ほどさっさと会社を辞める。
俺はもう完全にITから足を洗おうと思ってるんだ。
ただ、もう少しこの業界には居るつもり。
JCLは今の職場でも知っておいたほうがいいけど、理解してる奴は数人。
1つだけ聞きたいが、運用設計とはどのようにやってるんだ?
今の職場は別部署がやってるから、オペレータは一切ノータッチで誰も分からない。
もし、答えられないなら、それでも構わない。
972非決定性名無しさん:2006/02/20(月) 23:34:08
運用設計はシステムの開発時期に平行して
インフラ構築側のSEが行うイメージがあるね。
私はUNIXの運用設計を担当しているけど
お客の運用体制、時間帯ごとのシステム稼働率、
障害時のリカバリ用件、予算に応じた
導入する機器の選定から始まり
開発チームの使う検証機の構築、
DB,アプリケーションサーバ等のミドルウェアのインストール、
クラスタリングなどを用いた信頼性向上策、
バックアップリカバリシステムの構築、
バッチ処理のジョブネット構築、
エンドユーザ向けの教育、マニュアル整備なんかを
開発側やお客の担当者と調整しながらやっていく。
なかにゃ雑用まがいのこともやるのでもうほんと何でも屋に近いね。
汎用機でもやっていることの根幹は同じだと思う。
特徴的なのは開発側と同じく運用設計側も
(うちの会社じゃインフラ側と呼んでる)
システムが出来上がったら解散してしまうってこと。
短い間だからいかにお客が利用しやすいように
運用イメージを掴めるかが一番の課題かな。
973非決定性名無しさん:2006/02/21(火) 03:06:37
>>951
某メーカの中の人だが、JCLはなくさん。
汎用機がなくなってもだ。

必要とされなくなったらなくなるがw

>>952
>>821を見るといいと思うよ。

>>956
>正直、JCLくらいで手こずるようじゃJAVAなど到底むりだ。

ネットジョブのJCLは難しいよう・・・

>>960
JCL「言語」のマニュアルは薄いよね。ユーティリティもそんなに厚くないよね。
でもね、システムパラメータとかそっちの分厚いマニュアル読まないと載って
ないこともあるよね。>>936はその辺で挫折したんじゃないかな。
974非決定性名無しさん:2006/02/21(火) 03:49:27
本来、オペレーターってプログラムは関係ないよね。

なんで、最近、書き込みが多いんだろう…?
975非決定性名無しさん:2006/02/21(火) 08:18:10
そもそも、運用に必要なスキルとは、プログラム組めるスキル
というよりも、障害時の切り分けや一次対応の正確性とか
そういった部分だと思うが?
ウチに来てる開発SEで、ネットワークに接続されているあるPCで、
ウィルス感染が検地された際の最初の行動が、「このウィルスがなんであるかをネットで調べることだ」と主張してた人がいるけど、
いくらJAVAが出来ても、これでは運用では使えないよね。
976非決定性名無しさん:2006/02/21(火) 11:07:20
>>975
セキュリティのガイドライン程度の教育もしていない
みたいだな御社は。
そんなことだと今にオペが顧客情報漏らすぞ。

ウチはオペだからこそセキュリティ教育には
力を入れている。
その発言は釣りとしか考えられんが・・・
977非決定性名無しさん:2006/02/21(火) 11:42:33
>>976
上のウィルス感染時の行動は、試験にも出てくる問題だから、
間違える奴はいるんだろうね。
「直ちにウィルス駆除のとりかかる」と回答する奴はありがちだから。
978非決定性名無しさん:2006/02/21(火) 17:59:34
>>963
まさしくライン工DQNオペだなw

>「ジョブ制御言語ハンドブック」や
>「コンソールメッセージハンドブック」を見て対応しろとは書いていない。

どこの試験問題にそんな範囲の狭いACOSの問題が出るんだ?
マニュアルに通りにしか行動できないんだな。お前は。
職業病だわ。ご愁傷様。

>僕等交替制の仕事ではない。

確かにそーだ。お前らにJOB管理は出来ない。
でも暇なんだろ上の2種類のマニュアル読んどけよ。
いづれは管理者になるんだろ。
979非決定性名無しさん:2006/02/21(火) 22:58:37
>>978
オペから管理者になれんのなんて、一握りだろ。
980918:2006/02/22(水) 06:58:12
>>971
運用設計?基本的な内容は>>972の方が書いていらっしゃるからとりあえず
一例を挙げると、開発部門では一つの処理毎にプログラムを開発するわけだが
それを個別にオペレーターが処理していては手間も多いしそれだけミスも多く
なる。運用ではそのプログラムの集まりをJCLでつないで今度はこのJCLの
集まりをスケジューリングしてなるべく一つのメニュー項目で全てを構成し、
このスケジューリングした処理別に監視サーバのイベントビューアーみたいなもんに
「正常・異常」を表示し、オペレーターがこれをもって最終結果を確認するように
環境を作る。途中のログなどは一切、見ない。

そこで難しいのは他部署とのデータ転送や、多数のサーバーとの連動だ。
これを制御するのがJAVAやVBなどを使い、汎用機と結合させる。
厳密には汎用機側、サーバー側でそれぞれ情報送受信の環境を定義する。
だいたい一つの業務を全自動化するとすれば汎用機側でまずスケジューリング
するから業務PG、JCL、判定環境言語、スケジューリング言語と4〜6種類の
言語を組み合わせて環境を作り、サーバー側では業務PG、環境連動言語、
判定言語、スケジューリング言語などを使うから総合計で10近い言語の
組み合わせ構成されていて、オペレーターが一つのメニュー選択だけで、
テープ掛けなどのハンドリングを行い、監視サーバーで結果を知る事ができる。
981918:2006/02/22(水) 06:59:20
オペは絶対に業務PGは作らない。しかし少人数でこれら多数の業務PGを
処理するには自動化する必要かあった。かつ、あっちこっちのサーバーに
処理結果を見に行くようであれば処理が混乱する。そこで業務起動サーバ、
汎用機、転送サーバ、周辺機器制御サーバ、処理結果監視サーバと分野ごとに
分けている。業務中のオペレーターは業務起動サーバより処理起動し、
周辺機器制御サーバを見てテープなどをセットし、処理結果監視サーバで
結果を確認する。これを実現可能にするのが運用設計の役割だ。
但しあくまでもうちのスタイルであって、他とは異なる部分もある。

正直、これらをSEの仕事と言う人も多いだろう。俺もそう思う。
ただ、企業側は裏方ともいえるべきオペレーターに多くの人材を
充当する事は不可能。従って少数のチームで多くの業務をこなすべき必要がある。
そこで考えたのが自分達で環境を作り、これを自分達でこなす。このスタイルが
できあがっていった。ぶっちゃけ、個人的にはメーカーSEに負けていない
自信がある。まぁ俺もいちおう若手に入るからえらそうな事は言えないけどな。

こんな感じだ。そのうち細かくカスタマイズできる自動化制御ツールが
できると思う。そうなるまではこういった運用設計やる企業も少なくない。
とりあえず、皆さんの参考になるといいな。
982非決定性名無しさん:2006/02/22(水) 08:28:15
>>980>>981
その程度の事はオープンシステムだと、各種ミドルウェアが充実
してるから、必要ないからねぇ。
ウチはJobcenter、IT/O,ominiback等、JOB制御、バックアップ制御
のツールを導入すれば問題ない。

980、981の例で懸念されるのは、設計時のメンバがいるうちはいいが、
自動化された環境の元でメンバ入りした者に対して、いかに内部構造を
理解させるかがポイントだと思う。
一見、自動化されていていいように見えるが、かなり人に依存した
システムだと思いますね。

自動化は諸刃の剣であるということは運用の現場では多々あるので、
ウチは逆にオペレータにいちいちコマンドを打たせたり、
サーバのディスクアレイ等の状態確認も、わざわざそこのサーバまで
行かせてます。
983非決定性名無しさん:2006/02/22(水) 09:50:28
>>980>>981
「在日は帰れ」まで読んだ。
984918:2006/02/22(水) 09:59:11
>>982
わかっています。豊富にミドルウェアがある事も知っています。
ただそれらは全て標準パッケージであって細かくカスタマイズできなかった為に
我々も止む無く素作りしています。夜間の無人化を目標としている為、途中途中で
人間の介入が必要あるならば意味がありませんでした。ましてやオープン系
だけならまだしも汎用機内に多くの資産があります。こことどう結ぶかが
非常に難しいと思っています。ちなみに今この世にあるアプリで、細かく
設定ができ、かつ汎用機とオープン系の機種に依存しないものは存在しません。
メーカー、OS、そして汎用機、オフコン、サーバーが全く異なるものを
連動させる技術というのは簡単にはいきません。我々が未熟な為かもしれません。

我々の懸念材料は>>982がご指摘なさったとおりです。設計者不在時にミスが
おこる可能性を持っています。その為にもうちで働いていただいている方には
派遣・社員に関係なく、誰でも学んで欲しいと願っています。
985非決定性名無しさん:2006/02/22(水) 09:59:16
>>980-982
大変だな。

バカオペのために自動化
     ↓
応用が利かず電話対応なんか
出来ないロボットオペの出来上がり
     ↓
内容を解らすため手動へ
     ↓
オペミス連続
     ↓
バカオペのために自動化

永久ループ。
要はバカオペ切って運用管理も出来るオペを
そろえればいいんじゃないの?
でも企業側は安くて粗悪なオペしか用意しないがね。
986918:2006/02/22(水) 10:00:49
>>983
読んでくださってありがとうございます。ん〜と、誤解があるような。
987918:2006/02/22(水) 10:09:51
>>985
いや、自動化は少人数でやるためだけにやっているわけじゃない。
手間が少なければ業務中でもまとまった時間がとれる。
その間に仕様書などを見て覚えてほしいと思っている。

少なくともオペレーターをバカにした覚えは未だに一度たりともない。
俺も一介のオペレーターだ。ちなみに今日から連休だけどな。
988非決定性名無しさん:2006/02/22(水) 10:31:57
>要はバカオペ切って運用管理も出来るオペを
>そろえればいいんじゃないの?

お金の問題がある。ユーザお金を出せばいい人材は
用意できるけど、大体が一人70万でもらえる方で、
50万に買い叩かれる事も多い。

ところで、オペレータの単金について、オペレータと呼称するのと運用SE
と呼称するのとで、委託された業務内容が同じでも単金が違うと言う
のは本当なのだろうか?
自分の会社の営業が、4月からの契約更改で単金を上げたいがために、
外注のオペレータを1月から運用SEと呼び、各オペレータにも
「貴方たちはオペレータではなく、これからは運用SEです。」と徹底
しているようなのだが。
989非決定性名無しさん:2006/02/22(水) 11:02:39
>>987
理想: その間に仕様書などを見て覚えてほしいと
現実: 2ch、ネトゲ、漫画、動画三昧
990918:2006/02/22(水) 11:13:07
>>988
長年勤めてレベルアップしている派遣を「運用SE」って事にして
単金をあげて派遣元の会社が派遣先に金額の交渉をするってのは
よくあることだけど、もしそうじゃなかったら深刻な事態もありうるぞ。

オペレーションのみって契約と、正式にSE業務も担当するとでは
これから先が大変かも。まぁスキルアップにはなると思う。

勤務先の会社の4月からスケジュールを調べといたほうがいいよ。
他の企業にいっている同じ派遣会社の人がいればその人にも
聞いてみなよ。
991非決定性名無しさん:2006/02/22(水) 12:09:08
>>990
業務は変わらないみたい。
ただ、一方的に呼称を変えているだけ。
ユーザや開発SEは依然として”オペレータ”と呼んでいる。
業界標準で、運用の単金が、作業内容以前にオペレータとSE
とで違うのかなと。
992非決定性名無しさん:2006/02/22(水) 13:35:40
60万で1次受けが2次受けに丸投げ
40万で2次受けがry
30万で3次受けがry
んで、20万以下でどこの馬の骨ともわからん派遣がやって来る。
企業が60万出しても、60万に見合ったスペックを持つ人がやってくるんじゃなくて
20万以下のスペックしかもたない人間がやってくるんだから、仕事も大したことできない。

IT業界はこのピンハネ構造が問題なわけで、ほんとに何とかしないとヤバイと思う。
993非決定性名無しさん:2006/02/22(水) 14:06:11
オペで単価70万!
ウチは一次受けで50万くらいだ・・・。orz
994非決定性名無しさん:2006/02/22(水) 17:09:44
最近、ふと思うのだが、俺らは請負契約で元請と契約して、
とあるユーザの現場に入って作業しているのだが、
元請が自分たちの会社の規定の遵守を俺等に求めてくる。
社内のセキュリティに関する意識調査なんてーのはまだいいのだが、
社内規定に従って、プロパーオペと同様に、出退勤を元請の管理部門
にメールしないといけないし、その他諸々、元請の社内規定に
沿って行動しなければならない。
俺らは業務請負契約であって派遣契約でないのだから、これって
おかしくないか?
今度、何かあったら一言クレームをつけようと思ってる。
995非決定性名無しさん:2006/02/22(水) 17:41:14
やめとけ
多分契約書に派遣先の規則に準拠するものとするみたいな事書いてあると思うよ
996非決定性名無しさん:2006/02/22(水) 17:41:39
>>994
今言えよ。
997非決定性名無しさん:2006/02/22(水) 18:58:33
>>992
いつか、外注オペのせい(というより偽装派遣システムのせい)で、世間をゆるがす
ような大事故が起きるんじゃないかと思う。
998非決定性名無しさん:2006/02/22(水) 19:06:25
1000
999非決定性名無しさん:2006/02/22(水) 19:07:21
1000
1000非決定性名無しさん:2006/02/22(水) 19:08:49
1000
10011001
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。