「メインフレーム」を含む日記 RSS

はてなキーワード: メインフレームとは

2019-03-06

実際に社会を支えているレガシーに重きを置くならつきつめるとメインフレーム様とCOBOL様にひれ伏せ愚民どもって話だし…

2019-03-01

anond:20190301083815

SIerという総称で殴るのあんまり好きくないけど

情シスがクッソ雑いWebフィルタオラクルフォーラムすら見えないような縛り方してる一方で

会社としてはメインフレーム技術者OSS技術習得して移行して欲しいとか支離滅裂なとこ普通にあるから困るよね…

ツールインストールも調べ物ももままならないのにできるか!ってな

2019-01-09

改元に伴うシステム改修が1か月で終わったらいいけど、現実甘くはないよ

【新元号】改元のシステム改修で慌てるシステム屋は「無能」とのこと - Togetter

最初一言書いておくと、元号システムに最も絡んでいるであろう金融機関とか官公庁とか、そういうとこのシステムって想像以上に複雑怪奇に絡み合った化物みたいにどでかいやつが多くて改修めちゃくちゃ大変だと思うので、あんまり外野から勝手なこと言わんといてあげてください。

元号がすぐにわからないと生活に困るという実例を挙げて下さい

あんまりないと思うけど、今書いた通り官公庁とか金融機関は困るんじゃないですか。流行りのふるさと納税とかやったことないですか? あれのワンストップ特例申請見るだけでも、どこで元号使われてるかわかりますよね。

元号はいずれ変わるものなわけで、それを考慮してないシステム設計・構築すること自体無能

言いたいことはわかる。わかるけど、問題はそこではないと思う。仮に改元対応可能システムを組んでいたとしても、そのシステムはこれまでに改元経験していない。つまり実際に改元する際の手順を確認する必要があるし、その影響範囲を見極めなくちゃいけないし、改元作業テストが要るし、改元当日のためのリハーサルが要るし、そのための業務調整やら休日出勤やら何やらが発生するわけで、いずれにせよ「平成」と書いてあったところを「hogefuga」と書き換えて半日ぐらいでハイ終了、みたいな話ではない。

というか、システムなんて想定外がヤマのようにあるのが常だろう。IPv4が枯渇するなんて想定されていなかったし、西暦2000年も想定されていなかったし、今後も2038年問題なんてのも控えてる。そんなもんだろ。システムって。

そもそも事前に知れるのが異常で、天皇がいつ亡くなっても良いように設計してるから問題ない

言いたいことはわかる。が、今回に関しては「事前に新元号が通知される」からこそ問題なんだと思う。

昭和平成ときのように、突然元号が変わったとしよう。その場合、突然なので誰もすぐには対応できない。その時点でみんなが手遅れだ。だからこそ、SEはお客さんと調整しやすいんじゃないだろうか。すみません半年かかります、1年はかかります、だからそれまでは暫定で平成使いましょう、西暦使いましょう、みたいな。まぁ、そうも行かない人たちはデスマるんだろうし、そういった負担や混乱を鑑みて、今上天皇は「生前退位」の意向を示したんだったと思うけど。

今回は事前に改元の日程がわかっている。2017年12月閣議決定しているので、1年半近い猶予があった。そうすると当然、改元当日までに対応しようと誰もが思う。早く新元号を発表してもらって、悠々と対応を終えておきたいと思うのが人情だ。それなのに、新元号の発表は1か月前だと言い始めた。だからみんな憤っている。

システムがーと吠えてる人がいるけど、漢字文字なことは分かってんだから、前々からデータいくらでも改修できるしテストもできる

もちろん、1か月前まで何もしないわけじゃなくて、仮の文字列を使って改修やテストは進めるだろう。しかし、最終的には正しい新元号がきちんと画面に表示されるか、帳票に印刷されるか、そういう確認必要になる。元号を使うシステムなんて、公的機関金融機関が多いだろうから、尚更チェックは厳しいだろうし、役所にある様々な種類の書類とか申請書、あれ全部新元号表記されてること多分チェックしますよ。んでチェックした帳票や申請書を全国にあらかじめ配送しておいて5月1日から使ってもらうとか、そういう手配も必要なわけで。そういうことに1か月しか使えない、って結構ぞっとしない話じゃないですか。

1ヶ月前とか準備期間なさ過ぎるって思ってるならアレですよね

言いたいことはわかる。でも、そんな簡単な話じゃない。

例えば。何らかのデータを、元号による日付入りで1000社に販売している会社があるとしよう。その会社改元対応を行う。すると、そのデータを受信している1000社でも、受信後のデータ処理やらバッチ処理やらに影響が出ることになる。システムというのは、単体で動くものではなくて、複数が連関して動く。だから1箇所の変更が、その末端や連携先にも影響を及ぼすことが多い。複数社が関わるシステム場合、各社の都合もあるので、2回に分けてシステム変更のリハーサルをやりますだとか、そういことだってあり得る。それを果たして1か月のうちに全部終えられるのだろうか。

今はネットアップデートできる時代パソコンアップデートの様に一瞬で元号を変える事は可能だろう

