システム開発プロジェクトでWBS（Work Breakdown Structure：作業分解構成図）を作成する際、ふとこんな疑問が浮かぶことはないでしょうか。
「課題検討や仕様変更対応のタスクは、WBSに入れるべきだろうか？」
設計成果物を作成する作業は当然WBSに含めますが、プロジェクト進行中に発生する課題検討や仕様変更対応といった、成果物以外のタスクをどう扱うべきか。とりあえずWBSに入れておけば忘れないだろうという考えもあれば、WBSが膨大になってしまうという懸念もあります。
この判断は、プロジェクトの進行管理の質を大きく左右する重要なポイントです。
とりあえずWBSに入れておくという判断
現場では、課題検討や仕様変更対応が発生した時点で、「とりあえずWBSに入れておく」というアプローチを取ることが多く見られます。
「xx課題の検討・対応」「xx仕様変更対応」といったタスク名でWBSに登録し、とりあえず管理対象に含めておく。こうすることで、少なくとも課題や仕様変更の存在を忘れずに済むという考え方です。
このアプローチの最大のメリットは、忘れないこと、いつか思い出せることにあります。WBSを定期的に棚卸すれば、登録したタスクを思い出すきっかけになります。特に小規模なプロジェクトでは、WBS全体の量も限られているため、このメリットを十分に享受できます。定期的なWBSレビューで、「そういえばこの課題はどうなった？」と気づくことができるのです。
このスタンス自体は決して悪いものではありません。忘れてしまうよりは、どこかに記録しておく方が確実に良いでしょう。
ただし、プロジェクトの規模が大きくなると、この方法には大きな問題が潜んでいます。
WBSに入れると見えなくなる現実
大規模プロジェクトでは、このアプローチが深刻な問題を引き起こします。
第一に、WBS自体が膨大になり棚卸ができなくなります。大規模プロジェクトでは、WBS自体が数百、時には1,000を超えるタスクを管理している場合もあります。そのような状況では、WBS全体を見渡すことすら困難です。どうしても先行着手や遅延が多く発生していて、「今週作業するべき作業」や「完了期限が近い作業」といった目先の作業の管理に追われてしまいます。
第二に、課題検討や仕様変更のタスクがおざなりになります。発生時点でWBSに入れる場合、着手予定や完了期限は仮で入れてしまうことが多く、期間も長く取りがちです。ゴールへの道筋やゴールまで導く担当者、解決期限が不明確な状態でタスクを切ってしまうため、結局その作業自体がおざなりになってしまいます。
目先の作業に追われている状況では、課題検討や仕様変更の作業をウォッチするという意識がどうしても希薄になるのです。
第三に、WBSのステータスがなかなか動きません。仕様変更要望が来た時点でWBSに追加しても、結局やるのかやらないのか、具体的な仕様は何かというところからスタートになります。課題検討も同様で、検討の方向性すら決まっていない状態でWBSに登録しても、タスクのステータスを更新できる状態ではありません。
その結果、工程の後半になって初めて、大きな課題が残されていたことに気付く、仕様変更の取込が間に合わないといった事態が発生してしまいます。小規模プロジェクトで有効だった「忘れないためにWBSに入れる」というメリットは、大規模プロジェクトでは完全に薄れてしまうのです。
課題一覧と仕様変更一覧で管理するという方針
私は、課題検討や仕様変更対応は、それぞれ専用の一覧で管理し、成果物への影響が明確になってからWBSに登録するという方針を推奨しています。
ただし、すべての課題や仕様変更をWBSから除外するわけではありません。重要なのは、WBSに登録するタイミングを見極めることです。
第一に、課題検討は課題一覧で管理します。進め方やゴール設定、担当者がまだ不明確なうちは、WBSではなく課題一覧で管理することが大事です。課題一覧上で、課題の進め方、ゴール設定まで検討し、対応方針が決まれば、影響する成果物が明確になってきます。そのタイミングで初めて、成果物単位でWBSに作業を登録します。
例えば、「データ移行方式の検討」という課題があったとします。この段階では、どんな検討が必要で、どの成果物に影響するかも不明確です。課題一覧で検討を進め、「既存データの整合性チェック仕様書を作成する」という対応方針が決まった時点で、該当する設計書の作成タスクとしてWBSに登録するのです。
第二に、仕様変更も同様に仕様変更一覧で管理します。仕様変更を取り込むことが確定し、要件整理が完了するまでは仕様変更一覧で管理します。そこまで進めば、成果物単位でWBSに登録することができるため、以降は仕様変更NoとともにWBSで進捗管理します。
もちろん、WBSに登録する際には、その作業の発生起因がどの課題・仕様変更であることがわかるよう、課題Noや仕様変更Noとともにレコード追加しておくことが大切です。こうすることで、トレーサビリティが確保されます。
第三に、専任の担当者を配置します。このプロセスでは、課題一覧や仕様変更一覧の定点チェックが必要になりますが、これは各一覧について、デイリーで課題や仕様変更検討の対応状況を点検することをミッションとする担当者を置くようにします。
この方針の最大のメリットは、管理すべき対象が明確に絞り込まれることです。WBS全体で見るより明らかに管理するべき対象が少ないため、おざなりになることなく推進することが可能です。また、成果物への影響が明確になってからWBSに登録するため、WBS上のタスクは常に具体的で実行可能な状態を維持できます。
忘れてはいけない運用上の注意点
この方法を実践する上で、いくつか重要な注意点があります。
まず、専任担当者をバイネームで決めることが必須です。課題一覧や仕様変更一覧について、デイリーで状況をウォッチする担当者を明確に決め、それを正式なミッションとして位置づけます。「誰かが見るだろう」「課題ごとの担当者が見るだろう」といった曖昧なやり方では、うまく機能しません。
例えば、週次の進捗会議で課題一覧を確認するという運用では、頻度が不十分です。デイリーでチェックする専任担当者がいることで、初めて課題や仕様変更の検討が停滞することを防げます。
次に、一覧からWBSへの移行を確実に実施することです。一覧上で対応方針が決まり、成果物にまで落とし込めた時点で、WBSに登録することを忘れないことが大事です。課題一覧でゴール設定まで行ったが、WBSに入れなかったことで実際の対応を忘れたというケースもよく見られます。
課題一覧をウォッチしている担当者は、WBSに登録されていることまでしっかり見届け、課題をいったんクローズすることが大切です。そのために、前述した課題No、仕様変更NoをWBSに記載しておくことがとても大切になります。これにより、「この課題は既にWBSに登録済み」という確認ができるのです。
最後に、二重管理の手間を恐れないことです。課題一覧・仕様変更一覧とWBSの両方で管理するのは手間に感じるかもしれません。しかし、この手間こそが、大規模プロジェクトで課題や仕様変更を確実に追跡するための必要なコストなのです。
管理の仕組みを使い分ける
課題検討や仕様変更対応は、発生時点ですぐにWBSに入れるべきではありません。それぞれ専用の一覧で管理し、成果物への影響が明確になった段階で、初めてWBSに登録すべきです。
「とりあえずWBSに入れておく」というアプローチは、小規模プロジェクトでは有効ですが、大規模プロジェクトでは管理が破綻します。WBSが膨大になり、目先の作業に追われる中で、重要な課題や仕様変更が埋もれてしまうのです。
課題一覧・仕様変更一覧という専用の管理の仕組みを使い分けることで、それぞれの状況を確実に追跡できます。そして専任担当者を配置することで、おざなりになることを防げます。
ただし、何でもかんでも一覧で管理すればよいわけではありません。成果物への影響が明確になったら、必ずWBSに移行し、課題Noや仕様変更Noとともに記録する。このルールを徹底することが重要です。
完璧な正解はありませんが、プロジェクトの規模や状況に応じて管理の仕組みを使い分けるという姿勢こそが、確実な進行管理を実現する鍵なのです。
