「この機能、やっぱり変えてほしいんだけど…」
プロジェクト終盤でのこの一言は、PMにとって最も恐ろしいフレーズの一つだ。感情的に拒否するのではなく、AIで影響範囲を定量的に整理し、建設的な提案につなげることが重要だ。
仕様変更が炎上を招く本当の理由
仕様変更そのものが問題なのではない。炎上の火種となるのは「影響範囲の見積もり不足」と「関係者への説明の遅れ」だ。
「やってみないと分からない」では交渉にならない。スケジュール・コスト・品質への影響を数字で示すことで、ステークホルダーも「変更するかどうか」を合理的に判断できる。AIはその影響分析の初期ドラフトを素早く作れる。
仕様変更影響分析プロンプト（基本形）
あなたはITプロジェクトのリスク分析アシスタントです。
以下の仕様変更要求について、影響範囲を分析してください。
【現在のプロジェクト状況】
- フェーズ：〇〇（例：開発中、テスト中）
- 残り期間：〇週間
- チーム体制：〇名
【変更要求の内容】
〇〇（変更内容を具体的に記載）
【変更が必要な理由（申請者の主張）】
〇〇
【出力形式】
1. 変更の影響を受けるシステム領域（箇条書き）
2. スケジュールへの影響（追加作業の概算日数と根拠）
3. コストへの影響（追加工数の概算と理由）
4. 品質リスク（変更による新たなバグ・手戻りのリスク）
5. 変更しない場合のリスク（変更を却下した場合の影響）
6. 推奨アクション（今すぐ変更 / 次期バージョンに先送り / 代替案の提案）ステークホルダー向け説明文プロンプト
影響分析が完了したら、関係者に説明するための文書を作成する：
以下の仕様変更影響分析をもとに、発注者（非技術者）に説明するための報告文を作成してください。
感情的な表現を避け、事実と選択肢を中心に記述してください。
【影響分析結果】
〇〇（上のプロンプトの出力を貼り付ける）
【今回の変更要求の優先度（申請者の認識）】〇〇
【出力形式】
1. 件名（20文字以内）
2. 変更要求の内容の要約（2行以内）
3. 影響のサマリー（スケジュール・コスト・品質を箇条書きで簡潔に）
4. 提示する選択肢（A案：今すぐ変更、B案：次期バージョンで対応、C案：代替案）
5. 回答期限（いつまでに判断が必要か）
6. PMからのコメント（中立的なトーンで）変更管理を仕組み化するヒント
仕様変更は「断る」ものではなく「正しく管理する」ものだと捉えることが重要だ。そのために、変更要求ごとに以下を記録する習慣をつける：
- 変更要求の内容・申請日・申請者
- AIで分析した影響範囲のドラフト
- ステークホルダーへの提示内容と決定事項
このログが蓄積されることで、プロジェクト終盤の「いつの間にかスコープが増えていた」問題を防げる。AIはその記録作業の省力化にも使える。