クロスイデアblog

5年前「炎上プロジェクトから学ぶセミナー」というタイトルのプロマネ向けの講習を友人の会社と共同で開催し、それからだいぶ経ちました。それ以来私は、参加者のアンケートなどを基に「より効果の出るテーマは何か」と考えてきました。その結論の一つが「WBSの作成」です。前回の記事で「なぜWBSを作成しなければならないか」について述べましたが、WBSは簡単そうに見えるためか、きちんと作り方を教わることも無いまま作らされることが多いように感じています。そこで、私なりのWBSの作り方を書き留めておきたいと思います。あくまでも私のやり方ですのでこれが正しいやり方というわけではありませんが、必要としている方にとって少しでも参考になればと思っております。

さて、WBSの書き方・作り方の前に、「誰がWBSを作るべきか」という問いがあります。「WBSを作れ」と言われてもその必要性を認識していなかったり、仮に必要性を認識していたとしても（以前お伝えしたように）「見える化」しないタイプの人は全く作らないか、なんとか誰かに作らせて少なくとも自分は作らないで済まそうとするのではないでしょうか。

しかし、今のところ私の考えでは、複数の会社が関わるならそれぞれの会社で、複数の部門が関わるならそれぞれの部門で作成すべきです。もっと分かりやすく言えば、全体で1つではなく、管理の単位（便宜的にチームと呼びます。きっと組織の文化によって呼称は異なるでしょう。）それぞれに1つずつのWBSがあるべきです。（もちろん社内の小さなプロジェクトなら1つあれば充分ですね。）そして、チームリーダーの責任でWBSを作るのが良いと考えます。何故ならWBSは、自分のチームが作らなければならない、あるいは実施しなければならないことをまさに網羅的に表現したものだからです。

だから、自分たちの作るべき成果物、やるべき項目を漏れなく列挙し、実作業の責任者としてそれをスケジュール化します。もちろん他のチームと連携しなければならない項目についてはマイルストーンの摺り合わせも必要ですが、基本的には他のチームの作業はそのチームが管理すべきことと考えます。だから他チームの作業そのものを項目化するのではなく、作業に係る他チームとのやり取りを項目化して、期日を両者で合意すると良いでしょう。

次に「どの粒度まで表現すべきか」という問いがあります。これは私も良く訊かれますし、他の人が訊かれているのを耳にしたこともあります。それだけ答えを探してもなかなか見つからない問いなのだと思います。中にはあらゆる作業、あらゆる成果物を細目に落とすべきといったアドバイスもネット上で見かけます。私もこれといった答えを持っているわけではないのですが、これだけは言えます。それは「管理する人が管理しやすい粒度で」ということです。項目が大まか過ぎて日々の状況把握に耐えられないようではいけないし、逆に細か過ぎて全体が俯瞰できなくなったりメンテナンスの負荷ばかり高くなっても本末転倒だからです。最初から完璧なWBSは作れなくても、慣れてくればその辺りのサジ加減は会得できると思います。

また、対象のプロジェクトや、そのプロジェクトを実施する組織によってその管理のやり方も異なってくるでしょうから、画一的な「正解」に凝り固まらない方が良いのではないでしょうか。WBSをきれいに作ることが目的ではないし、まして管理することが目的でもないのです。まったく初めての取組みであって勝手が分からないようなケースは本当に検討事項の一つ一つまで細かくしないと危ないかもしれないし、類似のプロジェクトを経験していればそこまで細かいと冗長さを感じることもあるでしょう。そこはWBSを利用する本来の目的に合わせて柔軟に粒度を調節できることが望ましいと考えています。

より具体的な作り方に関する問いについては次回に続きます。

プロジェクトに携わると必ずと言って良いほど「WBSを出して下さい」と言ったり言われたりします。WBSとはWork Breakdown Structureの頭文字をとった頭字語で、プロジェクトを計画する際によく使われるツールですが、多くの人はWBSを作る立場になる前に少なくとも1つ以上のWBSを見たことがあるのではないでしょうか。

ところが、自分がWBSを作る立場になると、WBSの作成は簡単そうに見えて意外と難しいということに気づくケースが多いように思います。少なくとも私はそうでした。

以前にも書いたように、たまたま参画したプロジェクトのPM（プロジェクトマネージャ、プロマネ）が「見える化」をしないタイプだとしたら、おそらくWBSは存在していない（作られていない）でしょう。そういうプロジェクトは概して無計画で、出たとこ勝負であり、ノリ重視であったりします。人生は出たとこ勝負で良いかもしれませんが、プロジェクトとなれば（当人がプロジェクトのオーナーで無い限りは）そういうわけにもいきません。そういう現場が好きな人以外は、そのようなプロジェクトに間違って参画してしまうとそれなりに苦しい時間を過ごすことになります。

「プロジェクトは計画通りにいかない」という人がいます。もちろんそのとおりだと思います。プロジェクトには大なり小なり想定外のイベントは付物で、事故と言ってもいいでしょう。しかし、だからといって計画を立てなくて良いということにはなりません。それは何故でしょうか。

WBSはプロジェクトの完了に必要な要素を全て洗い出したものです。多くの場合、洗い出した項目とガントチャートを組合せてスケジュール表として作成します。（以降、WBSといえばスケジュール表を兼ねているものを指す）だから、WBSがあれば、

• そもそも何をしなければならないか（全体の規模感）が分かるため、心構えができる。
• 何をいつから始めれば良いかが分かるため、気付いたら時間切れという事態を避けられる。
• 各作業の全体の中の位置付けが分かるため、次の作業を意識して取組むことができる。
• 先々の予定を把握することで、余裕を持って作業に取組むことができる。
• 結果的に、生み出す成果物の品質が高くなり、プロジェクトの成功確率が高まる。

…と、このようなメリットが期待できるのです。逆にWBSが無ければどうなるでしょうか。

• 何をしなければならないか「分かったつもり」になっているため、必要な項目が漏れる。
• 何をいつから始めれば良いか分からないため、項目を思いついた時点で既に時間切れの場合がある。
• 全体の中の位置付けが分からないため、1つの作業に没頭してしまい、目的と期限を見失う。
• 先々の予定が分からないので、差し迫ってない項目は放置し、差し迫ってから着手する。
• そのため、突貫工事で低品質の成果物を生み出し、高稼働でコスト増またはスケジュール遅延となる。

…と、このようなデメリットが想定されるのではないでしょうか。ここでは私の思いつく限りを列挙しましたが、きっと皆さんはそれぞれの状況下でそれぞれのメリット・デメリットを挙げることができるでしょう。突き詰めていくとWBSの有無がプロジェクトの成否だけでなくプロジェクトに関わる人たちに影響をもたらすと言えます。