WBSを使い分けよう

WBS とは Work Breakdown Structure の略で、プロジェクトの作業を詳細に分割したものです。それを基に見積りを行ったり、ガントチャートなどのスケジュール表に展開し、進捗管理に使用します。システム開発プロジェクトに携わった方であれば、ご覧になったことがあるのではないでしょうか。

※ 当コラムではガントチャートなどのスケジュール表も包含して WBS と表現しています。厳密には別のものですが、現場では一括りに「 WBS 」と表現することが多いからです。

私は多くのシステム開発プロジェクトやシステム保守に携わる中で、自分で WBS を作成したり、別の方が作ったものを見てきました。そのような経験から、プロジェクトの規模や特性によって WBS を使い分ける必要があるという事を学びました。

以下に二つの例を挙げてみたいと思います。

１．大規模システム開発における WBS

まず、大規模な新規システム開発プロジェクトのおける WBS のあるべき姿を考えてみます。

1-1. 作業を抜け漏れなく洗い出す

新規プロジェクトの発足時点では不明確なことが多く、 WBS 作成においては、作業を出来る限り抜け漏れ無く洗い出して可視化することが重要です。

作業の量はそのままコストと工期に影響します。必要な作業を漏らせば、予算オーバーや期日の遅れにつながります。また、品質保証の作業が漏れれば、品質低下を招くでしょう。

できれば一から作るより、類似プロジェクトの WBS を参考にする、テンプレートがあればそれを活用するなどして、先人の知恵を借りましょう。

また、一人で作り上げようとせず、有識者/プロジェクトメンバーから意見を聞いたり、レビューを開催したりしましょう。

1-2. 詳細な作業まで分割する

新規開発においては、一から開発する成果物が多く、一つの機能開発に比較的長い期間が必要です。中核となる重要な機能の開発に数か月かかる場合もあるでしょう。それらの作業が、1本のなが～い WBS にならないよう、注意しましょう。作業着手2か月後になって、やっと大きな遅延が表面化した・・・などという事になりかねないからです。

一つの作業は、1～2週間に収まる程度まで分割するのがよいでしょう。そうすればすぐに遅延に気が付きます。

設計書/プログラムのレビューも WBS を分割します。作業の担当者任せでは、人によってはレビューが行われておらず品質に問題が・・・などという事になりかねません。また、無計画にレビューを行うと、リーダーや有識者にレビューが集中してボトルネックとなり、作業が進まなくなるという事態が起こりがちです。そうならないよう、いつ誰が何のレビューを行うのかを計画しましょう。

1-3. 個別の作業に余力は取りすぎない/取らない

一つ一つの作業の見積工数に×1.X倍などして、余力(いわゆるバッファ)を取るケースが見られますが、これはあまり良い策ではありません。作業の担当者は、提示された工数・工期に沿って進め、余裕を使い切ってしまう傾向があるからです。これでは、余力を無駄に食いつぶしているだけです。

また、問題や遅延はどの作業で発生するか分かりません。その都度実態に合わせて WBS を調整するのは、管理の手間となるでしょう。

個別の作業については余力は取らず、プロジェクト全体としてまとまった予備期間を設けるという手法があります。各作業については当初の見積工数に則って作業を進めてもらう。ただし、遅延した場合や、想定外の作業が発生した場合、その予備期間を使ってフォローするという考え方です。

実際のプロジェクトではそのような余力は取れませんよ！と言われてしまいそうですが、個別の作業に余力が取れるのであれば、その割当先を変えればよいということです。

２．システム保守における WBS

上記のあるべき姿はあらゆるプロジェクトに活用できるでしょうか。答えは否です。次は、システム保守における WBS のあるべき姿を考えてみます。

※ システム保守とは、既に存在するシステムについて、維持・改善のための改修や障害対応を行う体制を指します。

2-1. WBS を細かい作業まで引かない

システム保守では、システムの調査や障害対応などの割り込み作業が不定期に発生します。厳密な WBS を引いてもその通りに進行しないことが多く、細かければ細かいほど、調整に多くの時間を要します。

そもそも、既存プログラムの小規模改修が多く、それぞれの作業は1～2週間ほどに収まるものが多いでしょう。また、新規開発と比較して、作業の見積工数と実態が大きく乖離することは多くありません。

各担当者の作業が抜け落ちないように細かく WBS を引くより、作業を標準化し、各種の作業フローやチェックリストを整備するほうが効率がよく、品質向上にも役立ちます。

2-2. タスク毎に余力を取る

システム保守においては、作業毎に余力を取ることも必要であると思います。

上記したとおり、システムの調査や障害対応はいつ発生するか分からず、突発的に割り込んできます。これらに対処する度に他の作業の期日が遅れていくのは問題になりますし、都度スケジュールを調整するのは管理の負荷になりますから、ある程度、余力を見込んだスケジュールを引いておくべきです。

また、各種レビューは管理者が前もってスケジューリングするより、担当者同士が調整して実施するほうが効率的です。スケジュールにはそのための時間を含んでいることを担当者に伝え、動いてもらうのがよいでしょう。

余力は、リーダークラスであれば各種調整・レビューなどで時間を取られるので多めに。自分のタスクに集中できる担当者であれば少なめに。担当者の役割によって余力の割り当てを変えるのが良いと思います。

まとめ

このように、プロジェクトの規模や特性によっては真逆の考え方で WBS を作成・管理したほうが、うまくフィットします。

また、システム保守といっても、その中で並行して中規模以上の新規機能開発が行われることがよくあります。このような場合は、上記の大規模システム開発における WBS の考え方を取り入れる必要があります。

臨機応変に組み合わせる必要があるのです。

多くのプロジェクトで使われている WBS ですが、ご利用の WBS が最適なものか。今一度見直してみるのはいかがでしょうか。