Yahoo! JAPAN

この記事で書きたいことは、大体以下のようなことです。

・「タスクを実行する能力」は大事ですが、「タスクを適切に振る能力」もとても大事です
・「タスクを振るのが苦手」という人は、かなりのベテランでも珍しくありません
・管理職になった頃、私も「タスクを人に振る」ことが大の苦手で、しばしば自分で仕事を抱え込んだり、タスクを偏らせたりしてしまっていました
・「タスクの意味や優先順を明確に言語化出来ておらず、タスク振りに説得力がないこと」が最大の原因だったと思っています
・解決する為に、「タスクを徹底的に言語化すること」「誰にお願いするか、その理由も明確化すること」「それをチームで共有すること」などを習慣化しました
・その結果、以前よりはだいぶマシなマネジメントが出来るようになった気がします
・言語化大事ですよね。今後も精進します

以上です。よろしくお願いします。

さて、書きたいことは最初に全部書いてしまったので、後はざっくばらんにいきましょう。

マネージャー・管理職の皆さん、人に仕事振るのって得意ですか？適切なタスク振り、出来てますか？頼みやすい人にタスクが偏ったり、スケジュール調整に失敗してタスクが滞ったり、「自分でやった方が早いから」で仕事抱え込んだりしてませんか？

「タスクを適切に処理する能力」はもちろん大事なんですが、「タスクを適切に割り振る能力」も超重要、というかマネージャーの主な仕事ってタスク振りと優先度管理・スケジュール管理なんですが、案外「タスクを振る能力」について語られることって、「タスクを実行する能力」よりは稀な気がしています。なんででしょうね？

しんざきは、昔「タスクを人に振ること」が大の苦手で、何度も大失敗しました。

マネジメント職をやるようになってから20年弱経つんですが、最近ようやく多少はマシになったかなーと思えるようになったので、ここまで色んな人に聞きながら試行錯誤してきたことについて、簡単に書かせていただければと思います。よろしくお願いします。

***

昔話から始めます。

20年近く前のことですが、しんざきは中堅どころのSI企業からとあるベンチャー企業に転職して、そこで初めて管理職を経験しました。

なにせ創立数年のベンチャーだったので、当時はシステム面も殆ど整備されておらず、社内に情シス部門すらありませんでした。

出来合いのパッケージで動かしていた基幹システムを、内製でリプレースするお手伝いとして私が呼ばれました。テクニカルな話が多少なりとも分かる人は私を含めてほんの数人しかおらず、社内で動いている仕事はなにもかもが属人業務でした。

システムのリプレースを協業さんも含めて3,4人で半年かけてなんとか終わらせ、息つく暇もなく社内システムの整備にとりかかりました。

前職では下っ端だった私も、転職先では「有識者」の類いでした。というより、付け焼き刃でも誰かが有識者として動かないと、会社のシステムが回りませんでした。

やることは山ほどあるのに人は全く足らず、何度も会社に文句を言って、少しずつ採用を進めました。結果、どういうわけか、私が新設のシステム部門のマネージャーになりました。別に知見を見込まれて抜擢されたわけではなく、単に他にやる人がいなかっただけですが。

何もかも手探りでした。当時はチームビルドのノウハウも知らず、人事評価のやり方も分からず、ステークホルダーという言葉すら知りませんでした。前職の頃管理してもらっていた、その見よう見まねでタスク管理をして、スケジュールの線表を作って、評価基準も考えました。

当時は本当に「失敗の山を築きながら、時々発生する成功ケースでなんとか仕事を回す」ような状態だったのですが、そこで失敗したことの一つが「タスクの振り方」でした。

***

当時の私の失敗をいちいちあげつらっているとそれだけで記事が終わってしまうので、代表的なところをピックアップしますが、

