納期はなぜ初めから決まっているのか

俺の参画するプロジェクトは必ず納期が決まっている。
社内プロジェクトでも受託開発でも必ずだ。
もちろん、それが"プロジェクト"というものだというのはわかってる。
PMBOKにそう定義されているのである。プロジェクトは有期だ、と。
じゃあその納期はどうやって決まってるかというと、いいかげんに決めてるとか、決算までだとか、プレスリリースまでとか、いろいろだ。


納期を決めることが悪なのではなく「納期までにすべての要件を実装する」という"約束事"が悪である。
システム要件(スコープ)がなにも決まってない状態で、予算(リソース)とそこから逆算して納期が決定するのである。
まず、終わるわけがない。
金額が大きければ大きいほど納期は長くなる。
「だから要件は全部満たせるじゃないか！」とマネージャーは言う。
その考えが間違いだ。
納期が長いほど、完成するのは未来であり、そのときにはもうそのシステムは必要なくなっているのである。


だから「納期までにすべての要件を満たす」というゴールを持ったプロジェクトは100%失敗している。
絶対にだ。
成功する要因が見当たらない。
もしも「ウチは成功しているよ！」という企業があれば、おそらくその企業の顧客は辟易していることだろう。


「妊婦が9人集まっても子供は一ヶ月で産めない」と言うと
「ウチは2人で3ヶ月で産んだよ！　　・・・・死んでるけどね！」というのと同じである。

そういえば、俺の時代キターーーーだった

そう、プロジェクトがほぼ停止状態になって何も知らない人間達が残された。
ほとんど人がいない状態になったのである。(もちろんマネージャーも別部隊へ)


っつーわけで俺がプロジェクト進行を管理することになったのである。
これはノブレスオブリージュだから仕方ない。
で、今の課題となってるのはチームの能力を測るということ。
スクラムの教科書では


・フィーチャーのストーリーポイントをチーム内で決定する。
・スプリント毎にストーリーポイントがどれくらい減算したかを算出する。


となっている。
問題はストーリーポイントが決定できない、ほぼ未知数の要件ばかりで規模感すらわからない状態という有様。
要件の規模が算出できないのでは、チームの能力を測ることができないのである。



とは思ったけど、今まで間違いだらけの認識で間違ったことをやってきたから不可能感があったけど、俺が主導でやればできるかも。

小さな例で考えてみよう

ストーリーポイント3のフィーチャー(what)が複数存在している。
それらをタスク(how)に分解すると12時間のチケットができた。
これを同じ速度で4人が行うとする。
チームのベロシティはいくらか？？
(ここで一日の作業時間は6時間とし、一週間は5日。スプリントは一週間とする)


1日の作業時間が6時間なら、2日で1つのチケット。すなわち3ポイント消化される。
これを5日で4人が行うのだから、答えは30ポイントということになる。


うーむ、これでいいのだろうか。

絶望行進曲ｗｗｗ

日立なら有り得ると思います。あーんど、日立はまだマシなのかもよ？とも思います。


まぁ、たしかに日立自体はまだマシとは思います。
ただ、一緒に仕事をする人間が日立の皮をかぶった外注の皮をかぶったどこぞのゴミ人間(俺含む)どもの集まりが「初心者C言語」を読みながら仕事をするというね。

それもこれも

「間に合わない！」に対して人数を集める風潮のせい。
間に合わない時点で予算はもう残ってないから必然的に安くて人がいっぱいいるところに頼まざるをえない。
じゃあその状態でなにができるかというともう手遅れでできることはなにもない。
約束を破ってスコープを縮小するということしかできなくはないけどそれができるほど器の大きい組織だったらそんな手遅れな状態にはならない。
死が約束されている、まさにデスマーチである。