パスワードを忘れた? アカウント作成
119513 journal

malice-angelの日記: ホストの不備をクライアントで吸収 2

日記 by malice-angel

ホストから送られてくるデータ(と言ってもネットワーク上の共有フォルダに置かれるファイルなんだけど)を取り込むとエラーが出る。
てなことで、調査する。
あれ?仕様と違うじゃん。仕様だと可変長CSVなのに固定長になってる(CSVですらない)。こりゃ駄目じゃん。
で、連絡するとクライアント側で吸収できませんか?となる。なんで?。そんなの吸収っていうレベルじゃなくて、仕様変更じゃねーか。ホスト側の不備だろ。知るか!!ボケ。

すったもんだのあげくクライアント側で吸収する羽目に(怒)。とりあえず完成。テストデータを作って確認。オッケー!!。
で、ホストとの結合テスト開始。すると、またエラー発生!!。なんで?(涙)。

これはホストからのデータが絶対におかしい。ということでチェック。
あれ?。データの中のスペース(0x20)に見えてる部分がNULL(0x00)の奴がある(秀丸で見るとブランクスペースに見える)。
ボケか?。どうしたらこんなデータにできるんだ?。ホストのプログラム作ってる奴ってバカなの?。これ以上は知らん。ホスト側で直せ!!。

今回のじゃないけど、行末に余分なカンマがあるデータを作ったり、改行コードが指定のでないのを送ってきたり、ファイルの途中に改行オンリー(おそらくコントロールブレイク)があったり、最終行が必ず改行オンリーだったり。
仕様を読む力が無いのか?。作った後にテストして確認するというプロセスが無いのか?。そもそもバカなのか?。

聞いたところによると、ホストのプログラムっていろんなもの(ライブラリ?)を使いまわすから、そうなるらしいとか。
そんなの関係あるか!!。成果物が仕様と合ってるのか確認すらもできないのか!!。仕様と合ってなければ0点なんだよ。カス!!。

『できました』って大きな顔してんじゃね~よ(見たことないけど)。

この議論は、malice-angel (8295)によって ログインユーザだけとして作成されたが、今となっては 新たにコメントを付けることはできません。
  • 自分もある官庁案件で、まさに似たような経験をしました。
    「データの中のスペース(0x20)に見えてる部分がNULL(0x00)の奴」とか、
    当時を思い出して苦笑してしまいました。

    >ホストのプログラム作ってる奴ってバカなの?。

    個人個人は誠実で優秀、出来る範囲で頑張った結果だったりするようです。
    多分。

    大体、こうなっている歴史的経緯は以下の5つ辺りにあるかと思います。

    ・ステークホルダーが多すぎてモジュール分割が細分化
    (もちろん、単に意思疎通や方針決定の障害にもなる)

    ・丸投げ前提のくせに実装関係者が居ない会議で決定
    (開発物の類似案件で実装経験がある人間さえいない)

    ・仕様が固まる前に話を進める前倒しが美徳と勘違い
    (あるいは出来ていると嘘をついて受注している)

    ・現場の工夫で帳尻を合わせた個所や過程が明文化されていない
    (ノウハウ隠蔽や文書化否定がベンダーの強みと勘違い)

    ・開発プロセスに無知な顧客だから成果物チェックが緩い
    (セカンドオピニオンのコンサルを雇っているにも関わらず)

    確かに終身雇用とバブル景気が続いていれば、そのプロジェクトに
    張り付いて一生を終えるなんて夢を見れたからノウハウなどを含めた
    保守性は自己完結しているため無視できる問題だったのかも知れません。

    派遣や請負に丸投げする今でも、そのようなノリでプロジェクトリーダー
    を務めているようなバブル崩壊以前に入社した似非SEが中堅に居座って
    現場の士気でなんとかしてくれる事に期待するだけのマネジメントをする。
    そのくせ、モチベーションを盛り上げようという努力はしない。

    しなくていいはずの苦労をした時に、「自分の場合は改めよう」と思うSEと
    「こういうものだ」と物分り良く思考停止して他人にもそれを求めるSE。
    そこに不幸の連鎖を食い止める案件と、嵌る案件の違いがあるのではないかと。

    #ただ、いくら頑張っても景気の波のように理不尽な状況は発生するだろうし、
    #逆境を成長のチャンスと置き換えられる位の精神力の必要性は否定しません。

    未だに年功序列で主任や課長になれる大手SIer辺りには、しなくていいはずの
    苦労を前提としたマネジメントが常識化している人間が上流に多い気がします。
    当然、ホストコンピュータのような歴史の長い案件に寄生率が高くなると…

    突き詰めていけば、そういう人間を出世させる会社にも責任があるでしょうし、
    新卒信仰の雇用体制、簡単に人を切れない制度上の都合があるのでしょうし、
    転職をマイナス評価する忠誠心ばかりに重点を置く人事評価があるのでしょう。

    人型バグを追放する気が無く、生産性の低い人材が高給をとれる組織的問題。
    だから能無しだと自覚している人間でさえ、会社にしがみつこうとします。
    そのぶん滅私奉公しているならまだ解るけど、人並みの勤務しかしていない。

    ようするに

    ホスト側だろうと、クライアント側だろうと末端PGの仕事に責任追及しても、
    個人に権限の無い上流の問題に目を向けないと根本的には変わらないかと。

    • by malice-angel (8295) on 2009年07月12日 21時58分 (#1603788) 日記

      腹立つのは、仕様の逆読み、つまり

      行末に余分なカンマがあるデータを作ったり、改行コードが指定のでないのを送ってきたり、ファイルの途中に改行オンリー(おそらくコントロールブレイク)があったり、最終行が必ず改行オンリーだったり。

      等についてツッコむと、

      • 行末に余分なカンマを付けてはいけない
      • ファイルの途中に改行オンリーの行があってはいけない
      • 最終行が改行オンリーになっていてはいけない

      とは、仕様書に記載されていない。などとほざく奴がいる事です。あんた、それでよく自分は一人前だと言えますね。って思ったもんです。
      こういうところに仕事を出す時は、俺が上記のような事をヌカせないようにガチガチに仕様を固めてやるから、一旦その仕様を見せてくれ。と発注元にお願いした事もあります。

      とにかく、不具合を不具合と認めない。しまいには時間がないとかヌカす。全体の納期が決まっているから融通の利くクライアント側に理不尽な仕様変更が回ってくる。で、クライアント側が不具合を吸収した事を知っているかというと末端の担当者はなにも聞いていないので知らない。自分のプログラムに不具合は無かったと認識しやがる。
      それで、後日同じ事を繰り返す。プログラムなんてこんなものでいいんだという意識が根付く。もう最悪。

      ホストって何様やねん?。発注元もホスト側にもっと言いたい事言えや。なんでそんな弱腰やねん?と、書いているとどんどん腹立ってくるのでこの辺でやめときます。

      --

      我は俗物なり。ひれ伏せよ。

      親コメント
typodupeerror

日本発のオープンソースソフトウェアは42件 -- ある官僚

読み込み中...