  |
はてなキーワード: 汎用機とは
あと５年もすればいよいよ昔を知る人が居なくなり日本中で同じ事が起こるだろ
技術者を軽視してきた経営側・管理側の招いた負の遺産となるだろう。
上記の通り仕様書がないことも多いうえ、システム課に限らず市役所の人員は基本ローテーションするよ。
導入当初の担当者が残っていることは珍しいし、30年も前に導入した汎用機のことなんてここ10年に入った職員にはわからないよ。
こういった無意味な人事ローテーションをやめて、スペシャリストをしっかり身内に育成してきていれば良かったのに
残念なことに、「属人化は良くない」といった言い訳で、専門家を軽視してきた。
Q8.じゃあ役所は悪くないの？
Q8.悪いよ。
みんな沈む。
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の組み合わせである。
それをここ十年くらい、リプレースでx86系サーバにJavaという構成に変更することが多い。
しかし、ハードが汎用機からオープン系になるのはともかく、プログラムを別の言語に書き換えるとか、誰も幸せになる気がしない。
ぶっちゃけCOBOLはCOBOLのまま移植し、今後も改修を続けるほうが、長い目で見たコストも低くなるのでは？と思うのだ。
その理由はこうだ。
COBOLで書かれたバッチ処理は、設計書の書式がフローチャートであることが多い。
勿論ロクに設計書がない場合もあるだろうけど、いずれにせよCOBOLの文法は、「普通の人にとっての仕事らしい仕事」をそのまま入れ子状のフローチャート(分岐の先が別のフローチャート参照みたいになってるやつね)に書き表したものである。
そういうモノが既にある企業や銀行の文化において、当然発注側は担当者からお偉いさんまでCOBOLer系フローチャート脳だし、新しいシステムの設計でもそれを踏襲しようとする。
というか踏襲すること前提じゃないと設計書をレビューできない。
UMLで考えるようなパラダイムシフトはまず不可能なので、それを求めるのは受注者の傲慢だろう。
というわけで、受注した大手SIerは、ほぼ確実にフローチャートもしくはそれに準じる記法の設計書で処理を組み上げざるを得なくなる。
そうなると、実装もフローチャートの設計を基にコードを書くわけだが、こういう設計はハッカー文化で発展してきた言語(Fortran→C/C++→Javaという流れと、PerlからPython・PHPというインタプリタ系の諸言語)との相性が最悪である。
設計とは実装を楽にするために書くのに、これらの言語において、フローチャートの設計は役に立たないどころか、邪魔でしかない。
だからFortranしかなかった頃から、本物のプログラマ達はフローチャートをdisってきたわけである。
ちなみに筆者はハッカー文化が生み出した恩恵に敬意を示すし、実際とても好きという立場である。
しかし、「普通の人達の普通の思考」からはかけ離れ過ぎているという意味で、「普通の人達の普通の仕事」をシステム化する時にどこまで役に立つかについては、非常に懐疑的に見ている。
…いささか話が脱線してしまったが、とにかくフローチャートで上がってきた設計書でコードを書くならCOBOLかアセンブラを選択すべきだし、それで書けないなら書く意味が無いくらいに思ったほうが良い気がする。
というわけで、自分はCOBOLからのリプレース案件は、その根本的な愚かしさを抱えている現状を見るに、今後一切関わる気はない。
今日も日本の何処かで、基幹システムのリプレースが行われている。
基幹システム…そう、古くは汎用機にCOBOLという、枯れるを通り越してまさに朽ち果てんとしているアレだ。
そもそも朽ちて土に還る前に建て直すためのリプレースだ。
てか朽ちないんだったら、もう半永久的に触るべきじゃないと思うんだけど、形あるものは必ず滅びるのだ、作り直すしかない。勘弁してくれーという感じだ。
じゃあ何を用いて作り直すか？またCOBOLが一番手っ取り早そう(ソースいじらず移植という意味で)だが、それは許されないのだそうだ。ふざけんな。
今だったら大体どこでもJavaで作り直しだ。どういうわけか今のトレンド()だ。
てかそれ、オブジェクト指向とWebアプリに夢見過ぎじゃね？別にそれ銀の弾丸でもないしエクスカリバーでもなければ伝家の宝刀でもない、ただの道具なんですけど。
その証拠に、色々共通化されて保守性も拡張性も格段に上がったとか言ってる割に、その実態は、数える気にもならないほどインターフェースをimplementしまくった、複雑怪奇なクラスファイルの乱立ですよ。
もちろんドキュメントも上から下のレイヤーまで、そのクラスの分だけ揃ってる。というか山のようにある。いやそれ分量的に読めねーから。
ちなみに、今時の銀行や大企業は、基幹システム一つだけなんて事は無いケースが多い。基幹システムは複数あって相互に通信する巨大システム群の中の一つに過ぎなかったり。
そこで基幹システムだけ今風に作り直した所で、コスト増大の根本原因である複雑さの解消に、微塵も貢献しているとは思えないのだが、その質問はダメらしい。
もうさ、ぶっちゃけちゃうと、そもそも人間という柔軟な脳を持つ生き物がこなしている業務を、人間より正確かもしれないけど全く融通が効かないコンピュータに代替することが限界なんじゃね？と思うんだわ。
基幹システムを見ていると、そんな暗澹たる気分になる。
そりゃCOBOLと汎用機しか選択肢のなかった時代から比べて、今は色んなソリューションやソフトウェアがある。どれもシンプルに造るため、分かりやすく造るためにある。
しかしこの国の基幹システムは、それでもなお複雑さを解消していない。
あるいは、そういう大きなシステムを抱えている日本の組織性の問題なんですかね？
爆発しなくてもいいから、Google辺りに生息している本物のプログラマが、そういう複雑さを一気に解決するような、黒船もびっくりなソリューションで、今のITゼネコンありきのSIの世界に風穴を開けてくれることを切に願う。
うん。分かる分かる。
過去に掠っただけの経験を盛って何とか面談相手のニーズに合致してますアピールをしなきゃならないこの苦しさ。
日本のシステム開発の現場って無駄にギョームケイケンを求めすぎなんだよな。
どの現場も作ってるもんは画面の入力内容をRDBMSに保存して、画面やら帳票やらファイルに出力するだけ。
オンラインとバッチ、汎用機とオープン系、この位の粒度で経験がかぶってて、オブジェクト指向の言語どれか一つ使いこなせりゃ別に現場に入ってから学習で全然事足りるし、業務知識なんて販売管理やら在庫管理やらの一般的な業務システムの知識を本とかで仕込んでおいて後は現場で覚えりゃ十分。
まるで、専門知識がなければ戦力にならないかのようにみんな面接してくるけど、どうせお前外部の人間にそこまで深くコミットした仕事させねーだろって思うわ。
以下、確認しないで思い込みで書く。
停電対策として、UPS（UnstoppablePowerSupply）をつなぐんだけど、一定以上の年代の人（50代以上？汎用機を経験してる人とか）は、必ずCVCFと呼ぶ。
CVCFってControlledVoltageControlledFrequencyかConstant～か知らんけど、要はコンセントの100V/50Hzを整える意味しかないから、それじゃ停電したときに役に立たないじゃんって思う。
昔は、AC電源の品質が低くて安定していなかったのか、それともコンピュータ側がきじゃくだったんだろうか。
UPSにも2種類あるようで、常にバッテリーを経由して電気を出力するものと、普段はAC直結で停電時のみ切り替えるものがあるらしい。
そうなると、前者はCVCF的な要素もあるわけで、CVCFと呼べなくもない。
ただ、おじさんたちは明らかに区別しないで呼んでるんだよな。
想像をはるかに超える高速性と安定性を持つWindows ServerをメインにWindows＋Linuxのハイブリッド環境でインフラを構築
http://gihyo.jp/admin/serial/01/gloops/0001
IISとASP.NET，そしてC＃で書かれたアプリケーションが
想像をはるかに超える高速性を実現していることが挙げられます。
そのうえ，安定して動作しているのです。
ttp://itpro.nikkeibp.co.jp/article/NEWS/20090609/331590/?SS=imgview&FD=-654674548
HPCでもダントツのパフォーマンスをたたき出すWindows
ttp://cloud.watch.impress.co.jp/docs/interview/20101224_416025.html
ttp://wsmgr.jp.brothersoft.com/screenshot-50450.html
NASパフォーマンス比較テストでWindowsがLinuxを圧倒！！
ttp://www.flexense.com/documents/nas_performance_comparison.pdf
ttp://it.slashdot.jp/story/12/04/24/0052242/
【一方Linuxは…】
Linux Daily Topics：2011年9月2日 Kernel.orgがトロイの木馬の侵入被害に｜gihyo.jp … 技術評論社
ttp://gihyo.jp/admin/clip/01/linux_dt/201109/02
Linux カーネルの基盤サイトがクラッキングの被害に - japan.internet.com
ttp://japan.internet.com/webtech/20110902/2.html
Linux Daily Topics：2011年9月15日 狙われるLinux… 今度はLinux Foundationが標的に｜gihyo.jp … 技術評論社
ttp://gihyo.jp/admin/clip/01/linux_dt/201109/15
Linux Daily Topics：2011年9月2日 Kernel.orgがトロイの木馬の侵入被害に｜gihyo.jp … 技術評論社
ttp://gihyo.jp/admin/clip/01/linux_dt/201109/02
Linux カーネルの基盤サイトがクラッキングの被害に - japan.internet.com
ttp://japan.internet.com/webtech/20110902/2.html
Linux Daily Topics：2011年9月15日 狙われるLinux… 今度はLinux Foundationが標的に｜gihyo.jp … 技術評論社
ttp://gihyo.jp/admin/clip/01/linux_dt/201109/15
MySQL.comのWebサイトに不正なコード 闇市場でroot権限も販売か
ttp://www.itmedia.co.jp/news/articles/1109/27/news027.html
またもOSSプロジェクトが被害に! Wineプロジェクト、不正侵入を発表 | エンタープライズ | マイコミジャーナル
ttp://journal.mycom.co.jp/news/2011/10/13/115/index.html
・安定性・信頼性
フリーソフトであるLinuxの安定性・信頼性はハッキリ言って問題外。
1日連続で稼動させることすら困難。
いまやWindowsの安定性・信頼性はメインフレーム(汎用機)をも凌ぐ。
世界中のメインフレームが全てWindowsServerに置き換わったのがその証拠。
・脆弱性
Linux()
Linuxで稼動している世界中のサーバーがクラックされまくっている。
デフォルトスタンダードOSとしてあらゆる攻撃を受けてきたWindowsはいまや世界で一番強固なOSとなった。
豊富なウイルス対策ソフトもさりながら、カーネルの構造的に絶対に外部からクラックされることが無いOSとなった。
しかし上記内容により安定稼動させるのはほぼ不可能。
またサポートが存在しないため自前で何とかするしかなくかえってコスト高となる。
OSは無料ではないが従来のメインフレームのOSと比較すると安価。
もともと安定性に優れたOSであるため、誰にでも安定稼動させることが容易である。
サポート面もマイクロソフトを始め、各ベンダーが完璧なサポートを行える体制となっている。
なんか毎日楽しくねーなー面白いことねーかなーとか思ってたんだけども、
ある店長のブログを見ててその理由に気が付いた。
人とのコミュニケーションをほとんど放棄しているからなんだ、と。
いやあの修羅場真っ只中の状況を見て面白そうとか楽しそうとか思っちゃうあたり
どこの自宅警備員か事務系公務員か(事務系とジム系って似てるよね量産汎用機的な意味合いで
ってなもんだけど、そして本当にあのブログ通りの会話がなされたのかはともかくとして、
だからみんなキャッチボールを続けるためにテレビ見たり流行に乗ったりするのか。
最低でも試合に備えてバッティングセンターに通うのはありでも、
試合どころか野球する気もないのにバット振っててもそりゃ面白くないし飽きるわなー。
といって話したい内容も主張したい思想もないけど、
そこで自己完結せずにもう少し誰かに届くように外向きの思考してみようと思いました、まる。
ただまあ、手動監視なんてのを真面目にやっていた現場にいきなり正論を持ち込むのはJCLとCOBOLと汎用機な世界にWEBの常識を持ち込むようなもので素直に通るわけ無いよな～と感じた。
君の説明でメール駄目な理由を考えると、多分管理者はちゃんと管理してないんだよ。監視して異常があったら大騒ぎするアラート機能を新人に求めてるんだと思う。だからメール送るだけじゃなくて、メールが期待通りに来なかったりメールが送ってくる内容に異常があったら爆竹が爆発するぐらいの提案じゃないといけないんだと思う。「ソフトウェアあんどん」みたいなやつ。
あと、台帳からぬけられないのは「いわゆるオフィスのIT化」が事務手続きの合理化じゃなくて帳票の清書から入るのと同じだと思う。IT企業でそれだってのは結構重傷だけど、たんなるオフィスのことだと思えば「ごくフツーのだめだめな展開」だと思うよ。段階を踏んで改善させないとこういうのって理解されにくい。
俺からの提案としては、
ttp://brevis.exblog.jp/12270332/
ちなみに、工場見学をしていると、人によって見るところが違うことに気づく。たとえば、工場見学の初心者は、たとえば自動溶接ロボットの動く工程だとか、整然と美しく広々した構内、あるいはコンベヤが連続して運び出す製品などに感心する。いわば、工場の目をひく付属品や印象を見ているのである。
ところが、工場見学の中級者は、別のところを見る。たとえば、NCマシンのラインと汎用機のブロックを分けてレイアウトしているな、とか、なぜ大型の自動切削機を2階においているのだろうか、といった点に注目する。建物の床には耐荷重（m2あたり500Kgとか1 ton等）という設計指標があり、これを大きくするには柱・梁を太くしたり補強を入れる必要があって、建築費が高くなる。だから重量のある機械装置はふつう1階におくのが工場計画論の定石なのだ。つまり、中級者は工場の構造に注目するのである。
そして、諸先輩の中でも上級者クラスの人を見ると、この工場は製造ロットサイズが大きすぎるんじゃないか、とか、構内は整然として見えるが通路脇に置いてある部品カゴに現品表がついていないな、といったことを指摘する。つまり、工場というシステムの動きと機能を見ているのである。だから、いろいろな人と一緒に見学に行くと勉強になる。
