開発リーダーになってから、なぜか毎日ぐったりしている。手を動かす量は減ったはずなのに、前より疲れている。おかしいな、と思いながら今日も終電近くにコードを書いている。
そんな方に読んでほしい記事です。
コード書くのは得意だったはずなのに、リーダーになってから全然進まないんだ。僕、向いてないのかなあ……。
向いていないんじゃなくて、仕事の種類が変わったんだよ。私も同じところでつまずいたから、その話をしようか。
開発リーダーのしんどさは、よくある「リーダー疲れ」とは別物です
リーダーがしんどいという話は世の中にあふれています。人間関係、板挟み、責任の重さ。どれも本当です。
ただ、開発リーダーのしんどさには、それとは別の成分が混ざっています。コードも見て、人も見なければいけないということです。
営業のリーダーなら、部下の商談に同席しても自分が喋る必要はありません。ところが開発リーダーは違います。設計がこれでいいのか判断して、レビューで指摘して、障害が起きれば原因を追う。技術の当事者であり続けたまま、人の面倒も見ることになります。
しかも、開発リーダーになる人はたいてい、プレイヤーとして評価された人です。書けるから任された。その「書ける」が、そのまま重荷になります。
しんどさの正体1：自分の作業が、定時後に押し出される
私がリーダーになって最初に狂ったのが、時間の使い方でした。
それまでは、自分の作業だけを見ていればよかった。朝来て、その日やることを決めて、順番に片付ける。それで回っていました。
リーダーになった途端、それが成り立たなくなりました。部下から質問が来る。仕様の確認が来る。判断を求められる。ひとつひとつは5分で終わる話です。でも、そのたびに自分の作業は止まります。
気づけば、自分の作業を始められるのは定時を過ぎてからになっていました。昼間は人の相手、夜に自分の仕事。そりゃ疲れます。
それ、まさに今の僕だ……。質問されるのが嫌なわけじゃないんだけど、自分の分が終わらなくて。
ここで多くの人が、自分を責めます。段取りが悪いんだ、要領が悪いんだ、と。
違います。質問に答えるのも、立派なあなたの仕事になっただけです。それを「自分の作業の邪魔」と数えているうちは、永遠に足りません。邪魔が入っているのではなく、仕事が2種類に増えたのです。
しんどさの正体2：正解を持っているから、口を出しすぎる
もうひとつ、私がやってしまった失敗があります。
技術が分かるぶん、自分の中に「こうするのが正解」という答えがありました。だからレビューでも助言でも、その正解に相手を誘導するような言い方をしていました。
表向きは質問の形をとっています。「ここ、こうしたほうがよくない？」と。でも中身は答えの押しつけです。相手に選ぶ余地はありません。
今から考えると、相手が考えたやり方を尊重する余裕がなかったのだと思います。自分の正解のほうが早い。手戻りも少ない。だからそっちに寄せる。その判断自体は間違っていないこともあります。
ただ、それを続けるとどうなるか。部下は考えるのをやめます。どうせ最後はリーダーの案になるのだから、先に聞いたほうが早い、と。
そして質問がさらに増えます。正体1の「手が止まる」が悪化します。この2つは、別々の問題ではなくつながっていました。
自分で自分の首を絞めていたわけだね。口を出すほど、質問が増える。
抜け出せたきっかけは「自分がなんとかする」をやめたこと
では何が変わったのか。技術でも段取りでもありませんでした。考え方を2つ捨てたことです。
ひとつめは「リーダーだから自分がなんとかする」。
ふたつめは「部下は守るもの」。
どちらも、悪い考えには見えません。むしろ責任感のある、いいリーダーの言葉に聞こえます。私もそう思っていました。
でもこの2つには、共通する前提が隠れています。自分のほうが上で、部下は助けられる側だという前提です。そう思っている限り、仕事は全部こちらに集まってきます。集まるように、自分で設計してしまっている。
やめたあとに残ったのは、もっと単純な問いでした。
リーダーとしてどうすべきか、ではなく、チームとしてどうしたらいいか。
この問いに変えると、選べる手が増えます。自分が抱えなくていい。部下に頼ってもいい。分からないことは分からないと言っていい。
要するに、見栄を張るのをやめたということです。リーダーは全部分かっていなければならない、という見栄。あれがいちばん重かった。
でも、頼ったら「このリーダー頼りないな」って思われないかなあ。
逆だったよ。頼られた人のほうが、自分の仕事だと思ってくれるようになった。
明日からできる3つのこと
考え方の話だけだと動きにくいので、実際にやったことを3つ挙げます。
1. 自分の作業時間を、先に予定として置く
質問対応は減りません。減らそうとすると別の問題が起きます。だから自分の作業のほうを先に確保します。午前のこの1時間は自分の作業、と決めて予定に入れてしまう。
大事なのは、その時間に質問されたらどうするかを先に決めておくことです。私は「10時半までに戻る」と伝えていました。待たされる側は、待ち時間が分かれば待てます。
2. レビューで、まず相手の意図を聞く
指摘したくなったときに、一拍おいて「ここ、どう考えてこうした？」と聞くようにしました。
これ、自分の正解を引っ込めるためではありません。相手に理由があるかどうかを確かめるためです。理由があるなら、多少非効率でもそのまま進めてもらったほうがいい。理由がないなら、そこで初めて自分の案を出す。
順番を変えただけですが、相手の顔つきが変わります。
3. 分からないことは、その場で分からないと言う
知ったかぶりをすると、あとで自分が調べる羽目になります。しかも間違っていたら手戻りです。
「それ分からないから、一緒に見てくれる？」と言えるようになってから、驚くほど楽になりました。頼ることは、仕事を押しつけることではありません。一緒に考える人を増やすことです。
まとめ：しんどいのは、あなたの能力の問題ではありません
開発リーダーがしんどいのは、コードも人も両方見なければいけないからです。そして、書けるからこそ口を出しすぎて、自分で仕事を増やしてしまうからです。
能力が足りないのではありません。プレイヤーとして優秀だった人ほど、この道を通ります。私も通りました。
抜け道は、もっと頑張ることではありませんでした。「リーダーだから自分が」をやめて、「チームとしてどうするか」に問いを変えること。それだけで、抱えていたものの半分は下ろせます。
今日、定時後に自分の作業を始めようとしているなら。明日の午前に1時間だけ、自分の時間を置いてみてください。そこからで大丈夫です。
よくある疑問
Q. 自分の作業時間を確保したいのですが、質問を断ると感じが悪くなりませんか？
断るのではなく、待ち時間を伝えてください。「10時半までに戻る」と具体的な時刻を言えば、相手は安心して待てます。感じが悪くなるのは断られたときではなく、いつ返ってくるか分からないときです。
Q. 部下のやり方が明らかに非効率なときも、口を出さないほうがいいですか？
口は出していいです。順番を変えるだけです。まず「どう考えてこうした？」と理由を聞き、理由がなければ自分の案を出す。納期や品質に実害が出る場合は、迷わず言ってください。尊重と放置は別物です。
Q. 部下に頼ると、頼りないリーダーだと思われませんか？
私の経験では逆でした。頼られた人ほど「自分の仕事だ」と思ってくれるようになります。頼りないと思われるのは、頼ったときではなく、抱え込んで納期直前に破綻したときです。
コメント