見出し画像

頑張っているのに嫌われる。-嫌われないタスク依頼方法-プロジェクトマネジメント

ユーザー:「〇〇機能、早めに追加してほしいんですけど…」
営業:「クライアントから至急対応を求められています!」
PM:「はい!任せてください!」

「なんだか、あの人に依頼されるとやる気が出ないんだよな…」
「気づけば周りが疲れ切っていて、モチベーションが下がっている…」

1. 頑張るほど周りが疲れていませんか?

プロジェクトマネジメントやプロダクトマネジメント(以下、PM)を担うと、日々こんな場面に直面しませんか? タスクは山ほどある、スケジュールはカツカツ。でも、周囲を巻き込まないとプロジェクトは前に進まない…。そうやってどんどんタスクを依頼していくうちに、知らず知らずのうちに周りから「なんか嫌だな」「煙たがられているかも」と思われてしまうことがあります。

私(@suh_sunaneko)は複数のプロジェクトマネジメントやプロダクトマネジメントの業務に携わってきました。何度となくタスクの振り方で失敗し、チームの雰囲気を悪くしてしまったり、逆にうまく頼りながら高いモチベーションを保てた経験もありました。

このnoteでは、そんな失敗と成功の両方の経験から学んだ「嫌われないタスク依頼」をするための考え方をまとめています。特に「タスク依頼自体は仕事として当たり前なのに、どうしてこんなに相手を不快にさせてしまうのだろう?」と感じているPMの方に読んでいただけると嬉しいです。


2. まず押さえておきたい「依頼」にまつわる基礎

PMをしている以上、人にタスクを振る・依頼するのはまったく悪いことではありません。むしろ、「適切な人に適切な仕事をふって、プロジェクトを動かしていく」というのは、PMの大切な役割の一つです。

しかし、ただやみくもに依頼を繰り返すだけでは、次のような問題が起きやすいです。

依頼する際の言葉遣い・トーンが刺々しく、相手が不快に感じる

“なぜその人に頼むのか”という意図が伝わらず、モヤモヤを抱かせる

「またあれやってくれませんか?」と気軽に振るうちに、不満が積み上がる

結果的にチームのモチベーションが落ち、肝心のプロジェクト品質も下がる

一方で、きちんとした依頼ができるPMは、チームからの信頼を得やすくなります。するとどうなるか? 誰かに手伝ってほしい時に「いいですよ、任せてください!」という前向きな姿勢で応えてもらえるようになるのです。

「タスクを振ることは当たり前」だけど…

  • 当たり前だからこそ、「依頼の仕方が雑」だと反発を招きやすい

  • 自分の都合ばかりを優先すると、相手のモチベーションは急降下する

  • チーム内に不満の火種が残っていると、プロジェクトの成功確率は下がる

依頼が下手な人ほど、「仕事なんだからやって当たり前でしょ」と思い込みがち。そこで相手へのリスペクトや感謝を抜かしてしまうため、結果としてチームメンバーにストレスを与えてしまいます。


3. 嫌われる理由は大きく2つ:言い方の問題&役割定義の問題

「同じタスク依頼でも、受け取られ方がまったく違う」という経験はありませんか? Aさんがお願いすると「わかりました、やりますね!」とスムーズなのに、Bさんがお願いすると「うっ…またあの人からだ…」と微妙な空気になる、みたいな。

実は、嫌がられる原因は大きく2つに分類できると思っています。

  1. 言い方の問題

    • 上から目線

    • 感謝や敬意が伝わってこない

    • 納期や優先度ばかりを押し付ける

  2. 役割定義の問題

    • 「なぜこのタスクを自分がやるのか」不明確

    • 担当範囲があいまいで、押し付けられている気になる

    • チーム内での役割が定期的にすり合わせられていない

これらを解消することが、「嫌われないタスク依頼」の第一歩です。次からは、それぞれの原因をもう少し掘り下げて見ていきましょう。


4. 嫌われる原因1:言い方の問題

まずは言い方の問題です。これは誰しもが少なくとも一度は体験したことがあるでしょう。典型的な例を挙げてみます。

  • 急に「これやっといて」と言われる
    納期や優先度の説明なし。感謝の言葉もなし。相手が抱えているタスク状況もお構いなしだと、受け取る側は戸惑いしかありません。

  • 「○○が終わらないと困るんで、早くやって」
    「お互い協力して進めよう!」ならまだ気持ちいいのですが、「とにかく急いでやれ」と押し付けられると反発心が芽生えます。

  • 偉そう・上から目線がにじみ出ている
    「それくらいわかるでしょ?」や「本来は自分でできるけど、あなたのために振ってあげるよ」といったニュアンスが伝わると、一気にやる気を削ぎます。

