「WBSを書くのが難しい問題」を、徹底的に解剖する

着目する問題：
「WBSが難しい」は、なにが難しいのか

　PM研修のお仕事をさせていただくなかで、かならずいただく質問が「WBSを書くのが難しい」というお悩みです。

　WBS作りは、普通に書けるよ、という人にとっては、「なんでもない、普通の作業」というイメージがあるかと思います。どうやって作るかも、取り立てて意識して勉強した記憶もなく、みようみまねでやっているうちに、なんとなく普通に書けるようになった、という人も多いと思います。
　一方で、「別に、普通に書けるよ」という人でも、「本当に、この書き方でいいのか？」と、心のどこかでうっすらと悩むこともあります。実際、「どんなに頑張って書いても、現実はその通りにならず、困っている」という人も多い。

　たとえばインターネットで「WBS　書き方」みたいな検索をすれば、いくらでも解説記事が見つかります。それらを読めば、なんとなくわかった気がする。

　でも、自分の取り組みにあてはめ、応用しようと思うと、なんとなくしっくりこない。

　AIサービスにお願いして、具体的に「こんなプロジェクトなんだけど、WBSを作ってくれますか？」といえば、代筆だって、いくらでもしてくれます。確かになんとなく、そんな感じ、というアウトプットは出してくれる。

　じゃあそれをほんとうに実戦投入していいのか、というと自信がぐらついてしまう。

　今回は、WBSの「深層問題」がテーマです。
（このコラムにおける「WBS」は、成果物そのものの内部構造の話というよりは、マスタースケジュールも含めた全体計画、という意味合いで、お読みください）

初心者の勘違いの、初歩的なもの

　プロジェクトワークのビギナーの方が、「計画を立てるのが難しい」との悩みを感じる理由は、ほとんどの場合、同じ勘違いによって発生しています。

「世の中には、正しいWBSの書き方というものがあって、プロジェクトマネジメントというものを学べばそれを教えてもらえるし、それを教えてもらいさえすれば、お手本通りのWBSが書けるようになる」

というものです。

　確かに「論理的に分解しよう」とか「同じ仲間同士でグループ分けし、階層化しよう」「担当者と期限を設けよう」といった原則論はあります。確かにそれは「正しいWBSの書き方」ではあります。

　しかしそれは原則論であり、原則論だけでは、使えるWBSは、書けません。

●その取り組みのなかで、どこからどこまでの範囲をプロジェクトとして取り扱うか
●関係者のスキル経験のレベルや、モチベーションの具合はどうか
●その取り組みに関する過去の知識は十分にあるか
●進めていくなかで、誰がどこまでの責任を負っていて、途中経過はどうやって報告・相談するか
●生み出すべき成果物の仕様や内部構造は明らかになっているか、または探索的に進めるのか
●途中作業にかかる時間や費用、必要とする技術レベルなどはわかっているか、または探索的か

　といった要素を考えていかないと、実利のあるWBSは、どうやったって、書けません。そして、これらの状況しだいで、WBSの表現は、粗くもなり得ますし、細かくもなり得ます。必要な項目や作業手順も、変わります。

　たとえ同じプロジェクトだったとしても、それを扱う主体者が違えば、WBSの表現は、変わります。世の中に、いかにたくさんのWBSの「お手本」があっても「あなたのプロジェクトのWBSのお手本」は、どこにも存在しないのです。

　どこかで見たことのあるお手本のように書こう、書こうとしすぎると、あなた自身のプロジェクト状況が求めるものと、かえって離れていってしまうかもしれません。
　WBSは、その場その場に置かれた状況に、あわせて書くしかありません。

　「そんなことを言われても、じゃあどうすればそう書けるのか、イメージがつかない」と思われるかもしれませんが、そこはもう、たくさん書いてみて、成功体験も失敗体験もたくさん積んでみて、そこから学ぶしかないのです。

