PR

 システム開発プロジェクトにおいてWBS(Work Breakdown Structure)は最も重要な成果物の一つである。WBSなくしてプロジェクトは進行しないといっても過言ではない。

 PMBOKではWBSをプロジェクト・スコープ・マネジメントの成果物として位置づけており、「プロジェクト目標を達成し、必要な要素成果物を生成するために、プロジェクト・チームが実行する作業を、要素成果物を主体に階層的に要素分解したもの」と定義づけている。

 つまりWBSとは、プロジェクトを進行する上で必要な作業を細分化したものといえる。このWBSの作成方法については、多くの書籍にて紹介されているのでここでは割愛する。PM(プロジェクトマネジャー)になりたての若手技術者の中には、各書籍にて紹介されたWBS作成手順を忠実に守ろうと、作業をとことん細分化してしまう人がいる。基本に忠実であることは重要だが、作業の細分化に固執してしまうと、結果として開発工数がシステム規模に対して想定以上に増大することが少なくない。

入社10年目A君の見積もりはFP値ベースの2倍に

 A君は今年で入社10年目の中堅社員である。彼の所属する部署は大企業を相手にしており、入社以来一貫して大規模プロジェクトに参画してきた。そんな彼の実績が評価され、このたび別の部署で小規模プロジェクトのPMとして抜擢されたのだった。10年もの間、常にプロジェクトの中にいて先輩PMの仕事を見てきたA君である。多少の不安はあるものの、小規模プロジェクトならばそんなに苦労はしないだろうと高をくくっていた。

 プロジェクトが始まり、A君はさっそくWBSを書くことにした。WBSについては入社以来常に見てきた成果物である。自分で書いたことはなかったものの、多くのWBSを見てきたA君は、これまでの経験を基に作成することにした。

 A君の作成したWBSは自画自賛するほど綿密なものだった。作業は教科書通りに細分化されていた。特に小規模プロジェクトということもあって、収支管理が厳しくなると考えたA君は管理の最小単位を1時間として作成した。例えば「設計書作成」という項目については、成果物のボリュームを50ページと仮定した上で、一人のエンジニアの生産性は2ページ/時間と設定した。

 つまり設計書作成に要する工数は、「50/2=25時間=3人日+1時間」といった具合であった。A君の作成したWBSは緻密であったが、そのボリュームは莫大なものとなっていた。

 WBSを作成した後、プロジェクト全体工数の見積もりを行うことにしたA君だが、ここで大きな壁にぶつかってしまった。WBSをベースに算定した工数が、FP値をベースに算定した工数を大幅に上回り、2倍くらいになってしまったのである。何度積み上げ直してもその差は縮まらない。結局彼は自分が積み上げたWBSを正しい値としてプロジェクト予算の増額を上申することにした。

 しかし、FP値をベースにした工数に対して2倍の工数を提示されても、顧客は納得いかない。その後、この工数折衝は大きくもめてしまい、プロジェクト自体が先へ進まない事態に発展する。

 見るに見かねたA君の上司は、彼をPMからPL(プロジェクトリーダー)へ格下げし、その代わりに別のエンジニアをPMに据えてFP値ベースの工数で合意してしまった。自分の出した工数を譲らないAさんと、彼を疑いの目で見るようになった顧客の両方を納得させるにはこの方法しかなかったのだった。

 結果的にこのプロジェクトはFP値ベースの工数に近い工数で完了した。A君の主張が間違いだったことを証明してしまった形となった。皮肉なことに、この高い生産性で想定工数通りにプロジェクトを納めたのは、誰を隠そうPLとして辣腕をふるったA君自身だったのだ。