もちろん、PMとしては「スケジュールが迫っているから」「クオリティを担保したいから」など、いろいろな理由で急ぎで依頼せざるを得ない状況もありますよね。とはいえ、最初のコミュニケーションで相手の心象を悪くしてしまうと、その後ずっとギクシャクしがちです。

言い方を工夫するだけでも違う

  • 相手へのリスペクトを示すフレーズ

    • 「お忙しいところ恐縮ですが…」

    • 「いつも助けていただいてありがとうございます。」

    • 「専門知識が必要なので、ぜひ力を借りたいのですが…」

  • 依頼の背景を簡潔に伝える

    • 「△△までにリリースしないと大きな機会損失があるので、ご協力いただけると助かります。」

    • 「このタスクが終わると、▲▲というメリットが得られるんです。」

  • 相手の都合を聞く

    • 「もし難しいようでしたら調整しますが、スケジュール的にいかがでしょう?」

ちょっとした配慮で、受け手の印象は大きく変わります。すごく初歩的に思えるかもしれませんが、忙しくなってくると人は忘れがちなポイントでもあります。


5. 嫌われる原因2:役割定義の問題

次に役割定義の問題です。これは「どうして自分がそのタスクをやらなければならないのか」が不明確なまま仕事を押し付けられるように感じる状況を指します。

こんなこと、思い当たりませんか?

  • PM「〇〇さん、この作業お願いしていいですか?」
    相手「(なんで私? でも言えない…)わかりました。」

    • 実は内心モヤモヤしているのに、その場で「嫌です」とは言えず、引き受けてしまう

    • 不満はどんどん溜まっていくが、表面上は普通に仕事をこなす

    • PMは「すんなりOKもらえたし助かる」と思い込み、また同じようにお願いする…

    • …結果、メンバーの不満は爆発寸前

役割定義が曖昧だと何が起きる?

  • 依頼する側は「適材適所」で振っているつもりでも、相手が納得していない

  • 負のループに陥り、チーム内の信頼関係が悪化する

  • 周囲のモチベーションを下げるだけでなく、プロジェクトの質にも影響

役割定義をすり合わせる重要性

たとえば、新規プロジェクトの開始時や定例ミーティングなどで、**「各メンバーの担当領域はどこからどこまでか」**を確認する時間をしっかり取りましょう。システム企画と業務企画、営業と開発など、複数のチームが連携するプロジェクトでは特に大切です。

  • 業務企画:「何を実現したいか」を考えるのがメイン

  • システム企画:「どう実装するか」を考えるのがメイン

このように、どちらが主導権を持って進めるべきか、あらかじめ線引きしておくだけでも随分と違います。

また、「もう誰がやるかわからないタスク」が浮き玉になっている場合は、PM自身が拾うか、あるいは「これはどのチームの担当にも入らない作業です」という事実を正直に提示して協力を仰ぐ姿勢が大事です。曖昧なまま他人に押し付けるのはNGです。


6. 浮き玉のタスクをどう扱うか

PMをやっていると、本来は誰が担当するのか不明なタスク(通称:浮き玉タスク)が大量に発生しますよね。典型例としては、

  • ドキュメント整備や議事録作成、打ち合わせ調整などの事務作業

  • 新しいツールの導入検討で、どこの部署にも属さない検証作業

  • 開発チーム・営業チーム間の「調整役」そのもの

浮き玉タスクを放置すると…

  • 「なんとなく暇そうな人がやる」という曖昧な状態が続く

  • 結局、声の大きい人が押し付けたり、黙って引き受ける人が消耗したりする

  • 不公平感が募り、チームの空気が悪くなる

PMが意識すべきは、「一旦自分が引き受ける覚悟」と「このタスクがチーム全体のどこに属するか」をオープンに議論することです。
「すみません、実はこれが誰の役割にも当てはまっていないんです。今回だけ私が対応しますが、今後はどうしましょうか?」と提案してみるのも手です。



7. PMが本当に目指すべきは「長期的に人間関係を築くこと」

プロジェクトマネージャーは「プロジェクトを成功させる」ことがゴールだと思われがちですが、私はそれ以上に**「長期的に良好な人間関係を築き、チーム全員が気持ちよく仕事できる環境を作る」**ことが大事だと考えています。

なぜ長期的視点が重要なのか

  • プロジェクトが終わっても、同じメンバーや社内外のステークホルダーと再び仕事をする可能性が高い

  • 短期的にはうまくいっても、メンバーが疲弊しきってしまうと次のプロジェクトでうまく協力を得られない

  • 現在のプロジェクトだけでなく、チームの「将来の成長」を見据えた仕事の進め方をする方が結果的に効率的