　ただし、その難しさの本質について理解すると、少し、その試行錯誤が、しやすくなるかもしれません。

　以下にご紹介する「本質的な問題」の話が、もし、ご参考になると幸いです。

初心者の「難しい」の、実はとても本質的な悩み

　実は、プロジェクトワークにおける、極めて本質的な問いに直面していて、そのせいで「WBSは難しい」となっている場合も、あります。

　どんな問題か。それは「スコープを切ることの難しさ」と「展開シナリオのコントロール問題」です。どういうことか、それぞれ説明します。

スコープを切ることの難しさ

　プロジェクトワークには、必ず、スコープ（責任範囲や活動範囲）があります。そして、スコープとは、大きく取ることもできるし、小さく取ることもできます。

　スコープという言葉をイメージしていただくために、以下の「プロジェクトワークにおける基本文法」をご参照ください。

　規模の大小や題材を問わず、どんなプロジェクトだって、必ず、以下の2行で表すことができます。

「関係者Sとともに、目的Pのために、資源Rと手段Mを用いて、成果Tを目指す」
「制約L、課題I、不確実性Uを念頭に起き、踏破ルートCを設定する」

　プロジェクトとは、比較的自分の意志でコントロールしやすい、任意に設定してよい変数である、S、P、R、M、Tと、所与の条件であるL、I、Uをもとに、達成プロセスの設計解であるCを導出する、ということです。

　この基本文法の面白いところは、言葉の抽象度を高めて、広い範囲のことを言い表すこともできるし、逆に具体化して、より狭い範囲のことを精密にあらわすこともできる、ということです。
　たとえば「ある新規事業のために、ECサイトを作りたい」となった場合、その商材獲得や資金調達、組織づくりも含めた、事業作り全体を扱う計画を書くことだってできますし、サイト制作に限定することもできる、ということを、イメージしてください。

　通常私たちがプロジェクトの計画とかWBS、ガントチャート等の形で表すものは、この「踏破ルートC」のことなのです。Cを描くためには、一体どこからどこまでの範囲のことを念頭に置くのかが、明らかでないといけません。

　WBSのなかで、語りたい範囲や扱いたい領域を限定することを、スコープを切る、というふうに言うわけですが、一体どこからどこまでが守備範囲なのかを考え出すと、実はかなり、悩ましいところがあります。

　ECサイト制作の話でいえば、仮に、WBSを書くスコープをサイト制作に限定したとしても、インフラ、バックエンド側の話もあれば、フロントコーディング側の話もある。デザインやUX、レイアウトの話もある。
　いや、そもそも取り扱う商品のなにがいいのか、どこを推したいのか、想定する顧客が求めるものは、なにか。ブランド作りのために、どんなアートディレクターを招聘して、どんなネーミングやロゴマークを作るのか・・・いやまてよ、それって私の仕事だっけ？どこまでやればいいんだっけ？

　たとえばあなたがいま、ECサイト作りのWBSを書いてください、と上司や顧客に依頼された場合に、この「そもそもの全体的なスコープや、それを分解した部分スコープたちの関係性」を明確にすることは、とても大事です。守備範囲が確定していないと、必ず、WBS作成は、堂々巡りが起きます。
　しかし、現実的な業務のなかで、この「そもそもの守備範囲とその構造」の話は、抽象度も不確実性も高いので、上司や顧客がスパッと決めて、おろしてくれるということは、ほぼほぼ、ありません。

　この問題については、実は、明確な答えがあります。まずは「こんな感じかな」と、えいやっと決めてしまって、まずは、たたき台でもいいから書いてみるのです。
　書いてみて、関係者と話してみて、また修正して、という過程を通して、塩梅のいい答えを見い出せばよいのです。

