「WBSを作れと言われたけど、何から手をつければいいかわからない」
プロジェクト計画で最も時間がかかるのは、実はWBSを書く作業ではありません。その前段階の「何をやるべきか」を洗い出す整理です。
この記事では、マインドマップを使ってWBS前の整理を最短で終わらせる方法を解説します。テンプレート付きなので、今日から使えます。
WBS前にやるべき整理とは
WBS（Work Breakdown Structure）は、プロジェクトを作業単位に分解した一覧表です。しかし、いきなりWBSを書き始めると、こんな問題が起こります。
よくある失敗パターン
- 抜け漏れが後から発覚 → 手戻り発生
- 粒度がバラバラ → 見積もりが崩壊
- 依存関係が見えない → スケジュール破綻
WBS前に整理すべき4要素
| 要素 | 整理する内容 |
|---|---|
| 成果物 | 最終的に何を作るのか |
| 作業 | 成果物を作るために必要なタスク |
| 期限 | いつまでに何を終わらせるか |
| リスク | 何が起きたら計画が狂うか |
この4要素をマインドマップで可視化してからWBSに落とすと、抜け漏れが激減します。
型（成果物→作業→期限→リスク）
プロジェクト計画のマインドマップには、再現性のある型があります。この型を使えば、どんなプロジェクトでも同じ手順で整理できます。
ステップ1: 中心に「プロジェクト名」を置く
まず、プロジェクトの名称を中心に配置します。ここが起点です。
ステップ2: 4つのメイン枝を伸ばす
中心から以下の4枝を伸ばします。
[成果物]
│
[リスク] ── [プロジェクト名] ── [作業]
│
[期限]
ステップ3: 各枝を展開する
成果物の枝: 最終アウトプットを具体的に書き出す
成果物
├── システム本体
│ ├── 画面A
│ ├── 画面B
│ └── API
├── ドキュメント
│ ├── 要件定義書
│ ├── 設計書
│ └── テスト仕様書
└── 教育資料
├── マニュアル
└── 研修スライド
作業の枝: 成果物を作るために必要なタスクを洗い出す
作業
├── 要件定義
├── 設計
├── 開発
├── テスト
├── リリース準備
└── 移行作業
期限の枝: マイルストーンを設定する
期限
├── 要件FIX: 4/30
├── 設計完了: 5/31
├── 開発完了: 7/31
├── テスト完了: 8/31
└── リリース: 9/30
リスクの枝: 想定されるリスクを洗い出す
リスク
├── 技術リスク
│ ├── 新技術の習得遅れ
│ └── 性能問題
├── 人員リスク
│ ├── メンバー離脱
│ └── スキル不足
└── 外部リスク
├── 要件追加
└── 他システム連携遅延
手順（15分で完成させる5ステップ）
実際にマインドマップを作る具体的な手順を説明します。
ステップ1: 成果物を書き出す
- 1. プロジェクト名を中央に置く
- 2. 「成果物」の枝を伸ばす
- 3. 最終的に納品するものをすべて書き出す
- 4. 各成果物をさらに分解する
ポイント: 「これがないと完了と言えないもの」を基準にする
ステップ2: 作業を洗い出す
- 1. 「作業」の枝を伸ばす
- 2. 成果物ごとに「何をすれば作れるか」を書き出す
- 3. フェーズ（要件→設計→開発→テスト→リリース）で整理
ポイント: この段階では粒度を揃えなくてOK。まず出し切る
ステップ3: 期限を設定する
- 1. 「期限」の枝を伸ばす
- 2. 外部から決められた期限（納期、中間報告など）を先に書く
- 3. 逆算してマイルストーンを設定
ポイント: 「これを過ぎたら危険」という警告日も入れておく
ステップ4: リスクを洗い出す
- 1. 「リスク」の枝を伸ばす
- 2. 「もし〜が起きたら計画が狂う」を書き出す
- 3. 技術・人員・外部の3カテゴリで考える
ポイント: 対策は後で考える。まずは洗い出しに集中
ステップ5: 全体を見渡して調整する
- 1. 4枝のバランスを確認
- 2. 成果物と作業の対応が取れているか確認
- 3. 期限とリスクの関係を確認
コピペ用プロジェクト計画テンプレート
そのまま使えるテンプレートを用意しました。コピーしてマインドマップツールに貼り付けてください。
汎用プロジェクト計画テンプレート
プロジェクト名: [ここに記入]
├── 成果物
│ ├── メイン成果物
│ │ ├── [成果物A]
│ │ ├── [成果物B]
│ │ └── [成果物C]
│ ├── ドキュメント
│ │ ├── 要件定義書
│ │ ├── 設計書
│ │ └── マニュアル
│ └── その他
│ └── [必要に応じて追加]
│
├── 作業
│ ├── 企画フェーズ
│ │ ├── 要件ヒアリング
│ │ ├── 要件定義
│ │ └── 見積作成
│ ├── 設計フェーズ
│ │ ├── 基本設計
│ │ └── 詳細設計
│ ├── 開発フェーズ
│ │ ├── 実装
│ │ └── 単体テスト
│ ├── テストフェーズ
│ │ ├── 結合テスト
│ │ └── 受入テスト
│ └── リリースフェーズ
│ ├── 本番環境準備
│ └── リリース作業
│
├── 期限
│ ├── マイルストーン1: [日付]
│ ├── マイルストーン2: [日付]
│ ├── マイルストーン3: [日付]
│ └── 最終納期: [日付]
│
└── リスク
├── 技術リスク
│ ├── [リスク1]
│ └── [リスク2]
├── 人員リスク
│ ├── [リスク3]
│ └── [リスク4]
└── 外部リスク
├── [リスク5]
└── [リスク6]
Webサイト制作プロジェクト例
コーポレートサイトリニューアル
├── 成果物
│ ├── Webサイト
│ │ ├── トップページ
│ │ ├── サービス紹介
│ │ ├── 会社概要
│ │ ├── お問い合わせ
│ │ └── ブログ機能
│ ├── ドキュメント
│ │ ├── ワイヤーフレーム
│ │ ├── デザインカンプ
│ │ └── 運用マニュアル
│ └── その他
│ ├── ドメイン設定
│ └── サーバー設定
│
├── 作業
│ ├── 企画
│ │ ├── 現状サイト分析
│ │ ├── 競合調査
│ │ └── 要件定義
│ ├── 設計
│ │ ├── サイトマップ作成
│ │ └── ワイヤーフレーム作成
│ ├── デザイン
│ │ ├── デザインカンプ作成
│ │ └── デザインレビュー
│ ├── 開発
│ │ ├── フロントエンド実装
│ │ ├── CMS構築
│ │ └── フォーム実装
│ ├── テスト
│ │ ├── 表示確認
│ │ ├── 動作確認
│ │ └── 本番環境テスト
│ └── リリース
│ ├── DNS切り替え
│ └── 旧サイトリダイレクト
│
├── 期限
│ ├── 要件FIX: 1週目
│ ├── デザイン確定: 3週目
│ ├── 開発完了: 6週目
│ ├── テスト完了: 7週目
│ └── 公開: 8週目
│
└── リスク
├── 技術
│ └── CMS習熟不足
├── 人員
│ └── デザイナー繁忙
└── 外部
├── 原稿遅延
└── 仕様追加
スコープ漏れチェックリスト
マインドマップを作った後、以下のチェックリストで抜け漏れを確認してください。
成果物チェック
- 顧客に納品するものは全部入っているか
- 社内承認に必要なドキュメントは入っているか
- 教育・引き継ぎ資料は必要か
- 環境構築（本番・検証・開発）は含まれているか
作業チェック
- 各成果物に対応する作業があるか
- レビュー・承認の作業は入っているか
- 移行作業（データ移行、切り替え）は含まれているか
- 社内調整・会議の時間は考慮しているか
期限チェック
- 外部から決められた期限は反映しているか
- レビュー・修正のバッファは取っているか
- 他プロジェクトとの競合はないか
- 休暇・繁忙期は考慮しているか
リスクチェック
- 「これが起きたら終わり」レベルのリスクは把握しているか
- 過去のプロジェクトで起きた問題を参考にしたか
- 外部依存（他チーム、顧客、ベンダー）のリスクは洗い出したか
- 対策・代替案は最低限考えているか
共有・レビューのコツ
マインドマップで整理した内容を、チームや上司に共有する際のポイントを解説します。
共有のタイミング
| タイミング | 目的 | 共有形式 |
|---|---|---|
| 計画初期 | 方向性の合意 | 画面共有でウォークスルー |
| 計画完了後 | 承認取得 | PDF出力して添付 |
| 定例会議 | 進捗確認 | 更新箇所をハイライト |
レビューで聞くべき3つの質問
- 1. 「これで全部ですか？」 → スコープ漏れを防ぐ
- 2. 「この順番で大丈夫ですか？」 → 依存関係の確認
- 3. 「他に心配なことはありますか？」 → 隠れたリスクの発見
効果的な見せ方
- 階層を折りたたんで見せる — 最初は全体像、質問に応じて展開
- 色でステータスを示す — 確定=緑、検討中=黄、リスク=赤
- 変更履歴を残す — 前回からの差分がわかるように
レビュー後のアクション
- 1. 指摘事項をその場でマインドマップに追記
- 2. 合意した内容にマーク（色を変える）
- 3. 宿題事項を別枝で管理
MindTreeのメリットが出る場面
プロジェクト計画のマインドマップを作るツール選びで、MindTreeが特に力を発揮する場面を紹介します。
機密性の高いプロジェクト計画
プロジェクト計画には、予算、人員配置、リスク情報など社外に出せない情報が含まれます。
MindTreeは完全ローカル保存。クラウドにデータを送信しないため、セキュリティポリシーが厳しい企業でも安心して使えます。
オフライン環境での作業
出張先、移動中、セキュリティエリア内など、ネット接続がない環境でも問題なく作業できます。
オートセーブ機能（デフォルト30秒間隔）で、保存忘れの心配もありません。
複数形式での書き出し
プロジェクト計画は、さまざまな形式で共有する機会があります。
| 用途 | 書き出し形式 |
|---|---|
| メール添付 | |
| 資料への貼り付け | PNG, SVG |
| 議事録への転記 | Markdown |
| 他ツールへの移行 | OPML |
MindTreeはPNG, JPG, PDF, SVG, Markdown, OPMLに対応。用途に応じて使い分けられます。
こんな人にMindTreeは向いている
- プロジェクト情報をクラウドに置きたくない
- 社内ネットワークでしか作業できない環境がある
- 月額課金ではなく買い切りで使いたい
- 複数形式で書き出す機会が多い
当てはまる項目が1つでもあれば、MindTreeを検討する価値があります。
よくある質問（FAQ）
Q1: マインドマップで整理した後、WBSへの変換は手作業ですか？
A: 基本的には手作業になりますが、マインドマップで構造化しておけば、WBSへの転記は「並べ替え」だけで済みます。Markdown形式で書き出せば、テキストベースで編集できるため、ExcelやWBSツールへのコピペも簡単です。整理済みの情報を転記するだけなので、ゼロから作るより圧倒的に早く終わります。
Q2: チームメンバーがマインドマップに慣れていない場合、どうすればいいですか？
A: 最初のミーティングで、画面共有しながら一緒に作るのが効果的です。「成果物は何ですか？」「作業は何が必要ですか？」と質問しながら枝を伸ばしていけば、自然と理解してもらえます。完成したマップはPDFで共有すれば、ツールを持っていない人でも見られます。
Q3: プロジェクト規模が大きい場合、1つのマップで管理できますか？
A: 大規模プロジェクトでは、階層を分けるアプローチをおすすめします。全体計画は1枚のマップで俯瞰し、各フェーズや担当領域ごとに詳細マップを作成します。全体マップには「詳細は別マップ参照」と記載し、ファイル名で紐づけて管理するとスムーズです。
まとめ
プロジェクト計画をマインドマップで整理すると、WBS作成前の「何をやるべきか」が15分で可視化できます。
ポイントは3つ。
- 1. 型を使う: 成果物→作業→期限→リスクの4枝構造
- 2. 出し切ってから整える: 最初は粒度を気にせず洗い出す
- 3. チェックリストで漏れを防ぐ: 完成後にスコープ漏れを確認
テンプレートをコピーして、次のプロジェクトから試してみてください。
関連記事
あわせて読みたい:
コメント