medibaでのキャリアパス
こんにちは。テクノロジーセンター6GでManagerをしている下地(@primunu)です。
メンバーとの雑談でたまに話題になるエンジニアのキャリアパス。
どのキャリアを選択するかはもちろん各々が決定しますが、昨今のソフトウェアエンジニアのキャリアパスは多様かつ、組織によって若干役割が異なる事があるので、目指す方向がわからず迷子になる事があると相談を受けました。
そこで一度立ち戻り、medibaではどんなキャリアパスがあるのか？また、どのような役割なのか？を整理を含め図解してみました。
キャリアパスの概要
役割を図解した所、23のキャリアがありました。
その中でもイメージが付きにくい、または他社と若干領域に乖離があるキャリアを重点的に説明していきます。
SRE
主な業務はAWS全体管理や、インフラ管理や構築、SLO/SLA/SLIの定義、セキュリティ、バジェット管理、トイルの洗い出しやトラッキング等が主な業務になります。なお、IaCやアーキテクチャ設計はリードバックエンドエンジニアやテックリードが実施する事が多いです。
インフラ組織から名前がSREに変わった背景があるので、SREという職能のコミットメント領域がまだ不明確という課題があり、組織の納得度を高める為にも定義したいと考えています。
※SRE奮闘記に今後記載していきます。
リードエンジニア(セキュリティエンジニア含)
豊富な知識・経験から最適なアーキテクチャを選定し、技術選定を行いながらPoCを回し、技術で牽引してくキャリアになります。後述するテックリードと似た振る舞いしますが大きな違いは影響範囲になります。リードエンジニアの影響範囲はチームになりますが、テックリードは組織全般に及びます。
ここまで記述するとエンジニアリングしかしないと思われがちですが、ステークホルダーとの会話も行いも各メンバーへの教示も行うので、ただコードを書くキャリアではありません。
テックリード予備軍のキャリアなのでテックリードと連携をしプロダクトの技術的意思決定を行います。
システムディレクター
medibaでは完全自社開発の会社ではなく、プロダクトによっては受託開発もあります。
現時点だと受託開発プロダクトのみのキャリアになり、そこでステークホルダーと技術ナレッジを活かしながらディレクションを行います。ディレクターという事もあり提案や、要件定義はもちろんの事、ファシリテータも行います。ステークホルダーや協力会社・外部会社と技術的な会話ができ、意思決定ができ必要があるので〇〇エンジニアの上級職になると感じています。
プロジェクトリーダー
プロダクトによってPjMと責務が被る事がありますが、開発チームオンリーのチームや、8人未満の小規模チームのリーダーがmedibaで言うプロジェクトリーダーになります。サーバントリーダーではなく前に出て引っ張っていくリーダーとなります。
ステークホルダーとの会話はもちろんの事、スケジュール管理や、チームビルディングも行います。チームによってはスクラムマスターがプロジェクトリーダーを兼任する事が多いと感じています。ハードスキルとソフトスキルの両面を求められるので、マネージャーを目指す方が通るキャリアになります。プレマネバランスですが感覚値としてプレーヤー7、マネージャー3です(個人の感想です)。
そんなプロジェクトリーダーですが、マネージャーとの大きな違いはピープルマネージャーと組織へのコミットメントの有無になります。チームへのコミットメントは当然ですが、組織への干渉は低く、ピープルマネージメントは直属マネージャーの責務になります。
品質管理リーダー
品質管理はスポットで入る事が多く、協力会社と連携する事が多いです。そこで試験項目作成やスケジュール確認、SLA的に問題ないか実施、確認すると平行し、協力会社との連携や契約、統率を行うのが品質管理リーダーになります。品質管理の知識以外にも他社を巻込み組織しなければらないので、メンバーをまとめ組織するスキルが求められます。E2Eテストのシナリオを記述したり品質管理におけるPDCAを回す所までは介入できておらず今後の課題となっています。
なお、品質管理とテスターの大きな違いは要件から試験項目作成ができるの有無です。
テックリード
テックリードとは完結に言うと、リードエンジニアの上位職になり、リードエンジニアの箇所でも触れましたが、影響範囲が組織全般となります。厳密にこれを実施する等はなく、PjMを実施したり、PoCを回したりと技術的な意思決定を主導し推進します。コードの品質管理はもちろんの事、チーム全体の生産性、アーキテクチャ・設計も行うので広さと深さの両面を求められます。
なお、medibaのテックリードはマネージャーではなく、成長支援等は行やメンタリングは適宜行うもののコミット領域ではなく、あくまでも技術でリードしプロダクトの成功に寄与するキャリアになります。
Unitマネージャー、マネージャー、シニアマネージャー。何が違うの？
細かい違いはあるものの、大きな違いは管轄するチームの種別とコミット領域、比率になります。
Unitマネージャーはプロダクト横断チーム、マネージャーとシニアマネージャーはプロダクトに強く関わるマネージャーになります。マネージャーとシニアマネージャーの役割は大きく変わりませんが、シニアマネージャーの方が組織へのコミットメントが求めれます。
PO(プロダクトオーナー)や、PM(プロダクトマネージャー)のキャリアパスは？
Biz職からのPO/PMのキャリアパスはあるものの、POの業務範囲にエンジニアに馴染みが薄いPL管理が含まれているのが起因しているせいか、エンジニアとしてのPO/PMのキャリアを描けていません。【翻訳】プロダクトマネジメントトライアングルにあるように、プロダクトは開発者、ユーザー、ビジネスの 3 つで構成されており、エンジニア視点は必要不可欠だと認識しています。
エンジニアリング、データ分析、エンジニアとのコミュニケーションと言った領域をカバーできるのはエンジニア出身のPO/PMの強みだと感じており、プロダクトの意思決定を素早く判断できると感じています。
先述の通りまだエンジニアのキャリアとして描けていないのもの、現場ではマネージャーや、テックリードが中心となりエンジニア領域をカバーしています。マルチタスクになってしまうので、キャリアパスにない事を組織課題と捉え、PO/PMのコミット領域を明確にし、キャリアパスとして描きたいと考えています。
まとめ
如何だったでしょうか。複雑に見えるキャリアパスですが、目指す方向の咀嚼ができれば、日々の行動が変わり、目標、引いては組織へのコミットメントが高くなると考えています。
これを気にキャリアプランを再考してみるのは如何でしょうか。少しでも手助けになれば幸いです