・「自分がやった方が早いから」と色んなタスクを部下に振らずに抱え込んでしまい、本来マネジメント層がやるべき仕事を滞らせてしまった
・タスクの意味や必要とされる成果物の粒度をきちんと説明出来ず、仕事に納得感がない状態を招いていた
・頼みやすくタスク処理が速い人にばかりタスクを集中させてしまい、業務量の不公平感を招いてしまった
・いざタスクを振っても、「任せる」ということがなかなか出来ず、いちいち細かいところまで指示しようとしてしまった
・タスクが遅れた時のリカバリの引き出しがなく、「自分で引き取る」か「出来そうな人に引き取ってもらう」くらいしか解決しようがなかった

逆に何が出来ていたんだよ、という話ですよね。今から振り返ると、本当に何も出来ていなかったと思います。

まず、最大の問題として、「本来部下に任せるべき仕事を抱え込んでしまっていた」という点があります。

例えば細かい実装の作業とか、日々の運用におけるトラブル対応とか、「それちゃんとやり方を説明すればお前じゃなくても出来るよね」というタスクを、「引き継ぐ余裕がないし、タスクを止めるわけにもいかないから」という言い訳でいつまでも自分で抱えてしまっていたのです。

人間が処理出来るタスク量には限界がありますから、何かの仕事を抱えていれば、当然それ以外が疎かになります。本来ならマネージャーの一番の仕事は「部下の仕事が上手く回るような建て付けを考えること」なのに、抱えた仕事の忙しさを言い訳にして、そっちの時間を全くとれていなかったわけです。

もちろん程度問題ではあるのですが、私について言えば、これは間違いなく「マネージャー(私)の怠慢」でした。

タスクを引き継ぐこと、タスクの意味を説明してドキュメントを整備してやり方を教えて、相手に権限を委譲することは、もちろん大変ですし時間コストもかかります。当初は却って仕事が増えることにもなるでしょう。

しかし、マネージャーが「個人」としてしか動いていなかったら、いつまでも「チーム」での仕事は出来ない。チームでのバリューを出せなければ、組織で動く意味がないわけです。結果、あふれた仕事だけを継ぎ接ぎ的に下に振っていたわけですから、論外としか言いようがありません。

「頼みやすい」「処理が速い」人ばかりにタスクを集中させてしまっていた、というのもひどい失敗だったと思います。

もちろん、「既存のタスクとのスケジュール調整が出来ている」というのは最低限の前提です。

その上で、「適材適所」というものは当然あります。部下のスキルによって、守備範囲によって、「この人にはこのタスクを振るべき」という場面は往々にして発生します。結果的に、「一部の人にタスクが偏ってしまう」ということはあるでしょう。

ただ、やらないままだといつまでも出来るようにはならない。今タスク処理が遅い人でも、スキルや知見が足りない人でも、経験を積むことによってレベルアップは出来る筈なのに、マネージャーが最初からその機会を作らないのでは話になりません。

タスクを喜んで受けてくれる人か、それとも毎回いやな顔をする人か、という点にも、正直なところ、随分影響されてしまっていたと思います。

もちろん仕事なのだから、やってもらわないといけない時には頼み込んでもお願いするのですが、喜んで受けてくれる人に偏ってしまう部分はどうしてもあった。

これには、自分自身が「ちゃんと説得力を持ったタスク振りが出来ているか」という点に自信を持てていなかった、という点も大きかったと思っています。

部下にしても、納得出来る理由や説明もなくタスクを振られていれば、そりゃ「こいつは俺に何をさせようとしているんだ」という気分にもなるでしょう。逆に、きちんとタスクの意味も価値も説明出来ているし、スケジュールの調整も出来ていれば、感情としていやな顔をされても「そこを何とか」とは言いやすくなるでしょう。

「タスクをちゃんと任せられていなかった」ということも大きな反省点です。

タスクの目的をきちんと定義した上で、「自分が責任をもつべき範囲はどこまでか」をきちんと考えられていれば、「じゃあここから先は私が責任をもつので、ここまではあなたの裁量で考えてください。もちろん相談には乗ります」と言えた筈でした。

それが出来ていなかったから、責任範囲の切り分けも出来ず、「自分はどこまで口出しをするべきか」が決められずに、細かいところまで口を出しがちになっていた。部下をきちんと信頼できていなかったわけで、タスク振りに納得感がない一因にもなっていたでしょう。

