Main Contents
2007年09月13日
K工業 実機テスト
先週ほぼ完成し、実機テストがまだだったスポット溶接のデータ取りプログラム(それもんの機械から RS-232Cで吐き出されるテキストデータを受信してファイルに落とすだけのもの)を試験設置。
大丈夫だろうと思っていたけど、やっぱり大丈夫。
とりあえず設置して帰る。
単純に CSV形式で吐き出されるので、それをファイルに記録するだけなんだけど上司はDBに入れろ入れろと言いもめる。
取得したデータは何か問題があったときに、提出データに添付するデータとして使うだけのものなので CSVのままで保存しておいて、必要になったら該当日付のファイルを探せばいいだけだと思うんだけれど。抽出は日付、機番単位のみ、データの値は集計とかすることは求められていない。
前の客先打ち合わせのとき、そんなに複雑なものは要求されておらず必要になったらExcelに取り込めればヨシのレベルと私は理解したんだけれど、上司は「そんなもんじゃ お客さんは納得するわけがない」という。
まともに要求仕様を定義するってことをしてないのが、そもそもあれなんだけれどさ。二人同じ場所にいて思い描いた仕様が全く違うというのが面白い。
Keep It Simple, Stupid.
何でもかんでも複雑化させればいいってもんじゃないと思うんだけれどな。
お客さんが「こうしてくれ」と言うのなら、もちろんそのように作るんだけれど、今回はお客さんが望んでいるものをお客さん抜きでそれぞれの理解を元に議論しあってるわけで、上司が言うがままに作って結局使わないもの作っても仕方がないと思うのよね。
一応 grep呼ぶ簡単なフロントエンドくらいは用意しているんだけれども。
どっちが正しいのかはまだわかんない。
- by umedak
- at 2007年09月13日 23:12
- in Works
Comments
省略してるんじゃなくて、そもそも それをやる業務の流れになっていないという問題が。
ほとんどの場合直接客先の話を聞くことはなく、上司が聞いて、まとめた資料を基にシステムを作成します。
完成してから実際に話を聞いてみると、「そうゆうことなら、そんなふうに作らなかったのに」ということは、時々発生してますね。
- umedak
- 2007年09月17日 00:30
ストレスの原因を作らないような予防処置は
「共通の認識にいたる仕様書の取り交わし」
だと思う。省略するとこう言うことになる。
独りよがりの傾向が強いのは親譲りだぜ。