- - PR -
コーダー（プログラマ）の愚痴聞かせて下さい。
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2005-09-20 09:50
なんか盛り上がっているので寄ってみました（笑） 言葉って会社によって大きく違ってくるので「コーダー」と言う言葉にまず惑わされてはいけないのではないでしょうかね。 もしかしたらどこかの工業規格あたりで言葉の定義があるのかもしれませんが、そんなものを意識している会社もあればそうではない会社もありますよね。 私もコーダーと聞くとパンチャーに近いものを想像しますが、 パンチャーがいわゆる純粋なパンチャーだとすると、コーダーはコーディング用紙を 書く人なのかもしれませんね（役割的に） 仕様書をどこまで書くか、どのレベルの仕様書からプログラムを起こすのかにも よりますが、プログラム経験の無いSEが書ける仕様書のレベルは、言ってみれば 要求仕様書に近いものだったりするので、そこからいきなりコーダーが 登場できるかといえば、その間にプログラム設計者（プログラマー？）が 必要になってくるように思います。 うちでは「設計」というとプログラマーさんを指します。 仕様書をどこまで書くかにもよりますが、一例で、 SEが、中間ファイルのソートを普通のテンポラリファイルにするように設計していまして、そんで、プログラマ（うちでは「設計」ね）が、 「あほか、メモリーでやったほうが早い」といって、 メモリー上でソートするように変えてしまいました。 でも実はその中間ファイルは後続のJOBに引き継ぐものであり、 またその対象処理件数は膨大であったため、接続テスト時点でOUT。 でも、逆もありますよね、少ない件数を大量に処理しなければならなくて、 性能要件を満たすためにメモリー上でソートしないととてもスループットが出ないとか。これも運用テストあたりでOUT。 そして、SEとプログラマー間で、もめはじめるんですよね。たしかこの手の＠ITの記事がありましたよね。 さて、何が悪いんでしょうか。 行間を読めないプログラマが悪い？ 細部まで書いてないSEが悪い？ なんとなくですがどっちでも無い様に思います。なんとなくですが。 | ||||||||
|
投稿日時: 2005-09-20 10:08
この話では明らかにプログラマが悪いと思うんですが… まあ、パフォーマンスがって言う部分に関しては、 パフォーマンスの検証やら、考慮した設計やらなんやら、その辺の部分を 誰が責任持っているのか、担当しているのか、ということになるでしょうが… あ、「細部まで書いて無くても行間を読め」って言ってるんじゃないですよ、もちろん。 | ||||||||
|
投稿日時: 2005-09-20 11:07
よくＳＥの方が「仕様の行間を読んでコーデングしろ！」と言ってました。
以前、以下のような仕様書を渡されました。 「・・・（略）・・・ 1.勘定科目によって指定された所定の処理を行う 2.その処理結果を各ＤＢに書き出す 3. ・・・(略）・・・」 ここで勘定科目のコード表も渡されてなかったし、その勘定科目毎の 処理内容を記述してるものもありませんでした。 こんなもので、どうやったらプログラムを作ることが出来るんでしょうか？ これを書いたＳＥへ聞きに行ったのですが、 「そんなもの常識だろ？」 「えっ？！私はここの会社の社員じゃありませんよ。この勘定科目って・・・」 「こんなものも知らないで、プログラムなんて良く作れるね」 「そんなことを言わずに教えてください！」 ・・・・・・ 
結局、散々蔑まされて、教えてもらえませんでした。 しょうがないので、お客様に全部聞いてコーデングしました。 その時、お客様が怖かったし、自分が恥ずかしかったです。 
| ||||||||
|
投稿日時: 2005-09-20 11:23
今回の例ですと、SE 側が確実に悪いと言えるでしょう。 組める材料がない。こんなので仕事出されても工数なんて見積もれませんし。 Yoshi さんは正論を言っていると思います。 (お客さんに聞くのはまずかろうとは思いますが) 別の例だと PG が確実に悪い例もあります。 こういうのって、極論で語ると論争になりかねません。 どちらが悪いのかは、その時々の場合によって変わるでしょう。 (愚痴スレだと割り切って、愚痴だけで終われば良いのですが) 別の話で、「COBOL では常識だから、知らなくてどうする」なんて話もありました。 COBOL を存じてない方からしたら、どうなんだろうなぁと思いつつ、聞き耳立ててました。 しかも、C# での開発で COBOL "固有概念" の話が飛び出してくるもんだから、面白おかしく聞いてました。 _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||
|
投稿日時: 2005-09-20 11:32
きちんと用件定義が出来ていないで作られた仕様（私様）を元に全部が揃っていない設計書（拙計書）を作成（でっちあげ）してそれを渡し、疑問点を質問をすれば「行間を読め」「そんなの常識だろ」と言い、足りない追加資料をお願いすれば「そっちで作るんだろう」「何が必要なんだ」と言われ、リリース時に「動作が俺の思ってたのと違う」と言われ。
あなたの立場をわかってはいるつもりです。 長年一緒にやってきたのですから。 少しでもいいものを顧客に提供したいという思いは同じです。 ですが、なぜあなたは私達に丸投げでさも私達の問題のようにしてしまうのですか？ お互い後で困らないためにもう少し話しましょうと言ったのはあなた側のはずですよね？ 確かに私達にも落ち度があったこともありますが、それと違う次元で私達のせいにされるのは心外です。 もうその人とは一緒に仕事することはないでしょうけどね。 「切られてよかったと思った」という人の言葉をたまーに聞く事はあるけど、まさか自分が実感する立場になるとは思いませんでした。 以上、現実にあったことからの愚痴を書かせていただきました。 _________________ #「やらない」と「出来ない」を混同してはならない | ||||||||
|
投稿日時: 2005-09-20 11:40
この場合時間が切迫していまして、リーダやってる方がお客様のところに 行きっぱなしでしたので、私はどうしたら良いか分からず こんな行動になってしまいました。 ただ、このお客様が良い人で丁寧に教えてくれましたし 
上流工程の資料を殆ど頂きました。コード表も。 これがビックリするくらい多かったです。 
このプロジェクトでは、それから相当ヤバイ仕様書でも プログラムを書いていました。 結合テストも総合テストもやらされました。 [ メッセージ編集済み 編集者: Yoshi 編集日時 2005-09-20 11:46 ] | ||||||||
|
投稿日時: 2005-09-20 13:27
仕事がうまく運ぶのは何よりですが、こういう状況を放置してはダメです。 特に SE が「ほら見ろ自分のやり方でいいじゃないか」とつけあがるのを助長してしまいます。 # 上はちょっとだけまだマシです。これが「自分のおかげだ」と思うようになると末期です。 # 既に切れたようなので読ませていただいた一人としては一安心ですが、 # 件の SE が悪運強く干されることもなくソフトウェア業界の別の場所で # 生き残っているとしたら、大変疎ましいことです。 | ||||||||
|
投稿日時: 2005-09-20 13:56
ええ、それは行間からも読めました。(^^) 手を尽くしたからこその行動だろうとも思ってました。 まあ、念のため、です。 客に聞くのが当然と取られたら、少しイヤだったものでして... (^^;)
優しい方で良かったですね。 これで「何故、私が工数を裂かねばならんのだ!!」とか言われたら、 どうしていいかわかりませんものね... _________________ C# と VB.NET の入門サイト じゃんぬねっと日誌 | ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。