無理でしょ。銀行の真ん中とかメインフレームだぞ。あれがインターネットにでも繋がってると思ってんのか。

疲れたからこのへんで。特に3つ目が重要かなと思っていて、本来なら1年半あったはずの猶予がわざわざ1か月に縮められるあたりが怒りを呼んでいるんじゃないでしょうか。わざわざ短い納期で焦ってやって失敗したら、それまたみんな叩くんでしょ? 陛下のおことばにも、国民暮らしへの影響が言及されていてとてもありがたい話なのに、なんで「短納期でも問題ないだろ」ってその国民から蹴り入れられなくちゃなんないんですかね。

2019-01-04

anond:20190104004632

逆だよ

プログラマとして働く場合、多くの場合Linux上でJAVA程度の知識がありゃイケるのに、メインフレームCOBOLとかWindowsパワーシェルプログラムとか、ぜ~んぶ覚えないとプログラマになれない、とかそっちの方が厳しくて死ぬ

更に言えば「次の案件は◯◯の●●ですよ」と言われたら、その仕事が始まる前までにそれらの基本を一通りマスターしとくのがプログラマであって、逆に仕事もなしで全部覚えるなんてプロセス踏んでいられない、というかそんなのしたら死ぬ

2018-11-25

anond:20181125105119

メインフレームだったからかと

まぁ実は裏側の深いとこで未だにメインフレームが一部生きてるけど俺はその担当じゃないのでよく知らない

ただシルバー人材を登用しているという話を聞いたことある。昔メインフレームを使ってた超ベテラン人材

シルバー人材は一度長期休暇を取ると戻ってこないらしいという怪談も聞いたw

2018-11-18

SEエンジニアとして転職することを考えたとき

ある金融系のユーザー子会社SEをやっている。

会社入ってからプログラミングはじめたが、普通に部署エースみたいな感じになった。

配属から5年。

安定した会社ではあるが、自分の思い描いていたIT企業ではなかった。

(というか就職ときIT企業の中身すらよくわかっていなかったのが正直なところだが……)

自分がやってきた仕事は、システム設計・開発・テスト実施の一連のことはやった。

よくある協力会社マネジメントというのではなく、全部自分の手でやった。

あとユーザー説明障害対応

いわゆるSEとしての仕事は一通りできるようになったかな〜という感じ。

WEB業界なり、外資系IT企業日本法人なりが転職先の候補なのだが、

担当してるシステムメインフレーム系なので、今の会社で培った技術というのが、ほぼ外で応用できない。

よくSEからWEB転職する際に、プライベート勉強してつくったものアピールして、

自分技術アピール、というのが鉄板なので、ちょっとした手土産を作って持っていこうとは思う。

情報処理の高度資格は3つほど持っている。

ExcelばっかのSIから抜け出したいと思っているものの、

結局Git使って、コンテナ基盤の上でCIして、アジャイルに開発してますみたいな世界線で、

自分がどれだけやれるかが自分自身も不安だし、正直やってみないとわからない。

今の会社にいれば、間違いなく「仕事ができる人」でいられるんだよなあ・・・

2018-09-29

旧来型SIerである弊社でアジャイルスクラム)が上手く行っていない

弊社は未だにメインフレーム相手をしてCOBOLを書いているような、低技術力・プロマネ偏重SIer

20代の若手SE(笑)である自身ウォーターフォール経験しかなく、社内の99%も同じ。

最近興味があって近くにいる人とアジャイル開発の勉強をしていており、ジェフサザーランドの著書ほか何冊か本を読んだ、というだけのただのエンジニアワナビー

最近近所で絵に描いたようなアジャイル失敗例があって、ちょっとかに聞いてほしくて書いてる。


この度、既存システム刷新するプロジェクト(たぶん1億以上5億未満)をアジャイル開発でやることになり、先月くらいに最初スプリントスタートした。

アジャイル導入にはおそらく特に動機がなく、お客さんの偉い人たちが

最近アジャイル流行ってるんでしょ

無限要件変更できるんでしょ

アジャイルにすると早く安くできるんでしょ

などと仰せになった結果だと聞いている。

そのスプリントが当初からコケ

最初スプリントスピードが出ないのはよくあることなのだろう。古事記にもそう書いてあった。

が、内容を聞いているとどうもそうは思えない。もっと根本的なところだ。

スクラムなのに、なぜか最初からウォーターフォールみたいなスケジュールがある

なので、開始直後から「遅れが…」とか言ってる

要件範囲もなぜか最初から必達が切られている。ウォーターフォールかな。

なので進捗報告もウォーターフォールみたいに行っている

当然「ご報告資料」づくりもセット。

開発メンバーが開発できないらしい

どうも、開発メンバーユーザストーリー理解していないらしい。

それがなぜかというと、プロダクトオーナーとのコミュニケーションがとれていないらしい。

さらにそれがなぜかというと、プロダクトオーナーユーザ部門の人がよそと兼業してて全然時間がとれない、そもそも別の場所にいて会うことすら難しいらしい。

ユーザーがしっかり参加するのがスクラムじゃないのか。

