@IT情報マネジメント会議室は、2009年4月15日に新システムに移行しました。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
新たに書き込みを行う場合には、新しい会議室をご利用ください。
- @IT情報マネジメント 会議室 Indexリンク
- IT戦略
- 仕事の改善
- アーキテクチャ
- プロジェクト管理
- ITインフラ
- Webマーケティング
- BPMプロフェッショナル
- 業務アプリ
- - PR -
「それは、もう決まった事だから」
投票結果総投票数:126 | |||
---|---|---|---|
積極的思考停止に陥る | 91票 | 72.22% | |
損失を出しても問題を改善する | 35票 | 27.78% | |
|
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2004-09-16 10:35
決まった事だから、その問題について考える必要は無い、痛いトコ突かれる前にその
「痛いトコ」について議論を封じようとする防御の姿勢が垣間見えてきますが、実際 そういうシステム・エンジニアについ最近も出会いましてな (プ とどのつまり、ある問題について「思考停止」「論理的脳死」を要求されてる訳ですな。 これ、問題の質・規模によって結果も異ってくるかと思いますが、例えば銀行のオン ライン系で、ある処理のディスクアクセスが頻繁でパフォーマンスに著しい劣化が見ら れる、これ、仮に「納期が押し迫ってるから」問題点を予見・把握し得る立場にあり ながら、スケジュール遅延の為に発注元からの報酬額カット、即ち社内において業績を 否定的に評価される事を恐れる余り、「もうテキストファイルに対する read / write は決まった事だから」とそれ以上課題について議論しないという事は、後々預金者や発注元に使用に耐え得ない程のパフォーマンスの悪さを知られてしまう事を承知で放置した 訳で、結果だけで言うとこれは預金者や銀行に損失を与えた、と言われかねん職務怠慢 、悪く捉えれば「意図しない背任」という事にもなりかねん。 これを、スケジュールを遅らせてでもアーキテクチャを変更、、この場合例えば 同時多発プロセスによる膨大な数に上るテキストファイルの順次読み出しによる特定データの 取得がディスクアクセス過多によるオーバーヘッドとなりパフォーマンスのボトルネックと なっている、、を、 RDBMS からの SQL 呼び出し一発に変更、、という改善の余地があり、 果たしてその通り仕様変更に伴うデータ取得 I/O インターフェースの実装変更を余儀なく され、納期を大幅に過ぎた為にペナルティで会社に損失を与える方を採るか、それともその 問題については後回しにして、客からクレームがこないうちは「問題は問題にはならない」と 判断、後からクレームと共に会社と社会に損失を与えた損害賠償を支払う羽目になるか・・・ 正に前門の虎 後門の狼の「三菱ふそう」状態ですが、こういう時あなたならどうする? 積極的思考停止に陥り問題を「存在しない」として片付けて後でペナルティを課され る側に回るか、それとも問題を問題として受け止め、必要ならば仕様変更を行い、高 品質でも納期遅れのペナルティを課される側に回るか・・・!? | ||||
|
投稿日時: 2004-09-16 11:49
「決まった事」が決まった経緯が不明です。
また、責任の所在を明らかに出来ていません。 責任の所在を管理する人も明らかにされていません。 お話を伺う限りに於いては、判断が難しいです。 と言う回答にならざるを得ませんでした。 前提がないので有れば前提を作る作業が必要だし、 痛い所があるならアナウンスした上でお金をぶんどりに行くような手はずが必要と考えます。 「そんな事するだけ無駄だよ」というのであれば、やっている事は痛い所付かれた人と 同じなのではないかと考えました。 | ||||
|
投稿日時: 2004-09-16 11:58
こんにちは。
難しい問題ですねぇ (^^; 一技術者としては 「損失を出しても問題を改善」 しないと、後々の実入りに影響を及ぼすと考えるのですが。 要求仕様等で明確に応答スピードについて定義されていても同様ですね。 実際、「パフォーマンステストに入ってからが長い」 とは、よく耳にする言葉です… | ||||
|
投稿日時: 2004-09-16 12:06
つまり、責任者の有無、責任者が誰かによって判断を変えるという事ですか?
しかし、あるプロジェクトに参画する者が全員最初からそのプロジェクトに居たとは 限りません。ある仕様が「決まった経緯」というのは最初から参画していた者に とっては明らかなのでしょうが、そうでない者にとっては、「既に決まった事」と して提示される以外無いでしょう。ただでさえスケジュールオーバー気味なところ、 「どうやって決定されたのか」まで懇切丁寧に提示してくれる発注者は少ないかと思われ ます。 投票は、「ある処理のディスクアクセスが頻繁でパフォーマンスに著しい劣化が見られる」 事を予め把握しておきながら、「あなたなら、どう行動するのか?」という非常に シンプルな問いです。責任が何処にあるか、によって行動を変える等、複雑な概念は 不要という前提です。 損得勘定でいうとどちらの損失を採るか、というだけです。 | ||||
|
投稿日時: 2004-09-16 12:18
いいえ、流し(?)の PG をしているので、お客さま(この場合エンドユーザさまではない)の意向に従わなければならないときもある、ということです。 個人の意思は別にして。 予見しているのであれば、当然指摘しますが。 # 私も途中参画のパターンが多いです | ||||
|
投稿日時: 2004-09-16 12:27
最終的な納め先の客が「カラスは白!」と言えば白と思わなきゃならんと思います。
客がわかってて案件として保留している場合もありますから。 | ||||
|
投稿日時: 2004-09-16 12:52
そうすると、親亀がコケたら何とか、、親亀の間違った判断で我々小亀がその損害を被る
(発注者倒産、担当部署解体、取引停止、賃金引下げ)事もあり得ますな。まぁ、現場で 「黒を黒」と言うた為に即切られるよりはマシですか? 私の場合、切られても「黒は黒」です。 切られた事もあります (プ | ||||
|
投稿日時: 2004-09-16 13:00
アンケートと見せかけて、グチをこぼすだけですか。
暇なんですね。 |