顧客質問への即答が危ないケース
プロジェクト現場で顧客から「この機能って来月追加できますか？」「このデータはCSVで出せますか？」と聞かれたとき、すぐ「できます」と答えるのは止めた方がいい。
技術的には可能でも、その発言がスコープ変更の約束になることがある。PMが把握していない状態で、エンジニアが顧客に直接答えた内容は、あとで「言った・言わない」の原因になる。
回答前に確認する4つの判断軸
確認1：事実として答えられるか
「現在の設計で対応可能か」「自分の担当範囲で確認済みか」を先に確認する。
実装上は可能でも、他チームの確認が必要なものや、まだ設計段階のものは「確認して回答します」が正しい。
確認2：納期・費用・スコープに影響するか
機能追加や仕様変更を伴う質問は、技術的に答えられる内容でもPM確認が必要な場合がある。
「できます」の一言がスコープ変更の了承として受け取られると、後でプロジェクトの工数・コストに影響する。
確認3：PM確認が必要か
顧客への公式な回答は、PMが判断・承認するものが多い。エンジニアが個別に答えた内容と、PMが把握している内容がずれると、チームの信頼性が落ちる。
「PMと確認したうえでお答えします」はネガティブな発言ではなく、適切なプロセスの確認だ。
確認4：その場で答えることの影響
「今日中に答えが必要か」「後日で問題ないか」を確認する。その場での回答を急かされる状況でも、確認すべきことは確認してから答える。
その場で持ち帰るための言い方
確認が必要だと判断したら、以下の言い方で持ち帰る。
「技術的な確認と、スケジュールへの影響をPMと確認してから回答させてください。○日までにご連絡します。」
「分からない」ではなく「確認してから答える」という形にすることで、相手に対しても適切な対応になる。
PMへ共有する内容
持ち帰った後、PMへ共有する内容は以下をセットで伝える。
- 誰から、何を聞かれたか
- 自分がその場でどう答えたか
- 技術的に可能かどうかの確認結果
- PMに判断してほしいこと（スコープ・スケジュール影響）
PMが判断材料を持てる形で共有することで、次の顧客回答につながる。