また、そもそも開発でかき集めたメンバースキルが、スクラム要求するそれに届いていないという話もあるらしい。スクラム要求する開発チームのスキルはおそらく自力要件解釈解釈コードまで落とせるレベルだが、弊社が旧来の手法で人売りから買ってきた「エンジニア」たちにそれを求めるのは酷だろう。


現場プラクティスだけは導入している。デイリースクラムスプリントレトロスペクティブ…比較スタンダードに全部形から入ったらしい。表面だけとってきてスクラムと称しているが、サザーランド氏がつぶしたかった予測不可能予測しようとする傲慢さとか、ユーザ不在のシステム開発とか、コミュニケーション協調のない開発とか、マイクロマネジメントとか、一番重要エッセンスを尽く省いているようにみえる。

お魚買ってきて、全部は食べられないね~って言いながら表面の皮とウロコだけ食べてる感じ。これで以て「アジャイルってお魚は、ウロコと皮しかなくて、おいしくないし食べづらい」って結論づけるんでしょ僕知ってるよ。



この件について、まあ弊社じゃこうなるよな。だったらここまでなんだけど、こんな駄文を書こうと思ったのは今回の顛末不思議だったから。

本件のプロジェクトを率いているのは弊社でも指折りの有能PM。何度か一緒に仕事をしたり、指導を受けたりしたこともあるが非常に頭の切れる人で、社内での発言力も非常に強い。彼は「スクラムで」との命令を受けた後、当然スクラムについて勉強しただろうし、当然「何もしなかったらこうなる」とわかっていたはずだ。その政治力を使ってなんとかしようとしたはずだ。彼の周りについた弊社メンバーも、それぞれがスクラム勉強をしていたし、みんなPMには劣るかもしれないものの頭の切れる人たちだ。

そんな知力と政治力の両方を備えた歴戦のPMが、こんなにもあっさりと、なんの策も打てずにウォーターフォールの悪いところをしっかりと引き継いだアジャイル(笑)をやって失敗するのか。これじゃあ、弊社じゃあずーーーーっと無理じゃないか

2018-07-25

日航123便墜落事故日本IT業界

未だに、なんもしらんCS専攻の学生に嘘吹きこんで日本IT業界という地獄に叩きこんでる、どこから金貰ってそんな、爆弾テロよりはた迷惑無差別テロレベル迷惑行為を続けてる

IT系のニュースサイトブログ記事を書いてる元エンジニアたちが口をそろえて言う「TRON開発チームが全員日航事故で死んでいなければ、日本IT業界はこんなブラック業界になっていなかった」っていう言説

シグマ時代よりちょっとから、すでに35歳定年説や客先常駐によるエンジニアの大量の心身障害による廃人化、人売りによる使い捨てパワハラなんてレベルじゃないコンプライアンス無視エンジニア軽視、オマケ組み込みメインフレームは山奥常駐で人権も何もない、スキルも一度変なところに当たればつかずに陳腐化→速攻スキル遅れで底辺化待ったなしは始まっていたし、当時でも業界内では問題になってた

息が長い(とされている)インフラ系ですら、80年代から90年代前半は20代だった層がごっそりいない時点で、ちょっとおかしいって業界で働いてる増田なら疑問に思ったことがあるはずだ、あの当時CS専攻だった人間なんて、超一握りの理系エリートレベルだったんだから

そもそもTRONプロジェクト成功していたとしたって、まずマイクロソフト含め、アメリカには逆立ちしたって勝てなかっただろうってのは、今勉強すればよくわかると思う

そんで、そういう反論が現役側から出れば、今度は「金子勇氏はブロックチェーン技術ひながたさえあの時代に作ってた、彼が生きていれば日本IT業界は…」とかいいつつ故人でさえ金儲けにタネに利用して、セコく舌を一枚増やして口をそろえていうわけだ

「でもIT業界には無限需要があって将来性もあるから、これからどんどん就職すべき!」ってね

こういう奴等もはや、狂って通り魔する大量殺人犯よりタチ悪いから、マジで捕まえてくんねえかな、というか天罰が当たって物凄い苦しい死に方してほしい

顔も知らん人間冤罪に仕立てておいて、警察相手劇場型犯罪起こすレベルアノニマスですらやらん様なサイバーテロリストさえ排出するくらいモラルハザードきわまった業界に将来性なんてあるかよカス

だってブラック当たって職歴に傷がなけりゃ日本IT業界なんてカス業界に入りもしなかったわ

稼げるだけ稼いでリーマン前にちょうど「定年説」直前になったのでとっとと別業種に転職決めた元ITエンジニア愚痴

2018-05-30

anond:20180530105549

あれってCOBOLという言語をできる人がいないという言い方が誤解を招いてる気がする、ソースを解析したり書いたりはクソみたいなソースでも時間をかければどうにかなるし、実際は使用されているメインフレームによって実装が違うから人が足りないというのが正しいと思う。

それに汎用機ルールなんて機種の開発会社によっても違うし機種が同じでも運用によってルールが違うし、原因が高齢化による退職だというなら解決方法は人を育てるしかない。

2018-05-08

anond:20180508004011

