「口頭でそう言ってたじゃないですか」——受託開発の現場で一度でもこのセリフを聞いたことがあれば、この記事は役に立つはずです。
口頭依頼は、炎上の入口になりやすいトラブルの源泉です。定例会の後、ランチのついでに、Slackのスレッドの隅で。顧客はカジュアルに依頼してきますが、PMが受け取り方を間違えると、後でそれが「決定事項だった」に化けてしまいます。
この記事では、顧客の口頭依頼を受けた瞬間にどう対処するか、具体的なルールを整理します。変更管理の全体論ではなく、「今この場で何を言うか・何を書くか」に絞った内容です。
口頭依頼が炎上の入口になりやすい理由
口頭依頼が問題になるのは、顧客が意図的に騙そうとしているからではありません。顧客側も「軽いリクエスト」として話しているケースがほとんどです。
問題が起きる構造は単純で、**「依頼した側は覚えているが、受けた側の記録がない」**という状態です。顧客は「あの件、対応してもらいましたよね」と前提で話してくる。PMは「それ正式な依頼として受けていないんですが…」と言いにくい状況になる。この繰り返しが積み重なると、対応しているのに評価されない、むしろ遅いと言われる、という悪循環に入ります。
また、口頭依頼の内容がチームメンバーに伝わっていないことも問題です。PMが「ちょっと確認してみます」と答えたことが、チームには「対応することになった」と伝わっている場合があります。
口頭依頼を4分類する
受けた口頭依頼は、その場で4種類に分けて判断します。この分類を意識するだけで、扱い方がぐっと変わります。
分類1：単なる質問・確認
「この機能ってこういう動きをしましたっけ？」という類です。回答はその場でできても、対応は発生しません。議事録に「〇〇の仕様についての質問あり、回答済み」と残しておけば十分です。
分類2：追加要望の候補
「ここにボタンを追加できますか？」「この画面の順番を変えてほしいんですが」という類です。「できるかどうか」の話であり、まだ依頼ではありません。持ち帰って工数確認→チケット起票→正式依頼として受ける流れに乗せます。
分類3：変更・修正の依頼
「この動きが間違っています、直してください」という類です。バグ修正なのか仕様変更なのかによって扱いが変わります。いずれにせよ、チケットを起票して対応記録を残します。
分類4：決定事項の伝達
「あの件、社内で決まりました」という類です。これは正式な合意として記録が必要です。議事録または確認メールで文字に起こし、双方確認済みにしておきます。
その場で約束しない言い方
口頭依頼を受けたとき、PMが犯しやすいミスは「わかりました」と言ってしまうことです。誠実に答えようとするほど、この言葉が出やすくなります。
代わりに使いたいのが次のような表現です。
「確認して折り返します」 — 工数が不明なものは必ずこれ。その場での約束を避けつつ、対応する姿勢は示せます。
「チケットに起票してもらえますか？」 — 追加要望の候補を正式な依頼として受け取る際の定型フレーズ。「チケットに書いてもらえたら確認します」と続けると自然です。
「今日の議事録で確認させてください」 — 決定事項の伝達を受けた場合。その場で記録せず、議事録で双方確認する形にします。
「対応するかどうか」ではなく「プロセスに乗せる」という話をするのがポイントです。顧客への印象としても、拒否ではなく確認姿勢に見えます。
議事録・チケットに残す基準
「全部記録する」は理想ですが、実際には文脈によって記録の粒度を変えます。判断の基準はシンプルです。
チケットに起票する基準
- 作業が発生するもの
- 誰かが確認・判断する必要があるもの
- 後でエビデンスが必要になりそうなもの
議事録に残す基準
- 会話の場で発生したすべての依頼・確認・決定の記録
- 特に「決定事項」「未決事項」「持ち帰り事項」は必ず記録
記録しなくてよいもの
- 純粋な雑談、天気の話
- 回答済みかつ作業不要の質問（ただし後日参照が必要そうなら残す）
判断に迷ったときは「後で揉めそうか」という基準で考えてください。「揉めそう」と感じるなら残す、それだけです。
次回確認へのつなげ方
その場で解決できない口頭依頼は、必ず「いつ返答するか」を伝えます。
「次回の定例でお答えします」「今週中に確認してご連絡します」——期限を明示することで、顧客は追いかけてくる必要がなくなります。追いかけられないと、顧客は「忘れられている」と感じます。そこから「なんで対応してないんですか」という話になります。
また、返答の期限をメールやSlackに書いておくと、双方の記録として機能します。「〇〇についての工数を木曜日までに確認してご連絡します」というひと言を送っておくだけで、そのやりとり自体が依頼の記録になります。
まとめ
受託開発PMの口頭依頼対応は、個人のコミュニケーション能力の問題ではありません。「分類する」「その場で約束しない」「記録する」という3つの動作ルールを持っているかどうかの問題です。
ルールを持てば、誰でも安定した対応ができます。顧客との関係が悪くなるどころか、「きちんとした進め方をする人」という印象につながります。
顧客対応の基本スキルや受託開発PMとしての実務力を体系的に学ぶなら、受託開発PM向けの課題別パックやITエンジニア向けビジネススキル講座が参考になります。口頭でのやりとりを議事録・チケットに落とす一連のフローは、実務に沿って学べる内容です。