プロジェクト進行中の追加要求にどう立ち向かう？──“後出しジャンケン”に振り回されないPMの実践術 #PM奮闘記6

はじめに：プロジェクトに潜む“後出しジャンケン”

こんにちは、HASエンジニアです。

「また顧客から追加要求が来た……」
「営業と開発の板挟みで、どうすればいいのか分からない……」

プロジェクトを進める中で、突然の追加要求に頭を抱えた経験はありませんか？私自身、現在進行中の案件でまさにその状況に直面しています。

そしてそのたびに、スコープ（作業範囲）がズルズルと広がる“スコープクリープ”の怖さを実感しています。

1. 🧨 スコープが崩壊する瞬間──追加要求の恐ろしさ

スコープクリープとは、プロジェクトの進行中に作業範囲が拡大してしまう現象です。
当初予定になかった機能追加の要求が発生し、設計変更や部品の追加調達が必要になることがあります。

ところがうちの会社はIT企業ではなく、ハードウェア中心の製品開発が主です。そのためソフトウェアのようにアジャイル開発で柔軟に機能追加、というわけにはいきません。

製品開発のプロセスは順次進めていくウォータフォールモデルをほとんどのプロジェクトで採用しています。

一つ機能を追加しようとすれば、

• 設計変更

• 部品の追加調達

• 評価のやり直し（既存機能への影響確認も含む）
  といった作業が連鎖的に発生します。

つまり、「ちょっと追加で」では済まないのがハード開発の現実なのです。

2. ⚔️ 三つ巴の構図：営業 vs 開発 vs PM

この「追加要求」、実はよくある構図に発展します。

• 営業は「顧客の信頼を得るチャンスだ！」と前向き。

• 開発は「今の技術では厳しい。コストも納期も跳ね上がる」と反対。

• そして板挟みになるのがPMです。

さらにこの構造について、営業は海外（ヨーロッパ）、開発は日本と物理的な距離も隔たりを大きくしている要因になったりします。

ここでPMは単なるスケジュール管理者ではなく、事業として成り立たせる“最終責任者”として判断を迫られます。

3. 🔁 タックマンモデルで読み解く「チームの混乱」

本来チームビルディングは以下のタックマンモデルに従って行われます。

1. 形成期（Forming）

2. 混乱期（Storming）

3. 統一期（Norming）

4. 機能期（Performing）

5. 散会期（Adjourning）

統一期に開発するものの仕様が固まって、機能期で完成に向かって進んでいくベスト状態のときに、こういった追加要求で混乱期に逆戻りするケースがあります。

このような逆戻りの状態をいかに最小限にするかがPMには求められます。

4. PMが取るべき3つのステップ①：要求の棚卸と“本気度”の見極め

こうした場面で最も避けたいのは、「根拠のない主張」が飛び交う空中戦になることです。

まず必要なのは、要求を整理して、優先度を明確にすること。

• Must（必須）

• Should（できれば欲しい）

• Nice to have（あればうれしい）

に分類した上で、その要求が本当にビジネスに直結するのかを掘り下げます。

ここで重要なのは、「顧客がどれくらい本気なのか」。

• この要求が実現しなければ、競合に移るレベルなのか？

• それとも「あれば便利かな」程度なのか？

• 顧客はうちの会社にどれくらいのビジネスを期待しているのか？

営業の立場だと、”顧客を大事にしたい”という思いからどうしても重要度を上げたい気持ちがあります。

でも追加要求事項を正しく見極めていくと、ビジネスに直結しないものが多々あったりします。

逆にビジネスインパクトが強いものがあった場合、なぜ事前に挙げられなかったのかという反省点もあります。
こういった内容は今後のプロジェクト改善のために正しくフィードバックするべきです。

5. PMが取るべき3つのステップ②：影響範囲の見える化（コスト・スケジュール）

要求の真意を把握したら、次は「その要求がプロジェクトに与える影響」を具体的に洗い出します。

• 開発リソースの再配分が必要か？

• スケジュールはどれくらい遅れるのか？

• 新たな部材の調達や評価に、どれだけの期間が必要か？

こうした影響を明文化することで、感情論ではなく事実ベースの議論が可能になります。

営業チームも「そんなにコスト、時間がかかるなら顧客のためにならない」という方向性に向かっていく可能性もあります。

WBS（作業分解構成図）の更新や影響分析ドキュメントを使うと、ステークホルダーの理解も得やすくなります。

WBSの内容とよくある事例についてはこちらをご覧ください。

6. PMが取るべき3つのステップ③：コンフリクトマネジメント

追加要求の是非をめぐる議論は、往々にして部署間の対立を生みます。
しかし私は、対立（コンフリクト）は悪いものだとは思っていません。

むしろ、「違う立場からの意見が出てくるのは、プロジェクトが健全に進んでいる証拠」だと捉えています。

大事なのは、その対立を放置せず、早期に合意形成に持ち込むこと。
そのためには上記2つのステップである要求の棚卸と、影響範囲の見える化をしっかりやっておく必要があります。

対立解消の5つのアプローチ

• コラボレーション（協調）全員の懸念を解消し、Win-Winを目指す（理想形）

• コンプロマイズ（妥協）双方が譲歩し、落とし所を見つける

• アコモデーション（受容）一方の主張を一時的に受け入れる

• コンペティション（競争）一方の意見を優先（緊急時に有効）

• アボイダンス（回避）一時的に議論を先送り（戦略的撤退）

理想はコラボレーションですが、現実的には妥協（コンプロマイズ）が最も多いです。
妥協であっても、その判断の背景と理由を明確にしておくことで、関係者の納得感は大きく変わります。

そして最終的に対立が収まったあとには、必ず「なぜこの対立が起きたか」の振り返りを行い、次回プロジェクトに活かしていきます。

まとめ：スコープクリープは、PMの“腕の見せ所”

ここまでお読みいただきありがとうございました。

【本記事のまとめ】
✅ 要求の“本気度”を見極め、空中戦を防ぐ
✅ コスト・スケジュールへの影響を明確に
✅ 対立は悪ではない。合意形成の機会と捉える

「後出しジャンケン」に見えても、実はPMにしかできない勝ち筋がある——私はそう信じています。
「ここが調整力の見せ所だ」と前向きに捉えて乗り越えていきたいものです。