＠IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- PR -

難しく考える開発者(ＰＧ)について

«前のページへ 1|2|3|4|5|6 次のページへ»
投稿者投稿内容
るぱん
ぬし
会議室デビュー日: 2003/08/01
投稿数: 1370
投稿日時: 2006-11-24 17:58
まぁ、定数クラスに追加して、配列かなんかで
回せるような処理にしておけば、
商品コードが増えてもまぁ、多少は問題ないでしょうねぇ。

でも、５個以上増えてきたら、
それをたてに、DBまで手を入れる・・・とか、
仕様変更の基準を予め作りましょう。

全ては打つ先手にかかっています。
がんばってくださいね
_________________
nagise
ぬし
会議室デビュー日: 2006/05/19
投稿数: 1141
投稿日時: 2006-11-24 18:03
引用:

Practical SEさんの書き込み (2006-11-24 17:39) より:
私もＳＥをやりたくてやっているわけではありませんよ。
正社員という立場と年が年なんで自動的にＳＥになった被害者のひとりですよ。
一生懸命なんですからきついことは言わないでよ。ウルウル。。。


ここは技術者の集まりなんで、頭ごなしに決め付けてかかるような発言は反発大きいですよ。
公正に客観的に見て、何が問題なのか、解決するにはどうしたらよいかを
考える人が主な利用者層ですから。
釣っただの釣られただのくだらない茶々をいれる人がいても、
その横でその議論からなにかを得ようとしているし、得ているし。

「ひどい目にあったんだよ〜」
「そうか、そりゃひどいな、オレもにたような経験あるよ。
　やつら、二言目にはできません、だもんな。全くいやになるよ」

といった感じのなんらの生産性のない愚痴を言いたいのであれば
適切な場所とは言えませんね。
同情と慰めは少ないけど、思索と解決策は提示するビジネスライクさが
技術系の人間が集う場所の趣でしょうか。
（あとは衒学的なジョークと、かな）

SEを「やらされている」んだったらやってられないと思うことも多いでしょうね。
私はSEを「やっている」人間なので気になりませんが。
もちろん、PGも「やっている」んですよ。えぇ。
あすか
ぬし
会議室デビュー日: 2006/07/12
投稿数: 309
投稿日時: 2006-11-24 18:13
別の視点からの意見を述べさせていただきます。

ＳＥ（Practical SE様）と
そのプログラマ様の関係が分りませんので
あくまで仮定の話です。

お二人の会社や部署が違う場合
（年度月度の予算、売上を別々の枠が設けられているグループという意味です）
仮に私がそのプログラマ様であれば
既に作成したプログラムに対し
少量の変更であろうと難癖をつけて
請け負うことを拒否したくなる可能性があります。
ぶっちゃけて言えば、修正をするのであれば金と時間を出せ、
と言うことになります。

自分の責任範囲においてバグの発生等があれば
それはどんなに金や時間が掛かろうと
プログラマは修正するべきですが
大元の仕様の変更による修正によって発生する工数ならば
それがわずかな物であろうとも拒む可能性があります。
修正が１秒で出来ても再テストを考えると気が重いですから。

プログラマ様の言っている内容が正しいのかどうかは
情報が少ないので判断しようがありませんが
こんな見かたもあるのだという一意見を述べさせていただきました。
ひら
ぬし
会議室デビュー日: 2005/03/04
投稿数: 260
投稿日時: 2006-11-25 02:15
引用:

Practical SEさんの書き込み (2006-11-24 16:39) より:
件名の件、開発者(PG)の意図がわからないのでご質問させて下さい。

Practical SEさんは「開発者はSEの設計に従うのが当然だ」という信念があり、
開発者が意見をするといったことはそもそも許せない事になっていませんか？
そして、今回の件で開発者との関係がこじれてしまっており、頭にきた勢いで
ここの会議室に書いていませんか？そして、「そうだ、そうだ」と味方になって
くれる人を求めているようにも見えます。(もしかしたら、その開発者も
他の掲示板で「融通の利かない設計者(SE)について」というタイトルで
書きこみしているかもしれませんよ？)
でも、これってただの愚痴ですよね…。
(「教科書ではこうしている」なんて、子供の言い訳としか思えませんし)

多少の愚痴なら聞いてあげても良いとは思いますが、所詮は赤の他人ですので
ここで適切な解決策が出たからといって、すぐに効果が出る訳ではないという
ことを前提にお話します。

きちんと付帯状況を見たわけではないので、どちらが正解ということは
わかりませんが、Practical SEさんの案と開発者の案、書きこみを見る以上は
『どちら正解』のように見えます。そして、Practical SEさんのおっしゃる通り
このようなことで堂々巡りしていたのでは時間の無駄です。

そうは言いましても、最終的には開発者にプログラムを作ってもらわなければ
なりませんので、以下のようにしてみたらいかがでしょうか？

・開発者案のメリット、デメリットを調査の上、説明する。
・Practical SEさん案のメリット、デメリットを調査の上、説明する。

時間も手間もかかりますので、「こんなことやってられない」というのが
本音でしょう。それこそ、時間の無駄としか思えないのかもしれません。
しかし、これ以外に相手を説得する方法は私には思いつきません。

(それとも、「クビにするぞ」って脅しますか？「こんな会社辞めてやる」
と言われたらそれで開発者との関係はオシマイです。)

開発者との関係が冷えきってしまって、上記の調査を行ってそれを説明するに
しても、非常に気まずい雰囲気になってしまっていますので、説得は難しいと
思います。そこで、上司の方に現状を説明した上で、仲介に入ってもらったら
いかがでしょうか？

