アカウント名:
パスワード:
いろんなケースがあると思うので、一概にどうとも言えないと思うのですが、大雑把に言ってしまうと、例えばあるモジュールの開発を部下に依頼するときに、そのモジュールのプログラムの組み方を一から十まで詳細に説明する上司ってあんまりいないと思うのです (そんな指示の出し方をする人がいるとしたらそれはそれでほとんどの場合不効率だと思う。相手が新人さんとかで、教育が必要な場合などはこの限りじゃない場合もあるけど)。で、言われたとおりに動くモジュールを作ってくれるわけだけど、それを如何にして作り上げたかは、単純な作業時間的効率にしても、プログラム自体のメンテナンス性などにしても、やはり千差万別だと思うのです。
で、そうしたときに、今どういったものを作っていて、それはどういった部分に使われるもので (関係する他モジュールとの連動性)、どういった部分に気を使う必要 (言い換えれば、バグが出る可能性) があって、プログラム的には (あるいは内部仕様として)、どういった部分が明確になっているとメンテナンスを行なう上ではありがたいのか、といったようなことをしっかり考えながら仕事ができる人と、そうでもない人との差というのは、かなりあると思うのです。
もちろん、そういう部分を埋め合わせする機会を提供するのがレビューだったりするわけで、ここにまたレビューの重要性なんてモノが問われたりするわけですが、テスト同様、レビューというものが軽視されがちな風潮の中、あんまり考えて仕事することができない人というのはやっぱり多くなっちゃうんじゃないかなぁとはつくづく感じてしまうのであったりするわけで。。。
でも、本当にやる気がある人だったら、考えて仕事をする、という視点をしっかり教育してあげることで、いくらでも化ける可能性はあると思う。その場限りの努力は、努力とはいえない。学習し、あるいは研究を重ね、経験を蓄積していった人にだけ、そういうセンスは磨かれてゆくのだと思います。
必要なのかな? 必要なんだろうなぁ。1 つ目のタイプの人たちに、徹底的に嫌われるタイプの、厳し~い上司。
あー、出世はしたくないものだねぇとかいう (-_-)zz...
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
普通のやつらの下を行け -- バッドノウハウ専門家
やっぱりないっす (スコア:4, 興味深い)
1つ目のタイプは裁量労働だの業績評価だので事実上残業カットされた結果、明確に自分の仕事であるもの以外はやらなくなった連中。この連中は納期がどうなっても気にしない。だからバグが見つかって怪しいのでプロジェクトマネージャから調査を指示されても、自分のところのバグという証拠が外部から示されない限り調査すらしない。以前は証拠の有無に関係なく調査などの活動を行っていた。(もちろん、残業手当がついていたから)
2つ目のタイプは、最近のリストラで人が減ったり1つ目のタイプで放置された結果残った仕事が納期に影響するのを気にして、そういったところを頑張って処置していたが、あまりの過負荷と残業手当てなしの仕打ち、残業時間が長いことによる能力低しの査定(現場を知らない上のほうからは仕事が遅いと見えるらしい)などに打ちひしがれて気力が萎えているタイプ。
2つ目のタイプの亜種として、「過労による入院で退職」「過労によるストレスで失踪(まじで捜索願い出した・・・)」「やってられないので転職・独立」があります。(うちの職場、ここ数年毎年入院者や失踪者が出るんですけど・・・)
当たり前ですが、1つ目のタイプと2つ目のタイプ(特に予備軍)の人間関係がいいところは見たことがありません。どんどん2つ目のタイプの予備軍は減っていくので、ここ数年だんだんプロジェクトの遅延の度合いが酷くなってます。(このままだと、会社潰れるぞ・・。たぶん。)
3つ目のタイプとして、自分の上司(妻子あり)のように、「女にうつつを抜かしててやる気が無い」というのもあります。これはいつの時代でも同じかもしんないけど、その下で仕事を押し付けられてるとやる気失せる・・・。
#転職しよっかな~
ちなみに、やるき「しか」無い奴も困る (スコア:3, すばらしい洞察)
>明確に自分の仕事であるもの以外はやらなくなった連中。
>この連中は納期がどうなっても気にしない。
「自分に与えられた仕事」はやるし、やろうと努力もするんだけど、
そのヤレと言われた「そのままのやり方」でしかやろうとしない、
っていう連中には個人的にウンザリしてます。
つまり、どんなに不適切や非効率な指示をされても、それをそのまま実行しちゃう。
納期は気にするんだけど、
なぜ納期が遅れそうになってるか?という一段ひいた視点を、持たない。
だから遅れるに決まってる非効率なやり方を延々と繰り返す(藁
----
やっぱり「心が折れる」なのかなあ…
http://itpro.nikkeibp.co.jp/free/ITPro/OPINION/20040325/141948/
>“心が折れるその一言”がプロジェクトを倒壊させる IT Pro 記者の眼
Re:ちなみに、やるき「しか」無い奴も困る (スコア:1)
不適切な指示をする人間が一番問題だと思うが…?
そういう人間に限って、
間違っていても引かない、
引かない代わりに思いつきで指示を変更する、
相手をすぐに否定する、
事細かに突っ込んで指示以外のことをさせない、
なんてことあるけどね。
(しかも、そういう人ほど仕事をしているように見えるから厄介)
そうなると、人間は基本的にトラブルを避ける生き物なので、
「まあ言うとおりにしとけば良いか」と思うわけですよ。
で、それに慣れると他の場所でもそうなっちゃう。
でも、それは本人の問題と言うよりも組織構造の問題なわけで。
>なぜ納期が遅れそうになってるか?という一段ひいた視点を、持たない。
「何故その人が指示通りにしか動かないのか?」
と言う”一段引いた視点”を貴方も欠いてますよ。
結局、人のアラほど良く見えるってやつなのですが、
もしあなたの話があなたの部下を指しているのだとすると、
考え直す必要があるのはあなた自身かもしれませんね。
Re:ちなみに、やるき「しか」無い奴も困る (スコア:3, 興味深い)
いろんなケースがあると思うので、一概にどうとも言えないと思うのですが、大雑把に言ってしまうと、例えばあるモジュールの開発を部下に依頼するときに、そのモジュールのプログラムの組み方を一から十まで詳細に説明する上司ってあんまりいないと思うのです (そんな指示の出し方をする人がいるとしたらそれはそれでほとんどの場合不効率だと思う。相手が新人さんとかで、教育が必要な場合などはこの限りじゃない場合もあるけど)。で、言われたとおりに動くモジュールを作ってくれるわけだけど、それを如何にして作り上げたかは、単純な作業時間的効率にしても、プログラム自体のメンテナンス性などにしても、やはり千差万別だと思うのです。
で、そうしたときに、今どういったものを作っていて、それはどういった部分に使われるもので (関係する他モジュールとの連動性)、どういった部分に気を使う必要 (言い換えれば、バグが出る可能性) があって、プログラム的には (あるいは内部仕様として)、どういった部分が明確になっているとメンテナンスを行なう上ではありがたいのか、といったようなことをしっかり考えながら仕事ができる人と、そうでもない人との差というのは、かなりあると思うのです。
もちろん、そういう部分を埋め合わせする機会を提供するのがレビューだったりするわけで、ここにまたレビューの重要性なんてモノが問われたりするわけですが、テスト同様、レビューというものが軽視されがちな風潮の中、あんまり考えて仕事することができない人というのはやっぱり多くなっちゃうんじゃないかなぁとはつくづく感じてしまうのであったりするわけで。。。
でも、本当にやる気がある人だったら、考えて仕事をする、という視点をしっかり教育してあげることで、いくらでも化ける可能性はあると思う。その場限りの努力は、努力とはいえない。学習し、あるいは研究を重ね、経験を蓄積していった人にだけ、そういうセンスは磨かれてゆくのだと思います。
むらちより/あい/をこめて。
Re:ちなみに、やるき「しか」無い奴も困る (スコア:1)
レビューが軽視されるプロジェクトの次に、
レビューが形骸化(?)してるプロジェクトに行ったことが有ります。
#ガリバー旅行記な気分なのでG7
「レビューというもの」を重要視してはいるんですが、
じゃあ何を「レビュー」と呼ぶのか?っていう時点でズレてるっていうか。
#コメントのテニヲハを直すのに2時間かけるのは問題でしょなのでG7
#てか、コメントじゃなく先ず実ソースを読めよな。コメントの評価はその次だろ。
#さては、お前らソース読めないからコメントに「だけ」こだわってるんでねーのか?と小一時間…
劣ったビュー(視点)に基づけば、劣った(最悪マイナスな)レビューしか出来んわけです。
重要なのはレビューという名称じゃなく、その中身がきちんと優れたものであるかどうか、なんですよね。
あ。テストも同じです。テストの着眼点や手法が劣っていたら、効果は激減。
盲人は盲人を導けない(聖書によれば)って奴ですかね。
だから例えば「レビュー者の能力」をまず問うべきなんですが、
そこから先がまたなんともグチャグチャで…(T_T)
Re:ちなみに、やるき「しか」無い奴も困る (スコア:2, 興味深い)
その視点から、自分自身に対して限界まで厳しく見ても、
「理由は、その人の『限界』にある」
という結論に達したことが過去一ヶ月以内に二回ほどあります。
今は、その『限界』を前提にして対処するようにしてます。
あきらかに「業務の肩代わり」かつ「給料外の仕事」だし、
そして、それゆえのリスクもあります。
しかし、自分の業務遂行、ひいては「成果」に影響するので
止むを得ません。
#愚痴だけどIDで。
Re:ちなみに、やるき「しか」無い奴も困る (スコア:1)
まあ指示する側も人間なんで、常に適切完璧な指示を出す、というわけでも無いでしょう。
普段はそれなりに適切な指示を出していても、時には間違った指示を出すこともあるわけで。
で、問題なのは、そういう不適切な指示を出されたときに、
「そこは○○なやり方のほうが良くないですか?」
と質問(逆提案)してくれるかどうか、ですね。
G7 がウンザリしてるのは、そういうふうに「聞き返す」ことをしない人でしょう。
とにかく言われたことだけは頑張るが、その裏にある「何を目的とした指示なのか」を考えない。
いわば本質的に「兵隊」な人。なんなら「ダム端」な人と言ってもいいかも。
自分がやってる作業が、全体の中でどういう位置にあるのか、どういう役割を持っているのか。
そこらへんを考える想像力が無いと、生産性や品質などもイマイチになりがちです。
考えてくれる人だと、「あ、じゃあ××な感じでやっといたほうがいいですね」と、話の通りが良いんですが……
# 部下からの質問や逆提案をつぶすような上司は、論外。
# ちゃんとした根拠があってダメ出しするならいいけどさ。
*-----------------------*
-- ウソ八百検索エンジン --
Re:ちなみに、やるき「しか」無い奴も困る (スコア:1)
あー。俺が(今回のコメントに限らず常態として)ウンザリしてる対象は、
両方です。
貴方の話と、その1つ上の人が言った話と、両方。
>自分がやってる作業が、全体の中でどういう位置にあるのか、どういう役割を持っているのか。
>そこらへんを考える想像力が無いと、生産性や品質などもイマイチになりがちです。
ちなみに「想像」だけじゃ不味いです。
定義する人間が定義したら、それをつぶさに読む(評価/Evaluate?)ってことをする必要が有る。
やるべきは、Evalした上で、その内容に不味そうな部分が有ったら突っ込む。ってとこじゃないでしょうか。
#なので、情報量不足なドキュメントしかないと、凄く辛い。
#「ドキュメント有るでしょ。読め」といわれても、読んでも「判りたい肝心のこと」が書いてなかったりするんだよね。
># ちゃんとした根拠があってダメ出しするならいいけどさ。
DQNな人は、根拠が「ちゃんと」してるかどうか自体を見誤るんですよね。
Re:ちなみに、やるき「しか」無い奴も困る (スコア:0)
無能な振りをしておいたほうが楽なんだよ、、、
逆らうなんて面倒だしリスキーだし、
個人的にメリットなんて何も無いだろう。
Re:ちなみに、やるき「しか」無い奴も困る (スコア:0)
Re:ちなみに、やるき「しか」無い奴も困る (スコア:1)
これがTRUEかどうかは俺には判らないけど、
ただ言えそうなことは、
「無能として振舞う訓練(藁)を続けていると、それはいずれ、身に染みついてしまう」
だと思います。
だからこそ怖いんですよね。家庭内暴力と同じ(?)で、無能は連鎖する。
Re:ちなみに、やるき「しか」無い奴も困る (スコア:0)
Re:ちなみに、やるき「しか」無い奴も困る (スコア:1)
私は「無能な上司とその部下、それを眺めてる G7」と思ったんだけど。
だって G7 のコメントで、
>つまり、どんなに不適切や非効率な指示をされても、それをそのまま実行しちゃう。
って、書いてるし。
# つまり G7 は不適切or非効率とわかってそういう指示を出してると。
# そりゃ無能とかそういうレベルじゃないな。
*-----------------------*
-- ウソ八百検索エンジン --
Re:ちなみに、やるき「しか」無い奴も困る (スコア:1)
いや、指示出す側じゃないんですけど(^^;
Re:ちなみに、やるき「しか」無い奴も困る (スコア:1)
その指示に対し、プロとしての主体性を失っていることが問題なのです。
まぁ、場にいるうちの誰が「一番問題か」と言われたら駄目な指示を出す人間だというのに異存はありません。
でも主体性を失い、ましてやそれを環境のせいにしてしまう側にも問題はあると思うのです。
こういう事を言うのも私が指示を受ける側の人間だからかも知れませんが…
Re:ちなみに、やるき「しか」無い奴も困る (スコア:1)
面白いキーワードですね。
というのは、「言われた仕事をやれ!」という捉え方もまた
「プロ」の道だと解釈されがちなようなので。
つまり、「依頼された仕事をやる」のと「自分の経験とかからして、これじゃ不味いよと言う」のとが
どう折り合いをつけるか?っていう問題なんですよね。
一言でいえばフィードバックの問題だと思います。
つまり、フィードバックが旨く通るような職場であるかどうか?っていう問題だと。
#ハナから言うネタすら無い奴は論外なので勘定に入れませんが…
上流の連中が下流に、
判ってて踏み込むのは有り、
判ってて踏み込まないのも有り、
判らないんで踏み込まないのも、まあ理想ではないけど許せるかな、
判らないのに踏み込むのが、一番困るかな。
#それ以前に古典的な「上流、下流」という切り分けがヤバイと思うのでG7
#どっちが上か下かなんて判らなくなるくらいに意見(や実装案としてのソース)が往復しまくるのが、望ましいんじゃないかと。
Re:ちなみに、やるき「しか」無い奴も困る (スコア:1)
>そういう人間に限って、
>間違っていても引かない、
>引かない代わりに思いつきで指示を変更する、
>相手をすぐに否定する、
>事細かに突っ込んで指示以外のことをさせない、
>なんてことあるけどね。
>(しかも、そういう人ほど仕事をしているように見えるから厄介)
まるで私の上司を指しているかのようですw
こうなるとチーム全体はトラブルを避けるためみんな無口になります。
その代わり自分が責任を被らないための予防線を張ることには
非常に気を使い、上司からの連絡や指示は全てメモを取り
全員に供覧して証拠を残します。
これだけ部下から嫌がられているのに、酒席になれば
「このチームには組織としての一体感が無い」と嘆くのですから
始末が悪い。
どこの会社や組織にもこういう奴はいるんだなと思いつつも、
やっぱり自分の近くには居てほしくないですね。
And now for something completely different...
Re:ちなみに、やるき「しか」無い奴も困る (スコア:0)
マネージャだって暇じゃないんだし、サポートするのも部下の務め。
指示だしの場面場面で、きちんと状況を把握した上で確認したりしていけるかどうかってことでしょう。
それができないのは、社会人以前のバイト君レベルだと思う。
バイト君でも有能なやつはちゃんとやる。
Re:やっぱりないっす (スコア:1, 興味深い)
Re:やっぱりないっす (スコア:1)
新しい事を受け入れる素地がない人(会社)なのかな…って思ったけど。
新しい技術に果敢に挑戦して玉砕する人よりも、
自分の知己の範囲にしがみ付き変化を恐れる人のほうが厄介だよね。
#新人君の空回りをフォローできる先輩(上司)でなくて何の先輩だろう?
Re:やっぱりないっす (スコア:3, すばらしい洞察)
「新しい技術に果敢に挑戦して玉砕する人」は個人的な趣味でやってくれる分には、どうでもいいとしても、同じ職場で仕事でやられるのは迷惑以外の何者でもないんですが?
仕事でやってる以上、そこは譲りたくはないなぁ。作らずに済むバグなら作りたくはないし。それをあえて作る奴がいたら、人間関係も歪みそうだし。
Re:やっぱりないっす (スコア:1)
「高信頼性」だけを重視するとは限りません。
それに、顧客の目的の他に開発会社としての目論見もありますし。
・機能性
・信頼性
・開発効率
・話題性
・新規性・・・
ただ、「危ないから新技術はダメ」なら開発会社はやっていけませんし、
そのような会社は見たことがありません。(人なら見たことがあります)
要はバランスの問題でしょうね。
# 経験上、1つのプロジェクトで新規技術は1つのみをルールにしてます
--- (´-`)。oO(平和な日常は私を鈍くする) ---
Re:やっぱりないっす (スコア:0)
私の知っている範囲では
信頼性、性能は当たり前と言う人が多いです。
しかも作っているときは何かといえは納期、納期ばかりで信頼性も性能も考えてないように思えます。
これらの問題は、実際に運用に入ってから問題がでることが多いようにも感じます。
機能性についても、よく「できない」と言う言葉を聞
Re:やっぱりないっす (スコア:1)
ですね。ただ、「どの程度の信頼性・性能にどの程度のコストがかかるか」
を説明すると、「じゃ、この程度でいいス」と妥協してくれる事が多いですね。
曖昧にせず具体的に話すと、顧客が重視している部分が良く見えてきます。
> プロジェクトを始める際にそれほど優秀な人は集まりません
>(あくまで私の主観ですが)からそれにあった仕事の仕方を
> すべきだと思います。
こちらも同感です。
私の場合も、メンバーのスキルを見て採用する方式を提案しています。
技術的課題が全部自分に降りかかってくるのも嫌だし。
--- (´-`)。oO(平和な日常は私を鈍くする) ---
Re:やっぱりないっす (スコア:0)
>ですね。ただ、「どの程度の信頼性・性能にどの程度のコストがかかるか」
>を説明すると、「じゃ、この程度でいいス」と妥協してくれる事が多いですね。
>曖昧にせず具体的に話すと、顧客が重視している部分が良く見えてきます。
そのような場合も多いとは思います。しかし、最近ではお客様システム部門
とではなく業務部門のかたと仕様を決めている事も多くなっている事も多く
なっているように思います(直接私はその様な立場では作業をしていないの
であくまその様に聞こえてくだけですが)。
この様な場合は性能や信頼性の
Re:やっぱりないっす (スコア:0)
レス付いた書き込みした人です。
そうですなぁ、その通りです。私もそう思いますよ。
でも、私はその立場に居ないんですよ(苦笑)別チームだし。
一応
Re:やっぱりないっす (スコア:0)
玉砕しちゃダメでしょう?
何故か熱い思いで これからはUMLだ、オブジェクト指向だ~とかいいはじめた人では。さらに想像するに本人もまだマスターしてなかったりとか。
まずはちゃんと自分の担当分をまっとうしてから言えと、いい
Re:やっぱりないっす (スコア:0)
社会を動かしている製品を作っている会社を、学校の実習と混同してもらっては困る。
そういう新人は言ってもわからないので、一度全部をまかせて
地獄を味わってもらうのが吉。
もちろん裏でこっそりバックアップシステムを作っておく。
Re:やっぱりないっす (スコア:0)
>自分の知己の範囲にしがみ付き変化を恐れる人のほうが厄介だよね。
こういうやつなんだろうな、患者使って未経験の手術法を試して玉砕するやつ。
自分の欲しか頭になくて、他に全然考えが及ばないのな。
Re:やっぱりないっす (スコア:0)
>>自分の知己の範囲にしがみ付き変化を恐れる人のほうが厄介だよね。
>
>こういうやつなんだろうな、患者使って未経験の手術法を試して玉砕するやつ。
>自分の欲しか頭になくて、他に全然考えが及ばないのな。
コワイコワイ(笑)
最新技術もそうですが、手段と目的が逆になっている人もいますよね。
「この手法だと要件満たせないから元にもどさない?」
とか聞くと
「いや、この最新の
Re:やっぱりないっす (スコア:0)
・゚・(つД⊂)・゚・イキロ
Re:やっぱりないっす (スコア:0)
Re:やっぱりないっす (スコア:0)
この業界結構狭いからお隣に居たかも?(苦笑)
でもまぁ~どこも似たようなものじゃないですかねぇ~
最新技術追いかけるのも良いけど、とりあえず要件満たした他人がメンテ出来るコード書けと。自分で制御出来ない技術を現場に持ち込むのは止めて欲しいと思います(切実)
Re:やっぱりないっす (スコア:0)
Re:やっぱりないっす (スコア:0)
Re:やっぱりないっす (スコア:0)
最後の「フゥ」がそれを物語っているが。
何をするにも行間を読めないとね。
#もっとも改行の無い文には行間は無いか。(笑
嫌われ役って (スコア:1)
必要なのかな? 必要なんだろうなぁ。1 つ目のタイプの人たちに、徹底的に嫌われるタイプの、厳し~い上司。
あー、出世はしたくないものだねぇとかいう (-_-)zz...
むらちより/あい/をこめて。
Re:嫌われ役って (スコア:1, 興味深い)
どー考えてもソフトのバグなのに、調査もせずにソフト屋の管理職に「ハード屋がバグを放置している」とか役員にチクられました。結局、最終的にソフトのデバッグも自分でやる羽目に・・・。ソフトのバグの原因を突き止めて、仮の修正をした上で、本修正はソフト屋に任せたのですが、どうやら役員への報告は「ソフトで修正した」とだけ報告したらしい。
結局、役員にチクられたことによって査定が下がってたんでは、やる気も失せます。(ちゃんと役員に反論してくれよ>漏れの上司)
s/役/者/ (スコア:0)
そしたら、そっちの部門長殿は、こっちの部門で不具合を放置したからだって
客先に報告したらしい。おいおい(;´д`)。
幸いにも、客先とはこっちの方が綿密に状況報告していたので、
誤解されることはなかった。
探りを入れると、その部門長殿は、独自の判断でそういうことをやってく