  |
はてなキーワード: Cobolとは
http://itpro.nikkeibp.co.jp/atcl/column/14/346926/101101158/
Q1.役所の仕事なんて全国でほぼ一緒なのに、なんで自治体ごとに別のシステムを作るの？
A1.地方自治体の事務や財務について法律で決まっているのは大枠だけだよ。
それを実務≒内部規定に落とし込むのは各役所ごとなので大枠は似てても実務プロセスは全然各役所で違うよ。例えば同じ業務でも独自の語彙があったり、下手すると同じ語で市町村ごとに意味が違ったりするよ。
Q2.なんで新規で作らないの？
A2.80年代ぐらいにやったよ。その結果が政令市クラスに残ってて今回京都市が更新しようとしてるような、メインフレーム上のシステムだよ。
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が汎用機の付属品みたいについてって、困ったらオペレーターとして介入して動かしていたみたいだよ。
そうやって現場感覚バリバリでやっているので、オペレーターしか知らないプロセスがあったりするよ。
マイグレーション開発では総合テスト中にそういう隠しプロセスが「発見」されたりするよ。こわいね。
上記の通り仕様書がないことも多いうえ、システム課に限らず市役所の人員は基本ローテーションするよ。
導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機のことなんてここ10年に入った職員にはわからないよ。
Q7.なんで入札にしたの？ 現行ベンダに指名してやらせたほうが良くない？
A7.金額がでかいから、たぶんどこの市役所でも入札案件だよ。
随意契約（随契）は無理だし、入札業者を発注者が指定する指名競争入札は談合の温床になってたから最近はあんまりやらないよ。
（裏技としてRFPを指名したいベンダーに書かせて公募型指名入札にしたり、RFPの段階でハードを全部特定ベンダで型番まで指定するというのがあるけど、公になると多分問題になるよ。こわいね）
Q8.じゃあ役所は悪くないの？
Q8.悪いよ。
入札案件はRFPで書かれた各項目をどれだけ満たすかの技術点と、価格点で決まるよ。点が高ければだいたい自動的にそのベンダーに決まるよ。
なので、技術点の項目に現行システムの調査にかかる項目を入れるとかして、現行機の開発・保守ベンダが高得点を取れるようにしておけば価格勝負してくるベンダーをはじけた可能性はあるよ。
もちろん現行の会社に嫌われて逃げられたとか、役所が現行の会社をめっちゃ嫌いになって声をかけなかったとかもあるかもしれないけれど、可能性は低いと思うよ。
A9.ここまで述べたようにこの手のマイグレーションは火薬庫だよ。火を噴いても爆発しなければラッキーぐらいなので、強いて言うなら入札したことが悪いよ。
A10.前にマイグレーションをやったことがあるSEだよ。もうやりたくないよ。今は転職してSIerじゃなくなったからやらなくてよくなったよ。うれしいね。
しょぼいSEだからここに書いたことは個人の体験に基づく参照情報だよ。一般的じゃないことを言ってたり、間違ってたら教えてもらえると助かるよ。
(2017.10.13 追記）
Q3がかぶっていたよ。恥ずかしくてなきそうだけどブコメに番号で言及してくれている人がいるから忍んでそのままにするよ。
あと、「オープン化」の定義が違くない？という指摘があったよ。確かに増田が間違っていたので、記事の主旨から外れるけど補記するよ。
メインフレームは本文で述べたようにOSからハードまでメーカー謹製なので独自仕様のカタマリだよ。
これに対しPCサーバは標準規格で作られているよ。こういう標準規格に基づくサーバをオープン系と呼ぶよ。
独自規格でクローズしたコンピュータから、そうでないオープン系に移行するからオープン化なのであって、専用線とかは関係なかったよ。半可通な知識で語ってしまったよ、ごめんね。
京都市で火中にいるシステムズさんのサイトの解説がこの増田よりも分かりやすくて正確だから気になる人は見てほしいよ
http://www.migration.jp/column/column01.html
完全に余談だけどオープン系のx86サーバに移行しても、システムはそんなにオープンにならなかったりするよ。
H系に頼むとDBが拝承DBになったり、Fに頼むとシステム管理が全部SystemWalkerになったり、要するにベンダ独自のミドルに入ってがっつりロックインされたりするよ。
誰か墓に入れてやってくれ
COBOLを育てた親たちは
もう、プログラミングのプの字すら知らない
死体を回収して新しい人に仕事を任せることすら困難になってしまった。
COBOLは処理が早くて10進計算が得意だから変えられないとはよく言ったもんだ
部署全員が長くCOBOL1割とエクセルしか触ってないから新しい言語に切り替える予算がないのだ
ZIPファイルの解凍方法を聞かれて教えるみたいな仕事をしてる
このまま俺はコボラーとして生きたくはないし
生きていくつもりもない
====
入社して2か月で都市伝説だと思ってたエクセル方眼紙を業務で見たぞ
その当時付き合っていた彼女が大好きで地元就職にこだわった結果
いざ会社に入ってみればエクセルしか触れないやつらの部署に配属されてしまった
規模がおっきい会社に入れば研修やらなんやらで金かけて貰えると思ったんだけどな
システムの設計とかDBの設計とか勉強させてもらえると思ったんだけどな
うける
隣の席の人に質問しようとして
この人たちは何も知らない
早く辞めてやる
転職するんだ。
既存の資産をそのまま使いまわして同じ相手とこのあと40年取引するとか考えられない。
好きでせっかく勉強してきたことが
忘却の彼方へ行ってしまっていることがとても怖いし焦りでしかない
ただの愚痴
わざわざつけなくても文脈でわかるよね。
つけたほうが紛れがないってことなら、
「Raspberry PiとGo言語でミニトマトの栽培環境を監視してLINE Botで通知する」
みたいなのは
「Raspberry Pi端末とGo言語でミニトマトの栽培環境を監視してLINEアプリ Botで通知する」
と書くかというとそんなことは絶対ないし。
－－追加
Goじゃわからないとかつけたほうが優しいみたいな人がいるけど、golang.orgのドキュメントでさえ、golangみたいな書き方しないでGoとしか書いてないよな。
CだってC Languageとか書かないでただCと書くのが普通だし。
ーー追加
TPOとか状況に応じてつけろとかいい加減なこと言ってる人がいる。
常に付けなくていいよ。
明示するときは「プログラミング言語C」みたいに文章の最初に書くよ。あとはC。
English語とか、Japanese語みたいな書き方変でしょ。C言語とかCOBOL言語みたいな書き方おかしい。
イングリッシュ語と書くのが適切な状況ってどういう状況だ。
FとかNとかHみたいな大手SIerがどうすれば再生できるか考えてみた
何の役にも立たない人間が非常に多い。
設計も書けない、実装も出来ない、マネジメントも20年前の開発手法で止まってるので無理。
しかもそういう人間に限って、無駄に社内のランクが高いのでプロジェクトの予算を圧迫する。
Java出来る若手2名分の金を食う上、行き場がないからとりあえず余裕がありそうなプロジェクトに配属されて予算を圧迫する。
その結果、プロジェクトは無駄に炎上し、前途有望な若手はSIerを見切って外に出ていく。
この工程を3～5年（技術が大きく変わる大体の期間）で繰り返せばいいのではないか？
この間数えたら社会人になって15年経過してた。
初期のころの職務経歴書を読み直していて、当時の上司たちと同じくらいの年齢になっているわけだけど、
今から見返してみて、何故あんな連中と働かなきゃいけなかったのか理解できない。
いやいいんだよ。経験年数重ねてても。
まともに業務内容が説明できない。身なりは汚い。くさい。くちゃくちゃうるさい。
資料は独りよがり。コードもファイリングもぐちゃぐちゃ。レビューもできない。
顧客が自分よりも新人の俺のほうが話が分かりやすいということで間に立とうとしたら拗ねる。
時間のコントロールもできないから、平気で残業を強要する。俺の家お前より片道一時間通勤が長くかかるんですが。
今ほぼ変わらない年齢なんだけど、なぜあんなにできない人間の下にいなきゃいけなかったのか。
考えてみたら配属の希望なんて一度も聞かれず、全く希望しない部署に回された。
学校のコネでもなんでも、別の会社に入っておけばよかったと数年後悔した。
このころCOBOLとかやらされたおかげで未だに求人に突っついてくるけど、俺そのあとAWSとかSalesforceとかいじってるから。
全くやる気ないからCOBOLとか。経歴書にCOBOLという汚れがついているような気がしてしょうがない。
（しかも設計書の記述を手書きで定規使ってやらされてた。当時EXCELやVISIOがあるにもかかわらず、だ。
苦労を人に継承させる類の効率化の図れないバカばっかりだった。）
退社後、自分のいた会社はパートナ契約切られ、優秀な人はやめるなり、親会社につれていかれたらしいけど、
残された人は悲惨なもので自分から命を絶った人も現れてニュースにもなったらしい。
正直あんなところにいたら死にたくもなるよ。
大きく成長させてもらえたと思う。でもごめん。やりたい事に遠くなるのはつらい。
今回の転職活動で職務経歴書書き直すまですっかり忘れてたんだけど、
新人時代から7年をカスみたいな環境で身をやつしたの、こうやって見返すと勿体ない。
今新人で、業務内容も実質大手の下請けみたいなことつかまされて周りがバカばっかりな職場にいる20代
引用元：http://www.kantei.go.jp/jp/headline/pdf/seicho_senryaku/2017_all.pdf
入社3年目までwebアプリを開発する部署に所属していたのだけど、
今度担当するシステムの中核はcobol？という言語で構成されているらしい。
といっても今度の部署は、下流工程をソフトハウスさんに投げてしまうので、
これからの主な仕事は、発注元の「業務フロー変えたいからシステムもこんな感じに変えてくれ〜」
みたいな要件を聞いて、それをソフトハウスさんに伝えて開発してもらう、
いわば橋渡し役みたいなものになる。
全く異なる毛色の部署からの異動だし、なんとか手探り手探り手探りで４月から業務をしてみたけど、
この、発注元とソフトハウスさんの橋渡し役って、何の利益を生み出してるのかよくわからなくなってきた。
この橋渡し役は、「システムのことわからない発注元の要望を、システム仕様に翻訳する」という役割があるらしい。
だけど、このシステムの発注元はちゃんと要望をシステムチックに出してくれるんだよね。
先日受けた、エラー時のチェック仕様変えたいですっていう要望についても、
要件書の記載がそのままif文作れるような文章になっているので、
僕はそれを受け取って、いくつか申請書を作って、あとはソフトハウスさんに要件を伝えるだけ。
というのも、COBOLとかメインフレームとか、まだ圧倒的に知識不足の為、
ソフトハウスさんが作ってくれた成果物、実施してくれたテストの証跡を検証できないんです。(ごめんなさい。)
テスト証跡ではなく、「テスト結果の報告」をチェックして、それをもとにいくつかのチェックリスト作って提出して、
その結果がなんだがよくわからないうちにシステムに反映されていた。
この仕様変更について僕がやったことといえば、
·いくつかの申請書をつくる
·ソフトハウスさんのテスト結果報告に対して「確認しました。対応ありがとうございました。」と返信する。
·いくつかのチェックリストをつくる
くらいだ。
エクセルとメーラーしか触ってないのに、いろんなことがトントン進んでいくのが不思議だし、
こんな業務にもちゃんとお給料が発生するのがいちばん不思議だ。
·······。
もっと月日が経って、色んな仕事任せてもらえるようになったら、また振り返ろうと思う。
悩み
···「内部のロジックなんて読めなくてもなんとかなるよ」なんて言われるし、
ひとつひとつを深くこなす、みたいなのがイレギュラー、という空気を感じるけど
まだその空気に慣れてない。
親父様は酒と野球とギャンブルが大好きなクズだったが、浮気と無職と借金だけはしない洗練されたクズだったので最低限の生活は保てていた。
鼻水を垂らしたまま何も考えず中学生になった僕は、そのまま何も考えず地元の底辺工業高校に進学した。
大学進学率0.3%未満の絵に描いたような地域密着型就職支援高校だった。
バカ、貧乏、次男坊のフルコンボを駆使し田舎を出て神奈川の大きな工場に就職した。
「僕ぁ、こんな事をする為に高校でプログラムを覚えたわけじゃないんですよねえ」等と同期のヤンキー達に吹聴してたら流れ的に辞めるしかなくなった。
とはいえ、ホントはプログラムなんか言う程できたわけじゃないので、どっかの会社に応募して落とされたら、周りも納得するかーなんて軽い気持ちでテキトーに選んだ会社に応募したら内定きた。
その会社でアセンブラとかいうミトコンドリアみたいに原初なプログラム言語を叩き込まれた。
おかげで、CだろうがCOBOLだろうがC#だろうがJAVAだろうがハイソサエティだよね、て気持ちになれた。
結局そのままいろんな会社を転々としつつもプログラムの仕事を今でも続けられ、不自由なく暮らしていけてる。
僕の未来予測では35歳になるまでに、能力的に限界がきて、pepperくんに仕事を奪われ、飲んだくれた挙句、アル中で手の震えが止まらずキーボード打てなくなり、プログラム以外の仕事もできず、部屋に引きこもりxvideosばかり見てたら奥さんに愛想をつかされ、底辺高校に行かせるのがやっとの長男と、承認欲求をこじらせてニコ生やらツイキャスやらで裸体を晒す娘を連れて出ていかれるハズなのだ。今頃。
だが、現実はどうだ。
天海祐希似の奥さんと、映画やCMとかで使われるくらい良ロケ高校に通う長男と、部活に汗する健全な娘に囲まれ、それなりにシアワセに生きている。
小学校時代に道端で座り込んでた奇妙な婆さんに「お前さん、34で死ぬよ」と言われ、なるほどですねーと過ごしていたが、既にそのＸデーから十年以上経過しても元気に生きている。
たぶん、何十回か別の世界線で死んでるよね？僕。
じゃないと、そろそろ変な死に方しそうで怖い。
意識低い企業内研究者です。プログラミングはサブウエポン。だけど趣味でも勉強してる。
働き方改革のせいで早く帰れって言われて、酒のみながら今これを書いてる。
C言語とかC++は・・・これで作らないといけないものが今の所ないし、これでお金を稼ぐのはハードルが高いし、
WindowsのAPIを使って複雑なプログラムを作りたいわけじゃないのでwhileとかifとか基本的な構文だけ覚えるだけで満足。
組み込みプログラミングではC言語はいまだに現役。お金も普通に稼げると思うよ！次代のCOBOLと化しそうで怖いとこはあるけど。
Javaは・・・使える人が多いからあえて今から学習しなくてもいいような気がする。
文字列の結合だけでもダメやり方と良いやり方があるらしくて、何かPHPのようにその言語特有のセオリーみたいなのを覚えるのが面倒くさそうなので入門の時点で学習するのをやめた。
セオリーとかあるかもしんないけど速度とか気に揉むまえに書いて測れ。たいていは杞憂か、あるいはCPUパワーで殴れるから。
Goは・・・HTTP/2が使えるから学習してる。他の言語だとnghttp2をインストールしないといけないようなのでGo便利だと思ってる。
ライブラリの選択肢が多すぎるのでこういうのが作りたいってときにこれを使うのがいいよっていうのが知りたい。
GUI作るのにライブラリありすぎてどうやって選べばいいのかさっぱりわかんない。
Goでデータベース扱うならこれを使え、だけどMySQLしか使わないならこれを使え、あっSQLiteならこっちのライブラリ使うと便利みたいなこういう情報が欲しい。
GoでGUIつくるの？あんまり普通じゃない気がする。軽量プロセスのうまみがそんなない（詳しい人に否定されそうだけど）
普通にC#(mono/.net)かwebアプリにするかで良くないか？
ただ、言語をあれもこれも覚えるのって僕は意味があるのかなという思いもある。
広く浅く学習するより、狭く深くいきたいとおもうけど、paizaでCランクしか取れない。
twitterで有名な人てやっぱりSランクとか余裕なのかな、こういうのもいろんなプログラマーに聞いてみたい。
一応著名なプログラマーをTwitterでフォローしてるけど、ご飯の画像を載せてたり、若者の僕には通じない寒いギャク連発してたり、ロリっぽい画像をRTしてたりと、twitterはメインの情報収集としては利用してない。
twitterやってるプログラマーって勉強会とかオフ会に参加してるようなリア充の人ばっかりなので、肩身が狭いから自分からリプは送ったりはしない。
ファンがたくさんいるのに最近ニコ生配信してくれないchokudai先生みたいに、アルゴリズムを学ぶのがいいのかな。
アルゴリズムは使うものだ書くものではない！高階関数とかテンプレートプログラミングとかその辺勉強するといい。
あと計算が制限時間内に終わるなら総当たりが最速で品質も高いぞ。
どうしてVimかというとプラグインが多いしIDEっぽくできるから。
Vimってハードル高いイメージあったけど、入門記事がたくさんあるので助かっている。
NetBeansが重すぎるんだよ。補完ボックスが表示されるの遅すぎて警告メッセージが出た。補完ボックスが表示されるまで7秒ぐらい経過すると警告メッセージが表示されたと思う。
Vim知らない。Linux使うならVimかemacs使えるだろみたいな雰囲気あるけど、GUIならgedit, CUIならnanoでいいよね。
パソコンのスペックもどのくらいのものを用意したらいいのかわからない。
10年前のVistaが搭載されていた頃の家電量販店で一番安かったCeleron 1コア メモリ1GB グラボなしノートだからプログラミングに向いてないのかもしれない。
VirtualBox上のubuntuでMySQLをコンパイルすると2時間20分ぐらいかかった記憶がある。
CPUが1コアなのでコンパイル中にそれ以外の作業なんて重くてできない。
スペックにお金をかけることで時間の節約ツールの選択肢が増える
EclipseなどのIDEが支障なく使えるレベルのスペックってどのくらいするんだろう。
3年前のCore i7, SSD, 8GB。最近はもっぱらJupyter。
Pythonは・・・・機械学習する上で避けて通れないけど、今のPCだと無理。
Pythonはいいぞ、機械学習だけじゃなく計算系はエクセルじゃなくてJupyter使う。でも周りはエクセルつかってる、勿体ない。
使ってないけど最先端の研究では機械学習使って当たり前感があってそろそろヤバい。
僕は中学生の頃、いじめにより心の余裕なんてなかったから勉強どころではなかったけどもっと英語の勉強しておけばよかったと後悔している。
迷宮にいる感じ。
なんとなく、プログラミングじゃないほうがいい気がするなあ。
http://s.news.mynavi.jp/news/2017/03/30/133/
この記事で、おやおやCOBOLが入ってないぞ？と私も思ったし、他の人も思ってたようだ。
なんでだろう。
個人的には、この21世紀にコボラーとかヤバい、という認識で今まで生きてきたのは事実だが、はて、COBOLで嫌な思いをしたことがあるかというと、幸いにもそんな経験はない。
むしろ、
・関わった人たちが、ちゃんとした金融機関(某大手地銀)とかちゃんとした元請け(N社)だったので、ムチャな開発にもならなかったし、お金もちゃんともらえた
・それまではJAVA専門だったが、COBOLの仕組みとかは勉強になった
・一緒に仕事したおじさんがすごい優秀で経験豊富な技術者で、いろいろ教えてもらえた
と、悪い思い出がない。
やっぱ、悪い言語があるわけじゃなく、向いてないのに無理に採用するのが良くないんだよね。
件のアンケート結果は、そういう傾向(向いてないのに採用)が、COBOLからVBにシフトしてきたということかな。
システムがすでにCOBOLで記述されており、稼働実績も十分。
なるほど、COBOL以外の言語に置き換える必要性などどこにもない様に見える。
ていうか俺も触りたくない。
そのまま鎮座していて欲しい。
大企業や銀行で、昔から動いている基幹システムは、大抵メインフレームにCOBOLの組み合わせである。
それをここ十年くらい、リプレースでx86系サーバにJavaという構成に変更することが多い。
しかし、ハードが汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。
ぶっちゃけCOBOLはCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは？と思うのだ。
その理由はこうだ。
COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。
勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOLの文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである。
そういうモノが既にある企業や銀行の文化において、当然発注側は担当者からお偉いさんまでCOBOLer系フローチャート脳だし、新しいシステムの設計でもそれを踏襲しようとする。
というか踏襲すること前提じゃないと設計書をレビューできない。
UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。
というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法の設計書で処理を組み上げざるを得なくなる。
そうなると、実装もフローチャートの設計を基にコードを書くわけだが、こういう設計はハッカー文化で発展してきた言語(Fortran→C/C++→Javaという流れと、PerlからPython・PHPというインタプリタ系の諸言語)との相性が最悪である。
設計とは実装を楽にするために書くのに、これらの言語において、フローチャートの設計は役に立たないどころか、邪魔でしかない。
だからFortranしかなかった頃から、本物のプログラマ達はフローチャートをdisってきたわけである。
ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である。
しかし、「普通の人達の普通の思考」からはかけ離れ過ぎているという意味で、「普通の人達の普通の仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。
…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLかアセンブラを選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。
というわけで、自分はCOBOLからのリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。
以前にJB●CというSIerに就職した中国人と話をしたことがあったが、まさに同じような状況でワロタ。
その会社でも中国から優秀な人材(北京大学の卒業者とか)を採用してるが、
彼もExcel仕様書と無駄に格闘したり、枯れた技術を使わされたり、客先から無茶な要求をさせられてるようだった。
彼のコードを読んだことがあるが、同じプロジェクトの日本人が書くコードより読みやすく、わかりやすいものだった。
逆に日本人のSEはというと、COBOLやRPGしかできなかったり、クソコードを書いたり、
