WBS（Work Breakdown Structure）によるプロジェクト管理（旧稿）

表の形式

新しいソフトウェア開発プロジェクトをスタートする際には、費用や納期、要員などの計画を立てるために、まず、見積もりを行う。WBSは、規模の大きいソフトウェア開発の工数を正確に見積もる上で、とても役に立つツールだ。

WBSを使った見積もりでは、ソフトウェア開発プロジェクト全体を細分化し、個々の項目について工数を見積もった上で、それらを積み上げることで、全体の工数を求める。WBSは、見積もりの妥当性を示す、有力な資料となる。

この時点では、細分化した項目と、各項目の見積もり工数を記入するだけなので、次のような簡単な表の形式で充分だ。

項目の並べ方

WBSの大項目として何を挙げ、それらをどのように細分化していくか、については、対象となるソフトウェア開発プロジェクトによってさまざまである。

WBSは、本来は作業ではなく、成果物を細分化していくものとされている。それに従えば、ソフトウェア開発では、仕様書、設計書、モジュール、テスト計画書などを大項目として挙げることになる。だが、必ずしもその通りでなくても良いと考えている。

ソフトウェア開発では、機能を中心に細分化していく方法もある。この場合、細分化された各機能の配下に、設計、実装、テストなどの作業がタスクとして並ぶ。機能ごとに細分化する方法では、一部の機能を外したりすることも簡単なので、見積もりをした後で機能の選別を行う場合や、反復型の開発などでは有効であろう。

WBSの項目は、プロジェクトの実状に合わせた並べ方をすべきである。

プロジェクトを管理するための工数も忘れずに

ソフトウェア開発にかかる工数を見積もる際は、具体的な機能や成果物だけでなく、プロジェクト管理そのものの工数も考慮する必要がある。

WBSでは、大項目として「プロジェクト管理」も書くと良いだろう。その配下には、進捗管理、開発環境、リリースといった項目を挙げる。

表の形式

見積もりで作成したWBSは、ソフトウェア開発プロジェクトを進めていく際の、工数管理にも使用できる。

作業の進捗状況や、予定からの遅れ具合などを把握できるように、見積もりのためのWBSに、列を追加する。基本的には、次のような列を持つ表を作成する。

大項目 中項目 小項目

タスク 状態 担当

計画工数 予定工数 実績工数

遅延 備考

計画工数、予定工数、実績工数、遅延については、最下行に合計値を計算して表示するように、Excelの計算式をセットしておくと分かりやすい。

スタート時点のWBS

プロジェクトをスタートする時点では、WBSの表は次のようになっている。

運用中のWBS

ソフトウェア開発プロジェクトが始まった後では、WBSの表は次のようになる。

着手した項目については、実際にかかった工数を、実績工数の欄に記録していく。作業が終了した項目については、予定工数の欄に、実績工数をコピーする。

開発はどれくらい遅れているか？

ソフトウェア開発は、当初の見積もりの通りには進まない。実際に作業を始めてみると、たいていの場合は、思ったよりも工数が多くかかる。つまり、開発プロジェクトは遅れる。

当初の見積もりよりも時間がかかりそうだ、と分かったら、WBSの予定工数の欄を書き直す。すると、見積もり工数との差が、遅延の欄に表示される。これを見れば、開発作業の遅れ具合が把握できる。

開発作業の遅れを正確に知るためには、随時、工数の見直しを行い、予定工数の欄を、常に最新の、最も正確な値にしておく。早く見直すほど、開発作業の遅れを早い時点で正確に把握できる。

見積もりの時点では見落としていた作業項目があった場合は、すぐに、WBSに項目を追加する。この時、計画工数の欄には「0」を書き、予定工数の欄に、工数の見込みを書く。この場合、追加した作業項目にかかる工数は、すべて遅延になる。

作業が終わった時は、実績工数の値を、予定工数の欄にコピーする。もし、当初の予定よりも短い時間で終わった場合は、遅延の欄にはマイナスの値が表示される。

開発はいつ終わるか？

最下行に表示されている予定工数の合計から、実績工数の合計を差し引いた結果が、残りの作業工数である。これを見れば、いつソフトウェアをリリースできるかが分かる。

遅延の合計に表示される値は、あくまで、工数上の遅れである。工数上の遅れが発生していなくても、病欠や、他の業務との兼務などにより、メンバーの稼働率が低い場合は、期間上の遅れが発生することがある。逆に、遅延が大きくても、残業や休出によって、期間上の遅れが発生しない場合もある。

リリースなどのスケジュールを調整する場合は、遅延の欄だけを見ないようにすること。

実績は0.1日単位で記録する

実際に開発作業に着手したら、WBSの実績工数の欄に、実際にかかった工数を記録する。

予定工数は、1日単位の大雑把な値になっているかもしれない。だが、実績工数は、必ず0.1日単位で正確に記録する。

