WBSなんて書いてるから仕事できねーんだ --二度目--
■同じネタを引きずってみる
別にWBSに恨みがある訳ではないが、同じネタを引っ張ってみた。多分、前のコラムでもそうだと思うが、WBSを書いている人にとってはあまりいい気分のするものではなかっただろう。自分が良しとして書いているものを批判されたら、いい気分はしないだろう。
だからこそ新年早々同じネタを引っ張ってみた。WBS一つでも、角度を変えればいろいろなネタは出てくる。業務でWBSを書いている人たちであれば、ただ書けと言われたから書くのでは困る。自分の書いているドキュメントの意味はよく考えて頂きたい。
■スケジュールではどうやっても解決できないこと
WBSを書くことで目的を明確化できる。とはよく言うが、目的が決まっても根本的なスキルが不足していては、事を成し得ることは不可能だ。どんなに整理の上手い人でも、収納スペース自体を拡張することはできない。詰め込める量には必ず限界がある。
つまり、どんなに綿密に計画を立てようと、できないものはできないのだ。理論的思考で、できない → 課題を整理する → 目標を明確にする → 問題が解決する。という論法をよく見る。ここでよくある大きな誤解は、課題を整理したり、目標を明確にした時に、「できません」という結論も出るということだ。
「仕事だからできないじゃ困るんだ！」という人もいると思うが、そういう人は諦めて欲しい。困っただけで不可能が可能になるなら、誰も苦労なんてしない。見直すなら、計画よりも積み重ねてきた技術的な負債だ。ここを素直に認めない限り、永遠にプロジェクトの炎上は阻止できないだろう。
■WBSに想定外は書けない
WBSに「もしミスをしたら？」という IF を想定して書くだろうか？全てがうまくいく前提でWBSを書いているように思う。それはそうだろう。会議で使ったり、お客様に見せるとするなら、ミスをした時の想定なんて書けるはずがない。なので、WBSに想定外も含めずに計画を立てるしかない。
このように書かざるを得ないので、想定外に対しての許容量が狭くなる。理論的にタスクと結果を結びつけるのも結構だが、理論自体が間違えていれば正しい結果は出ない。どんなに理論的に考えても、その人のキャパシティーを超えた答えは出せないのだ。つまり、頭の固い人がどんなに理論的に考えても正解は出ないということだ。
■WBSをどう使っているか
そもそも、計画と進捗管理を混同していないだろうか。よく、進捗に合わせてWBSを更新している人がいるが、あれは進捗管理だ。もし計画だとするなら、そんなに軽々しく更新すべきではない。それは、計画が練られていことになるからだ。
計画と進捗の区別を付けて書かれているWBSをあまり見ることがない。それだけ技術のいることなのだと思う。最近は安直な思考の人が多いので、見た目と更新の方法さえわかれば運用できると思い込んでいる節がある。しかし、実際は意図を把握しなければ運用できない。
結論として、WBS自体は何も悪くはない。使う人のレベルが低いのだろう。ものすごくシンプルな話で、そんな人がWBSを書いても役に立たない。むしろ、そんな仕事をしているから炎上するんだと。
コメント
やまぐち
割とよくわかる内容です。
結局、遅延が発生したときの対処方法を決めておかないと意味ないんですよね
①残業や休日出勤で対処
②作業順序を変更する（遅延理由が機材がないなど）
③足が出た部分はヘルプの人間を割り当てて対処
④スケジュールを引き直す（人員も割り当てなおす）
⑤客と交渉して機能を削る
⑥終了したことにして後工程でこっそり対処
⑦もういっそ未実装ですべてを不具合として報告してもらう（見かけの設計・実装工数が０になる悪魔の錬金術）
⑧記録に残らない作業は一切放棄し実作業にだけ専念する（進捗会議や打ち合わせに出ない）
⑨設計の詳細部の省略
⑩実装のエラーチェック全無視
①②しかやらないと決まってる会社はWBSなんて書いても無駄でしょうね
ちょっと頭がよくなると⑥⑦⑧⑨⑩を使いだすだけです
③④⑤はそれなりにお金があってそれなりに会社が強くないとできないこと
なので結局①②⑥⑦⑧⑨⑩でやっていくしかないわけです
でも会社やプロジェクトにしても無い袖は振れないので
まあ、しょうがないんでしょう
⑥～⑩をうまく使えば強烈な残業が必要になるのは最後の納品ぐらいです
慢性残業症候群になってしまうと「バカ」になっていくので
そこはある程度調節してうまく生きていけるといいと学びました（私は）
いつか正直ベースでＷＢＳを書ける日がくるといいですね
げげ
ちゃんとPMBOK勉強したら？スタティックおじさん見たい。
Anubis
>やまぐちさん
コメントありがとうございます。
よくまとまっていると思います。
あと一つ選択肢が思い浮かびました。
⑪体調壊して戦線離脱する
マネージャクラスの人で、本気でそういう手段を語る人がいました。
IT業界の闇の深さを感じました。
>げげさん
このコラムのWBSをPMBOKに置き換えても意味は通じます。
スタティックおじさんを見たいのですか？でしたら、こちらへどうぞ。
http://el.jibun.atmarkit.co.jp/minagawa/2010/04/post-ebc4.html
調べればすぐ出ますので、コメント欄でわざわざ聞かずにググってください。
(人を挑発するなら、意味が通じるように日本語を使いましょう)
ardbeg32
計画時のWBSの線をそのままにして、進捗率と実際のスケジュール推移を別の色の線で次の行に書き入れていくやり方もありますよね。
ただAnubis様が仰るとおり、WBSだけでは「できないものはできない」事態に陥った時に、線表の更新なし使い続けることは出来ないわけで、だからこそPMBOKその他のPDCAを回して計画の見直しが組み込まれている新しいツールがもてはやされているとも言えるのでしょう。（まあそれでも当初スケジュールを守れないという意味では一緒なわけですがｗ）
まあただ私の経験では、スケジュールはいつも客先都合にぶん回されるのが常でしたので、WBSにも巧妙？ｗに予備日や削っても支障のない工程、サバを読みまくったテスト日程を入れて、理想と想定外な現実のすり合わせを行っていました。
「そんなのＷＢＳじゃねー！」と言われてしまうとそのとおりなのですがｗ
結局のところ、前回申し上げた通り、ＷＢＳなんてのはエライ人に納得感を持たせるのが主目的とも言えるでしょう。
Anubis
>ardbeg32様
コメントありがとうございます。
> 計画時のWBSの線をそのままにして、進捗率と実際のスケジュール推移を別の色の線で次の行に書き入れていくやり方もありますよね。
ココらへんの技法に興味があるのだが、上手くいってる実例を見た事が無い。本当に有効に使えている人の話を聞いたら、意見が変わるかもしれません。
お客さん都合でサバ読み入れれば、確かにWBSを書けなくもない。だけど、後から見て分析には使えなくなってしまうのですよね。そんなことで、PDCAも、Pで歪んでDで破綻、CでスルーしてAが炎上するのが私のよく遭遇するパターンです。
>結局のところ、前回申し上げた通り、ＷＢＳなんてのはエライ人に納得感を持たせるのが主目的とも言えるでしょう。
コレは私も同感です。
Anubis
> げげ さん
見苦しいコメントだったので消しときました。
これ以上関わりたくないのでスパムに登録しておきました。
吠えたいな伝わる形で吠えてください。
その時はキチンと受けて立ちます。