ganyariya blogはじめに
概要
「エンジニアのためのマネジメントキャリアパス」を図書館で借りて 3 章まで読みました。
この記事では、こちらの本の構成ならびに自分の学び・所感についてまとめます。
記事を読んで得られること
- 「エンジニアのためのマネジメントキャリアパス」がどういう本であるのか？がわかる
- ganyariya がそれを読んでどういうことを考えたのか？がわかる
記事を読んで得られないこと
- 「エンジニアのためのマネジメントキャリアパス」の詳しい内容について
本の特徴と構成について
エンジニアのためのマネジメントキャリアパスは、以下のような読者を対象にしています。
- これから社会人として働き、自分の上司が配属される人
- 自分がメンターとなり、インターン生や内定アルバイトの方と仕事を進める人
- チームのリードエンジニアとなる人
- チームのマネージャーになる人
- CTO になる人
こちらの本では、章が進むにつれて内容が詳しくなっていきます。
具体的には、第 1 章では「メンティー・管理される側として心すべきこと」が記されています。
つまり、これから社会人として働き、自分の上司が配属される人向けです。
第 2 章では自身がメンターとなったときに心すべきことが記されています。
そして、第 3 章では自身がチームのリードエンジニアとなったときに心すべきことが記されています。
このように、章と役職が比例するように本が構成されています。
そのため、「今の自分の役職にあったところまで読めばいい」構成になっており、非常に読みやすいです。
ganyariya の場合、現時点では第 2 章「メンターになる」までが直接し、将来を見越して第 3 章「リードエンジニアになる」の章を読みました。
本をすべて読むのはなかなかに大変ですが、自分に関係ある部分まで読み進めるだけでよいのは気持ち的にも楽ですね。
第 1 章 マネジメントされる側の基本
第 1 章ではマネジメントされる側として心がけるべきことが記されています。
たとえば、 1on1 のときに何を話すべきなのか？などです。
上司に対して求めることとして「1on1 でフィードバックをもらうこと・意志を伝えること」が書いてあり、非常に大事だなと思いました。
1on1 をするときに、多くの場合単なる作業報告になっていることがあります。
しかし、メンターや上司とは同じチームになっていることが多く、チームの MTG でやっていることがすでに管理されているため、ただの二重報告になってしまいます。
そのため、 1on1 で話すべきことは
- 今の仕事・プロジェクトにおける課題を相談し、解決策を導き出す
- 将来のキャリアについて話す・MVPの取り方について相談する
- 自分の仕事や技術についてフィードバックをもらう
など、より自分を前に進められる・成長できるような内容を話すべきです。
自分が考えていること・やりたいことも話すべきです。
ganyariya はこれまで作業報告を多く行ってしまっていたため、ここ最近は課題やキャリア・フィードバックをできるだけ話そうとこころがけています。
社会人 1 年目のときは仕事の進め方がまるでわからず、作業報告をすることで進捗の管理や工数見積も合わせて行っていましたが、少しずつ仕事に慣れてきて自分でこなせるようになってきました。
そのため、よりチーム全体での課題について相談したり、自分の仕事の改善点を相談するなど、より良く進められる取り組みを 1on1 ですべきだなと感じました。
第 2 章 メンタリング
こちらの章では、はじめにインターン生のメンター、続いて新入社員に対するメンターになったときに気をつけるべきこと・心意気について書かれています。
しかし、大事にすべきことは同じであり
- 相手の言葉について傾聴する
- 的確なフィードバックをする
- 常にオープンな心をもつ
ことが大事だなと思いました。
相手の言葉について傾聴する
1on1 で話すときに自分のことが優先されて、相手の話をうまく聞けないことがあります。
ここでいう、相手の話を聞く、というのは相手の身振り手振りも踏まえながら、相手が本当に話したいこと・相談したいことを途中で止めず聞き出す、ということです。
自分のことを優先するのではなく、自分は聞き手側に徹して、相手が本当に話したいことを聞き出すことを意識しようと思います。
的確なフィードバックをする
「第一章 メンタリング」と同じであり、今度は自分がフィードバックする側として、相手の仕事がより良くなるような的確なフィードバックをするようにします。
ただし、押し付けにするのではなく、こういうやり方もあるよ〜など、より良くなる「提案・フィードバック」をするようにします。
自分のこれまでのメンタリングをふまえると、フィードバックがほとんどできていないな、と感じました。
進捗確認やここ最近あったことを優先してしまい、どのように仕事をしていくべきなのか、どこが良くてどこが改善できるポイントなのか、を伝えられていませんでした。
「フィードバックをする」を意識して、メンティーの方をサポートしようと思います。
常にオープンな心を持つ
ganyariya もそうですが、社会人として働いてくるとチームやプロダクトのあり方に慣れてきて、今の仕事の仕方に疑問を抱かなくなります。
疑問を抱かなくなると、改善が行われなくなり、同じフローを繰り返すだけになってしまいます。
インターン・内定アルバイト・新入社員の方々は新鮮な視点を持っており、できるだけその視点を活かせるよう、一緒に相談してそれを実現するべきです。
そのためにはメンターがオープンな心を持ち、否定するのではなく「どのようにすれば新しい解決策が実現できるか？」を考えることが大事です。
- 仕事ではできるだけ否定せずに、一緒に実現可能な解決策を考える
- 常に自我を持つ（自分で考えて自分で行動する）
が大事だなと改めて思いました。
第 3 章 リードエンジニア
チームにおけるリードエンジニアになったときに気をつけるべきことが書かれています。
この章を読んだうえで、リードエンジニアが大切にすべきこと・意識すべきことは以下の 3 つだなと思いました。
- 個人ではなく、チーム全体を技術的に前に進めること
- コミュニケーションを積極的にとること
- 全体のアーキテクチャを理解していること
チーム全体を前に進めること
エンジニアとして作業をしていたときは「目の前のタスク」を決められたスケジュール・ガントチャートに間に合うように実装することが求められます。
分からない仕様があればプランナーの方や他のエンジニアの方に相談を取り、決められた工数内で最適なアーキテクチャで読みやすいコード・変更可用性の高いコードを書くことが大事です。
しかし、リードエンジニアでは、個人ではなく「チーム・プロダクト全体」を前に進めることが求められます。
他のメンバーの方々が行っていることを把握し、適宜技術的なサポートを行ったり、プランナーの方との MTG を設定します。
スケジュール的に炎上しそうな箇所があれば、スケジュールの調整を行ったり、タスクを分割し、他のメンバーの方と一緒に並行してタスクを分担することもあります。
自分ひとりの作業を優先するのではなく、「チーム全体を前に進めて、そのうえで自分のコードも書く」ことがリードエンジニアには求められるのだな、と思いました。
コミュニケーションを積極的にとること
リードエンジニアがすべての技術ならびに仕様を把握している必要はありません。
より詳しい人に仕様を教えてもらったり、プランナーの方との MTG を設定します。
すべて 1 人で責任を負おうとするのではなく、あくまで一次受付として機能し、詳しい方を読んで一緒に進めていく、のが大事なのだなと思いました。
上記をふまえて、リードエンジニアはコミュニケーションのフットワークが軽く、気になったことにはとりあえず顔を出して、一緒に相談することが求められうなとも思いました。
全体のアーキテクチャを理解すること
コミュニケーションを積極的にとることで、詳しいメンバーの方に相談をとったり、タスクをお願いすることができます。
しかし、そのためには全体のアーキテクチャを把握していなければ、そもそもどの技術を使っているのか・誰が詳しいのか？などを知ることができません。
そのため、詳細も知っているべきですが、まずはプロダクトが成り立っているような全体のアーキテクチャを理解することが大事です。
また、アーキテクチャのコンポーネントそれぞれについて、誰が一番くわしいのかも把握しておくことが大事です（相談できるため）。
最後に
エンジニアのためのマネジメントキャリアパスを読んだうえで、スキルが増えてできることが増えていくと、「自分の手の届く範囲」も増えていくのだなと感じました。
（７つの習慣でいうと、自分を変えていくことで自分が影響を及ぼせる範囲が広がっていく）
自分の手の届く範囲が広がっていくと、自分が求められる仕事の仕方も変わってきます。
個人ではなくチームで前に進める、改善してく、ということを意識して仕事とユーザの方々に向き合っていこうと思います。