未記入
大ベテラン
会議室デビュー日: 2005/03/12
投稿数: 148
投稿日時: 2006-11-25 07:24
確かにifの追加だけですむところを
DBの見直しからしなければならないなんて面倒なことですな。

DBの見直しからなら修正やテストが大きく減るとか言うもんでもないでしょうに。
でもifが複雑に絡み合うなら開発期間や開発費を増やすとかして
いろいろ見直さなければならないけど。

余裕のあるプログラマだな。
そういう俺もちょっとした修正であっても数日掛けるけど。
unibon
ぬし
会議室デビュー日: 2002/08/22
投稿数: 1532
お住まい・勤務地: 美人谷　　　　　　　　良回答(20pt)
投稿日時: 2006-11-25 11:42
「顧客→SE」の関係が、そのまま「SE→PG」の関係に降りてきた、というように見えます。

顧客から仕様変更を求められた場合、たいていは SE が要求分析をやり直すことはなく、要求定義を変更するだけで済ませてしまうため、しわ寄せがそのままプログラマーに降りてきます。これが問題だと思います。
プログラマーにすれば、プログラムを追加・修正するだけなら良いのですが、受け入れた以上、バグがないようにする必要があり、テストもそれに応じて追加しなければならなくなります。プログラマーが統一的に考えて作りこんだ画面遷移の手順が一部で乱れたりするのはストレスがたまり、プログラマーが考える美学が侵されたと感じてしまいます。

顧客→SE→PG という流れがある以上、SE の段階で仕様変更をある程度ブレークダウンしてプログラマーに渡すべきです。それか代わりに、「プログラマーは言われたとおりコードを追加するだけで良くそれに伴なうテストはしなくてよい。バグがあってもよい。」などの念書を書くことです。それができるかどうかを思い浮かべてみるのが良いと思います。しかし、普通はそんなことは SE としてはできないでしょう。だとすれば、やはり SE が問題を解決しないままプログラマーに投げている仕事量は、相当量のものであると認識したほうが良いです。

--
unibon {B73D0144-CD2A-11DA-8E06-0050DA15BC86}
未記入
大ベテラン
会議室デビュー日: 2005/03/12
投稿数: 148
投稿日時: 2006-11-25 12:11
ブレークダウンした結果if文追加するだけですむやん
言われたとおりにしたからテストしなくていいことなんかないだろ
object
ぬし
会議室デビュー日: 2002/03/20
投稿数: 338
お住まい・勤務地: 香川県高松市
投稿日時: 2006-11-25 12:54
objectです。

問題を私なりに、少し整理してみました。

>条件文（if、switchなど)をひとつ追加する程度の仕様変更や
>ひとつフラグを立てればいいだけ程度の仕様変更を
>素直に受け入れない開発者とＳＥの間で揉めています。
ここでの
「条件文（if、switchなど)をひとつ追加する程度の仕様変更や
　ひとつフラグを立てればいいだけ程度の仕様変更」
という判断が、問題(トラブル)を起こす原因の様に思います。

この判断は、
・「RDB(SQL)」に対する理解不足。…(1)
・「プログラム」に対する理解不足。…(2)
#「プログラムでの処理」は少し知っている。
から来ている様に感じられます。

●先ず、(1) に関して。
「RDB(SQL)」は簡単に言えば
「データに対して、既定の論理操作が定義された一つの閉じた世界」
と言っても良いと思います。
#表現が少し曖昧ですが、分かり易さの方を選択しました。
#「論理操作」-> 述語論理に対する「一つの応用」程度の意味。
#実際「RDB(SQL)」は「述語論理の一つの応用」だと思います。

●次に、(2) に関して。
「プログラム」は簡単に言えば
「一般的事象に対して、論理操作を含めプログラマー(SE)が創造していく、開いた世界」
と言っても良いでしょう。
#プログラムも「述語論理」の応用的側面を持ちますが、それが全てではありません。
#尤も、そういう意味では「RDB(SQL)」の世界も「述語論理」が全てではありませんが。
#「物・事」に対して「正当性の保証に係わる」だけですから。
=========================
以上から、簡単に纏めると、
プログラマーが、「プログラムがいくら開いた世界」とは言え、
「RDB(SQL)」内で解決すべき問題をプログラム内に持ち込む事を嫌う
のは自然であるし、基本的には、そうすべきだと思います。
#実際、プログラムコードに一つの商品に対する操作を埋め込むと、この時点で、
#「RDBとプログラム」の「普通であった関係」が、特異な関係に変異します。
#変異：動作、メインテナンス等を含めて。

そういう意味で、私も、
「SQLサーバーに除外テーブルを追加して処理」…(3)
をすれば良いと思います。

実際、お話を伺う限り、
(3)は、大きな作業では無いと思います。(DB設計の見直しかどうかは別として。)
#お話を伺う限り、
#除外商品を除外商品テールの商品コードでハジクという単純明瞭な作業
#だと思いますから(構造まで変える必要は無い？)。

ただ、
「SEが問題の本質をどこ迄理解しているか」
は、「PG」との感情的な問題を発生させる可能性はあると思います。
それが、起きているのでしょうか？

若し、「RDB」の変更も「PG」の作業なら、SEである「Practical SE」さんが
「一緒にやろう」
と提案すれば、関係は今迄より寧ろ良くなるという可能性もあると思いますよ？
#私の状況理解が間違っている可能性は十分にあります。
#でも、少しでも参考になれば幸いです。
«前のページへ 1|2|3|4|5|6 次のページへ»

スキルアップ／キャリアアップ（JOB@IT）