結論：「わかりました」が返ってくる依頼は、相手に判断を委ねている部分が多すぎる。完成のイメージ・期限・確認のタイミングが最初から書いてある依頼は、相手が具体的な行動に移れる返事を引き出しやすい。

外注先に何かを頼んだとき、返ってくる「了解です」「わかりました」は、どこまで理解されているのか読めない。

返事が来た時点では問題ないように見える。だが納品の直前になって「この部分、どういう意味でしたか？」という確認が来たり、上がってきたものが想定と全然違う仕上がりだったりする。

「わかりました」は内容の理解ではなく、受け取り確認に過ぎないことが多い。

「わかりました」が返ってくる依頼の特徴

確認漏れが起きやすい依頼には共通した構造がある。

完成形が書いていない

「このページのリライトをお願いします」という依頼は、何が終わったら完成なのかが書いていない。リライトとは文章を直すことなのか、構成から変えることなのか、SEOも意識するのか。受け取る側はその全てを自分で解釈する。

解釈のばらつきが、納品時の「これじゃないんですが」につながる。

期限が曖昧

「できたら教えてください」「早めにお願いします」という期限は、相手の感覚に委ねている。「早め」が3日後なのか1週間後なのかは人によって違う。

期限がないタスクは、他の急ぎの案件に押されて後回しにされやすい。

確認タイミングが設定されていない

「わからないことがあれば聞いてください」という依頼は、聞くべきタイミングを相手に委ねている。「作業を始めてから気づいた」「納品直前に不安になった」という状況で確認が来ると、対応コストが一気に上がる。

「不明点は◯日までに確認してください」という期限付きの聞き口が、早い段階での確認を促す。

「わかりました」が変わる依頼文の要素

確認漏れを減らす依頼文には、以下の5つが含まれている。

1. 担当者名と役割

「お願いします」だけでなく「岸本さんにお願いします」「制作の担当として入ってください」という、誰が何をするかの明示。複数人が関わる場合は特に重要で、「誰かがやってくれると思っていた」という状況を防ぐ。

2. 期限と「期限の意味」

「6月30日まで」だけでなく「6月30日に私がクライアントへ提出するので、それまでに」という背景があると、相手が期限の重さを理解できる。期限が業務上どういう意味を持つかが見えると、優先度の判断が相手にも委ねられる。

3. 完成基準

「作成してください」より「◯◯の状態になったら完成です」というゴール定義が、後からの認識ずれを防ぐ。完成の条件を書くのが難しければ、「こういうものは含みません」という除外条件でもいい。

4. 参照情報の場所

「以前送ったブリーフを参考に」より「このタスクのコメントに資料を添付しました」という場所指示が、相手が迷わず動ける状態を作る。

5. 確認期限

「不明点は◯日◯時までに聞いてください。それ以降は一度進めてください」という確認の締め切りが、作業着手前の確認を促す。確認期限がないと、作業途中に「やっぱり聞いておけばよかった」という状況が発生しやすい。

タスクとして書かれた依頼が返事の質を変える

チャットで流した依頼文と、タスク管理ツールの「タスク」として渡された依頼は、相手の受け取り方が異なる。

チャットの依頼は会話の流れの中の一つのメッセージで、スクロールすれば流れる。タスクとして渡された依頼は、完了するまで残り続ける。チェックボックスがあり、期限が表示されており、完了させるまで「未完了」という状態が続く。

タスクとして依頼を渡すと、相手の行動が「返事を送る」から「タスクを完了させる」に変わる。「わかりました」という返事ではなく、ステータスの変化・コメントの更新・完了の通知が、依頼者の手元に届くようになる。

依頼の前に確認するチェックリスト

依頼を送る前に以下を自問すると、「わかりました」で終わる依頼を減らせる。

  • この依頼が完了したとき、何が起きているか書いてあるか
  • 期限はいつで、なぜその日か書いてあるか
  • 不明点があったらいつまでに聞けばいいか書いてあるか
  • 参照すべき資料の場所が書いてあるか
  • 担当者が自分一人であることが明確か

全部に「Yes」なら、相手が迷わず動ける依頼になっている。

関連記事

外注先との情報共有設計：外部メンバーへの情報共有設計｜どこまで見せるか・何を伝えるかの基準

業務委託メンバーの稼働把握：業務委託メンバーの稼働時間を把握する方法｜マイクロマネジメントにならない確認設計

タスク依頼の基本設計：外注向けタスク管理ツール 5選比較｜越境チームに必要な条件