2019年もよろしくお願いします。
この投稿で言いたいこと、オチ
いわゆるSIerのSEがやるプロジェクトにおいて「やること」をどう取り扱えばみんな幸せになれるのか。 僕も知らないので、誰かうまくやっている人は教えてください。 がオチ。
序論
たまにWBSなんて不要だ、タスクリストでいいじゃん的な言説を見かけるが多分それは正しくないと思ってます。 正確には完全ではないと思ってます。この辺を語りたいなと。
まず勘違いしがちなこと
WBSは
| WBS | 成果物 | 1月 | 2月 | 3月 | 4月 | ... |
|---|---|---|---|---|---|---|
| 要件定義 | 要件定義書 | 〇 | 〇 | |||
| 基本設計 | 基本設計書 | 〇 | 〇 | |||
| 詳細設計 | 詳細設計書 | 〇 |
ではありません。これはスケジュール表です。 WBSは「Work Breakdown Structure」の略だというのは皆さんご存知かと思いますが、 つまり、タスクよりは大きな単位であるワーク(やらなければならないこと)をブレイクダウンしたものです。 つまり構成がゴールであり、この表でいうと左半分です。
この時点で
「WBSは不要だ、タスクリストでいいじゃん」っていうのは少し違うことがわかるかと。 「十分にブレイクダウンされたWBS」と「タスクリスト」は誤解を恐れずいえばある意味同じものです。
違うところはタスクリストは「作った時点で具体的なタスクの一覧であること」であり、 「何のためにそのタスクをやるのか」はふつうは表現しません。 WBSは粒度によってWBS1、WBS2、...等と分解していきますが、WBS1は目的に近い表現になります。
タスクリストにしてはいけない理由
なぜタスクリストは楽(と感じる)のか
比較的小規模でメンバーが多くない(直接マネジメントしてる人の人数が10数人程度？) プロジェクトは個人のタスクリストを突き合わせるやり方がやりやすい。
ただし「個人のタスクリストの突合せ」はN対N通信なので、ある程度の規模になると破たんする。
何が問題なのか
一言でいうと「うまくいってれば問題ないが、うまくいってないときにさばけなくなる」
-プロジェクトメンバー個々人が遅れだしたらどうするのか -遅れが取り戻せる見込みが立つのか -その人がやっているタスクは別の人がやってるタスクに影響しないのか(クリティカルパス) -他メンバーでリカバリできるのか
タスクリストでこのあたりは表現できない。 仮にこの辺を表現したタスクリストはもうWBS/スケジュール表と呼ばれるものになる。
みんながWBSを嫌う理由
なぜメンバーはWBS書きたくないのか
いわば書くことはタスクリストと同じなので問題ないはず。 一番面倒なのは更新しないといけない(スケジュール含め)こと。 そんなことするぐらいなら実作業時間を取りたい。
でどうすればいいのか
わからない。ここ募集中。
この投稿で書けなかったもの
-よく似たものの違い + WBS:一覧、網羅的、全体管理 + タスク:単発的、個々の実用 + 課題管理 + スケジュール + トラブル対応
-スコープ(誰に言うべき課題/問題/トラブルか。隠したい問題と言いたい問題。) + 会社単位 + チーム内 +プロジェクト内 + お客様向け
