第16話｜WBSはありません｜東央ソリューションズ―― 実務統合型PM論・連載小説

「進捗を確認したいので、最新版のWBSを共有してください」

田辺の一言で、会議室が静かになった。

高梨はノートPCを開く。

フォルダを探す。

「少々お待ちください」

そう言って検索を始めた。

更新日が並ぶ。

WBS_v3。

WBS_v5。

WBS_最新版。

WBS_最新版_修正版。

WBS_最新版_最終。

その横に、

「本当の最新版.xlsx」

というファイルまである。

高梨は苦笑いした。

「これです」

画面を映す。

だが、黒田が首を傾げた。

「それ、先週のじゃないか」

隣で村瀬も口を開く。

「AIチームは別管理ですよ」

「データ連携はスプレッドシートです」

「画面チームはBacklogで管理しています」

「基盤チームはExcelですね」

高梨の手が止まった。

「……全部合わせたものは？」

誰も答えない。

午後。

高梨は各チームを回った。

画面チームには画面チームの管理表。

AIチームにはAIチームのタスク一覧。

データ連携チームには独自の進捗管理。

協力会社はまた別のフォーマット。

それぞれは整理されている。

だが、

互いにつながっていない。

夕方。

白石が近づいてきた。

「全体進捗って今どれくらいですか？」

高梨は答えようとして止まった。

「たぶん……七割くらいです」

「たぶん？」

「いや、八割かもしれません」

白石は少し笑った。

「そんな感じなんですね」

高梨も笑い返した。

だが、

心の中では笑えなかった。

翌日の定例会。

神谷が経営層向け資料を映した。

進捗率。

82％。

緑色のバーが伸びている。

「順調ですね」

役員が頷く。

田辺も安心した表情を見せた。

「予定どおりですか」

神谷は迷わず答える。

「はい」

高梨はその数字を見つめていた。

82％。

どうやって出した数字だったか。

自分でも思い出せなかった。

夜。

オフィスには高梨だけが残っていた。

ホワイトボードの前に立つ。

付箋を貼る。

AI。

画面。

IF。

基盤。

帳票。

バッチ。

データ移行。

矢印を引く。

依存関係を書く。

途中でスペースが足りなくなる。

隣の壁まで使う。

ようやく全体像が見えてきた。

その瞬間、

チャットが鳴る。

『高梨さん、今の最新版WBSってありますか？』

別の通知。

『進捗管理表、共有いただけますか』

さらにもう一件。

『どのタスクがクリティカルですか？』

高梨はホワイトボードを見た。

そこには、

今この瞬間だけ存在する、

唯一の全体像が描かれていた。

写真を撮ろうとスマートフォンを手に取る。

だが、

電話が鳴る。

着信は村瀬だった。

「すみません、高梨さん」

「AIチームと画面チームの優先順位、確認したいんですが」

高梨はホワイトボードから目を離した。

数分後。

電話を終えて振り返る。

さっきまで見えていた全体像が、

もう頭の中から少しずつ消え始めていた。

翌朝。

田辺からメールが届く。

『最新版WBSをご共有いただけますでしょうか』

高梨は返信画面を開く。

指が止まる。

添付できるファイルはある。

だが、

どれも今のプロジェクトを正確には表していない。

静かなオフィスで、

高梨は小さく息をついた。

「……WBSは、ありません」

誰も削除したわけではない。

誰も管理を放棄したわけでもない。

それでも、

誰も全体を見られなくなったとき、

プロジェクトは地図を失う。

そして人は、

見えない道を進み続けるしかなくなるのだった。

ケーススタディ

第16話では、田辺から「最新版のWBSを共有してください」と依頼された高梨が、その場で答えに詰まってしまいました。

ファイルはあります。

進捗表もあります。

各チームはそれぞれ管理しています。

それでも、プロジェクト全体を表す「たった一つの真実」が存在しません。

その結果、高梨の頭の中だけが唯一のWBSとなり、組織全体が少しずつ属人化へ向かっていきます。

これは決して珍しい話ではありません。

実際のプロジェクトでも、

「WBSはあるけれど更新されていない」

「各チームが独自管理している」

「進捗率だけは報告されるが根拠は曖昧」

という状態は少なくありません。

もしあなたがPMなら、この状況をどう立て直すでしょうか。

なお、WBSそのものの考え方や作り方について詳しく知りたい方は、こちらの記事もあわせて読むと理解が深まります。

Q1

WBSが存在しない、あるいは更新されていない状態では、どのような問題が発生するでしょうか。

A1｜解答例

最大の問題は、プロジェクト全体を誰も正しく把握できなくなることです。

各担当者は自分の作業を理解しています。

しかし、

• どの作業が終わっているのか

• どこが遅れているのか

• 何がクリティカルパスなのか

• 変更による影響範囲はどこか

といった全体像が見えなくなります。

その結果、進捗報告は感覚的になり、「たぶん大丈夫」という判断が増えていきます。

WBSは単なるタスク一覧ではありません。

プロジェクト全体を可視化するための地図なのです。

Q2

各チームが独自に進捗管理をしている場合、何が問題になるのでしょうか。

A2｜解答例

チーム単位では最適化されても、プロジェクト全体では整合性が失われます。

例えば、

• AIチームは完了と認識している

• 画面チームは未着手と認識している

• データ連携チームは仕様変更待ちになっている

といった状態でも、それぞれの管理表だけを見る限り問題が見えないことがあります。

依存関係が可視化されていないため、遅延やリスクが表面化するのは実装やテスト段階になってからです。

PMに必要なのは、各チームの管理を否定することではなく、それらを統合して全体最適を判断できる仕組みを持つことです。

Q3

PMが「頭の中で管理している状態」は、なぜ危険なのでしょうか。

A3｜解答例

一見すると、経験豊富なPMほど「自分が把握しているから大丈夫」と考えがちです。

しかし、その情報がドキュメント化されていなければ、

• PMが休めない

• 判断がPMに集中する

• 他メンバーが自律的に動けない

• 引き継ぎが困難になる

という状態を招きます。

さらに、プロジェクトが大きくなるほど記憶だけでは管理しきれず、認識漏れや判断ミスのリスクも高まります。

「自分だけが分かっている」は強みではありません。

組織として見れば、大きなリスクです。

このケースで本当に学んでほしかったこと

WBSは、単なるスケジュール表でも、PMだけが使う管理資料でもありません。

チーム全員が同じ景色を見るための「共通言語」です。

その共通言語が失われると、

人は自分の担当だけを見るようになります。

チームは自分たちだけで最適化を始めます。

そして最後には、

「高梨さんじゃないと分かりません」

という属人化が生まれます。

つまり、WBSの崩壊は単なる管理不足ではありません。

コミュニケーションの崩壊であり、組織構造の崩壊の始まりなのです。

だからPMに求められるのは、立派なWBSを作ることではありません。

誰が見ても同じ状況を理解できる状態を維持し続けることです。

その積み重ねが、プロジェクトを「個人の記憶」ではなく「組織の知識」で動かす土台になります。