「自分でやったほうが早い」の限界。仕事が自分に戻ってきた理由
「自分でやったほうが早い。」
見積書を作るとき、以前の私は何度もそう考えていました。
誰かに仕事を頼むには、案件の条件や作業内容を説明しなければなりません。出来上がったものを確認し、必要であれば修正を依頼する時間もかかります。
それなら、最初から自分で処理したほうが早い。
実際、目の前の一件だけを見れば、その判断は間違っていませんでした。
しかし、そのやり方を続けているうちに、見積書だけでなく、任せた案件の日程管理も、外部パートナーの不具合修正も、最後は私のところへ戻ってくるようになりました。
今回は、こうした経験を通して、私が「仕事を任せる」ということを考え直した話です。
1. 自分でやるほうが早かった
見積書を作る業務では、案件ごとの条件や見積項目を説明し、完成後の内容まで確認する必要があります。
そこまでの時間を考えると、自分で作ったほうが早いことがありました。
自分であれば、途中で説明する必要はありません。判断に迷って作業を止めることもなく、そのまま最後まで進められます。
その日の成果だけを見れば、とても効率的でした。
ただし、この速さには一つの条件があります。
私自身に、作業できる時間と余裕があることです。
案件が増えたり、ほかの業務と重なったりしても、判断と作業が私に集まったままでは、いつか処理できる量の限界がきます。
さらに、私が毎回自分で処理していれば、次の見積書も、その次の見積書も、私が作ることになります。
私は仕事を早く終わらせているつもりで、実際には「自分にしかできない仕事」を増やしていたのです。
もちろん、急ぎの案件では、自分で処理したほうがよい場合もあります。
問題は、それが例外ではなく、いつもの仕事の進め方になっていたことでした。
2. 任せた仕事が、自分に戻ってきた
ある工場案件で、作業を部下に任せたことがあります。
それほど大きな案件ではありませんでした。しかし、作業を任せた後のスケジュール管理がうまくいかず、予定どおりに進めることが難しくなりました。
結局、途中から私が仕事を引き取り、自分で進めることになりました。
当時は、「やはり任せるより、自分でやったほうが早い」と考えていました。
けれど、今振り返ると、私は作業を渡しただけで、仕事を進めるための判断までは渡せていなかったのだと思います。
いつまでに、どの状態まで進めるのか。
途中で何を確認するのか。
予定より遅れそうなときは、どの段階で相談するのか。
こうした条件を、相手が実際の判断に使える形で共有できていませんでした。
これでは、予定外のことが起きたとき、相手は自分で進めてよいのか、私に相談すべきなのかを判断できません。
その結果、仕事は止まり、最後は経験のある私が引き取ることになります。
仕事が戻ってきた理由を、部下の能力だけで説明することはできません。
任せる側の私が、仕事の進め方まで共有できていなかったことにも問題がありました。
3. 1日5件の不具合対応で、へとへとになった
外部パートナーと仕事をしていたとき、多い日には1日5件ほどの不具合に対応していた時期がありました。
私は自分の業務を進めながら、不具合箇所を確認し、自分で修正していました。
一件ずつ私が直せば、目の前の成果物は早く整います。
しかし、不具合が出るたびに自分の業務を止め、確認と修正を繰り返す状態が続き、私は次第にへとへとになっていきました。
疲れた原因は、単に件数が多かったからではありません。
何を不具合と判断するのか。
どの段階で相談するのか。
どこまで修正すれば完了なのか。
こうした判断と、最後の修正作業が、すべて私に集まっていたことが大きかったのだと思います。
私が直し続ければ、その日の問題は収まります。
けれど、私が修正して終わらせるだけでは、相手が不具合の原因を振り返り、次の仕事で判断を変えることにはつながりにくくなります。
そして次の案件でも、私は同じように確認し、同じように修正することになります。
見直すべきだったのは、外部パートナーを責めることではありませんでした。
提出前に何を確認するのか。迷ったときは誰に相談するのか。何をもって完了とするのか。
その条件を一緒に確認し、相手自身が判断できる状態をつくる必要がありました。
4. 正解を教える人から、判断できる状態をつくる人へ
この考え方が変わるきっかけの一つになったのが、ピーター・ドラッカーの『マネジメント』を読んだことです。
それまでの私は、管理することを「細かく指示し、正解を教え、間違いがあれば自分で直すこと」だと考えていたのかもしれません。
しかし本を読み、管理する側の役割は、自分がすべての正解を出すことではなく、人が成果を出せる状態をつくることだと、私なりに受け取りました。
それからは、仕事を任せる前に、少なくとも次の四つを共有する必要があると考えるようになりました。
いつまでに、どの状態まで進めるのか
どの段階、どの条件で相談するのか
何を基準に完了と判断するのか
問題が起きたとき、誰が判断するのか
これは、すべての作業方法を細かく指定するためのものではありません。
相手が自分で進められる範囲と、相談すべき境界を明確にするためのものです。
もちろん、これを伝えるだけで、誰もがすぐに同じ判断をできるわけではありません。
相手の経験や技量、仕事が品質に与える影響に応じて、任せる範囲や確認の回数を変える必要もあります。
それでも、この条件がないまま作業だけを渡せば、予定外のことが起きるたびに、仕事は最も経験のある人へ戻ってきます。
私が変えるべきだったのは、自分の作業速度ではありませんでした。
ほかの人が判断して進められるように、仕事を渡す方法だったのです。
5. まとめ
今でも、「自分でやったほうが早い」と思う場面はあります。
急ぎの対応では、自分で処理することが必要な場合もあります。
ただし、それが毎回続いているなら、目の前の作業ではなく、仕事の任せ方を見直す必要があります。
自分が速く正確に処理できることと、チームが自分なしでも判断して動けることは、別の能力です。
以前の私は、自分が正解を出し、問題を解決することが技術者としての役割だと考えていました。
今は、周囲が判断できる状態をつくり、仕事が一人に戻らない進め方を考えることも、自分の役割だと思っています。
正解を教える人から、判断できる状態をつくる人へ。
技術者として仕事を続ける中で、私の役割は少しずつ変わってきました。
皆さんの仕事にも、「自分でやったほうが早い」と思いながら、何度も自分に戻ってくる業務はありますか。