同じ世代でも都市部地方、あと偏差値で随分違うんやで

俺が昔、派遣NECの子会社に入ってた当時は、確かに

団塊世代の年少組(1950年生ぐらい)でパソコン使ってるおじさんがいたよ

現在なら70歳手前ぐらいだよな

ところが

俺が上京してくる以前の1980年代当時

地方理工系でもない偏差値50ぐらいの高校じゃ

パソコンなんて触った事ない奴が圧倒的多数

本物の昭和団塊世代にしたって

ネット上では団塊全共闘と盲信されとるが

当時の大学進学率は3割に満たず、しかノンポリ学生が9割やで

中卒高卒集団就職

コンピュータといえばWin95普及ごろまで

長らくテープがぐるぐる回ってるメインフレーム

電子頭脳」と思っとったようなおっさん

地方にはごろごろいることだろう

2018-04-07

泣きながら仕事してもよい風潮にしてほしい※補足

最近デフォルトで涙がでてくる。

キーボード叩いてると突然ウっとなって涙がじわじわにじんでくる。きっかけはよくわからない。

涙がにじむとトイレにこもってできるだけ涙を排出し、自席に戻る。

涙が出るたび一々トイレに行かなければならないのが面倒くさい。

涙を出しきったつもりで自席に戻ってもしばらくは残尿みたいに止まらないのも面倒くさい。

そういうのが一々面倒くさいからそのまま涙流しながら仕事させてほしい。

世間的には泣く行為は割とハードル高い行為みたいだ。

なので泣きながら仕事してたら変に心配されてしまうと思うが、でももデフォルトで涙がでてくるため

自分としてはなんかあくびとかくしゃみとか居眠りぐらいの位置づけであり、あまり気にしないでほしい。

居眠りしながら仕事してる人間もいてそれが黙認されてるくらいゆるい会社なので

泣くことも許してくれないかなあとおもう。

なお今日も泣いてしまった。

きっかけはエンジニアのおじさんに理系特有早口でしゃべられた上長赤字メールを送りつけられたからだとおもう。違うかもしれない。

そういえば職場で始めて泣いたのはおじさんからバカかいフォントの指摘メール送られてきたときだった。

なんでこんなにおじさんから圧かけられがちかというと、この分野の知識が本当に本当になく不勉強からだ。

弊社はメガバンクSIer会社なのだが、自分最近までwebアプリの開発を担当していた。eclipsejavajQueryUNIXでshellだったのだ。

それが今のチームに異動となり、分野は一変、メインフレームでzOSでcobolファンクションキーになったのだ。

最初はわからないことが多いけど弊社主力の分野なので頑張ろうと思った。社内研修かたっぱしからでてメインフレームで遊ぼうよんで

がんばってついてこうとした、でも座学だけでは知識は身につかなかった。

手を動かしたかったが、Sierとはコードは書かないし資源引き揚げもしないみたいだ。

そういうのは製造委託先のエンジニア達の仕事で、では我々は何をするかというと、エンジニアさんの作った内部設計書、

テストケース成果物一覧、スクリーンショット確認するのである

でもそもそも何が確認観点で何がまちがってて何がどうなってれば正しいのかよくわからないのだ。

自分会社上司先輩に聞きたかったが、ある程度スキルをもった上司先輩は業務忙殺されておりもはやふだんどこにいるかよくわからない。

というのも近年弊社では超大規模プロジェクトが発足しており、

ある程度スキルをもった人間はそちらに根こそぎもってかれてしまっている。

自分はメインは運用保守メンテナンスチームなので、そういう上司先輩とは関わりがない。

たこプロジェクトでごっそり人がもってかれてるためメンテナンスチームの人間が少ない。なのでとにかく一人あたりの作業が膨大なのだ

そして作業内容は前述のとおり。委託先のつくった成果物をチェックし、品質関連の定型的な資料をつくり、承認する。

なにをみたらよいかからない成果物がどんどん送られてきてどんどんチェックしなければいけないのがつらい。

なにをしたらいいかからないことをどんどんしなければならないのがつらい。

そういうタスクがどんどんたまると涙がじわじわでてくる。

どう確認したらよいかからないけど聞く人もいない。

同じメンテナンス担当の先輩にきいてもよくわからないと返答がきたので

今日エンジニアのおじさんに聞いたら

いまさらなにをそんなこと聞くんだみたいな雰囲気をにおわせながら

理系特有早口でいまさらそんなこと確認しても意味ないですっていわれたからもうめんどうくさくなってしまった。

でもかつてはソースかいテストして資源ひきあげする立場だった身をしては、ちゃん確認したい気持ちがある。

でも同時に、とんちんかん質問する担当者に対してエンジニアイラっとする感覚も容易に想像つくので

もうなにもかもめんどうくさい。

明るくない分野の仕事をてさぐりでやらなければなければならないのがめんどうくさい。

何の意味があるかわからない資料を大量につくる仕事がつらい。

チェックシートに日付をひたすら埋める仕事がつらい。※つじつまをあわせるために、全て同じ日付にしてはならない。

ぐちゃぐちゃのエクセルをぐちゃぐちゃにする仕事がつらい。

