「自分でやったほうが早い病」というのを、聞いたことがある方もいると思います。その時点では自分でやった方が早くても、自分にしか出来ないことでなければ人に任せた方がいいし、また自分にしか出来なくても属人化を防ぐために、他の人にレクチャーすることの意義はあるわけです。
ただ、ここからは私の意見なのですが、人に任せる判断は慎重に行わないと、本当に時間の浪費になってしまうことがあるということです。私自身の経験だと、人に任せてみたものの結果が出なかったりレクチャーした内容もちゃんと吸収してもらえなかった、ということが何度もありました。これは私自身のマネジメントの力が足りなかったという点と、受け取る側のキャパや特性が仕事と合っていなかった、という2点が要因としてあるかなと考えられます。
人に任せる以上は、その人がどのような性格・志向・スキルを持っているか、というのを勘案して判断する必要がある、ということが今の時点での私の結論です。システム開発や保守の現場だと、よく知らない相手に仕事をふらなければいけないことが多々ありますが、これは上手くいくかが分からないので、ある種のギャンブルになると感じます。ギャンブルである以上は相手に過度に期待せず、もしダメだったら自分でやるくらいの心持ちが大事になってきます。ここで相手に期待して、相手を変えようとするのは徒労に終わることが多いからです。
【人に期待しないことで豊かな人生になる方法】
https://www.syacyokike.net/entry/2017/02/13/102131
もし、仕事をふる部下が成果を出せそうにないと感じた場合は、大事な仕事は全て自分でやるべきと感じます。その部下がダメな人というわけではなく、適性や好み・職場の環境によってその人のパフォーマンスが変わるので、それは組織の配置ミスであると頭を切り替えるべきと私は思います。ことさらに部下を成長させようと取り組んだ結果、自分も部下もストレスが溜まって仕事が進まないという状況が一番避けなければいけないと考えます。
【【ビジネスの極意】「ダメな部下」を使わないといけない課長の苦悩】
https://serai.jp/living/378293
なので、「自分でやるべきかどうか」というのはその時々で判断するべきであり、何も考えずに人に全て任せるのが良いとは私は思いません。
システム開発に視点を移すと、ウォーターフォールの手法がありますが、これは各工程毎にしっかり成果物を残すことで、何かあった時に次工程の担当を変えやすいというメリットもあるわけです。実装工程を担当した人がダメダメでも、詳細設計まできっちり出来ているとすると実装工程の担当を変えれば、新しい人が設計書を見て作業が進められるわけです（理論上は）。逆にアジャイル開発はそうはいきません。各自が自分で考えて開発を進めるのが求められるので、一人ダメダメな人がいたらその人の担当している機能の開発が進まなくなってしまいます。その人をフォローするために他の人の工数を割くとなると、アジャイルどころではなくなる状況に陥ってしまうリスクもあるわけです。その為、アジャイル開発を進めるときはメンバーの選定により気を使う必要があると、私は思います。
