アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
年功序列型賃金も (スコア:5, すばらしい洞察)
短期間にプロジェクトをがんがん進められて売り上げを伸ばせる
ような人が企業の収益力のメインエンジンなんだろうけれども、
そういう人をサポートしたり、人が出した新しいアイディアに対して
その実装を考えられたり、またチーム内の人間関係を取り持てるような、
仕事に人生にある程度経験を積んだバランス感覚に優れた人もいないと
会社として成り立たない。
メインエンジンにはその出力に、姿勢補助エンジンにはその安定性に
応じて評価するってことじゃないですかね。
#と、学生としてはこのように思うわけです。
ごめんなさい。
Re:年功序列型賃金も (スコア:5, すばらしい洞察)
成果主義というのは結局成果が見えやすいか見えにくいかに依存しますよね。
よく言われることですが、プロジェクトの成功が目に見える開発部門の人に比べ
システムの保守運用を行う部門の人はどうしても評価が低くなります。
また、トラブルの解決が高く評価されがちなのも気になります。
トラブルを起こさないことの方が価値は高いと思うのですが。
人によっては年功序列型を選ぶことで評価制度への不服従の表明の意味もあるかもしれませんね。
Re:年功序列型賃金も (スコア:3, すばらしい洞察)
> トラブルを起こさないことの方が価値は高いと思うのですが。
トラブルを起こす人と解決する人が別人なら問題無いような気もします。
Re:年功序列型賃金も (スコア:1)
確かにそうなのですが、開発した人は詳細を把握しているだろうということで、解決も任せる場合が多いのではと思います。
Re:年功序列型賃金も (スコア:0)
> 解決も任せる場合が多いのではと思います。
違います。開発した人でなければ詳細を理解不能ということで、
解決も任せざるを得ない場合が多いのです。
Re:年功序列型賃金も (スコア:1)
> 解決も任せざるを得ない場合が多いのです。
でも、現実は、数ヵ月も経つと、開発者ですら詳細を忘れている罠。
酷いときには存在そのものを・・・
そんな開発者に任せざるを得ない場合、
「思い出せる可能性があるだけマシかも知れない」
という何とも後向きな便りかたになるんでしょうか。