情報システム課・電算課スレ Part5

1 ：10/12/06 〜 最終レス ：11/11/25

職場全体の業務のインフラを担う縁の下の力持ち。
原課とベンダーと理解度の低い上司との板挟みになりつつもシステムの運用に奔走する
担当者達の情報交換の場でございます。

2 ：

thread.got(2);

3 ：

>>1
上司の理解度をとやかく言えるほど知識を持った奴なんてほとんどいない。
情報システム課自体が自治体には不要な存在。

4 ：

>>3
そう思って情報システム課を廃止すると，
ベンダーの言い値でシステムを支えなければならない。

5 ：

>>4
ベンダの提案を評価できないような情報システム課なんかがあっても、何も変わりはしない。
高木氏の電突に対して対等に渡り合えるくらいの人材がいないなら、原課が直接交渉するのと変わりはしない。
少なくとも情報系の学部卒、できれば院卒程度の能力は必要。

6 ：

>>5
うちの職場は、民間の情報システム経験者でoracle silver持ちと
大学で情報工学やって、テクニカルエンジニア(ネットワーク) 持ってたやつがやってたよ

7 ：

>>6
幸運な例外だね

8 ：

>>7
まぁそれも2，3年で変わるんだけど

9 ：

民間と渡り合えるようなスキルを持っている公務員なんかごく僅か。
だから，現場を経験してスキルを積ませる意味もあって，
システム課に人を貼り付ける。
…なのに，今は数年で異動させちゃうからなぁ。

10 ：

異動しても異動先でトラブルシュートや情報リテラシーの向上に協力してくれたりするのであれば
積んだスキルが生きてくるのだけどね

11 ：

コンピュータがまだ珍しかった時代（電算機と呼ばれてた頃）にそれ専門で
選考採用された香具師がシステム部門の事実上のボス（ドン）となってしまい
一般事務屋は誰も意見できず多額の税金が大型電算機に無駄に使われたという
苦い経験がある。
異動が無いのも考えもの。

12 ：

>>11
かといって、専門家不在では誰もベンダに意見できずに多額の税金が無駄に使われる。
岡崎市図書館みたいな馬鹿な対応も生まれる。
素人ばかりの情シスなんぞ存在価値なし。

13 ：

専門家と言っても全体最適のことまで考えられる有能な人材はまず皆無で
オタクの塊みたいなのが多いんだよな。
システムの細かいことは得意だが費用対効果とかメンテナンスのことまで
考えずに自分の自由にできるオモチャを作ることばかり考えてる。
本人は専門知識で周囲を指導してるつもりでも結局、商売上手のベンダーに
いいように利用されてるのが実態。

14 ：

>>13
うちは、システムに詳しい人間と、
システムには詳しくないけど業務に詳しい人間セットで置いてる
大体バランス取れてるよ

15 ：

>>13
「システムの細かいこと」ってのがよくわからんな。
全体最適のことまで考えられる人は、基礎ができているから、システムの細かいことまで理解しているもんだ。

16 ：

>>15
正確に言えば「特定の分野の細かいこと」が得意な香具師だな。
大型電算のレガシーシステムに精通してる香具師とか逆に
ＰＣクライアントサーバーシステムに精通してる香具師とか。
ＩＴの全分野に精通する必要は勿論無いが、全体を俯瞰できないため
自分の土俵に無理やり引きずり込もうとする自称専門家が多すぎる。
その自称専門家に何も意見できない管理職は確かに糞以下だが。

17 ：

>>16
なるほど。
この世の全てがMSによって創造されていると信じているVBA厨とかだね。

18 ：

極端かもしれないが，自治体のシステムは，
自治体が自前で作ったほうがいいんじゃないかって気がする。
少なくとも，そういうことができる人材を育てないと
ベンダーの言いなりだね。
まあ，ハード整備の公共事業で建設業が潤う構図が
情報システム業にも拡大されたと解釈すれば，
今みたいな中途半端な体制がもっとも効率はいいだろうけどね。

19 ：

age

20 ：

