はじめの一歩はWBSから
WBS（Work Berakdown Structure）はプロジェクトマネジメントで計画を立てる際に用いられる手法の一つで、プロジェクト全体を細かい作業に分割した構成図または表のことを指します。
日本では古くから、「作業分割構成」「作業分解図」などとも呼ばれます。
ことさらＩＴ業界ではすでに一般化した言葉ですが、なにもＩＴ業界に特化した用語ではありません。というか、すべての仕事のいわば「基礎」であり「土台」として新人からベテランまで広く使われるべき概念の１つだとも言えます。
なんとなく横文字だから…と敬遠する人もいるかもしれませんが、正直、これができないと大きな仕事を成功に導くのはどんなに優れたマネージャーでも難しいのではないでしょうか。何億、何十億、何百億という規模のビジネスでは勘や経験則でどうこうなることはありません。必ず成功するための「仕組み」というものがあります。そのなかでももっとも簡単で、もっとも一般的で、もっとも広く普及しているのがこのWBSです。
WBSとは簡単に言ってしまえば「仕事を分解し、整理すること」です。
どんな製品でも部品を組み合わせているものですが、それは仕事も同じです。単一の仕事だけで何かをなすことは決してできません。それら仕事を部品化しましょうといっているだけなのです。
当然、技術的に難しいことは何１つありません。コツのようなものはありますが、スマートに整理しなくていいのであれば子供にだってできることです。
難しく考えずに、身近なものでイメージしてください。
たとえば
「ガパオライスをつくって」
と急に言われたら、みなさんはいきなり料理に取り掛かれますか？
（あえてメジャーだけどレシピを知らなさそうなところ選んでみましたが）
単一の仕事かのように言われると、多くの人は困ることでしょう。
ですが、分解してみるとどうでしょう。
材料 （2人分）
挽肉（鶏か豚） 200g
玉ねぎ 1/2個
パプリカ 1/2個
バジル 10枚
にんにく 1個
卵 2個
ナンプラー 大さじ１
醤油・オイスターソース 各小さじ１
豆板醤 小さじ1/2
砂糖 小さじ1/2
胡椒・ごま油 各少々
①玉ねぎとにんにくはみじん切り、パプリカは２ｃｍ角に切り、
フライパンにごま油を引いてにんにくと豆板醤を炒める。
②香りが立ってきたら玉ねぎを加えて軽く炒め、挽肉も加えて炒め
ほぼ火が通ったら、パプリカを加えてよく炒める。
③調味料を加えて混ぜ、バジルを加えて軽く炒めたら、火を止めてご飯に添え、
同じフライパンで目玉焼きを作り胡椒を振って添える。
仕事の内容をどんどん分解してみてください。
分解された一つひとつのタスクはそれほど難しいものですか？
そう。
いきなり「〇〇をやれ」と言われるよりも数百倍、数千倍簡単になっているはずです。
優れたマネージャーは必ずこれをします。
優秀な人材の多くも、個人タスクであってもやはり脳内でWBSを描きます。
WBSと気づいていなくても、同じようなことはしているのです。
昨日お話したテーマも、実はこの技術「WBS」があって初めて成立するものだったりします。いえ、ただ闇雲に「やってみる」だけなら猿でもできますが、当然確度の高い成功予測があって始めなければビジネスになりません。
だからこそWBS化して最小単位のタスクを洗い出し、仮に失敗したとしてもほとんど被害らしい被害が生まれない範囲を見定めてから「まずはやってみる」わけです。
私は日頃から「仕事の素因数分解」と呼んでいますが、これが身について即分解できる人とそうでない人とでは、仕事の精度、速さ、成功確率などすべてにおいて雲泥の差が出ます。それくらい基本にして究極のスキルの１つといっても過言ではありません。
WBSでは、まずプロジェクトの成果物をできるだけ細かい単位に分解していきます。
その際、全体を大きな単位に分割してから、それぞれの部分についてより細かい単位に分割していき、階層的に構造化していきます。成果物の細分化が終わったら、それぞれの部分を構成するのに必要な作業（一つとは限らない）を考え、最下層に配置していくことでWBSが作成できます。
これは一言でいうと
仕事内容の具体化
です。
「ビルを建てる」「製品を作る」「料理する」etc.…抽象的なままでは決して行動には起こせません。「ビルを建てる」というタスクは存在しないのです。数多くの小タスクを組み合わせ、積み上げていった結果として「ビル」が建つのですから当然です。
逆に言うと、具体的にできない仕事をそのままにしておけば解釈する人の力量によって問題を内包しかねないということを意味します。ゆえに抽象的な表現しかできない人、抽象的な指示しか出せない人というのは多くのシーン（マンガやアニメ、ドラマなど）においても口先だけで無能なキャラクターだったりするはずです。
そうした背景からも、WBSを定義、作成することはプロジェクトマネジメントにおいて必須というのは間違いないでしょう。
仕事の母体規模が大きければ大きいほどWBSを作成するのは非常に大変なことではありますが、本来はスケジュールの長短に関わらず作成することが望ましいものです。
その理由には大きく５つあり、それぞれがメリットであると同時にWBSを実施しない場合に発生するプロジェクト上の大きな障壁とも密接な関係があります。
作業の抜け・漏れや重複を防げる
部品は、すべてを組み合わせると分解する前の状態に戻ります。
なんとなくでしか分解できない人は、分解した際にできる部品をもう一度組み立てなおしてみてください。どこにも関係しない部品があまったり、逆に部品が足りなくなったりしていませんか？
そういう人はきちんと図表化してみるといいでしょう。
まだ脳内で整理できるだけのレベルにはありません。
最初に挙げるのは、作業の抜け・漏れや重複を防げるメリットです。
WBSでは、トップダウンで論理的に作業や成果物を分解していきます。このため、作業の抜けや漏れ、重複を防ぐことができます。MECEな状態を生み出しやすくなるということですね。
たとえばカレーをイメージしてみてください。
これだと分解もしていない状態ですので、とても漠然としています。
じゃあ、一番簡単な分解をしてみましょう。
さらに分解してみると
…とこのように詳細に落とし込んでいきます。
見てもわかるように漠然と「カレー」と言っていたものが、具体的にはどのような材料で作られていたのか分かるようになっていきますよね。仕事でもこれと同じことをするわけです。
これは、分解するという思考過程そのものが"気付き"を促す効果を与えてくれます。
たとえば、「作業1」と「作業3」を洗い出したとき、
「作業3」を始めるには事前に"資料集め"という「作業2」をしなければいけない
ということに気付くことができます。また、「作業1」と「作業3」は実はよく見ると同じような作業であり、共通化すればどちらか一つを実施しなくて済むこと…なんてことも発見できるかもしれません。
このようにWBSを作成していく過程では、作業計画を洗練させていくことが可能です。
その結果、
「もっと早く手を付けないと間に合わない」
「もっと人が必要だ」
といった未来予測に基づいた判断も、相応の根拠を持って事前に実施することができるようになります。
少なくとも過去にチーム全体あるいは個人であっても、計画を立てる際に１度でもタスクを見逃してしまったなどのミスを起こしたことがある人は、必要だと思っておいた方がいいでしょう。失敗したのち、具体的な解決策を持たずに経験則だけでスケジューリングを行っている人はいつかきっと同じ過ちを冒してしまう危険性をはらんでいます。そしてそれがわかっていても実行しない人は、確信犯的に実施していないのだと断言できます。
また、こうして細分化されたタスクごとに担当を割り当てていくことで要員やリソースの管理も同時に行うことができ、並行してPERT図やガントチャートと並行的に運用していくことでより漏れや抜けの発生しにくいプロジェクトマネジメントが可能となっていきます。
スコープが決まる
２つ目のメリットは、作業や責任のスコープ（範囲）が決まることです。
プロジェクトマネジメントの世界では、WBSを「スコープマネジメント」という領域で扱っています。この中で、WBSで洗い出した作業の範囲は「プロジェクトスコープのベースライン」として定義します。
"ベースライン"という言葉が出てきましたが、これはステークホルダー（利害関係者）の間で合意した判断の基準のことを指します。
実際のプロジェクトでは、計画段階で作成したプロジェクト計画書の中でプロジェクトスコープ（プロジェクト活動としてすべきこと／せざるべきこと）のベースラインを定義します。ここで定義したWBSの作業は「スコープ内」、書かれていない作業は「スコープ外」としてはっきりするわけです。
もしスコープが不明確な状態でプロジェクトがスタートしたら大変なことが起こります。というかＩＴ調停などのトラブルになるのも大抵はこのスコープに起因します。
たとえばスケジュールが遅延したときや、要員が増えたときに発注側（ユーザー）と受注側（開発チーム）で費用を巡ってトラブルになる可能性があります。仮にWBSに書かれたプロジェクトスコープ外の作業によってスケジュール遅延やメンバーの増員が発生したのであれば、これは追加費用が発生することを意味します。
逆に、プロジェクトスコープ内の作業に対応するためのスケジュール遅延や増員であれば原則として追加費用は認められません。
これらのスコープ（対象および対象外）を明確にしないと言うことは、
自社にまたはお客さま（の従業員）に多大な迷惑をかけることを意味します。
図を見ても判るように、WBSはプロジェクトマネジメント知識体系（PMBOK）で定められていると同時に、その中では品質計画のインプットとして用いられることも規定されています。
計画が明確になる
この３つ目の理由は、「管理しやすい」あるいは「しっかりした計画を作成できる」ことを指します。このメリットを得るには、精度の高いWBSを作成していることが前提となりますが、
「誰がやるのか」
「何をやるのか」
「いつやるのか」
「どこまでやるのか」
等、スコープが決まってくれば計画が立てやすくなるのは道理です。少なくとも何も決まっていないカオスな状態から始めるのとでは雲泥の差を感じられることでしょう。
ここでいう計画とは、WBSで定義した作業計画だけではありません。
WBSで定義したスコープはプロジェクトで利用するさまざまな計画のインプット情報となります。裏を返すと、WBSがないとプロジェクトの計画やそれに基づくコントロールができなくなってしまうということです。仕事の具体性が伴わないわけですから、プロジェクトの計画作業とコントロールに支障をきたしていくことになります。
スケジュール作成と進捗の管理
プロジェクトが始まると、スケジュール表が管理の中心となることが多いでしょう。
スケジュール表に記載されている作業項目は、WBSの作業項目そのものです。WBSとスケジュール表の整合を取ることで、プロジェクトの計画と実行がつながります。
細かい作業単位で進捗を把握できれば、管理レベルはグッと向上します。
中にはスケジュール表を作るときに、せっかく作ったWBSをベースにせずに他のプロジェクトのスケジュール表を書き直している人がいます。これでは作業の抜けや漏れの防止など、WBSで解決しようとしたことが振り出しに戻ってしまいます。
役割分担の決定
メンバーの役割を漠然と決めて、柔軟に対応することもあるかもしれませんが、それはよほど臨機応変さを求められるような状況に限ります。
プロジェクトのように目的がはっきり決まっているときは、役割を漠然と決めるよりもWBSを基に各作業に対して担当者を割り当てて、責任を明確にした方がプロジェクトが成功する確率は上がるでしょう。
逆に、漠然とした役割分担などでは必ず「甘えるもの」「苦労するもの」が出てきます。役割や責任を自分事として捉えることができない人が必ずいるからです。
「みんなで」という漠然とした責任スコープしか定めなかった場合、子供のころはともかく大人たちの間ではドロドロとした欲望渦巻く結果にしかなりませんので、注意しましょう。
必要なリソースの洗い出しと割当
リソースとして最も代表的かつ最も管理すべきなのは『人』と『時間』、または『金』と『時間』です。一般的に言われるマネジメント手法CCPMとEVMがまさにそれに当たります。
作業が明確になるとその作業を実施するために必要なスキルが明確になるほか、作業で必要となるハードウエアやツール、開発環境などを洗い出すことができます。必要に応じて調達の計画まで立てることができるでしょう。
たとえば、登山の計画を立てるような場合、WBSの作業項目をベースにすると必要な装備を漏れなく洗い出しやすくなります。着の身着のまま軽装で富士山に登ろうとはしないはずです。
工数やコストの詳細見積り
WBSは、いわゆる「ボトムアップ見積り」と呼ばれる分野で活躍します。
ボトムアップ見積りは、成果物や実施すべき作業を分解し、分解された構成要素や作業項目ごとに所要工数を算出し、それらを積み上げていく手法です。過去の事例や経験から全体の工数を見積もる「類推（トップダウン）見積り」や、基準値や数式から工数を算出する「係数モデル見積り」に比べて、ボトムアップ見積りは高い精度で見積もることが可能です。
見積る対象は作業を分解したものなので工数見積りに利用できるのはもちろん、たとえば作業に必要な機器や事務用消耗品の所要量を見積もる上でも利用できます。
プロジェクトが始まれば、工数（コスト）の実績をWBSの構造を基に集計して、見積もった予定工数（コスト）と対比させて問題点の早期発見につなげることができます。
品質計画とリスクの洗い出し
WBSに書かれたレビューや検証の作業項目は、品質保証の仕組みを検討する上でベースとなります。また WBSの内容はリスクを洗い出すときの貴重な情報源となります。
まだ顕在化していないリスクに先んじて手を打つには、ヒントになる情報をなるべく多く集めることが大切です。具体的な作業イメージをWBSから思い描くことで「ここは大丈夫か」と気配りしながらリスクに気付くことがあります。
ゴールまでの道筋が頭に入っていれば、いざリスクが顕在化したときの対処や判断もスムーズに行えます。
円滑なコミュニケーション
普段からWBSに記述された言葉を使うことによって、チーム内、プロジェクトマネジャーとメンバー間、発注者 と受注者間のコミュニケーションギャップを防ぐ効果があります。
プロジェクトが失敗する原因の一つに、スコープに対する認識の相違が挙げられますが、これはスコープマネジメントのミスではなく、明らかにコミュニケーションマネジメントのミスとなります。
よくこのようなアンケート結果などを例に挙げられることがありますが、これらの原因の背景にはほとんどの場合、「コミュニケーション」に難があることが透けて見えることでしょう。エンジニア個人の思い込みを見逃して問題が起きるのも、十分なコミュニケーションによる情報共有が徹底されていないからにすぎません。
とかくコミュニケーションを疎かにする人は、マネジメントに向いていないといえるでしょう。話せるかどうかは関係ありません。情報や認識をいかにして共有し、またその状態を維持できるかが重要になってくるのです。話すのが苦手なら、メールでもチャットでもドキュメントでもかまいません。
WBSがあれば、コミュニケーション上では少なくともさまざまな『スコープ』について共通の言葉、共有の認識で話せるようになり、多くの齟齬を防げます。
ここで挙げた各計画は、WBSの内容と整合性や連続性を常に持たせることが肝心です。
たとえば、仕様追加に伴ってプロジェクトスコープのベースラインが変わればWBSを修正します。そうしたら、コストのベースラインを変更（追加費用の見積り）し、スケジュールのベースラインも変更（スケジュール表への作業追加）するという流れです。
分解して管理する習慣が身に付く
要するにプロジェクトマネジメントの世界でよく出てくる話題の１つ、古代ローマ帝国の統治方法「分割して統治せよ（Divide and Conquer）」のことです。
大規模なプロジェクトやよく定義されていないプロジェクトは、いくつかの小さなグループに分割すると問題が小さなグループの中に閉じ込められ、特定が容易になり、解決（統治）しやすくなります。
オブジェクト指向の発想とまったく同じですね。
部品化
疎結合化
するのも、「管理をしやすくする」「問題を特定しやすくする」「影響を最小化する」などといった目的で実現されるものですからね。そうして複数の小グループを統治することによって、最終的にプロジェクト全体を統治できるようになるのです。
ちなみにWBSでは「ワークパッケージ（仕事の小単位）」と呼ばれる単位にまで作業を分割します。つまり、WBSの小グループとはこのワークパッケージを指します。
マネジメント上の問題、たとえば"納期"や"コスト"といったトレードオフの関係にある項目間の調整はワークパッケージの単位で解決し、プロジェクト全体に影響が及ぶのを防ぐようにします。
プロジェクトに限らず、大きな仕事や自分が経験したことがない仕事を与えられたらWBSを使ってできるだけ問題を局所化し、対応方法を考える習慣を身に付けることが大切です。
先を予測する習慣が身に付く
これは、プロジェクト管理において最も重要だと感じている部分です。
プロジェクトを遂行する上で極めて大切なリソースは「時間」です。お金は使わなければ残るし、いざとなれば他から調達することもできます。しかし、時間はそうはいきません。"過ぎ去った時間を取り返すことはできない"のです。
だからこそ、時間を無駄にしないためにプロジェクトの「先を読む」ことで無駄を省いたり、手戻りを減らしたりといった習慣がプロジェクトマネージャー、ひいてはエンジニア一人ひとりに求められます。
WBSは、ゴールまでの道筋を考えながら作成します。
既に実施した作業を洗い出すのではなく、将来実施する作業を洗い出すわけです。
WBSの作成を経験 すると、自然と先を読むという習慣が身に付くはずです。
実際に洗い出していると
「思っていたより大変！」
「なんだ、これとこれをやればいいのか」
という意識を持ちながら仕事を進めていくようになります。
先を見る習慣は、何もプロジェクトの中だけで有効なわけではありません。
普段のどんな仕事でも、先を見て時間をうまく使えると作業の効率が高まります。
現在、日本のソフトウェア開発にかかるプロジェクトは、品質、納期、コストのいずれの側面も、バランスよく及第点に至っているプロジェクトはまだ多くないようです。ここ最近は少しずつ成功プロジェクトも増えてきているようですが、到底ほかの業界に自慢できるような数値ではありません。
こういった状況に、企業も手をこまねいているわけではありません。こまねいている…わけではない…はず…たぶん（…ｱﾚ？ﾐﾀｺﾄﾅｲﾅ…）
PMBOK（ISO 21500）やISO 10006などのプロジェクト管理の方法論を適用し、改善を試みているようですが、徐々に改善はみられているものの、劇的に効果が上がったといった話はなかなか聞きません。
それはなぜか。
その理由はいくつかありますが、その理由の１つとしていずれの方法論でも
「プロジェクトの分解・構造化（WBSの作成）」
という極めて初歩的であるがゆえにおざなりにされてきたプロジェクトが非常に数多く存在しており、その精度の低さによってプロジェクト管理の結果が大きく左右されてしまうことが挙げられます。
通常のプロジェクト管理の方法論は、
プロジェクトの分解・構造化（WBSの作成）
プロジェクトに必要な全タスクの前後関係、平行関係を明らかにする
タスクの関係性を崩さないスケジュールの作成
マネジメント（監視、コントロール）
と順を追って進めるものですが、プロジェクトの分解・構造化が非常に軽視されているためWBSの精度が低く、結果として進捗管理に大きな影響が出るのです。
知識ゼロからタスクを分解して整理するのは難しいかもしれませんが、ソフトウェア開発の流れ自体は
「パッケージ製品」
「組込み系システム」
「業務系システム」
等、ある程度分類化してしまえばベースラインに大きな差は生まれません。ユーザー側の業界や業務知識も体系立てればある程度のグループにサマリすることが可能です。
経験を積めば積むほど、その経験をしっかりと活かせば活かすほど、過去振り返って作成することは容易なはずなのに、過去を振り返ることなく毎度新しいプロジェクトに無策でぶつかろうとするから苦労しているにすぎません。
プロジェクトが終了した後でもいいので、順調に進めることができた作業はWBSのベースラインとして残しておくことを推奨します。ベースラインさえ作成してしまえば、タスクの要否を取捨選択していくことで以降のWBSの精度は格段に向上することでしょう。
とは言え、WBSの作成はプロジェクトマネジメントのほんの入り口です。
WBSは全てのプロジェクトマネジメントの起点となりうる重要なものですが、それだけでプロジェクト管理が問題なく行えるものではありません。こうしたタスク分割にTOC（Theory of Constraints：「制約条件の理論」）の概念を取り込むことでより精度の高い、より問題の発生しにくいマネジメントの実現も可能となるでしょう。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。