作業項目を多角的に分類する
ソフトウェア開発プロジェクトのWBSは、文書やモジュールといった成果物か、または、ソフトウェアの機能を中心に、作業項目が整理されたものとなっている。だが、それ以外の異なる観点からも作業項目を整理し、多角的に分析できることが望ましい。
WBSの作業項目は、成果物や機能の他にも、下記のような観点で分類することができる。
- 工程
- マイルストーン
- 担当者
異なる観点で工数を集計し、分析することで、WBSからプロジェクトの進捗状況についてのさまざまな情報を得られることは、すでに述べた。見積もりにおいても、異なる角度から眺めることで、精度を上げることができる。例えば、下記のような作業は、成果物や機能を中心に考えていると忘れてしまいがちだが、工程ごとに分類できれば、漏れを防ぎやすい。
- 環境構築
- ドキュメントのレビュー、及び、レビュー後の修正
- 最終的なドキュメントの確認、及び、修正
- テストで見つかった障害の修正と、再テスト
- リリース準備、及び、リリース作業
また、本稿では、WBSを開発がスタートした後の進捗管理にも使用する、という管理手法を提案している。だが、見積もりで作成したWBSの階層構造は、そのままでは、開発がスタートした後の進捗管理には不向きなことがある。見積もりのために項目を分析する際の観点と、実際に開発する際の作業の切り分け方とは、必ずしも一致しないためである。
見積もりのWBSと、進捗管理のWBSとのミスマッチの例を示す。
- 工程ごとに分類するのが望ましいケース
下記の例では、画面ごとに見積もりを行っているが、実際の作業では、２つの画面を同時に作っていく方が作業しやすい。こうしたケースでは、工程ごとにWBSを再分類してから開発をスタートすると良い。
工程ごとに分類したWBS - マイルストーンごとに分類するのが望ましいケース
下記の例では、テストが終わった後で、ドキュメントを手直しすることを想定している。こうしたケースでは、テスト終了時を１つのマイルストーンとして、テストまでの作業と、テスト後の作業とに分けると良い。そして、ドキュメントの工数の一部を、テスト後の作業として切り出しておく。
マイルストーンごとに分類したWBS - 担当者ごとに分類するのが望ましいケース
下記の例では、画面ごとに見積もりを行っているが、実際にはどちらの画面も、実装までの作業と、テストの作業を、２人の担当者で分担する。こうしたケースでは、担当者ごとにWBSを分類すると、記入がしやすい。
担当者ごとに分類したWBS
こうしたミスマッチを解消し、開発がスタートした後のWBSの運用をやりやすくするためにも、WBSの作業項目を、さまざまな観点で分類できることが望ましい。
業務外や休暇を調整する
本稿で提案したプロジェクト管理手法では、業務外や休暇も作業項目として扱い、工数を計上する。だが、作業計画を見直したり、マイルストーンを変更する際には、業務外や休暇について、面倒な調整が必要となる。
例えば、あるプロジェクト開発の見積もりが30日だとする。向こう2ヶ月の間の業務外や休暇の見込みが、およそ10日だとすると、合計で40日となり、最短のリリース可能日は、ちょうど2ヶ月後となる。
ところが、計画の見直しがあり、10日分の作業が追加されたとする。この時、最短のリリース可能日も10日後に延期する、という訳にはいかない。その10日の間にも、業務外や休暇に費やす時間があるためだ。
このケースでは、もしも2ヶ月後から半月の間の業務外や休暇の見込みが、およそ3日だとすれば、最短のリリース可能日は13日後に延期する必要がある。
業務外・休暇を考慮した、納期の延期
開発プロジェクトのタスクの実施日が、WBSに記入されている工数を基に順に並べることで自ずと決まるのと違って、業務外や休暇は、開発プロジェクトからは独立している。そこで、カレンダーに記入するように、おおよその時期を決めて予め登録しておき、開発プロジェクトのタスクやマイルストーンに応じて、適切に調整されるようにしておくと理想的である。
さまざまな線表（ガントチャート）を描く
ソフトウェア開発プロジェクトの現場では、作業スケジュールを表す道具として、線表（ガントチャート）が使われることが多い。
線表は、それぞれの作業項目をいつからいつまでに実施するかを示したものである。WBSに記入されている工数を基に、タスクを作業順序に従って並べていくことで、線表が出来上がる。
線表を描くことで、それぞれのタスクをいつ実施するか、また、開発を終えられる最短の期日、即ち、最短のリリース可能日がいつになるか、の目処が立つ。
また、進捗率に応じて線を塗り潰すことで、おおまかな進捗状況を把握する上でも役立つ。
計画ベースの線表と、実績ベースの線表
WBSには、計画工数と予定工数が記入されている。計画工数は、見積もりをした時点で算出した工数で、開発を始めるに当たって顧客と合意をした値である。一方、予定工数は、開発をスタートした後で、実績に基づいて見直した、現実的な作業時間の予測値である。
WBSによるプロジェクト管理では、計画工数に基づいて線を引いた線表（計画ベースの線表）と、予定工数に基づいて線を引いた線表（実績ベースの線表）と、どちらを描くこともできる。
計画ベースの線表は、初めに顧客に提示したスケジュールに対して、作業が遅れているかどうかを示すのに適している。だが、実際の開発作業が当初の見積もりから大きくずれてくると、この図法は適さなくなる。
計画ベースの線表
一方、実績ベースの線表は、どれくらいの作業が残っていて、いつになれば開発を終えられるのかを把握するのに適している。だが、この図法では、当初の見積もりに対する遅れの度合いは分からない。
実績ベースの線表
この２つの図法は、目的に応じて使い分ける。
進捗率と、残り作業工数
開発がスタートした後は、進捗率に応じて線を塗り潰す。
実績ベースの線表では、塗り潰された線の長さは、実績工数と一致する。だが、計画ベースの線表では、これらは一致しない。
一般的には、線の長さに対する塗り潰された部分の割合が、作業の進捗率を表すようになっている。だが、この方法では、作業が遅れている状況では、プロジェクトの遅れ具合を過小評価してしまう危険性がある。
例えば、10日間の見積もりで始めた作業が、8日経った時点でも半分しか終わらず、まだあと8日かかる、という状況を考えてみる。進捗率は50%である。この時、先の方法で塗り潰すと、計画ベースの線表は次の通りになる。
計画ベースの線表を、進捗率に合わせて塗り潰した例
この線表では、あと5日で終了する、という印象を与えてしまう。
作業の遅れ具合を過小評価しないためには、進捗率に応じて塗り潰すのではなく、残りの作業に要する時間だけを塗り潰さない、という方法も有効と思われる。即ち、あと8日かかる、ということは、実質的にまだ2日しか作業していないのと同じである、と考える。
計画ベースの線表を、残り工数に合わせて塗り潰した例
この場合、塗り潰される部分の割合は、下記の式で計算される。
１−残り工数÷計画工数
＝１−（予定工数−実績工数）÷計画工数
タスクの並列化
WBSに記入されている工数を基に、タスクを作業順序に従って並べていくことで、線表が出来上がる。この線表では、それぞれのタスクを１つずつこなしていくことになる。
だが、タスクによっては、他のタスクと並列に実施する場合もある。
特に、業務外や休暇、プロジェクト管理といった、ソフトウェアの開発に直接的に関わらないタスクは、ある時期にまとめて実施する、といった類のものではない。設計や実装といった直接的な作業と並列に線を引かないと、実際の作業形態から乖離した線表になってしまう。
タスクを並列に並べた線表
特定の日に限定されたタスク
線表では、それぞれのタスクをいつ実施するかが表されている。
一般的には、WBSに記入されている工数を基にタスクを順に並べると、タスクの実施日が自動的に決まることになる。だが、タスクによっては、ある特定の日に実施することが決まっている場合もある。
例えば、顧客の施設を利用してのテストや、顧客との仕様検討会議などは、実施する日時が限定されたタスクとなる。また、外注したライブラリとの結合テストや、装置が入荷してからの結合テストなども、ある特定の日の後にしか実施できない、限定されたタスクとなる。
線表を描く際には、こうしたタスクを特別扱いする必要がある。
特定の日に限定されたタスクは、納期の見極めにも影響する。開発を終えられる最短の期日、即ち、最短のリリース可能日は、見積もり工数を加算して求めるが、それよりも後に実施しなければならないタスクがあれば、リリース可能日はそれに合わせることになる。
特定の日に限定されたタスクのある線表
また、線表を描く際には、8時間を1日として線を描く。だが、ある特定の日に、16時間分の作業を行うことが決まっている場合もある。その場合は、そのタスクとして1日分の長さの線を引くだけでなく、その他のタスクの線に1日分の余白を挿入する必要がある。休日に作業することが決まっている場合も同様である。
作業時間が決まっているタスクのある線表
多角的な線表
WBSに記載されているタスクをすべて線表に描くと、タスクの数が膨大になってしまい、分かりにくくなってしまうことがある。その場合は、タスクごとにではなく、いくつかのタスクをまとめた線を引くと良い。
この時、WBSの作業項目を異なる観点から整理するのと同様に、線表においても、異なる観点でタスクをまとめられるようにし、多角的に眺められることが望ましい。
例えば、WBSの項目が機能ごとに細分化されている場合でも、成果物ごとにまとめた線表を描けば、それぞれの成果物を順次リリースするための、目処が立つ。
異なる観点でまとめた線表の例を示す。
異なる観点でまとめた線表