情報システム課に常駐する民間の外注さんたちｗ

21 ：

ソースコードなくしちゃったり。
意図的に消去したり。
ソースコードを管理する知識がないので
ロードモジュールをビルドしたときのソースコードが
今じゃ取り出せないんだよな。

22 ：

>>21
うちもソースを管理できてないや
納入物としては貰ってるが、契約上単年度なんで
手を入れたところの部分しか貰ってない
そのくせ、10年以上前のシステムに継ぎ足してるから、
スパゲッティーになってる
役所でCVSとか作らないとだめなのかねぇ

23 ：

svnとかcvsとか管理してないことにつけ込まれて
変な改竄が横行するようになるよ。
そしてソースコード消されちゃうのさ。

24 ：

ソース管理してないとチームで開発してると
他人の開発から自分のコードを守るために
同じようなロジックをコピーし始めるのだが
これが致命的にボリューム爆発させてしまう。
最後は自分達が混乱させたソースコードなのに
特殊な作業で改修が難しいと言い訳。
こうしてカネばかり浪費される。

25 ：

そもそCOBOLERやVBA厨はソースバージョン管理という概念を知らない
クソみたいなコード書くくせにドキュメントを作らない
いい加減にしろ

26 ：

うちはドキュメント命だな。

27 ：

うちには代表システムが２つあり、１つはドキュメントを徹底しすぎて
画面のコピペのようなマニュアルもどきが膨大に発生し、そのメンテ工数で
本来の改修作業が滞っている。
もう１つはドキュメントなど全く存在しないシステム
巨大なCOBOLとJavaとAccessで実装されてる。
巨大になる理由はソースコードの管理がないからで
開発者はコードを集約するのではなく、
他人の開発コードから自分のロジックを守るためにソースコードをコピーしてる。
毎日似たようなコードをコピーしてれば
たいした処理をやってなくてもボリュームは爆発する。
最後に、俺たちは特殊な仕事をやっているのだと自慢したりする。

28 ：

>>27
> 最後に、俺たちは特殊な仕事をやっているのだと自慢したりする。
井の中の蛙の典型だな。
どうせVBAかじった程度のパソコン博士だろ。
本当にデキる奴は、上には上がいることを知っているから、
素人さん相手に自慢することなんてありえない。

29 ：

>>27
＞巨大なCOBOLとJavaとAccessで実装されてる。
メマイがするようなシステムだな。

30 ：

監査する人が存在しないので、職員は財務会計規則・手続きを勝手に捻じ曲げて
自由に起票にでき、業者と連携できる仕様変更が日々多くなる訳だが
どこか後ろめたい気持ちがあるので、こんな結果になるのだろうな。

31 ：

日本語でおk

32 ：

なかの仕掛けがわからないクレーマのような職員が増えて大変なんだよな。
基地外との会話のようになってくるから、どうしようもない。
窓口にくる市民より職員の方がタチが悪い。
民間企業のように利益とか成績とか数値目標がないと人間腐るのかね？

33 ：

障害は仕事をサボるための言い訳。
障害原因を自ら調査したりするわけもないので
誰かに外部の人間に押し付けては
まだかまだかと念仏のように唱えるのは簡単だ。
勤務時間がいちばん浪費できるし
他のやりたくない仕事をしなくても済むもはメリットだ。
自作自演のときもあれば
自分バカでまったく勘違いしてる場合もある。
第三者に状況を説明しないことが大事
一瞬にして解決されては元も子もないからだ。

34 ：

>>33
運用を委託している委託先の民間企業のオペレーターミスで障害が発生して
システムが丸一日止まったんだが
自作自演だったのか
>>32
ベンダが｢出来ました。テストしてください｣って持ってきたシステム
触って15分で落ちたぞ
インターネットに公開するシステムなのに
3人以上で同時に触ると過負荷で落ちるらしい
両方とも、世の中では超一流で通ってる会社
もう、潰れちまえ

35 ：

>>34
Hかパソコン作ってない方のNだろ

36 ：

