【初心者向け】顧客の期待値ハンドリング 日常と業務の実践術
はじめに：なぜ期待値調整が難しいのか？
「この仕様って、最初から決まってましたっけ？」
ある日、顧客からそう言われて、血の気が引いたことがありました。
私自身、駆け出しの頃は何度も期待値のズレでプロジェクトを炎上させてきました。
「関係性を壊したくないからOKしてしまう」
「全部伝えたつもりだったのに、相手は違う理解をしていた」
そんなすれ違いが積み重なり、気づいた時には火の手があがっていたのです。
この記事では、そうした失敗を乗り越えて得た
「誰でも実践できる、でも意外とやれてない期待値ハンドリングの日常と業務での方法」
を紹介します。
日常での会話編
まずは日常から顧客との関係構築が大事。
日常の交渉術①：「Yes, but」でまず受け止め、次に調整する
顧客から「この機能も追加したいんです」と言われたとき、
つい「いや、それは厳しいです」と即答していませんか？
そんな時こそ、「Yes, but」のアプローチが有効です。
- 「Yes」で受け止める：要望を否定せず、まずは理解・共感を伝える
- 「but」で現実を共有：スケジュールや工数の制約、影響範囲を丁寧に説明する
例：
❌ 従来の対応
「それは難しいですね。工数が足りません。」
✅ 改善後の対応
「素晴らしいアイデアですね！その機能があれば確かに使いやすくなります。実装には約40時間の工数が必要で、現在のスケジュールだと納期が2週間延びる可能性があります。他の機能との優先度はいかがでしょうか？」
この手法を使うだけで、顧客からの信頼や納得感が格段に上がります。
今すぐ使える「Yes, but」フレーズ集
- 「もちろん可能です。ただし、セキュリティ面での検討が必要で...」
- 「とても良いご提案です。実現するには、他の機能への影響が...」
- 「ぜひ実装したいです。品質を保つために、テスト期間を...」
日常の交渉術②：文章ではなく、口頭での確認を重視する
Slackやメールだけで済ませると、無機質なやりとりになりがちです。
人間性が伝わらないと、相手は遠慮なく無茶な要望をしてきたり、誤解が起きやすくなります。
ポイント：
- 5分でもいいので、声を聞く（Zoomや電話）
- 会話のあとには必ず議事録を送る
- 普段から軽い雑談や状況共有で関係性を築いておく
たったそれだけで、トラブル時にも冷静に話し合える“信頼貯金”ができていきます。
効果的な口頭コミュニケーション戦略
困った時は迷わず電話・対面
- 仕様の認識齟齬が発生した時
- スケジュールに影響する問題が発生した時
- 顧客が感情的になっている時
雑談力も重要なスキル
「今週は検索機能の実装で少し苦戦してまして...」
「お疲れ様です。何か難しい部分があるんですか？」
→ 自然な会話の中で状況共有と期待値調整
必須ルール：記録を残す
口頭での合意内容は必ず文書化します。
テンプレート例：
【電話会議 記録】2024/XX/XX
参加者：○○様、△△（PM）
議題：検索機能の仕様変更について
決定事項：
・部分一致検索のロジック変更 → 実装
・検索履歴機能 → 次版に延期
・テスト期間 → 3日間追加
次回確認：XX/XX（金）14:00
業務での会話編
次に業務で実際に使う期待値ハンドリングについて。
業務の交渉術①：QCD（品質・コスト・納期）の優先順位を事前にすり合わせる
プロジェクト開始時の「危険な会話」
顧客：「高品質で、安く、早く作ってください」
あなた：「はい、頑張ります！」
この会話、実は爆弾を抱えているのと同じです。
プロジェクト開始前に絶対にやるべきなのが、QCDの優先順位確認です。
QCDとは：
- Quality（品質）
- Cost（コスト・予算）
- Delivery（納期）
これらすべてを完璧にすることはできません。だからこそ、何を最も重視するかを早めにすり合わせておく必要があります。
例：
- 納期優先：「展示会に間に合わせたいので、品質は最低限でOK」
- 品質優先：「多少遅れてもいいので、しっかりテストして完成度を高めたい」
この合意があるかないかで、進行中の意思決定のスピードとストレスがまったく違ってきます。
実際の確認シート例：
【QCD優先度確認シート】
Q（品質）: ★★★☆☆ バグは許容範囲内で
C（コスト）: ★★★★★ 予算厳守が最重要
D（納期）: ★★★★☆ 多少の延期は可能
具体的な合意事項：
・致命的でないUIバグは次版で修正
・追加機能要求時は別途見積もり
・納期は最大1週間の調整可能
業務の交渉術②：完成度60%での早期共有
「完成してから見せます」の罠
完璧主義は危険です。完成してから見せて「イメージと違う」と言われた時の絶望感...経験ありませんか？
「中途半端なものを見せたら、不安にさせてしまうのでは？」
そう思って完成まで見せないでいると、最後の最後に大きな齟齬が発覚するリスクがあります。
だからこそ、完成度60%の段階で共有するのが理想です。
目的：
- 顧客の想像と実物のズレを早期に見つける
- 認識の差異を調整する
- 新たな発見や改善点を取り込む
「まだ途中ですが、ご意見をいただきたいです」と前置きしておけば、むしろ誠実な印象になります。
60%共有で防げること
- 「思ってたのと違う」の大幅修正
- 土壇場での仕様変更
- 納期直前のパニック状態
- チーム全体のモチベーション低下
おわりに：技術だけじゃない、「信頼を設計する力」
自分はコードを書けたと思っていたプロジェクトでも、いざ顧客の前に立たされてみると全然違う要望に面食らった思い出があります。
日常の会話から相手に話をしてもらう姿勢をとってもらい、業務ではQCDのすり合わせと早期共有で、あんなに理不尽なこと言う人が「なーんだ話通じるじゃん」になってきました。
特に「Yes, but」と「QCDのすり合わせ」は、今すぐ試せる強力な武器です。
次の案件で、まず一つだけでも試してみてください。
プロジェクトが少しずつ穏やかに、そしてうまく回り始めるはずです。
Discussion