パスワードを忘れた? アカウント作成
42746 submission
アメリカ合衆国

ベテランプログラマを管理するには? 130

タレコミ by pinbou
pinbou 曰く、
本家/.の記事より。悩める新米管理職からのご相談。

私は元々技術畑の出身で、プログラマとして何年か働いていたのですが、最近管理職となってJavaプログラマから成る小さなチームを率いることになりました。私にとってチームの仕事の技術的な側面は大したことはないのですが、今やダークサイドに堕ちたスーツである私にきちんと報告させ、チームのモチベーションを高く保つにはどうしたらいいか、自信が持てず悩んでいます。一応お伝えすると私はまだ30代前半なのですが、チームのメンバのほとんどは私より年上の世代です。口うるさい上司にならずにうまくチームを管理するための、何か良いアドバイスはありませんか?

情報元へのリンク
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 勇気 (スコア:5, 参考になる)

    by Anonymous Coward on 2008年12月14日 10時12分 (#1472972)
    好かれる上司になろうとしないこと、です。

    - 自分の好きな事しかやろうとしない人
    - 気に入らないことをさせると手を抜く人
    - やりたいことはスケジュールを無視してもやり出す人
    - このプロジェクトには向かないとわかっていても新しい技術や言語を使いたがる人

    やりたいようにさせておくとプロジェクトが滅茶滅茶になってしまいます。

    - 嫌な事でも言わないといけない時は言う
    - クォリティが低ければNGを出す

    を徹底しましょう。
    嫌な事を言った時に反感を持たれないようにするには馬鹿馬鹿しいことですが
    上下関係をはっきりさせるための半儀式的な会議などが役に立ちます。
    (自分に能力がないと馬鹿にされるだけですが)
    特に厄介なのは自分の能力を過信した部下がいるときです。
    プロジェクトへの悪影響が避けられないようなら早めにチームから外しましょう。
    遅れると取り返しのつかないことになります。

    その上で、

    - プロジェクト全体の方向性を明確にし、各メンバーがその中でどの位置に立っているかを自覚させる
    - 部下の意見を聞く
    - 優秀な部下にはどんどん権限委譲する

    といったことを考えていきましょう。

    仕事終わりの飲みも役に立ちます。
    大きな会社、組織ならば部下とだけでなく、自分の更に上司との飲みも円滑なプロジェクトの管理に役に立つでしょう。
    予算やリソースの配分、人事などに融通が利くようになります。
    • Re:勇気 (スコア:3, 興味深い)

      by rockwall (33028) on 2008年12月14日 17時50分 (#1473113) 日記
      チームメンバに好かれていない上司に対して、
      クオリティの高い仕事をして貢献しよう って気になれる?
      モチベーションを高く維持できる?
      並のクオリティの仕事しかしないと思うよ。
      (ここでいうクオリティは品質もあるけど、納期に対する時間的なアドバンテージも含む)
      で、ちょっと大きなトラブルがあるとピンチになるってパターン。

      いい上司ってのは、やりたいようにやってる人に対して、
      ・成果を挙げているときは、徹底的に褒める
      ・成果を挙げていないときは、どうしてそれがNGなのかを徹底的に議論して納得させられる
       (もちろん、言い包められる事もあるだろうけど)
      ことができ、モチベーションの維持に努める人。
      少なくともチームメンバからは嫌われてないと思う。

      # チームメンバ以外から見たときは、嫌な管理職(融通が利かない、すぐに出来ると言わない)って方ならば
      # チームメンバから見ていい上司ってのは納得。
      親コメント
    • by NAT33 (17123) on 2008年12月14日 13時34分 (#1473022)
      - 自分の好きな事しかやろうとしない人
      - 気に入らないことをさせると手を抜く人
      - やりたいことはスケジュールを無視してもやり出す人
      - このプロジェクトには向かないとわかっていても新しい技術や言語を使いたがる人

      これって今の常駐先のリーダーさんの特徴に該当するんですが?(苦笑)
      親コメント
    • Re:勇気 (スコア:1, 興味深い)

      by Anonymous Coward on 2008年12月14日 14時15分 (#1473037)

      うわぁ、俺が超げんなりするタイプだな、こいつ。そんなの自己満足以外のなにものでもないんですけど。
      こういうの本人がよかれと思って、それがあるべき姿なんだと思ってやってるとこがさらに質が悪いんだよなぁ。

      あのね? 好き勝手やるタイプのヤツだって自分のチームやボスに対して少なからず忠誠心も持ってれば、プロジェクトが成功してみんながハッピーになって欲しいとぐらいには思ってんだよ?
      それなのにあんたが言うようなことをやるのは、そういった気持ちを吹き飛ばすモノでしかなく、例え短期的には能率があっても中長期的に確実にしっぺ返しをくらいます。

      必要なのは相手を尊重しつつ、しっかり話し合いをすることで、具体的には次のようなやり方があります。

      1. 本人にプロジェクトが成功して欲しいと思っているのかまず確認すること( ここで No と答えるようなヤツならばそれはさすがに即そので場クビを切らなければならない。法律的な問題等で即クビを切れなくても且つどんなに能力があろうとそれ以後は一切仕事をさせてはいけない。 )
      2. その上でプロジェクトが成功する為にそいつがやろうとしていることあるいはやろうとしないことによって、プロジェクトが成功に近づくのか遠ざかるのか本人にどう思うか"本人の判断"を聞いてみること。
      3. で、そこで意見が食い違っててもそいつの考えを極力尊重すること。
      4. そいつの考え通りだとまずいと思われる場合はそのまずいと思っている理由を説明しつつ話し合いをすること(説得に非ず!)。
      5. 話し合いをしても意見が合わない場合は、チームとしての判断に従って欲しいとお願いすること( ここで No と答えてもそれが明らかに本人の我が儘でない場合はペナルティ等を与えないこと )。
      このやり方のミソは最初に本人の口からそのプロジェクトへのコミットメントをとることで、その後の反プロジェクト的な言動を封じることです。他人の言うことに従わないヤツでも自分の言ったことに反する行動をとることはプライドもあるし避けたがるものです。

      仕事終わりの飲みも役に立ちます。
      最後に、これもただの自己満足だから。そんな昭和的価値観からは一日も早く脱却されることをオススメします。
      親コメント
      • Re:勇気 (スコア:1, 興味深い)

        by Anonymous Coward on 2008年12月14日 19時39分 (#1473148)
        あなたは、きっとしっかりされた方だと思います。そのような方ばかりのプロジェクトであれば、緩い管理のほうがうまく行くと思います。
        しかし、あなたのすぐ周りの人6人を束ねたプロジェクトのマネジメントを担当することになったとして、あなたはプロジェクトを成功に導く自信はありますか?


        各プロジェクトメンバの考え方や行動パターンはさまざまです。
        絶対にコミットメントをしないタイプの人がいます。これは、非常に技術者っぽい人にありがちで、多くのリスクがあることが見えるだけに何もコミットできなくなります。
        自分の仕事の範囲を勝手に自分で決めてしまい、本当のプロジェクトの目的を見失う人もいます。
        コミットが守れないときに隠してしまうタイプの人もいます。人間は弱いものです。
        一生懸命やるのですが、自分が信じている作業優先度で作業するため、プロジェクトとしての作業に影響を出す人もいます。本人が後回しにしてよい作業だと思っていても、その作業が完了しないと始められない作業を持っている人にとっては致命傷です。人は自分を中止に局所最適化しがちです。
        つまらない仕事は誰もやりたがりません。なるべく他の人がやって欲しいので、問題を知っていても、そのことを口にしない人がいます。
        プライドを守ることの出来る言い訳さえ見付かれば、後から意見をひっくり返すことは何とも思わない人もいます。
        プロジェクトに問題が発生したとき、自分に最初に与えられた作業に含まれていないことを理由に、逃げる人がいます。プロジェクトが失敗しても、自分が原因でなければ、管理者の責任だと考える技術者は、珍しくありません。


        たったひとりのメンバが問題を起こしても、それに対応できなければ、他の5人分の仕事がうまく行っていたとしても、プロジェクトとしては失敗します。5人のメンバにはうまく行っても、1人のメンバにはうまくいかない方法であれば、それはリスクの非常に高い方法です。

        親コメント
    • Re:勇気 (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2008年12月14日 18時21分 (#1473120)
      >このプロジェクトには向かないとわかっていても新しい技術や言語を使いたがる人

      プロジェクトに向くとか向かないとかまったく考えずに、古い技術や言語を使いたがる人こそ何とかしないと。
      親コメント
    • Re:勇気 (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2008年12月14日 19時07分 (#1473138)
      これは妄想だ。
      職人家質でプロ意識が高いプログラマはかなり少ないし貴重だぞ。

      問題のあるプログラマは、
      - 自分の好きな事しかやろうとしない人
      - 気に入らないことをさせると手を抜く人
      - やりたいことはスケジュールを無視してもやり出す人
      - このプロジェクトには向かないとわかっていても新しい技術や言語を使いたがる人

      そういう考えを起こす以前の問題があるやつだ。

      これでスコア5はよくないな。
      親コメント
  • あきらめろ (スコア:4, 興味深い)

    by Anonymous Coward on 2008年12月14日 9時05分 (#1472956)
    こんなところでアドバイスをもらおうと考えている時点で管理者失格。

    本人たちと話をしろ。
    年上とか、技術系(理系、文系)関係なし。
    • Re:あきらめろ (スコア:5, おもしろおかしい)

      by Anonymous Coward on 2008年12月14日 9時07分 (#1472958)
      そういう頑固な意見を言ってくる年上プログラマーの管理方法について語りましょう。
      親コメント
    • by DesKwa (35996) on 2008年12月14日 9時28分 (#1472961)
      まあ、まずは
      >本人たちと話をしろ。
      で同意。

      メンバが自分のことをどういう風に思ってるか確認、だな。
      年下と言うことで上司としてみてなければかなりハードルが高くなりそうだ。
      もしそうでなければ、自分の思うようにやればいいと思う。
      今まで管理される側の経験を生かして。
      親コメント
  • 必読の書 (スコア:4, 参考になる)

    by ikotom (20155) on 2008年12月14日 10時04分 (#1472971)
    トム・デマルコ著「ピープルウェア」をまず読むべし、とアドバイスしたい。
    個人的には、名著の枠を超えて、必読の書だと思う。
    管理するってどういうことかという基本的な概念、哲学みたいなのを
    教えてくれる。

    その後で、PMBOKとかCMMIとかの教本で具体的な手法を学べばいいんじゃないかな。
    • Re:必読の書 (スコア:3, 参考になる)

      by MitiM (15971) on 2008年12月14日 14時30分 (#1473041)
      最近の本ですけど
      Johanna Rothmanの「Manage It! 」が良かったですね。最近の管理者らしい観点をもった、現実的かつ具体的な内容で。
      ピープル・ウェアと一緒にこれを読むのがいいんじゃないかな?と思うくらい、惚れ込みました。
      親コメント
    • Re:必読の書 (スコア:3, 参考になる)

      by okky (2487) on 2008年12月14日 15時38分 (#1473063) ホームページ 日記
      その前に "The will to lead" by Marvin Bower を読むべし。その方が Peopleware を理解しやすい。
      --
      fjの教祖様
      親コメント
  • >技術的な側面は大したことはない
    のに、ベテランプログラマ多数のチームが構築された経緯が分からないです。

    謙遜して単にベテランという言葉を年齢が高くて水準の低いプログラマを指していって
    いるのだとしたら、容易に自分の技術的優位を示せるはずです。しかし、このような質問
    をするということは、あなたには技術的な自信が満ちているわけではなさそうです。

    もしかすると、大したことはないと思っているのはあなただけかもしれません。
    仮にそうだとすると結果は悲惨なことになります。なぜそのようなチームが構成された
    のかを複数の視点

    • 会社経営からみたときの社内の人材のバランス(単に人材に対して仕事が少ないから贅沢なチーム構成になったのか)
    • 社内の他のチームとの関係、仕事の性質と個々のメンバの社内での扱い(掃き溜めチームなのか、重要チームなのか、唯一の開発チームなのか、チームの人材は流動的なのか否か)
    • 会社からみたあなたの評価と新しい仕事の方向性や関連性(新しい経験をすることが求められているのか、短期の実績が求められているのか、そのバランス)
    • あなたの上司の普段の判断が適切か否か(人材の配置は普段からおかしいのか、今回だけ異常にみえるのか、自分が過去におかしいと思っても結果的にプロジェクトが成功した例はないのか、それともおかしいと思ったときは必ず失敗しているのか)
    • あなたの性質(問題をいつも過小/過大評価する傾向がないか)


    から、考察してみるべきでしょう。
    • by Anonymous Coward on 2008年12月14日 19時19分 (#1473142)
       技術力を買われたのか、管理能力を買われたのかというのも。最初に考えておいた方が良いと思います。どっちかで、リーダーシップを取るのが良いのか、部下に仕事を任せるのが良いのかが変りますから。

       その他に、部下の話を良く聞くことと、叱る時に部下の顔をつぶしてよいのかどうかをまず最初に考えた方が良いでしょうね。
      親コメント
  • by ots556556 (34248) on 2008年12月14日 12時10分 (#1473004)
    管理者に働きかけても期待する結果が得られないと感じると、技術者はふてくされて管理者と対話しようとしなくなったり、
    頭越しに行動しようとしたりし始めるので、必要な情報が得られなくなります。
    もちろん働きかけに応えられない場合もあるでしょうが、なぜ応えられないのか説明し、時には議論すべきです。

    やるべきことは、技術者からの入力を無視しない、作業に必要なものを与える、仕事に報いるといったところだと思います。
  • by Anonymous Coward on 2008年12月14日 13時50分 (#1473029)
    君の仕事は本当にプログラマを管理する事ですか?
    プロジェクトを管理する事じゃないんですか?
    根本的な所から心得違いをしてませんか?
  • http://lifehacking.jp/2008/12/management-rules-of-a-top-scientist/ [lifehacking.jp]

    本家のタレコミ主の状況が良く分からないが、まずは2の、

    自分の力量を越えるプロジェクトのリーダーになってはいけない。
    に該当していないかをチェックすべき。
    --
    I'm out of my mind, but feel free to leave a comment.
    • by Anonymous Coward on 2008年12月14日 11時06分 (#1472987)
      普通は本人の意向とは関係なく所属する組織の人事として配属が決定しますよね。
      自分から進んで志願したなら何も悩むことはないと思います。
      命令で現職に配置されたのであろうから悩んで相談を持ちかけて来ているのではないでしょうか。
      仮に「自分の力量を越えるプロジェクトのリーダーになって」しまったとしてその人事を拒むことが現実的に可能でしょうか。
      辞表を提出させられて終わりではないでしようか。
      その項目は人事を受けるかどうか決断するときにすべきことで、断れば自分から使えない奴だと告白することになり人員削減候補入りするでしょうから、自分の実力がどうであれ人事を断る選択は最初から存在しなかったと思います。

      自分の力量を超えていたとしても、それを悟られないように自己研鑽していくしかないのですよ。
      親コメント
      • by Anonymous Coward on 2008年12月14日 18時26分 (#1473124)
        ごもっとも。だけど、
        • 自らの力量に余るプロジェクトだと言えない雰囲気がある
        • 自らの力量に余るから援軍を求めたいが、人事の協力が得られない
        という組織は潜在的に問題があると思う。そして、
        • 管理者の力量に余るプロジェクトであるなら火を吹く可能性が高い
        という、組織自ら首を絞める結果になる道を選んでいると言えないか?

        組織がタレコミ主の技量を見込んで指名したなら、それは期待に応えなければならないが
        特にこの業界、単なる人材プールで過度な重責が回されてくることもあるわけで、
        その点の真偽を判断せずに自己研鑽と言ってもね。炎上したら誰が責任取る?
        親コメント
  • 自信がない場合
    ・無理に管理しようとしない。
    権限の範囲内で責任を全うしてくれればいいです。
    部下が自分よりベテランだと思うなら、技術的なことは素直に部下に頼りましょう。
    管理職にしかできないこと(納期管理、折衝など)に徹してくれればいいです。

    ・そのために
    自分よりベテランだと思う人に報告などをきちんとして欲しい場合、それをルール化してみてはどうでしょうか。毎週XX曜日のXX時に報告とか。
    定例ミーティングはよくあることですし、報告を定例化したい時の常套手段として便利かと思います。

    ・何をやったら「だめな管理職」になるのか
    典型的なだめ管理職の例として

    目的を説明しない、手段を説明する
    →手段は聞かれて答えればいいですが、目的は聞かれる前に説明すべき。「聞かれて答えればいいこと、聞かれる前に説明すべきこと」がわかってればOK。
    よーするに、相手にエスパー能力を要求しないようにする。

    間違ったやり方を押しつける
    →ベテランのほうが正しい(効率的な)やり方を知ってるはずなので、自分の力量と部下の力量を客観的に判断できればいい。このケースではたぶん問題にはならないと思います。
    ただ、押しつけてる本人は間違ってると思ってないはずなので……

    自分のやり方を強要する
    →前の同様、必要でない限り、基本的に手段は聞かれるまで説明しなければいいだけ。
    別にいじわるするわけではなく、説明してしまうとベテランは「そのやり方よりもっといいやり方を知ってる」と思ってしまうし、説明した自分は、そのやり方でやってくれないと不満を感じがちなので。
    「やり方は説明したじゃないか!」と言いたくなっても、もっと効率的なやり方でやってるかもしれないし、「説明したやり方じゃないといけない」場合でない限りは、違うやり方でやってても怒らないようにする。
    自分よりスキルあると思ったら、基本的にやり方はおまかせしたほうがいいかも。

    結果だけで部下を評価する
    →「結果だけで判断する」のはお客の仕事、「過程で判断する」のは上司の仕事。結果も大事だけど、そのために何が犠牲になったのかを判断しよう(結果失敗した場合でも、どんな反省材料/ノウハウが生まれたのか……とかも評価する)。
  • by foohogehoge (35368) on 2008年12月14日 14時04分 (#1473033) ホームページ
    非常に良いリーダだと思ってます。

    ・技術面から全体を大雑把に把握している
        -あんまり無茶な要求は受けない
        -あくまで「大雑把」だということを自覚しているので細かいところは任せる

    ・スケジュールの障害となるものを(言えば)取り除いてくれる
        -仕様が未定だとか
        -デバッグ機がない(組込みなもので)とか

    個人的には後者の役割をきちんとやってくれる管理者が好きです。
    # 自分の番が回ってくれば気をつけたい
    • by MitiM (15971) on 2008年12月14日 15時13分 (#1473058)
      プラスして
      • チーム内の情報の風通しに気を使う
        • 各メンバが何をやってるか明らかだとか
        • どこに何の文書があるか明確になっているとか
        • メンバのアクションに対して相応しいフィードバックを返してるとか
      も含めて、特定マネジメント下にあるチームリーダの三原則だと思ってます。
      親コメント
  • 解くべき問題と、その期限を明確にする。

    そして、その2つがずるずる動かないように外部と交渉する。
    外部との交渉においてどうしようもなくなる前に、一番腕の立つ人間と一番年長の人間を相談相手に、何か手がないか聞く。

    これだけでもマネージャとしての仕事の60%はできたも同然。「マネージャとして高い評価」を得られるかどうかはともかくとして、部下になめられるほど酷くはならないし、プロジェクトが成功する確率もきわめて高くなる。
    --
    fjの教祖様
  • 嫌われたくないてな想いが強すぎます
    相手は理系なのだから理詰めで正論を淡々としつこく含めつつ
    プロジェクトに必要な要求を相手にしてやればいいだけです

    #んで順調に進むならほめるべき所は褒め、叱るべきところは叱りましょう
    #但し全部理詰めでお願いします
  • by Anonymous Coward on 2008年12月14日 9時18分 (#1472960)
    自分より力量のあるプレイヤーの力を引き出すにはコーチングですね。
  • メンバーが年上との事なので自然とそうなると思いますが
    チームリーダーとしてまずやる事は、とにかく腰を低くする事ですね

    プログラマ>管理者 という図式でないと成果物のクオリティが上がりません
    欧米では当たり前なのですが、日本ではまだまだ管理者=偉いという
    くだらない図式が成り立っているようで、こういう面でも日本はIT後進国だと言えます

    あと細かい事を言い出すとキリがありませんが
    ・プロジェクトのロードマップをハッキリさせた上で、ある程度のスケジュールはまかせること
    ・週1ぐらいで進捗報告のミーティングをすること
    ぐらいでしょうか
    まあ最初は何かしら失敗しますし、メンバーが年上なら尚更ですので
    失敗しても隠さず素直に謝罪して、それをどうやったらリカバーできるかを考えてください
    • by Anonymous Coward on 2008年12月14日 10時30分 (#1472978)

      プログラマ>管理者 という図式でないと成果物のクオリティが上がりません
      欧米では当たり前なのですが、日本ではまだまだ管理者=偉いという
      くだらない図式が成り立っているようで、こういう面でも日本はIT後進国だと言えます

      アメリカで10年以上働いていますが、技術的に下の人が統括するってケースを経験したことはないです。 個別の技術では個々のプログラマの方が突出していることはあっても、その分野全体にわたってバランス良く マスターしている人がleadとかmanagerポジションにつきます。 IT業界といっても広いので、業種が違えば慣習も違うのかもしれませんが…

      ああ、ただ、「偉い」「偉くない」という見方はしませんね。責任分担の違いと考えます。 プロジェクトがこけて責任をとらないといけないのはマネージャなので、最終的な判断はマネージャが絶対の権限を持ちます。 ただし、個々のプログラマが突出している専門分野について、プロジェクトに貢献すべく判断材料を整えてマネージャに伝えるのは それぞれのプログラマの責任と。

      親コメント
      • by Anonymous Coward on 2008年12月14日 11時30分 (#1472995)
        >技術的に下の人が統括するってケースを経験したことはないです。

        この日本って国では、技術的に優れた人間が統括するってケースをめったに経験できないです。

        だいたい技術的に優れた人間は工数管理や予算管理だけに忙殺され、自分では何も書けない管理職に就くことを面倒がりますし、一方で企業は管理職にならない限りキャリアパスを用意していませんし(形だけ整えてる所ならあるけど実態は・・・)、何より技術的に優れた人間は日々の業務が忙しすぎて昇進試験みたいなくだらないものに割く時間がありません。

        一方、管理職の方は肩書きだけはご立派なことが多いので技術職を格下だとナメてますし、管理職でなくとも偽装請負の「発注者様」と化して若いうちからお山の大将になることも多いですし、技術職をブルーワークと断じて「プロの管理職の俺様がやる仕事じゃねーよ」なんて能書きブッコいてたり、かといって技術を学ぶ気も全くない(実際には学習できる脳味噌を持ち合わせていないケースが大半)ので、トンチンカンな命令を出してチームメンバーに陰口を叩かれる対象になったりします。しまいには「黙って俺様の言うことを聞け」とかなんて気合と根性でチームを引っ張って行こうとするので、チームメンバーに心優しき天才でもいない限り悲惨なものです。
        何より解雇要件が厳しすぎてクビ切ることもできず、かといって実務をやらせたら何やらかすか分からないゴミクズを横文字職位で祀り上げてるケースも少なからずあるので人事制度の問題も大きいです。

        元トピに戻りますが、まー、「私にきちんと報告させ」とか寝言を言ってる段階でリーダーとしてどうなの?とは思います。
        小さいチームならシステム全体を詳細レベルで理解することくらい出来るでしょうし(出来ないならそれはあなたの力量を超えた仕事です)、理解さえできていれば普段の何気ないコミュニケーションレベルで進捗状況やメンバーの信頼度を推し量ることも可能です。そういったアクションはリーダーが起こすべきものなので、「報告させ」なんて受動的な姿勢はそこからNGでしょう。あと、「モチベーション」とか、維持させるものではなくてメンバーが前に進みたがる空気を作るのもリーダーの仕事かと思いますが。
        親コメント
        • by Anonymous Coward on 2008年12月15日 5時51分 (#1473349)
          マネージャが技術的に優れた人間であるのは「望ましい要素」ではありますが必須では
          ありませんよ。いくら技術的に優れていても、マネージメントに関する理解がない人間
          がトップに立ったら、いずれそのプロジェクトは「ビジネスとして」失敗し、その次が
          続かなくなります。営利活動なんですから、食いぶち稼げるくらいの状態を維持できな
          ければ、そもそも仕事自体が消滅します。

          1つのチームの構成要素として「ビジネス戦略屋」「マネージメント屋」「アーキテクト」
          「技術者」がいること、その間の連携が円滑かつ有効になされる体制が構築されている
          こと、そして各要素を受け持つ人間がそれぞれの領域で求められる行動・アウトプットを
          きちんと理解できていることが基本(そして最重要)の要素でしょう。
          それらの要素のいくつかをマネージャが兼ね備えていれば各要素間の連携にからむ
          不都合のリスクは減りますのでうまく行くケースも多くなるでしょうが、そうでなければ
          うまく仕事ができないなんてのは、はっきりいって技術者の甘えですよ。チームの一員で
          ある以上、仕事ができない状態に対しては大なり小なり責任はあるんです。

          モチベーションが上がるようにリーダーがなんとかしろ、とか、何気ないコミュニ
          ケーションで俺の仕事を理解できるようになれとかって、単に他人まかせなだけじゃないですか。
          現状が問題だと思うなら、チームの一員なんだから自分も動けばいいんです。何もせずに
          飲み屋でお偉いさんの批評をしてても時間の無駄。
          そういうと聞く耳もってもらえないとかいう人も出てきますが、聞く耳を持ってもらえる
          ような伝え方を心がけてますか?相手も人間で感情があるんですよ?

          人に何かを求めるなら、自分もそれ以上のものを提供する意識は持つべきです。それがなければ
          どの世界であろうとチームの仕事なんてうまく行くはずもありませんよ。
          親コメント
      • by duenmynoth (34577) on 2008年12月14日 21時32分 (#1473195) 日記
        サンノゼあたりではプログラマになれなかった人が管理職に回されるといった事が普通に行われていて、
        優秀なプログラマはマイスター(職人)として尊敬されていましたが、
        いわゆる世間では違ったようですね。失礼しました。

        #自分でも嫌らしい言い方だと思うので意味無いけどAC
        親コメント
  • と、管理する立場にある者が思い込めば、技術者のチームは崩壊する。
    管理職 ー> 管理 ー> チーム、と連想されているようなので、なおさら崩壊し易いでしょう。
    チーム -> 構成員 -> やる気 -> 技術者 -> 技術を身に着けたい -> 一朝一夕にはうまくいかない
    ということで、気長に本人の技術的欲求を満足させるような仕事を提示し続けることをお勧めします。
    できる構成員なら、とっくの昔にこのチームからいなくなっているでしょうけど。

  • 古参の中で一番実力あってカリスマも高い人との信頼関係を得るのが最重要課題なんでしょか。
    • 映画とかアニメの軍隊なら、新任少尉と先任軍曹ってのはよくある組み合わせですが(^^)、企業の場合、その軍曹さんしかいないって状態の方が多いですよ。特に協力会社の立場で現場に入ると、トップが複数いようと一人だろうとあんまり関係なかったりする。

      つーか、協力会社を目下に見るタイプのリーダーさんは付き合う方もある程度の忍耐を要求されるんで疲れます。こちらを軍曹扱いなんか間違ってもしてくれませんし。
      親コメント
  • by fiercewinds (22740) on 2008年12月14日 13時01分 (#1473012) 日記
    マネジメントについては素人なので何とも言えませんが……

    ・プログラマを管理するのではなくて、あくまで仕事の進捗を管理する。
    ・でも逆に、プログラマを「仕事を処理する担当者」ではなくて、個性を持った人間として理解する。

    という上司だと良いなと思います。
    自分でやろうとすると破綻しますが……
  • by s02222 (20350) on 2008年12月14日 13時34分 (#1473021)
    家族を人質に取るとか?
  • by Anonymous Coward on 2008年12月14日 13時36分 (#1473024)
    このあたりが理解できていないプログラマが多いのも事実。
    管理者は管理監督するのが業務であるのでプログラムを書くわけではないし、
    プログラマはプロジェクトのためにより良いコードを書くのが仕事であるから
    本来であれば、管理者とプログラマが衝突することは無いと思うんですがね。
     
    もっとも不幸なシチュエーションは、管理能力の無い優秀なプログラマウが
    管理者になってしまうこと。
    最悪なのは、自称「優秀なプログラマ」だったり自称「優秀な管理者」だったりするのだけれども。
  • 把握と情報展開 (スコア:1, 参考になる)

    by Anonymous Coward on 2008年12月15日 0時57分 (#1473299)
    管理される側にいる事が多いのですが、情報が来ないと動こうにも動けなかったりします。
    顧客から来たメールをメンバー全員に転送するマネージャーと
    顧客から来たメールを一切転送せず、ある日突然「実はこないだからこんな話が来てる」と言いだすマネージャーと
    両方経験しましたが、前者の方がまだやりやすかったですね。

    なるべく情報共有することで、ある程度の準備をしてくれる人もいるかもしれませんし(過度な期待は禁物ですけど)

    あとは誰がどれぐらいできるかを早めに見極めること、
    (作業において)誰が何を気にしているかそれとなく見てまわることじゃないでしょうか。
    できるマネージャーって結構いろんなところを見てると思います。
  • 貴方がどのような経緯で、マネージメントすることに
    なったかは、よくは、判りませんが、開発のプロジェクトの
    マネージメントだけなんて寂しい気がしませんか、、、。
    会社の都合か、どうかは判りませんが、開発をやる人間は、
    やはり、技術で、ぐいぐい引っ張っていかないとついてきません。
    表面上うまくいったと思っても、必ず痛い目にあいますよ。
    簡単に言えば、寝ても覚めても、技術のことを考えているような、
    そんな態度が、プロジェクトを成功に導く、唯一の方法です。
    これが開発一筋30年の結論です。
    貴方が状況で、どうしても、、、と言うのであれば、
    自分も勉強中という態度を前面に出して、今日からでも
    猛勉強ですよ、、、。
    がんばってください、、、。

typodupeerror

海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs

読み込み中...