「頼み方が丁寧だし、一緒にやっていると学びも多いから協力したい!」と周りに思ってもらえるPMは、本当に強いです。依頼されたメンバーも気持ちよく動けるので、結果としてプロジェクトの成果も上がりやすくなります。


8. 実践的なステップまとめ

ここまでの内容を踏まえ、実際に「嫌われないタスク依頼」を行うためのステップを再度整理してみましょう。

ステップ1:依頼の前に自分の意図を明確にする

  • 何を、いつまでに、どのようなクオリティでやってほしいのか

  • なぜその人に頼むのか(専門性、経験、担当範囲など)

  • 依頼がプロジェクトや相手にもたらす価値を言語化

ステップ2:相手の都合や忙しさを確認し、背景を説明する

  • いきなり依頼ではなく、まずは「今お時間よろしいですか?」から始める

  • 「実は〇〇の理由があって、今週末までに終わらせたいんですが…」など、背景と期限を具体的に伝える

  • 「タスクが重なっているなら、優先度調整や一部タスクの分担を検討します」と柔軟な姿勢を見せる

ステップ3:感謝と敬意を込める

  • 「お忙しいところ恐縮ですが」といった一言で印象は大きく変わる

  • 仕事とはいえ、人の時間を奪う行為なので、**「ありがとう」や「助かります!」**の姿勢を忘れずに

ステップ4:役割定義を定期的にすり合わせる

  • プロジェクトの初期・中期などで**「誰が何を担当するのか」**を見直し

  • 新しいタスクが出たときにも「これは本来誰の担当領域なのか?」を迷ったら確認する

  • 担当外の作業をお願いする場合、**「本来の領域ではないけれど、今回だけサポートしてほしい」**と明確に言う

ステップ5:浮き玉タスクはオープンな話し合いで対応

  • PM自身が一旦引き受けるか、チームに相談して協力を仰ぐ

  • 「誰も担当じゃないんだけど重要な作業」という事実を共有し、割り振りを検討

  • 放置や丸投げは避け、チームの理解を得ながら進める

ステップ6:フォローアップとフィードバック

  • 依頼して終わりではなく、進捗や困りごとを適宜確認する

  • 完了したら成果の共有、そして改めて感謝の言葉を伝える

  • 「ここはうまくいった」「ここはもう少し早くサポートできたかも」といった振り返りをチームで行う


9. おわりに:嫌われないタスク依頼で、チーム全体をハッピーに

PMという仕事は、「期限内に成果を出す」ことが大きなミッションです。つい、それだけを最優先にしてしまい、周囲に対する言動が乱暴になったり、役割を押し付ける形になったりしがちです。でも、目先の成果だけを追いかけてチームの関係性を壊してしまうと、長い目で見たときに損失が大きいのも事実です。

・依頼の仕方を少し変えるだけで、相手のモチベーションは格段に上がる
役割定義をこまめに確認することで、「なんで自分が?」という不満を解消できる
浮き玉タスクにPMが真摯に向き合うと、チーム全体からの信頼が高まる

プロジェクトが終わっても、また同じメンバーと一緒に仕事をすることは多々ありますよね。ぜひ、本記事を参考に「嫌われないタスク依頼」を心がけて、長期的に見てもチーム全員が気持ちよく働ける環境づくりを進めてみてください。

ちょっとした宣伝

私は、X(@suh_sunaneko)を中心にプロダクトマネジメントやプロジェクトマネジメントに関する情報を発信しています。タスク依頼のコツや役割定義のやり方など、日々の現場で使えるTipsを共有しているので、興味があればぜひフォローいただけると嬉しいです。
PMが不足していてプロジェクトが始められない方は、「PM代行サービス」も行っておりますので、ぜひ無料相談いただければ幸いです。

ここまで長文をお読みいただき、ありがとうございます。何か一つでも「なるほど、今度試してみようかな」と思うものがあれば幸いです。あなたのプロジェクトとチームが、よりスムーズかつ気持ちよく進行しますように! それではまたどこかでお会いしましょう。


いいなと思ったら応援しよう!

ピックアップされています

システムエンジニアのお勉強

  • 29本

コメント

コメントするには、 ログイン または 会員登録 をお願いします。
AI駆動PM | PM(プロジェクト/プロダクト)のやる気が1mmだけ上がる仕事術を発信 ◻︎経歴: アクセンチュア(PM) ▶︎ 事業会社(PjM/PdM) ▶︎ 起業 PMコミュニティ『PM研究所』運営中 https://sunaneko.jp/pmlab
頑張っているのに嫌われる。-嫌われないタスク依頼方法-プロジェクトマネジメント|すぅ | AI駆動PM
word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word word

mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1
mmMwWLliI0fiflO&1