なぜエンジニアに話が伝わらないのか

「お願いしたはずのものと違うものが出てきた」「簡単だと思ったのに、できないと言われた」。開発と仕事をしていると、この2つが繰り返し起きます。

原因は技術力でも熱意でもなく、渡している情報の型が違うことにあります。埋めるべき欄が空のまま渡されているため、相手が推測で埋めるしかありません。

伝わる形を整理します。

1. なぜ伝わらないのか

理由1：前提が省略されている

依頼する側にとっては当たり前の業務知識が、相手には未知であることが多いです。

× 「キャンセル分を除いて集計してください」

これだけでは、次が分かりません。

• キャンセルはどこに記録されているのか
• 出荷後の返品はキャンセルに含むのか
• キャンセルされた月と、注文された月のどちらから引くのか

自分が「説明するまでもない」と思っている部分ほど、伝わっていません。

理由2：要望と手段が混ざっている

× 「この表にフィルタを付けてください」

これは手段です。本当に必要なのは「特定の条件のデータだけを見たい」という目的かもしれません。目的を伝えれば、もっと簡単な方法が出てくることがあります。

手段を指定すると、その手段しか検討されません。

理由3：判断に必要な情報が欠けている

エンジニアは実装の前に、いくつもの分岐を判断しています。

質問が多いのは、理解が浅いからではありません。 埋まっていない欄を埋めようとしています。

2. 依頼するときの型

6項目を埋めます。慣れると3分で書けます。

書き換えの例

× 「受注データのレポートを早めにお願いします」

○ 背景  : 毎週月曜の会議で、前週の受注状況を手作業で集計している（毎回2時間）
  目的  : 会議前に、前週の受注件数と金額を確認できる状態にする
  条件  : ・注文日ベース、キャンセルを除く
          ・商品カテゴリ別に分ける
          ・毎週月曜の朝9時までに更新されていること
  優先  : 必須＝件数と金額 / できれば＝前年同週との比較
  期限  : 今月末（来月の会議から使いたい）
  裁量  : 表示の方法、更新の仕組みは任せます

「裁量」の欄が効きます。 任せてよい部分を明示すると、確認のやり取りが減ります。

3. 避けたい言葉

曖昧な言葉は、そのまま曖昧な成果物になります。

「ちょっと」「簡単」は使いません。 作業量を判断するのは相手であって、依頼する側ではありません。この言葉は、見積もりを軽く見せる圧力として受け取られることがあります。

数値で言えるものは数値にする

4. 「できない」と言われたとき

否定ではなく、制約の説明であることが多いです。聞き方を変えます。

「何を諦めれば、何ができるか」を聞きます。 期間、精度、対象範囲のどれかを緩めると可能になることが多いです。

○ 「全件のリアルタイム更新が難しいなら、
    主要カテゴリだけ1時間ごと、では可能ですか」

5. 質問されたときの答え方

即答できないときに「確認します」で止めると、そこで作業が止まります。止めない答え方をします。

「どちらでもよい」は、はっきり伝えます。 伝えないと、相手は確認を待ち続けます。

6. 仕様を変えるとき

途中変更は起きます。伝え方で受け取られ方が変わります。

× 「やっぱりこうしてください」

○ 「先週お伝えした仕様を変更したいです。
    理由：現場から〇〇の要望が出たため
    変更点：Aの条件をBに変える
    影響が出そうなら、期限の相談をさせてください」

理由と、影響を聞く姿勢をセットにします。 変更そのものより、影響を確認せずに変えることが問題になります。

7. 用語の擦り合わせ

同じ言葉を違う意味で使っていることがあります。特に業務の言葉です。

1回、用語の対応表を作ります。 10行程度で足ります。これがあると、以後の会話の精度が上がります。

8. やりがちな失敗

途中で一度見せてもらいます。 30%の時点で方向が合っているか確認すると、手戻りが小さくて済みます。

まとめ

• 伝わらないのは、埋めるべき情報が欠けているため
• 依頼は背景・目的・条件・優先順位・期限・裁量の6項目で書きます
• 「なるべく早く」「いい感じに」「ちょっと」を使いません。数値で書きます
• 「できない」は制約の説明です。何を緩めれば可能かを聞きます
• 即答できないときも、進められる形で返します
• 用語の対応表を1枚作ります
• 完成前に一度見せてもらいます

手段ではなく目的を渡すと、たいてい自分が思いつかなかった方法が返ってきます。伝え方を変えるだけで、出てくるものが変わります。