>RSS101回死んだエンジニアいろいろな仕事を渡り歩き、今はインフラ系エンジニアをやっている。いろんな業種からの視点も交えてコラムを綴らせていただきます。2017/09/25WBSを書くことが目的になっていないか昔書いたコラムを読み返してみた。「WBSなんて書いてるから仕事できねーんだ」というタイトルで二回もコラムを書いていた。読み返してみるとけっこうコメントがたくさんついている。それなりに多くの人の関心事だったのかと思う。コラムを書いたころからいろいろ勉強したり、多くの経験を積んできた。その結果、たどり着いた結論はやはり、「WBSなんて書いてるから仕事できねーんだ」だった。経験則で話すとすれば、炎上したプロジェクトではもれなくWBSをか書くことが目的になっていた。WBSを書いて、それ通りに実行していけばプロジェクトは成功すると、誰も信じて疑わない。実際は印刷しきれないほどExcelシートが巨大になって非常に見づらかった。更新がある度にマネージャが数時間かけてメンテナンスしていたようだ。WBSを書けば上手くいくと思っている人の中で、どれだけの人がWBSを研究しただろうか。そもそも、最初から「こういうフォーマットで」と、工夫の余地さえ与えられていないこともよくある。分り易くWBSをかくにもスキルは必要だ。安直にWBSを書くと、グチャグチャになって情報が管理できなくなってしまう。結果、プロジェクトは致命的なダメージを受ける。WBSを書けばプロジェクトがうまくいくと思っている人が多いと思うが、現実はそんなに甘くない。考えずに書いているとプロジェクトが炎上する。WBSのフォーマットは普及しているが、実のところ活用しきれていないのではないだろうか。活用したらいいかというのは検討の余地がかなりあるように思う。今回はWBSを叩くのではなく、その可能性を探ってみたい。記録としてのWBSだいたいのプロジェクトでは計画としてWBSを書く。プロジェクトが終わった後にWBSを見直しているのを見たことが無い。似たような案件が発足した時に、何も考えずにコピペして使う。考えると、凄く勿体なくないだろうか。プロジェクトが終わったすぐ後に見直した方がいろいろと気付くことも多いと思うのだが。後から見直して自分たちが何をやったか分るようにWBSを書いているだろうか?多分、書いた人は分っても、第三者に見せて分るような代物ではないだろう。WBSを書くなら、どうすれば第三者が見て分り易いかを意識して書いてみよう。違う観点が見えてくると思う。そもそもな話で、第三者がみて分らないものは、プロジェクト終了後の自分が見ても分らなくなる。第三者が見て分るようにWBSを書こうとすれば、WBSが計画なのか、それとも行動記録なのかはっきりさせる必要がある。私の携わったプロジェクトでこれを意識して書かれたWBSは無かった。最初は計画書として書かれたものが、いつの間にか行動記録にすげ変わっているものが大半だ。その行動記録にも、ありとあらゆるものが詰め込まれて、最終的にWBSとも呼べない得体のしれないものになってしまう。WBSを書くときの情熱を見直す時にも注いで欲しいものだ。WBSの見直しをしないと書けるようにならない。見直すことで改善のネタを見つけていくことができる。書けと言われた書き方で書いて「言われたことをやり遂げたんだ」と満足していては、いつまで経ってもまともにプロジェクトを管理できるようにはならない。詰め込み過ぎたWBSは肥だめと同じだWBSを「これさえ見ればプロジェクトの全貌が見える」万能シートと勘違いしていないだろうか。「これさえ見れば簡単に」はインスタントに慣れすぎた現代人的な発想だ。どんなに頑張っても、本一冊分の情報をA4用紙一枚で網羅することはできない。プロジェクトで扱っている情報量も、規模が大きくなればそれだけ情報量が増えて「これさえ見れば簡単に」で収まる範囲を超える。WBSに限らず、「全貌が一目瞭然」をコンセプトに作られた資料というのは大抵使い物にならない。あれもこれもと情報を詰め込んで、情報の吐き捨て場になるのがオチだ。何十人と集まるプロジェクトでは、管理すべき情報の量も増えるし内容も複雑になる。それを一枚のExcelシートでまとめようというのは狂気の沙汰としか思えない。まともなWBSを書けるようになるには、それなりに時間をかけて過去に書いたWBSを分析する必要がある。炎上するプロジェクトではこういう地道な積み重ねをしないし、実際に書けていない。過去に書いたWBSを分析せずに善し悪しを語るのも、いささかナンセンスなように思う。とある炎上プロジェクトのWBSを分析して面白いことがあった。会議での発言が吹き出しで追記されており、議事録のようにWBSが使われていた。決定した根拠、説明などの情報が一切残されていない。言っている事に一貫性が無かった理由がなんとなく読み取れる。WBSを分析すると、計画や進捗だけでなく、運営用法の問題点など色々なことが見えてくる。現実はWBSに収まるほど簡単じゃない情報というのは一つの事実だ。紙に書き出していくと、自分の想像していたのと実は違っていたということはよくある。WBSを書く人の最大の過ちは、多分こうなるだろうという形に事実をはめ込んでいくことだ。作業の逆戻りや並行作業が発生すると、途端にWBSの見た目が汚くなってしまう。実際の作業は、見た目が綺麗にまとまらないものだ。現実が綺麗にまとまらないので、WBSが綺麗にまとまることはまず無いと考えた方がいい。詳細に描き込めば描き込むほど汚さが際立ってしまう。ここで更にまずいのは、綺麗に書けないのは情報が整理できていないからだと思い込むことだ。現実が綺麗にまとまっていないのに、表に書いて綺麗にまとまるのは逆におかしい。無理に綺麗にまとめようとすると、工数を消費する上に大きな歪みが生じる。私の経験上、炎上するプロジェクトほど詳細にWBSを作成する。細かく計画をブレイクダウンするほどプロジェクトの成功率が高まるというのが通説だが、実際は逆だ。詳細を書きすぎると計画が破綻する。物事がそんなに予想通りに動くはずがないからだ。ブレイクダウンすればするほど、ズレた時の崩れ方は大きい。そもそも、WBSで管理したいのは、計画なのか、進捗なのか、行動記録なのか、工数管理なのだろうか。これら全部をWBSで安直に管理しようとするから失敗するのだ。管理したい項目に対して適切な手段を模索しよう。手法を模索せずにWBSを安直にかいているから仕事ができねーんじゃないかと思います。19:30批判でも肯定でもないですがWBSのSはStructureのSであってScheduleのSではないです。根本的に開始予定日や終了予定日があるのがおかしいと感じています。管理されるべきだ!」との要求に、WBS何だから必要作業の解析と落とし込みまでじゃないんですか?と返すと「計画、進捗含め、全貌が一目瞭然であるべきだ!」と同じ結論を繰り返され、辟易している次第です。WBSの役割りをはっきりさせることは大事だと思っています。作業分解(抽出、細分化)までに止めれば、それはそれで有用だと思ってます。聞いても、どこに行っても、求めているのはWBSではなく、WBS+CBS+OBS+PBSを1セットにしたガントチャートが求められる状況です。計画が完璧ならそのとおり進めば完璧にこなせると言う夢を口々に語ってくれます。そんな神がかった能力を私は持ち合わせていないので、何時も計画作成に苦慮しております。計画通りに進んでいないことを神々からいつも叱られるという試練を得ます。どちらかと言うと、自分がWBSから作り出すのはガントチャートではなく、パート図なんですが、一寸だけ神々に逆らってパートベース(パート+パート単位のコスト+タスク+)の計画を出すと、これじゃ解らないと付き返される始末。その解らないくらい混み合ったパートの工程をクリアしようとしているんですが、なかなか理解は得られません。すみません、ほとんど愚痴でした。「現実はWBSに収まるほど簡単じゃない」と言う言葉に、一寸だけ救われた気がしました。13:01何度読んでもワールドビジネスサテライト(おだまりそもそも論で、過去(記録)と現在(進捗)と未来(計画)を一緒くたにした言葉なのがそもそもの害悪な気がするねぇ。11:54技術は悪ではないのだけど、使う側が悪ければってやつですねWBSの解説してるページとかも「スケジュールと一緒になったもの」みたいな書かれ方してて「違うなぁ」と感じますよWBSは「作業ありき」で考えるのに対して、スケジュールは「期限ありき」ですから短縮やオーバーワークを加味した結果であるスケジュールをさらに短縮するとか、どんな魔法だよそうしてできた無理な前提を前例として、次のPM管理のスケジュールが・・・あ、そうか秘伝のタレってコードだけじゃなかったんだな(ぶちまけてぇわWBSとスケジュールと進捗管理は全部別箇。これがわかってもらえないのか不思議。14:00WBSに時間情報を含めることは、WBSの確度をゆがめるので止めてほしい。時間情報(計画/進捗/実績)自体はWBSをベースに管理すべき、とも思うので、WBSとは別のカテゴリとすべき。09:58同じ意見を持ってる人って多いんですね。(少しビックリしました)肯定も否定もしないとだけしか書いてなかったので理由を書いておきますWBSを正確な意味で扱うなら開発には必要であるし詳細化されればされるほどいいWBSだと思っています。途中で参画する方でも何をして何を成果物として残せばわかりますからね。達成率もわかりやすいですし。その意味ではWBSはいらない、詳細化しないほうがいいという意見には否定です。WBSはスケジュールがあるのが当たり前という前提であればこのコラムには肯定です。私も必要ないと思います。1タスクが1日遅れただけで玉突き事故のようになって後行程がずれるのはスケジュール(管理)とは呼べない代物です。サポート、社内SE、構築を渡り歩き今に至る。このコラムは自分への挑戦だ。自分の書いた文章だけでどこまでいけるか、挑んでいきたい。嘘を許せる強さ人脈?うるせーから寝てろ。書籍「プログラミング思考のレッスン」を読んでみた。利用規約ITmediaはアイティメディア株式会社の登録商標です。