valid,invalid

関心を持てる事柄について

エンジニアリングマネジャーになってから技術力が伸びるパターン

もう半年以上前だが、このツイートにそこそこFavが付いたのでもう少し丁寧に考えや経験を補足しようと思った。

僕が観測する界隈ではエンジニアがマネジャーになることに対するネガティブな印象として「コードを書けなくなる」「技術力が落ちる」といった意見を聞くことが多いので、いち反例として個人的な経験を挙げてみる。*1

どういうことか

僕がエンジニアリングマネジャーになったのは2017年で、今から約2年前。*2

過去に記事で書いたようにその頃は 「日常の業務を漫然と続けるだけで成長するフェーズは終わった」という焦燥感があった一方、目線の上げ方・課題の見つけ方・実行するための冴えたやり方といったものを知らなかった。

だが、エンジニアリングマネジャーとしての仕事をこなしたり、その立場で何をすべきかを考えたり、自分がどうなりたいかを見直すことで技術力の向上につながることが多々あった。この記事ではそうした個人的な経験について書く。

なぜ伸びたか

理由を大別すると、立場・役割・周囲が自分に与えた影響と、自分から自分へかける圧力の増加の2つがあると思う。

立場・役割・周囲の影響

僕がQuipperでエンジニアリングマネジャーになった当時、メンバー (subordinates) はみな独力で自走できるレベルの高い同僚ばかりだった。相対的に社歴が長い自分が成り行きでマネジャーになったものの、そんなメンバーたちに対して成長支援や伴走が必要とは全く思えなかった。

そういった状況下でも目標設定や評価などはマネジャーの役割として存在した。そのため 「技術的な課題やその達成に向けたアクションなどについてメンバーと話ができる」は要求される最低ラインであり、そこに届いていない領域については引き上げる必要があると考えた。

自分がメンバーに追いついていない領域すべてをカバーすることが必要だとは考えなかったが、自分が全く意識していなかった課題をメンバーが挙げることもままあり、定期的に自分の不足を知ることになった。これは学習意欲の向上に直結した。

すごいエンジニアとは雑談するだけで学びがある

そう、「すごいエンジニアとは雑談するだけで学びがある」ということも自分は1-on-1から大いに学んだ。

視野・視座・視点のみならず問題の解法の見つけ方や思考プロセス、計画の立て方や実行力などなど経験と知識に裏打ちされた技能を間近に見たり聞いたりする機会に恵まれたのは定期的な1-on-1や、評価のためにメンバーを単なる同僚のとき以上に観察したおかげといえる。1-on-1は決して上司・部下の関係だけで行われるものではないが、必然的に交流や雑談の機会に恵まれるのは事実だ。

こうした仕事中の雑談や交流が1-on-1に閉じるのはもったいないと感じるようになり、それらが自然発生するような文化や振る舞いやスキルや思考様式について考えるようになり、書いた記事が Working Out Loud 大声作業(しなさい)、チームメンバー同士でのトレーニング文化の醸成 - Quipper Product Team Blog である。このようなことはエンジニアリングマネジャーになるまでは考えていなかったことだった。

採用活動やメンターの機会を活かす

これはエンジニアリングマネジャーに限定されることではないが新入社員のメンターを引き受けたり、採用活動に関わるようになると技術について説明したり聞かれることが増える。

自社で利用している技術を知るだけでは十分ではなく、なぜ利用しているのか、近年流行している代替技術を利用していないのはなぜか、課題はあるか、あるとすればどのように対処するのか(技術戦略)、等々の数段深掘りした質問に答えられる程度の理解が求められる。このプレッシャーもスキルアップのためのインプットには有用となる。

自分が自分にかける圧を増やした

これまでに述べたのは自身の置かれた状況や役割から逆算して必要な水準が引き上げられたという話だった。一方、自分で自分に課すハードルを上げることで実践に至る取り組みもしばしばあった。

元来マネジャー志向ではなかったが、"if もしも"マネジャーになるならどうありたいだろうか?というのは自問した。その中には「技術的に信頼がおける」「登壇とかバリバリしててイケてる」というものもあった。*3

「技術力のあるマネジャーになってほしい」と誰に頼まれたわけでもないから、これはエゴである。どういったマネジャーであるべきかは独りよがりではなく周囲のメンバーとの対話を通じて期待値を合わせるのが肝要だ。とはいえ、他人からの期待だけで動いててもすぐにつまらなくなる

