読者です 読者をやめる 読者になる 読者になる

書評ブログ

日々の読書の記録と書評

プログラミングの心理学 25周年記念版(ワインバーグ)

1970年代のIT業界で、プログラマー心理的な側面とパフォーマンスの関係に焦点を当て、ひいてはあるべきマネジメントの姿を考察した古典。

それから25年たっての(1998年)著者のコメントが章ごとに丁寧に付されている。今でも通用するところが多いと思う。

以下、心に残った(響いた)箇所の備忘。

【目標の設定・達成】
  • メンバーが、下位の仕事を割り当てられたことに対する感情を抑圧すると、チームの努力が予想外に損なわれることがある。エゴレスプログラミングを行うと、個々のプログラマーがシステム全体の中で自分の役割を受け持っていると感じるため、そのような感情は和らげられやすい。
  •  グループの目標についてほんとうの合意に達するには、グループがみずから目標を設定するのが最良の方法である。
    • まず、目標の設定に参加することで、より明確に目標を理解できる。
    • 次に、グループのメンバーが目標に取り組む姿勢をあきらかにする機会がつくれる。いったんそのような姿勢をあきらかにすると、認知的不協和によって、目標を受け入れやすくなることがわかっている。
    • しかし、これらの要因は別にしても、目標の設定に参加すること自体が、個人がチームの目標を心から受け入れる決定要因となり、ひいては生産性の向上につながる。
  • 上層部を喜ばせるには、言われたことをなんでも引き受けるのが一番だと考えるかもしれない。しかし、最終的に上層部が求めるのは約束が守られることであり、それには、チームに約束を目標として受け入れさせることができなければならない。チームリーダーは、次のことを学ぶ必要がある。
    1. どれほど強く「約束」を要求しようと、上層部がほんとうに求めているのは「結果」である。
    2. チームの全員参加で設定した目標を追求した方が、はるかに容易に結果が得られる。
  • 降りる覚悟のあるリーダーだけが、ほんとうに成功する可能性がある。

 

【民主的グループのビルディング】

  • チームに入れるプログラマーを選ぶときは、移り変わる構造の中でうまく適応できる人物(支配的すぎず、受動的すぎず)を選ぶようにするべきである。
  • プログラマーの訓練にあたっては、有能なリーダーに従う方法と、自分がグループ内で最もリーダーに適任であるときに、リーダーシップの機会をつかむ方法を教えるべきである。
  • そして、チームのライフサイクルの間は、部外者はチームの民主的プロセスに介入しないようにするべきである。
  • チームの人選が終わって稼働し始めると、その上に立つマネージャが賢明であれば、チームの内部構造と構造の変化については「無干渉」の方針をとるはずである。

 

【グループ運営とリーダーシップ】 

  • 民主的なグループでは、リーダーシップ、あるいは影響力は、1人だけがもつものではなく、チームのニーズがその人の能力やアイディアに合えば、メンバーからメンバーへとめぐっていくものである。
  • 機能する民主的なグループの重要な要素は、メンバー全員が等しくリーダーシップを発揮することではなく、リーダーシップが外部からの圧力ではなく内部の現実によって決まることである。

 

【トラブル対処】

  • 「民主的」に組織されたチームは、(中略)メンバーを失ったショックにうまく対処できる場合が多い。
  •  逆に、民主的に組織されたチームにとって、新しいメンバーを受け入れるのは難しい場合がある。チームの構造の中に、新しいメンバーが占めるべき明確な位置がないからだ。逆説的なようだが、民主的に組織されたチームは、部外者にとって一見冷淡でよそよそしく感じられ、権威主義的なチームのメンバーは、新人には温かく親しみやすい場合がある。
  • もう1つ危機が生じやすいのは、メンバーの1人が作業分担をこなせないことに、ほかのメンバーが気づき始めたときである。民主的チームの場合、そのメンバーからほかのメンバーへ徐々に仕事が移っていく可能性が最も高い。中央集権型の強力なリーダーが1人いるチームの場合、問題のメンバーを辞めさせる可能性の方が高い。しかし、それで終わりではない。問題が認識される頃には、交代要員を確保して訓練する時間も十分になく、やめさせても何も解決しない場合がある。
  • 民主的グループの場合、能力はあるが仲間とうまくやっていけないメンバーの方が、まったくの能力不足より深刻な問題になることがある。

プログラミングの心理学【25周年記念版】

にほんブログ村 本ブログ 書評・レビューへ