我が県にはシングルサインオン(SSO)もどきが存在し
なぜかそれが特定の業務システムに組み込まれている。
LDAPサーバを共有すればすむ話を
業者が囲い込みのためSOAP実装と共にラップjarファイルにしたため
拡張性も、移植性も非常に悪く
その業務システムのバージョンアップの障害になってたりする。
Windowsドメインのユーザとも連携してないし
その管理部署とは別管理なので、SSOと言っても
WindowsにログオンしたあとにSSOもどきのブラウザ画面に
再度ログインするはめになっている。
しかもSSOが適応できるのは２つのシステムだけだ。

37 ：

オープンソースのOpenSSOはWindowsのAD認証と連携できる。
なのでOpenSSOにアプリを対応させれば一元管理など簡単な話だ。
そんな技術的な問題ではなく、日々ハッキング行為に余念がない
Windowsのドメインを管理する部門にSSOを一元管理させることが
最も危険なことになるかもしれない。

38 ：

>>35
パソコン作ってない方のNはひどすぎ。
なにをどうしたらあんなクソシステムがあの破格(の高額)で提供できるのか。

39 ：

パソコン作ってない方のNって○RIのこと？
それとも○TT？

40 ：

>>38
自分ではほとんど何もせず全部下請け孫請けに丸投げしてるから。
官公需中心の仕様書の形式的管理だけの典型的ピンハネ会社。
ま、いくら技術力が超一流でも役所が零細ベンダーや個人に仕事を
直接委託できない罠。
ＩＴ土建ってのは実にうまくこのビジネスモデルを表現してる。

41 ：

>>40
零細ベンダと直接契約してみた
行程管理が甘いのと、テスト環境を持ってないので
うちのテスト環境を使わせる必要があったが
予算は1/5になったよ
後は、当たり外れをどうするかだな
うちはうまく行ったけど、他の課で契約した会社は
プロジェクトひっかきまわして
結局出来ませんって泣き入れてきたらしいし

42 ：

>>32
>民間企業のように利益とか成績とか数値目標がないと人間腐るのかね？
利益を考えるのなら電算部署いらなくなるという結論にはなるなw

43 ：

情報システムは必要だけど、素人ばかりの電算部署は確かに不要だな。
ついでに言うと、コンピュータをどうやって業務に役立てればいいかもわからない原課職員も不要だな。

44 ：

メインフレームにはsvnやvss、cvsのようなソースコード管理する文化がない。
そのCOBOLをUNIXサーバに移植、しかし担当はコボラーなのでソースコードを管理する価値観はなかった。
自分の修正が他の部分に影響するのは嫌だし、他人の開発に自分のコードが影響されるのは嫌だ。
Eclipseもなければ、リファクタリンクする文化もない、
常にソースコードをコンパクトに集約しようという価値観はコボラーにはない。
オブジェクト指向の継承構造などは使えないのだから、コボラーはソースコードをコピーするだけだ。
プログラムのIDだけ変えてソースファイルを何も考えずにコピーするのが今日の仕事だ。
COBOLは今でも質より量をとる、ステップいくらの世界だ。
整合性を取ってないソースコードのファイル数を自慢しても無意味だと思うが
そんな毎日を何年も続けてれば、ソースコードは何千ファイルにも膨れ上がる。
プログラム改修は通常システム全体で整合性をとるものだが、そんなことはコボラーにはできない。
実はシステム全体で整合性を取らなくてもいいように、スタティックリンクのロードモジュールにしてある。
他のロードモジュールは再度リンクするまで影響がないはずだ。
ソースコードは管理されてないのだから、昔のバージョンのソースコードをsvnから切り出すようなことはできない。
だからロードモジュールを再びビルドすることは絶対に不可能なのだが、そんなことはコボラーの責任範囲ではない。

45 ：

無意味に複雑にする自作自演の破壊活動なのだが、
素人の役人にはシステムのボリュームしか見えないため
せっせと予算を捻出してくれるところにも問題がある。

46 ：

