Engineering Meetup という面白そうな会があったので参加してきました。発表の中であった、「マネジメントは手段。チームの成果の最大化が目的」という treby さんのフレーズが自分の中で響いたのでその話をします。
engineering-manager-meetup.connpass.com
エンジニアのキャリアパスとマネジメント
自分がチームビルディングやエンジニアリングマネジメントに興味を持ったのはここ半年〜１年のことでした。きっかけは、自分のリードしているプロジェクトの成果をいかに最大化するかという課題でした。 自分は人間の機微に気を配ったり、人と話したりするのが得意なタイプではありません。それゆえに、若いときからマネジャーを見据えたキャリアパスというのはあまりイメージに持っていませんでした。
成果の最大化
一貫しているのは、子供の頃からいち早くプログラミングを続けてきた事による技術力に強みを置く働き方です。テックリードとして若手を引っ張りプロダクト開発を推進する。一定の成果は上げられたものの、成果の最大化にはスタンドプレイヤーとしての振る舞いに頼っていたように思います。つまり、ゴールにミートしない場合、「自分が頑張ればなんとかなる」と自分でカバーする仕事の範囲を増やしたり残業を増やしたりしてなんとかしてしまうというものです。
この働き方は、技術者として楽しくはありました。より高い成果を短時間で上げることができましたし、プロダクト開発のスピードも上がりました。多少業務がきつかろうと、自身にとってはどうでも良いことでした。なぜなら、自身で課した高いゴールを達成するのが楽しかったからです。チームメンバーに恵まれた幸運もありました。メンバーの殆どが、触発されて一緒に走ってくれる若手だったためです。もし、よりワークライフバランスをとって働きたい中堅がメンバーにいたとしたら、きっと噛み合わなかったことだろうと思っています。
この働き方に限界を感じたのは、プロダクト開発が軌道に乗りさらなる成果を求められたときでした。自分自身限界まで働いていましたし、チームのメンバーにこれ以上の負担を求めるわけにも行きませんでした。一方でこのペースで開発を進めていたのではいつまでたっても使えるモノに仕上がらない。そうした中で、自然と「スケールするチームを作るしかない」という発想に至りました。いままで手を動かしてもらっていた若手たちにステップアップしてもらって、さらなる若手を採用してリードしてもらう。そうすることで全体のスピードを上げ、チーム全体の負荷を下げるしかない。
つまり、自分の中で一貫したキャリア観というよりも、成果を最大化するための手段としてチームビルディングやエンジニアリングマネジメントのいろはを学ぶようになりました。 勉強し始めてみると意外と面白いもので、科学的管理法から始まり、具体的なソフトウェア開発手法まで、科学的に体系化された様々な基礎理論が存在します。「成果を最大化するための科学」がそこにあったのです。
エンジニアリングとマネジメントの共通点
蓋を開けてみるとエンジニアリングもマネジメントも、そこには科学的に体系化された基礎理論があり、そうした基礎理論をベースに問題の解決 (=自分の場合プロダクト開発成果を最大化すること) を図ります。いままで、水と油のように錯覚していた 2 つの要素が実は「とても良く似ている」と思うようになりました。
こうした科学的な側面と問題解決 (≒自分にとっては成果の最大化) という側面に光を当ててみると、自分がいままで割けようとしてきた領域が、実は興味深くやりがいのある仕事なのではないだろうかと思うのです。
