スケジュール管理: WBSのサンプルのダウンロード
こんにちは、経営コンサルタントの入野です。
15000人月以上の合併プロジェクト、2000人月規模のシステム開発プロジェクト、ベンチャーの新規事業立ち上げまで、様々なプロジェクト管理を経験させていただきました。
「WBS(Work Breakdown Structure)のサンプルないですか?」
よくこんな質問をよくされます。
プロジェクト管理におけるスケジュール作成・進捗管理のコツをまとめ、
WBSのサンプルをダウンロード提供させていただきます。
プロジェクト管理におけるスケジュール作成・進捗管理の位置づけ
プロジェクト計画書の目次は一般的には次のとおりです。
- プロジェクトの経緯
- ゴール
- スコープ
- スケジュール
- マスタースケジュール
- WBS (Work Breakdown Structure)
- プロジェクト体制
- 体制図
- 役割
- 会議体
- プロジェクト予算
- コスト見積もり
- 定量的効果
- 定性的効果
- プロジェクト管理プロセス
- 進捗管理
- 課題管理
- 品質管理
- 障害管理
- 文書管理
- リスク管理
- スコープ管理/変更管理
- 予算管理/調達管理/契約管理
- 各種管理票サンプル 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は4つのタイプのうち、1番時間がかかるタスク依存性なので。
クリティカルパスの定義はプロジェクト管理をする者ならば誰でも知っています。
でも、実際で有効に使っている人は結構少ないです。
原因は、フェーズに区切られたウォーターフォール型のシステム開発プロジェクトが多く、概要レベルで見るとクリティカルパスは一見明白だから。
「クリティカルパスはどこですか?」と私が質問すると
「フェーズ1→フェーズ2→フェーズ3→フェーズ4 がクリティカルパスです。」と答えるPMもいます。
確かに、概要レベルのクリティカルパスとしては正解です。
しかし、クリティカスパスでの遅延が発生する場所はあくまでも詳細なタスクレベルです。
マスタースケジュール図などの概要レベルではなく、WBSなどの詳細なレベルでクリティカルパスを特定することが重要です。
詳細レベルで見ると、クリティカルパスは複雑で、遅延が発生すると変化することもあります。
クリティカルパスの自動計算機能があるので、MS-Projectなどのプロジェクト管理ツールはできるだけ使いましょう。
PMの勘とは違った意外な計算結果が出ることもあります。
- プロジェクト管理計画書の作成タスク
- 進捗会議の準備タスク
などのPM自身が費やす工数や時間が十分に想定されていないケースです。
「PMの仕事も大変なんです・・・」と言えないPM自身のプライドや照れが原因の場合もあります。
プロジェクトの規模や性質にもよるので一概には言えませんが、目安としては、プロジェクト全体工数のうちの5~15%はプロジェクト管理工数を想定するべきです。
PMが一人でゼロからタスクを抽出してしまうケースです。
ゼロから作成するアプローチ以外にも
現実的なスケジュールを作成する際のアプローチにはいくつかあります。
- 似たようなプロジェクトを参考にする
- 各メンバーに詳細タスクを抽出してもらって積み上げる
- 業務領域の専門家にレビューしてもらう
- 成果物の一覧から逆算してタスクを抽出する
- 業務領域の専門家にレビューしてもらう
特に、組織あるいは個人として過去に経験のあるプロジェクトの場合は、恥も外見も捨てて、古いスケジュールをパクリましょう。
なぜなら、
- 過去の実績はヘタな見積よりも数十倍も精度がいいから
- 過去の実績はどの部分がムリな計画になりやすいかを教えてくれるから
上級者は以下のような考え方をします。
- タスクは遅延することはあっても先行することはほとんどないという現実を受け入れる
- 「遅れるリスクを考えるより、遅れないようにがんばれ」という精神論や空気を作らない
- 予定と実績のブレを統計的に分析して、スケジュールバッファーを設定する
- スケジュールバッファーを置く場所をよく考える
- 各タスク and/or フェーズの最後
- クリティカルパス上 and/or フロートタスクのあと - スケジュールバッファーの長さをよく考える
- 遅延実績の平均値 or メジアン or モード
- 管理しやすいキリのいい数字:10日,5日 etc
例えば、
「タスクAは90%完了しています」という週次報告を受けたが、次の週になっても、その次の週になっても、残りの10%の進捗がなかなか進まず、結局は遅延してしまうという経験はないでしょうか?
経験のあるPMは以下のような報告の仕方を徹底させます。
- 「やったこと」よりも「残っていること」を報告するように徹底させる
報告者の心理はやったこと(≒自分の努力)を認めてほしいという気持ちが強いので「自分がどれだけやったか」を報告しがちですが、進捗を把握する上で重要なのは「何が残って、何日かかるか」であるので。 - 進捗率の逆行も報告するように徹底させる
特に、トライアンドエラー型のタスクは、実行してはじめて残タスクが判明することが多いので。
※課題管理に興味のある方は以下の記事もご参照ください。
↓
課題管理:「ガーベージコレクターとは?」
セミナーのお知らせ
『事業計画作成のテクニック』
日本政策金融公庫にて講演します。
↓
日時:2010年7月9日(金)14:00-15:30
会場:日本政策金融公庫 東京中央支店
【終了いたしました】
100名近い方のご来場ありがとうございました。
| エグゼクティブサマリー プレゼンテーション |
||
|---|---|---|
| マネジメントチーム 経営理念 |
||
| 市場分析 競合分析 ビジネスモデル 営業マーケティング |
||
| 人事戦略 成長戦略 |
||
| 資金調達 資本政策 |
||
| 立ち上げ戦略 | ||
| プロジェクト管理 | ||
| 事業計画書テンプレート 作成プロセス |
||

» 動画
- 日本最大のビジネスプランコンテストで1位2位のワンツーフィニッシュ
- 国認定「スーパークリエーター」間のビジネスプランコンテストで2位
- シリコンバレーのビジネスプランコンテストで4位
- Google検索「事業計画書」No.1
- 年間300人以上の経営者に会い、100本以上の事業計画をレビュー
- 東京大学法学部を休学し
University of British Columbia (カナダ)へ転入・卒業 - 世界第2位のソフトウェア会社OracleでITコンサルタント、
外資系コンサルティング会社Headstrongにて経営コンサルタントを経て
Linzy Consulting株式会社 を設立 - IT業界から宇宙ビジネスまで
数社のベンチャー企業、大手企業の取締役・顧問をつとめる - ビジネスメディア 「Insight Now」 にビジョナリーに選ばれ
起業家サイト「Dream Gate」でも高い顧客満足度・相談件数を
誇るトップアドバイザー - 「事業計画」をテーマに
日本実業出版、日経BPなどに記事を寄稿中 - 講演実績: 政府系金融機関、証券会社、コンソーシアムなど
- その他、千に三つの世界での失敗経験は数知れず。。。
- 記事一覧⇒「リアルな事業計画書の書き方」
WBSのサンプルのダウンロード

クリティカルパスの分析ができるので、できればMS-Projectを使ってほしいのですが、
Excelを使うのがまだ世の中では一般的なのでExcelの3か月WBSをダウンロード提供します。
ご登録の上、WBSサンプルをダウンロードしてください。
ウェブサイト開発プロジェクトを想定したシンプルなサンプルです。




