--- title: ④WBSの作り方（複数名編）.pptx tags: author: [Yukiko](https://image.docswell.com/user/yukiko_it) site: [Docswell](https://www.docswell.com/) thumbnail: https://bcdn.docswell.com/page/DJY4QDG47M.jpg?width=480 description: ④WBSの作り方（複数名編）.pptx by Yukiko published: August 10, 26 canonical: https://image.docswell.com/s/yukiko_it/Z8NLM1-2026-08-10-231330 --- # Page. 1 ![Page Image](https://bcdn.docswell.com/page/DJY4QDG47M.jpg) うさうさ研修工房 実践ガイド WBSの作り方 複数名で作る実践ガイド 査読済み研究にもとづく、チームで精度を高める分解のつくり方 エビデンスベース設計 うさうさ研修工房 | YUKIKO ファシリテーション手順付き 視認性の高いレイアウト # Page. 2 ![Page Image](https://bcdn.docswell.com/page/V7NYK6G6E8.jpg) 01 BASIC WBSとは何か： 3つの基本原則 WBS（Work Breakdown Structure）は、プロジェクトの成果物を階層的に分解し、実行可能な単位（ワークパッケージ）に落とし込む手法。PMBOKでは「プロ ジェクトチームが実行する作業の階層的な分解」と定義される。 100%ルール 相互排他性 成果物ベース 各レベルの合計が、上位レベルの範囲を100%網 羅する（過不足なし） 要素同士が重複せず、担当と責任の境界が明 確である 作業手順ではなく「何を生み出すか」を軸に分解 する 01 BASIC / WBSの基本原則 2 # Page. 3 ![Page Image](https://bcdn.docswell.com/page/YJ9PVLWR73.jpg) 02 WHY なぜ「一人」ではなく「複数名」で作るのか WBSのパターンは、組織や成果に影響する 同じプロジェクトでも、 WBSの分解パターンは複数成立しうる。 Globerson（1994） チームで作る 3つの利点 は、選ぶパターンによって必要な組織構造やマネジメントスタイルが変わることを 示した。一人の視点だけで作ると、特定の切り口に偏りやすい。 抜け漏れの発見 複数名で作業を持ち寄ることで、抜け漏れ・重複・偏りに気づきやすくなり、後工 各メンバーが異なる作業を想起するため、網羅性が上がる 程（見積り・体制設計）の精度も上がる。 当事者意識の醸成 自ら定義した作業には責任と納得感を持ちやすい 「WBSはプロジェクトの分類体系（taxonomy）であり、異なるWBSパターンは異なる組織構造とマネ ジメントスタイルを要求する」（Globerson, 1994, IJPM） 合意形成の土台 見積り・体制・スケジュールの前提を関係者間で共有できる （Jones, 2007, PMI Global Congress） 02 WHY / 複数名で作る理由 3 # Page. 4 ![Page Image](https://bcdn.docswell.com/page/GJ8DPXNGJD.jpg) 03 CAUTION 一人で作る WBSに起きがちな落とし穴 Jones（2007）は、多くのプロジェクトマネージャーがチームを巻き込まずWBSを場当たり的に作成し、結果として精度と実行段階での納得感を損なっていると指摘す る。 得意領域への偏り 抜け漏れに気づけない 作成者が詳しい工程は細かく、不慣れな工程は粗くなる 一人の知識では想定できない作業が漏れる 現場の納得感が薄い 見積りの独りよがり 与えられた計画への当事者意識が育ちにくい 第三者チェックがないまま工数が確定してしまう 「多くのプロジェクトマネージャーは、チームの関与や上位管理職の支援を伴わずにWBSを場当たり的に作成している」（Jones, 2007, PMI Global Congress） 03 CAUTION / 単独作成の落とし穴 4 # Page. 5 ![Page Image](https://bcdn.docswell.com/page/LJLM18PXER.jpg) 04 PROCESS 複数名で作る： 5つの作成ステップ 1 2 3 4 5 目的・スコープ共有 個々に分解 持ち寄り・統合 重複・漏れの確認 合意形成・承認 何を・どこまで作るか全員で認識 合わせ 各自が担当・専門領域から作業を 洗い出す 個々の分解結果を1つのツリーに 統合する 100%ルールで網羅性と排他性を 検証 最終形を全員でレビューし承認を 得る 04 PROCESS / 作成の5ステップ 5 # Page. 6 ![Page Image](https://bcdn.docswell.com/page/47MYW6437W.jpg) 05 METHOD 会議設計のモデル： Wideband Delphi式 ソフトウェア分野で広く使われる集団見積り技法。WBS作成を「キックオフ会議」と「見積りセッション」の2段階に分け、個人の思い込みや声の大きい人への偏りを防 ぐ設計になっている。 チーム編成 ①キックオフ会議 • ファシリテーター1名＋メンバー3〜7名 • 目的・前提を共有し、その場でWBSを作成 • 関連工程の代表者を必ず含める • 各自が思いつく作業と前提条件を出し合う 個別見積り ②見積りセッション • 会議後、各自がタスクごとに工数を独立して見積る • 見積り結果を共有し、差異について議論 • 他者の見積りを見ずに行うことでバイアスを回避 • 合意が取れるまで反復し、最終版を確定 05 METHOD / Wideband Delphi式 6 # Page. 7 ![Page Image](https://bcdn.docswell.com/page/P7R9YPWRE9.jpg) 06 RULE 重複と漏れを防ぐ： 100%ルールの徹底 持ち寄った分解を統合するときのチェック観点 網羅性（ 100%） 上位レベルの範囲を、下位要素の合計が過不足なくカバーして いるか 統合ミーティングの進め方 ・各自の分解結果をカード化し、模造紙やホワイトボードに並べ る ・重複するカードは統合し、担当者間で認識をすり合わせる 相互排他性 同じ作業が2つの要素にまたがって定義されていないか ・空白（誰も出していない領域）がないか全員で見渡す ・最後に発注者・上位管理職の視点でレビューを受ける 粒度の一貫性 同じ階層の要素同士で、詳細度の粗密が揃っているか 成果物ベース 「〜する」という作業名ではなく、成果物・納品物で命名されてい るか 06 RULE / 100%ルールの徹底 7 # Page. 8 ![Page Image](https://bcdn.docswell.com/page/PJXQG3PY7X.jpg) 07 ROLES 誰が何をするか：役割分担とファシリテーション ファシリテーター（ PM） メンバー（各領域の担当者） 上位管理職・スポンサー 目的・スコープの提示、進行管理、最終統合の合意 形成をリードする 自分の専門・担当範囲の作業を洗い出し、見積りに 責任を持つ 完成したWBSをレビューし、スコープと体制の妥当性 を承認する 「効果的なWBS作成を通じてプロジェクトマネージャーが果たすべきリーダーシップの役割」を体系化する必要がある（Jones, 2007, PMI Global Congress） 07 ROLES / 役割分担 8 # Page. 9 ![Page Image](https://bcdn.docswell.com/page/3JK94YD4JD.jpg) 08 DESIGN 「伝わる」 WBS資料に仕上げる 4つの視点 階層をツリーで可視化 コード体系を統一 担当者を明記 粒度を視覚的に揃える レベル1〜3の親子関係を、線ではなく色 と余白で示す 1.1 / 1.1.1のような番号で、階層と親子を 一目で判別できるようにする 各ワークパッケージの右肩に担当アイコ ン・氏名を添える カードの大きさ・情報量を同一階層で統一 し、粗密のばらつきを防ぐ 08 DESIGN / 視認性を高める設計 9 # Page. 10 ![Page Image](https://bcdn.docswell.com/page/LE3WL9RDE5.jpg) 09 TEMPLATE WBS構成イメージ：レベル 1〜3の例 1.0 プロジェクト全体 1.1 要件定義 1.2 設計・開発 1.3 テスト・納品 1.1.1 業務要件ヒアリング 1.2.1 画面設計 1.3.1 結合・受入テスト 1.1.2 要件定義書作成 1.2.2 実装・単体テスト 1.3.2 本番リリース ※ワークパッケージ（レベル3）には、担当者・見積り工数・完了基準をひもづける 09 TEMPLATE / 構成イメージ 10 # Page. 11 ![Page Image](https://bcdn.docswell.com/page/8EDKNGY27G.jpg) 10 PITFALLS 複数名で作るときのよくある失敗と対策 声の大きい人の意見に偏る 個別見積り→持ち寄りの順で進め、匿名的に意見を出す場を作る 粒度がバラバラになる 統合時に「同じ階層は同じ詳細度」というルールを明示する 作業ベースで命名してしまう 「〜する」ではなく成果物・納品物の名詞で書くルールを共有する レビューだけで終わり修正されない 統合ミーティングの場でその場修正・即時合意を原則にする 10 PITFALLS / 失敗と対策 11 # Page. 12 ![Page Image](https://bcdn.docswell.com/page/V7PK536LJ8.jpg) まとめ：複数名 WBS 作成チェックリスト 目的・スコープを全員で認識合わせしたか 各自が個別に作業を洗い出す時間を確保したか 持ち寄り時に100%ルールで網羅性を確認したか 同一階層で粒度・命名が揃っているか 担当者・見積り工数をワークパッケージに紐付けたか 上位管理職・スポンサーの承認を得たか 面白きこともなき世を面白く 🐰 うさうさ研修工房 # Page. 13 ![Page Image](https://bcdn.docswell.com/page/2JVVP436JQ.jpg) APPENDIX 参考文献（査読済み論文・実務研究） 1 Globerson, S. (1994). Impact of various work-breakdown structures on project conceptualization. International Journal of Project Management, 12(3), 165-171. DOI: 10.1016/0263-7863(94)90032-9 2 Jones, C. (2007). Creating an effective WBS with facilitated team involvement. Paper presented at PMI® Global Congress 2007—North America, Atlanta, GA. Project Management Institute. 3 Dvir, D., Raz, T., & Shenhar, A. J. (2003). An empirical analysis of the relationship between project planning and project success. International Journal of Project Management, 21(2), 89-95. DOI: 10.1016/S0263-7863(02)00012-1 4 McConnell, S. (1996). Rapid Development: Taming Wild Software Schedules. Microsoft Press.（Wideband Delphi見積り手法） 5 Zwikael, O. & Globerson, S. (2004). Evaluating the quality of project planning: A model and field results. International Journal of Production Research, 42(8), 1545-1556. DOI: 10.1080/00207540310001639955 APPENDIX / 参考文献 13