■ そのWBSは、どうやったら全てのタスクが終わるんですか？
前回は、要件定義フェーズという上流工程における「プロジェクト」のWBSを引いていきました。今回は、筆者が実際にWBSを作成していく際に留意している事項や、ちょっとしたスケジュール短縮のコツ（これをTipsという）を紹介していきたいと思います。
⇒「プロジェクトマネジメントの王道 WBSを作成する（1）WBSで管理すべきプロジェクトが何か分からないとWBSを理解できない！」
⇒「プロジェクトマネジメントの王道 WBSを作成する（2）上流プロジェクトの事例で実際にWBSを書いてみる！」
それでは、前回、実際に作成した、予算編成業務要件定義フェーズのWBSをご覧いただきます。
このWBSの作り方の手順は前回説明通りですが、手順だけで機械的に作成できれば、熟達のプロジェクトマネージャーは必要ありませんね。そういう彼らは、何か経験とコツを身につけているからこそ、彼らなりのプロジェクトを成功に導けるWBSが作成できるわけです。
（１）常にExitのことを考える！
WBSは、徹底して「ゴール思考」で作成します。自分で引いたWBSにまぶされたタスクのひとつひとつの終了条件を意識しながら、WBS上にタスクを置いていきます。そして、最後のタスクがきれいに仕上がること、これがこのプロジェクト全体の完了条件。最後よければすべてよし。従って、最後のタスクがもし予定通りに終わらなかったら、
①どういうコンティンジェンシープランがあるのか？
②プロジェクト途中できれいにフィニッシュできるかどうか、中間判断ポイントはあるのか？
③完了条件を変更するための代替案をきちんと考えているのか？
の3点について、予めWBS作成時に準備しておかなければならないのです。
■ そのWBSは、どういうフレームワークで構成されているんですか？
（２）最適なタスクの分解レベルを知る！
WBSで定義されるひとつひとつのタスクについて、どこまで細かく分解すればいいのでしょうか。「できる限り、分かる限り細かくしなさい。それがプロジェクトマネージャーの実力を表すものだから」と指導されることもあるかもしれませんが、不必要なまでに詳細化することは百害あって一利なしです。
筆者は次の3点に留意しています。
①Magic number 7の法則
アメリカの認知心理学者ジョージ・ミラーが1956年に提唱した理論で、人間が同時並列的に理解できる数（チャンク）は７±２というものです。これは、1週間が7日で、曜日ごとになら、好きなテレビ番組が何曜日に放送されるか記憶できる、という筆者の実体験からも、7つ以上のタスクは並列に置かないことをお勧めします。もし、7つ以上になりそうだったら、階層化できないか、括れるものを単純に横並びにしていないか、を疑います。さらに、どんな大規模プロジェクトでも、階層についても7つ以上はちょっと考えものでしょう。
②8-80時間の法則
1つのタスクは、時間軸の上で進捗管理をする必要があります。日次で進捗管理することもありますし、週次進捗会議で1週間まとめて仕事の進みっぷり（時には遅れっぷり）を評価して善後策を協議することになります。それゆえ、1日の作業時間を8時間とみなして、これを最小単位とします。これより細かいタスクの定義は、1日にやることが複数になって、管理倒れになる可能性が大です。一方、週次進捗会議でひとつのタスクが終わっているのか、半分まで行っているのか、大体の目安が分かり、リカバリ案を考えられるのも、ひとつのタスクの必要納期が5日から10日の間に無いと、感覚的に人間が直観で判断することが難しくなるでしょう。
③Last man standing の法則
人間って弱い存在です。自分には甘く、他人には厳しく。。。それゆえ、WBS上のタスクはできるだけ共同作業として設定するより、誰か一人の責任者を置ける単位にまで細かく（または粗く）設定することをお勧めします。自分の仕事になった瞬間、他人事から自分事になり、そのタスクの完了に対する責任感が違ってくるはずです。
（３）役割はどこまで分類するの？
上記の参考事例のチャートに示したのは、筆者にとっても知り得る限りの役割分担を記載したものになります。これを全て識別して、ひとつひとつのタスクに設定している例はあまりないでしょう。しかし、ひとつのタスクに対して、実行責任者（レビュイー）と、完了承認者（レビュワー）は必ず設定しておく必要があります。また、仮に一つのタスクについて、2人以上で当たる必要が生じた場合、「Last man standing の法則」で述べた通り、「実行責任者」と「サポーター」という役割分担も明確にしておくべきです。
タスク ≡ 責任範囲
という恒等式が成立する単位で、①タスクの粒度設定、②役割の定義を行うのが鉄則となります。
（４）遠い先のことは分かりませんが？
半年以上先の将来に、何が起こり得るか、全てを知り得る人はもはや人ではない、それは神でしょう。それゆえ、WBSを作成する際に、最後まで上記（２）（３）を考慮したタスクの粒度でWBS上のタスクを定義・設定することは難しいかもしれません。そういう場合は、上記（１）に対する最低限の配慮だけしておいて、終盤のスケジュールとタスクは粗く仮置きしておけばよいでしょう。WBSを用いてプロジェクト管理を進めていくうちに、いくつかの分岐点で判断したことで、終盤の仕事の有り様が見えてくることでしょう。そうなってから、上記（２）（３）を踏まえた粒度でタスクを置き直せばいいのです。
■ WBSがどうしても指示された期間に収まらないのですが、、、(>_<)/
一番手堅いプロジェクト管理の手法は、前工程がきちんと終わってから、次工程を開始することです。プロジェクト自体をこういう手順をきちんと踏まえて進める手法を「ウォーターフォール」形式のプロジェクトと呼びます。筆者は、数多くのプロジェクト進行の手法があることを知っていますが、やはりプロジェクト管理手法の王道は「ウォーターフォール」だと考えています。
そして、上司やお客様からある必達納期を申し渡され、いったんWBSを引いてみたものの、どうしてもスケジュールが納期通りに収まらない。まさにその時、プロジェクトマネージャーの力量がプロジェクト開始前から試されているのだと思います。こうした事態に遭遇した時、よくあるのが、前工程の完了日前に次工程の開始日を設定して、なんとなく帳尻を合わせたWBSを作ってしまうことです。
これは、プロジェクト開始前から、プロジェクト失敗の可能性を大きくする所作以外の何物でもありません。きちんと、上司やお客様に、納期がきついことを訴えるべきです。そうでないと、任されたプロジェクトのQ（品質）・C（コスト）・D（納期）の全てに責任を持つことはできません。それでも、上司やお客様から納期は動かせないと言われてしまったら、、、
それでは、プロジェクトマネージャーとしてできる最善は尽くしましょう。ここで、筆者のコツをお伝えします。それは「リード」の有効活用です。
「リード」とは前工程と次工程の時間的重なりを持つことです。これにより、プロジェクト全体のクリティカルパス（最小日程）を短縮することができます。しかし、次工程の開始条件を甘くして、なんとなく先行着手することを正式に認めることを意味していません。
次々工程のアウトプットまで考慮した成果物（次工程へのインプット）を定義し、次工程は、前工程が継続中から、断続的に作業開始が可能なインプット情報を細切れで手に入るように工夫するのです。当然、人の配置にも、そのインプット情報に対応したきめ細やかな配慮が必要になりますが。
もし、こうした工夫をしたうえでも、上司やお客様の希望納期を満たすことができない場合はどうするか？ 誠意をもって「できません」と答えるべきです。その上で、コストを積む（並行作業できる人員を増やすなど）と納期が守れるのか、資材納入日を前倒しすることで納期が守れるのか、きちんと自分が分かる範囲での「代替案」を毅然として提示することも忘れないでください。
コメント