できるヤツから潰されただけの話

cnaos2009-05-07

[チーム編成編]できる人間を担当者にしてはいけない | 日経 xTECH(クロステック)
が検討違いの対策を書いていると思ったので書いてみる。

できる人間を酷使して潰してはいけない

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

このプロジェクトがこの後どうなったか?結論から言うと,結合テスト開始予定までに単体テストが完了したチームは,Fさんのチームだけであり,他のチームはすべて遅延してしまったのだ。

最終的に完成したシステムソースのほとんどがFさんの手が入ったものとなったのだ。このため,Fさんは1カ月間400時間を超える労働を強いられてしまった。カットオーバーを間近に控えたある日,過労のため入院してしまったのである。

1日8時間労働、1ヶ月20日だとして、1ヶ月の基本的な労働時間を160時間としよう。
400時間-160時間でおおざっぱに計算しても240時間は残業しているわけだが、
そのくらいの作業量を結合テスト前のたった数日間で挽回出来たであろうか?

いや、無理だったに違いない。

  • 「他のチームは全て遅延してしまった」、
  • 「最終的に完成したシステムソースのほとんどがFさんの手が入ったものとなったのだ。」

という部分からわかるが、最初からプロジェクトが破綻していたんじゃないのか?
全体的にプロジェクトメンバーのスキルが不足しており、
スキルのある人間に負荷が集中してしまっただけのよくある話。

意図してやったのか、そうでないのかはともかく、
http://www.mars.dti.ne.jp/~hirok/xp/col/031.htmlを地でいっただけの話だ。

「できる人間を担当者にしてはいけない」という話とはまったく関係がない。


また、「Fさんをリーダー格として抜擢し,プログラム実装をさせない」
を実行したところで、全体的にスキルが低いのであれば、作業内容が変わっただけで
結局Fさんにかかる負荷は変わらないのではないか?
(メンバーが成長してくれれば多少は改善されるかもしれないが。)


あえて「やってはいけない」をつけるとすれば、
「できる人間を酷使して潰してはいけない」
をレベル3で。

あるいは「プロジェクトメンバーをスキルの足りない面子で構成してはいけない」
をやっぱりレベル3で。

間違った指標を進捗管理に使ってはいけない

なぜ他のチームが遅延してしまったのか、
なぜ課金ロジック・チームの進捗が進んでいた(ようにみえた)にも関わらず遅延してしまったのか。

それは他のチームが間違った指標を進捗管理に使っていたためだと思われる。

たとえば、ステップ数(wで進捗をはかってたりすると、
どんなに実装がめためたでも一応は進捗しているように見える。
そして、テストの段階になってから遅延が発覚する。

途中で遅延が明らかになっていれば、全体的にプロジェクトメンバーのスキルが足りていない事が明らかになっていたかもしれない。
(しかし、それでもFさんに負荷が集中する事は避けられなかっただろうけど。)

負の生産性を考慮しなければいけない

シナジー効果を目指すのは結構だが、
世の中には-5(ソースコードレポジトリふっとばす)とか-10(本番環境のDBふっとばす)とかいう
負の生産性を持った人がいることを考えていないのではないか?

たとえ5人力の出来る奴でも-5のメンバーがいたら、
5-5=0だ。

PMたるもの、個人レベルの能力を充分見極め、
負の生産性をもったメンバーの影響を最小限にするように要員をアサインをしなければならない