これらをやらなくてもどうせシステムちゃんうごくのがわかってるから尚つらい。

かつてソースかいテストしてた時代は、ネットにあふれるイシキタカキラキラサイシンギジュツブログ

自分担当しているつまらなくぱっとしない時代遅れのwebアプリに不満を感じていた。

テストといってはひたすらスクリーンショットを延々と印刷する作業にいったいなんの意味があるのだろうと思っていた。

でも今の自分よりはるか意味のある仕事だった。

昨日Qiitaメインフレーム関連の記事をあさっていたところ、zOSではteraTermによりUNIXライクな操作ができることを知った。

また、ftpが使えることも知った。ということはffftpが使えるかもしれない。希望の光に見える。うれしい。すごくうれしい。

USSが使いこなせればもうすこしこメインフレームまわりに馴染みやすくなるかもしれない。

※補足

みずほではないです。とばっちり申し訳なかったので補足です。

2018-04-04

SEってなんの仕事をしているのだろうか

今は金融職だが、以前の職場や古い付き合いでSEという職種がいた。

ただ話をしてみると答えがまばらでなんのしごとをしているかわよくわからいかった

A コボルなるものを使ってうんたらかんたら 

B オラクルゴールドでうんたらかんたら

C メインフレームがうんたかんたら

D Webがうんたらかんたら

E アクセンチュアがうんたらかんたら

F NTTがうんたらかんたら

彼らは何の仕事をしているのだろうか

2018-03-06

n=1だけどいまどきメインフレーム仕事してページプリンタジャーナル吐きまくる我が職場

月一の保管期限切れドキュメント廃棄は完全に男性だけの仕事だな

2018-02-15

電子通貨は国が管理すれば問題がない。例を示そう。

基本的仕様

プライバシー

セキュリティ


子供

予算

他の政策

教育

メリット



データ形式

{
	'transaction':[
		'key':'some_token_like_SHA-2',
		'descriiption': 'bar',
		'from_wallet': 1234567890,
		'to_wallet': 0987654321,
		'total_amount': 9999999999999,
		'tax_amount': 999999999999,
		'timestamp': yyyymmddhhmmss
	]
}

ブロックチェーン、電子通貨は国がやるメリットが大きい。さよなら仮想通貨

2017-10-13

俺は役所側のシステム担当だけど

https://anond.hatelabo.jp/20171012165214

うちのプロジェクト普通に成功したので特に面白い話はない。

つーか失敗が稀だからニュースになるのであって、実際は成功するのが大半だよ。

そもそも入札してもらえないと始まらないので、仕様書にあまり無茶なことは書けない。

開発中に新規要件が出ることはあるけど、こっちだって完成しないと困るから適宜調整するし、無理な分は来年度以降の課題ということで先送りする。

その結果市民からは「不便すぎる役所死ね」と叩かれることもあるけど平謝りするしかいね…。

なので京都市ほどこじれるのはうちの役所では考えられん。

まあメインフレームはどんどん消えてくし、異動があるとはい組織内でのノウハウは蓄積されるし、特許庁みたいな反面教師を挙げて庁内を説得できるようにもなったし、どこも段々と良くなってくんじゃないかなー。

公務員から成功しても失敗しても給料は(ほぼ)変わらんけどな。

京都市システム開発トラブルに対する雑感

http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/

https://anond.hatelabo.jp/20171012165214

市町村役場で大規模開発が必要システムと言えば住記・税・福祉系の3つだが、この中でも福祉系がぶっちぎりで地雷

住記:住民票管理住民票はほぼ全国統一フォーマットなのでシステム移行は容易。

税:市町村の税で大きいのは住民税固定資産税軽自動車税。細かい税率は違うが基本の計算式はほぼ全国統一されてるのでこれも移行は容易。

福祉系:一言福祉系というが、その範囲は多岐にわたる。

国民健康保険住民への給付保険料徴収等。

国民年金運営日本年金機構が行っているが、申請受理審査の窓口業務市町村

高齢者福祉系:介護保険後期高齢者医療介護予防等。

障害者福祉系:障害者手帳交付自立支援医療給付・通所サービス・その他医療費助成(重心)等。

児童福祉系:児童手当・児童扶養手当・保育(保育園幼稚園)・妊婦健診・その他医療費助成(小児慢性や養育医療)等。

生活保護生活保護認定給付

保健所系:健康診断難病対策医療費助成)・予防接種等。

これらの業務それぞれが国・県から権限移譲されたもの市町村独自のものが混在している。

市町村ごとに千差万別と言っても過言ではない。また、普通市町村中核市政令指定都市でも、どこまで権限があるかは異なる。

これらの業務を全て1つのメインフレーム運用しておりそれを新しいものに入れ替えるだけ、

であれば話は簡単なのだがもちろんそんなわけはない。

これらの業務根拠法令が成立して制度が始まった時期がバラバラなため、そのたびに入札を行って新たにシステムを構築する羽目になる。

そのため、役所内にメインフレームと、異なるベンダー・異なる言語パッケージが乱立する状態になる。

