工程表を作成する方法はいくつかある。システム開発プロジェクトではWBSを用いてガントチャートを作成する方法が一般的である。このWBSを分解 しワークパッケージ単位まで落とし込む際に，各担当SEやプログラマに概算工数を算出させるプロジェクト・マネージャ（PM）は少なくない。
各担当者は，PMからの要請に従い，自分が行う作業工数を見積もって報告する。PMは，各担当者から報告された工数をベースにWBSを ガントチャートに割り当ててゆくのである。事実，筆者もワークパッケージを1～2週間単位の粒度まで細分化していく場合，担当者やその作業に見識のある技 術者に当該成果物がどのくらいの工数で作成できるのかを聞く機会は多い。
こうして作成した工程表を基にプロジェクトを推進しようとすると，往々にして予定していた工数を超過してしまう。では，いったいなぜ各担当者からの見積もりに基づく工数が超過してしまうのだろうか。一つのエピソードから，その原因を探ってみよう。
A君の失敗
A君は入社8年目の中堅社員。今回15人月程度のWebシステム開発のPMとして任命された。これまでA君は，プロジェクトのサブリーダー経験は あったが，PMは初めての挑戦である。今回のプロジェクトは，要件定義フェーズまでを準委任契約で行い，基本設計以降については請負契約で実施することと なっていた。
要件定義フェーズは，A君と後輩のSEの二人で実施することにした。二人とも優秀なSEであり，またユーザーも非常に協力的であったの で何事もなく要件定義フェーズを完了しようとしていた。そこで，A君は次フェーズの契約を締結するために，基本設計以降について工数見積もりと工程表の作 成に取りかかった。
今回の開発は小規模ということもあり，設計～プログラミング～テストのすべてを自社開発で行うことにした。特にプログラミングについては，A君のチームでは要員が足りないこともあり，Web系システム開発で実績のあるBさんのチームにお願いすることにした。
A君は早速Bさんと今回のシステム開発要件について打ち合わせを行った。このとき，A君が事前にWBSを成果物単位まで分解していたので Bさんもスムーズにシステム開発概要を理解してくれた。その上で，A君はBさんに対して，各ワークパッケージに必要な工数を算出するように要請した。ほど なくしてBさんから概算工数が提出された。
それはA君が想定していた工数より少ない工数であった。しかしA君はBさんの工数を信用し，そのままの値を利用して工程表を作成したの だった。その後，プロジェクトは順調に進み，詳細設計が終わり，プログラミング・フェーズに入った。A君は，いよいよBさんチームの本領が発揮されるとき であると思っていた。
プログラミング・フェーズに入り1カ月が経過した時点でA君はがくぜんとした。なぜならば，プログラミング・フェーズで消費されたプロ ジェクト原価実績が当初の想定よりも1.5倍以上超過していたからだ。実はA君の会社では，複数のチームで協業する場合には，以下の社内ルールが決められ ていた。
| ・依頼先のチームは，1カ月単位でその労働時間を依頼元に報告する ・依頼元のチームは，報告された労働時間数に応じて，依頼先チームの社内原価を負担する ・1人月は160時間で換算する |
当然この社内ルールについてはA君もBさんも十分熟知していた。A君はBさんが算出した工数に該当する社内原価を計算し，それをプロジェクトの直接原価として計上していた。そうであるにもかかわらず原価実績が超過したのだ。
その原因をA君が調べた結果，Bさんのチームの労働時間数の超過にあると判明した。つまり，Bさんのチームは毎日遅くまで残業していたのだ。これによって「期間」は守れているが「労働時間」が超過し，結果として工数超過となっていたのだ。
Bさんとしては，最初にA君から工数を聞かれたときに，自分のチームの人数であれば，どのくらいの「期間」が必要かを考えた。そしてその「期間」に人数を掛け合わせたものをA君に報告したのである。その際，Bさんには「1日当たりの労働時間」という概念は無かった。
確かに，Bさんが「期間」を考えるときに，「1日当たりの労働時間」を考慮していれば，今回の問題は発生しなかったのかもしれない。しか し，だからと言ってBさんが悪いと言うのは間違いである。今回の問題は，PMであるA君が，Bさんが提出した工数をうのみにして使ったことが問題なのだ。
担当者は過少申告する
一般的に，各担当者に工数の見積もりを行ってもらうと，実際にかかる工数よりも少なく見積もる傾向にある。これは各担当者が意図的にそうしているのではない。A君の失敗例がそうであるように，各担当者が作業時間を見積もる際に1日の労働時間を想定していないのだ。
リスクを多めに見積もる安全主義者か，毎日きっかり8時間しか労働しない担当者で無い限り，過少申告してしまうのである。特にプログラマについて言え ば，裁量労働制を採用していない限り，たとえプロジェクトが順調に進んでいたとしても，毎日5時半きっかりに退社し，1カ月の労働時間が所定労働時間の範 囲に収まるという技術者はそうはいないだろう。
A君の場合は設計からテストまで一貫して社内開発であったが，協力企業を使って開発を行う場合も同様である。特に協力企業への支払い条件が労働時間に応じて精算するような方法をとっている場合には注意が必要である。
また，支払い条件は労働時間に左右されない方法となっていたとしても，担当者からの過少申告による「期間」への影響も忘れてはならない。 A君の場合には，Bさんのチームが工数こそ超過したものの工期については守ってくれたので，ユーザーに対して大きな迷惑を掛けることはなかった。しかし， 一歩間違えれば工数のみならず工期まで超過する危険性があることを十分理解しておく必要がある。PMは，各担当者から報告された工数を利用する場合には， 労働時間について十分注意しその内容について確認しておく必要がある。
PMの実力は工程表で分かる
PMは，担当者が報告した工数についてまず疑ってかかるくらいの慎重さが必要だ。その上で，プロジェクトの難易度やメンバーのスキルを勘案し，すべての工数について見直しを行うべきなのだ。
あるベテランPMによれば「工程表を見れば，そのPMの実力が分かる」と言う。それほど工程表とはPMにとって重要な成果物なのである。PMたるもの，たとえ担当者が算出した工数であっても自分の手で再度算出し，自信と責任を持って工程表を公開すべきである（表）。
| 種類 | 目 的 | 作成時期 | 管理対象 | 単位 | 例 |
|---|---|---|---|---|---|
| 大工程表（マスター・スケジュール） | プロジェクトで実施すべき作業内容と作業日程の明確化 プロジェクト全体の進捗を管理する ステークホルダーへの報告資料 | 見積もり作成時 プロジェクト計画時 | 全工程 システム全体 プロジェクト全体 | 月単位 週単位 | WBS PDM/ADM ガントチャート |
| 中工程表 | 工程ごとの詳細な作業内容と作業日程の明確化 チーム単位の進捗管理 ステークホルダーへの報告資料 | 各工程開始前 | 各工程単位 サブシステム単位 チーム単位 | 週単位 | WBS PDM/ADM ガントチャート |
| 小工程表 | 工程ごとの個人レベルの作業内容と作業日程の明確化 個人レベルでの進捗管理 | 各工程開始前 | 各工程単位 機能単位 プログラム単位 個人単位 | 日単位 | WBS ガントチャート |
ADM：Arrow Diagramming Method
●●コメント●●
0 件のコメント:
コメントを投稿