スケジュール管理：　WBSのサンプルのダウンロード

こんにちは、経営コンサルタントの入野です。

15000人月以上の合併プロジェクト、2000人月規模のシステム開発プロジェクト、ベンチャーの新規事業立ち上げまで、様々なプロジェクト管理を経験させていただきました。

「WBS(Work Breakdown Structure)のサンプルないですか？」

よくこんな質問をよくされます。

プロジェクト管理におけるスケジュール作成・進捗管理のコツをまとめ、
WBSのサンプルをダウンロード提供させていただきます。

プロジェクト管理におけるスケジュール作成・進捗管理の位置づけ

プロジェクト計画書の目次は一般的には次のとおりです。

1. プロジェクトの経緯
2. ゴール
3. スコープ
4. スケジュール
   • マスタースケジュール
   • WBS (Work Breakdown Structure)
5. プロジェクト体制
   • 体制図
   • 役割
   • 会議体
6. プロジェクト予算
   • コスト見積もり
   • 定量的効果
   • 定性的効果
7. プロジェクト管理プロセス
   • 進捗管理
   • 課題管理
   • 品質管理
   • 障害管理
   • 文書管理
   • リスク管理
   • スコープ管理/変更管理
   • 予算管理/調達管理/契約管理
   • 各種管理票サンプル　etc

スケジュール作成・進捗管理のコツ

プロジェクト管理においてスケジュール作成や進捗管理を行う場合に、
PM(プロジェクトマネージャ)やPMO（プロジェクト管理事務局）がハマりやすい落とし穴やツボを簡単にまとめます。

タスク間の依存性には４つのタイプがあります。
↓

Finish to Startのタイプしか載っていないWBSをよく見かけます。
すべての矢羽がきれいな階段状になっいるのでとても美しいWBSです。

しかし、タスク依存性はFinish to Startだけではありません。

意外と多い間違いは、実際にはStart to StartなのにFinish to Startだと勘違いしてしまうケース。

must Finish task A to Start task B
＝ 「タスクBを着手するためには、タスクAが完了されていなければならない」

must Start task A to Start task B
＝ 「タスクBを着手するためには、タスクAが着手されていなければならない」

両タイプともタスクBの着手のタイミングがポイントであるのは同じですが、
Start to StartをFinish to Startと間違うと、
タスクBの着手のタイミングが遅れてしまいます。

なぜタスクBの着手が遅れるのかというと、
must Start task A to Start task B
＝ 「タスクBを着手するためにはタスクAが着手されていなければならない」
≒
「タスクAの完了をわざわざ待たなくても、タスクAが着手さえされていれば、
早めにタスクBを着手できる」

つまり、Start to StartをFinish to Startだと勘違いすると、
タスクBをもっと早く着手できるのに、わざわざタスクAが終わるのを待ってしまって時間をムダにするのです。

「本当にFinish to Startか？」と疑ってみるだけでも、時間短縮のチャンスが見つかるかもしれません。

Finish to Startは４つのタイプのうち、１番時間がかかるタスク依存性なので。

クリティカルパスの定義はプロジェクト管理をする者ならば誰でも知っています。
でも、実際で有効に使っている人は結構少ないです。

原因は、フェーズに区切られたウォーターフォール型のシステム開発プロジェクトが多く、概要レベルで見るとクリティカルパスは一見明白だから。

「クリティカルパスはどこですか？」と私が質問すると
「フェーズ1→フェーズ2→フェーズ3→フェーズ4 がクリティカルパスです。」と答えるPMもいます。

確かに、概要レベルのクリティカルパスとしては正解です。

しかし、クリティカスパスでの遅延が発生する場所はあくまでも詳細なタスクレベルです。

マスタースケジュール図などの概要レベルではなく、WBSなどの詳細なレベルでクリティカルパスを特定することが重要です。

詳細レベルで見ると、クリティカルパスは複雑で、遅延が発生すると変化することもあります。

クリティカルパスの自動計算機能があるので、MS-Projectなどのプロジェクト管理ツールはできるだけ使いましょう。

PMの勘とは違った意外な計算結果が出ることもあります。

• プロジェクト管理計画書の作成タスク
• 進捗会議の準備タスク

などのPM自身が費やす工数や時間が十分に想定されていないケースです。

「PMの仕事も大変なんです・・・」と言えないPM自身のプライドや照れが原因の場合もあります。

プロジェクトの規模や性質にもよるので一概には言えませんが、目安としては、プロジェクト全体工数のうちの5～15%はプロジェクト管理工数を想定するべきです。

PMが一人でゼロからタスクを抽出してしまうケースです。

ゼロから作成するアプローチ以外にも
現実的なスケジュールを作成する際のアプローチにはいくつかあります。

• 似たようなプロジェクトを参考にする
• 各メンバーに詳細タスクを抽出してもらって積み上げる
• 業務領域の専門家にレビューしてもらう
• 成果物の一覧から逆算してタスクを抽出する
• 業務領域の専門家にレビューしてもらう

特に、組織あるいは個人として過去に経験のあるプロジェクトの場合は、恥も外見も捨てて、古いスケジュールをパクリましょう。
なぜなら、

• 過去の実績はヘタな見積よりも数十倍も精度がいいから
• 過去の実績はどの部分がムリな計画になりやすいかを教えてくれるから

タスクの進捗状況の確率分布はこんなイメージです。
↓

上級者は以下のような考え方をします。

• • タスクは遅延することはあっても先行することはほとんどないという現実を受け入れる

• • 「遅れるリスクを考えるより、遅れないようにがんばれ」という精神論や空気を作らない

• • 予定と実績のブレを統計的に分析して、スケジュールバッファーを設定する

• • スケジュールバッファーを置く場所をよく考える
    – 各タスク and/or フェーズの最後
    – クリティカルパス上 and/or フロートタスクのあと

• スケジュールバッファーの長さをよく考える
  – 遅延実績の平均値 or メジアン or モード
  – 管理しやすいキリのいい数字：10日,5日 etc

90%シンドロームとは、こんなイメージです。
↓

例えば、
「タスクAは90%完了しています」という週次報告を受けたが、次の週になっても、その次の週になっても、残りの10%の進捗がなかなか進まず、結局は遅延してしまうという経験はないでしょうか？

経験のあるPMは以下のような報告の仕方を徹底させます。

• • 「やったこと」よりも「残っていること」を報告するように徹底させる
    報告者の心理はやったこと（≒自分の努力）を認めてほしいという気持ちが強いので「自分がどれだけやったか」を報告しがちですが、進捗を把握する上で重要なのは「何が残って、何日かかるか」であるので。

• 進捗率の逆行も報告するように徹底させる
  特に、トライアンドエラー型のタスクは、実行してはじめて残タスクが判明することが多いので。

  

本日は以上です。

入野

WBSのサンプルのダウンロード

クリティカルパスの分析ができるので、できればMS-Projectを使ってほしいのですが、 Excelを使うのがまだ世の中では一般的なのでExcelの3か月WBSをダウンロード提供します。

ウェブサイト開発プロジェクトを想定したシンプルなサンプルです。