「WBSは”動詞”で始まる」という原則——タスク設計の言語を変えることで、チームの動き方を根本から変える実践技法

＜目次＞

WBSをめぐる「見えにくい問題」
なぜ「動詞起点」のタスク設計が重要なのか
1. 動詞がタスクに「完了条件」を内包させる
2. 名詞タスクが生む「見えない手戻り」
WBSの動詞設計：3つの実践原則
WBSを「活用し続ける」ための1つの習慣
言語を変えると、チームが変わる

WBSをめぐる「見えにくい問題」

WBSを作ること自体は、多くのプロジェクトマネージャーが経験している。しかし、「作ったのに機能しない」という声は絶えない。

その原因を探ると、意外なところに行き着く。WBSに書かれた言葉の問題だ。

たとえば、以下のようなタスク名をよく目にする。

「要件定義」
「設計書」
「ユーザーテスト」
「関係者調整」

これらに共通するのは、名詞で書かれているという点だ。名詞のタスクは「何があるか」は示しても、「何をするか」を示していない。担当者は無意識のうちに「何をどこまでやればいいのか」を自分で解釈し始める。その解釈のばらつきが、後々のズレや手戻りの温床になる。

本記事では、WBSの言語設計という切り口から、タスクを「動かせる粒度と表現」に変えるための実践技法を解説する。

なぜ「動詞起点」のタスク設計が重要なのか

動詞がタスクに「完了条件」を内包させる

「要件定義」という名詞タスクに対し、「顧客と要件を合意し、要件定義書にサインをもらう」と動詞で書き直すと、何かが変わる。完了の定義が言葉の中に宿るのだ。

動詞起点のタスク設計には、次の構造が自然と組み込まれる。

誰が：主語が意識される
何を：対象物が明確になる
どうする：動詞が行動を規定する
どうなれば終わりか：完了条件が言葉に滲み出る

プロジェクトの遅延原因を分析すると、「タスクが完了したかどうかの判断が人によって異なる」というケースが驚くほど多い。動詞起点の言語設計は、この曖昧さを構造的に排除する。

名詞タスクが生む「見えない手戻り」

「設計書」というタスクが完了したとする。だが、レビューで「これは設計書の体裁になっていない」「内容が浅い」という指摘が出る。担当者は「作ったのに」と感じ、PMは「なぜ確認しなかった」と感じる。

これは能力の問題ではなく、タスクの言語が完了条件を持っていなかったという設計の問題だ。「レビュー担当者から承認を得た設計書を作成する」と書かれていれば、担当者は最初からレビューを意識した動き方をする。

WBSの動詞設計：3つの実践原則

原則1：タスク名は「動詞＋目的語＋完了条件」の形で書く

理想のタスク名のフォーマットは次の通りだ。

「〜を〜して、〜の状態にする」

具体例で比較してみよう。

名詞タスク（Before）	動詞タスク（After）
ユーザーインタビュー	対象ユーザー5名にインタビューし、課題仮説を検証する
システムテスト	テストケース全件を実行し、重大バグゼロの状態で完了報告する
関係者調整	営業・開発・法務の三者から仕様変更への合意を書面で取得する

「After」の表現は長く感じるかもしれないが、長さではなく明確さが重要だ。タスク名が完了条件を内包することで、担当者は「自分が何をやり切ればいいか」を自律的に判断できる。

原則2：分解の粒度は「1人が1週間以内で完了できる単位」を目安にする

WBSの分解が粗すぎると、進捗が見えない。細かすぎると、管理コストが上がりチームが疲弊する。

実務での目安として有効なのが、「1人が1週間以内で完了できるタスク」という粒度だ。これにより、週次の進捗会議でタスクの完了・未完了を明確に報告できる。「80%完了」という曖昧な状態が出にくくなる。

もし1週間を超えるタスクが残るなら、さらに分解できるはずだ。「設計書を作成する（3週間）」は、「骨格となる章立てを確定する」「各章の初稿を書く」「レビューコメントを反映し最終版にする」という3タスクに分解できる。

原則3：WBSのレビューは「動詞の一覧を声に出して読む」ことで行う

WBS完成後のセルフチェックとして、タスク名の動詞だけを抜き出して声に出して読むという方法が効果的だ。

「確認する、作成する、調整する、実施する……」と並べたとき、どれも似たような動詞ばかりなら、タスクが十分に具体化されていないサインだ。「合意を取得する」「バグゼロを確認してリリース判定を出す」「三者に同席してもらい議事録を当日中に送付する」——こうした動詞の多様性こそが、WBSの解像度の高さを示す。