この辺、マネージャーとして最低限の仕事も出来ていなかったわけで、今から考えると汗顔の至りという他ありません。

***

じゃあこれだけ惨憺たる状態をどう解決したのか、という話なんですが。もちろん改善のための魔法の一手があったわけではなく、知見がないなりにあれこれ悩んで、色々と試行錯誤しました。

まず、タスクを徹底的に可視化・言語化する、というところから始めました。

具体的には、

・タスクを実施する理由、背景
・タスクの規模
・定常的なタスクか、非定常的なタスクか
・タスクの優先度、期限
・タスクを実施する際求められるもの、成果物、その粒度
・そのタスクを実施するとどんないいことが起きるのか
・やらないと何がまずいのか

この辺りのテンプレートを作って、見えているタスク全てについてテキスト化して、誰にでも見える形にしました。その上で、タスクを振る時はもちろん、タスクの発生時や完了時にも、毎回この内容をみんなで確認するようにしました。

自分で仕事を抱えてしまっている最大の原因は、「タスクを手放せないから」なのですが、自分や周囲を説得するためにも、「そのタスクは本当に手放せないのか？」を深掘りすることは必要でした。

なんなら、タスクが一時的に滞っても、一時的に品質が低下しても、もしかするとやめちゃっても大丈夫なんじゃないのか？これによって、タスクの取捨選択の判断も出来るし、「一時的にクオリティや速度を下げても人に任せる」という判断も出来ます。

もちろん、「タスクを振る」際にも、これらをきちんと言語化し、共有することは重要です。

タスクを実施する際にも、「その理由」まできちんと理解しているかどうかでは、仕事をする上での解像度も、成果物に対する理解度も変わります。更にその上で、「何故自分がそのタスクを実施する必要があるのか」が理解出来れば、タスクを受ける上での納得感も上がるでしょう。

だから、「何故あなたにこのタスクをお願いするのか」という点についても、さぼらずに可能な限り言語化し、セットで共有するようにしました。

あなたにはこういう経験があるから、このタスクを高い品質で実施出来ると考えている、とか。今後あなたにこういう仕事をして欲しいから、今このタスクを担当して欲しい、とか。当然、その人が既に受けているタスクとの交通整理も行いました。

これで、私の無思慮なタスク振りに嫌な顔をしていた人にも、ある程度納得感を持ってタスクを受けてもらえるようになりました。

当たり前のことですよね？出来てなかったんです、当時。

この辺、殆ど意識せずに出来ている人もいれば、今なら色んなツールも使えると思うんですが、当時は「こう解決しよう」ということ自体、一つ一つ自分で言語化しなくてはいけませんでした。

改善は亀の歩みで、今だからこそ振り返ることも出来るようになりましたが、当時は本当に山ほど試行錯誤しました。ご迷惑をおかけした皆さんには、今でも足を向けて寝られません。

***

随分長く書いてしまいました。

昔よりは多少マシになったと思うんですが、私がちゃんとマネジメントをこなせているかどうかについては、正直今でもそこまで自信はありません。常に「これ大丈夫かな？」「本当にこのやり方でいいのかな？」と不安になりながら管理職をやる日々です。

とはいえ、自分を客観視して、今のやり方をより最適化していくためにも、「昔何が出来ていなかったのか」を可視化するのは悪いことではないかもなあ、と。

昔の私のように、マネージャーになりたてで右も左も分かりません、人に仕事振る時って何すればいいの、という方がいらっしゃいましたら、少しでもお役に立てればと考え、この記事を書かせていただいた次第です。よろしくお願いします。

今日書きたいことはこれくらいです。

***

【著者プロフィール】

著者名：しんざき

SE、ケーナ奏者、キャベツ太郎ソムリエ。三児の父。

レトロゲームブログ「不倒城」を2004年に開設。以下、レトロゲーム、漫画、駄菓子、育児、ダライアス外伝などについて書き綴る日々を送る。好きな敵ボスはシャコ。

ブログ：不倒城

Photo：Mark König