WBS（Work Breakdown Structure：作業分解構成図）を作成するとき、何をどの粒度で書けばいいのか悩んだことはないでしょうか。
設計フェーズでは、設計成果物を作成する以外にも、課題検討や仕様変更対応といったタスクが発生します。
これらのタスクはWBSに入れるべきなのか、入れるべきでないのか。
大きなプロジェクトでは、複数のサブプロジェクトに分割して進めることがあります。
それぞれのサブプロジェクトでWBSのルールが違ってしまうと、全体の進捗状況が正しく見えなくなります。
あるチームは課題検討をWBSに入れ、別のチームは入れていない。
そうなると、進捗率の比較ができず、プロジェクト全体の状況把握が困難になります。
WBSに何を書くかのルールが曖昧なプロジェクトは、進捗管理の精度を失い、最終的にはプロジェクト全体の見通しを見失ってしまうことがあります。
PMOがルールを定めて周知徹底する
WBSの粒度やルールの問題を解決するために、必要なのが「PMOがルールを定めて周知徹底する」ことです。
例えば、課題については課題管理表に掲載しているものはWBSで重複管理しないというルールを設けます。
課題は発生タイミングも解決までの期間もまちまちであり、WBSのタスクとは性質が異なります。
課題管理表で一元管理し、WBSには載せないことで、管理の重複を避けることができます。
仕様変更については、変更管理プロセスに沿って変更が確定したものはWBSに追加するというルールを設けます。
仕様変更が発生した時点ではまだ作業内容が確定していないため、WBSには追加しません。
変更管理プロセスを経て正式に承認された後に、必要なタスクをWBSに追加します。
このようにルールが明確に決まっていれば、現場のメンバーは迷うことなくWBSを更新できます。
全てのサブプロジェクトでルールが統一され、プロジェクト全体の進捗状況を正しく把握できるようになります。
このルールについては以下の記事で詳しく解説しています。
課題検討や仕様変更をWBSに入れるべきではない理由
ルールがあっても漏れが発生する現実
しかし、ルールを定めても、タスク管理がうまくいかないケースがあります。
一つ目は、仕様変更に伴うタスクをWBSに追加することを忘れてしまうケースです。
変更管理プロセスで仕様変更が承認されても、その後のWBS更新を忘れてしまうことがあります。
特に忙しい時期には、変更管理で決まったことをWBSに反映する作業が後回しになりがちです。
結果として、タスクが漏れたまま進捗管理が行われ、後になって「この作業が終わっていない」と発覚することになります。
二つ目は、WBSに追加しなかった課題の検討がおろそかになるケースです。
課題管理表で管理すると決めた課題であっても、WBSに載っていないと進捗会議で取り上げられにくくなります。
WBSの確認に時間を取られ、課題管理表の確認が後回しになったり、そもそも確認されなかったりすることがあります。
つまり、ルールを定めただけでは不十分なのです。
WBSと課題管理表、変更管理一覧のそれぞれが連携して機能する仕組みを整えなければ、どこかで漏れが発生してしまいます。
定量的な管理と可視化の仕組みを整える
こうした問題を防ぐためには、課題管理表や変更管理一覧についても、定量的に管理し可視化することが重要です。
WBSと課題を重複管理しないと決めたのであれば、両方のタスク消化状況をしっかりチェックする仕組みを整えます。
WBSのタスク消化状況だけでなく、課題管理表の消化状況も同じタイミングで確認することで、課題検討の遅れを見落とさないようにします。
変更管理に関しては、仕様変更が決まったものがWBSに反映されているかをチェックする仕組みを整えます。
変更管理一覧とWBSを突き合わせ、反映漏れがないかを定期的に確認します。
具体的には、WBS、課題管理表、変更管理一覧のそれぞれについて、同じ締切日を設け、PMOが同じタイミングでチェックするのがよいでしょう。
チェックは週1回で十分です。毎週決まった曜日に各チームが更新を完了、PMOが集計・可視化してチェックする。
このサイクルを回すことで、タスクの遅れや漏れを早期に発見できます。
もちろん遅れが目立ってきた、課題や仕様変更が大量に発生し進捗リスクがある、このような場合は週１回にこだわらず、週３にしてもいいですし、朝会・夕会などかなり頻度高く確認するべきです。
WBSだけを見ていると、課題検討の遅れや変更反映の漏れに気づけません。
3つの管理対象を同時にチェックすることで、プロジェクト全体の状況を正確に把握できるようになります。
仕組みを機能させるためのポイント
このアプローチを実践する上で、いくつか重要な注意点があります。
まず、PMOの集計・可視化作業に何日もかけるわけにはいかないという点です。
週一回のチェックを行うためには、集計・可視化作業を効率化する必要があります。
Excelのマクロやスクリプト、あるいは専用のプロジェクト管理ツールを活用して、できるだけ自動化することが重要です。
手作業での集計やグラフ作成に時間を取られると、本来のチェック業務に時間を割けなくなります。
次に、更新漏れや提出漏れがあると仕組み自体が機能しないという点です。
どれだけ良い仕組みを作っても、各チームがルール通りに更新してくれなければ意味がありません。
仕組みを導入する際には、目的・効果をしっかり納得してもらうことが重要です。
「なぜこのルールが必要なのか」「守らないとどうなるのか」を丁寧に説明し、メンバーの理解を得ることが、運用を定着させる鍵となります。
そして、定期的にリマインドすることも欠かせません。
最初は守られていたルールも、時間が経つと忘れられがちです。締切前のリマインドを定期的に行い、ルールの存在を意識し続けてもらうことが大切です。
WBSだけでなく全体を見渡す視点
WBSにどのようなタスクを入れるべきかという問いに対する答えは、プロジェクトの方針や規模によっても異なります。
重要なのは、ルールを明確に定め、そのルールに基づいて漏れなく管理できる仕組みを整えることです。
課題をWBSに入れないと決めたなら、課題管理表の消化状況も同時にチェックする。
仕様変更は確定後にWBSに追加すると決めたなら、反映漏れがないかをチェックする。
WBS単体ではなく、課題管理表や変更管理一覧と合わせて、プロジェクト全体を見渡す視点が必要です。
ルールを定めるだけでなく、そのルールが守られているかをチェックし、漏れがあれば早期に発見して対処する。
こうした仕組みを整えることで、WBSのルールが曖昧で進捗を見失うという問題を防ぐことができます。