京都市は今回そんな状態を解消すべくシステムの一括更新を試みたがプロジェクト炎上した、と推測する。

パッケージ業務を合わせろという指摘、業務役所の内部だけで完結するシステムなら簡単

人事給与財務や決裁のシステムであればどこの役所業務を適宜修正してる。

問題仕様変更住民に影響を及ぼす業務印刷物を送って申請をしてもらわなければならない類のもの)。

毎年送られてくる役所から文書が変わると混乱してしま住民の方はものすごく多い。

もちろん事前に今年からこのように変更になります、とお知らせはするんだが読まない方は読まないので。

京都市レベル大都市役所から書類が全部いっせいに変更なんてことになったら、

問い合わせと苦情で窓口電話口は間違いなくパンクする。

なので、対外的住民に出す文書様式は従来のものから変更はなしで、という仕様になりがち。

京都市の件でもオンライン処理は無事稼動したが帳票印刷のためのバッチ処理の移行で躓いたとあったので、

おそらくそのへんの印刷物仕様で揉めたのではなかろうか。

2017-10-12

京都市が今回失敗したような、自治体システム更新について

http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/

Q1.役所仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの?

A1.地方自治体事務財務について法律で決まっているのは大枠だけだよ。

  それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセス全然役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。


Q2.なんで新規で作らないの?

A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市更新しようとしてるような、メインフレーム上のシステムだよ。


Q3.メインフレーム汎用機)って何?

A3.みんなが使ってるWindowsとかLinuxとかのOSがなかった時代コンピュータだよ。IBMとかがベンダーごとに作っていてOSベンダー謹製だよ。性能はいいけどメチャ高いよ。

システム内でクローズして専用線以外では他とつながってなかったから、汎用機からPCサーバへの移行を「オープン化」と言うよ。

オープンソースソフトウェアとは全然関係ないよ。


Q3.使いまわしってどうやってやるの?

A3.80年代かに作ったシステムで動いてるCOBOLとかPL/IとかをLinuxとかUnixとかWindows上で動く言語コンバートしてリコンパイルするよ。

DBデータ階層データモデルからリレーショナルDB用にコンバートして移行するよ。こういう開発形態を「マイグレーション」と呼ぶよ。

あと、バッチジョブ制御もJCLという汎用機用の言語で動いているよ。これもそのままでは動かないのでコンバートするよ。

コンバート先はperlだったり、シェルスクリプトだったり、ベンダごとの独自スクリプトだったりするよ。

COBOLとかの実行プログラム移行も大変だけど、帳票の大量印刷はたいていバッチジョブでこなしてるので、JCLの移行もめちゃ厄介で大抵もめるよ。

今回もめたのもバッチらしいね


Q4.80年代のものを使いまわすとか。新規で作ればいいじゃん

A4.お金無限にあればできるよ。今の時代お金があった時代システムフルスクラッチ再開発するととんでもない予算になって市役所内の決裁が通らないよ。

しか汎用機時代の納品は割といいかげんだったのか、仕様書が残ってなかったりするから費用さらにかさむよ。


Q5.そんなんでよく運用できてたな

A5.当時はSE汎用機付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。

そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。

マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね


Q6.役所が現行システム資料を出すべきだろうが!

A6.もっともだけど、できないから無理だよ。

上記の通り仕様書がないことも多いうえ、システム課に限らず市役所人員は基本ローテーションするよ。

導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機ことなんてここ10年に入った職員にはわからないよ。



Q7.なんで入札にしたの? 現行ベンダ指名してやらせたほうが良くない?

A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。

随意契約(随契)は無理だし、入札業者発注者指定する指名競争入札談合の温床になってたか最近あんまりやらないよ。


裏技としてRFP指名したいベンダーに書かせて公募指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね



Q8.じゃあ役所は悪くないの?

Q8.悪いよ。

入札案件RFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。

なので、技術点の項目に現行システム調査にかかる項目を入れるとかして、現行機の開発・保守ベンダ高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。

もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社めっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。



Q9.じゃあベンダーは悪くないのか?

A9.ここまで述べたようにこの手のマイグレーション火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。

安すぎる見積もりを出したSEだか営業だかは死んでね。



Q10.お前(増田)は何者?

A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね

  しょぼいSEからここに書いたことは個人体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。





(2017.10.13 追記)

Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。


あと、「オープン化」の定義が違くない?という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。

メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。

これに対しPCサーバ標準規格で作られているよ。こういう標準規格に基づくサーバオープン系と呼ぶよ。

独自規格クローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。

京都市で火中にいるシステムズさんのサイト解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ

http://www.migration.jp/column/column01.html

完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。

H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。

オープン化(オープンではない)みたいなことになって面白いよ(面白くない)

2017-08-26

https://anond.hatelabo.jp/20170826233411

メインフレームCOBOLについては、言語には責任はない。

仕様がわからないんだ。

銀行同士で違うシステム使ってるって時点で察しろ

あと、オブジェクト指向が判れば、もう大体言語による差なんて小さいと思うけどね。

WindowsPowerShellはクソだけど。

https://anond.hatelabo.jp/20170826232407

