人に任せると申し訳ない。結局、自分で全部やってしまう
「お願いしてもいいですか」が、どうしても言えない
火曜の16時半、リリース前の確認で小さな不具合が見つかった。
エラーログを追う。設定差分を見る。修正後の確認項目を作る。顧客への報告文も用意する。ひとつずつなら重くない。でも、夕方の予定へ重ねると、全部を今日中に終えるのは少し苦しい。
隣のメンバーが画面を見て言う。
「ログの切り分け、私がやりましょうか？」
助かるはずなのに、すぐには「お願いします」が出てこない。
背景を説明するだけで時間を取らせそうだ。途中で分からなくなったら、相手を困らせるかもしれない。そもそも、自分に来た仕事を渡すのは無責任に見えないだろうか。頼む側として偉そうになるのも嫌だ。
いくつもの気まずさが一度に動いて、口から出るのは別の言葉になる。
「大丈夫です。自分で見ます」
相手は「分かりました」と席へ戻る。会話はきれいに終わる。でも、自分のタスクリストだけが重くなる。
こういう抱え込みは、相手を信用していないからとは限らない。むしろ、相手へ負担をかけたくない、頼まれた仕事は自分で完了させたい、困っている人を増やしたくないという気持ちから起きる。
だから厄介だ。やさしさや責任感から始まっているぶん、手放す方が悪いことに見えてしまう😓
ただ、人に任せることは、自分の責任を相手へ押しつけることではない。目的と範囲を共有し、戻ってこられる場所を残したまま、一部を一緒に持ってもらうこと だ。
この記事では、申し訳なさを無理に消すのではなく、その気持ちがあっても小さく任せられるところまで整理していく。
抱え込むほど、誰にも頼めなくなっていく
最初は「今回だけ自分でやればいい」と思う。説明に20分かけるなら、その間にログを見た方が早い。自分なら背景も分かっているし、品質も読みやすい。
その判断が間違いとは限らない。本当に急いでいる時や、引き渡す方が危ない作業もある。問題は、毎回同じ判断になっている時だ。
その日の速さと、チームの速さは違う
17時を過ぎ、ログを追いながら報告文も書く。別の質問が届いても、手を止めたくなくて返信を後回しにする。焦るほど説明が雑になり、確認も増える。
さっき助けを申し出てくれたメンバーは、こちらが何を調べているのか分からない。声をかけ直すにも、もう作業が進みすぎている。自分で抱えたことで、その人が入れる場所まで消えていく。
「自分でやった方が早い」は、その30分だけ見れば正しいことがある。でも、同じ種類の調査が来月も自分に集まるなら、チーム全体では速くなっていない。自分が空くまで仕事が待つ状態を作っているだけだ。
Scrum Guide は、チームが誰に何を、いつ、どう任せるかを内部で決める「自己管理」を重視している。スクラムを使っていなくても、仕事の持ち方を一人の頭の中だけで決め続けないという考え方は使える。
頼むために説明すると、自分の曖昧さまで見えてしまう
もう一つ、頼みづらさの奥にあるのが、説明する怖さだ。
自分だけで作業している時は、「まずログを見て、たぶん設定差分を調べればいい」と曖昧なまま始められる。ところが誰かへ頼むには、目的や確認範囲を言葉にしないといけない。そこで、実は自分も調査の終わりを決めていなかったことに気づく。
その瞬間、「こんな状態で頼むのは申し訳ない」「整理してから渡さないと」と感じ、また全部を自分へ戻したくなる。
でも、最初から完璧な手順を渡せないことと、頼んではいけないことは同じではない。「原因はまだ分からない。まずアプリ側か設定側かの当たりをつけたい」と、分かっている範囲と分かっていない範囲を一緒に渡せばいい。
頼むために言葉にしたことで、自分の調査も整理される。委任は、完成した作業指示を配るだけではなく、何を一緒に明らかにしたいかを共有すること から始められる。
申し訳なさは、仕事量を示す数字ではない
人へ頼もうとした時に胸が重くなるのは、相手を雑に扱いたくないからだ。その気持ちはなくさなくていい。
ただ、「申し訳ないと感じる」と「相手に余裕がない」は別の事実だ。こちらが気まずくても、相手には時間と関心があるかもしれない。逆に、笑顔で引き受けてくれても、本当は余裕がないこともある。
Google re:Work のチーム研究では、効果的なチームの要素として、失敗や質問を罰されない感覚だけでなく、頼んだ仕事をやり切れる信頼や、役割と期待の明確さも挙げられている。安心だけでも、明確さだけでも足りない。
だから、心の中だけで相手の負担を決めない。申し訳なさは自分の気持ちとして受け止め、仕事量は相手に確認する。 ここを分けると、少し呼吸が戻る。
申し訳なさがあっても、小さく任せられる
いきなり大きな機能を丸ごと渡す必要はない。最初に任せるのは、戻しやすく、終わりが見え、途中で相談できる仕事がいい。
火曜16時半の場面なら、「障害対応をお願いします」では大きすぎる。代わりに、ログの一次切り分けだけを頼む。
伝えるのは4つで十分だ。
- 何のために見るのか
- どこまで見れば一区切りか
- いつ、どの状態で一度話すか
- 今の予定で難しくないか
たとえば、こう言える。
さっき申し出てもらったログ確認、お願いしてもいいですか。15時以降のエラーを見て、アプリ側か設定側かの当たりをつけたいです。まず45分見てもらって、分からない点があれば17時半に一度一緒に確認したいです。今の予定で難しければ、遠慮なく言ってください。
ここには、命令も丸投げもない。目的があり、終わりがあり、戻る時間があり、断る余地もある。
相手が「できます」と答えたら、そこで初めて任せる。自分の申し訳なさだけで、相手の選択肢を先回りして消さない🤝
任せる仕事は「失敗しても戻れる」ものから選ぶ
初回から、顧客への最終回答や本番操作の判断を渡す必要はない。まずは調査、情報整理、確認項目の初稿など、途中結果を一緒に見られる仕事から始める。
選び方は難しくない。
- 期待する結果を3行で説明できる
- 30〜60分後に途中経過を見られる
- 違っていても戻してやり直せる
この3つが揃う仕事なら、頼む側も受ける側も怖さが小さい。任せる練習を、いきなり信頼の大勝負にしなくていい。
断られても、頼んだことが失敗になるわけではない
相手の予定を聞いた結果、「今日は難しいです」と返ってくることもある。その時、頼んだこと自体が迷惑だったように感じて、顔が熱くなるかもしれない。
でも、断れる余地を残して聞いたなら、その返事は失敗ではない。チームの仕事量が一つ見えたということだ。別の人へ聞く、範囲をさらに小さくする、今日は自分で持って次回のために手順を残す。次の選択ができる。
無理に引き受けてもらうことと、相手に選んでもらうことは違う。断られない頼み方を探すより、断られても関係が崩れない頼み方を持っておく方が、長く一緒に働きやすい。
任せたあとに残ることも、責任の一部になる
仕事を渡したあと、別の不安が出てくる。
説明が足りなかったかもしれない。自分で見た方が確実かもしれない。やっぱり戻してもらおうかな。
ここで作業を取り返すと、相手は「任されたと思ったのに、結局信用されていなかった」と感じやすい。一方で、何も見ずに結果だけ求めれば、本当に丸投げになる。
GitLab Handbook は、委任について、相手と問題や進め方の共通理解を持つ必要があり、任せた後に支えないことは放置だと整理している。さらに、目的や期限、期待する結果を伝え、必要な情報を渡し、途中で支援する流れを示している。
つまり、任せる側に残る仕事はある。
- 必要な背景や情報へアクセスできるようにする
- 質問を返してよい場所を決める
- 約束した時刻に途中経過を見る
- 自分と違う手順でも、目的を満たしていれば奪い返さない
遅さを見た瞬間に、仕事を取り返さない
17時半、メンバーの調査メモはまだ途中だった。自分なら15分で見られた場所に、30分かかっている。
ここで焦りが戻る。「やっぱり自分でやる」と言えば、その場は速い。でも、その一言で次回も自分に戻ってくる。
代わりに、「いま何が分からない？」と聞く。すると、ログの時刻と設定変更の時刻が合わず、どこを基準にすべきか迷っていたと分かる。基準だけ共有すると、メンバーは設定差分を見つけた。
その間に、自分は報告文と確認項目を終えられた。18時過ぎ、二人の結果を合わせて対応方針が決まる。
全部自分でやるより、最初の説明には時間がかかった。それでも、自分だけで夜まで抱える形にはならなかった。メンバーにも、次に同じログを見る時の手がかりが残った。
気持ちが一気に晴れるわけではない。「頼んでよかった」と思う横で、「負担をかけたかな」はまだ少し残る。それでいい。相手が選び、途中で戻れ、仕事も前へ進んだ。その事実まで見れば、申し訳なさだけで判断しなくて済む。
IPAが2026年4月に公開したデジタルスキル標準ver.2.0も、デジタルの仕事を複数の役割とスキルに分け、関係者の連携や共創を促す力を扱っている。役割が広がることは、自分が処理できる作業を増やすことだけではない。誰が力を出せるかを見て、仕事が一人に閉じない状態を作ることも含まれる。
明日は、ひとつだけ一緒に持ってもらう
人に任せられない自分を、能力不足だと責めなくていい。頼むことに気まずさがあるのは、仕事や相手を雑に扱いたくないからでもある。
ただ、その気持ちのまま全部を抱えると、自分が苦しくなり、周りも仕事へ入れなくなる。やさしさの行き先を、自分の残業だけにしなくていい。
明日やることは、大きな委任計画を作ることではない。自分のタスクリストから、戻しやすい仕事をひとつ選ぶ。目的、一区切り、戻る時間、相手の予定を3〜4行で伝える。それだけでいい。
役割を広げることは、何でも自分でできるようになることではない。自分が持つ責任を見失わず、周りが力を出せる場所を作ること も、仕事を前へ進める力だ。
関連する話は、実装だけの人が、PM要素を少しずつ増やすには と ファシリテーションはPMだけの仕事じゃない にも書いた。
頼む言葉がうまく出ない時は、誰に何を丸ごと渡すかではなく、どこなら一緒に持てるかから考えよう。今の仕事を抱え込みではなく役割の広がりへ変える方法を、一緒に整理していこう🌱