自分にとっての理想のマネジャー像とエンジニア像が極力重なるような道を歩みたくなり、結果として自分に対して「技術力を伸ばせ」という圧をかけることになった。

具体的にどんな動き方をしたか

業務内において気を付けたこと

マネジャーとしての業務と開発を兼任する場合は自分がボトルネックにならないようにする必要がある。結果として締切がない、または相対的に締切がゆるいタスクにシフトしていくことがあった。

その中にはライブラリやフレームワークのアップデート、技術的負債の解消、不要機能の削除、CI/CD周りの改善など、重要度は高いが緊急度が低く取り組めなかった*4タスクも含まれる。これらに取り組むことで技術力の幅が広がった。

巻き込み力、運用力

また、独力でこうしたタスクに取り組む場合でも成果物を周囲にレビューしてもらったり引き継いでもらう必要があるので、達成のためにいかに周囲を巻き込んでいくかや、自分の開発したものを運用で回るところまでもっていくスキルも以前より身に付いたと感じる。

これも広義には技術力の一部だと考えている。

仕事を選ぶ

タスクがシフトしていくと述べたが、実際には自然にそう流れていっただけではなく自分で仕事を選ぶ機会が増えたというのもある。

チームメンバーが優秀で、油断しているとマネジャー抜きでも勝手に仕事が進んでいく。自分の出る幕がなくなるからこそ取り組む価値の高い仕事を自分で考えなければいけない。これは望ましい環境であるが同時にハードモードでもある。

業務外でのアウトプット

業務外ではアウトプットを意識した行動を増やした。これは以下の記事に書いたとおりだ。

ohbarye.hatenablog.jp

アウトプットを意識して仕事を選んだり、仕事のやり方を考えることにもなった。

いずれもマネジャーにならなければできなかったことではないが、自分の背中を押す理由として立場・役割を利用できたのは良かった。

マネジャーでなければできなかったか

今になって思えば、上述のような取り組み・仕事の進め方・スキルの伸ばし方をするうえでエンジニアリングマネジャーである必要は何もない。いちチームプレイヤーであっても勝手にやっていけばよいだけだ。

…とは言うものの、仕事の移譲のしやすさや動きやすさやタスクの調整のしやすさ等々の立ち回りはマネジャーの立場のほうが有利であることが多いというのは事実だと思う。健全に透明性のある組織であっても一部の情報はマネジャーにいち早く知らされることもあり、それがチーム横断的な課題発見に役立つこともある。

僕のような凡庸ないちエンジニアからするとマネジャーの立場・役割を活用して技術力を磨く機会を作るのは生存戦略の一つだと思う。

余談ながら、マネジャーへのロールチェンジを不可逆なものとせず、マネジャーとエンジニアを行き来する振り子モデルという考え方もある。本旨からそれるため紹介するだけに留める。

charity.wtf

再現性があるか

ここまで述べたのは完全に個人的な体験なので、再現性があるかどうかは正直わからない。

同じ環境においてでさえこれまでの2年とこれからの2年は違うものだと思うのでたとえ自社でも「できる」と断言はできない…が、少なくとも上述のような振る舞いをするマネジャーがいても許されているのでこれからも機会は十分にあると思う。

会社やチームによってエンジニアリングマネジャーの職務は異なるので、他社にいたっては本当に何もわからない…!

しかしながら、適切な移譲や価値ある仕事の創出・選択をマネジャーができるようになるのは概ね目指すべきところだと思うので、自分と同じような事例や感想が出てくると嬉しい。

*1:無論、一般的に「コードを書けなくなる」「技術力が落ちる」ことになるケースが多いというのは重々承知している。

これは個人的なブレイクスルーの話、自分の技術力は今でもたかが知れているというのは承知の上で過去と現在を相対的に比較して技術力が伸びたという話なのであしからず。

*2:その頃の気持ちはnow = ohbarye.hired_at.since 2.yearsに書いた

*3:他人に求めるものではない、というのは承知の上で… 自分の理想のエンジニア像の延長線上に置いた

*4:というのは言い訳で、正確には取り組む機会を作る力がなかったというのが今になってわかる