はじめに：構造は“正しくても伝わらない”ことがある

WBSを作っていて、こんな風に感じたことはありませんか？

「ちゃんとWBSにしたのに、どうも現場と噛み合わない」

「整ってるんだけど、チームメンバーの反応が薄い…」

「なんか、“伝わってない”気がする…」

実はこの違和感、WBSが「正しくないから」が原因ではないかもしれません。
WBSとして構造がきちんと組まれていても、見る人が違えば意味も変わるのです。
その背景の一つとしてあるのが、“視点のズレ”です。

本シリーズの第1部では、話し言葉（自然言語）をWBSという構造に落とし込むときに起こる「ズレ」や「違和感」について扱いました。

会話で通じていたことが、構造にすると急にモヤモヤするあの現象…
あの違和感の正体は、言葉に含まれていた“文脈”や“暗黙の了解”が失われることにありました。

↓第1部はこちらからご覧いただけます。↓

【WBSシリーズ①】自然な会話が“WBSという構造”に変わるときに起こる違和感の正体

そして今回の第2部では、さらに一歩踏み込みます。
テーマは──
「誰の視点でWBSを見るかによって、意味が変わる」問題。

各人の視点の違いがどのように構造を歪めるのか、そしてそのズレをどのように防ぐかを、具体例とともに整理していきます。

この記事に対応するホワイトペーパーでは、

• 視点定義ワーク（フレーム）
• 意味のブレを見える化するテンプレート
• 現場で使えるレビュー観点

などを図解つきで詳しくご紹介しています。

【WP第2部】その構造、“誰の視点”でできていますか？

WBSは、ある意味とても“理性的”な道具です。

作業を分解し、順序を整理し、粒度を揃え、関係性を明示する。
これだけ整っていれば、伝わらないはずがない――
そう思いたくなります。

ですが現実は、“整っているのに伝わらないWBS”がしばしば存在します。

たとえばこんなケース。

• 項目はちゃんと並んでいる。でも、チームメンバーがピンと来ていない
• 一見スッキリしているWBSなのに、質問が絶えない
• 「これは何のための作業？」と毎回確認されてしまう

こうした状況に陥ったとき、私たちはつい構造の“粒度”や“分類”を見直そうとします。
しかし実は、そこより先に見直すべきものがあります。
それは
“誰のためにWBSを作っているのか”という視点です。

WBSという構造は、一見“共通言語”のように思えます。
誰が見ても同じように読めるはずだ、と。

しかし、実際にはこうしたすれ違いがよく起こります。

• 「“UI改善”って、どこまでの範囲を指してる？」（デザイナー）
• 「改善って、どう測るの？KPIあるの？」（PM）
• 「それってデザインなの？要件変更なの？」（クライアント）

同じ「UI改善」というタスク名でも、立場や期待の違いによって、まったく別の意味で受け取られてしまうのです。

視点	UI改善から想起すること
PM	ユーザビリティ向上、指標改善、工数内での最適化
デザイナー	画面設計の刷新、導線の見直し、レイアウト改訂
クライアント	印象向上、ブランドトーンとの整合性、洗練された見栄え

構造は言葉で表現されますが、言葉は“誰が読むか”で意味が変わる。

それが、WBSに潜む落とし穴であり、視点のズレが生む構造のゆがみです。

構造としては「正しい」のに、実際には噛み合わないWBSには、共通するパターンがあります。
ここではその中でも特に多い「視点のズレ」が引き起こす3つのすれ違いを紹介します。

① 階層が混ざる：俯瞰と実行のレイヤーが混在

• PM視点：全体の進捗を捉えるためのWBS
• エンジニア視点：今日・明日なにをやるかのToDoリスト

この2つが混在すると、タスクの粒度や順序がバラバラになります。

② 粒度が揃わない：細かすぎる、ざっくりすぎるが混在

同じ「レビュー」というタスクでも…

• デザイナー視点：モックを見せてフィードバックをもらう
• クライアント視点：承認を前提とした正式チェック

どのくらい詳細に書くべきかも視点によって大きく異なります。

③ 意図が伝わらない：「成果物」か「行動」かがあいまい

「資料をまとめる」という言葉。

• ドキュメントの作成？
• 議論の整理？
• 納品物作成？

意図が共有されていないままタスクになると、“完成したのに納得されない”というズレが起こります。

これらはすべて、「誰の視点で構造が作られているか」が曖昧なことに起因しています。

視点のズレによる構造のブレを防ぐ一番シンプルで効果的な方法は、
「このWBSは誰のためのものか？」を先に定めること。

たとえば、こんな問いから始めてみましょう。

問い	ねらい
このWBSは誰が使う？	PM？エンジニア？クライアント？
何を判断するための構造？	進捗？成果？リスク？
どのフェーズで使う？	計画？実行？報告？
粒度はどこまで必要？	作業単位？日単位？目的単位？

構造を視点とセットで設計するだけで、

• 作る側は「どこまで作ればいいか」が明確になり
• 使う側は「このWBSから何を読み取ればいいのか」がわかる

つまり、WBSが読みやすく、判断しやすくなるのです。

補足：複数の視点を並立させることもできる

「このブロックはPM視点」「ここは実務者視点」といった形で、視点のラベルを添えるだけでも効果的です。

今回は、WBSが「整っているのに伝わらない」理由のひとつ、
“視点のズレ”について掘り下げてきました。

本記事の要点ふりかえり

• 構造は、正しくても伝わらないことがある
• 同じ項目でも、人によって意味がズレる
• “誰のための構造か”を明示するだけで、WBSの伝わり方が大きく変わる

ただし、視点を明示してもなお、WBSには“未定なこと”や“曖昧なこと”が残ります。

次回の第3部では、
「あいまいなものを排除せず、構造の中に仮置きする」という考え方を取り上げます。
WBSは「問い直せる地図」

仮置きしながら進める柔軟な設計について、一緒に考えていきましょう。

もっと詳しく知りたい方へ：ホワイトペーパー無料公開中！

※免責事項
本記事（または資料）の内容は、あくまで情報提供を目的としたものであり、すべての状況に当てはまるとは限りません。内容を参考にされた結果については、ご自身の判断と責任でお願いいたします。当方では、その内容をもとにした実践や対応によって生じたいかなる結果についても、責任を負いかねますことをご了承ください。