ステータス管理で細分化を抑えるアプローチ
細分化を抑えるアプローチの1つとして、WBSのタスクは粗く分けて、進捗の詳細をステータスで管理するというやり方があります。
具体的には、設計書1本につき「作成」と「顧客レビュー」の2タスクに集約します。
「作成」タスクは担当者の執筆開始から社内レビュー完了まで、「顧客レビュー」タスクは初回レビュー提出から顧客承認までをカバーします。
細かいプロセスの進行状況は、ステータス項目で表現します。
「作成」タスクなら「未着手」→「作成中」→「社内レビュー中」→「社内レビュー完了」といった形です。
複数のレビューステップがある場合は、そのレビューごとにステータスを分けることもできます。
このアプローチの最大のメリットは、成果物ごとのステータス集計がしやすく、進捗報告がまとめやすくなるという点です。
WBSの行数も抑えられるため、全体を俯瞰して理解しやすくなります。
1週間以内で社内レビューまで完了するようなボリュームであれば、ステータスも「未着手」→「作成中」→「社内レビュー完了」の3段階で十分かもしれません。
作業のボリュームに応じて柔軟に調整できる点も、このアプローチの利点です。
粗い管理で実態が見えなくなる落とし穴
しかし、このアプローチにも問題があります。
特に問題になるのが、長期にわたる設計書作成で作業実態がわからなくなるということです。
2週間も3週間もかかるような大きな設計書の場合、ステータスをあまり簡略化すると実態が分からなくなります。
例えば、進捗会議で状況を確認しても、ずっと「作成中」のままで、今どこで止まっているのか、一目では理解できません。
「作成中とのことですが、具体的にはどの段階ですか？」 「セルフレビューに入っています」 「いつからセルフレビューですか？」 「1週間前からです」
このような確認を毎回行わなければならず、結果として進捗の遅延を見逃すことになります。
ステータスが「作成中」のままで2週間が経過していても、それが正常なのか異常なのか判断できないのです。
以前担当したプロジェクトでは、50本の設計書すべてを「未着手」「作成中」「完了」の3ステータスで管理していました。
2週間後の進捗会議で確認すると、30本が「作成中」のままでした。
個別にヒアリングしてみると、実は10本はまだ書き始めたばかり、5本はセルフレビューで行き詰まり、3本はチームリーダーレビューで大幅な手戻りが発生していたのです。
ステータスが粗すぎたために、これらの問題を早期に発見できませんでした。
では、ステータスを細かくすれば安心かといえば、注意が必要です。
たとえばいつまでに「社内レビュー」を開始できていればいいのかという期日が表現できないため、そろそろ社内レビューに行かなくて大丈夫か、予定通り始められるか、といった状況を注意深く観察する必要があります。
また、開始-終了期間も1週間程度に納めておくべきでしょう。
組織とプロジェクトの特性で粒度を決める
では、どのように細分化の粒度を決めるべきでしょうか。
重要なのは、その組織の文化、メンバーの自己管理能力、プロジェクト特性（求められる管理の厳格さ）、働き方の形態によって判断するということです。
それぞれについて見ていきます。
第一に、組織文化としての報告習慣です。
細やかな作業報告をすることに慣れている組織なのか、それともそのような文化がない組織なのか。
日次で進捗を更新する習慣がある組織であれば、細かいステータス管理も機能します。
一方で、普段からあまり細かく管理せず、週次で報告をするということが基本の組織だとすると、無理に日次更新を求めても、更新が追いつかず形骸化するだけです。
より細かい管理を求める場合は文化として浸透するまで粘り強くフォローする必要があります。
第二に、メンバーの自己管理能力です。
作業の締め切りを意識してくれて、遅れる場合は自発的に報告するようなメンバーが揃っているなら、管理粒度はある程度粗くて構いません。
逆に、マイクロマネジメントをしてあげないと遅延に気づかないメンバーが多い場合は、細かいステータス管理が必要です。
第三に、プロジェクトの特性です。
わずかな遅延も許されないような厳格なスケジュール管理が求められるプロジェクトなのか、ある程度の柔軟性があるプロジェクトなのか。
前者であれば細かい管理が必要ですし、後者であれば粗めの管理でも問題ありません。
ここまで挙げた３つの管理粒度選択の観点のうち、最も決定的な観点となります。
第四として、働き方の形態も重要な判断材料になります。
同じ場所で働いていて毎日のコミュニケーションが密である場合は、管理粒度を粗くしても問題が起きにくいです。
日常会話の中で「今日はセルフレビューに入りました」「チームリーダーレビューで指摘が多くて困っています」といった情報が自然に共有されるためです。
逆に、リモートでお互いの作業状況が見えないようなプロジェクト形態なら、細かい管理をしたほうが良いでしょう。
ステータスやWBSが唯一の情報源になるため、そこに十分な情報が含まれている必要があります。
管理を細かくすればするほど手間がかかります。
必ず可視化するメリットとのトレードオフがあるという点を忘れてはいけません。
見落としがちな2つの失敗パターン
この方法を実践する上で、特に注意すべき失敗パターンが2つあります。
まず、細かくしたはいいが更新が追いつかないパターンです。
ステータスを10段階に分けたものの、担当者がこまめに更新する習慣がなく、結果として正しい状態を表していない状況になるケースです。
「詳細設計レビュー中」のステータスのまま2週間放置され、実際には既に顧客レビューに進んでいた、といった事態が発生します。
細かい管理を導入する際は、必ず更新のルールと頻度を明確にし、それが実行可能かを検証する必要があります。
例えば、毎週金曜日の16時までに全員がステータスを更新する、といったルールを設定し、守られているかを確認します。
次に、長期タスクで粗い管理をするパターンです。
開始から終了まで2週間以上かかる設計書作成で、「未着手」「作成中」「完了」の3ステータスしか用意しないケースです。
これでは進捗の実態が見えず、遅延の早期発見ができません。
長期タスクの場合は、たとえ管理工数が増えても、ある程度細かいステータスを設定すべきです。
最低でも「執筆中」「セルフレビュー中」「社内レビュー中」「顧客レビュー中」程度の粒度は必要でしょう。
また、そもそも、以下の記事の「日常的な進捗確認の仕組みを構築する」のパートで説明しているとおり、WBSの分割を検討したほうがよいかもしれません。
参考記事： 進捗の真偽を確かめようとするPMOが失敗する理由 ( https://www.j-q.co.jp/jq-note/knowledge08/ )
状況に応じた最適な粒度を見極める
設計成果物の進捗管理において、細分化の粒度に絶対的な正解はありません。
細かく管理すれば遅延を早期に発見できますが、管理工数が膨大になり、更新が追いつかなくなるリスクがあります。
粗く管理すれば工数は削減できますが、長期タスクで実態が見えなくなり、問題の発見が遅れます。
重要なのは、組織文化、メンバーの自己管理能力、プロジェクトの特性、働き方の形態という複数の要素を総合的に判断するということです。
完璧な管理方法はありません。
しかし、自分たちのプロジェクトに何が必要で、何が過剰なのかを見極める姿勢こそが、進捗管理を機能させる鍵となります。
