概要
生産性の高いチームを育てる
詳細
書籍
共通の目標を持つこと。
ただ一緒に開発しているだけではチームとはいえない。
現実
現実ではただ一緒に開発しているケースの方が多そうだ。
特に下請け案件などは、よっぽど積極的にチームをなじませるようなキーマンがいないと
各自ばらばらになりがち。
目的、目標などなくただ単に割り振られた作業を消化するだけの開発者も多々いる。
他の章でも触れていたが、各自の利益が異なるため部分最適化が悪影響を及ぼしてしまうのか。
自分がリーダーの場合は案件の目的・目標、開発社としての目的・目標については
テスターも含めて必ず全ての部下に話すようにしているが、作業だけを割り振る管理者も多いですよね。
少数精鋭の自社製品開発や、Web系の企業などは共通の目標を持っていそうだが
どうなのだろうか？自身も経験がないし、知人にもそっち系の企業の人が居ないのでわからない。
過去の経験上明らかに差があるのは元請け1社体制のチームと、
下請けメインのごった煮チームでは結束に大きな差があるということか。
現実
上記のようなチームを作るには、
良いリーダーと良いリーダーの判断を尊重する良い組織が必要だな、と思ったり。
結局、良いリーダーでなければ良いメンバーを選べないし
良いメンバーも良いリーダー以外の元では継続して働かないと思う。
書籍中のチームのアイデンティティ（チーム愛称を付けたり、妙な格好をしたり）などについては
日本の堅い企業だとなかなか許容されない場合が多いと思う。
少なくともそこまでぶっちゃけて許される現場にはいたことがない。
生産物共有意識については、個人個人の技量も出るなと。
出来る人はチーム内の作業を引き受けるのをためらわないが
出来ない人に限って、自分の担当を出来るだけ最小化しようと懸命になる。
書籍
チーム殺しの7原則。
・自己防衛管理：部下を信頼せず過度の干渉を行う。この手法が一番チームに悪影響を与える。
・官僚主義：マニュアル的な管理。想定外の事象への対応力が鈍る。
・作業場所の分散：チーム間の作業だけではなく、私的なつながりを強くしてチームの結束を高める機会を失う
・時間の分散：複数の案件の掛け持ちなど分断されたメンバーとの結束は強くなりにくい。
・品質低減：期日を守るために品質を低下させる。これにより開発者のモチベーションは著しく低下する。
・サバ読納期：現実に見積もりをした上で多少厳しい納期ならよいが、政治的事情などにより決められた納期はチームのモチベーションを下げる。
・チーム解体：一体となったチームを解散させるとせっかく高まったチーム力が無になる。
現実
残念ながらほとんどの項目の経験有り。
チームメンバーは上記による弊害を理解しているため、リーダーや上司に意見をあげてみるが
上の判断や顧客側の指示により却下されてさらに失望感を強めるのが通例。
よりタチが悪いのは、うまくいってないプロジェクトの改善策として上記がより強化され
さらに状況が悪化する、と言うケースが多々見受けられることである。
書籍
優れた管理者はチームに成功の機会を与える。
それは模擬プロジェクトなどの小さなものでもよい。
成功体験がチームの結束を強める。
現実
この内容を読んで新卒でつとめた会社で、入社直後に社内システム作成のために新人のみでシステムを
開発した件を思い出し、技術面でもチーム力向上の件でも利にかなっていると関心した。
逆にプロジェクトごとに必ずチームを解散するような体制の非効率さを強く感じるし、そういった現場は多い。
書籍
チーム健全化の原則
・品質至上主義
・満足感のある打ち上げ
・エリート感覚を醸成する
・チームに異分子を混ぜる
・成功チームを継続する
・戦術ではなく戦略を与える
基本的にはチーム殺しの原則の反対。
現実
上記を数多く守っているチームに所属した際のことを思い返すと
チームはよく機能していた。
