はてなキーワード: Cobolとは
俺の住む世界はアイティーとやらに支えられているらしい。
アイティーに関われば、俺の住む世界をさらに素敵なものにしていけるに違いない。していきたい。
そう願って、何も知らなかった文系新卒の俺が金融系のシステム会社に入って、もう一年以上が経つのだ。
昔、お遊びでゲームを作ったことはあった。RPGツクールなんかが好きだった。
パズルみたいで楽しかった。コンピュータの中身が理解できて、わくわくした。
楽々と基本情報技術者の資格を手にし、半年後にはほとんど勉強もせずにソフ開も取得した。
研修の課題では同期の誰よりも速く、短く効率のいいソースを仕上げた。
現場に出て、本番機に触った。
30年間親会社を支え続ける偉大なシステムの中身を、わくわくしながら覗いた。
そこには、俺の求めていた世界とはまったく違うものが広がっていた。
俺が産まれる前から、入れ替わり立ち替わり何人もの手によって継ぎ足されたロジック。
何千行にもわたって、似たような処理が何回もひたすら繰り返される似たようなモジュール何十本。
1993年に行う臨時処理のロジックが、今もコメントもなしに埋め込まれている。
仕様がわからなくなれば、キャビネへと走って、黄ばんだ方眼紙に鉛筆で書かれた仕様書を探し、
そして修正履歴のみが書かれているのを確認して肩を落とす。
半年後に臨時で行われる業務に対応するため、いくつかのモジュールについて、処理可能なユーザーコードをひとつ、条件に加える。
与えられた期間は2週間だった。ずいぶん長いなと思った。
何枚もの設計書を書いた。つまり、方眼紙状のExcelテンプレートに同じ文章をコピペした。
追っていったモジュールはどれも、ヒープもソートもメモリ管理も論理演算も出番がなかった。
あるのはただ、IF文とMOVE文とばかりだった。ソースの難易度は使われている命令の数とは関係ないことを学んだ。
テストデータを作るため、階層型DBを何回も辿ってデータをアウトプットさせるモジュールを書いた。資格試験で学んだSQLは、無用の知識だった。
協力会社への仕事割り振りやユーザー対応に毎日忙しそうだった上司が、夜遅くまでの残業続きでくまのできた目を皿のようにして設計書をレビューした。
2日後、承認が出た。フェーズが設計から開発に移った。
ロジックを丸々コピペしてソースを修正し、コンパイルし、実行した。
2週間はあっという間だった。
俺のせいで、半年後以降は使われないロジックがソースにまたひとつ増えた。
今回の対応については、Excel方眼紙にレポートをまとめて共有ドライブに入れておいた。
だが共有ドライブの検索には時間がかかるし、Excelシートの中身となれば検索から漏れることも多い。
きっと誰にも読まれないだろう。
2バイト文字が使えない関係上、原則、ソースにはコメントはあまり入れられない。
数年後の新人はきっと、俺の書いたモジュールを見て「このロジックは何だ」と首を捻るんだろう。
数年後の俺はきっと、今回のレポートを共有ドライブから探し回って新人にパスを教えてから、
協力会社の管理に追われる作業に戻って目の下にくまを作るのだろう。
俺がやりたかったシステム開発って、こんなものだったのか。
俺は部署の中で、俺の望む仕事を探し続けた。
先輩たちは忙しくて誰も興味を持ってないけど、自動化できる作業はいくらでもある。
よく使われるExcelシートを改造し、定例作業をクリックだけでできるようにした。
ExcelVBAとはいえ、書いていて心地よかった。引数が明確な関数と変数のスコープと全角文字があったからだ。
COBOLで打つプログラムより、控えめに見て100倍くらいの生産性を発揮できていたと思う。
先輩たちは喜んでくれたが、ただし俺の仕事を、あまり仕事とは見なさなかった。
それでもよかった。業務時間外は俺は相変わらずスクリプトを書いていた。とても楽しかった。
VBAから入って、WSHなんてものを知り、やがてJavaScriptを学び、ネットで資料を探し、はてなを知り、はてブでWeb技術についての記事を読みふけった。
知れば知るほどに、どんどんCOBOLが、メインフレームが嫌いになっていく。
先輩は誇らしげに言う。システムはたいしたことをやっていない。業務知識こそが大事なのだ。
ユーザーより詳しく業務を理解し、適切に提案し、設計する能力。
協力会社を率いて、わかりやすい文書で指示を行い、スケジュールを調整する能力。
人を動かすぶん、責任も大きくやりがいもある。優秀な人材こそが我が社の強みだ。
そんな人材が育つよう、我が社は安定して働ける環境と福利厚生を整えている。
ああ、そうだよ。先輩、あなたは正しい。
俺だってメインフレームの信頼性のすごさはわかってる。
密なユーザーとの関係から生まれるシステム子会社としての強みも認識してる。
それだけじゃない。社内環境も悪くない。給料もいいし休みも取れるし先輩は優しい。
ここは、いい会社だ。
けど駄目なんだ。
30年前のシステムを枯れた言語でツギハギする仕事じゃ、俺の心はやっぱり満たされない。
ユーザーの業務知識ばかり身につけたって、俺自身の人生には、いいことなんてない。
俺が求めていたのは、この仕事じゃないんだ。
社内の誰も、TumblrもTwitterもやっていない。ライフハックなんて聞いたこともない。
Joostやモバゲーや2ちゃんねるが社会に与える影響について誰も語れない。
休日はゴルフや酒に興じている。自宅にPCを持ってない人までいる。
おかしいことじゃない。普通の人たちだ。
それどころか彼らは、仕事とプライベートを切り分けている、立派な人たちだ。
でも、やっぱり俺の生きていきたい世界は、ここじゃないんだ。
たぶん俺がいるのは極北なんだろう。
ここが、人月計算とExcelとスーツの世界というやつなんだろう。
俺は80文字×32行の緑文字を見つめながら、遠い夢を見続ける。
http://anond.hatelabo.jp/20070719172216
・二人の船頭
要望を吸い上げるために打ち合わせをしてると、相手方の担当者二人がいつも細かい部分で言い争ってて、なかなか方向が決まらない。
・古株と新米
そして、その二人が古株と新米である事もよくある事。
古株は業務知識に長けているが、技術的な知識がCOBOL全盛期から進歩してない(たとえば、将来の拡張用にPADDING領域は作らなくて大丈夫?ってマジで心配する)ので、そこらへんでトンチンカンな意見を言う。
新米は最新技術に長けていても、業務知識が欠けているので、そこらへんでトンチンカンな意見を言う。
仲が良ければちょうど補完し合えていいのに、大抵仲が悪かったりする。
素人さんの作ったExcelシートは、一見、行×列に分けて綺麗に項目が整理されているように見えても、それはワナである。
このままデータベースのフィールド・レコードとして対応できると思ったら大間違い。
実際の運用ではイレギュラーなパターンが発生するたびに、その行だけ、普段使っている数式を消して手動で編集したりなんてことはザラ。
それも、「普段こんなシートを使ってる」と渡されたExcelシートには、決まってそのイレギュラーパターンが存在しなかったりするので、そういう運用の存在自体に気付かなかったりするもの。
上司ですら気付かなかったりするから、現場で一列一列確認する必要があったりする。なお、現場の担当者ですら全部の例外運用パターンをすぐ思い出せるわけではないのが、また困りもの。とにかく根気強く聞き出すしかない。
リンクつけわすれごめんなさい
http://anond.hatelabo.jp/20070508170219
こうですか?よくわかりません(><)
COBOLなんて需要無いか…
IDENTIFICATION DIVISION. PROGRAM-ID. FizzBuzz. ENVIROMENT DIVISION. DATA DIVISION. WORKING-STORAGE SECTION. 01 W-添字I PIC S9(09) COMP VALUE ZERO. 01 W-添字J PIC S9(09) COMP VALUE ZERO. 01 W-出力エリア PIC X(08). PROCEDURE DIVISION. FIZZBUZZ-MAIN. PERFORM VARYING W-添字I FROM 1 BY 1 UNTIL W-添字I > 100 MOVE SPACE TO W-出力エリア PERFORM VARYING W-添字J FROM 3 BY 3 UNTIL W-添字J > 100 IF W-添字I = W-添字J THEN MOVE 100 TO W-添字J MOVE 'Fizz' TO W-出力エリア ELSE CONTINUE END-IF END-PERFORM PERFORM VARYING W-添字J FROM 5 BY 5 UNTIL W-添字J > 100 IF W-添字I = W-添字J THEN IF W-出力エリア = SPACE THEN MOVE 'Buzz' TO W-出力エリア ELSE MOVE 'Buzz' TO W-出力エリア(5:4) END-IF MOVE 100 TO W-添字J ELSE CONTINUE END-IF END-PERFORM IF W-出力エリア = SPACE THEN MOVE W-添字I TO W-出力エリア ELSE CONTINUE END-IF DISPLAY W-出力エリア END-PERFORM. FIZZBUZZ-END. GOBACK.
http://www.geekpage.jp/blog/?id=2006/12/13
プログラミング言語ヒエラルキーにおいて、上位が下位に対してどう見下してるのかを書いてみた。詳しくない言語も無理して調べながら書いてある。あと、他言語に理解の無い人みたいで生々しいかと思って、刺激的かつあまり真っ当でない内容ばっかにしてみたよ!((FORTRAN から Java に「GO TO も実装されてないんですか?」とかそういう、馬鹿にすることを目的とした偏狭で的外れな発言ってことだよ!))((ここにある中では、C# に多重継承が無いことを馬鹿にする C++ プログラマーが真っ当でない指摘のわかりやすい例かな))
みんなが普段どういう不当な見下しをしてるかも教えてね!
「C++ の難解な仕様と戦うぐらいなら C で関数ポインタを使ったオブジェクト指向の方がスマートだね」
「STL は糞」
「多重継承したくなったらどうするの?」
「CPAN 見たって C でコア部分を書いてるライブラリばっかじゃん」
「なんでわざわざ use strict なんて書かなきゃいけないの」
「Python って明示的に object を継承した場合としなかった場合で挙動が違うって本当なの?」
「ライブラリ環境が全然整備されてなくて最悪じゃん。C や C++ で書かれたライブラリをラップしてるだけのはずなのに機能が減りまくってるのも多いし」
「簡単な処理をコピペで実装してるだけだね」
「As とか書いてて混乱しない?」
「C# があるのにまだ使ってるんだ」
「冗長でわかりやすいですね(笑)」
「DIVISION の概念って本気で言ってるんですか?」
「記述がわかりづらいね」
「ペンタゴンで使われてるだけじゃん」
「ガベージコレクタが無い……?」(あるらしいです><)
「昔 Apple で使われてただけじゃん」
「Del…phi…?」
「コンパイルも実行も遅いらしいけど何に使うんですか?」
「処理も記述できないのに何言ってるの」