本日は代休
とりあえず、寝て起きてお昼。
設計および工程の最適化によって工数は最小化されるが、限度もある
何かを開発するには時間が必要。
この時間を見積もるのに必要なのは、やっぱどんだけの開発をこなしてきたか（指揮してきたか）という経験。
単に経験するだけではなく、開発にかかった期間が適正であるかどうかをきちんと振り返り、次の開発に活かしていることが必要。
おそらくだけど、腕利きのプロジェクトマネージャは、このあたり肌感覚で染み付いてる。
大丈夫か？と思いつつも、きちんと段取りができたものの例
例えば、（ちょっと前のネタだが）Day2 と呼ばれた三菱東京UFJ銀行のシステム統合は、問題なく完遂した。
このプロジェクトの例は、11万人月という巨大な工数を適正に割り振れた例であり（3年がかりとはいえ、移行で2600億ってのは相当でかい）、同時に動いたSEの人数は6000人というから恐れ入る。
炎上プロジェクトあるある：「遅延しそうだから人数を投入」は、たいていの場合傷口を広げる
Day2の期間3年のうち10ヶ月が試験だったとして、多分この期間は短縮はできない。
おそらくは各工程を最適化し、かつ各工程で発生しうるリスクも織り込んだ結果だろうからだ。
システム統合の「正攻法」という書籍の目次には、「成否のポイントは開始前にあった」とあるが、これは（開始前に完全な最適化はムリにしても）それまでの経験から「これくらいかかるはず」という目論見があってのことだろう。でないと（期間はともかく）費用的にはGoが出るレベルのものではない。
Day2の場合は成功裏に終わったが、もし何らかの理由で「期間短縮」という話が出たり、前工程のロスを後工程で吸収するために「期間短縮」という話が出た場合には、話は大幅に変わったはず。
一般的なプロジェクトにおいて、「要員を追加投入」という話が出てくるが、これはよほどのことが無い限りはすべきでない、というのがオレの考え。「単純作業だけしてればよい」というわけではないので、新たに集められた要員の考え方などにはどうしても差異がある。というか、集めるだけでなんとかなり、かつ呼集できるレベルの人は、最初の時点で集められていると考えるのが自然である。
要員増やすならば、工程の分割単位を見直すか、アサインする作業の割り振りを考えるべき〜それでも限度あるけど
「設計および工程の最適化によって工数は最小化されるが、限度もある」でも書いたが、最初の時点である程度勝敗が決している部分がある。ここで主に期間に係るところを見直す必要があるとなると、工程全体の見直しが必要というのが今のところの持論。「人数は増やして期間はそれに応じて短縮してもらうけど、それ以外は何も変えない」では、多分開発現場がもたない。
要員を増やすならば工数の割り振りや作業単位を見直すレベルまで踏み込まないとならないけど、たいていの場合は知恵を絞り尽くしてある期間に収めてるはずなので、それ以上あれこれやっても検討の工数のわりに短縮される、ということにはならない（例外：本当に機械的な作業しか残っていないとか、そもそも最適化が全然出来てなかったとか）。
開発には期間が必要。人数を投入しようとここは変わらない
人数投入を否定するわけではないけど、それは工程の見直しが前提にあってのこと。
その前提を満たすにも、ある程度の時間を見込む必要があるし、そもそも開発には期間が必要。
2人がかりで5日のものを、5人がかりで2日でやるとかいう無茶はそもそもないし、それを根拠なく言い出すような人がいて、「やればできる」とか「やる気の問題」とかいう返事しか出てこないようならば、結構ヤバいと察するべき。