とはいえ、設計や文書作成、レビューやコーディングなどの作業時間を、日頃から0.1日単位で正確に記録しておく必要は無い。

例えば、１週間分の実績を記録する場合、設計に約２日、実装に約３日かかった、という程度で充分である。但し、もし２時間半ほど残業したのであれば、１週間の実績が5.0日ではなく、5.3日になるように、実績工数を配分する。

個々の値は正確である必要はないが、合計値は正確にすること。

メンバーごとの作業工数も管理する

プロジェクト管理のツールとして、ここでは、成果物や機能ごとに工数を記録したWBSを作っている。だが、これとは別に、メンバーごとに作業工数をまとめた表も作ると良い。

この表を、ここでは WTT (Work Time Table) と呼ぶ。

WTTでは、メンバーの作業量や、作業期間、稼働率、残業時間などが把握できる。これらは、WBSだけでは把握できない。

また、WTTを作ることによって、下記のような利点が生まれる。

• WBSに、いつの時点までの工数を記録したのかが分かる。これにより、メンバーごとに記録するタイミングが異なっても、混乱なくWBSの更新が行える。
• WTTの実績工数の合計と、WBSの実績工数の合計を比較することで、記入が正しいことを検証できる。WBSは記入欄が多く、計算ミスや記入漏れが起きやすいが、両者が一致していれば、正しく記入できている。

WBSに合わせて作業をしない

WBSの項目は、見積もりの時点で作成したものなので、必ずしも、作業をしやすいようには細分化されていない。

例えば、次の例では、画面ごとに細分化したWBSを作成している。見積もりでは、１つ１つの画面ごとに工数を見積もった方が精度が良くなる。

このWBSのタスクに従って作業すると、Ａ画面を完成させた後で、Ｂ画面に着手することになる。だが、この２つの画面は、まとめて一気に作る方が作業しやすいだろう。

開発中は、効率良くソフトウェア開発を進めることを優先するべきである。無理に、見積もりの時点で細分化したWBSに合わせて作業をする必要はない。

逆に、見積もりの時点では、正確な見積もりをすることを優先するべきである。無理に、実際の作業の進め方を見越した細分化をする必要はない。

WBSを作業に合わせて並べ替えない

とはいえ、WBSに合わせて作業をしなかった場合、実績工数をどのように記録するかが問題となる。

WBSのタスクと、実際の作業とが一致しない場合でも、WBSを開発作業の実状に合わせて並べ替えることはしない。そのようなことをすれば、WBSをメンテナンスするための工数が膨大になってしまう。

WBSを並べ替えるのではなく、実績工数を、WBSのタスクに適当に配分して記録する。なお、この場合も、個々の値は正確である必要はないが、合計値は正確にすること。

例えば、前述の例で、作業実績が下記の通りであったとする。

この場合、例えば、次のように配分する。

但し、もしも簡単にまとめられる項目がある場合などは、WBSの項目を並べ替えても構わない。

追加工数を記録する

当初の見積もりでは漏れていた作業が発生した場合や、途中で新しい機能が要求された場合は、WBSに項目を追加する。この時、追加された作業の工数は、どちらも、遅延として扱われる。

後日、追加費用を請求するために、客先の要求で追加された作業の工数を把握しておきたいこともある。その場合は、WBSに追加工数という列を追加すれば良い。

遅延の合計から、追加工数の合計を差し引いた結果が、作業が遅れた分である。

WBSよりも良く使われている線表

ソフトウェア開発プロジェクトの現場では、線表（ガントチャート）を使ってプロジェクトを管理していることが多い。

線表は、プロジェクト管理に使用するツールの１つで、いつ、どのような作業を行うか、スケジュールを図で表したものである。作業を始める際に、こういった計画を立てるのは当然なので、たいていのプロジェクトでは、線表が作られているだろう。

実際にプロジェクトがスタートした後は、作業の進捗状況を、随時、線表に反映していく。作業が進んだ分だけ、線表の線を塗り潰していく。塗り潰された長さは、作業の何パーセントまで終了したか、という割合を示している。

線表を見れば、開発プロジェクトが遅れているかどうかの判断ができる。その日までの作業がまだ塗り潰されていなければ、予定より遅れていることになる。

なお、実際には、たいていの作業は、線表の予定終了日を過ぎても、多少の残件が残り、100%には達しないことが多い。また、線表の予定開始日になっていなくても、少しは着手して、わずかに塗り潰されることが多い。

線表では、プロジェクトの実状は表せない

線表では、終わった作業の分が塗り潰されて示される。だが、塗り潰された線の長さは、実際に作業した日数や、作業にかかった工数といった、作業の実績を示している訳ではない点には、注意が必要だ。

