Microsoft Project 2000は、プロジェクトの経過時間と完了した作業を測定するための様々な方法を提供しています。見積期間やタイムシート、個人用ガントチャート、タスク委任など、データのスライスや進捗状況の追跡のためのオプションが豊富に用意されています。この追跡に役立つのが、しばしば誤解されがちな「達成率」と「作業完了率」という2つの機能です。
MSPに関するよくある質問の一つは、これら2つの機能に関するものです。ユーザーは、常に同じ値であるにもかかわらず、なぜ2つのフィールドが存在するのかと疑問に思うことがよくあります。この2つのフィールドの誤解を招く点は、多くの場合同じ値であるということです。この記事では、これら2つのフィールドの意味を探り、なぜ異なるのか、そしてなぜ同じに見えることが多いのかを説明します。
これらの値の計算
方法 完了率は期間に基づく指標であり、作業完了率は作業時間に基づいています。この2つのフィールドは次のように計算されます。
- 完了率 = 実際の期間/期間 (PC=AD/D)
- 作業完了率 = 実際の作業時間/作業時間 (PWC = AW/W)
タスクの期間が 3 日間で、1 日半が完了している場合 (実際の期間の 1 日半)、完了率は 1.5/3 = 0.50 なので 50 パーセントになります。
作業完了率についても同様です。作業時間が40時間で実作業時間が24時間のタスクの場合、24/40 = 0.60となるため、作業完了率は60%となります。
これら2つのフィールドは、多くの場合同じ値を持つため、同じものとして無視されがちです。これは、タスクの作業がタスクの期間全体にわたって均等に分散されることが多く、タスクの期間の半分が完了すると、タスクの作業も半分完了するからです。
例えば、5日間の期間で40時間の労働時間を8時間労働の5日間に配分したタスクを考えてみましょう。実際の労働時間も同じ配分（1日8時間、または半日4時間など）で計算すれば、2つの割合は同じになります。
値を確認したり、MSP がどのように機能するかを調査するためにテスト プロジェクトを設定する場合、ほとんどの人は、作業と期間の比率が均等になるようにプロジェクトを設定するため、異なる可能性がある条件でフィールドを確認することはありません。
値が異なる場合
これら2つのフィールドがどのように、そしていつ異なるかを示す良い例として、図Aに示すようなタスクが挙げられます。これは2週間の期間のタスクで、リソースAには最初の5日間で20時間、リソースBには最後の5日間で50時間が割り当てられています。
リソース A が最初の 5 日間に 1 日あたり 4 時間の作業を報告すると、10 日間の期間の半分が完了しているため、タスクの完了率は 50 パーセントになります。
ただし、作業の完了率は 29 パーセントにとどまります。これは、作業のほとんどが最終週にリソース B によって実行されるようにスケジュールが「後回し」にされていたためです。
2人のリソースはタスクの期間を均等に分担していましたが、Bは期間の半分で作業の70%以上を占めていました。作業の71%は、期間の最後の50%で完了する予定でした。そのため、期間の最初の50%が完了した時点で、実際に完了していたのは作業の29%だけでした。
| 図 A |
 |
図Aでは、Aは第1週に20時間、Bは第2週に50時間を費していることがわかります。期間を表す指標である完了率は、期間全体のうちどれだけの作業が完了したかのみを測ります。そのため、Aが5日間の作業を終えた時点では、完了率は50%となります。この例では、期間の半分が完了しているにもかかわらず、プロジェクトの設計上、まだ70%以上の作業が残っています。
計画期間とランプアップによって、PCとPWCも変化する可能性があります
。あるタスクに1人が一時的に作業し、その後プロジェクトがランプアップし、残りのタスクを20人が担当するような状況では、この2つの計算は異なります。このような場合、2つのパーセンテージの差は非常に大きくなります。
この違いは、サマリータスクレベルのプロジェクト、特にサマリータスクの上位レベル、またはサマリーの下に多数のタスクが存在するプロジェクトサマリーでより顕著になります。その好例がソフトウェア開発プロジェクトです。プロジェクト開始時のタスクは作業量が少なく（少数のリソースが単独で作業）、期間の中間点以降のタスクは作業量が多く（多くのリソースが共同で作業）なる場合があります。
開発プロジェクトの初期段階におけるタスクは、多くの場合、1人、またはプロダクトマネージャーとプログラムマネージャーからなる非常に小規模なチームによって行われます。彼らは機能仕様の作成など、単独で作業を行います。これらのタスクは比較的作業量は少ないものの、リソースが少ないため、期間は長くなります。
その後、開発作業が始まると、比較的作業負荷の高いタスク、あるいは同時に多くの作業負荷の高いタスクが発生する時間帯が発生します。多くの開発者が同時に作業し、実際のソフトウェアをコーディングします。比較的短い期間に多くの作業時間が発生するため、プロジェクトの後半では作業負荷が高くなります。そのため、プロジェクトレベルでは、仕様書が完成した時点では完了率は20%から30%になるかもしれませんが、作業完了率は10%から15%程度と非常に低くなる可能性があります。
上記のようなプロジェクトでは、完了率はプロジェクト全体の完了度を示す適切な指標ではないことを覚えておくことが重要です。完了率の最初の20%は、大きなリスクもなく容易に完了しました。一人で仕様書を作成するのは、ソフトウェアプロジェクトにおいて難しい部分ではありません。難しいのは、開発者全員が同時に異なる部分に取り組んでいる最終段階です。この場合、作業完了率の方が、残りの作業量を示すより適切な指標となるかもしれません。
