Work Breakdown Structure
大きなタスクを細分化する
誰でも知らず知らずのうちにやっている
プロジェクトの計画づくりの重要な要素でもあるので色々な考察が行われている
例: WBSには手順型のWBSと成果物型のWBSがある
歴史
アメリカ国防省やNASAで使われていたものをPMIがPMBOKで一般向けに紹介したのが1987年 階層状にはしていない
西尾の整理したWBSのつくり方のコツ
たとえばGTDのInboxだとかTODOリストだとかの形で「やること」を書いている人は多いだろう(してないならまずやる)
例：「量子コンピュータで巡回セールスマン問題を解く方法の解説を書く」
この仕事を実行するには、小さく分割（＝ブレイクダウン）する必要がある
なんとなく分割する人もいるだろう。
例
量子コンピュータで巡回セールスマン問題を解く方法の解説を書く
量子コンピュータの簡単な説明
巡回セールスマン問題の説明
どういうイジングモデルにすればよいかの解説
別の例
量子コンピュータで巡回セールスマン問題を解く方法の解説を書く
参考資料Xをざっと眺める
必要そうなところを抜き書きして付箋にする
それを並べてストーリーを考える
前者が成果物型のWBS、後者が手順型のWBSである
余力があるなら両方作って照らし合わせることによって抜け漏れが減る
上の例だと、手順WBSの側では参考資料を眺めてストーリーを考えることになってるのに成果物WBSの側ではもうストーリーが決まっているものとしてツリーが作られていておかしい。
WBSを作る目的はタスクを分割することではない
タスクを実行できるようにすることが目的で、その手段としてタスクを分割する
なので実行できる規模になったらそれ以上分割しなくてよい
細かく分ければその分管理コストが上がる。このバランス感を体得することが必要。
-----まとめ前のメモ-----
WBSを作ることを繰り返すうちに、タスク分割スキルが高まる
典型的パターンが明確化される→WBS標準
それを参考にすることで見落としや展開不足が避けられる
作業スコープを明確化できる
書かれていることがやることで、書かれていないことはやらないこと
コツ
他人にお願いするつもりで作る
明日の自分は他人だから
(1) >Excelがプロジェクト管理ツールより優れている点は初めのとっつきやすさだけ
100件を超えてきたときに管理不能になる
書き出し法
100個目安
曖昧なタスクタイトルは良くない
アウトプットになる書類のタイトルぐらいまで詳細化
要素成果物（つくるもの）を目安に構造化
最初はデッドラインを意識しない
調整はデッドラインを無視した理想プランができてから
理想プランがデッドラインに間に合うはずがない
依存関係をきちんと注目する
クリティカルパス以外を最適化しない
担当者を明確に
進捗は期間ではなく成果物で測る
WBSは１人でつくらない
有効に機能するレベルまで詳細なWBSは顧客にとっては情報過剰
WBSはレベルと要素からなる
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リストは1行で1タスクが完結するような、行の間に依存関係のない小さいタスク向き
複数のタスクで構成されるような「プロジェクト」、複数日にまたがるような大きなものには向いていない
それをツリー形式で扱うのがWBS
ルール：トップダウンで作ること
why？
「ボトムアップだと漏れが出る」本当か？
トップダウンでも漏れは出るだろ
MECEなつもりでやっていても人間は間違える
むしろトップダウンでやって「トップダウンだから漏れがない」とか考える方が有害ではないか？
反論
トップダウンとボトムアップの両方の視点を持つことが大事論
思いつくまま列挙してから事後的にツリーに整理
ボトムアップで作ると成果物視点と作業視点が混ざることに注意
作ったWBSは再利用に備えて保存しておく
手順のWBS、成果物のWBSと一緒に並列で作る
ワークパッケージだけを付箋にする
依存関係などに従って並べて考える
まずは全体像を把握する
２つのWBSで
次におしりから埋める
食器洗いのたとえ
食器を洗い始めてから、置き場所がないことに気付く
最初に「食器を洗おう」「食器を洗うとは、濡らして、こすって、ほすことだ」「ほす場所がない」と考えるべき
締切から埋めて行って、クリティカルパスが間に合わなければそれは無理
クリティカルでないものは制約条件の範囲内でいつやってもよい
全てのタスクを開始日時・終了日時指定する必要はない
期間の見積もりは明記しておく。
最終的に見積もりがどうずれたかを見て、自分の見積もり能力を鍛える。
参考文献