実績も記録するようにWBSを拡張する
見積もりの段階で作成するWBSには、細分化されたプロジェクトの構成要素の階層(大項目・中項目・小項目)と、それぞれの項目に付随するタスク、およびその見積もり工数が記入されている。
見積もり工数が記入されたWBS
WBSに実績も記入し、進捗管理にも活用できるようにするために、記入欄を追加してWBSを拡張する。拡張したWBSは、基本的に、下記の記入欄を持つ。
- 大項目
- 中項目
- 小項目
- タスク
- マイルストーン
- 工程
- 状態
- 担当
- 計画工数
- 予定工数
- 実績工数
- 残り工数
- 進捗率
- 遅延
- 備考
- マイルストーン
-
顧客とのレビューやリリースなどの予定日。どのマイルストーンまでに終える必要がある作業かを表す。
- 工程
-
仕様策定、設計、実装、テストなどの区別。
- 状態
-
「未」「作業中」「済」。
- 担当
-
必ず誰か1名を割り当てる。
- 計画工数
-
見積もり工数。運用中は、この値は原則として書き換えない。
- 予定工数
-
実際に作業にかかる工数の予測値。見積もりの時点では計画工数そのものだが、開発がスタートすると、さまざまな要因で見積もりとのずれが生じる。この値は、運用中は常に見直し、書き換えていく。
作業が終わった時点では、実績工数と一致する。
- 実績工数
-
実際に作業にかかった工数。
- 残り工数
-
作業が終わるまでに、あとどれくらいの工数がかかるかの見込み。下記の計算式で得られる。作業が終了したら必ず0となる。
予定工数 − 実績工数
- 進捗率
-
下記の計算式で得られる。作業が終了したら必ず1(100%)となる。
実績工数 ÷ 予定工数
- 遅延
-
見積もり工数と、実際に作業にかかる工数とのずれ。これは、作業が終わった時点で、最終的にどれくらいのずれが生じるか、の予測値である。
下記の計算式で得られる。
予定工数 − 計画工数
拡張したWBSは、Excelなどの表計算ソフトウェアを使って作成することになる。残り工数、進捗率、遅延については、表計算ソフトウェアの計算式を定義して、自動的に計算されるようにしておく。
拡張したWBSの例を示す。
拡張したWBS
WBSにおいては、タスクが最小単位となる。タスクは、数時間から数日程度の規模の作業となる。見積もり工数、実績工数の記入は、各タスクに対して行う。作業のマイルストーンや担当なども、タスクごとに決める。
各工数(計画、予定、実績、残り)と遅延については、最下行に合計が表示されるように、表計算ソフトウェアの計算式を定義しておく。進捗率についても、作業項目全体の進捗率が表示されるように計算式を定義しておく。
実績を記入したWBS
この拡張したWBSにおいて、開発プロジェクトがスタートした後に頻繁に書き換えられる個所は、実績工数、および、予定工数である。
WBSへの実績の記入は、原則として毎日行う。毎日記入することで、常にプロジェクトの最新の状況を把握することができる。また、記入する際には、必ず工数が充分かどうかを見直し、もし予定通りに終わらなそうであれば、随時、予定工数の欄を書き換える。これにより、常に、実績に基づいた正確な見通しを把握することができる。
コラム:進捗管理を行う単位
WBSにおいて、進捗管理を行う単位は、タスクである。見積もり工数、実績工数の記入は、各タスクに対して行う。作業のマイルストーンや担当なども、タスクごとに決める。
だが、見積もりの時点では、正確に見積もるために、タスクの粒度はかなり小さくなる。実際に開発がスタートした後も、その粒度のまま運用を続けると、作業分担や工数配分が細かくなり、煩雑すぎて現実的でなくなることがある。
その場合は、1つ上の小項目(ワーク・パッケージ)を単位として、ワーク・パッケージに対して工数を記入したり、マイルストーンや担当を決めても良い。
この場合のタスクは、やるべき作業を忘れないように書いておく、備忘録のような位置付けとなる。
拡張版WBSを運用する
実績は正確に記入する
見積もりの時点では、工数は0.5日または1日単位で計上されていることが多い。だが、実績については、プロジェクトの状況を正しく把握するために、正確な値を記入しなくてはならない。
WBSに記入する工数は、日単位で表す。だが、8時間を1日とするため、端数が生じてしまう。例えば、イベント処理の実装を3時間、データ処理の実装を5時間作業した場合は、実績はそれぞれ0.375日、0.625日となる。
この場合、イベント処理実装の実績を0.4日、データ処理実装の実績を0.6日という具合に、0.1日程度の精度に丸めてしまっても良い。合計した工数が正しければ、個々の作業項目に誤差があっても問題はない。
Excelを使って運用している場合は、計算式の形で記入することで、時間を日単位に換算せずに実績を入力することもできる。例えば、前述の例であれば、下記のように入力する。
工数を時単位で記入する方法
進捗報告や休暇なども計上する
筆者が提案するプロジェクト管理手法では、リリースまでの期間に影響を与えるあらゆる要因を、WBSにて管理する。そのため、このWBSには、ソフトウェアの開発に関わる直接的な作業だけでなく、プロジェクト管理そのものにかかる工数、さらには、業務外や休暇なども、すべて作業項目として計上する。
一般に使われているWBSでも、成果物を細分化した項目の他に、プロジェクトマネジメント要素という特殊な項目を設けるものとされている。開発プロジェクトにおいて、プロジェクト管理は必須なものであり、それにかかる費用や工数は無視できないためだ。具体的には、進捗報告、開発環境の整備、リリースなどの作業が該当する。
拡張したWBSを使ったプロジェクト管理では、それに加えて、業務外や休暇も作業項目として扱う。他の開発プロジェクトを兼務している場合だけでなく、社内行事や間接業務などについても、業務外として工数を計上し、通常の開発作業と同様に管理する。
そのため、見積もりの時点で、おおよその作業期間を想定して、その期間に発生する社内行事や間接業務などをすべて見積もっておく必要がある。また、休暇の予定も立てておく必要がある。
コラム:パーセントでの記入をしない
業務外や休暇に費やす時間は、一般には、稼働率として表現することが多い。だが、本稿で提案する拡張版WBSでは、業務外や休暇も、すべて日単位で記入する。
また、進捗状況についても、一般には進捗率を報告することが多いが、本稿で提案する拡張版WBSでは、実績工数と残り工数をそれぞれ日単位で記入する。進捗率は、それらの値から計算されるのみで、直接は入力しない。
本稿のWBSにおいて、パーセントによる記入をしない理由は、誤差が大きいためである。
例えば、1ヶ月に半分くらいは業務外の作業が入っている人に、稼働率をパーセントで訊くと、おそらくは50%と答える。だが、日単位で訊けば、12日かもしれないし、もしかしたら8日かもしれない。パーセントで答えると、人はあまり精度を追求しない傾向がある。
また、ソフトウェア開発において、作業が90%くらいまでは順調に進むが、最後の10%がなかなか終了しない、という話を良く耳にする。だが実は、機能の90%は実装したが、ログを入れていない、エラー処理を書いていない、ファイルヘッダを書いていない、といった具合に、まだ多くの作業が残っており、工数で言えば、まだ半分も終わっていなかったのかもしれない。パーセントで答えると、何に対するパーセントかが曖昧になりやすい。
追加作業は遅延として計上する
開発プロジェクトをスタートした後で、当初の見積もりでは挙がっていなかった作業が発生することがある。そうした場合は、WBSに新たなレコードを追加する。この時、計画工数の欄は0とする。そのため、追加した作業項目にかかる時間は、すべて遅延として扱われる。
拡張したWBSでは、当初の見積もり工数よりも時間がかかった分は、すべて遅延として表される。仕事を怠けていた場合でも、新たな作業が発生した場合でも、WBS上は区別されない。
ただ、実際の運用では、顧客から追加作業を依頼された場合は、その時点で計画を見直し、顧客と相談しながら、必要であれば、作業項目の選別や、マイルストーンの変更などを行うことが多い。その時は、新たな計画に基づいて、WBSの計画工数の欄を書き換える。
但し、計画を変更することは、必ず顧客と合意する必要がある。計画工数の欄は、顧客の合意なしには書き換えてはいけない。また、いつ、どのように計画を変更したかを、きちんと記録に残しておくことも重要である。
自社製品開発の場合は、顧客ではなく、他部門や会社との合意が必要となる。
見積もりのレベルに応じて、マイルストーンを設定する
WBSを使ったプロジェクト管理では、見積もりの時点で開発が終わるまでのすべての作業項目を洗い出し、正確に見積もることが前提となっている。だが、実際のソフトウェア開発プロジェクトでは、スタート時点ですべての作業項目の見積もりが決まらないこともある。
すべての作業項目の見積もりが立たなくても、作業項目の洗い出しを行うことで、明確な部分と不明確な部分をはっきりさせることができる。不明確な部分についても、実現方法や作業量などを明確にするために、何をする必要があるかを洗い出すことはできる。
そこで、不明確な部分を明確にすることを当面の目標として、そこまでの作業を第1フェーズ、それ以降の作業を第2フェーズと分けると良い。第1フェーズについては正確な見積もりを行い、WBSを作成する。
こうすることで、無計画の状態で作業を進めずに、具体的な目標が定まったマイルストーンに従って作業を行うことができる。見積もりの段階で、第1フェーズに時間がかかり過ぎることが分かれば、調査方法を工夫したり、機能を制限するといった対策も採れる。また、WBSを使って進捗管理をすることで、必要以上に調査が長引いてしまう、といった事態を防ぐことができる。
WBSの記入は、メンバー全員で行う
チームで開発を行っている場合は、毎日、メンバー全員分の作業実績の記入と、予定の見直しを行う必要がある。これを、プロジェクト・マネージャが1人でこなすのは大変である。
そこで、個々のメンバーが、それぞれ自分の作業実績を記入し、必要であれば、各自で予定の見直しを行い、WBSを更新するようにすると良い。
但し、そのためには、書かれている内容を、チームのメンバー全員が把握している必要がある。また、作業項目の分類やタスクの内容について、メンバー間で認識が統一されていないと、工数が正しく記入されなかったり、記入が難しくなって敬遠されてしまうことにもなりかねない。
そこで、プロジェクトを始める際の見積もりにおいて、開発チームのメンバー全員でWBSを作成すると良い。具体的には、メンバーがそれぞれ作業項目を洗い出して持ち寄り、それを基にブレーンストーミングを行う。
WBSを全員が記入する場合は、プロジェクトの状況の変化をプロジェクト・マネージャが把握できるように、書き換えた欄は必ず色を塗る、というルールを導入すると良い。プロジェクト・マネージャは、定期的にWBSを参照し、色が塗られている個所をチェックし、チェックした時点で再び色を元に戻す。
なお、メンバーがそれぞれ記入を行うため、いつの時点までの実績が記入されているかは、メンバーによって異なる。メンバーによっては、記入を忘れている場合も考えられる。そこで、メンバーごとの最終記入日も記録しておく。
コラム:プロジェクト管理の工数の扱い方
チームで開発をする場合は、WBSの作業項目について、メンバー間で認識が統一されている必要がある。特に、プロジェクト管理の工数については、注意が必要である。
進捗報告などのプロジェクト管理作業にかかる工数を、設計や実装などの実作業に含めて考えるか、もしくは、明確に分けて考えるか、については、人によって異なる。チーム開発では、プロジェクト管理の工数を分けて扱うかどうか、どちらかに決めておく必要がある。
一般に使われているWBSでは、プロジェクト管理は、実作業とは分けて考えるものとされている。だが、これらの工数を分けて扱った場合は、開発がスタートした後に実績を記入する際にも、作業時間を分けて記録する必要がある。これは、普段これらを分けて考えていない人にとっては、余分な負荷となり、場合によっては正しく実績が記入されないことにもなりかねないので、注意が必要である。
拡張版WBSから、プロジェクトの状況を読み取る
進捗上の問題がある個所を特定する
拡張版WBSでは、それぞれの作業項目ごとに、残り工数と進捗率、遅延が計算され、どの作業でどれくらい、進捗上の問題が発生しているかが分かる
これらの値を大項目・中項目・小項目のレベルで集計すると、成果物や機能ごとの進捗率や遅延が得られる。これにより、開発プロジェクトの中で、どの部分で進捗上の問題があるかを特定し、対策を考えることができる。
また、工程ごとに集計すると、開発プロセスのどの工程に問題があり、改善する必要があるかを知ることができる。
担当者の作業状況を把握する
工数や進捗率、遅延を、担当者ごとに集計することで、担当者の作業状況を把握することができる。
計画工数は、担当者がそれぞれどれくらいの作業を任されているかを表す。一方、予定工数は、実際に担当者がその作業をこなすのにかかる時間を表す。その差分が遅延として算出される。これらの値を見ながら、担当者ごとの作業配分を調整したり、分担を変更することができる。
通常、計画工数は、平均的な技術者を想定して見積もっている。そのため、経験のある技術者には、より多くの計画工数を担当してもらう、といった調整が可能である。また、遅延が生じている場合は、その技術者の作業を減らし、他の技術者がフォローする、といった対策を取ることができる。
担当者ごとに集計した例を示す。
担当者ごとの集計
追加作業や仕様変更の影響を把握する
開発プロジェクトによっては、顧客からの依頼で、小さな作業項目の追加や仕様変更が頻繁に発生することもある。個々にかかる時間は少なくても、積み重なると納期に重大な影響が及ぶ場合もある。
こうした追加作業の発生も、随時WBSに記録しておけば、最終的な影響の度合いを正確に把握し、適切な計画の見直しを行うことができる。
納期を見極める
WBSで表示される残り工数から、開発を終えられる最短の期日、即ち、最短のリリース可能日が計算できる。
見積もりの段階では、ある程度のリスクを考慮して、計算された最短の期日から幾分かの余裕を持たせた期日を納期とする。この納期は、顧客や市場との約束であり、いったん決めた後は、原則として変更しない。
開発がスタートすると、さまざまな要因で見積もりとのずれが生じる。決められた納期にリリースできるかどうかは、残り工数から判断できる。WBSが記入された時点から、残り工数を足した期日が、その時点での最短のリリース可能日である。それが納期よりも前であれば問題はない。だが、納期よりも後になっていれば、残りの作業日数を削減しないと、決められた納期にリリースできないことになる。
最短のリリース可能日と、納期
マイルストーンがいくつか設定されている場合は、マイルストーンごとに判断する。下記の例は、最終的な納期には間に合いそうだが、途中の外部レビューの期日は、予定を変更する必要がある。
マイルストーンごとの、最短のリリース可能日と納期
作業の遅れを把握する
開発プロジェクトの進捗会議で、作業がどれくらい遅れているかを報告することがある。
遅れには、工数的な遅延と、期間的な遅延の、2つの種類がある。見積もりよりも作業に時間がかかってしまっても、残業などによって遅れをカバーすることもできる。逆に、見積もりより少ない時間で作業が終わったとしても、稼働率が低ければ、当初の予定よりも日数がかかってしまうこともある。
拡張版WBSからは、どちらの遅延も計算することができる。
下記の例は、作業を始めて12日目のWBSを示したものである。2つのタスクは、どちらも計画工数が20日である。一方は工数的な遅延が発生し、もう一方は期間的な遅延が発生している。
工数的な遅延と、期間的な遅延
拡張版WBSの遅延の欄には、見積もり工数と、実際に作業にかかる工数との、差が表示される。これが、工数的な遅延である。
一方、期間的な遅延は、下記の計算式で計算できる。
A=見積もり時点で得られた、最短のリリース可能日
B=WBSが記入された時点での、最短のリリース可能日
期間的な遅延=B−A
この2種類の遅延の値を基に、開発プロジェクトの状況を考慮して、対策を取ることになる。
コラム:遅れた理由は必ず説明する
筆者の開発業務では、遅延が生じた時は、そのメンバーに、遅延の理由を説明してもらうことにしている。
遅延とは、即ち、見積もり工数からのずれであるが、その見積もり工数については、初めにチームのメンバー全員で合意している。新たな作業が増えたのであれば、チーム全体でフォローすべきだが、特に理由がなければ、本人が残業でカバーすべき場合もある。
あるメンバーの作業が遅れると、他のメンバーにしわ寄せが及ぶことになる。こうした状況を続けていると、メンバーどうしの分担や作業実績に対する不公平感から、不協和音が生じることもある。
いずれにせよ、遅れを取り戻すための対策は取らざるをえない。だが、遅れた理由を明らかにした上で対策を考えることで、分担を変えるにせよ、残業をするにせよ、メンバー全員が納得した上で取り組むことができるだろう。