組織を編成する場合に，個人の資質によって役割を与えることは非常に大切である。同じ人間であっても，使い方によっては実力の10％も発揮できずに終わることも多々あるからである。例えば次のような非常に優秀なプログラマが居たとする。

(1)仕事が速い
(2)バグの少ないプログラムを書く
(3)コーディング規約に沿って書く
(4)仕様書を具現化する際に業務を見渡したアルゴリズムを構築できる

　チームにこのような優秀なプログラマがいると，どうしても担当者としてプログラムを書かせたくなるのは心情というものだ。しかし，プロジェクト・マネージャ（PM）は，このような優秀なプログラマを，他のプログラマと同様に担当者として扱ってはいけない。できる人間は，チームのリーダー格として抜擢すべきである。

できる人間の使い方をミスしたEさん

　筆者の知り合いであるEさんは，Javaによる販売管理システム開発のPMに任命された。早速，Eさんはチーム組織を編成することにした。幸いにもEさんは，以前の部下であり「優秀なJavaプログラマ」として社内で有名なFさんを確保することができた。EさんはFさんの優秀さについて十分承知していたので，最も実装が困難になりそうな契約管理ロジック部分の担当プログラマとしてアサインすることにした。

　開発が始まり実装フェーズにはいるとFさんの優秀さは群を抜いていた。最も複雑なロジックになると見込まれていた契約管理ロジック部分については，Fさんがほぼ1人で担当したにもかかわらず，他のサブシステムに先行して単体テストまで完了したのだった。あまりにも予定よりも早く完了したことを喜んだEさんは，Fさんに対して他の遅れている実装部分についても手伝うよう指示した。特に進捗が遅れ気味の課金ロジック・チームを集中的にバックアップしてもらうつもりだったのだ。

　プロジェクト全体の進捗を管理しているPMとしては当然のことである。しかし，実際はうまく行かなかった。なぜならば，課金ロジック・チームのサブリーダーから強い反発があったためだ。課金ロジック・チームの言い分はこうだ。「全体進捗としては遅延しておらず，かつアサインされている担当プログラマの士気も高い。今の時点で外部から要員を入れてチームを混乱させたくない」。こう言われてしまってはEさんとしても何も言えず，結局Fさんは結合テストまでの数日間，特に何もやることなく過ごすこととなった。

　このプロジェクトがこの後どうなったか？結論から言うと，結合テスト開始予定までに単体テストが完了したチームは，Fさんのチームだけであり，他のチームはすべて遅延してしまったのだ。こうなるとFさんは引っ張りだこになり，あっちのチームでソースを修正すれば，次はこっちのチームでソースの修正と，まさに実装者として大車輪の活躍となってしまった。最終的に完成したシステムソースのほとんどがFさんの手が入ったものとなったのだ。このため，Fさんは1カ月間400時間を超える労働を強いられてしまった。カットオーバーを間近に控えたある日，過労のため入院してしまったのである。

問題は二つある

　問題は次の2点に要約される。一つは，EさんがFさんを一担当者として割り当てたこと。もう一つは，プロジェクトの遅れを取り戻すためのFさんの使い方である。

　チーム編成を行う場合，Fさんのような人材を一担当者として使ってはいけない。優秀な人材に，自分の担当する個所以外の個所を手伝わせたいと考えても，課金ロジック・チームのサブリーダーが指摘したように，プロジェクトの士気や，手伝われるプログラマのプライドといった極めて人間的な理由により，PMが考えるほどうまく行かないことが多いからだ。「プロジェクトは組織で動いているのだから目標達成のための手段は選ばない」と言うことは簡単だが，人間という感情を持った動物は，なかなかそうは動けないものである。

　では，プロジェクトが佳境に入ったときなら優秀な人材に縦横無尽の活躍を期待してよいかというと，これもダメである。理由はFさんの例のようにその人材自体が倒れてしまうリスクがあることと，他の担当者のモチベーションへの影響である。では，どうすればよかったのだろうか。