　たたき台として書いた初案が、最終的な答えである必要はありません。「こんな感じかな」というたたき台のWBSを上司や顧客と一緒に眺めながら、「そもそもの守備範囲」についての認識をすり合わせていく、ということができれば、たいていの場合は、それである程度、ものごとは円滑に進んでいきます。
　とくに、プロマネの専門的な勉強をしなくても、ある程度センスよくプロジェクトを推進できるよ、という人は、この「範囲の切り分け」に関するコミュニケーションの扱いが、上手な人です。

展開シナリオのコントロール問題

　ただし「スコープ不確定問題」をクリアしたとしても、より不確実性の高く複雑な取り組みになったときに直面する問題があります。

　「シナリオ分岐問題」です。

　プロジェクトワークでは、なにかしらの課題やタスクをこなしていくということが基本動作であるわけですが、それが、事前の想定通りの結果につながるとは限りません。

　なにかしらの施策を実行した場合に、それが、うまくいくときもあれば、うまくいかないときもあります。
（ここでいう施策とは、製品仕様を左右するユーザーインタビューとか、大型投資判断のための実証実験、大規模ピッチイベントへの登壇、といった、プロジェクトの成否に大きな影響を及ぼすイベントをイメージしてください）

　当然、それがうまくいったら次にはこれができるが、うまくいかなかったら、他のなにかに影響がある、ということが起きます。

　つまり、プロジェクトワークには「未来に向かって分岐していく複数のシナリオ」があります。

●Aさんがイエスと言ってくれたらこうするけど、Bさんが反対したらこうするしかない
●開発がうまく進めばこうしたいけど、そうじゃなかったらこうせざるを得ない
●もっと予算があればああできるけど、承認が取れるかどうかがわからないから、先に決定できない

などなど・・・

　しかし、WBSで、そのような分岐も含めた計画を描くことは、できません。WBSとは、「ただ一本の世界線上の、あるべき理想像」しか、表現できない表現形式なのです。

　実は、終局図から逆算して、辿ってきた一本の道を振り返る、というのが、一番カンタンに「正しく書くことができる、書き方」ですが、もちろんそれは、何の意味もない、ナンセンスな話です。

　筆者が必ず、PM講座でWBSについてお話しするときには「本当に未知の要素が大きなプロジェクトでは、WBSを高い精度で書くのは不可能だ」ということを、お話ししています。
　過去に前例が多く、先読みがしやすいプロジェクトでは、WBSは力を発揮してくれます。未知の要素が多すぎると、WBSがかえって妨げになることもあります。

　このことを直感的に理解している人の「WBSは難しい」という悩みは、プロジェクトワークの本質的な問題を理解しているがゆえの悩みです。
　それはまさに慧眼というしかない、ハイレベルな悩みです。

　ただし、その悩みは、すぐには解くことはできません。様々な経験を積んだ先にしか、その悩みの答えは、見えません。

中級者のおかしてはいけない間違い

　ある程度、プロジェクトワークの経験を積んだ人であれば、明確には言語化していなくても、なんとなく、上記のような問題は、体感として、理解されています。

　その結果として、WBSなんて、質が高くても低くても、極論、あってもなくても、別に生産性は変わらない、という実感を持つ、ということがあります。

　問題は、その学びの結果として立つ立場です。寓話「アリとキリギリス」になぞらえてみます。

A　キリギリス派
「どうせ計画からの逸脱は起きるし、起きたときに対処するしかない。WBSなんて、テキトーにそれっぽく書いておけばいい」

B　アリ派
「たとえ計画どおりにはならなくても、最善を尽くして事前にしっかりと考えるべき。不確実だからこそ、計画を大事にする」

　正解は、Bです。

　Aのキリギリス派でも、生きていくうえで困ることはありませんが、いつかどこかで、限界がきてしまいます。

　「初心者編」で解説しましたとおり、プロジェクトワークは、極めて多くの変数でできていて、変数同士が関係し合ってもいて、混沌とした活動です。
　しかし、その根本的な構造や文法が見えたとき、「絶対におさえるべき勘どころ」や「こういうときに、こういうことを放置するとまずい」といったものが、ふっと見えてくることがあります。