COBOLを使うと馬鹿になるって大先生も言ってたな
そしてVBA厨は現代のCOBOLER

47 ：

こんなクソ言語に税金がジャブジャブ遣われているのが問題だ。

48 ：

ただ書きなぐったようなCOBOLソースでは
デバッグすらできない事も判明。
ただ時間だけが過ぎていくのだが。

49 ：

うちは10年以上前に、Javaに移行済み

50 ：

ディスク容量が足りなくてバックアップしてない表があり
いざというときにはイメージバックアップから戻すからと言い訳。
しかし、イメージからのリストアとはDBインスタンス全体を上書き戻すことだっだ。

51 ：

ディスク容量が足りないのではなく
頭がたりないのだ。

52 ：

>>50
当たり前だ
基本仕様書作るときに、容量ぐらい見積もれよ

53 ：

我が県ではOracleの表に
表領域が許す限りPDFファイルを突っ込む仕様があり
容量の見積りなど不可能なのだ。

54 ：

>表領域が許す限り
つまり、TABLESPACEサイズを制限して、
HDDの物理的空き領域を確保すれば良いだけじゃないか

55 ：

1) 領域不足エラーにクレーム
2) 表領域を増やす
3) 増やした分だけPDF追加
4) 1)に戻る

56 ：

>>55
クレーム入っても空き容量無いで突っぱねろ
うちもファイルサーバーが容量足りないって言われるが突っぱてる

57 ：

>>56
昔はその手が使えたが今はストレージの容量が劇的に増えてることが素人にも
わかってしまってるので説明に苦労する。
「ゴラァ！今は２ＴＢのハードディスクが２万円で買えるんだぞ。嘘つくな！」
とかねｗ。

58 ：

>>57
SATAのHDD何か、信用低すぎて使えねーよ
サーバー舐めんな
って返してます

59 ：

>>58
そういう説明してたら高信頼性のはずのストレージがハード障害で飛んでしまい
収入会計業務が丸１日ストップして面子が丸つぶれになったことがある。
「損害賠償モンだ！」と不治痛を恫喝してＲＡＩＤの超高信頼性ストレージに
同じ値段で入れ替えさせた。

60 ：

2万円のSATAのハードディスクでもrsyncのバックアップだけで充分だったり
ゆうちょ銀行のIBM製ストレージの様にファームウェアの更新を怠っていたためにシステム全体が停止したり
ストレージって金額ではなく、運用する人間の技量で信頼性が決まるんだよな。

61 ：

２万円のSATAディスクと違って
最小構成価格は3億2509万5500円(税別)のDS8000シリーズなんて
しょっちゅうクリティカルなバグがファームウェアに発見される。
http://www-01.ibm.com/support/docview.wss?uid=ssg1S1003593
更新しなければならないけど、稼働開始後にストレージのファームウェアの更新って
結構勇気のある判断で、運用担当が尻込みしてる間に本当に障害が発生するのさ。
ディスクって価格じゃないんだよ、運用担当者の技量がものをいうんだよ。

62 ：

ディスク単体での信頼度と、システムの信頼度をを同一レベルで語るあたり…
>>60-61　おまえ、技術屋じゃないだろ

63 ：

>>60
ちなみに、ゆうちょのシステムダウンの原因は、
ファームの更新を怠ってた事じゃないぞ
うちも同じ機会入れてたから、IBMが頭下げに来たけど

64 ：

そうだよ。オットセイ職員だよ。

65 ：

http://www.itmedia.co.jp/news/articles/1008/17/news028.html
やっぱファームのバグか。
ディスク単体での信頼度も、
ストレージシステムの信頼度も
アプリから見れば同じだよ。

66 ：

>>65
ファームのバグだけど、ゆうちょの事例が1例目
ゆうちょで発動して、対策ファームが出た
だから
>ゆうちょ銀行のIBM製ストレージの様にファームウェアの更新を怠っていたためにシステム全体が停止したり
は誤り
そして、
>ディスク単体での信頼度も、
>ストレージシステムの信頼度も
>アプリから見れば同じだよ。
そんな低レベルな認識では、システム組めない
仕事でも能率上げるためにボトルネックを考えるのは日常的有ると思うけど、
そういうの考えない人？

