-
WBSと略される
-
大きなタスクを細分化する
- 明確な単位に分割しなければ見積もりができない
-
誰でも知らず知らずのうちにやっている
-
プロジェクトの計画づくりの重要な要素でもあるので色々な考察が行われている
- 例: WBSには手順型のWBSと成果物型のWBSがある
-
歴史
- アメリカ国防省やNASAで使われていたものをPMIがPMBOKで一般向けに紹介したのが1987年
- 日本では知的生産性向上システムDIPSで1992年にタスクのブレイクダウンが語られている
- 階層状にはしていない
西尾の整理したWBSのつくり方のコツ
-
たとえばGTDのInboxだとかTODOリストだとかの形で「やること」を書いている人は多いだろう(してないならまずやる)
-
その中に「即座に実行開始できないあいまいで大きなタスク」が紛れ込んでいることがしばしばある。
- 例：「量子コンピュータで巡回セールスマン問題を解く方法の解説を書く」
- この仕事を実行するには、小さく分割（＝ブレイクダウン）する必要がある
-
なんとなく分割する人もいるだろう。
- 例
- 量子コンピュータで巡回セールスマン問題を解く方法の解説を書く
- 量子コンピュータの簡単な説明
- 巡回セールスマン問題の説明
- どういうイジングモデルにすればよいかの解説
- 量子コンピュータで巡回セールスマン問題を解く方法の解説を書く
- 別の例
- 量子コンピュータで巡回セールスマン問題を解く方法の解説を書く
- 参考資料Xをざっと眺める
- 必要そうなところを抜き書きして付箋にする
- それを並べてストーリーを考える
- 量子コンピュータで巡回セールスマン問題を解く方法の解説を書く
- 前者が成果物型のWBS、後者が手順型のWBSである
- 余力があるなら両方作って照らし合わせることによって抜け漏れが減る
- 上の例だと、手順WBSの側では参考資料を眺めてストーリーを考えることになってるのに成果物WBSの側ではもうストーリーが決まっているものとしてツリーが作られていておかしい。
- 例
-
WBSを作る目的はタスクを分割することではない
- タスクを実行できるようにすることが目的で、その手段としてタスクを分割する
- なので実行できる規模になったらそれ以上分割しなくてよい
- 細かく分ければその分管理コストが上がる。このバランス感を体得することが必要。
-----まとめ前のメモ-----
-
WBSを作ることを繰り返すうちに、タスク分割スキルが高まる
- 典型的パターンが明確化される→WBS標準
- それを参考にすることで見落としや展開不足が避けられる
-
作業スコープを明確化できる
- 書かれていることがやることで、書かれていないことはやらないこと
-
コツ
-
他人にお願いするつもりで作る
- 明日の自分は他人だから
-
(1) >Excelがプロジェクト管理ツールより優れている点は初めのとっつきやすさだけ
- 100件を超えてきたときに管理不能になる
-
書き出し法
- 100個目安
- 曖昧なタスクタイトルは良くない
- アウトプットになる書類のタイトルぐらいまで詳細化
- 要素成果物（つくるもの）を目安に構造化
-
最初はデッドラインを意識しない
- 調整はデッドラインを無視した理想プランができてから
- 理想プランがデッドラインに間に合うはずがない
-
依存関係をきちんと注目する
- クリティカルパス以外を最適化しない
-
担当者を明確に
-
進捗は期間ではなく成果物で測る
-
WBSは１人でつくらない
-
有効に機能するレベルまで詳細なWBSは顧客にとっては情報過剰
-
-
WBSはレベルと要素からなる
- 100%ルール：子要素をすべて足し合わせると親要素と等しくなる
- 取りこぼしがないか確認
- 100%ルール：子要素をすべて足し合わせると親要素と等しくなる
-
要素分解は物に分解するパターンと作業に分解するパターンがある
-
葉のことをワークパッケージと言う
-
8/80ルール：要素への分解はワークパッケージがおよそ8時間以上、80時間以内になるまで行う
- 1日～2週間、ということ
-
7×7ルール：1つの親要素にぶら下がる子要素の数は7程度まで、WBS全体のレベルは7レベル程度まで
- 第1レベルがトップレベルで1個なので子要素7個で7レベルまでだと末端は117649個までいける
- 個人的に個数制限を加えるのは筋悪だと思うが、実質的に制限ではないか
-
作業分解型のWBS
- プロジェクトで必要とされるすべての作業をWBSにまとめたもの
- プロジェクトスコープとも呼ぶ
- フェイズ→タスク→作業手順…と作業マニュアル風になる
- スケジュールに落とすのが簡単
- 1つ1つの作業の終了条件が不明確
- 人によって作業範囲のイメージが異なっていたり
- 一括請負契約で作業分解型のWBSにするとリスキー
- 必要な成果物を見落とす可能性がある
-
成果物分解型のWBS
- 完成させることが必須であるすべての成果物をWBSにまとめたもの
- プロダクトスコープとも呼ぶ
- 責任範囲が明確になる
- 物理的製造業では部品に分割されるイメージ
- PMIが発行している「WBSワークショップ」
- 責任範囲と作業の終了条件を定義しやすいという理由から推奨
- 事前に成果物を把握する必要がある
- 中間生成物に必要な作業を見落とす可能性がある
-
ハイブリッド
- 作業分解型のWBSと成果物分解型のWBSの両方を作る
- トップレベルから順に比較して抜け漏れがないかチェック
-
WBSはルーチンワークの効率化のツール
- ルーチンワークでないものは10%程度
- 9割をルーチンワークにすることで効率化
-
TODOリストの問題点
- 抜け漏れがないかのチェックが働かない
- 書いたときに作業記憶にあった情報が失われて、タスクの詳細がわからなくなる
- 「何のためにするんだっけ？」
- 「具体的に何をするんだっけ？」
- 特定のタスクのためのメモが独立タスクであるかのようにふるまう
- そうするとやる気が出ない
- TODOリストは1行で1タスクが完結するような、行の間に依存関係のない小さいタスク向き
- 複数のタスクで構成されるような「プロジェクト」、複数日にまたがるような大きなものには向いていない
- それをツリー形式で扱うのがWBS
-
ルール：トップダウンで作ること
- why？
- 「ボトムアップだと漏れが出る」本当か？
- トップダウンでも漏れは出るだろ
- MECEなつもりでやっていても人間は間違える
- むしろトップダウンでやって「トップダウンだから漏れがない」とか考える方が有害ではないか？
- 反論
- トップダウンとボトムアップの両方の視点を持つことが大事論
- 思いつくまま列挙してから事後的にツリーに整理
- ボトムアップで作ると成果物視点と作業視点が混ざることに注意
-
作ったWBSは再利用に備えて保存しておく
-
- 手順のWBS、成果物のWBSと一緒に並列で作る
- ワークパッケージだけを付箋にする
- 依存関係などに従って並べて考える
-
まずは全体像を把握する
- ２つのWBSで
-
次におしりから埋める
- 食器洗いのたとえ
- 食器を洗い始めてから、置き場所がないことに気付く
- 最初に「食器を洗おう」「食器を洗うとは、濡らして、こすって、ほすことだ」「ほす場所がない」と考えるべき
- 締切から埋めて行って、クリティカルパスが間に合わなければそれは無理
- クリティカルでないものは制約条件の範囲内でいつやってもよい
- 全てのタスクを開始日時・終了日時指定する必要はない
- 期間の見積もりは明記しておく。
- 最終的に見積もりがどうずれたかを見て、自分の見積もり能力を鍛える。
- 食器洗いのたとえ
-
参考文献