ベテランプログラマを管理するには? 130
タレコミ by pinbou
pinbou 曰く、
情報元へのリンク
本家/.の記事より。悩める新米管理職からのご相談。
私は元々技術畑の出身で、プログラマとして何年か働いていたのですが、最近管理職となってJavaプログラマから成る小さなチームを率いることになりました。私にとってチームの仕事の技術的な側面は大したことはないのですが、今やダークサイドに堕ちたスーツである私にきちんと報告させ、チームのモチベーションを高く保つにはどうしたらいいか、自信が持てず悩んでいます。一応お伝えすると私はまだ30代前半なのですが、チームのメンバのほとんどは私より年上の世代です。口うるさい上司にならずにうまくチームを管理するための、何か良いアドバイスはありませんか?
情報元へのリンク
勇気 (スコア:5, 参考になる)
- 自分の好きな事しかやろうとしない人
- 気に入らないことをさせると手を抜く人
- やりたいことはスケジュールを無視してもやり出す人
- このプロジェクトには向かないとわかっていても新しい技術や言語を使いたがる人
やりたいようにさせておくとプロジェクトが滅茶滅茶になってしまいます。
- 嫌な事でも言わないといけない時は言う
- クォリティが低ければNGを出す
を徹底しましょう。
嫌な事を言った時に反感を持たれないようにするには馬鹿馬鹿しいことですが
上下関係をはっきりさせるための半儀式的な会議などが役に立ちます。
（自分に能力がないと馬鹿にされるだけですが）
特に厄介なのは自分の能力を過信した部下がいるときです。
プロジェクトへの悪影響が避けられないようなら早めにチームから外しましょう。
遅れると取り返しのつかないことになります。
その上で、
- プロジェクト全体の方向性を明確にし、各メンバーがその中でどの位置に立っているかを自覚させる
- 部下の意見を聞く
- 優秀な部下にはどんどん権限委譲する
といったことを考えていきましょう。
仕事終わりの飲みも役に立ちます。
大きな会社、組織ならば部下とだけでなく、自分の更に上司との飲みも円滑なプロジェクトの管理に役に立つでしょう。
予算やリソースの配分、人事などに融通が利くようになります。
Re:勇気 (スコア:3, 興味深い)
クオリティの高い仕事をして貢献しよう って気になれる？
モチベーションを高く維持できる？
並のクオリティの仕事しかしないと思うよ。
(ここでいうクオリティは品質もあるけど、納期に対する時間的なアドバンテージも含む）
で、ちょっと大きなトラブルがあるとピンチになるってパターン。
いい上司ってのは、やりたいようにやってる人に対して、
・成果を挙げているときは、徹底的に褒める
・成果を挙げていないときは、どうしてそれがNGなのかを徹底的に議論して納得させられる
（もちろん、言い包められる事もあるだろうけど）
ことができ、モチベーションの維持に努める人。
少なくともチームメンバからは嫌われてないと思う。
# チームメンバ以外から見たときは、嫌な管理職(融通が利かない、すぐに出来ると言わない）って方ならば
# チームメンバから見ていい上司ってのは納得。
Re:勇気 (スコア:1)
- 気に入らないことをさせると手を抜く人
- やりたいことはスケジュールを無視してもやり出す人
- このプロジェクトには向かないとわかっていても新しい技術や言語を使いたがる人
これって今の常駐先のリーダーさんの特徴に該当するんですが？（苦笑）
Re:勇気 (スコア:1)
- 自分の好きな事しかやろうとしない人
自分の独断でプロジェクトを回そうとする。メンバーの誰から見ても破綻してるのに。
- 気に入らないことをさせると手を抜く人
リーダーらしい業務を放棄して自分個人の作業に専念してます。たまにどこにいるのか分からなくなる方です（苦笑）、気がついたら帰宅されてたことも多し。
- やりたいことはスケジュールを無視してもやり出す人
意図的なのか知らないが、ユーザーへの納品直前まで死蔵していて、いつも直前になったらやるぞ！と言い出す。頼むから、もっと早めに言い出して欲しい。対処できないから。
- このプロジェクトには向かないとわかっていても新しい技術や言語を使いたがる人
何でか知らないが、やたらと外部からライブラリを持ってきて入れようとする。実績がないから使いたくないし、そもそも必要ない。
ま、こんな人なんですよね。ここ数年で類似の方はよく見かけますけどね。
Re:勇気 (スコア:1)
ひとつだけ引っかかったんですけど、実績がないからっていうのはあなたの会社で実績がないから？
それともそのライブラリの使用経験があるメンバがいないから？
いや、ここ１～２年で遭遇したプロジェクトで
- 会社で実績がないけど「実績をつくりたくて」FWを導入、当然火を噴く。
- 「チームメンバー数人に経験があり、それにより3倍以上開発効率が違うライブラリ」を導入しようと交渉したが「会社で実績がないから」と拒否、当然火を噴く。
この２パターンをそれぞれ経験したもんで。Re:勇気 (スコア:1)
業務アプリなんで、技術的な新しさよりも安定性を重視してるわけです。どうしても、そのライブラリが必要なら動作検証も含めて工数を考えますが、そこまでやるケースは少ないのです。
Re:勇気 (スコア:1, 興味深い)
うわぁ、俺が超げんなりするタイプだな、こいつ。そんなの自己満足以外のなにものでもないんですけど。
こういうの本人がよかれと思って、それがあるべき姿なんだと思ってやってるとこがさらに質が悪いんだよなぁ。
あのね？ 好き勝手やるタイプのヤツだって自分のチームやボスに対して少なからず忠誠心も持ってれば、プロジェクトが成功してみんながハッピーになって欲しいとぐらいには思ってんだよ？
それなのにあんたが言うようなことをやるのは、そういった気持ちを吹き飛ばすモノでしかなく、例え短期的には能率があっても中長期的に確実にしっぺ返しをくらいます。
必要なのは相手を尊重しつつ、しっかり話し合いをすることで、具体的には次のようなやり方があります。
- 本人にプロジェクトが成功して欲しいと思っているのかまず確認すること( ここで No と答えるようなヤツならばそれはさすがに即そので場クビを切らなければならない。法律的な問題等で即クビを切れなくても且つどんなに能力があろうとそれ以後は一切仕事をさせてはいけない。 )
- その上でプロジェクトが成功する為にそいつがやろうとしていることあるいはやろうとしないことによって、プロジェクトが成功に近づくのか遠ざかるのか本人にどう思うか"本人の判断"を聞いてみること。
- で、そこで意見が食い違っててもそいつの考えを極力尊重すること。
- そいつの考え通りだとまずいと思われる場合はそのまずいと思っている理由を説明しつつ話し合いをすること(説得に非ず！)。
- 話し合いをしても意見が合わない場合は、チームとしての判断に従って欲しいとお願いすること( ここで No と答えてもそれが明らかに本人の我が儘でない場合はペナルティ等を与えないこと )。
このやり方のミソは最初に本人の口からそのプロジェクトへのコミットメントをとることで、その後の反プロジェクト的な言動を封じることです。他人の言うことに従わないヤツでも自分の言ったことに反する行動をとることはプライドもあるし避けたがるものです。 最後に、これもただの自己満足だから。そんな昭和的価値観からは一日も早く脱却されることをオススメします。Re:勇気 (スコア:1, 興味深い)
しかし、あなたのすぐ周りの人6人を束ねたプロジェクトのマネジメントを担当することになったとして、あなたはプロジェクトを成功に導く自信はありますか？
各プロジェクトメンバの考え方や行動パターンはさまざまです。
絶対にコミットメントをしないタイプの人がいます。これは、非常に技術者っぽい人にありがちで、多くのリスクがあることが見えるだけに何もコミットできなくなります。
自分の仕事の範囲を勝手に自分で決めてしまい、本当のプロジェクトの目的を見失う人もいます。
コミットが守れないときに隠してしまうタイプの人もいます。人間は弱いものです。
一生懸命やるのですが、自分が信じている作業優先度で作業するため、プロジェクトとしての作業に影響を出す人もいます。本人が後回しにしてよい作業だと思っていても、その作業が完了しないと始められない作業を持っている人にとっては致命傷です。人は自分を中止に局所最適化しがちです。
つまらない仕事は誰もやりたがりません。なるべく他の人がやって欲しいので、問題を知っていても、そのことを口にしない人がいます。
プライドを守ることの出来る言い訳さえ見付かれば、後から意見をひっくり返すことは何とも思わない人もいます。
プロジェクトに問題が発生したとき、自分に最初に与えられた作業に含まれていないことを理由に、逃げる人がいます。プロジェクトが失敗しても、自分が原因でなければ、管理者の責任だと考える技術者は、珍しくありません。
たったひとりのメンバが問題を起こしても、それに対応できなければ、他の5人分の仕事がうまく行っていたとしても、プロジェクトとしては失敗します。5人のメンバにはうまく行っても、1人のメンバにはうまくいかない方法であれば、それはリスクの非常に高い方法です。
Re:勇気 (スコア:1)
で、ちゃんとした仕事が出来るメンバーが残るといいね（＾＾）
新人以外、残らなかった例を知っている自分には納得できないんだよなぁ。。。。
Re:勇気 (スコア:1, すばらしい洞察)
プロジェクトに向くとか向かないとかまったく考えずに、古い技術や言語を使いたがる人こそ何とかしないと。
Re:勇気 (スコア:1, すばらしい洞察)
職人家質でプロ意識が高いプログラマはかなり少ないし貴重だぞ。
問題のあるプログラマは、
- 自分の好きな事しかやろうとしない人
- 気に入らないことをさせると手を抜く人
- やりたいことはスケジュールを無視してもやり出す人
- このプロジェクトには向かないとわかっていても新しい技術や言語を使いたがる人
そういう考えを起こす以前の問題があるやつだ。
これでスコア5はよくないな。
Re:こういうやり方もあるとは思うけど (スコア:1)
いわゆる、恐怖政治的に管理しようとされる方の典型例じゃないかと？
昔の上司にそのまま当てはまるので笑いましたが、意外に多いんですよね、そういう人。
あきらめろ (スコア:4, 興味深い)
本人たちと話をしろ。
年上とか、技術系（理系、文系）関係なし。
Re:あきらめろ (スコア:5, おもしろおかしい)
Re:あきらめろ (スコア:1)
>本人たちと話をしろ。
で同意。
メンバが自分のことをどういう風に思ってるか確認、だな。
年下と言うことで上司としてみてなければかなりハードルが高くなりそうだ。
もしそうでなければ、自分の思うようにやればいいと思う。
今まで管理される側の経験を生かして。
Re:あきらめろ (スコア:1)
なら、協力体制は、必至だと思う。
ポイント、ポイントで、ご意見伺いをした方が良い。
ヘンなこと言うかもしれないが、巻き込んで行くのが良い。
それをまとめるのも、上司の仕事。
まぁ、まずは、3倍働いて、体を示すことだね。
Re:あきらめろ (スコア:1, 興味深い)
年下の上司が３倍の成果をあげてしまったら、年上の部下は完全に萎縮してあきらめちゃいますから。
場合によっては、妬みからくる誹謗中傷となって手がつけられないよ。
傍目にはっきりと解る成果の差(3〜5割くらい?)をみせつつ、部下が明らかに勝る部分を持たせる。
あえて、自分自身の弱点となる部分を残すと言うのが能力の高い管理者としては必要だと思うよ。
もちろん、完全に人事権を持っている管理者であれば、パフォーマンスに劣る部下を切っていくのも手だけどね。
Re:あきらめろ (スコア:2, 興味深い)
なんでこう、同じ土俵に立って優劣でものごとを進めようとする人間が多いんだろう？
開発者には開発者の、管理者には管理者の仕事がある。その仕事をきちんとこなして、メンバーを信頼すればメンバーはちゃんと応えてくれるもんだよ。人格破綻してる人物は別にして。
逆に「俺は開発者としてもすげえんだぜ、お前らついて来い」式にひけらかされると周りはしらけてくる。そのうえで管理者としてなっちゃいなかったらみんな離れていく。
お勧めは、良いアーキテクトとタッグを組んでチームを引っ張ること。そうすれば技術面でも管理面でも不安要素が激減する。あとはやり方次第。
必読の書 (スコア:4, 参考になる)
個人的には、名著の枠を超えて、必読の書だと思う。
管理するってどういうことかという基本的な概念、哲学みたいなのを
教えてくれる。
その後で、PMBOKとかCMMIとかの教本で具体的な手法を学べばいいんじゃないかな。
Re:必読の書 (スコア:3, 参考になる)
Johanna Rothmanの「Manage It! 」が良かったですね。最近の管理者らしい観点をもった、現実的かつ具体的な内容で。
ピープル・ウェアと一緒にこれを読むのがいいんじゃないかな？と思うくらい、惚れ込みました。
Re:必読の書 (スコア:3, 参考になる)
fjの教祖様
技術的な側面は大したことはないと思ってしまう上司 (スコア:3, 興味深い)
のに、ベテランプログラマ多数のチームが構築された経緯が分からないです。
謙遜して単にベテランという言葉を年齢が高くて水準の低いプログラマを指していって
いるのだとしたら、容易に自分の技術的優位を示せるはずです。しかし、このような質問
をするということは、あなたには技術的な自信が満ちているわけではなさそうです。
もしかすると、大したことはないと思っているのはあなただけかもしれません。
仮にそうだとすると結果は悲惨なことになります。なぜそのようなチームが構成された
のかを複数の視点
から、考察してみるべきでしょう。
Re:技術的な側面は大したことはないと思ってしまう上司 (スコア:1, 参考になる)
その他に、部下の話を良く聞くことと、叱る時に部下の顔をつぶしてよいのかどうかをまず最初に考えた方が良いでしょうね。
フィードバックを返す (スコア:3, 興味深い)
頭越しに行動しようとしたりし始めるので、必要な情報が得られなくなります。
もちろん働きかけに応えられない場合もあるでしょうが、なぜ応えられないのか説明し、時には議論すべきです。
やるべきことは、技術者からの入力を無視しない、作業に必要なものを与える、仕事に報いるといったところだと思います。
自分の仕事が何なのかをまず考えよう (スコア:3, すばらしい洞察)
プロジェクトを管理する事じゃないんですか？
根本的な所から心得違いをしてませんか？
Re:自分の仕事が何なのかをまず考えよう (スコア:1)
なのに、質問者はいきなり人の管理で悩んでいる。
これは、そもそもの目的を取り違えている可能性があるということでしょう。
もちろん、Project成功の壁が人の管理だけであると質問者が判断していて、いきなりこの質問になったのなら話は別ですが。
一流の研究者のマネージメント、21の鉄則 (スコア:2, 興味深い)
本家のタレコミ主の状況が良く分からないが、まずは2の、 に該当していないかをチェックすべき。
I'm out of my mind, but feel free to leave a comment.
Re:一流の研究者のマネージメント、21の鉄則 (スコア:2, すばらしい洞察)
自分から進んで志願したなら何も悩むことはないと思います。
命令で現職に配置されたのであろうから悩んで相談を持ちかけて来ているのではないでしょうか。
仮に「自分の力量を越えるプロジェクトのリーダーになって」しまったとしてその人事を拒むことが現実的に可能でしょうか。
辞表を提出させられて終わりではないでしようか。
その項目は人事を受けるかどうか決断するときにすべきことで、断れば自分から使えない奴だと告白することになり人員削減候補入りするでしょうから、自分の実力がどうであれ人事を断る選択は最初から存在しなかったと思います。
自分の力量を超えていたとしても、それを悟られないように自己研鑽していくしかないのですよ。
Re:一流の研究者のマネージメント、21の鉄則 (スコア:3, すばらしい洞察)
- 自らの力量に余るプロジェクトだと言えない雰囲気がある
- 自らの力量に余るから援軍を求めたいが、人事の協力が得られない
という組織は潜在的に問題があると思う。そして、- 管理者の力量に余るプロジェクトであるなら火を吹く可能性が高い
という、組織自ら首を絞める結果になる道を選んでいると言えないか？組織がタレコミ主の技量を見込んで指名したなら、それは期待に応えなければならないが
特にこの業界、単なる人材プールで過度な重責が回されてくることもあるわけで、
その点の真偽を判断せずに自己研鑽と言ってもね。炎上したら誰が責任取る？
ダメ管理職の例……にあてはまらないようにする (スコア:2, 参考になる)
・無理に管理しようとしない。
権限の範囲内で責任を全うしてくれればいいです。
部下が自分よりベテランだと思うなら、技術的なことは素直に部下に頼りましょう。
管理職にしかできないこと（納期管理、折衝など）に徹してくれればいいです。
・そのために
自分よりベテランだと思う人に報告などをきちんとして欲しい場合、それをルール化してみてはどうでしょうか。毎週XX曜日のXX時に報告とか。
定例ミーティングはよくあることですし、報告を定例化したい時の常套手段として便利かと思います。
・何をやったら「だめな管理職」になるのか
典型的なだめ管理職の例として
目的を説明しない、手段を説明する
→手段は聞かれて答えればいいですが、目的は聞かれる前に説明すべき。「聞かれて答えればいいこと、聞かれる前に説明すべきこと」がわかってればOK。
よーするに、相手にエスパー能力を要求しないようにする。
間違ったやり方を押しつける
→ベテランのほうが正しい（効率的な）やり方を知ってるはずなので、自分の力量と部下の力量を客観的に判断できればいい。このケースではたぶん問題にはならないと思います。
ただ、押しつけてる本人は間違ってると思ってないはずなので……
自分のやり方を強要する
→前の同様、必要でない限り、基本的に手段は聞かれるまで説明しなければいいだけ。
別にいじわるするわけではなく、説明してしまうとベテランは「そのやり方よりもっといいやり方を知ってる」と思ってしまうし、説明した自分は、そのやり方でやってくれないと不満を感じがちなので。
「やり方は説明したじゃないか！」と言いたくなっても、もっと効率的なやり方でやってるかもしれないし、「説明したやり方じゃないといけない」場合でない限りは、違うやり方でやってても怒らないようにする。
自分よりスキルあると思ったら、基本的にやり方はおまかせしたほうがいいかも。
結果だけで部下を評価する
→「結果だけで判断する」のはお客の仕事、「過程で判断する」のは上司の仕事。結果も大事だけど、そのために何が犠牲になったのかを判断しよう（結果失敗した場合でも、どんな反省材料/ノウハウが生まれたのか……とかも評価する）。
現プロジェクトのリーダは (スコア:2, 参考になる)
・技術面から全体を大雑把に把握している
-あんまり無茶な要求は受けない
-あくまで「大雑把」だということを自覚しているので細かいところは任せる
・スケジュールの障害となるものを(言えば)取り除いてくれる
-仕様が未定だとか
-デバッグ機がない(組込みなもので)とか
個人的には後者の役割をきちんとやってくれる管理者が好きです。
# 自分の番が回ってくれば気をつけたい
Re:現プロジェクトのリーダは (スコア:3, 参考になる)
- チーム内の情報の風通しに気を使う
- 各メンバが何をやってるか明らかだとか
- どこに何の文書があるか明確になっているとか
- メンバのアクションに対して相応しいフィードバックを返してるとか
も含めて、特定マネジメント下にあるチームリーダの三原則だと思ってます。特に最初なんだし、あまりいろいろできると考えない (スコア:2, 参考になる)
そして、その2つがずるずる動かないように外部と交渉する。
外部との交渉においてどうしようもなくなる前に、一番腕の立つ人間と一番年長の人間を相談相手に、何か手がないか聞く。
これだけでもマネージャとしての仕事の60%はできたも同然。「マネージャとして高い評価」を得られるかどうかはともかくとして、部下になめられるほど酷くはならないし、プロジェクトが成功する確率もきわめて高くなる。
fjの教祖様
口うるさくない上司なんてただの無能でしょう (スコア:2, 参考になる)
相手は理系なのだから理詰めで正論を淡々としつこく含めつつ
プロジェクトに必要な要求を相手にしてやればいいだけです
＃んで順調に進むならほめるべき所は褒め、叱るべきところは叱りましょう
＃但し全部理詰めでお願いします
コーチングを駆使せよ (スコア:1, 興味深い)
とにかく腰を低く (スコア:1)
チームリーダーとしてまずやる事は、とにかく腰を低くする事ですね
プログラマ＞管理者 という図式でないと成果物のクオリティが上がりません
欧米では当たり前なのですが、日本ではまだまだ管理者＝偉いという
くだらない図式が成り立っているようで、こういう面でも日本はIT後進国だと言えます
あと細かい事を言い出すとキリがありませんが
・プロジェクトのロードマップをハッキリさせた上で、ある程度のスケジュールはまかせること
・週１ぐらいで進捗報告のミーティングをすること
ぐらいでしょうか
まあ最初は何かしら失敗しますし、メンバーが年上なら尚更ですので
失敗しても隠さず素直に謝罪して、それをどうやったらリカバーできるかを考えてください
Re:とにかく腰を低く (スコア:3, 参考になる)
アメリカで10年以上働いていますが、技術的に下の人が統括するってケースを経験したことはないです。 個別の技術では個々のプログラマの方が突出していることはあっても、その分野全体にわたってバランス良く マスターしている人がleadとかmanagerポジションにつきます。 IT業界といっても広いので、業種が違えば慣習も違うのかもしれませんが…
ああ、ただ、「偉い」「偉くない」という見方はしませんね。責任分担の違いと考えます。 プロジェクトがこけて責任をとらないといけないのはマネージャなので、最終的な判断はマネージャが絶対の権限を持ちます。 ただし、個々のプログラマが突出している専門分野について、プロジェクトに貢献すべく判断材料を整えてマネージャに伝えるのは それぞれのプログラマの責任と。
日本の大手企業で10年くらいやってますが (スコア:5, 興味深い)
この日本って国では、技術的に優れた人間が統括するってケースをめったに経験できないです。
だいたい技術的に優れた人間は工数管理や予算管理だけに忙殺され、自分では何も書けない管理職に就くことを面倒がりますし、一方で企業は管理職にならない限りキャリアパスを用意していませんし（形だけ整えてる所ならあるけど実態は・・・）、何より技術的に優れた人間は日々の業務が忙しすぎて昇進試験みたいなくだらないものに割く時間がありません。
一方、管理職の方は肩書きだけはご立派なことが多いので技術職を格下だとナメてますし、管理職でなくとも偽装請負の「発注者様」と化して若いうちからお山の大将になることも多いですし、技術職をブルーワークと断じて「プロの管理職の俺様がやる仕事じゃねーよ」なんて能書きブッコいてたり、かといって技術を学ぶ気も全くない（実際には学習できる脳味噌を持ち合わせていないケースが大半）ので、トンチンカンな命令を出してチームメンバーに陰口を叩かれる対象になったりします。しまいには「黙って俺様の言うことを聞け」とかなんて気合と根性でチームを引っ張って行こうとするので、チームメンバーに心優しき天才でもいない限り悲惨なものです。
何より解雇要件が厳しすぎてクビ切ることもできず、かといって実務をやらせたら何やらかすか分からないゴミクズを横文字職位で祀り上げてるケースも少なからずあるので人事制度の問題も大きいです。
元トピに戻りますが、まー、「私にきちんと報告させ」とか寝言を言ってる段階でリーダーとしてどうなの？とは思います。
小さいチームならシステム全体を詳細レベルで理解することくらい出来るでしょうし（出来ないならそれはあなたの力量を超えた仕事です）、理解さえできていれば普段の何気ないコミュニケーションレベルで進捗状況やメンバーの信頼度を推し量ることも可能です。そういったアクションはリーダーが起こすべきものなので、「報告させ」なんて受動的な姿勢はそこからNGでしょう。あと、「モチベーション」とか、維持させるものではなくてメンバーが前に進みたがる空気を作るのもリーダーの仕事かと思いますが。
外資でも日本企業でも働いてきましたが (スコア:3, 興味深い)
ありませんよ。いくら技術的に優れていても、マネージメントに関する理解がない人間
がトップに立ったら、いずれそのプロジェクトは「ビジネスとして」失敗し、その次が
続かなくなります。営利活動なんですから、食いぶち稼げるくらいの状態を維持できな
ければ、そもそも仕事自体が消滅します。
１つのチームの構成要素として「ビジネス戦略屋」「マネージメント屋」「アーキテクト」
「技術者」がいること、その間の連携が円滑かつ有効になされる体制が構築されている
こと、そして各要素を受け持つ人間がそれぞれの領域で求められる行動・アウトプットを
きちんと理解できていることが基本（そして最重要）の要素でしょう。
それらの要素のいくつかをマネージャが兼ね備えていれば各要素間の連携にからむ
不都合のリスクは減りますのでうまく行くケースも多くなるでしょうが、そうでなければ
うまく仕事ができないなんてのは、はっきりいって技術者の甘えですよ。チームの一員で
ある以上、仕事ができない状態に対しては大なり小なり責任はあるんです。
モチベーションが上がるようにリーダーがなんとかしろ、とか、何気ないコミュニ
ケーションで俺の仕事を理解できるようになれとかって、単に他人まかせなだけじゃないですか。
現状が問題だと思うなら、チームの一員なんだから自分も動けばいいんです。何もせずに
飲み屋でお偉いさんの批評をしてても時間の無駄。
そういうと聞く耳もってもらえないとかいう人も出てきますが、聞く耳を持ってもらえる
ような伝え方を心がけてますか？相手も人間で感情があるんですよ？
人に何かを求めるなら、自分もそれ以上のものを提供する意識は持つべきです。それがなければ
どの世界であろうとチームの仕事なんてうまく行くはずもありませんよ。
Re:とにかく腰を低く (スコア:2, 興味深い)
優秀なプログラマはマイスター（職人）として尊敬されていましたが、
いわゆる世間では違ったようですね。失礼しました。
＃自分でも嫌らしい言い方だと思うので意味無いけどAC
技術的な側面は大したことはない (スコア:1)
管理職 ー＞ 管理 ー＞ チーム、と連想されているようなので、なおさら崩壊し易いでしょう。
チーム －＞ 構成員 －＞ やる気 －＞ 技術者 －＞ 技術を身に着けたい －＞ 一朝一夕にはうまくいかない
ということで、気長に本人の技術的欲求を満足させるような仕事を提示し続けることをお勧めします。
できる構成員なら、とっくの昔にこのチームからいなくなっているでしょうけど。
新品少尉とベテラン軍曹みたいだな (スコア:1)
Re:新品少尉とベテラン軍曹みたいだな (スコア:1)
つーか、協力会社を目下に見るタイプのリーダーさんは付き合う方もある程度の忍耐を要求されるんで疲れます。こちらを軍曹扱いなんか間違ってもしてくれませんし。
ピープルウェア (スコア:1)
・プログラマを管理するのではなくて、あくまで仕事の進捗を管理する。
・でも逆に、プログラマを「仕事を処理する担当者」ではなくて、個性を持った人間として理解する。
という上司だと良いなと思います。
自分でやろうとすると破綻しますが……
一般論で (スコア:1)
優秀なプログラマが、優秀なリーダーとは限らない (スコア:1, すばらしい洞察)
管理者は管理監督するのが業務であるのでプログラムを書くわけではないし、
プログラマはプロジェクトのためにより良いコードを書くのが仕事であるから
本来であれば、管理者とプログラマが衝突することは無いと思うんですがね。
もっとも不幸なシチュエーションは、管理能力の無い優秀なプログラマウが
管理者になってしまうこと。
最悪なのは、自称「優秀なプログラマ」だったり自称「優秀な管理者」だったりするのだけれども。
把握と情報展開 (スコア:1, 参考になる)
顧客から来たメールをメンバー全員に転送するマネージャーと
顧客から来たメールを一切転送せず、ある日突然「実はこないだからこんな話が来てる」と言いだすマネージャーと
両方経験しましたが、前者の方がまだやりやすかったですね。
なるべく情報共有することで、ある程度の準備をしてくれる人もいるかもしれませんし（過度な期待は禁物ですけど）
あとは誰がどれぐらいできるかを早めに見極めること、
（作業において）誰が何を気にしているかそれとなく見てまわることじゃないでしょうか。
できるマネージャーって結構いろんなところを見てると思います。
「技術的な側面は大したことはない」なんて、痛い目にあいますよ、、。 (スコア:1)
なったかは、よくは、判りませんが、開発のプロジェクトの
マネージメントだけなんて寂しい気がしませんか、、、。
会社の都合か、どうかは判りませんが、開発をやる人間は、
やはり、技術で、ぐいぐい引っ張っていかないとついてきません。
表面上うまくいったと思っても、必ず痛い目にあいますよ。
簡単に言えば、寝ても覚めても、技術のことを考えているような、
そんな態度が、プロジェクトを成功に導く、唯一の方法です。
これが開発一筋３０年の結論です。
貴方が状況で、どうしても、、、と言うのであれば、
自分も勉強中という態度を前面に出して、今日からでも
猛勉強ですよ、、、。
がんばってください、、、。
Re:無いですね (スコア:1)
でも、無意味に「うるさい」人も少なくないのよね。
Re:年上相手かつ日本でなら (スコア:1)
>客先に示すドキュメントをそこそこ説得力ある形で作成したり、
私の場合、協力会社の立場なので基本的に管理される側なのですが、両方ともリーダーがやっているのを見たことありません（苦笑）
両方とも私自身がやって結果をリーダーに報告しています（＾＾；
と言うか、納期を現実的なラインへ持っていけるリーダーって、かなり珍しいと思う。