67 ：

ファームのバグはわかっていたけど、運用上の問題で適用見送りになってたんだろ。

68 ：

仕掛けを理解できない高価なストレージシステムって
テストなんてやらないから、こんなことになったのさ。
それなら仕掛けを理解したSATAディスク２台構成のほうが信頼性があるね。

69 ：

>>67
システム障害の発生が、7月12日
IBMから対策ファームが出たのが8月20日
そして
>>68は馬鹿すぎるので一回死んでこい

70 ：

何れにしても未テストで稼働させた罪は大きいよな。

71 ：

インフラのテスト中に検出できなかったことも問題だな。
ていうか全くインフラの障害関連を未テストのまま稼働させてるってことだね。
いやー怖いね。３億円払うと安心するのかね？

72 ：

>69
#システム障害の発生が、7月12日
#IBMから対策ファームが出たのが8月20日
「7月に新規発生した障害のファームが9月にあてられる。
なんて普通ないから、運用都合かなんかで適用見送ってたんだろ」
というのが業界の判断です。

73 ：

世界で１万台以上入ってていままで事例なしだったこととも矛盾するので
ファームのバグは偽装で本当は設定ミスなんだろという見方もあるね。

74 ：

大金が絡んだストレージシステムって関係者の嘘も多いので
自分で充分理解したSATAディスク2台構成でrsyncってのが、一番信頼できるよ。

75 ：

>>74
その「自分」が異動することに問題がある。
結局、職員の能力値が一定でないから、rsyncで組むと
今度は職員起因の障害が発生するだけ。

76 ：

>>75
大手ベンダーの官公需部門は、まさにそこにつけこんで巨額の税金を
食い荒しているワケなのだが。
かと言って異動の無いＩＴ専門職員の養成は役所にとっては諸刃の剣。

77 ：

優秀だが嘘つきベンダーか？
それともバカで愚直な職員か？

78 ：

カネの切れ目はベンダーとの切れ目。
答えはでてる。手順書を明確にして職員がやるしかないのさ。

79 ：

>>75
それ以前に、こいつバックアップとRAIDの目的の違いも判ってなさそうだし、
相手するだけ無駄

80 ：

ベンダーかばうの必死だね。いくらもらったの？

81 ：

プール金持ち逃げされるから
切り捨てる訳にもいかないんだよね。

82 ：

紛失したソースコードを無理やり変造し、コンパイルだけ通るようにしただけでは
実際に動くかどうかもわからない。
そのロードモジュールが、昔と同じように動作するか確認する方法もない。
テストケースもなければテストデータもない。設計書もない、仕様もわからない。
この犯罪まがいの状況に、関わったメンバー達は、もはや逆ギレるだけ。

83 ：

自作自演で混乱させたコードを短期間で収束させると
それはそれで自作自演であったことを自ら証明してしまうようなもので
今までの開発工数を自ら否定してしまうことでもある。

84 ：

http://www.anysql.net/doc/bug10103.html Bugs fixed in the 10.1.0.3 Patch Set
http://www.anysql.net/doc/bug10104.html Bugs fixed in the 10.1.0.4 Patch Set
http://www.anysql.net/doc/bug10105.html Bugs fixed in the 10.1.0.5 Patch Set

85 ：

LOBデータはグチャグチャになっている筈だ。
だが根拠もなく大丈夫だと言い張るはずだ。
そうなると不正レコードが原因で移行できなくなるだろう。

86 ：

>84
「ねっ。Oracleってバグ多いでしょ。だからHiRDBにしましょうよ。」

87 ：

パッチを当てればなおる話を逆手に取って
不具合を起こす機能を見つけては
それを実装していった悪意を感じる。
まぁ確かにシステムは大混乱し
工数は爆発しボロ儲けすることができたのだろう。
そんな破壊工作の５年が終了しようとしているが
その前にデータを安全に抜き出さなければならない
まるで、爆発物処理班のように。

