顧客と開発の間に立つ仕事では、「これくらいなら対応できますよね」と追加要求を受けることがあります。
以前の私は、その場で受けた要望をそのまま開発メンバーへ伝えるだけであり、それが調整役の役割だと思っていました。でもそれは調整ではなく、情報を右から左に流すだけ、単に丸投げになっていたと気づきました。
この記事では、顧客の要求をそのまま開発へ流さず、影響範囲を確認し、顧客が判断できる材料へと変えて返すようになった対応法を紹介します。
顧客の要求をそのまま開発へ流していた
当時の私は、顧客から追加修正を頼まれると、まず開発側へ持っていくことを優先していました。
小さな修正でも影響は広がっていた
顧客から見ると「これぐらいなら大したことないだろう」という小さな変更でも、開発側ではそう簡単ではありません。
「画面を少し直してほしい」
「この項目も追加できないか」
たとえ画面表示を直すだけでも、関連する処理や、いろいろな表示パターンでテスト確認する必要があります。場合によっては、すでに終わった作業へ戻り、修正した部分だけでなく周辺機能まで確認し直すこともあります。
ただ、当時の私自身も「少し表示を直すくらいなら、それほど大きな作業ではないだろう」と考えてしまうことがありました。
実際に開発メンバーへ確認すると、
「ここを変えるなら、この処理も確認が必要です」
「この画面だけではなく、共通で使っているこちらも対応が必要です」
と、自分が見えていなかった影響を指摘されます。
開発と対話しながら顧客と調整しているからといって、私がすべての影響を分かって話しているわけではなかったんですね。
それでも以前は、顧客から言われた以上、まず開発へ伝えるべきだと思っていました。
会議室の空気で丸投げに気づいた
そうした中、ある朝の打ち合わせで、いつものように顧客からの追加要求を伝えたとき、誰もすぐに返事をしませんでした。
メンバーが目を伏せていて、会議室の空気が重い。
言葉には出していなくても、「今これを入れるのは負荷が高い」「このまま追加されるのは厳しい」と言っているように見えました。
そこでようやく、
「これはそのまま、開発に渡してはいけなかったのではないか」
「これでは私が何も考えず、そのまま持ってきているだけではないか」
と気が付きました。
顧客と話し、要望を受け取ることは、顧客の満足度や成果物の質を高めるうえで大切です。でも、受け取った要求をそのまま開発へ渡すことは、また別の話だったんですね。
開発側からすれば、それまで進めていた作業との優先順位も分からないまま、新しい要求だけが増えていく状態です。間に立っている私が何も調整や整理をしなければ、負担だけを渡していることになります。
その場で「対応します」と約束しなくなった
それからは、顧客から追加要求を受けても、その場で「対応します」と言わないようにしました。
なにか要求があれば一旦持ち帰り、開発側へ確認します。
見るのは以下のような点です。
- どこまで修正範囲が広がるか
- 関連テストがどれだけ増えるか
- 今の納期へ影響するか
- 既存作業を止める必要があるか
- 一部だけなら対応できないか
たとえ「画面を少し変えるだけ」に見えても、実際には複数の処理やテストへ影響することがありますし、逆に、全面対応は難しくても、一部だけなら今回入れられる場合もあります。
こうした確認をするようになってから、「思ったより影響が大きい」と分かることもあれば、一見難しそうな場合も「ここだけに限れば、今のタイミングなら対応できる」と分かることもありました。
最初から私一人で答えを決めるより、開発側が見えている影響を一度集めた方が、顧客へ返す内容も具体的になります。
必要に応じて、顧客へ「全面変更でなければいけないのか」「一部対応でも目的を満たせるのか」を確認し、そのうえで今回どこまで対応するか、別の方法で対応できないかを整理します。
追加要求を選択肢に変えて返す
開発側へ確認した後、私は顧客へ「できる／できない」だけを返すのをやめました。
代わりに、何を選ぶと何が変わるのかを整理して返すようにしました。
何を選ぶと何が変わるかを整理する
たとえば、以下のような形です。
- 今回この修正を入れるなら、総合テスト期間を短くする必要がある
- 納期を守るなら、別機能を次回へ回す
- 一部だけなら今回対応できる
- 全面変更するなら追加日数が必要
- 対応範囲によって費用にも影響が出る
単に「現場が忙しいです」と伝えても、顧客にとっては判断材料になりません。忙しいこと自体は珍しい話ではありませんし、「それで、この要求はどうなるのか」が分からなければ納得もしにくいですよね。
顧客から見ても大切なのは、追加要求を入れた結果、何に影響するのか、どこまでならできるのか、納期や費用にどう影響するのかを選択肢として確認できることでした。
実際にこの形で説明すると、
「そこまで影響するなら、今回は見送りましょう」
と言われることもあります。
こちらが一方的に断ったわけではありません。影響を確認した上で材料を返し、顧客自身が選んだ結果です。
この違いは大きかったです。
顧客の判断を開発側にも返す
以前なら、追加要求を持ち帰ったあと、開発メンバーへ「これもお願いします」と伝えていました。
でも顧客が見送ったときは、
「今回は見送りになりました」
「この範囲だけ対応することになりました」
と開発側へ返せます。
同じ「顧客から追加要求が来た」という状況でも、打ち合わせへ持っていく内容が変わりました。
要求そのものを運ぶのではなく、影響を確認し、決まった範囲まで整理して戻す。その方が、開発側も「また仕事が増えた」ではなく、「今回はここまで」と認識しやすくなります。
顧客担当者にも、その先に説明する相手がいます。「なぜ今回はできないのか」「いつならできるのか」「代わりに何ができるのか」まで整理されていれば、社内でも説明しやすくなります。
顧客の要求を全部受ければ開発へ負担が集中しますし、開発側の事情だけで全部断れば、顧客にも納得してもらえません。
だから今は、
「誰か一人へ負担を押しつけていないか」
「顧客にも開発にも、その理由を説明できるか」
を最後に確認しています。
要求を断ることより、影響を確認して、双方が判断できる形に整理することが調整役の仕事だと思っています。
まとめ
顧客から追加要求を受けたとき、以前の私はそのまま開発へ流していました。でも、会議室の重い空気をきっかけに、その進め方を変えました。
今は、以下のような順番で考えます。
- その場で約束しない
- 開発への影響を確認する
- 今回対応・次回対応・代替に整理する
- 何を選ぶと何が変わるかを顧客へ返す
「忙しいから無理です」だけでは、顧客は判断できません。何を入れると何が変わるのかまで分かれば、「今回は見送る」「一部だけ対応する」「次回へ回す」といった選択ができます。
顧客と開発の間に立つときは、どちらかへ要求を押しつけるのではなく、両方が判断できる材料へ変えて返すことが大切だと思っています。
コメント