「PMからの依頼が唐突すぎる」「何でそれが必要なのか分からない」——開発チームがPMに対してそう感じている現場は少なくありません。PMとしては「必要なことを依頼しているだけ」のつもりでも、エンジニアの立場から見ると「なぜ今？」「なぜそれを？」が伝わっていないことがあります。
信頼される依頼の出し方は、エンジニアを「動かす」というより「一緒に動く仲間として扱う」という姿勢から来ます。
開発チームに信頼されない依頼の特徴
開発チームとの関係が悪化しやすい依頼には、共通したパターンがあります。
- 「できますか？」と聞かずに「やってください」から始まる
- なぜその作業が必要なのかが伝わらない
- 技術的な難しさを考慮しない期限が設定される
- 「後から判断するので、今すぐ全部やって」という言い方になる
これらの依頼を受けたエンジニアは「PMは現場を分かっていない」と感じます。一度そう思われると、次の依頼への協力度も下がります。
依頼前に整理する背景
依頼をする前に、「なぜこの作業が必要なのか」を自分の言葉で説明できるようにします。
- 誰のために、何のための作業か
- いつまでに必要で、なぜその期限なのか
- 品質や形式について、どこまで求めるのか
この背景を伝えることで、エンジニアが「何が大切で、何は多少妥協できるか」を自分で判断できるようになります。目的が分かると、エンジニアは「もっとよい方法があります」という提案を持ってきてくれることもあります。
目的と制約を伝える
依頼のテンプレートとして、以下を意識してみてください。
「来週の顧客レビュー（目的）のために、A画面の設計書を金曜までに更新してほしいです（期限）。今回は機能説明だけでよく、詳細の実装仕様は不要です（制約）。もし金曜が難しい場合は水曜に教えてください（余地）」
このくらいの情報が入った依頼は、「何のために動けばよいか」が明確なので、エンジニアが迷わず動けます。
相談余地を残す
依頼を「命令」ではなく「相談」として出せる場面では、必ず余地を残しましょう。
「○日までにできますか？」「この方法でよいですか？」という確認の一言が、エンジニアに「自分の意見を聞いてもらえる」という感覚を与えます。
また、「技術的に難しい点があれば教えてほしい」という一言も入れておきます。エンジニアが「それはちょっと難しいですが、こうすれば解決できます」と言いやすい環境を作ることが、PMとチームの信頼の土台になります。
依頼の悪い例・良い例
| 場面 | 悪い例 | 良い例 |
|---|---|---|
| 設計書の修正 | 「この設計書、直してください」 | 「◯◯さんから仕様変更が入りました。3ページ目のフロー図を修正してほしいです。今週金曜までに確認できますか？」 |
| バグ修正の依頼 | 「このバグ早めに直してほしいです」 | 「顧客から画面Xのエラーが報告されました。来週月曜の定例前に状況を確認したいのですが、今週中に見ることはできますか？難しければ代替策を相談させてください」 |
「何を・いつまでに・なぜ必要か」が依頼に入ると、受け取る側が動きやすくなります。
依頼後の確認と感謝
依頼したあと、完了報告が来たときに「ありがとうございました」「助かりました」と一言添える習慣が、長期的な信頼関係を作ります。
成果物の内容に問題があった場合でも、まず感謝を伝えてから修正点を話すことで、次のやり取りがスムーズになります。「いきなりダメ出し」は関係を消耗させます。
まとめ
開発チームに信頼される依頼の出し方を整理しました。
- 依頼前に「なぜこの作業が必要か」を自分の言葉で説明できるようにする
- 目的・期限・制約・余地の4点を依頼に含める
- 「命令」ではなく「相談」として出せる場面では必ず確認の一言を入れる
- 完了後の感謝を習慣にする
開発チームとの信頼は、一度の依頼で築けるものではありませんが、一度壊れると修復にも時間がかかります。日頃の依頼の仕方の積み重ねが、チームとの関係を作ります。
チームコミュニケーションと実務スキルを学びたい方はこちらもどうぞ。