はじめに
メーカーでコーポレート部門でソフトウェアエンジニアをやっているモンゴルです。
最近、自分のキャリアであったり、自分の周囲の体制について考えることがあり、なにか参考にしたいと思い、次の本を読みました。
感想
特に印象に残った2つのことを示したいと思います。
職位と職責を分けるべきということ
筆者が「テックリードは職位ではなく、職責として扱われている、言い換えると、テックリードだから偉いとかはなく、シニアレベルのスキルを持ちつつピープルマネジメントできる人が担当し、定期的に交代している」という旨の記述があったのが興味深かったです。
過去、「このポジションが空いているから、能力に不安があるが担当する」「能力はあるけど、ポジションが空いていないから上に上がれない」みたいな事象を見ていて"もやっ"たことがあったので、こういう考え方は非常にいいな～と思い、自分がチームを作るときも取り入れたいなと思いました。
本書で書かれている、テックリードが担っている役割も PM + スクラムマスター + エンジニアリングマネージャー のようなものであり、たしかに人間力と開発力がある開発者であれば務まるし、そうなると、PMやスクラムマスター、エンジニアリングマネージャーというロールは不要で、テックリードがいるだけでいいのではないかなー？と、思いました。 また、テックリードというのも名前はどうでも良くて、マネージャーやステークホルダーが望む形に合わせてチームメンバーが分担してその役割を担っていくという形もありなのではないか？と、思いました。
最近は「テックリードを目指すのか？」「エンジニアリングマネージャーを目指すのか？」ということで悩んでいたのですが、どちらも求められる要素は同じ（各要素のレベルは違うかもだが）なので、現段階では道は絞らず、愚直に技術力を高め、仕事を通してピープルマネジメントも成長させていく、そうやってエンジニア、社会人としての価値を高めていくのが結果的に自分がやりたいことを実現するための近道になりそうとも思うようになりました。
また、先日、 RSGT2022で牛尾さんの話 のなかでは、"優秀なマネージャーとエンジニアだけがいる"というシンプルな構造になっていそうだったので、そこの話を受けても、「エンジニアとしての腕を磨き、ピープルマネジメント力もつけていき、マネージャーを目指す」というのが今の自分の理想だなーと思うようになりました。
1on1の進め方
スクラムマスターとして1on1をすることがよくあるのですが、自分の勘を頼りに、相手や目的に合わせて方式を変えていました。
本書では以下の型が紹介されており、あまり固定せず、もうちょっといろいろ試してみてもいいかもと思いました。
- TODOリスト型
- キャッチアップ型
- フィードバック型
- 経過報告型
ただ、どういう方法をやるにしても「相手を理解する」という気持ちは忘れずに取り組みたいと思いました。
終わりに
マネージャーとしても、マネジメントされる人としても、転職しようとする人としても、体制を作っていく人も、色んな立場の人の役に立ちそうな情報満載でした。
ただ、まえがきでも書かれていますが、アメリカでの話がメインになっているので、現在の日本と思想が異なるところもほんの一部ありますが、そういった章もむしろ考え方は参考になると感じました。
また、以下のようなことも思いました。
「エンジニアのためのマネジメントキャリアパス」を読んでて、技術系のマネージャーは以下の要素が備わっていてほしいなと思った（CTOなのかVPoEなのかで、求められるレベルは異なりそう）
— モンゴル (@mongolyy) 2022年1月24日
・開発力
・IT業界の最新動向把握
・発信力
・プロセス改善力
・ビジネス側との協調性
また、時が経ったら立場も変わると思うので、そのときに読み返してみようと思います。
