タスクボリュームの算定と人員計画

プロジェクトのスケジュールを考えるときに、一番難しいのが工数を算定することだ。
つまり、このタスクは何人で実施して、何日で終わる（または何時間で終わる）、ということをカウントすること。

これは自分のタスクであっても難しいのだが、スケジュールをレビューする立場の人間は相当のプロフェッショナルでもない限り、ほとんど「理解していない」に等しい。そもそも人の仕事の内容すら理解していないことが多いため、そのタスク自体の重要性はともかく、ボリュームや難易度、本人のスキルと照らし合わせた工数なんか分かるわけがない。とはいえ、プロジェクトスケジュールおよび進捗（しんちょく）状況というものは「報告して当たり前」のもの。さらに、遅れてなくて当たり前、のものである。シビアな世界だ。コンサルタントやエンジニアの皆さん、毎日ご苦労様。

そこで何が言いたいか、というと、不条理（absurdity）について、である。つまりこういう難しい状況にありながら、リソースの確保、つまり人員の確保はプロジェクトマネージャーやスタッフの希望にかなわないことがほとんどである。希望にかなわない、というのはどういうことか、というと最適な人員がアサインされること、だけでなく、人員そのものが追加されること、が希望に叶わない。既に「スタッフィングは済んでいて」、とか、「予算が」、とかまあそのあたりの言い訳でうまくはぐらかされるのだが、そうなると待っているのはデス・マーチ、もしくはシーシュポスの神話である（ちょっとメタファーとしては難解か）。
それを避けるための秘策が、今いるリソースの最大活用に走るしかなくなるわけである。つまり気力・体力・時の運ならぬチームワークである。

ここで奇跡が起きることはほとんど無いのだが、過去の体験を交えてノンフィクションかフィクションか、どちらでもいいけど、そのうち書いてみよう、と思う。
地獄のプロジェクトのことを「デス・マーチ」というのだが、この手の話は面白くない。（WindowsNTの開発物語「闘うプログラマー」はそれなりに面白かったのだが。）面白い話を書いてみたいもんだ。

いや、それ以上に経験してみたいもんだ。

闘うプログラマー 上巻

闘うプログラマー 下巻

昨日から何度か聴いている最近のiPodヘビーローテーションはこちら。

チャイコフスキー:ヴァイオリン協奏曲