「問題はありません」。前回そう報告していたサブチームのリーダーが定例会議に青い顔をして座っていた。「タスクのほとんどが終わっていません。既に1週間単位の遅れが出ています」。利用部門の部長が長期出張へ立つ前にレビューを実施しなければならないドキュメントには、着手もできていないという。PMのEさんは天を仰いだ。

 突然の遅れが発生するのは、実作業を行うサブチームレベルのWBS(ワークブレークダウンストラクチャー:目的達成に必要なタスクを洗い出した一覧)に問題があるからだ。ケンブリッジ・テクノロジー・パートナーズの滝川佑次アソシエイトディレクターは「プロジェクトを回せるレベルに達していないWBSをよく見かける」と明かす。

 よくある悪い例が「××作成」「××確認」といった、1つのタスクの粒度が大きすぎる計画だ。しかも、そのタスクに割り当てている予定工数が非現実的。現場作業者の役に立たないうえ、タスクが期限を迎えたタイミングで突然PMに遅延が報告されるという困った代物だ。「ユーザーやPMに『計画を立てた』という報告をするため、体裁だけ整えて作るとそうなる」(滝川アソシエイトディレクター)。

 トラブルからの脱出は、WBSの組み直しが第一歩となる。滝川アソシエイトディレクターによると、駄目なWBSには3つの問題があるという。それぞれについて改善していくと、おのずと脱出の道筋は見えてくる。

遅れたチームのWBSを組み直す
突然遅れるタスクはサブチームレベルのWBSに3つの問題がある。PMが介入して計画の組み直しを実施する
[画像のクリックで拡大表示]

1つのタスクは3日以内に

 1つめは、タスクの粒度が大きすぎるという問題だ。特に1週間を超えるタスクは「その時点で論外」(滝川アソシエイトディレクター)というほど。タスクが大きいと、どこまで進んでいるのかがサブチームの外側から見えない。1週間を超えると毎週の進捗会議をまたぐことになるため、大きな遅れをPMが見逃すリスクが高まる。脱出法としては、大きなタスクを小さな複数のタスクに分割していく。滝川アソシエイトディレクターは「できるだけ1つのタスクは3日以内で完了できるように分割する」とアドバイスする。

 2つめはタスクの完了条件に抜け漏れがある問題だ。特に利用部門の承認レビューには注意が必要。必須プロセスの想定不足による遅れは、チームの頑張りでは挽回できない。脱出法としては、タスクの開始から完了までのプロセスを確認する。この際、会社やプロジェクトのルールと照らし合わせ、抜け落ちたプロセスがないかを確認する。

 3つめは工数の根拠がないという問題だ。全体スケジュールから逆算して書いただけという場合にこうなる。脱出法としては、タスクで誰がどのくらいの時間を使うのか、サブチームのリーダーが根拠を持って回答できるようにする。これはタスクの分割と同時に進めるとよい。