プログラム言語なんぞプラットフォーム次第だろ

メインフレームはまだまだCOBOL全盛なんだぞ

COBOL死ぬ死ぬ言われてるけれど、恐らく今後も使われ続ける

2017-06-10

幸せのために競争するんじゃないよ

将来死なないで済むために、競争するんだよ

ガチンコ競争死屍累々の山を築く、そりゃもう悲惨なことだ、そんなことは分かってる

でも余所じゃそれをやってるし、その結果の技術革新が生まれ

ドロップアウトして安穏としてりゃ、いずれ黒船に全部持っていかれる

メインフレームスパコンPC、全部そうなったよね

まだ繰り返すの?

少しずつ犠牲者出しながら切磋琢磨するか、全滅エンドにレッツゴーするか、どっちがいいのよ

http://anond.hatelabo.jp/20170610163114

2017-06-06

SI(メール右から左へ受け流すお仕事)

入社3年目までwebアプリを開発する部署所属していたのだけど、

4月から業務系のシステムを取り扱う部署へ異動になった。

これまではjavaソース書いたりしてたけど、

今度担当するシステムの中核はcobol?という言語構成されているらしい。

といっても今度の部署は、下流工程ソフトハウスさんに投げてしまうので、

これからの主な仕事は、発注元の「業務フロー変えたいかシステムもこんな感じに変えてくれ〜」

みたいな要件を聞いて、それをソフトハウスさんに伝えて開発してもらう、

いわば橋渡し役みたいなものになる。

全く異なる毛色の部署からの異動だし、なんとか手探り手探り手探りで4月から業務をしてみたけど、

この、発注元とソフトハウスさんの橋渡し役って、何の利益を生み出してるのかよくわからなくなってきた。

この橋渡し役は、「システムのことわからない発注元の要望を、システム仕様翻訳する」という役割があるらしい。

だけど、このシステム発注元はちゃんと要望システムチックに出してくれるんだよね。

先日受けた、エラー時のチェック仕様変えたいですっていう要望についても、

要件書の記載がそのままif文作れるような文章になっているので、

僕はそれを受け取って、いくつか申請書を作って、あとはソフトハウスさんに要件を伝えるだけ。

それで設計工程での僕の仕事ははおしまい

また、テスト工程でもあんまり特に何もしてなかった。

というのも、COBOLとかメインフレームとか、まだ圧倒的に知識不足の為、

ソフトハウスさんが作ってくれた成果物実施してくれたテストの証跡を検証できないんです。(ごめんなさい。)

テスト証跡ではなく、「テスト結果の報告」をチェックして、それをもとにいくつかのチェックリスト作って提出して、

発注元に完了報告してテスト工程おしまい

一連の工程がなんだかよくわからないうちに完了して、

その結果がなんだがよくわからないうちにシステムに反映されていた。

この仕様変更について僕がやったことといえば、

·発注元の要件書をソフトハウスさんに転送する

·いくつかの申請書をつくる

·ソフトハウスさんのテスト結果報告に対して「確認しました。対応ありがとうございました。」と返信する。

·いくつかのチェックリストをつくる

·発注元に完了報告をする

くらいだ。

エクセルメーラーしか触ってないのに、いろんなことがトントン進んでいくのが不思議だし、

こんな業務にもちゃんとお給料が発生するのがいちばん不思議だ。

·······。

もっと月日が経って、色んな仕事任せてもらえるようになったら、また振り返ろうと思う。

悩み

メインフレーム知識つけたいなあ

おすすめ方法などあったらおしえてください。

周囲の先輩方もあんまりわかんないようだ。

···「内部のロジックなんて読めなくてもなんとかなるよ」なんて言われるし、

ひとつひとつを深くこなす、みたいなのがイレギュラー、という空気を感じるけど

まだその空気に慣れてない。

やっぱり中身知りたいし、テスト結果はなるべくナマに近い証跡で確認したいな。

2017-03-12

書き換える必要なくね?

大企業銀行で、昔から動いている基幹システムは、大抵メインフレームCOBOLの組み合わせである

それをここ十年くらい、リプレースx86サーバJavaという構成に変更することが多い。

しかし、ハード汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。

ぶっちゃけCOBOLCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは?と思うのだ。

その理由はこうだ。


COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。

勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOL文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである

そういうモノが既にある企業銀行文化において、当然発注側は担当者からお偉いさんまでCOBOLerフローチャート脳だし、新しいシステム設計でもそれを踏襲しようとする。

というか踏襲すること前提じゃないと設計書をレビューできない。

UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。

というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法設計書で処理を組み上げざるを得なくなる。


そうなると、実装フローチャート設計を基にコードを書くわけだが、こういう設計ハッカー文化で発展してきた言語(FortranC/C++Javaという流れと、PerlからPythonPHPというインタプリタ系の諸言語)との相性が最悪である

設計とは実装を楽にするために書くのに、これらの言語において、フローチャート設計は役に立たないどころか、邪魔しかない。

からFortranしかなかった頃から、本物のプログラマ達はフローチャートdisってきたわけである

ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である

