現場で使える!WBSの作成手順とそのコツ 【PMの道具箱#4】
みなさん、こんにちは!
今回はWBSの作成です。
今までなんとなくWBSを作っていた方、部下にWBSの作り方を教えたい方、はじめてプロジェクトマネージャーになりWBSの作り方に迷っている方必見です。
WBSを作成する手順をコツと共に説明します。
はじめに
WBSとは
WBS とは「 Work Breakdown Structure 」(作業分解構造)の略称です。
Work
プロジェクト目標を達成するために必要な作業をBreakdown
漏れなく要素分解したStructure
上位から下位に階層的に詳細化した構造
構造化(Structure)とは
「成果物」と「作業(プロセス)」で要素分解し可視化することです。
構造化された状態の例
ソフトウェア開発(ウォーターフォールでは)下図のようなツリー形式で表現されます。(Lv6が成果物、それ以外は作業)
2種類のWBS作成アプローチとその違い
本稿では成果物指向とよばれる、成果物を中心に考えるアプローチを推奨しています。これは、最初に成果物を定義し、次に成果物を作成する作業(プロセス)を定義する進め方です。
一方、作業(プロセス)を中心に考えるプロセス指向という進め方もあります。こちらは作業(プロセス)を先に考え、次に成果物を定義します。
システム開発を例にすると、プロセス指向では、まず要件定義・基本設計・実装に大きく分解します。次に要件定義を業務要件定義とシステム要件定義、基本設計を画面設計とバッチ設計などに分解します。最後に業務要件定義では業務フロー、システム要件定義でユースケースと成果物を設定します。
このようにプロジェクトを作業の観点で細分化してから、各作業の成果物を決める進め方です。
一方、成果物指向はプロジェクトのゴール時点で作成されているであろう、成果物の全体像を先に定義し、そこから逆算して作業を決める。という違いがあります。
成果物指向のメリット
本稿で推奨する成果物指向のアプローチをプロセス指向と比較すると3つの利点があります。
①ステークホルダーと合意形成しやすい
スコープをステークホルダが実際に見る「成果物」を示すため、作業(プロセス)で語るよりステークホルダーのイメージが湧きやすく、合意形成に役立ちます。
②作業が膨らみづらい
作業だけでは完了の状態がステークホルダーとズレることが多く、作業が膨らむリスクが高くなります。一方、作業の完了条件を成果物にすればステークホルダー間で作業内容のズレがおきづらく作業工数が安定します。
③抜け漏れが発生しづらい
作業間の繋がりを成果物の構造(繋がり)を可視化することで、成果物の抜け漏れがチェックできます。
後から作業のInput(成果物)の不足に気付くことを防げます。
逆に、本稿の成果物指向のデメリットは、最初に成果物全体を定義しなければならない点です。しかし、その手間と比較しても上記のメリットの方が大きいため、本稿では成果物指向のアプローチを推奨しています。
1.成果物全体を可視化する
以降では、システム開発プロジェクトを例に説明を進めます。
1-1.成果物の構成とそれぞれの繋がりを可視化
まず、成果物関連図を作成します。
所属している会社や顧客でソフトウェア開発標準がある場合はそれを使います。
1−2.成果物の調整(成果物のテーラリング)
さあ、成果物の素案ができあがりました。ここからが腕の見せ所です。
1-2-1.総作業量を試算する
成果物毎にそのボリューム(本数)と1本当たりの標準的な作成工数を設定し総作業量を試算します。
1-2-2.成果物をダイエットする
試算した結果、予算内であればそのままでも良いでしょう。
が、あれもこれもと定義していくと、予算を超えると思いますので、最低限の成果物にダイエットさせます。
1-2-3.スコープ(機能)を減らす
上記のダイエットをしてもまだ予算超過している場合は、スコープ(やりたい事)の削減を検討します。
ここで、ビジネスサイドからスコープ削減が許可されることはまれだと思います。(大体の場合、「頑張れ」「生産性上げろ」となりがちです。)
しかし、事前に早い段階でステークホルダーに規模感を伝えることで、短期間で実行するリスクを会話できるため、成果物の可視化は有効的なアプローチになります。
2.プロセスを定義する
ここまでで成果物が定義できました。ここからは、成果物を作る作業(プロセス)を考えます。
2-1.全体のアプローチを決める
プロジェクトの特性にもとづき、全体のアプローチを決めます。
たとえば、とにかく早く世に出したいWebサービス系のシステム開発であれば、最小限の重要な機能を優先的に作成し、それ以外の機能を別フェーズで作成する。などです。(下図:Lv2)
2-2.成果物の作成プロセスを定義する
まず、「1-1.成果物の構成とそれぞれの繋がりを可視化」で作成した成果物関連図の各成果物をどういった作業で作るか成果物関連図上で分類します。
次にその分類をWBSツリーに当てはめます。
下図のWSBツリーでは、成果物をLv6、成果物を作成するプロセスをLv3〜5で定義します。
最後に成果物をアウトプットするプロセスをLv7に定義します。
下図では、ドラフトを作成⇒レビューを実施⇒レビューの指摘内容を修正し、修正確認をして完成。というプロセスにしています。
最後に、プロセスを設計する時に注意が必要なことが1つあります。
それは、最初から全体を成果物のアウトプットプロセスのレベルに落とさない。ということです。(上記のWBSツリー(Lv7))
人は細かくすればするほど“管理の精度が上がる”と錯覚し、さらにやりきった感も生まれます。真面目な人ほど詳細化をしがちです。特にウォーターフォール型のアプローチを取った際にこの罠にはまりがちです。
しかし、未来になればなるほど不確実性は高くなります。
せっかく、精密に作成したWBSがメンテナンスしきれず、形骸化し利用されなくなったり、ひたすら修正するはめになったことはないでしょうか?
これを防ぐコツは、プロセス定義は直近の活動までにとどめ、未来の活動を段階的詳細化(progressive elaboration)する、ローリングウェイブ技法を使うことです。
おわりに
WBSは成果物+プロセスという複合的な情報から成り立ちます。
作業がなんとなく見通せている状況におかれると、見えている情報から、ついプロセス指向でWBSを作成したくなります。しかし、作業開始後に抜け漏れが見つかると手戻りが発生します。
急がば回れ。はじめは成果物を可視化することから始めましょう。
もちろん先に作業(プロセス)の枠組をきめて、最小の成果物を定義するというトップダウンのアプローチを否定はしません。しかし、このアプローチで抜け漏れのないWBSとスケジュールを作成できる人は、その領域での経験が豊富な熟練のPMです。慣れないうちは本稿で説明したボトムアップの成果物指向のアプローチで始めることをお勧めします。
この「現場で使える!コンサル道具箱」では、その名の通りすぐに現場で使えるコンテンツを無料でご提供している note です。あなたの欲しい道具が探せばあるかも?ぜひ他の記事もご覧ください!
ウルシステムズでは「現場で使える!PM道具箱」でご紹介したコンテンツにまつわる知見・経験豊富なコンサルタントが多数在籍しております。ぜひお気軽にご相談ください。