納期決定の妥当性 |
作成日：2000-10-13 最終更新日： |
納期、と聞くとそのたびごとに胸が締め付けられる。冷や汗が出てくる。
その私が担当して失敗したプロジェクトに関して、ある試算をしたことがある。
これこれの納期で、これこれの機能を実現させるためには、 どのように人員計画を立てればよいか、 積算しろと上司から言われた。 私だけでは積算に必要な個別の算定資料が出てこなかったから、 もう一人実績のある若手に頼んで 機能ごとにほぼどの程度工数を要するかを積算してもらった。 いわゆる３点見積もりはしなかったと思う。 幅をもたせたかどうかも覚えていない。 さほどに私は凡庸な管理者だったと改めて感じる。
さて、積算資料をもとに、山積み計画を立てはじめた。 このときマイクロソフトの Project という製品を手に入れた。 ツールを使いこなす訓練も兼ねて、 ガントチャートや PERT や CPM といったものを書いてみた。 驚くべきことに、納期を満たそうとなると全く要員が足らない。 ドッペルゲンガーがいてもこなせないほどの量がある。私は頭を抱えた。 平準化した仕事で行おうとすると、開発期間が３倍必要になってしまう。
私があほだったのは、この現状を正式に上司に報告しなかったことだ。 私と上司は休みの日にきていたことがあった。 私が「こんなに大変なんですよ」とその山積み計画を見せたことは、 一度か二度はあった。 しかし、上司は「まあ工夫しろよ」で終わっていた。 私もそうします、といっただけで終わってしまった。 事実は、その３倍（以上の）開発期間がかかったのである。 裏を返せば、その実績のある若い人の工数見積もりが正しかった、 ということになる。
では問題である。納期の問題を解決するにはどうすればよかったか。
人を増やす。これは一法である。しかし、あの「人月の神話」がいうように、 人を増やした分だけ速く仕上がる、ということはない。 よほどインターフェースや機能が分離されているとか、管理者の能力がいいとか、 それほどのことがなければ思った程の効果は得られない。
生産性効率のためのツールを導入する。これも一法である。 問題は、どのような観点でツールを使うかだ。 別のプロジェクトでは、組み込みライブラリーを購入することで、 開発期間を短縮した。 これはいいアイディアだったといえる。 納期はこれで短縮できる。これによって顧客満足度が向上し、 機会損失を抑えることができる。 しかし、イニシャルコストはもちろん、ランニングコストや教育の考慮が必要だ。 このライブラリを組み込むことで、 なにがしかのライセンスフィーを支払わなければならない、としよう。 すると、せっかく得られた機会利益も多少は割り引いて考えなければならない。 あとはこのライブラリーの質とサポートとも関連するが、 教育である。どのようにすれば 使いこなせるか。もし私が採用していたらどうだったろう。
