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

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

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

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

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

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

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

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

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

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

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

というものです。

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

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

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

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

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

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

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

　ただし、その難しさの本質について理解すると、少し、その試行錯誤が、しやすくなるかもしれません。どんな問題かというと、それは「スコープを切ることの難しさ」と「展開シナリオのコントロール問題」です。

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

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

　プロジェクトワークには、必ず、スコープ（責任範囲や活動範囲）があります。スコープという言葉を正確にイメージするためには、まず以下の「プロジェクトワークにおける基本文法」を理解する必要があります。

「目的Pのために、関係者Sとともに、資源Rと手段Mを用いて、目標成果Tの達成を目指す」

「制約L、課題I、不確実性Uを念頭に置き、踏破ルートCを設定する」

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

　プロジェクトとは、ドライな言い方をすれば、「変数の調整と組み合わせ」なのです。すべての変数が整合したときに、プロジェクトは、幸せな形で成就します。整合しないあいだは、産みの苦しみが続きます。

目的　P	purpose	なんのためにやるのか　その取り組みにおける大テーマ、本題
関係者　S	stakeholder	取り組みのなかで利害の発生する他者
資源　R	resource	投下できるお金や時間や設備、機材、情報、社会的立場など
手段　M	method	用いる技術やノウハウ、理論、フレームワークなど
目標成果　T	target	目的を叶えるための、具体的な成果物
制約　L	limiting condition	取り組みにあたって活動の制限となる状況や不利な条件
課題　I	issue	理想と現実のギャップ　取り組みの前進を阻む矛盾やトレードオフ
不確実性　U	uncertainty	すべての変数に関する不確定性の見積
踏破ルート　C	course	どの順番で、どんな行動や作業を実行し、どんな条件を満たしていくか

　これらの変数は、自らの意思でコントロールしやすいものもあれば、そうでないものもあります。

●実行主体者の自由意志により決定や調整がしやすい・・・P、S、R、M、T
（だれと、なんのために、どうやって、いつまでに、なにをめざすか、という意志）

●外部環境から与えられた、所与の条件・・・L、I、U
（すすめるにあたって、対応せざるを得ない不利な条件や課題、そもそもの不確実性など）

　これらの変数のなかで、究極にやっかいなのは、U（不確実性、uncertainty）です。すべての変数が、プロジェクトの開始時点ですべてが既知である、ということはありません。やってみて初めてわかるものもありますし、最初に決めていた（わかっていた）つもりでも、外部環境の変化から、進めているうちに変わってしまうものもあります。

　そういうことも含めて考えたうえで、「達成プロセスの設計解である踏破ルートC」を導出する。プロジェクト設計とは、そういうことです。

　通常私たちがプロジェクトの計画とかWBS、ガントチャート等の形で表そうとしているものは、この「踏破ルートC」のことなのです。

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

　「プロジェクトワークの基本文法」の面白いところは、言葉の抽象度を高めて、広い範囲のことを言い表すこともできるし、逆に具体化して、より狭い範囲のことを精密にあらわすこともできる、ということです。

　たとえば「ある新規事業のために、ECサイトを作りたい」となった場合、その商材獲得や資金調達、組織づくりも含めた、事業作り全体を扱う計画を書くことだってできますし、サイト制作に限定することもできる、というようなイメージです。

　どんなプロジェクトも、大きなスコープが、小さなスコープを包含しています。それをさらに分解すると、より具体化されたスコープが見えてきます。
　プロジェクトにはいわゆる「入れ子構造」が存在するのです。

　踏破ルートを描くためには、一体自分たちは、どこからどこまでの範囲の行動をするかが、明らかでないといけません。そして、WBSを書くことによって、語りたい範囲や扱いたい領域を限定することを、スコープを切る、というふうに言うわけですが、一体どこからどこまでが守備範囲なのかを考え出すと、実はかなり、悩ましいところがあります。

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

　たとえばあなたがいま、ECサイト作りのWBSを書いてください、と上司や顧客に依頼された場合に、この「そもそもの全体的なスコープや、それを分解した部分スコープたちの関係性」を明確にすることは、とても大事です。守備範囲が確定していないと、必ず、WBS作成は、堂々巡りが起きます。

　特に、現代ビジネスプロジェクトの大規模なものになると、委託者の組織構造も、受託者の組織構造も、極めて高度に複雑化しています。

　この「そもそもの守備範囲とその構造」の話は、抽象度も不確実性も高いので、現実的な業務のなかで、上司や顧客がスパッと決めて、おろしてくれるということは、ほぼほぼ、ありません。

「スコープの不確定性問題」に対する、現実的な対処法

　この問題については、小規模ないし中規模ぐらいまでのものであれば、実は、簡単な解答方法があります。

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

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

　プロジェクトワークのセンスが良い人は、以上のようなことを、意識的に考えているわけではありません。なかば無意識的に、身体感覚で、状況をとらえ、関係者の意図や意向を汲み取り、なんとなく、こんなふうに表現すればよかろう、という感覚で、計画を表現し、コミュニケーションしています。

　それは、「自転車に乗る」みたいなもので、身体感覚によっています。ゆえに、できる人には自然とできるけど、わからない人にはわからない。できる人が他者にいざ教えようとしても、なぜかうまく教えられない。できる人も、自分の手に余る状況に直面したりすると、途端にスランプに陥る、ということが起きます。

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

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

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

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

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

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

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

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

などなど・・・

　しかし、WBSで、そのような分岐も含めた計画を描くことは、できません。WBSとは、「ただ一本の世界線上の、あるべき理想像」しか、表現できない表現形式なのです。（シナリオ分岐をWBS上で表現しようとすると、かならずそれはバッファという表現となります）

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

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

　初心者の方の「WBSは難しい」という悩みは、ときに、プロジェクトワークの本質的な問題を理解しているがゆえの悩み、だったりします。
　それはまさに慧眼というしかない、ハイレベルな悩みです。

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

　「いちど計画を明確にしたら、責任を負わなければいけない」「誤りがあったら怒られる」といった恐怖感に縛られてしまうと、最初の一歩が踏み出しにくくなってしまうので、要注意です。

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

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

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

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

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

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

　正解は、Bです。

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

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

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

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

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

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

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

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

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

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

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

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

まとめ

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

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

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

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

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

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

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

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