できる人間を担当者にしてはいけない：ITpro（情報元のブックマーク数）
仕事が速くて出来る人間は現場で働かせるのではなくリーダ格として抜擢すべき
次のような非常に優秀なプログラマが居たとする。
[チーム編成編]できる人間を担当者にしてはいけない | 日経 xTECH（クロステック）
(1)仕事が速い
(2)バグの少ないプログラムを書く
(3)コーディング規約に沿って書く
(4)仕様書を具現化する際に業務を見渡したアルゴリズムを構築できる
チームにこのような優秀なプログラマがいると，どうしても担当者としてプログラムを書かせたくなるのは心情というものだ。しかし，プロジェクト・マネージャ（PM）は，このような優秀なプログラマを，他のプログラマと同様に担当者として扱ってはいけない。できる人間は，チームのリーダー格として抜擢すべきである。
結局出来る人間の速度でプロジェクト予測をして、火の車を見て出来る人がデスマーチへ・・・・って感じになり勝ちらしい
プロジェクト全体の進捗を管理しているPMとしては当然のことである。しかし，実際はうまく行かなかった。なぜならば，課金ロジック・チームのサブリーダーから強い反発があったためだ。課金ロジック・チームの言い分はこうだ。「全体進捗としては遅延しておらず，かつアサインされている担当プログラマの士気も高い。今の時点で外部から要員を入れてチームを混乱させたくない」。こう言われてしまってはEさんとしても何も言えず，結局Fさんは結合テストまでの数日間，特に何もやることなく過ごすこととなった。
[チーム編成編]できる人間を担当者にしてはいけない | 日経 xTECH（クロステック）
このプロジェクトがこの後どうなったか？結論から言うと，結合テスト開始予定までに単体テストが完了したチームは，Fさんのチームだけであり，他のチームはすべて遅延してしまったのだ。こうなるとFさんは引っ張りだこになり，あっちのチームでソースを修正すれば，次はこっちのチームでソースの修正と，まさに実装者として大車輪の活躍となってしまった。最終的に完成したシステムソースのほとんどがFさんの手が入ったものとなったのだ。このため，Fさんは1カ月間400時間を超える労働を強いられてしまった。カットオーバーを間近に控えたある日，過労のため入院してしまったのである。
火の車を迎える前に、リーダとして、色々見て回って火消しをさせるってのが一番ってことか。
できる＝信頼されているってのもあるか。
筆者は，Fさんのような人材は思いきってリーダー格として抜擢し，プログラム実装をさせないという方法をとることが多い。抜擢した優秀な人材に対しては「それぞれメンバーの実装した内容をチェックし指導する」ということをミッションとして与えている。この意図は，Fさんのもっている専門性をプロジェクト内部で最大限に発揮するためだ。実際に実装できないリーダーが指摘するのとは異なり，メンバーも指摘を素直に受け入れることができる。開発中のウォークスルーも簡単に実施できる。何より各メンバーの実装スキルをプロジェクトを通して大幅に引き上げることができるからである。
[チーム編成編]できる人間を担当者にしてはいけない（2ページ目） | 日経 xTECH（クロステック）
