できる人間を担当者にしてはいけない

http://itpro.nikkeibp.co.jp/article/COLUMN/20080626/309556/

　筆者の知り合いであるEさんは，Javaによる販売管理システム開発のPMに任命された。早速，Eさんはチーム組織を編成することにした。幸いにもEさんは，以前の部下であり「優秀なJava プログラマ」として社内で有名なFさんを確保することができた。EさんはFさんの優秀さについて十分承知していたので，最も実装が困難になりそうな契約管理ロジック部分の担当プログラマとしてアサインすることにした。
　開発が始まり実装フェーズにはいるとFさんの優秀さは群を抜いていた。最も複雑なロジックになると見込まれていた契約管理ロジック部分については，Fさんがほぼ1人で担当したにもかかわらず，他のサブシステムに先行して単体テストまで完了したのだった。あまりにも予定よりも早く完了したことを喜んだEさんは，Fさんに対して他の遅れている実装部分についても手伝うよう指示した。特に進捗が遅れ気味の課金ロジック・チームを集中的にバックアップしてもらうつもりだったのだ。
　プロジェクト全体の進捗を管理しているPMとしては当然のことである。しかし，実際はうまく行かなかった。なぜならば，課金ロジック・チームのサブリーダーから強い反発があったためだ。課金ロジック・チームの言い分はこうだ。「全体進捗としては遅延しておらず，かつアサインされている担当プログラマの士気も高い。今の時点で外部から要員を入れてチームを混乱させたくない」。こう言われてしまってはEさんとしても何も言えず，結局Fさんは結合テストまでの数日間，特に何もやることなく過ごすこととなった。
　このプロジェクトがこの後どうなったか？結論から言うと，結合テスト開始予定までに単体テストが完了したチームは，Fさんのチームだけであり，他のチームはすべて遅延してしまったのだ。こうなるとFさんは引っ張りだこになり，あっちのチームでソースを修正すれば，次はこっちのチームでソースの修正と，まさに実装者として大車輪の活躍となってしまった。最終的に完成したシステムソースのほとんどがFさんの手が入ったものとなったのだ。このため，Fさんは1カ月間400時間を超える労働を強いられてしまった。カットオーバーを間近に控えたある日，過労のため入院してしまったのである。

ここでも

『わんこそば方式』
http://psv.moe-nifty.com/blog_1/2008/06/post_b39d.html

　昔，「行き詰ったプロジェクトを立て直す」というテーマで取材したときに，ある大手システム・インテグレータで聞いた話だ。そのインテグレータで，火を噴いたあるプロジェクトをどうリカバリしたかというと，「外注先にものすごく生産性の高いプログラマがひとりいて，そいつをカンヅメにして，わんこそばのように仕様書を次々と渡して一気に作らせた」のだという。それほど優秀なプログラマも，大手インテグレータにスカウトされたりはしなかった。大手の社員になるか下請けになるかは，新卒入社時に決まる身分制度のようなものだからだ。

の被害者の話が・・・。（つД｀）

ITproの『できる人間を担当者にしてはいけない』の記事には、次のような事を書いてありますが・・・。

　筆者は，Fさんのような人材は思いきってリーダー格として抜擢し，プログラム実装をさせないという方法をとることが多い。抜擢した優秀な人材に対しては「それぞれメンバーの実装した内容をチェックし指導する」ということをミッションとして与えている。この意図は，Fさんのもっている専門性をプロジェクト内部で最大限に発揮するためだ。実際に実装できないリーダーが指摘するのとは異なり，メンバーも指摘を素直に受け入れることができる。開発中のウォークスルーも簡単に実施できる。何より各メンバーの実装スキルをプロジェクトを通して大幅に引き上げることができるからである。

これは、『わんこそば方式』で優秀な人材を潰さない方法の一つの手ではあると思いますけど、
プログラマーとしては、コードを書かせてもらえないのはストレスが溜まるという問題もあったり・・・。

むつかしいですな。＞優秀なプログラマーを殺さない方法