しかし、「普通人達普通思考からはかけ離れ過ぎているという意味で、「普通人達普通仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。

…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLアセンブラ選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。


というわけで、自分COBOLからリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。

COBOLリプレースするのでない限りは。

2016-12-03

宙船モーレ 聖地巡礼の旅 ~迫るセンテンススプリングの脅威~

宙船モーレ号がH28植民恒星系を離脱してから、すでに300日以上が経過していた。

副長、主機の調子はどうかね?」

「はっ、PPAPの出力は99.89%でほぼ安定。マイナス金利の影響で一部トランプ現象の発生が見られますが、聖地巡礼には支障のないレベルです」

「そうか。引き続き、ジカ熱を絶やさぬようアスリートファーストで頑張ってくれ」

了解です」

「か、艦長!」

「どうした、先任通信士?」

通信です!」

「どこからだ?」

「それが……。この周波数は、おそらく『センテンススプリング』……」

バカな! センテンススプリングは、とうの昔にゲス不倫の影響でSMAP解散したはずだ」

しかし、この復興城主特有民泊は、どう考えてもセンテンススプリングのものしか……」

「推測はいい。すぐに確認を取りたまえ」

「り、了解。副通信士、通信だ!」

「はっ。レガシーレガシー。こちらはH28植民恒星系第5惑星シン・ゴジラ所属宙船モーレ未確認通信の発信者に問う。君の名は。

「…………」

「こちらはH28植民恒星系第5惑星シン・ゴジラ所属宙船モーレ通信に応答せよ。君の名は。

「……返答はまだか」

艦長。もしやこれは、おそ松さん陰謀では?」

分からん。だが、いざという時にはすかさずEU離脱できるよう、主機を都民ファーストに変更しておけ」

了解しました」

「……へ、返答ありました! こ、これは……!」

「どうした! 報告しろ

目標より返答。『斎藤さんだぞ』……以上です!」

いかん! 総員、第一種戦闘態勢! 文春砲直ちに発射準備に入れ!」

「駄目です! 斎藤さん、タカマツペアを展開しました。歩きスマホ盛り土を散布しています!」

「びっくりぽん」

艦長、このままでは文春砲使用できません。新しい判断を!」

《ホイクエオチニッポンシネ……ホイクエオチニッポンシネ……》

「こ、この音声は?」

斎藤さんが一般回線を通じて強制割込を行っています! 本艦のメインフレームにも斎藤さんの侵入確認!」

くそっ。斎藤さんの狙いはパナマ文書か」

艦長、もはやAIが止まりません!」

「ぬうぅ。かくなる上は、あれを使うしか……」

「ま、まさか! 駄目です、艦長。あれは危険過ぎます

「事ここに至っては他に手段はないだろう」

しかし……」

「……命令だ、副長ポケモンGO!!!」

艦長英断によって使用された未完の最終兵器PokEMONが放った「くまモン頑張れ絵」は、その神ってる威力によって、斎藤さんを一瞬でマイナスイオン水素水還元した。

窮地を切り抜けたアモーレ号は、予想外のアクシデントで遅れた日程を取り戻すため、盛り土転換によるジカ熱PPAPの出力を120%にして、一路、母なる惑星地球を目指すのであった。

ポリティカル・コレクトネス

2016-07-08

からみずほ銀行の開発拠点を見てみよう 中目黒

https://www.google.co.jp/maps/place/@35.6386097,139.6999833,521a,20y,41.58t/data=!3m1!1e3!4m5!3m4!1s0x60188b48682c837f:0xa07320890573c72c!8m2!3d35.6427516!4d139.6999923

みずほ情報総研 中目黒事業所(オーク中目黒ビル

みずほ銀行PJの陣頭指揮を取っているはずのみずほ情報総研、開発拠点は全国にありますがその中でも有数の規模を誇るのがこの中目黒です。

毎日夜遅くまでフロア電気が付いているそうですが、大変ですね。

みずほ銀行 中目黒センター(旧富士銀行 中目黒電算センター

Google Mapで見ると室外機が沢山載っている、まるで要塞のような建物が見えると思います

ここはみずほ銀行システムの中核をなすデータセンターの一つです。

IBMメインフレームが沢山入っていたそうですが、今後はどうなっていくのでしょうか。

ちなみにこの建物建築業協会賞を受賞しているそうです。かっこいいですしね。

みずほ情報総研 中目黒出張所(秋元ビル

中目黒センターの南にある、駒沢通りに面したちょっと変わった形のビル秋元ビルです。

ビルオーナーは1階で秋元商店という酒屋さんをやっており、

ここの数フロアみずほ情報総研事務所として借り上げています

みずほ関連の怪文書中目黒という単語が出てきた場合中目黒駅近くのみずほ建物ではなく

このビルのことを指しています

秋元ビル中目黒センターの間には、自販機と灰皿が設置されているのですが

朝の九時頃には首からMIZUHO」のカードキーを下げた方々が大勢喫煙されています

どんな立ち話をしているのか、気になりますね。

からみずほ銀行の開発拠点を見てみよう、今回はおしまい

次回は多摩が出来たらいいですね、では。

アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん