「お願いしたのに思っていたものと全然違うものが来た」「期限の日になってみたら、まだ着手すらされていなかった」——依頼した側が何かを言わなかったのか、受けた側が確認しなかったのか、どちらにも原因があることが多いですが、PMとして防げることはあります。
依頼が曖昧だと手戻りが増え、PM自身の時間も奪われます。
依頼が曖昧だとPMの手戻りが増える
依頼が曖昧なまま動き始めると、担当者は「おそらくこういう意味だろう」と自分で解釈して進めます。その解釈がPMの意図とずれていた場合、作業を最初からやり直すことになります。
担当者を責めることはできません。PMが「目的・完了条件・期限」の3点を最初から明確にしていれば、こうした手戻りの多くは防げます。
条件1：目的
「なぜこのタスクが必要なのか」を最初に伝えます。
目的が分かっていると、担当者は作業中に判断が必要な場面で自分で考えて動けます。目的が分からないと、「自分の判断で進めてよいか分からない」という状態になり、確認の往復が増えます。
悪い例：「この画面の仕様をまとめておいてください」 良い例：「来週の顧客定例でA画面の仕様説明があるので、口頭で説明できる資料を作ってほしいです」
「来週の顧客定例のため」という目的が分かれば、担当者はどのレベルの資料を作ればよいかを自分で判断できます。
条件2：完了条件
「どういう状態になったらOKか」を具体的に伝えます。
これがないと担当者は「ある程度できたら提出しよう」という感覚で動くため、PMが求めるレベルと実際の成果物にギャップが生まれます。
悪い例：「スケジュールを更新してください」 良い例：「スケジュールを更新して、遅延している3タスクに新しい完了予定日を入れてください。更新後はSlackで完了報告をしてください」
完了の状態が具体的なほど、確認の手間が減ります。
条件3：期限と確認タイミング
期限を伝えるだけでなく、「途中で確認するタイミング」も合わせて伝えておきましょう。
「金曜日まで」と言うだけでは、担当者が金曜の夕方に着手することも起こりえます。「水曜に途中確認させてください」という一言があると、進捗が見えるタイミングができます。
また、期限が守れなそうになったときに早めに言ってもらえるよう、「途中で詰まったら早めに知らせてほしい」と添えておくことも有効です。これは依頼の文化として積み重ねていくものです。
悪い依頼例と良い依頼例
悪い依頼例： 「田中さん、課題管理表を更新しておいてください」
この依頼では「どこを」「いつまでに」「どの状態に」が不明です。
良い依頼例： 「田中さん、明日の定例前までに課題管理表の対応中ステータスの課題に、最新の進捗コメントを入れておいてほしいです。分からないところがあれば木曜夕方までに教えてください」
目的（明日の定例前に使う）・完了条件（最新コメントを入れる）・期限（木曜夕方）が入っています。
受託開発では、顧客向けデモや設計書レビューなど締め切りの意味合いが重い依頼が多くなります。
受託開発での依頼例（悪い）： 「デモ用の資料、準備しておいてください」
受託開発での依頼例（良い）： 「来週火曜の顧客デモで使うために（目的）、A機能の操作手順を5ステップで示したスライドを1枚お願いしたいです。顧客に口頭で説明できる粒度で十分です（完了条件）。金曜午前中までにご共有いただけますか。木曜夕方に一度途中確認します（期限）」
依頼後のフォロー方法
依頼したら「あとは期限まで待つ」ではなく、途中で一度声をかけることが大切です。「○○の件、順調ですか？」という短い確認が、担当者に「気にかけてもらっている」という安心感を与え、問題が早めに出てくる文化を作ります。
ただし、過度な確認は逆効果です。期限の半分程度のタイミングで1回確認する程度が適切です。
まとめ
PMが担当者への依頼で曖昧にしない3条件を整理しました。
- 条件1：目的（なぜこのタスクが必要か）
- 条件2：完了条件（どういう状態になればOKか）
- 条件3：期限と確認タイミング（いつまでに・途中で確認する日時）
この3点が揃った依頼は、担当者にとって動きやすく、PMにとっても手戻りが少ない状態を作ります。
依頼力を含むPMの実務スキルを体系的に学びたい方は以下もご覧ください。