「任せたのに動かない」を防ぐ、権限委譲の設計手順

「この仕事、任せたはずなのに進んでいない」。マネージャーになってから、この種のモヤモヤを抱えた経験がある人は多いはずです。

催促すれば「すみません、どう進めるか迷っていて」と返ってくる。結局自分で巻き取り、自分の本来の仕事は夜に回る。任せたはずなのに、任せる前より忙しくなる悪循環です。

そして一度この経験をすると、「自分でやった方が早い」という結論に流れがちです。プレイヤーとして優秀だった人ほど、この罠にはまります。

結論から言います。権限委譲がうまくいかない原因の多くは、メンバーの能力ではなく「渡し方の設計」にあります。

結論

権限委譲の失敗は、能力の問題である前に設計の問題です。「何を任せるか」「どこまで決めていいか」「いつ・どう確認するか」の3点を渡す前に言語化するだけで、任せた仕事が止まる頻度は大きく下がります。

「任せる」と「丸投げ」は何が違うのか

まず言葉の整理です。「任せる」と「丸投げ」の違いは、仕事を渡した後に責任を持ち続けるかどうかにあります。

丸投げは、渡した時点でマネージャーの頭からその仕事が消えている状態です。成果物の基準も期日も曖昧なまま「いい感じにやっておいて」で終わり、失敗したときだけ登場して指摘する。これではメンバーは挑戦ではなく罰ゲームと感じます。

一方、任せるとは「プロセスの決定権を渡し、結果への責任は共有する」ことです。決めていい範囲を明示し、困ったときに戻ってこられる場所を用意しておく。この前提があって初めて、メンバーは安心して自分の判断で動けます。

現場で見てきた限り、「任せたのに動かない」と感じる場面の大半は、メンバー側から見ると「どこまで自分で決めていいのか分からない」状態です。動かないのではなく、動けない。性格ややる気の問題にする前に、ここを設計で解消するのが先です。

なお、「自分でやった方が早い」は短期的には事実であることが多いです。ただしそれは今日の話で、3か月後も自分でやり続けるコストまで含めると、ほとんどの場合で委譲した方が安くつきます。比較すべきは「今日の速度」ではなく「チームの総生産量」です。

何を任せるか。委譲する仕事の選び方

すべての仕事が委譲に向くわけではありません。選ぶ基準は、シンプルに2軸で考えます。

1つ目は「失敗したときのリカバリーが効くか」です。納期に余裕がある、やり直しが可能、影響範囲が社内に閉じている。こうした仕事は、多少の失敗を学習コストとして許容できます。

2つ目は「本人の成長につながるか」です。今の実力で8割はできて、残り2割に背伸びが必要な仕事が理想です。完全に手の内にある作業だけを渡しても単なる作業分担にしかならず、逆に背伸びが半分を超えると本人が潰れます。

たとえば「定例レポートの作成と、その内容を踏まえた改善提案」のような仕事は、作業部分で土台を確保しつつ、提案部分で背伸びができる良い組み合わせです。

逆に委譲に向かないのは、対外的な約束が絡む初回対応や、人事・評価に直結する判断です。これらは決定権そのものは渡さず、情報収集や案づくりの部分だけを切り出して任せる方法があります。「判断は渡せないが、判断材料づくりは渡せる」という分け方を覚えておくと、委譲できる仕事の幅が一気に広がります。

渡す前に決める、設計の3点セット

任せる仕事を決めたら、渡す前に次の3点を言語化します。口頭で済ませず、短くてもテキストに残すのがポイントです。後から「言った・言わない」を防ぎ、メンバーが迷ったときに立ち返る場所になります。

  1. Step 1: 完成の定義を書く

    「誰が、いつまでに、何を見てOKと判断するか」を1〜2行で書きます。過去の類似例や参考になる成果物があれば添えます。

  2. Step 2: 決めていい範囲を明示する

    「この金額までは自分で判断していい」「関係部署への一次連絡は任せる、最終合意の場には私が同席する」のように、決定権の境界線を引きます。

  3. Step 3: 確認のタイミングを先に約束する

    「水曜の1on1で5分だけ進捗を聞く」「方向性が固まった段階で一度見せてほしい」と、チェックポイントを最初に合意します。

