顧客から急ぎの要望が来たら？期限と影響を確認する対応手順
顧客から「来週までに何とかしてほしい」と届いたとき、すぐ開発へ割り込ませるべきか迷っていませんか。急ぎの要望は、期限の理由、業務への影響、回避策を確かめて判断します。受付の返答を急ぐことと、実装を約束することを分けるのが出発点です。
この記事では、通常の機能要望が急ぎで届いた場合の確認と判断を扱います。開発の候補を普段から比較する方法は、開発優先順位の決め方で紹介しています。
- 希望期限の理由と業務への影響を確認する
- 回避策と実装を分けて比較する
- 既存計画への影響と次の連絡を残す
希望期限の理由と、止まる仕事を確かめる
「急ぎ」という言葉だけでなく、その期限に何が起こるかを尋ねます。締め作業があるのか、社内の説明会で見せたいのかでは、必要な対応が違います。
たとえば、架空の申請管理ツールに「来週までにCSV出力がほしい」という連絡が届いた場面を考えます。月末の集計に必要なのか、別のシステムへ移すためなのか、まず作業の目的を確認します。期限を過ぎた場合に誰の何が止まるのかも聞くと、影響を整理できます。
英国政府の利用者ニーズの整理方法は、提案された解決策だけでなく、利用者が達成したいことや問題を確認する考え方を示しています。急ぎの要望でも、希望する機能名から一度、必要な仕事へ戻ると、ほかの対応を検討できます。
| 確認すること | 質問の例 |
|---|---|
| 期限の理由 | その日までに、どの作業を終える必要がありますか |
| 影響する範囲 | 間に合わない場合、誰のどの作業が止まりますか |
| 現在の方法 | 前回はどのようにその作業を進めましたか |
| 確認できる相手 | 作業の手順を詳しく説明できる方はいますか |
発生中の障害や情報の漏えいなどが疑われる場合は、機能要望の通常の検討を待たず、自社の対応窓口へ引き継ぎます。この記事の手順を、障害対応の判定や手順の代わりには使いません。種別が曖昧な場合は、不具合と要望の違いも参考になります。
受付では、確認することと次の連絡を伝える
最初の返答では、受け取った期限と事情を確認し、次に何を調べるかを伝えます。まだ実現性が分からない段階で「対応します」と言うと、顧客が実装の約束として受け止めるかもしれません。
先ほどの例なら、「来週の集計にデータが必要なのですね。現在の出力方法で必要な項目を用意できるか、開発側へ確認します」と返せます。次に連絡する時点は、社内で確認できる見込みを確かめてから伝えます。
顧客から期限だけが繰り返し届く場合も、確認済みの内容を先に示すと、同じ説明を何度も求めずに済みます。「期限は確認できています。いまは必要な列と、現在の方法で不足する箇所を確認しています」と、残る論点を絞ります。
顧客への返信文例は機能要望への返信方法で扱っています。ここでは、急いでいる気持ちを受け止めつつ、実装の約束をする前に判断材料をそろえることが中心です。
回避策と実装を、期限に間に合う範囲で比較する
対応案には、既存機能の案内や一時的な手順も含めます。希望された機能を完成させることと、期限までに仕事を進められることは、別々に確認できます。
架空のCSV出力の例なら、既存の一覧から必要な情報を取得できるか、対象を絞れば手作業で対応できるか、機能を追加する必要があるかを検討します。手作業の案は、顧客や社内の負担、誤りが起きた場合の影響も確認し、単に「人がやればよい」で済ませません。
| 対応案 | 確認する条件 |
|---|---|
| 既存の方法を案内する | 必要な情報が足りるか、顧客が使えるか |
| 一時的な手順を用意する | 誰が実行するか、負担と確認方法は何か |
| 範囲を絞って開発する | 必要な確認を含めて間に合うか、残る制約は何か |
| 期限内の実装を見送る | 代わりの選択肢と、その後の確認をどう伝えるか |
案を比べるときは、作る時間だけでなく、確認・公開・顧客への案内に必要な時間も含めます。「一部だけ作る」場合も、権限や既存の操作へ影響しないかを確認し、急ぎであることを品質確認を省く理由にしません。
回避策を案内した後は、顧客が実際に必要な仕事を進められたかを確認します。案内した事実だけで要望を終了にすると、困りごとが残っていても見えなくなります。
割り込みで変わる計画と、判断理由を残す
新しい作業を入れるときは、既存の何を遅らせるか、目標への影響があるかを確認します。急ぎの要望だけを単独で評価すると、すでに進めている仕事の負担が比較から抜けます。
2020年版スクラムガイドは、スプリント中にスプリントゴールを危険にさらす変更をしないことや、品質を下げないことを定めています。これはスクラムの規約ですが、計画中の仕事へ割り込ませる際に、守る目標と品質を確認する観点として参考になります。
スクラムを採用していないチームでも、判断する人、遅れる作業、関係者への連絡をそろえます。受付した人が独断で順序を変えるのではなく、開発計画を判断できる人へ影響を渡して決めます。
判断の記録には、期限の理由、選んだ対応、既存計画への影響を一緒に残します。期限内に開発できない場合も、確認した根拠と次にできることを説明します。次の連絡は実装日と混同させず、何を確かめて知らせるのかを具体的にします。
対応後には、その要望が今後も繰り返されるかを見直します。今回だけの事情か、複数の顧客に共通する作業かで、通常の開発候補として扱う意味が変わります。急ぎの期間が終わったあとも、原文と判断理由を通常の要望記録へ戻しておきます。
よくある質問
大口顧客からの急ぎの要望は最優先ですか？
顧客の規模も判断材料ですが、期限の理由、業務への影響、回避策、既存計画への影響を確認します。契約額だけで開発の順序を確定しないようにします。
期限までに実装できるか分からない場合はどう返しますか？
確認している内容と、次に連絡できる時点を伝えます。実装の約束と確認結果の連絡を分け、分かっていないことを推測で埋めないようにします。
一時的な方法で解決したら、元の要望は消してよいですか？
対応の結果と残った負担を記録します。同じ作業が繰り返されるかを確認し、通常の改善候補に戻すか、再検討の条件を付けて終了するかを判断します。
まとめ
急ぎの要望は、希望期限の理由と業務への影響から確認します。回避策と実装を分けて比較し、既存計画への影響と次の連絡を残すと、急いで返答しながらも判断の根拠を保てます。対応後は通常の優先順位の検討へ戻し、同じ困りごとを繰り返さないために必要な改善を考えます。