　プロジェクトマネジメント用語に、いわゆる「マイルストン」というものがありますが、それは、未来に向かって無限に分岐していくシナリオのなかで、「これ！」という形でポツンポツンと存在する、結節点のようなものです。
　それを押さえてしまえば、他のことは多少想定外になっても、どうにかなる、という勘どころです。まさにプロジェクトのシナリオにおける「交通の要衝」みたいなものです。
　どんなプロジェクトにも必ず「ある時点、どこかの場所で、なにかが、満たすべき状態を満たさないと、ワヤになってしまう」という急所があります。

　そのようなプロジェクトの要点、急所、ツボを理解したうえで描くことができれば、その計画や構想は、取り組みやチームに対して、飛躍的な生産性の向上をもたらしてくれます。

　プロジェクトワークの上級者とは、そのような大局観を手にした人のことであり、その領域に到達するためには、Bのありかたを選択する以外にありません。

悩まなくなった上級者が、注意しておきたい落とし穴

　無事、中級レベルを突破し、上級者となった方は、「WBSが難しい」とは、考えません。

　ただし、一点だけ、注意をしなければならないことがあります。それは、「特定の業界やビジネスモデル、特定の組織のなかでの計画手法に適応しているだけなのかもしれない」ということです。

　プロジェクトとひとくちにいっても、いろいろあります。

　同じITでも、SIerか、SaaSかで、扱う対象や重心、扱い方は、変わります。
　そもそも、それがクライアントワークか新規事業かで、スコープの取り方は、変わります。
　新規事業とひとくちにいっても、マーケットインか、プロダクトアウトかで、話の順序は、変わります。

　ひとつの業界で長く仕事をしていると、プロジェクトワークのイメージが、特定の類型にだけ偏ってしまうことがあります。あるいは「こういうWBSを書くべき」という文化やルールも、実はその事業展開領域に強く影響されていたりもします。

　積み上げてきた知見やノウハウ、コツも大事にしつつ、ときにはあえて意識してそれから自由になって、異業種、異分野のプロジェクトにもチャレンジをしてみる、ということで、プロジェクトワークの本質に、より深く、近づいていくことができます。

まとめ

　「WBSは難しい問題」は、プロジェクトワークが得意な人には、理解しがたいところがあります。簡単なようでいて、なかなか複雑な問題をはらんでいます。

　この問題は、「実際にレベルアップしてみないと、問題の難しさの本質を理解できない」という禅問答みたいな世界です。

　初級者の方は、正しく書こうとしすぎず、等身大で、まずは書いてみて、人に見せてみて、実際にやってみる、ということを大事にしていただきたいと思います。

　上級者の方へのメッセージとしては、後進の方にアドバイスをするときに、ぜひ、ご自身の初級者、中級者の時代を思い出してみていただけると幸いです。「正しい書き方」のノウハウそのものよりも、自分がなぜ、どうやってできるようになったのか、というプロセスや経験をご共有いただけると良いかと思っています。

　そして、もし中級者の方で、計画を立てて、人に説明したり、ただ報告共有するためにWBSを書く、ということに対して、面倒だと思われている方がおられましたら、そこはぐっとこらえて、キリギリス派ではなく、アリ派の仲間になっていただけると、嬉しいです。
　計画は、計画通りにならないから、無駄だ、ということはありません。たとえ計画通りにならなくても、計画をギリギリまで追い込み、考えるからこそ、見えてくる世界というものは、あるのです。

　ちなみに、WBSよりも、もっと使いやすくてプロジェクトの現実（スコープ不確定問題とシナリオ分岐問題）にフィットしやすい、プ譜というツールがあります。

　もし機会があれば、プ譜も一度、触ってみていただけると幸いです。

プ譜のテンプレートと、書き方のワンポイントアドバイス！