アカウント名:
パスワード:
いろんなケースがあると思うので、一概にどうとも言えないと思うのですが、大雑把に言ってしまうと、例えばあるモジュールの開発を部下に依頼するときに、そのモジュールのプログラムの組み方を一から十まで詳細に説明する上司ってあんまりいないと思うのです (そんな指示の出し方をする人がいるとしたらそれはそれでほとんどの場合不効率だと思う。相手が新人さんとかで、教育が必要な場合などはこの限りじゃない場合もあるけど)。で、言われたとおりに動くモジュールを作ってくれるわけだけど、それを如何にして作り上げたかは、単純な作業時間的効率にしても、プログラム自体のメンテナンス性などにしても、やはり千差万別だと思うのです。
で、そうしたときに、今どういったものを作っていて、それはどういった部分に使われるもので (関係する他モジュールとの連動性)、どういった部分に気を使う必要 (言い換えれば、バグが出る可能性) があって、プログラム的には (あるいは内部仕様として)、どういった部分が明確になっているとメンテナンスを行なう上ではありがたいのか、といったようなことをしっかり考えながら仕事ができる人と、そうでもない人との差というのは、かなりあると思うのです。
もちろん、そういう部分を埋め合わせする機会を提供するのがレビューだったりするわけで、ここにまたレビューの重要性なんてモノが問われたりするわけですが、テスト同様、レビューというものが軽視されがちな風潮の中、あんまり考えて仕事することができない人というのはやっぱり多くなっちゃうんじゃないかなぁとはつくづく感じてしまうのであったりするわけで。。。
でも、本当にやる気がある人だったら、考えて仕事をする、という視点をしっかり教育してあげることで、いくらでも化ける可能性はあると思う。その場限りの努力は、努力とはいえない。学習し、あるいは研究を重ね、経験を蓄積していった人にだけ、そういうセンスは磨かれてゆくのだと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日本発のオープンソースソフトウェアは42件 -- ある官僚
やっぱりないっす (スコア:4, 興味深い)
1つ目のタイプは裁量労働だの業績評価だので事実上残業カットされた結果、明確に自分の仕事であるもの以外はやらなくなった連中。この連中は納期がどうなっても気にしない。だからバグが見つかって怪しいのでプロジェクトマネージャから調査を指示されても、自分のところのバグという証拠が外部から示されない限り調査すらしない。以前は証拠の有無に関係なく調査などの活動を行っていた。(もちろん、残業手当がついていたから)
2つ目のタイプは、最近のリストラで人が減ったり1つ目のタイプで放置さ
ちなみに、やるき「しか」無い奴も困る (スコア:3, すばらしい洞察)
>明確に自分の仕事であるもの以外はやらなくなった連中。
>この連中は納期がどうなっても気にしない。
「自分に与えられた仕事」はやるし、やろうと努力もするんだけど、
そのヤレと言われた「そのままのやり方」でしかやろうとしない、
っていう連中には個人的にウンザリしてます。
つまり、どんなに不適切や非効率な指示をされても、それをそのまま実行しちゃう。
納期は気にするんだけど、
Re:ちなみに、やるき「しか」無い奴も困る (スコア:1)
不適切な指示をする人間が一番問題だと思うが…?
そういう人間に限って、
間違っていても引かない、
引かない代わりに思いつきで指示を変更する、
相手をすぐに否定する、
事細かに突っ込んで指示以外のことをさせない、
なんてことあるけどね。
(しかも、そういう人ほど仕事をしているように見えるから厄介)
そうなると、人間は基本的にトラブルを避ける生き物なので、
「まあ言うとおりにしとけば良いか」と思うわけですよ。
で、それに慣れると他の
Re:ちなみに、やるき「しか」無い奴も困る (スコア:3, 興味深い)
いろんなケースがあると思うので、一概にどうとも言えないと思うのですが、大雑把に言ってしまうと、例えばあるモジュールの開発を部下に依頼するときに、そのモジュールのプログラムの組み方を一から十まで詳細に説明する上司ってあんまりいないと思うのです (そんな指示の出し方をする人がいるとしたらそれはそれでほとんどの場合不効率だと思う。相手が新人さんとかで、教育が必要な場合などはこの限りじゃない場合もあるけど)。で、言われたとおりに動くモジュールを作ってくれるわけだけど、それを如何にして作り上げたかは、単純な作業時間的効率にしても、プログラム自体のメンテナンス性などにしても、やはり千差万別だと思うのです。
で、そうしたときに、今どういったものを作っていて、それはどういった部分に使われるもので (関係する他モジュールとの連動性)、どういった部分に気を使う必要 (言い換えれば、バグが出る可能性) があって、プログラム的には (あるいは内部仕様として)、どういった部分が明確になっているとメンテナンスを行なう上ではありがたいのか、といったようなことをしっかり考えながら仕事ができる人と、そうでもない人との差というのは、かなりあると思うのです。
もちろん、そういう部分を埋め合わせする機会を提供するのがレビューだったりするわけで、ここにまたレビューの重要性なんてモノが問われたりするわけですが、テスト同様、レビューというものが軽視されがちな風潮の中、あんまり考えて仕事することができない人というのはやっぱり多くなっちゃうんじゃないかなぁとはつくづく感じてしまうのであったりするわけで。。。
でも、本当にやる気がある人だったら、考えて仕事をする、という視点をしっかり教育してあげることで、いくらでも化ける可能性はあると思う。その場限りの努力は、努力とはいえない。学習し、あるいは研究を重ね、経験を蓄積していった人にだけ、そういうセンスは磨かれてゆくのだと思います。
むらちより/あい/をこめて。
Re:ちなみに、やるき「しか」無い奴も困る (スコア:1)
レビューが軽視されるプロジェクトの次に、
レビューが形骸化(?)してるプロジェクトに行ったことが有ります。
#ガリバー旅行記な気分なのでG7
「レビューというもの」を重要視してはいるんですが、
じゃあ何を「レビュー」と呼ぶのか?っていう時点でズレてるっていうか。
#コメントのテニヲハを直すのに2時間かけるのは問題でしょなのでG7
#てか、コメントじゃなく先ず実ソースを読めよな。コメントの評価はその次だろ。
#さては、お前らソース読めないからコメントに「だけ」こだわってるんでねーのか?と小一時間…
劣ったビュー(視点)に基づけば、劣った(最悪マイナスな)レビューしか出来んわけです。
重要なのはレビューという名称じゃなく、その中身がきちんと優れたものであるかどうか、なんですよね。
あ。テストも同じです。テストの着眼点や手法が劣っていたら、効果は激減。
盲人は盲人を導けない(聖書によれば)って奴ですかね。
だから例えば「レビュー者の能力」をまず問うべきなんですが、
そこから先がまたなんともグチャグチャで…(T_T)