皆さん、こんにちは。新卒で入社して6年目のPです。
去年から管理職として、日々メンバーの育成と機能開発の取りまとめをしています。
今回は、メンバーの育成について、取り組みや意識している点について少しお話しさせていただきます。
若手の育成をしている方々に、少しでも役立つ話ができれば幸いです。
まずは簡単に自己紹介をさせていただきます。
私は新卒で入社し、2年目からプロジェクトリーダー（PL）を務め、4年目にはプロジェクトマネージャー（PM）を経験し、5年目の10月にユニット長になりました。（ユニットは弊社の社内組織図における最小のチームを指します）
エンジニアを名乗っていますが、実はプログラミングはあまり得意ではありません。
製品開発チームには技術系のエキスパートが多くいますが、私は完全にマネージャータイプなので、技術的な話についていけないことも多々あります。
プライベートでは学マスでアイドルをプロデュースしています。（←こちらが本業）
チームの構成
紹介が遅れましたが、私は製品開発部門のユニット長を務めています。
育成の話をする前に、軽くメンバーの紹介をしたいと思います。
- Y：新卒5年目、アーキテクト
- M：新卒3年目、プロジェクトリーダー、コーダー
- H：新卒2年目、コーダー
- S：新卒1年目、コーダー
- N：BP、プロジェクトリーダー、コーダー
見ての通り若手しかいません（笑）。
コーダーと表記しましたが、設計から試験実施まですべて行います。
育成で取り組んでいること
それでは本題に入ります。
まずは、メンバー育成で取り組んでいることを2点紹介します。
１．メンバーにタスクを管理させる
メンバーにタスクを任せ、成果物の完成まで推進してもらうことを徹底しています。
具体的には、私でなければできない仕事（ユニット長の権限でしか操作できないものなど）以外は、すべてタスクとしてメンバーに渡しています。
また、スケジュールやタスク量の相談をメンバー側から提案するようなルールも設定しました。
このルールを導入した当初はあまり相談がありませんでしたが、現在ではメンバーが自分のタスク状況を把握し、新しいタスクに対して「他のタスクに影響します」と報告・相談してくれるようになっています。
メンバーが自分でタスク管理をできるようになると、マネージャーの負担が減ります。
マネージャーの負担が減ることで余裕が生まれ、その余裕が重要なカギとなります。
余裕があると全体を落ち着いて見渡すことができ、メンバーがミスをしても最悪の場合、自分が手を動かして対処することが可能です。
自分がタスクを巻き取ることになったとしても、それは元々自分が持っていたタスクが進まなかった状況なので、マイナスにはなりません。
２．タスクを振るタイミングで、何に期待をしているのかを伝える
最近にはなりますが、プロジェクトの開始時にメンバーに対して期待することを伝える取り組みを始めました。
具体的な期待を示すことで、成長の指標が明確になり、モチベーションも上がりやすくなると思っています。
自己成長について明確なビジョンを持っている人でない限り、上司からの期待や目標が示されている方がやりやすいと感じるのではないでしょうか。
また、上司と部下、先輩と後輩の間で成長に対する認識のズレが減り、評価が容易になると考えています。
私は以下のようなイメージでメンバーに伝えています。
「次のプロジェクトでは、君のリスク管理能力を活かしてほしい。今回は難易度の高いプロジェクトでリスクも多いけれども、これまでにないリスク観点については私や他のPLに相談しながら洗い出し、安全にプロジェクトを進めてほしい。プロジェクトを進めながら成長していこう。」
「次のプロジェクトでは、ソースコードのレビューを担当してもらいたい。初めての経験だから、最初はこれまでレビューを担当していたAさんにサポートについてもらう予定なので、Aさんに相談しつつ、アドバイスを受けてレビュアーとして成長してほしい。」
育成で意識していること
次に、メンバー育成で普段意識していることを2点紹介します。
１．このままスケールして破綻しないか
これは5年前に新人教育で教育担当の方に言われて今でも大事にしている考え方です。
「上手くいったからそこで終わりではなく、規模が大きくなっても通用するか考えろ」
私のチームは現在、若手メンバーが多く、小規模です。
しかし、3年後や5年後を見据えると、今の若手は中堅として活躍し、新たな若手メンバーが加わり、チームは大きく成長していることでしょう。
その時に、今のやり方が通用するかを考えます。
人が増えるということは、管理者の負担も増えるということです。
その負担を軽減するためには、新たな管理者を増やし、管理対象を分散させる必要があります。
製造者が増えれば、レビューの量が今以上に増えるでしょう。
現在のレビュアーの数のままでは、いずれレビュー専任の役割になってしまうかもしれません。
そうなってしまうとメンバーも苦しいですし、成果物のレベルに限界が来るため、チーム全体も苦しくなってしまいます。
そのため、今回が上手くいったとしても、将来に向けてさらに成長できる点がないかを探し、メンバーの次のステップを考えます。
２．結果と成長は相反する
ここで言う結果と成長は以下のイメージです。
良い結果＝スケジュールを縮めてコストを減らし、品質が高い製品を作る。
良い成長＝メンバーがそれぞれ今の能力だと少し難しいことに挑戦して、新しいことができるようになる
良い結果だけを追い求めると、得意な人に得意なことを任せるのが最適です。
しかし、これを続けると成長がありません。
メンバーは得意分野の精度が上がるだけで、新しいスキルは身につかず、次のプロジェクトでも同じ体制しか取れなくなります。
同じようなものを作り続けるならそれでも良いかもしれませんが、情報分野では3年も経てば技術の進歩が著しく、セキュリティやパフォーマンスの要件も厳しくなります。
つまり、同じ体制を続けていると世の中に取り残されてしまいます。
逆に、成長を目指してメンバーに未経験の領域のタスクを割り当てると、先述のように取り残されることはないかもしれません。
しかし、経験のない人が担当するため品質に不安があり、調査や学習が必要となりスケジュールが遅れるなど、結果が伴わないこともあります。
当たり前ですが、結果が出ないと評価されません。
メンバーは難しいことに挑戦して成長しているのに、会社からの評価が低く、モチベーションの低下に繋がってしまいます。
最悪の場合、離職に繋がり、同じ体制どころかマイナスになる可能性すらあります。
結局はバランスが重要ですが、私はプロジェクトの前半では成長を意識し、後半では結果を重視しています。
前半で成長の機会を提供し、後半では余裕があれば成長を重視し、余裕がなければ結果を重視してアサインの調整やWBSを変更します。
まとめ
日記とは？という感じですが、ここまで読んでいただきありがとうございます。
メンバー育成は、役職の有無に関わらず後輩を持つ社員にとって共通の課題だと思いますので、少しでも参考になれば幸いです。
先輩像やリーダー像、マネージャー像は人によって異なるため、そのやり方も多岐にわたります。
自分に合った方法を見つけるためには、他者から学ぶことが非常に有効だと思います。
私も日々、他のチームリーダーや書籍から新しい考え方や手法を学び、試行錯誤を繰り返していますので、一緒に頑張っていきましょう。
皆様と共に働けることを心待ちにしています。
お知らせ
ecbeingでは新進気鋭なエンジニアを募集しております！
careers.ecbeing.tech
