顧客から急な追加要求を受けたとき、そのまま開発へ伝えるべきか、断るべきか。会社員時代の私は、納品先と自社メンバーの間で何度も悩みました。
顧客の要望を受ければ現場が苦しくなり、断れば関係が悪くなるかもしれません。実際、夜遅くまで調整メールを書き直しながら、返事を決められないこともありました。
今回は、板挟みの中で、現場を守るために見直した対応を紹介します。
要求をそのまま開発へ流さない
納品先の担当者から追加の修正を頼まれると、以前の私は、そのまま開発メンバーへ伝えていました。
「顧客が必要だと言っているのだから、仕方がない」
そう考えていたのです。
早く返事をすることが、顧客への誠実な対応だと思っていた部分もありました。
でも、顧客から見れば小さな変更でも、開発側では話が違います。
例えば、画面上の項目を一つ追加するだけに見えても、実際には入力チェック、データベース、帳票、テスト項目まで確認が必要になり、一か所の変更だとしても、裏側では複数の担当者が動かなければなりません。
あるとき、納期が迫った段階で追加修正を受け、そのまま朝の打ち合わせでメンバーへ伝えたことがありました。私が説明を始めると、何人かが目を伏せ、会議室の空気が重くなりました。強く反対する人はいませんでしたが、「また増えるのか」という気持ちは伝わってきます。
要求を右から左へ流すだけでは、調整役とは言えないのではないか。
そう思い、それからは顧客から要望を受けても、その場で「対応します」と約束しないようになりました。当然費用もその分増えることになりますしね。
まず開発側へ持ち帰り、次の点を確認します。
- どの機能に影響するのか
- 作業とテストに何日必要か
- 現在の納期を守れるのか
- 先に予定していた作業と入れ替えられるのか
- 一部対応や別の方法で代替できないか
実際に開発メンバーへ確認すると、「修正自体は半日でも、関連テストに二日かかる」とか「影響範囲が広く1週間から2週間かかる」と分かる場合もあります。
顧客との会話だけでは見えなかった大きな負担です。
顧客の要求を受け取ることと、その場で実施を約束することは全く別。今なら、「影響範囲を確認し、明日までに回答します」と伝えます。
返事を保留するのは逃げではありません。曖昧なまま引き受け、後から納期や品質の問題を出すほうが、顧客にも迷惑をかけるものです。
現場の限界を具体的に伝える
顧客へ事情を説明するとき、
私はメールだけで済ませず、できるだけ対面で話すようにしていました。
以前は、相手を怒らせないように言葉を選び、夜遅くまでメールを書き直すことがありました。
「現状では難しいと思われます」
「可能であれば次回にお願いできないでしょうか」
柔らかく書こうとするほど、何が問題なのか分かりにくくなります。顧客から「結局、できるのですか」と聞き返されたこともありました。
そこで、単に「忙しい」「人が足りない」と訴えるのではなく、追加要求によって何が起きるのかを具体的に伝えるようにしました。
例えば、次のように説明します。
- 「今回の修正を追加すると、予定していた総合テストを1週間短縮する必要があります」
- 「納期を変えない場合、別の機能を次回へ回す判断が必要です」
- 「この部分だけなら対応できますが、全面的な変更には追加日数が必要です」
顧客が知りたいのは、開発側が大変かどうかだけではありません。追加要求を入れると何が変わるのか。予定どおり進めたいなら、何を諦める必要があるのか。その判断材料です。
ある追加依頼では、担当者は「画面を少し直すだけ」と考えていました。しかし関連する確認作業まで説明すると、「そこまで影響するなら今回は見送る」と判断してくれました。こちらが拒否したのではなく、影響を理解したうえで、顧客自身が優先順位を選んだ形です。
現場を守るには、苦しさを訴えるより、相手が選べる材料を示す必要があります。
こちらの都合だけを説明しても交渉は進まないため、その要求がなぜ必要なのかの確認も重要です。
- 「今回の運用開始時点で必須なのでしょうか」
- 「どの利用者から強く求められているのでしょうか」
- 「機能そのものではなく、別の方法でも目的を満たせますか」
詳しく聞くと、実際には機能追加そのものが目的ではなく、顧客担当者が上司へ改善状況を示したいだけだったこともあります。
目的が分かれば、簡単な暫定対応や資料の追加で解決できる場合がありますし、最初の要求どおりに作る必要がないこともあるのです。
断るのではなく対応を分ける
無理な要求を受けたとき、「全部やる」か「全部断る」かで考えると、どちらかに負担が偏ります。そこで私は、要求を細かく分けるようにしました。
例えば、複数の修正を一度に求められた場合は、次のように整理します。
- 運用開始に必要な部分は今回対応する
- 見た目の改善は次回へ回す
- 大きな作り直しは別見積もりにする
- 手作業で代替できる部分は暫定運用にする
ある案件では、顧客から複数の画面変更をまとめて求められました。
すべてを対応すると納期に間に合いません。そこで開発メンバーと確認し、利用頻度が高い画面だけを先に直し、それ以外は次回の更新候補に分けました。
顧客には、今回対応する項目と後回しにする項目を一覧で示し、さらに後回しにした場合でも業務が止まらないよう、当面の操作方法も説明しました。
「今回はできません」だけでは、担当者も社内で説明しにくいでしょう。
一方で、
- 今回できること
- 今回できないこと
- できない理由
- 次に対応できる時期
- それまでの代替手段
が整理されていれば、相手も持ち帰って話しやすくなります。
顧客の顔を立てるとは、言われたことをすべて引き受けることではありません。担当者が社内で説明し、判断できる材料を用意することだと、私は考えるようになりました。
もちろん、毎回きれいにまとまったわけではありません。
顧客から「何とか今回入れてほしい」と押され、開発側からは「また受けるつもりですか」と言われたこともあります。
どちらにも理解されていないように思い、「調整役なんて割に合わないな」と感じた夜もありました。板挟みになると、どちらか一方の味方をしたほうが楽に思えることもありますよね。
それでも、要求を一度止め、影響を確認し、誰か一人へ負担を寄せない形を探しました。やがて開発メンバーからも、追加要求が来たときに「まず確認してから返してくれる」と思ってもらえるようにもなりました。
すべての不満をなくせなくても、
要求がそのまま降ってこないだけで、現場の受け止め方は変わります。
板挟みで結論に迷ったとき、私は次の二つを確認していました。
- 誰か一人に負担を押しつけていないか
- 顧客と開発の両方へ理由を説明できるか
全員が満足する答えがなくても、この二つに答えられる判断なら、少なくとも無責任な丸投げにはなりません。
まとめ
顧客と開発の板挟みになったとき、要求をそのまま現場へ流すと、開発メンバーの負担が積み重なります。反対に、現場の事情だけを理由に断れば、顧客との関係が悪くなるかもしれません。
私が意識したのは、まず要求の影響を確認し、納期や品質に何が起きるのかを具体的に伝えることでした。そのうえで、今回対応する部分、次回へ回す部分、別の方法で代替する部分に分けます。
すべてを受ける必要はありませんが、ただ断るだけでも話は進みません。相手が判断できる材料を示し、現場にも無理をさせない着地点を探すことが大切です。
板挟みになると、どちらにも不満を持たれているように思うことがありますよね。それでも、要求を一度止めて整理し、誰か一人に負担を押しつけない判断を続けることが、現場を守ることにつながると思います。
コメント