第15話｜周りが何やっているかわかりません｜東央ソリューションズ―― 実務統合型PM論・連載小説

「増員しましょう」

その一言は、会議室の空気を少しだけ軽くした。

「人が足りないなら、人を入れればいい」

神谷は前向きに言った。

白石も頷く。

「他案件から応援を出せませんか？」

高梨は少し考えたあと、口を開いた。

「即戦力なら助かります」

黒田は何も言わなかった。

翌週。

開発フロアの座席表が更新された。

新しく五人の名前が追加されている。

別部署からの応援。

協力会社からの増員。

経験者もいれば、この案件を今日初めて知る人もいる。

朝会。

高梨は全員に向かって説明を始めた。

プロジェクトの概要。

現在の進捗。

担当範囲。

懸念事項。

説明が終わる頃には、一時間近くが過ぎていた。

その間、本来進めるはずだったレビュー作業は止まっていた。

午後。

チャットが鳴り続ける。

『この機能、誰が担当ですか？』

『最新版の設計書はどこですか？』

『この修正、もう対応済みですか？』

『AIチームに確認したいのですが、窓口は誰でしょう』

高梨は一つずつ返信する。

返信を書いている間にも、新しい通知が積み上がる。

気づけば、自分の作業はほとんど進んでいなかった。

夕方。

若い応援メンバーの一人が席に来た。

「高梨さん、少しいいですか」

「どうしました」

「この画面設計なんですけど……」

説明を始めたその瞬間、

別の社員が声を掛ける。

「すみません、このIF仕様の件なんですが」

さらにチャットが鳴る。

電話も鳴る。

高梨は苦笑いを浮かべた。

「順番にお願いします」

そう言いながら、

誰から話を聞いていたのか、自分でも分からなくなっていた。

数日後。

定例会。

村瀬が資料を映した。

「現在の体制です」

画面いっぱいに名前が並ぶ。

二十人。

二十五人。

三十人。

開始当初より、倍近い人数になっていた。

白石は感心したように言う。

「かなり体制強化されましたね」

神谷も笑顔を見せる。

「これなら安心だ」

その隣で、

黒田だけが静かにため息をついた。

会議後。

高梨は黒田に声を掛けた。

「人は増えました」

「ああ」

「でも、前より忙しい気がします」

黒田は少し笑った。

「そういうもんだ」

「教える人間が必要になる」

「聞く人間が増える」

「調整も増える」

「情報の伝達経路も増える」

「人数が増えた分だけ、会話も増える」

高梨は黙って聞いていた。

黒田は続ける。

「一人増えれば、一人分仕事が増えるわけじゃない」

「その一人を動かす仕事も増える」

翌日。

高梨は開発フロアを見渡した。

誰もが忙しそうにキーボードを叩いている。

打ち合わせをしている人。

設計書を読んでいる人。

チャットを書いている人。

電話している人。

仕事は進んでいるように見える。

人も増えた。

席も埋まった。

声も増えた。

それなのに。

以前より、

全体が見えなくなっていた。

そのとき、応援メンバーの一人が近づいてきた。

「高梨さん」

「はい」

「隣のチームって、今何をやっているんですか？」

高梨は思わず開発フロアを見回した。

AIチーム。

基盤チーム。

画面チーム。

データ連携チーム。

誰もが何かをしている。

だが、

それぞれが何を目指しているのか。

どこまで進んでいるのか。

自分にも、はっきりとは分からなかった。

「……確認してみます」

そう答えた自分の声が、

少しだけ遠く聞こえた。

人は増えた。

だが、

共有される情報は増えなかった。

そしてプロジェクトは、

静かに複雑さだけを増していく。

誰も悪くない。

誰も怠けていない。

それでも、

周りが何をやっているのか、

誰にも分からなくなり始めていた。

ケーススタディ

第15話では、開発の遅れを取り戻すために増員が行われました。

人員は増えました。

席も埋まりました。

会議も増えました。

チャットも活発になりました。

しかし、高梨は以前より忙しくなり、「周りが何をやっているのか分からない」と感じ始めます。

「人を増やせば進捗は改善する」

この考え方は、本当に正しいのでしょうか。

あなたがPMなら、この状況をどう捉えますか。

Q1

プロジェクトが遅れているとき、人員を増やせば必ず進捗は改善するのでしょうか。

A1｜解答例

必ずしも改善するとは限りません。

新しいメンバーが加わると、業務を教える時間や情報共有の負荷が発生します。

また、既存メンバーとの認識合わせや役割分担の調整も必要になります。

特にプロジェクト終盤や仕様が複雑化した段階では、新メンバーが戦力になるまでに時間がかかり、その間は既存メンバーの負荷がかえって増えることがあります。

この現象は「ブルックスの法則」として知られており、

「遅れているソフトウェアプロジェクトに人員を追加すると、さらに遅れることがある」

という考え方で説明されます。

重要なのは人数ではなく、「その人が価値を発揮できる状態を作れているか」です。

Q2

増員によってPMの負荷が急増するのはなぜでしょうか。

A2｜解答例

PMが情報の集約点になってしまうからです。

新メンバーは、

• 誰に聞けばよいのか

• 最新資料はどれか

• 仕様変更はどこまで反映されているのか

といった確認をPMに求めがちです。

その結果、本来はプロジェクト全体をマネジメントすべきPMが、問い合わせ対応に追われる状態になります。

さらに、情報がPM一人に集中すると、判断待ちや回答待ちが増え、プロジェクト全体の速度も低下します。

PM自身がボトルネックになっていないかを常に意識することが重要です。

Q3

増員を成功させるために、PMはどのような準備をすべきでしょうか。

A3｜解答例

人を増やす前に、「情報を増やす仕組み」を整えることが重要です。

例えば、

• 最新資料を一元管理する

• 役割分担を明確にする

• FAQやオンボーディング資料を用意する

• 判断基準をドキュメント化する

• チームリーダーを設置し、問い合わせを分散する

といった仕組みが有効です。

増員そのものが問題を解決するのではありません。

増えた人数が自律的に動ける環境を作って初めて、体制強化の効果が発揮されます。

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

プロジェクトで人手不足になると、

「人を増やせば解決する」

という発想になりがちです。

しかし実際には、人が増えるほどコミュニケーションは複雑になり、調整コストも増加します。

特に情報がPM一人に集中している組織では、増員によってPMの負荷がさらに高まり、結果として全体の生産性が下がることも珍しくありません。

本当に不足しているのは「人数」ではなく、「情報が流れる仕組み」かもしれません。

PMが管理すべきなのは人員数ではなく、

チーム全体が自律的に動ける構造です。

人を増やすことは手段であって、目的ではありません。

そして、その手段が機能するかどうかは、プロジェクトの情報設計にかかっているのです。