3点目が特に重要です。確認のタイミングを先に決めておかないと、マネージャーは不安になって随時口を出し、メンバーは監視されている感覚になります。「ここまでは見ない」という約束は、メンバーの裁量を守る防波堤として機能します。

この3点を書く時間は、慣れれば5分程度です。5分の設計を省いた結果、巻き取りに数時間を使うのが典型的な失敗パターンなので、ここは省かないことを勧めます。

任せた後の関わり方。介入の我慢と、送り出す覚悟

設計して渡したら、次はマネージャー側の我慢の番です。途中経過が自分のやり方と違っても、完成の定義を満たす道筋にあるなら口を出さない。ここで介入すると、せっかくの設計が台無しになります。

ただし、本人から質問が来たときは別です。このとき答えをそのまま渡すのではなく、「どの選択肢で迷っている?」「自分ならどっちにする?」と問い返して、判断の練習機会に変えます。答えを渡すのは早いですが、渡すたびに次の質問が増えます。

この点について、私自身の経験を1つ書きます。以前、異動希望を出してきた中堅メンバーがいました。チームの主力で、正直なところ、抜けられると短期的には大きな痛手です。それでも引き止めず、送り出すことを選びました。

そのとき実感したのは、引き止めは短期の損失回避にすぎず、送り出しは長期の信頼構築になるということです。本人はその後も社内で活躍し、別部署との連携で何度も助けられました。権限委譲も構図は同じで、目先の品質や速度を理由に仕事を手元に戻すのは短期の最適化です。多少の遠回りを許容して任せ切ることが、半年後のチームの実力に変わります。

もう1つ。任せた仕事がうまくいったら、成果は本人のものとして扱います。「私がフォローしたから」という顔をした瞬間、次から誰も背伸びをしなくなります。

よくあるつまずきと、その対処

最後に、権限委譲で典型的につまずくポイントを3つ挙げます。どれも私自身が一度は通った道で、現場でもよく見かけるものです。

1つ目は「任せたつもりが、作業指示になっている」ケースです。手順まで細かく指定すると、それは委譲ではなく作業依頼です。手順は本人に考えてもらい、完成の定義だけを揃えます。

2つ目は「最初の失敗で委譲をやめてしまう」ケースです。1回の失敗で「やっぱり自分でやる」に戻ると、メンバーは挑戦の機会を失います。失敗したら、設計のどこが甘かったかを一緒に振り返り、範囲を少し狭めて再挑戦してもらいます。委譲は1回の試験ではなく、徐々に範囲を広げていく継続的な調整です。

3つ目は「全員に同じ任せ方をする」ケースです。経験の浅いメンバーには確認頻度を上げ、ベテランには境界線を広く取る。任せ方は固定の型ではなく、相手の状況に合わせて調整するものです。

この記事のポイント

  • 権限委譲の失敗は能力ではなく設計の問題。「動かない」の多くは「どこまで決めていいか分からない」状態。
  • 委譲に向くのは、失敗のリカバリーが効き、本人に2割の背伸びがある仕事。
  • 渡す前に「完成の定義」「決めていい範囲」「確認のタイミング」の3点を言語化する。
  • 任せた後は介入を我慢し、成果は本人のものとして扱う。失敗したら設計を見直して再挑戦。

最終的な判断はご自身の状況に合わせてお願いいたします。

まとめ:任せる技術は、設計の技術

権限委譲は「思い切り」や「メンバーとの相性」の話にされがちですが、実際には設計の積み重ねです。完成の定義、決めていい範囲、確認のタイミング。この3点を渡す前に整えるだけで、任せた仕事の止まり方が目に見えて変わります。

  • 「任せる」はプロセスの決定権を渡し、結果への責任は共有すること
  • 委譲に向くのは、リカバリーが効き、本人に2割の背伸びがある仕事
  • 確認のタイミングを先に約束し、それ以外の場面では介入しない
  • 比較すべきは「今日の速度」ではなく「チームの総生産量」

任せ方に正解の型はなく、相手と仕事によって調整し続けるものです。うまくいかなかったときに「やっぱり無理だ」と戻るのではなく、設計のどこを直すかに目を向ける。その繰り返しが、メンバーの成長と自分の時間の両方を生みます。

次に任せる仕事が出てきたら、渡す前に3点セットを5分で書くところから始めてみます。

※本記事は2026年6月時点の情報に基づきます。制度・サービスは変更されることがあります。

監修: Shimaken