たとえ、予定通りに線が塗り潰されていたとしても、必ずしも、開発が順調に進んでいるとは限らない。もしかしたら、残業続きでなんとか間に合わせているのかもしれない。線表では、こうしたプロジェクトの実状は分からない。

線表は、開発プロジェクトのスケジュール的な見通しを把握するためのツールである。

残業続きかもしれないが、予定通りに線が塗り潰されていれば、約束の期日までにリリースはできそうだと言える。逆に、どんなに余裕があるように見えても、予定通りに線が塗り潰されていなければ、リリース期日が守れない怖れがある。線表は、こうした判断には有用だ。

だが、たとえ期日を守れても、残業したり、要員を補充したりして、開発に費やした工数が当初の見積もりを超えて、赤字になってしまう場合もある。そういったコスト的な実績は、線表では分からない。

実際、開発が終わって、線表がすべて100%に塗り潰されてしまえば、そこからは何も読み取ることはできない。線表はあくまで、開発プロジェクトを進めていく上での、計画のためのツールなのだ。

WBSと線表を併用しよう

一方、ここで紹介したWBSは、作業にかかった工数の実績を記録するツールである。

WBSと線表は、それぞれ目的が異なるツールである。開発プロジェクトを、スケジュールとコストの両面からうまく管理するためには、この２つのツールを併用すると良いだろう。

なお、線表を書く際には、WBSに記入した計画工数そのものを使って線を引かないように注意しよう。

WBSの計画工数は、作業にかかる時間の見積もりである。実際には、他の業務や雑用、休暇などによって、平日の時間すべてを、その作業に費やす訳ではない。

例えば、有給休暇が年に20日あれば、およそ２週間に１日の割合で休暇を取る計算になる。即ち、工数が10日の作業なら、線表では、少なくとも11日かかると考えて線を引くべきだ。

また、線表に進捗状況を記入する際は、塗り潰す割合が、WBSに記入した予定工数と実績工数の比と一致するようにする。実績工数の日数そのものの分だけ線を塗り潰してはいけない。

線表管理表の書き方

ただ、WBSが示す「日数」と、線表が示す「日数」が、違っているのは混乱を招く。そこで、混乱を防ぐために、次のような線表管理表を使うと良い。

線表管理表の中で、記入しなくてはならいのは、白抜きの箇所だけである。黄色で塗られている箇所は、計算式をセットして、自動的に計算されるようにしておく。

線表管理表は、次のような列を持つ。

最下行は、その列の合計を表している。

休暇は、作業期間内に取得しうる有給休暇の日数である。休暇の合計を記入すると、計画工数に応じて適当に分配するように、計算式をセットしておく。

WBSでは「プロジェクト管理」という項目もあるが、これは独立した作業ではないため、線表では表せない。そこで、「プロジェクト管理」の工数も、休暇と同様に扱う。WBSから、プロジェクト管理の工数の合計を転記すると、計画工数に応じて適当に分配するように、計算式をセットしておく。

他の業務にかかる工数は、稼働率を記入すれば計算されるように、計算式をセットしておく。

線表日数には、実工数、管理工数、休暇、他業務の合計を表示するように、計算式をセットしておく。線表は、この線表日数に従って線を引く。

線表管理表を作っておくことで、WBSと線表を、矛盾なく併用することができる。

作業期間の実績について

ここでは、WBSと線表を併用して、プロジェクトを管理することを薦めた。WBSでは、作業工数の実績を記録した。線表では、作業期間の予定を示した。

だが、ここで紹介しているプロジェクト管理では、実際に作業を行った期間の実績については記録していない。むしろ、記録するべきではない、と考えている。

WBSを使う場合でも、表に予定期間や実績期間といった列を追加すれば、作業期間の予定と実績を比べられるように思えるかもしれない。

これを線表で表そうとすれば、次のようになるだろう。

また、メンバーごとの作業工数をまとめたWTTの表を、作業単位ごとに整理すれば、作業期間の予定と実績を比べて、期間上の遅れを示すことができるように思えるかもしれない。

だが、作業期間は、作業の順序によって変わる。また、作業期間のずれには、工数上の遅れと、期間上の遅れの、双方が影響する。そのため、作業期間の予定と実績を単純に比べても意味は無い。

更に、実際のソフトウェア開発では、１つのタスクを完全に終えてから、次のタスクに進む、ということは稀である。その結果、実際の開発プロジェクトでは、作業期間の記録は、下記のように分かりにくいものとなる。

この例では、テストの最後になって、仕様や設計にちょっとした問題が見つかったのだろう。こういうケースは珍しくない。

このような記録からは、このソフトウェア開発プロジェクトの進捗状況について、有用な情報は得られない。

予定した期間と、実際に作業した期間を並べて、日付のずれを見ながら「遅れている」「遅れていない」などと評価するのは、無意味なことだ。そのため、いつ何を作業したか、という作業期間の実績は、記録に残す必要は無いと考えている。