88 ：

問題を揉み消してばかりいると
ついつい問題の解決案まで揉み消すようになり
もうこれは末期症状。何も変化を望まない老人ホームに似てる。

89 ：

Web画面のJspとバリューオブジェクトの生成ツールを、なぜかVisual C++でコテコテに開発していた。
そのツールはバリューオブジェクトのJavaソースコードを内部で消去して
クラスファイルだけを成果物として出力していた。
時がたってJDKを1.4から1.5に上げるときに、ソースコードが存在しないことが判明。
Javaのコードの呼び出し方によっては古いバージョンのクラスファイルから
新しいバージョンを呼び出すことはできない。
システム全体を廃棄することになりかねない問題になったっけ。
契約を切られないようにするために、そのベンダーはソースコードを消去までして
金融庁から業務改善命令が発令されそうな状況をワザと作って
その金融機関と取引を続けていたんだ。
このときソースコードって「人質」なんだと思ったんだよね。

90 ：

そんなことやってるから、外資に負けちゃうんだよな。

91 ：

>87
パッチを当てることになって
バグの内容によっては、COBOLソースをプリコンパイルしようにも
ソースコードが管理されてなかったのだから
ロードモジュールを、その当時のバージョンで再ビルドすることはできなかったはずだ。
だからパッチセット当てることなど論外だったのだ。

92 ：

サギ残業でネトゲやる時間があるのだから、svnに成果物を登録する時間はじゅうぶんあったはずだ。
なぜやらない？
なぜソースコードを消去するような必要があるのか？
なぜ全体と辻褄が合ってない自分のロードモジュールだけをリリースするのか？
わからないことだらけだ

93 ：

入退室カードやパスワードでガチガチにセキュリティが確保された部屋というのは
中で何をやってるのか、把握できないデメリットが常に付きまとう。
深夜勤務や休日出勤手当てを貰いながら、実際はネトゲに夢中になっていても
外からはまったく把握できないというリスクが伴う。
むかしはサギ残業などと呼んだが、今どきはネトゲ残業と呼ぶほうがふさわしい。

94 ：

自治体に、情シスって名乗るのもおこがましい電算部門がどれだけあるんだろうな。
管財課や契約課に吸収されたほうがいいんじゃまいか

95 ：

COBOL2002からオブジェクト指向言語になった
http://mac-reimann.de/OOC2002.pdf
クラス、メソッド、ファクトリー、継承、多重継承、インターフェイス...
ソースコードをコピーする時代は終わった。
これからのコボラーはオブジェクト指向設計ができなければ
工数やボリュームが爆発してやってられなくなるだろう。

96 ：

しかしまぁ、どんな意図があって
ソースコードを削除しちゃうんだろうね？
２年おきに配属がローテーションしちゃうから後任に対する嫌がらせ？
それとも違法なロジックを隠蔽するためなんだろうか？
自分だけ給料の振込額を倍に改造してたとか？
いろいろ考えちゃうよね。

97 ：

どうも工数を膨らませるために意図的にやってる気がする。
一人で１日で済むような修正を何人もの人間が何週間も悩み苦しむようになれば
自ずから工数が増えて誰かが儲かる仕組みだ。
厳重に注意しておかないと、簡単にソースコードを紛失し
カネがいくらあっても足りない現状を認めてしまうことになる。
新しく構築する環境でも、こいつらは過去の工数を正当化するために
またソースコードを意図的に混乱させてしまうだろう。
なんとも情けない話だ。

98 ：

>>96
> ２年おきに配属がローテーションしちゃうから
2年とはえらく短いな。
文系素人が2年でまともな仕事ができるようになるとは思えないな。

99 ：

春の入札祭り実施の季節ですね。
このご時世、保守も随契は無理で入札しなければいけないのだけれども、たまに仕事ほしさで激安で入札する業者が怖い。

100read 1read

1read 100read

TOP カテ一覧 スレ一覧 削除依頼 ▲